From jwilhelm at openjdk.java.net  Thu Jul  1 00:17:39 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Thu, 1 Jul 2021 00:17:39 GMT
Subject: RFR: Merge jdk17
Message-ID: <dVIsur6xwapgYbOUzsTSSunrJ8FbSqHGYkXFkK2S8mk=.e36b7d93-c9a1-4299-8b69-287b71855a77@github.com>

Forwardport JDK 17 -> JDK 18

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

Commit messages:
 - Merge
 - 8262841: Clarify the behavior of PhantomReference::refersTo
 - 8269703: ProblemList vmTestbase/nsk/jvmti/scenarios/sampling/SP07/sp07t002/TestDescription.java on Windows-X64 with -Xcomp
 - 8269513: Clarify the spec wrt `useOldISOCodes` system property
 - 8268897: [TESTBUG] compiler/compilercontrol/mixed/RandomCommandsTest.java must not fail on Command.quiet
 - 8268557: Module page uses unstyled table class
 - 8269691: ProblemList sun/management/jdp/JdpDefaultsTest.java on Linux-aarch64
 - 8269486: CallerAccessTest fails for non server variant
 - 8269614: [s390] Interpreter checks wrong bit for slow path instance allocation
 - 8269594: assert(_handle_mark_nesting > 1) failed: memory leak: allocating handle outside HandleMark
 - ... and 6 more: https://git.openjdk.java.net/jdk/compare/85262c71...d9b654b1

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

Changes: https://git.openjdk.java.net/jdk/pull/4645/files
  Stats: 394 lines in 29 files changed: 280 ins; 26 del; 88 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4645.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4645/head:pull/4645

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

From kbarrett at openjdk.java.net  Thu Jul  1 00:36:00 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Thu, 1 Jul 2021 00:36:00 GMT
Subject: [jdk17] RFR: JDK-8225667: Clarify the behavior of System::gc
 w.r.t. reference processing [v2]
In-Reply-To: <ZpgnqEdpEAzq3oLh7z8Kcb0qF0geRqpY4tFlLId1OpM=.b50e1c35-1906-4b92-ac97-e35c6b5f417e@github.com>
References: <P5HIv6qhUDaRF1LiEYjyLdvKPUK9CNH81gsb8Ja4UEw=.2a1eab1a-4b88-4d41-85b4-8ffedb39cdc7@github.com>
 <ZpgnqEdpEAzq3oLh7z8Kcb0qF0geRqpY4tFlLId1OpM=.b50e1c35-1906-4b92-ac97-e35c6b5f417e@github.com>
Message-ID: <--tNdy1YDxh-RXuM3cjrjzQP_TufeEytnG3eYZSUYnw=.48c95320-90aa-4a97-8865-dd293c34988e@github.com>

On Wed, 30 Jun 2021 22:52:36 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> This spec clarification is a follow-up to [JDK-8224760](https://bugs.openjdk.java.net/browse/JDK-8224760?focusedCommentId=14268320&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14268320) w.r.t. reference processing.  Since there is no guarantee for any memory reclamation by the invocation of `System::gc`, the spec should also clarify that there is no guarantee in determining the change of reachability of any objects or any particular number of `Reference` objects be enqueued and cleared.
>> 
>> CSR:
>>    https://bugs.openjdk.java.net/browse/JDK-8269690
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Kim's suggestion on the wording

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/183

From jwilhelm at openjdk.java.net  Thu Jul  1 01:06:45 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Thu, 1 Jul 2021 01:06:45 GMT
Subject: RFR: Merge jdk17 [v2]
In-Reply-To: <dVIsur6xwapgYbOUzsTSSunrJ8FbSqHGYkXFkK2S8mk=.e36b7d93-c9a1-4299-8b69-287b71855a77@github.com>
References: <dVIsur6xwapgYbOUzsTSSunrJ8FbSqHGYkXFkK2S8mk=.e36b7d93-c9a1-4299-8b69-287b71855a77@github.com>
Message-ID: <jCYsdyLJsNDVNYwDXY7qRD1OZ4eUNdhmKXLbleDHnmE=.2ec17623-9a83-4f15-a41c-507b6e0591b2@github.com>

> Forwardport JDK 17 -> JDK 18

Jesper Wilhelmsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 125 commits:

 - Merge
 - 8268637: Update --release 17 symbol information for JDK 17 build 28
   
   Reviewed-by: iris
 - 8269678: Remove unimplemented and unused os::bind_to_processor()
   
   Reviewed-by: dcubed
 - 8268457: XML Transformer outputs Unicode supplementary character incorrectly to HTML
   
   Reviewed-by: lancea, naoto, iris, joehw
 - 8269516: AArch64: Assembler cleanups
   
   Reviewed-by: ngasson, adinn
 - 8261495: Shenandoah: reconsider update references memory ordering
   
   Reviewed-by: zgu, rkennke
 - 8269478: Shenandoah: gc/shenandoah/mxbeans tests should be more resilient
   
   Reviewed-by: rkennke
 - 8269416: [JVMCI] capture libjvmci crash data to a file
   
   Reviewed-by: kvn, dholmes
 - 8268906: gc/g1/mixedgc/TestOldGenCollectionUsage.java assumes that GCs take 1ms minimum
   
   Reviewed-by: kbarrett, ayang, lkorinth
 - 8263461: jdk/jfr/event/gc/detailed/TestEvacuationFailedEvent.java uses wrong mechanism to cause evacuation failure
   
   Reviewed-by: kbarrett, iwalulya, ayang
 - ... and 115 more: https://git.openjdk.java.net/jdk/compare/9ac63a6e...d9b654b1

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

Changes: https://git.openjdk.java.net/jdk/pull/4645/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4645&range=01
  Stats: 31079 lines in 656 files changed: 18219 ins; 10796 del; 2064 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4645.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4645/head:pull/4645

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

From jwilhelm at openjdk.java.net  Thu Jul  1 01:06:47 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Thu, 1 Jul 2021 01:06:47 GMT
Subject: Integrated: Merge jdk17
In-Reply-To: <dVIsur6xwapgYbOUzsTSSunrJ8FbSqHGYkXFkK2S8mk=.e36b7d93-c9a1-4299-8b69-287b71855a77@github.com>
References: <dVIsur6xwapgYbOUzsTSSunrJ8FbSqHGYkXFkK2S8mk=.e36b7d93-c9a1-4299-8b69-287b71855a77@github.com>
Message-ID: <9kd-vCEotcwQxZlMbaZi-hGcyK6i6qGQRVefV1PeDBg=.d2fbbe58-7c3a-46d5-b685-66ab35fd8b70@github.com>

On Thu, 1 Jul 2021 00:08:51 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 17 -> JDK 18

This pull request has now been integrated.

Changeset: 9def3b06
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/9def3b068e9ee065e2e545bb35f8dc56ccfe5955
Stats:     394 lines in 29 files changed: 280 ins; 26 del; 88 mod

Merge

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

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

From Alan.Bateman at oracle.com  Thu Jul  1 08:43:46 2021
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 1 Jul 2021 09:43:46 +0100
Subject: RFR: 8190753: (zipfs): Accessing a large entry (> 2^31 bytes)
 leads to a negative initial size for ByteArrayOutputStream [v2]
In-Reply-To: <f6ba21c5-6d3e-9491-3d3a-a40fee147640@gmail.com>
References: <0GJVLeCPoDI4FePU-Z-NMwJHaS2XyH9S28LgqI1LNB8=.e32743dc-a6dd-475d-88ab-16ed3f46beab@github.com>
 <C1tXC_OuVRZJHFI1P0mHAK8Oa95pEPgcsBsfOgebzvg=.35c3a21c-f02a-471c-901a-d22e0ec5a759@github.com>
 <X-L6wgK4tmBlZsu0b5egUts_ckRsn-yjjklqMPO_DoI=.0e1f2557-18c4-478a-b7db-c1e6c8046204@github.com>
 <f6ba21c5-6d3e-9491-3d3a-a40fee147640@gmail.com>
Message-ID: <083bb049-3eb5-fb83-4846-29627c7faf05@oracle.com>

On 30/06/2021 17:15, Jaikiran Pai wrote:
>
> I understand that Alan's suggestion holds good and we should have some 
> logic in place which switches to using a temp file once we notice that 
> the sizes we are dealing with can exceed some threshold, but I guess 
> that is something we need to do separately outside of this PR?

My comment was mostly just to point out that it's only a partial fix and 
it will eventually fail with an OOME once the deflated size is too big 
for the BAOS. I don't have a strong opinion on whether the complete fix 
is done in one, two or many PRs but I think the first step could be to 
use the "useTempFile" path when the entry size is larger than some (10s 
of MB?) threshold.

-Alan

From jai.forums2013 at gmail.com  Thu Jul  1 09:13:35 2021
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Thu, 1 Jul 2021 14:43:35 +0530
Subject: RFR: 8190753: (zipfs): Accessing a large entry (> 2^31 bytes)
 leads to a negative initial size for ByteArrayOutputStream [v2]
In-Reply-To: <083bb049-3eb5-fb83-4846-29627c7faf05@oracle.com>
References: <0GJVLeCPoDI4FePU-Z-NMwJHaS2XyH9S28LgqI1LNB8=.e32743dc-a6dd-475d-88ab-16ed3f46beab@github.com>
 <C1tXC_OuVRZJHFI1P0mHAK8Oa95pEPgcsBsfOgebzvg=.35c3a21c-f02a-471c-901a-d22e0ec5a759@github.com>
 <X-L6wgK4tmBlZsu0b5egUts_ckRsn-yjjklqMPO_DoI=.0e1f2557-18c4-478a-b7db-c1e6c8046204@github.com>
 <f6ba21c5-6d3e-9491-3d3a-a40fee147640@gmail.com>
 <083bb049-3eb5-fb83-4846-29627c7faf05@oracle.com>
Message-ID: <2c8f9b6e-80d8-95ae-62b0-5ca4d9d3cd22@gmail.com>

Thank you Alan and Lance. I'll update this PR shortly with the proposed 
approach.

-Jaikiran

On 01/07/21 2:13 pm, Alan Bateman wrote:
> On 30/06/2021 17:15, Jaikiran Pai wrote:
>>
>> I understand that Alan's suggestion holds good and we should have 
>> some logic in place which switches to using a temp file once we 
>> notice that the sizes we are dealing with can exceed some threshold, 
>> but I guess that is something we need to do separately outside of 
>> this PR?
>
> My comment was mostly just to point out that it's only a partial fix 
> and it will eventually fail with an OOME once the deflated size is too 
> big for the BAOS. I don't have a strong opinion on whether the 
> complete fix is done in one, two or many PRs but I think the first 
> step could be to use the "useTempFile" path when the entry size is 
> larger than some (10s of MB?) threshold.
>
> -Alan

From github.com+10835776+stsypanov at openjdk.java.net  Thu Jul  1 10:38:28 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Thu, 1 Jul 2021 10:38:28 GMT
Subject: RFR: 8268764: Use Long.hashCode() instead of int-cast where
 applicable [v2]
In-Reply-To: <ZVcup6_4t_d6djkaIRuX8kk7qs7iUSBdvfTS2CwJR3Y=.fa4ac0b9-41df-4ade-8c38-7f262e5145f3@github.com>
References: <FWTqr_PuocBt9WX9bDw7_ugW8N818tZqV8O03ziXG20=.098ec08a-cb98-4f3a-8f83-fde4221ba583@github.com>
 <ZVcup6_4t_d6djkaIRuX8kk7qs7iUSBdvfTS2CwJR3Y=.fa4ac0b9-41df-4ade-8c38-7f262e5145f3@github.com>
Message-ID: <HB1z1cJI9L5pqd_WmVvj9vi018gqtImK_DEuX-sUtP8=.9ae2c48b-797f-4cd6-99ae-700daa4d8e55@github.com>

On Wed, 30 Jun 2021 11:49:51 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

>> In some JDK classes there's still the following hashCode() implementation:
>> 
>> long objNum;
>> 
>> public int hashCode() {
>>     return (int) objNum;
>> }
>> 
>> This outdated expression should be replaced with Long.hashCode(long) as it
>> 
>> - uses all bits of the original value, does not discard any information upfront. For example, depending on how you are generating the IDs, the upper bits could change more frequently (or the opposite).
>> 
>> - does not introduce any bias towards values with more ones (zeros), as it would be the case if the two halves were combined with an OR (AND) operation.
>> 
>> See https://stackoverflow.com/a/4045083
>> 
>> This is related to https://github.com/openjdk/jdk/pull/4309
>
> ?????? ??????? has updated the pull request with a new target base 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 8268764
>  - 8268764: Use Long.hashCode() instead of int-cast where applicable

Hi Kevin, thanks for review! I've updated copy-right year

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

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

From github.com+10835776+stsypanov at openjdk.java.net  Thu Jul  1 10:38:24 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Thu, 1 Jul 2021 10:38:24 GMT
Subject: RFR: 8268764: Use Long.hashCode() instead of int-cast where
 applicable [v3]
In-Reply-To: <FWTqr_PuocBt9WX9bDw7_ugW8N818tZqV8O03ziXG20=.098ec08a-cb98-4f3a-8f83-fde4221ba583@github.com>
References: <FWTqr_PuocBt9WX9bDw7_ugW8N818tZqV8O03ziXG20=.098ec08a-cb98-4f3a-8f83-fde4221ba583@github.com>
Message-ID: <ebvBjXWBYHat1Sel4UzveO8VLsyKMKdbbJ4BaMjcnJk=.4ed164b0-43d8-4668-b0f5-d90209d79fb7@github.com>

> In some JDK classes there's still the following hashCode() implementation:
> 
> long objNum;
> 
> public int hashCode() {
>     return (int) objNum;
> }
> 
> This outdated expression should be replaced with Long.hashCode(long) as it
> 
> - uses all bits of the original value, does not discard any information upfront. For example, depending on how you are generating the IDs, the upper bits could change more frequently (or the opposite).
> 
> - does not introduce any bias towards values with more ones (zeros), as it would be the case if the two halves were combined with an OR (AND) operation.
> 
> See https://stackoverflow.com/a/4045083
> 
> This is related to https://github.com/openjdk/jdk/pull/4309

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

  8268764: Update copy-right year

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4491/files
  - new: https://git.openjdk.java.net/jdk/pull/4491/files/12a1d3ac..932c26ad

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

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

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

From kevinw at openjdk.java.net  Thu Jul  1 11:39:00 2021
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Thu, 1 Jul 2021 11:39:00 GMT
Subject: RFR: 8268764: Use Long.hashCode() instead of int-cast where
 applicable [v3]
In-Reply-To: <ebvBjXWBYHat1Sel4UzveO8VLsyKMKdbbJ4BaMjcnJk=.4ed164b0-43d8-4668-b0f5-d90209d79fb7@github.com>
References: <FWTqr_PuocBt9WX9bDw7_ugW8N818tZqV8O03ziXG20=.098ec08a-cb98-4f3a-8f83-fde4221ba583@github.com>
 <ebvBjXWBYHat1Sel4UzveO8VLsyKMKdbbJ4BaMjcnJk=.4ed164b0-43d8-4668-b0f5-d90209d79fb7@github.com>
Message-ID: <RNAM2x8XAZGcoB3x5XrGJrXRre7sU01v9IL1OyljLhA=.98fc305e-6ec4-470b-8f8b-3942e87ffced@github.com>

On Thu, 1 Jul 2021 10:38:24 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

>> In some JDK classes there's still the following hashCode() implementation:
>> 
>> long objNum;
>> 
>> public int hashCode() {
>>     return (int) objNum;
>> }
>> 
>> This outdated expression should be replaced with Long.hashCode(long) as it
>> 
>> - uses all bits of the original value, does not discard any information upfront. For example, depending on how you are generating the IDs, the upper bits could change more frequently (or the opposite).
>> 
>> - does not introduce any bias towards values with more ones (zeros), as it would be the case if the two halves were combined with an OR (AND) operation.
>> 
>> See https://stackoverflow.com/a/4045083
>> 
>> This is related to https://github.com/openjdk/jdk/pull/4309
>
> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8268764: Update copy-right year

Marked as reviewed by kevinw (Committer).

OK, one more (C) in src/jdk.jdi/share/classes/com/sun/tools/jdi/ReferenceTypeImpl.java and done. 8-)
Needs a second Review before integrating, thanks.

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

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

From naoto at openjdk.java.net  Thu Jul  1 12:12:02 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 1 Jul 2021 12:12:02 GMT
Subject: [jdk17] Integrated: 8269704: Typo in j.t.Normalizer.normalize()
In-Reply-To: <5tcQNfqKKkO41BoxbhS8uzWis7SfJAGtyTJsFt0UFm4=.61b2691d-d8f1-4242-be27-9937d6c0ab0d@github.com>
References: <5tcQNfqKKkO41BoxbhS8uzWis7SfJAGtyTJsFt0UFm4=.61b2691d-d8f1-4242-be27-9937d6c0ab0d@github.com>
Message-ID: <uqSFpZOEMK3GhDoELh1Vo8JxdcaP-Lphllf-ezx1d-4=.f8764837-7d67-4b2e-a48d-5292c80c79db@github.com>

On Wed, 30 Jun 2021 21:38:43 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> A trivial typo fix.

This pull request has now been integrated.

Changeset: 54dd510b
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.java.net/jdk17/commit/54dd510bd5211dc440285dd53ca0e41c85e23552
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8269704: Typo in j.t.Normalizer.normalize()

Reviewed-by: joehw, prappo, iris

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

PR: https://git.openjdk.java.net/jdk17/pull/187

From github.com+10835776+stsypanov at openjdk.java.net  Thu Jul  1 12:19:53 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Thu, 1 Jul 2021 12:19:53 GMT
Subject: RFR: 8268764: Use Long.hashCode() instead of int-cast where
 applicable [v4]
In-Reply-To: <FWTqr_PuocBt9WX9bDw7_ugW8N818tZqV8O03ziXG20=.098ec08a-cb98-4f3a-8f83-fde4221ba583@github.com>
References: <FWTqr_PuocBt9WX9bDw7_ugW8N818tZqV8O03ziXG20=.098ec08a-cb98-4f3a-8f83-fde4221ba583@github.com>
Message-ID: <eciHLB1bKgy02_eV0d-Y-RiECZshzMxHakK2ZaUhFk0=.298fe17f-0913-4f1e-8eba-4587c28b05b1@github.com>

> In some JDK classes there's still the following hashCode() implementation:
> 
> long objNum;
> 
> public int hashCode() {
>     return (int) objNum;
> }
> 
> This outdated expression should be replaced with Long.hashCode(long) as it
> 
> - uses all bits of the original value, does not discard any information upfront. For example, depending on how you are generating the IDs, the upper bits could change more frequently (or the opposite).
> 
> - does not introduce any bias towards values with more ones (zeros), as it would be the case if the two halves were combined with an OR (AND) operation.
> 
> See https://stackoverflow.com/a/4045083
> 
> This is related to https://github.com/openjdk/jdk/pull/4309

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

  8268764: Update copy-right year

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4491/files
  - new: https://git.openjdk.java.net/jdk/pull/4491/files/932c26ad..20ad76be

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

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

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

From github.com+10835776+stsypanov at openjdk.java.net  Thu Jul  1 12:19:55 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Thu, 1 Jul 2021 12:19:55 GMT
Subject: RFR: 8268764: Use Long.hashCode() instead of int-cast where
 applicable [v3]
In-Reply-To: <ebvBjXWBYHat1Sel4UzveO8VLsyKMKdbbJ4BaMjcnJk=.4ed164b0-43d8-4668-b0f5-d90209d79fb7@github.com>
References: <FWTqr_PuocBt9WX9bDw7_ugW8N818tZqV8O03ziXG20=.098ec08a-cb98-4f3a-8f83-fde4221ba583@github.com>
 <ebvBjXWBYHat1Sel4UzveO8VLsyKMKdbbJ4BaMjcnJk=.4ed164b0-43d8-4668-b0f5-d90209d79fb7@github.com>
Message-ID: <KfVPBIhy44IKY4Nq3-UmI69sQPfr0Fb2oz_0jgykjfQ=.2edc1651-5efb-43d7-8ac6-5ca82e87713d@github.com>

On Thu, 1 Jul 2021 10:38:24 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

>> In some JDK classes there's still the following hashCode() implementation:
>> 
>> long objNum;
>> 
>> public int hashCode() {
>>     return (int) objNum;
>> }
>> 
>> This outdated expression should be replaced with Long.hashCode(long) as it
>> 
>> - uses all bits of the original value, does not discard any information upfront. For example, depending on how you are generating the IDs, the upper bits could change more frequently (or the opposite).
>> 
>> - does not introduce any bias towards values with more ones (zeros), as it would be the case if the two halves were combined with an OR (AND) operation.
>> 
>> See https://stackoverflow.com/a/4045083
>> 
>> This is related to https://github.com/openjdk/jdk/pull/4309
>
> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8268764: Update copy-right year

Right, done!

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

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

From tschatzl at openjdk.java.net  Thu Jul  1 12:48:03 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Thu, 1 Jul 2021 12:48:03 GMT
Subject: [jdk17] RFR: JDK-8225667: Clarify the behavior of System::gc
 w.r.t. reference processing [v2]
In-Reply-To: <ZpgnqEdpEAzq3oLh7z8Kcb0qF0geRqpY4tFlLId1OpM=.b50e1c35-1906-4b92-ac97-e35c6b5f417e@github.com>
References: <P5HIv6qhUDaRF1LiEYjyLdvKPUK9CNH81gsb8Ja4UEw=.2a1eab1a-4b88-4d41-85b4-8ffedb39cdc7@github.com>
 <ZpgnqEdpEAzq3oLh7z8Kcb0qF0geRqpY4tFlLId1OpM=.b50e1c35-1906-4b92-ac97-e35c6b5f417e@github.com>
Message-ID: <o9isO3GcfpO6KnN92bzrZWebOH9oVA9vcUK0jP4nt1U=.203f0c3b-a65f-4a78-8bfa-6dab0e949dd5@github.com>

On Wed, 30 Jun 2021 22:52:36 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> This spec clarification is a follow-up to [JDK-8224760](https://bugs.openjdk.java.net/browse/JDK-8224760?focusedCommentId=14268320&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14268320) w.r.t. reference processing.  Since there is no guarantee for any memory reclamation by the invocation of `System::gc`, the spec should also clarify that there is no guarantee in determining the change of reachability of any objects or any particular number of `Reference` objects be enqueued and cleared.
>> 
>> CSR:
>>    https://bugs.openjdk.java.net/browse/JDK-8269690
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Kim's suggestion on the wording

Marked as reviewed by tschatzl (Reviewer).

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

PR: https://git.openjdk.java.net/jdk17/pull/183

From alanb at openjdk.java.net  Thu Jul  1 13:07:59 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 1 Jul 2021 13:07:59 GMT
Subject: RFR: 8251329: (zipfs) Files.walkFileTree walks infinitely if zip
 has dir named "." inside
In-Reply-To: <H5Dy39I78mG6FE2N9U5vZnEhGI2zcIaxGvJ8uZBCGM0=.f3ba4976-f985-4002-87f3-da234b3c402d@github.com>
References: <H5Dy39I78mG6FE2N9U5vZnEhGI2zcIaxGvJ8uZBCGM0=.f3ba4976-f985-4002-87f3-da234b3c402d@github.com>
Message-ID: <ulkuJloqkrTihc2c_FI3Vr9HeBO7XsrkXzzJWzYxdJY=.6fa48d22-b72a-4869-b87a-07bd97465eb5@github.com>

On Sun, 27 Jun 2021 13:13:42 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this proposed fix for https://bugs.openjdk.java.net/browse/JDK-8251329?
> 
> As noted in that issue, if a zip filesystem created on top of a jar containing a "./" entry is "walked" using the `Files.walkFileTree`, it leads to a infinite never ending iteration (which ultimately fails with Java heap space OOM).
> 
> Alan notes in that issue that:
> 
>> This is more likely an issue with the zipfs DirectoryStream implementation. A DirectoryStream is specified to not include elements that for the special links to the current or parent directory. It should be rare. 
> 
> This indeed turned out to be an issue in the `jdk.nio.zipfs.ZipDirectoryStream#iterator()` implementation where it calls the `jdk.nio.zipfs.ZipFileSystem#iteratorOf(...)` implementation.  The implementation, unlike what the javadoc of `java.nio.file.DirectoryStream` states, was including the "." and ".." paths in its returned iterator:
> 
>> The elements returned by the iterator are in no specific order. Some file
>  systems maintain special links to the directory itself and the directory's
>   parent directory. Entries representing these links are not returned by the
>   iterator.
> 
> 
> The proposed fix in this patch checks the paths for "." and "..", similar to what the `sun.nio.fs.UnixDirectoryStream` does in its `isSelfOrParent` and skips those paths from being added into the returned iterator. The `jdk.nio.zipfs.ZipFileSystem#iteratorOf(...)` (where this change has been done) is currently only used by `jdk.nio.zipfs.ZipDirectoryStream#iterator()` and has package-private visibility, so this change shouldn't impact any other usage/expectations.
> 
> A new jtreg test has been added to reproduce this issue and verify the fix. Local testing of the `test/jdk/jdk/nio/` (including this new test) went fine without any issues after this change. I will be triggering a `tier1` test locally in a while.

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

> 1969:         }
> 1970:         return false;
> 1971:     }

It might be a bit clearer if ZipPath define isSelfOrParent(), that would avoid needing to expose the internal representation.

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

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

From jpai at openjdk.java.net  Thu Jul  1 13:25:37 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Thu, 1 Jul 2021 13:25:37 GMT
Subject: RFR: 8251329: (zipfs) Files.walkFileTree walks infinitely if zip
 has dir named "." inside [v2]
In-Reply-To: <ulkuJloqkrTihc2c_FI3Vr9HeBO7XsrkXzzJWzYxdJY=.6fa48d22-b72a-4869-b87a-07bd97465eb5@github.com>
References: <H5Dy39I78mG6FE2N9U5vZnEhGI2zcIaxGvJ8uZBCGM0=.f3ba4976-f985-4002-87f3-da234b3c402d@github.com>
 <ulkuJloqkrTihc2c_FI3Vr9HeBO7XsrkXzzJWzYxdJY=.6fa48d22-b72a-4869-b87a-07bd97465eb5@github.com>
Message-ID: <y3qwFFskkgTk96tsbVS1AKz4GNTgdoFBzqOtujKzvwc=.8ae3da6a-da7a-4a9e-ac86-1fe83357cc86@github.com>

On Thu, 1 Jul 2021 13:05:26 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   implement review suggestion - move isSelfOrParent to ZipPath class
>
> src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 1971:
> 
>> 1969:         }
>> 1970:         return false;
>> 1971:     }
> 
> It might be a bit clearer if ZipPath define isSelfOrParent(), that would avoid needing to expose the internal representation.

Done. I've updated the PR to implement this suggestion.

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

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

From jpai at openjdk.java.net  Thu Jul  1 13:25:32 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Thu, 1 Jul 2021 13:25:32 GMT
Subject: RFR: 8251329: (zipfs) Files.walkFileTree walks infinitely if zip
 has dir named "." inside [v2]
In-Reply-To: <H5Dy39I78mG6FE2N9U5vZnEhGI2zcIaxGvJ8uZBCGM0=.f3ba4976-f985-4002-87f3-da234b3c402d@github.com>
References: <H5Dy39I78mG6FE2N9U5vZnEhGI2zcIaxGvJ8uZBCGM0=.f3ba4976-f985-4002-87f3-da234b3c402d@github.com>
Message-ID: <YPCqIo02ztuhCJjbbrGnaF_FomLwH8ZrRu0JGj3Nc40=.05cc10af-9962-425f-8b90-86261619822e@github.com>

> Can I please get a review of this proposed fix for https://bugs.openjdk.java.net/browse/JDK-8251329?
> 
> As noted in that issue, if a zip filesystem created on top of a jar containing a "./" entry is "walked" using the `Files.walkFileTree`, it leads to a infinite never ending iteration (which ultimately fails with Java heap space OOM).
> 
> Alan notes in that issue that:
> 
>> This is more likely an issue with the zipfs DirectoryStream implementation. A DirectoryStream is specified to not include elements that for the special links to the current or parent directory. It should be rare. 
> 
> This indeed turned out to be an issue in the `jdk.nio.zipfs.ZipDirectoryStream#iterator()` implementation where it calls the `jdk.nio.zipfs.ZipFileSystem#iteratorOf(...)` implementation.  The implementation, unlike what the javadoc of `java.nio.file.DirectoryStream` states, was including the "." and ".." paths in its returned iterator:
> 
>> The elements returned by the iterator are in no specific order. Some file
>  systems maintain special links to the directory itself and the directory's
>   parent directory. Entries representing these links are not returned by the
>   iterator.
> 
> 
> The proposed fix in this patch checks the paths for "." and "..", similar to what the `sun.nio.fs.UnixDirectoryStream` does in its `isSelfOrParent` and skips those paths from being added into the returned iterator. The `jdk.nio.zipfs.ZipFileSystem#iteratorOf(...)` (where this change has been done) is currently only used by `jdk.nio.zipfs.ZipDirectoryStream#iterator()` and has package-private visibility, so this change shouldn't impact any other usage/expectations.
> 
> A new jtreg test has been added to reproduce this issue and verify the fix. Local testing of the `test/jdk/jdk/nio/` (including this new test) went fine without any issues after this change. I will be triggering a `tier1` test locally in a while.

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

  implement review suggestion - move isSelfOrParent to ZipPath class

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4604/files
  - new: https://git.openjdk.java.net/jdk/pull/4604/files/344da6cb..3971ad6f

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

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

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

From rriggs at openjdk.java.net  Thu Jul  1 14:43:07 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 1 Jul 2021 14:43:07 GMT
Subject: [jdk17] RFR: JDK-8225667: Clarify the behavior of System::gc
 w.r.t. reference processing [v2]
In-Reply-To: <ZpgnqEdpEAzq3oLh7z8Kcb0qF0geRqpY4tFlLId1OpM=.b50e1c35-1906-4b92-ac97-e35c6b5f417e@github.com>
References: <P5HIv6qhUDaRF1LiEYjyLdvKPUK9CNH81gsb8Ja4UEw=.2a1eab1a-4b88-4d41-85b4-8ffedb39cdc7@github.com>
 <ZpgnqEdpEAzq3oLh7z8Kcb0qF0geRqpY4tFlLId1OpM=.b50e1c35-1906-4b92-ac97-e35c6b5f417e@github.com>
Message-ID: <iSRZTf2cqAOtRQSZraZK4ayhkfQXo033GifC4cM2lZI=.01f367af-e5f7-405f-ae90-a2acd598d757@github.com>

On Wed, 30 Jun 2021 22:52:36 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> This spec clarification is a follow-up to [JDK-8224760](https://bugs.openjdk.java.net/browse/JDK-8224760?focusedCommentId=14268320&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14268320) w.r.t. reference processing.  Since there is no guarantee for any memory reclamation by the invocation of `System::gc`, the spec should also clarify that there is no guarantee in determining the change of reachability of any objects or any particular number of `Reference` objects be enqueued and cleared.
>> 
>> CSR:
>>    https://bugs.openjdk.java.net/browse/JDK-8269690
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Kim's suggestion on the wording

Marked as reviewed by rriggs (Reviewer).

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

PR: https://git.openjdk.java.net/jdk17/pull/183

From rriggs at openjdk.java.net  Thu Jul  1 15:06:06 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 1 Jul 2021 15:06:06 GMT
Subject: RFR: 8188044: We need Math.unsignedMultiplyHigh
In-Reply-To: <23ldlDveuxh3c09WTFw5rQTJTAGd-KQHdo5K_KTtFSU=.39e4ccfb-e56e-4473-bee8-3c272cc94771@github.com>
References: <23ldlDveuxh3c09WTFw5rQTJTAGd-KQHdo5K_KTtFSU=.39e4ccfb-e56e-4473-bee8-3c272cc94771@github.com>
Message-ID: <sGSc6ThPRYIaVtlpxsiceQ9NHatCyzmeuGFN004Gegc=.9e410298-4886-4b38-8caf-071814238adc@github.com>

On Wed, 30 Jun 2021 23:13:06 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Please consider this proposal to add a method `unsignedMultiplyHigh(long,long)` to each of `java.lang.Math` and `java.lang.StrictMath`.

Looks good.

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

Marked as reviewed by rriggs (Reviewer).

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

From lancea at openjdk.java.net  Thu Jul  1 15:14:02 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Thu, 1 Jul 2021 15:14:02 GMT
Subject: [jdk17] RFR: 8269543: The warning for System::setSecurityManager
 should only appear once for each caller [v2]
In-Reply-To: <vPw2xfwQgS1duPSA8DJi8DmTahaKp62qxqtnzZxOos0=.70c45b23-da4c-40fc-8e37-5e65d9570f69@github.com>
References: <2wPGdH3DHTe2qZGNGWufKdvKRpw8UnjeQYYeX8HgKrg=.8589766e-28ee-44f5-80a2-8a1e021f1d3e@github.com>
 <vPw2xfwQgS1duPSA8DJi8DmTahaKp62qxqtnzZxOos0=.70c45b23-da4c-40fc-8e37-5e65d9570f69@github.com>
Message-ID: <wGMbK84Iew6XmDZORfSDYCKR6KPuli-wZHt6bQ_Gwsk=.c2e0792d-ab4a-4792-948a-b443dba61d3a@github.com>

On Wed, 30 Jun 2021 15:45:25 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Add a cache to record which sources have called `System::setSecurityManager` and only print out warning lines once for each.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update cache key from String to Class

Marked as reviewed by lancea (Reviewer).

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

PR: https://git.openjdk.java.net/jdk17/pull/166

From mcimadamore at openjdk.java.net  Thu Jul  1 16:32:04 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 1 Jul 2021 16:32:04 GMT
Subject: [jdk17] Integrated: 8268566: java/foreign/TestResourceScope.java
 timed out
In-Reply-To: <dL7x5rTs1hNLHbyNCMXrDJ5M1mh-7AVwKFlEdKLOXS4=.4da6549e-9438-4c74-8600-4af026dde75d@github.com>
References: <dL7x5rTs1hNLHbyNCMXrDJ5M1mh-7AVwKFlEdKLOXS4=.4da6549e-9438-4c74-8600-4af026dde75d@github.com>
Message-ID: <_UJkcmDZ8Ydo_MTePWiuDNlWEdX2GDzR7a7v-dlb2XE=.bd28640e-0481-4508-9c5e-85a0fad26d3c@github.com>

On Mon, 14 Jun 2021 15:42:03 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This patch contains another minor tweak to TestResourceScope as we have seen this test timing out at least once (on arm64).
> 
> I realized that some of the logic recently introduced in the test could lead to the test waiting forever: for instance, if all threads are executed right away before the main thread gets a chance to do anything, we'd be in a state where the lock count is zero, and no other thread will update it. I've removed the while loop - as that's not essential to make sure that the test works (what we want is to trigger a close operation that is concurrent with respect some acquire/release).
> 
> I've also lowered the number of threads - which was using 10K - that was good for stress testing, but it's not a good number in more realistic conditions.

This pull request has now been integrated.

Changeset: e3773977
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.java.net/jdk17/commit/e3773977cfdcd691a5664a4715328f8552e319e7
Stats:     5 lines in 1 file changed: 0 ins; 4 del; 1 mod

8268566: java/foreign/TestResourceScope.java timed out

Reviewed-by: jvernee

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

PR: https://git.openjdk.java.net/jdk17/pull/45

From bpb at openjdk.java.net  Thu Jul  1 18:08:22 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 1 Jul 2021 18:08:22 GMT
Subject: RFR: 8188044: We need Math.unsignedMultiplyHigh [v2]
In-Reply-To: <23ldlDveuxh3c09WTFw5rQTJTAGd-KQHdo5K_KTtFSU=.39e4ccfb-e56e-4473-bee8-3c272cc94771@github.com>
References: <23ldlDveuxh3c09WTFw5rQTJTAGd-KQHdo5K_KTtFSU=.39e4ccfb-e56e-4473-bee8-3c272cc94771@github.com>
Message-ID: <IRMokdcxI2T6fdKxFf3iIPH5LQXz3EXA7rZ9BUS0piI=.4290d61b-73e5-485c-a6b0-447fbf8ff515@github.com>

> Please consider this proposal to add a method `unsignedMultiplyHigh(long,long)` to each of `java.lang.Math` and `java.lang.StrictMath`.

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

  8188044: Add @see links between multiplyHigh() and unsignedMultiplyHigh().

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4644/files
  - new: https://git.openjdk.java.net/jdk/pull/4644/files/df884569..0a8fec63

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

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

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

From mcimadamore at openjdk.java.net  Thu Jul  1 21:19:15 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 1 Jul 2021 21:19:15 GMT
Subject: [jdk17] RFR: 8269281: java/foreign/TestUpcall.java times out
Message-ID: <WAGKCk0ZtG6QlEKrfcB4uv4Vd7NBenJkCOBqxcoB6Y8=.dc970d5e-a200-42ee-98fa-b97bc4823e38@github.com>

The previous fix to this test which used removed the `VerifyDependency` flag worked well, but we're still observing rare timeouts. Looking at the test reports, it seems likely that slightly increasing the timeout would do the trick.

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

Commit messages:
 - Increase timeout for TestUpcall

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

PR: https://git.openjdk.java.net/jdk17/pull/198

From github.com+1701815+mkarg at openjdk.java.net  Thu Jul  1 21:59:33 2021
From: github.com+1701815+mkarg at openjdk.java.net (Markus KARG)
Date: Thu, 1 Jul 2021 21:59:33 GMT
Subject: RFR: 8265891: (ch) InputStream returned by
 Channels.newInputStream should override transferTo [v2]
In-Reply-To: <XlU5gCBUEa4qTTz8yhMeElh95FuiPcFYQ_nj_WYvbLE=.6e9fc6a4-f3b1-4faf-91f0-d8b06f875780@github.com>
References: <XlU5gCBUEa4qTTz8yhMeElh95FuiPcFYQ_nj_WYvbLE=.6e9fc6a4-f3b1-4faf-91f0-d8b06f875780@github.com>
Message-ID: <cZlX2_-SUyC7Ynxi-JQF2FM6qay9v_dbaD5W4Z-0a9Y=.d0bc0712-1645-4f38-967d-3bc2691f1c36@github.com>

> This PR-*draft* is **work in progress** and an invitation to discuss a possible solution for issue [JDK-8265891](https://bugs.openjdk.java.net/browse/JDK-8265891). It is *not yet* intended for a final review.
> 
> As proposed in JDK-8265891, this PR provides an implementation for `Channels.newInputStream().transferTo()` which provide superior performance compared to the current implementation. The changes are:
> * Prevents transfers through the JVM heap as much as possibly by offloading to deeper levels via NIO, hence allowing the operating system to optimize the transfer.
> * Using more JRE heap in the fallback case when no NIO is possible (still only KiBs, hence mostl ynegligible even on SBCs) to better perform on modern hardware / fast I/O devides.
> 
> Using JMH I have benchmarked both, the original implementation and this implementation, and (depending on the used hardware and use case) performance change was approx. doubled performance. So this PoC proofs that it makes sense to finalize this work and turn it into an actual OpenJDK contribution. 
> 
> I encourage everybody to discuss this draft:
> * Are there valid arguments for *not* doing this change?
> * Is there a *better* way to improve performance of `Channels.newInputStream().transferTo()`?
> * How to go on from here: What is missing to get this ready for an actual review?

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

  Draft: Renaming i and separating code into several methods
  
  Signed-off-by: Markus Karg <markus at headcrashing.eu>

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4263/files
  - new: https://git.openjdk.java.net/jdk/pull/4263/files/ed49098a..7d18ca62

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

  Stats: 108 lines in 1 file changed: 57 ins; 39 del; 12 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4263.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4263/head:pull/4263

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

From emcmanus at openjdk.java.net  Thu Jul  1 22:05:01 2021
From: emcmanus at openjdk.java.net (Eamonn McManus)
Date: Thu, 1 Jul 2021 22:05:01 GMT
Subject: RFR: 8188044: We need Math.unsignedMultiplyHigh [v2]
In-Reply-To: <IRMokdcxI2T6fdKxFf3iIPH5LQXz3EXA7rZ9BUS0piI=.4290d61b-73e5-485c-a6b0-447fbf8ff515@github.com>
References: <23ldlDveuxh3c09WTFw5rQTJTAGd-KQHdo5K_KTtFSU=.39e4ccfb-e56e-4473-bee8-3c272cc94771@github.com>
 <IRMokdcxI2T6fdKxFf3iIPH5LQXz3EXA7rZ9BUS0piI=.4290d61b-73e5-485c-a6b0-447fbf8ff515@github.com>
Message-ID: <-groEHIHl0a6nRLCX_um3NyLgBcTshMMSqPlqK8hX-4=.6b612f95-a170-4172-82f6-418494071b95@github.com>

On Thu, 1 Jul 2021 18:08:22 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Please consider this proposal to add a method `unsignedMultiplyHigh(long,long)` to each of `java.lang.Math` and `java.lang.StrictMath`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8188044: Add @see links between multiplyHigh() and unsignedMultiplyHigh().

`Long` already has some unsigned arithmetic methods: `divideUnsigned`, `compareUnsigned`, `toUnsignedString`. `Math` doesn't. Would it make more sense to add the new method to `Long`? That would also avoid the quirk of having distinct methods in `Math` and `StringMath` when the numbers in involved are integers.

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

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

From bpb at openjdk.java.net  Thu Jul  1 22:10:58 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 1 Jul 2021 22:10:58 GMT
Subject: RFR: 8188044: We need Math.unsignedMultiplyHigh [v2]
In-Reply-To: <IRMokdcxI2T6fdKxFf3iIPH5LQXz3EXA7rZ9BUS0piI=.4290d61b-73e5-485c-a6b0-447fbf8ff515@github.com>
References: <23ldlDveuxh3c09WTFw5rQTJTAGd-KQHdo5K_KTtFSU=.39e4ccfb-e56e-4473-bee8-3c272cc94771@github.com>
 <IRMokdcxI2T6fdKxFf3iIPH5LQXz3EXA7rZ9BUS0piI=.4290d61b-73e5-485c-a6b0-447fbf8ff515@github.com>
Message-ID: <reW9KLxR46ElDbdXGy-wPUGpkrQ8IFOBJnhhJWluBGA=.432979c1-625a-4503-a725-e983c5dc6de5@github.com>

On Thu, 1 Jul 2021 18:08:22 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Please consider this proposal to add a method `unsignedMultiplyHigh(long,long)` to each of `java.lang.Math` and `java.lang.StrictMath`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8188044: Add @see links between multiplyHigh() and unsignedMultiplyHigh().

Yes, I am aware of those methods on `Long`. We do however already have `Math.multiplyHigh()` so adding the new method to `Math` would be consistent.

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

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

From emcmanus at openjdk.java.net  Thu Jul  1 22:30:01 2021
From: emcmanus at openjdk.java.net (Eamonn McManus)
Date: Thu, 1 Jul 2021 22:30:01 GMT
Subject: RFR: 8188044: We need Math.unsignedMultiplyHigh [v2]
In-Reply-To: <IRMokdcxI2T6fdKxFf3iIPH5LQXz3EXA7rZ9BUS0piI=.4290d61b-73e5-485c-a6b0-447fbf8ff515@github.com>
References: <23ldlDveuxh3c09WTFw5rQTJTAGd-KQHdo5K_KTtFSU=.39e4ccfb-e56e-4473-bee8-3c272cc94771@github.com>
 <IRMokdcxI2T6fdKxFf3iIPH5LQXz3EXA7rZ9BUS0piI=.4290d61b-73e5-485c-a6b0-447fbf8ff515@github.com>
Message-ID: <H0sIAbz6AZ6x2bqyCmw52baWaGWfSJyq1CA80fIqcJA=.bbd8f08e-965e-4d8d-b7b3-6c0d5094076e@github.com>

On Thu, 1 Jul 2021 18:08:22 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Please consider this proposal to add a method `unsignedMultiplyHigh(long,long)` to each of `java.lang.Math` and `java.lang.StrictMath`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8188044: Add @see links between multiplyHigh() and unsignedMultiplyHigh().

Oh right. Then obviously this is the right place for the new method. Sorry for the noise.

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

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

From dholmes at openjdk.java.net  Thu Jul  1 22:56:58 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 1 Jul 2021 22:56:58 GMT
Subject: [jdk17] RFR: 8269281: java/foreign/TestUpcall.java times out
In-Reply-To: <WAGKCk0ZtG6QlEKrfcB4uv4Vd7NBenJkCOBqxcoB6Y8=.dc970d5e-a200-42ee-98fa-b97bc4823e38@github.com>
References: <WAGKCk0ZtG6QlEKrfcB4uv4Vd7NBenJkCOBqxcoB6Y8=.dc970d5e-a200-42ee-98fa-b97bc4823e38@github.com>
Message-ID: <6HaGGz87_f41wPluyCDwNSktUI5maSicjf914HPuoIo=.55811822-bd50-4b35-9146-6327eb59ac15@github.com>

On Thu, 1 Jul 2021 21:11:44 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> The previous fix to this test which used removed the `VerifyDependency` flag worked well, but we're still observing rare timeouts. Looking at the test reports, it seems likely that slightly increasing the timeout would do the trick.

Hi Maurizio,

Sorry but I don't see why you think increasing the timeout will help here. From what I can see a normal successful run takes less than a minute, or just over. I see a couple of outliers at 4 and 6 minutes, then you have a timeout after 10 minutes - that is 10x slower than expected. I think something unexpected is happening here to cause it to take so long.

David

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

PR: https://git.openjdk.java.net/jdk17/pull/198

From bpb at openjdk.java.net  Thu Jul  1 23:55:10 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 1 Jul 2021 23:55:10 GMT
Subject: RFR: 8188046: java.lang.Math.mutliplyHigh does not run in
 constant time
In-Reply-To: <-XW-J7GWnt6RQmbuvQ1bApn7qC2hNpW4bspCOCG8KRw=.4a315407-7617-47a7-993f-fc0c8e906a0f@github.com>
References: <-XW-J7GWnt6RQmbuvQ1bApn7qC2hNpW4bspCOCG8KRw=.4a315407-7617-47a7-993f-fc0c8e906a0f@github.com>
Message-ID: <GQY1vDB4MYSeRTd_nAtVFu6LJdliBtjV_SFutONgEds=.dd6f8cd8-7d55-4f5f-b5ab-772282fdbc3f@github.com>

On Thu, 1 Jul 2021 23:46:00 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Please consider this proposal to remove the fast path in `java.lang.Math.multiplyHigh()` the small performance improvement of which is eclipsed by the branch penalty.

Please refer to the issue for a benchmark and sample output from it.

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

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

From bpb at openjdk.java.net  Thu Jul  1 23:55:10 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 1 Jul 2021 23:55:10 GMT
Subject: RFR: 8188046: java.lang.Math.mutliplyHigh does not run in constant
 time
Message-ID: <-XW-J7GWnt6RQmbuvQ1bApn7qC2hNpW4bspCOCG8KRw=.4a315407-7617-47a7-993f-fc0c8e906a0f@github.com>

Please consider this proposal to remove the fast path in `java.lang.Math.multiplyHigh()` the small performance improvement of which is eclipsed by the branch penalty.

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

Commit messages:
 - 8188046: java.lang.Math.mutliplyHigh does not run in constant time

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

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

From jwilhelm at openjdk.java.net  Fri Jul  2 00:25:29 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Fri, 2 Jul 2021 00:25:29 GMT
Subject: RFR: Merge jdk17
Message-ID: <TUjEwZq1CJKqY5Om5LvjGRrePb-6rZkJDxuLEA3bZB8=.50845890-a4f8-49a6-9f48-bc2897ffc752@github.com>

Forwardport JDK 17 -> JDK 18

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

Commit messages:
 - Merge
 - 8269745: [JVMCI] restore original qualified exports to Graal
 - 8268566: java/foreign/TestResourceScope.java timed out
 - 8260684: vmTestbase/gc/gctests/PhantomReference/phantom002/TestDescription.java timed out
 - 8269580: assert(is_valid()) failed: invalid register (-1)
 - 8269704: Typo in j.t.Normalizer.normalize()
 - 8269354: javac crashes when processing parenthesized pattern in instanceof
 - 8269285: Crash/miscompile in CallGenerator::for_method_handle_inline after JDK-8191998
 - 8269088: C2 fails with assert(!n->is_Store() && !n->is_LoadStore()) failed: no node with a side effect
 - 8269230: C2: main loop in micro benchmark never executed
 - ... and 3 more: https://git.openjdk.java.net/jdk/compare/de61328d...5515a992

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

Changes: https://git.openjdk.java.net/jdk/pull/4661/files
  Stats: 996 lines in 26 files changed: 843 ins; 64 del; 89 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4661.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4661/head:pull/4661

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

From jwilhelm at openjdk.java.net  Fri Jul  2 01:12:34 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Fri, 2 Jul 2021 01:12:34 GMT
Subject: RFR: Merge jdk17 [v2]
In-Reply-To: <TUjEwZq1CJKqY5Om5LvjGRrePb-6rZkJDxuLEA3bZB8=.50845890-a4f8-49a6-9f48-bc2897ffc752@github.com>
References: <TUjEwZq1CJKqY5Om5LvjGRrePb-6rZkJDxuLEA3bZB8=.50845890-a4f8-49a6-9f48-bc2897ffc752@github.com>
Message-ID: <uKN02bBiFcW-sCGWUPDQ48YZM6qeSPLnGp-Rvlg6rCE=.55740632-bafe-4584-a4ec-f54d3cd4dfb4@github.com>

> Forwardport JDK 17 -> JDK 18

Jesper Wilhelmsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 133 commits:

 - Merge
 - 8225559: assertion error at TransTypes.visitApply
   
   Reviewed-by: sadayapalam, jlahoda
 - 8268960: com/sun/net/httpserver/Headers.java: Ensure mutators normalize keys and disallow null for keys and values
   
   Reviewed-by: chegar, dfuchs, michaelm
 - 8267307: Introduce new client property for XAWT: xawt.mwm_decor_title
   
   Reviewed-by: azvegint, serb
 - 8133873: Simplify {Register,Unregister}NMethodOopClosure
   
   Reviewed-by: tschatzl, kbarrett
 - 8268298: jdk/jfr/api/consumer/log/TestVerbosity.java fails: unexpected log message
   
   Reviewed-by: egahlin
 - 8266746: C1: Replace UnsafeGetRaw with UnsafeGet when setting up OSR entry block
   
   Replace UnsafeGetRaw with UnsafeGetObject when setting up OSR entry block, and rename Unsafe{Get,Put}Object to Unsafe{Get,Put}
   
   Reviewed-by: thartmann, dlong, mdoerr
 - 8268870: Remove dead code in metaspaceShared
   
   Reviewed-by: tschatzl
 - Merge
 - 8268637: Update --release 17 symbol information for JDK 17 build 28
   
   Reviewed-by: iris
 - ... and 123 more: https://git.openjdk.java.net/jdk/compare/a4d2a9a7...5515a992

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

Changes: https://git.openjdk.java.net/jdk/pull/4661/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4661&range=01
  Stats: 32483 lines in 677 files changed: 18918 ins; 11377 del; 2188 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4661.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4661/head:pull/4661

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

From jwilhelm at openjdk.java.net  Fri Jul  2 01:12:36 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Fri, 2 Jul 2021 01:12:36 GMT
Subject: Integrated: Merge jdk17
In-Reply-To: <TUjEwZq1CJKqY5Om5LvjGRrePb-6rZkJDxuLEA3bZB8=.50845890-a4f8-49a6-9f48-bc2897ffc752@github.com>
References: <TUjEwZq1CJKqY5Om5LvjGRrePb-6rZkJDxuLEA3bZB8=.50845890-a4f8-49a6-9f48-bc2897ffc752@github.com>
Message-ID: <9541FIty7ivYR6t4zu5TZr5R_tIsqCHUaP4Wmo7q1nM=.6563c5be-64bb-40aa-a0e4-4facdfb85b2c@github.com>

On Fri, 2 Jul 2021 00:18:55 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 17 -> JDK 18

This pull request has now been integrated.

Changeset: b0e18679
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b0e186792e816be30347dacfd88b8e55476584e7
Stats:     996 lines in 26 files changed: 843 ins; 64 del; 89 mod

Merge

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

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

From github.com+1701815+mkarg at openjdk.java.net  Fri Jul  2 06:20:30 2021
From: github.com+1701815+mkarg at openjdk.java.net (Markus KARG)
Date: Fri, 2 Jul 2021 06:20:30 GMT
Subject: RFR: 8265891: (ch) InputStream returned by
 Channels.newInputStream should override transferTo [v2]
In-Reply-To: <cZlX2_-SUyC7Ynxi-JQF2FM6qay9v_dbaD5W4Z-0a9Y=.d0bc0712-1645-4f38-967d-3bc2691f1c36@github.com>
References: <XlU5gCBUEa4qTTz8yhMeElh95FuiPcFYQ_nj_WYvbLE=.6e9fc6a4-f3b1-4faf-91f0-d8b06f875780@github.com>
 <cZlX2_-SUyC7Ynxi-JQF2FM6qay9v_dbaD5W4Z-0a9Y=.d0bc0712-1645-4f38-967d-3bc2691f1c36@github.com>
Message-ID: <hawEb_Wv5KQa7KFHa4isTjiedxPp1g4J1PhFkEGbJSA=.2cfe4407-b8f4-4ece-b41b-ee31de7c87fa@github.com>

On Thu, 1 Jul 2021 21:59:33 GMT, Markus KARG <github.com+1701815+mkarg at openjdk.org> wrote:

>> This PR-*draft* is **work in progress** and an invitation to discuss a possible solution for issue [JDK-8265891](https://bugs.openjdk.java.net/browse/JDK-8265891). It is *not yet* intended for a final review.
>> 
>> As proposed in JDK-8265891, this PR provides an implementation for `Channels.newInputStream().transferTo()` which provide superior performance compared to the current implementation. The changes are:
>> * Prevents transfers through the JVM heap as much as possibly by offloading to deeper levels via NIO, hence allowing the operating system to optimize the transfer.
>> * Using more JRE heap in the fallback case when no NIO is possible (still only KiBs, hence mostl ynegligible even on SBCs) to better perform on modern hardware / fast I/O devides.
>> 
>> Using JMH I have benchmarked both, the original implementation and this implementation, and (depending on the used hardware and use case) performance change was approx. doubled performance. So this PoC proofs that it makes sense to finalize this work and turn it into an actual OpenJDK contribution. 
>> 
>> I encourage everybody to discuss this draft:
>> * Are there valid arguments for *not* doing this change?
>> * Is there a *better* way to improve performance of `Channels.newInputStream().transferTo()`?
>> * How to go on from here: What is missing to get this ready for an actual review?
>
> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Draft: Renaming i and separating code into several methods
>   
>   Signed-off-by: Markus Karg <markus at headcrashing.eu>

I have renamed `i` (and other ambiguous variables) and separated the implementation of `transferTo` into multiple methods. I will look into the test examples next to learn what I can reuse when writing tests for all those implementations. Thank you for all the kind input and the good ideas.

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

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

From github.com+1701815+mkarg at openjdk.java.net  Fri Jul  2 06:20:29 2021
From: github.com+1701815+mkarg at openjdk.java.net (Markus KARG)
Date: Fri, 2 Jul 2021 06:20:29 GMT
Subject: RFR: 8265891: (ch) InputStream returned by
 Channels.newInputStream should override transferTo [v3]
In-Reply-To: <XlU5gCBUEa4qTTz8yhMeElh95FuiPcFYQ_nj_WYvbLE=.6e9fc6a4-f3b1-4faf-91f0-d8b06f875780@github.com>
References: <XlU5gCBUEa4qTTz8yhMeElh95FuiPcFYQ_nj_WYvbLE=.6e9fc6a4-f3b1-4faf-91f0-d8b06f875780@github.com>
Message-ID: <aS5i72i7KLnTndIFIA_94OUjEgyuwXiHDHu1H898QtE=.0fcdd01c-2219-4318-86d7-8826941b6f41@github.com>

> This PR-*draft* is **work in progress** and an invitation to discuss a possible solution for issue [JDK-8265891](https://bugs.openjdk.java.net/browse/JDK-8265891). It is *not yet* intended for a final review.
> 
> As proposed in JDK-8265891, this PR provides an implementation for `Channels.newInputStream().transferTo()` which provide superior performance compared to the current implementation. The changes are:
> * Prevents transfers through the JVM heap as much as possibly by offloading to deeper levels via NIO, hence allowing the operating system to optimize the transfer.
> * Using more JRE heap in the fallback case when no NIO is possible (still only KiBs, hence mostl ynegligible even on SBCs) to better perform on modern hardware / fast I/O devides.
> 
> Using JMH I have benchmarked both, the original implementation and this implementation, and (depending on the used hardware and use case) performance change was approx. doubled performance. So this PoC proofs that it makes sense to finalize this work and turn it into an actual OpenJDK contribution. 
> 
> I encourage everybody to discuss this draft:
> * Are there valid arguments for *not* doing this change?
> * Is there a *better* way to improve performance of `Channels.newInputStream().transferTo()`?
> * How to go on from here: What is missing to get this ready for an actual review?

Markus KARG 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:

  Draft: Renaming i and separating code into several methods
  
  Signed-off-by: Markus Karg <markus at headcrashing.eu>

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4263/files
  - new: https://git.openjdk.java.net/jdk/pull/4263/files/7d18ca62..47ee00a2

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

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

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

From plevart at openjdk.java.net  Fri Jul  2 08:47:03 2021
From: plevart at openjdk.java.net (Peter Levart)
Date: Fri, 2 Jul 2021 08:47:03 GMT
Subject: [jdk17] RFR: JDK-8225667: Clarify the behavior of System::gc
 w.r.t. reference processing [v2]
In-Reply-To: <ZpgnqEdpEAzq3oLh7z8Kcb0qF0geRqpY4tFlLId1OpM=.b50e1c35-1906-4b92-ac97-e35c6b5f417e@github.com>
References: <P5HIv6qhUDaRF1LiEYjyLdvKPUK9CNH81gsb8Ja4UEw=.2a1eab1a-4b88-4d41-85b4-8ffedb39cdc7@github.com>
 <ZpgnqEdpEAzq3oLh7z8Kcb0qF0geRqpY4tFlLId1OpM=.b50e1c35-1906-4b92-ac97-e35c6b5f417e@github.com>
Message-ID: <KbEQAjBnP0qaE1sUdQ9vvbMY-wJi8iIm9q6gkrGiXkM=.eafef21d-0559-4987-b9d0-b4dcd252c32a@github.com>

On Wed, 30 Jun 2021 22:52:36 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> This spec clarification is a follow-up to [JDK-8224760](https://bugs.openjdk.java.net/browse/JDK-8224760?focusedCommentId=14268320&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14268320) w.r.t. reference processing.  Since there is no guarantee for any memory reclamation by the invocation of `System::gc`, the spec should also clarify that there is no guarantee in determining the change of reachability of any objects or any particular number of `Reference` objects be enqueued and cleared.
>> 
>> CSR:
>>    https://bugs.openjdk.java.net/browse/JDK-8269690
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Kim's suggestion on the wording

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

> 660:      * or that any particular number of {@link java.lang.ref.Reference Reference}
> 661:      * objects will be cleared and enqueued.
> 662:      * <p>

Hi Mandy,
I'm not a native speaker so this might be wrong thinking: The word "determine" feels to me like saying "cause". But running System.gc never actually causes the change of reachability (well it does, when the Reference object is cleared, the reachability of referent changes from Weakly/Softly/Phantom-reachable to unreachable, but I don't think you had that in mind. Or did you?). What would you say about using word "detect" instead? Please others, do say if my thinking is wrong...

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

PR: https://git.openjdk.java.net/jdk17/pull/183

From plevart at openjdk.java.net  Fri Jul  2 08:55:02 2021
From: plevart at openjdk.java.net (Peter Levart)
Date: Fri, 2 Jul 2021 08:55:02 GMT
Subject: [jdk17] RFR: JDK-8225667: Clarify the behavior of System::gc
 w.r.t. reference processing [v2]
In-Reply-To: <KbEQAjBnP0qaE1sUdQ9vvbMY-wJi8iIm9q6gkrGiXkM=.eafef21d-0559-4987-b9d0-b4dcd252c32a@github.com>
References: <P5HIv6qhUDaRF1LiEYjyLdvKPUK9CNH81gsb8Ja4UEw=.2a1eab1a-4b88-4d41-85b4-8ffedb39cdc7@github.com>
 <ZpgnqEdpEAzq3oLh7z8Kcb0qF0geRqpY4tFlLId1OpM=.b50e1c35-1906-4b92-ac97-e35c6b5f417e@github.com>
 <KbEQAjBnP0qaE1sUdQ9vvbMY-wJi8iIm9q6gkrGiXkM=.eafef21d-0559-4987-b9d0-b4dcd252c32a@github.com>
Message-ID: <L7M7no8PrSvC4dYWryuET3udnSRQRYSQ5t35v-wVJAA=.57602d75-5ac9-447d-8da8-fc74d0ad6028@github.com>

On Fri, 2 Jul 2021 08:40:42 GMT, Peter Levart <plevart at openjdk.org> wrote:

>> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Kim's suggestion on the wording
>
> src/java.base/share/classes/java/lang/Runtime.java line 662:
> 
>> 660:      * or that any particular number of {@link java.lang.ref.Reference Reference}
>> 661:      * objects will be cleared and enqueued.
>> 662:      * <p>
> 
> Hi Mandy,
> I'm not a native speaker so this might be wrong thinking: The word "determine" feels to me like saying "cause". But running System.gc never actually causes the change of reachability (well it does, when the Reference object is cleared, the reachability of referent changes from Weakly/Softly/Phantom-reachable to unreachable, but I don't think you had that in mind. Or did you?). What would you say about using word "detect" instead? Please others, do say if my thinking is wrong...

Well, "determine" seems to have both meanings:
https://www.google.com/search?q=determine
So by the 2nd meaning, it is good.

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

PR: https://git.openjdk.java.net/jdk17/pull/183

From github.com+10835776+stsypanov at openjdk.java.net  Fri Jul  2 09:02:34 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Fri, 2 Jul 2021 09:02:34 GMT
Subject: RFR: 8266972: Use String.concat() in j.l.Class where
 invokedynamic-based String concatenation is not available [v4]
In-Reply-To: <mmH_gQ8uVQa6VMhBzCMHjdgL7wpmwll5DKxnfuS0U9A=.82977d2b-d934-471e-94b6-dd5ef90c037c@github.com>
References: <mmH_gQ8uVQa6VMhBzCMHjdgL7wpmwll5DKxnfuS0U9A=.82977d2b-d934-471e-94b6-dd5ef90c037c@github.com>
Message-ID: <lHbcUFbrLyDetTqpgzDsEi1DJ56CoBiQnCn1_1pBR1c=.3b28b0d9-feeb-4908-b90f-3a4fe1ff1f90@github.com>

> Hello, from discussion in https://github.com/openjdk/jdk/pull/3464 I've found out, that in a few of JDK core classes, e.g. in `j.l.Class` expressions like `baseName.replace('.', '/') + '/' + name` are not compiled into `invokedynamic`-based code, but into one using `StringBuilder`. This happens due to some bootstraping issues.
> 
> However the code like
> 
> private String getSimpleName0() {
>     if (isArray()) {
>         return getComponentType().getSimpleName() + "[]";
>     }
>     //...
> }
> 
> can be improved via replacement of `+` with `String.concat()` call.
> 
> I've used this benchmark to measure impact:
> 
> @State(Scope.Thread)
> @BenchmarkMode(Mode.AverageTime)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"})
> public class ClassMethodsBenchmark {
>   private final Class<? extends Object[]> arrayClass = Object[].class;
>   private Method descriptorString;
> 
>   @Setup
>   public void setUp() throws NoSuchMethodException {
>     //fore some reason compiler doesn't allow me to call Class.descriptorString() directly
>     descriptorString = Class.class.getDeclaredMethod("descriptorString");
>   }
> 
>   @Benchmark
>   public Object descriptorString() throws Exception {
>     return descriptorString.invoke(arrayClass);
>   }
> 
>   @Benchmark
>   public Object typeName() {
>     return arrayClass.getTypeName();
>   }
> }
> 
> and got those results
> 
>                                                    Mode  Cnt     Score     Error   Units
> descriptorString                                   avgt   60    91.480 ?   1.839   ns/op
> descriptorString:?gc.alloc.rate.norm               avgt   60   404.008 ?   4.033    B/op
> descriptorString:?gc.churn.G1_Eden_Space           avgt   60  2791.866 ? 181.589  MB/sec
> descriptorString:?gc.churn.G1_Eden_Space.norm      avgt   60   401.702 ?  26.047    B/op
> descriptorString:?gc.churn.G1_Survivor_Space       avgt   60     0.003 ?   0.001  MB/sec
> descriptorString:?gc.churn.G1_Survivor_Space.norm  avgt   60    ? 10??              B/op
> descriptorString:?gc.count                         avgt   60   205.000            counts
> descriptorString:?gc.time                          avgt   60   216.000                ms
> 
> patched
>                                                    Mode  Cnt     Score     Error   Units
> descriptorString                                   avgt   60    65.016 ?   3.446   ns/op
> descriptorString:?gc.alloc.rate                    avgt   60  2844.240 ? 115.719  MB/sec
> descriptorString:?gc.alloc.rate.norm               avgt   60   288.006 ?   0.001    B/op
> descriptorString:?gc.churn.G1_Eden_Space           avgt   60  2832.996 ? 206.939  MB/sec
> descriptorString:?gc.churn.G1_Eden_Space.norm      avgt   60   286.955 ?  17.853    B/op
> descriptorString:?gc.churn.G1_Survivor_Space       avgt   60     0.003 ?   0.001  MB/sec
> descriptorString:?gc.churn.G1_Survivor_Space.norm  avgt   60    ? 10??              B/op
> descriptorString:?gc.count                         avgt   60   208.000            counts
> descriptorString:?gc.time                          avgt   60   228.000                ms
> -----------------
> typeName                                           avgt   60    34.273 ?   0.480   ns/op
> typeName:?gc.alloc.rate                            avgt   60  3265.356 ?  45.113  MB/sec
> typeName:?gc.alloc.rate.norm                       avgt   60   176.004 ?   0.001    B/op
> typeName:?gc.churn.G1_Eden_Space                   avgt   60  3268.454 ? 134.458  MB/sec
> typeName:?gc.churn.G1_Eden_Space.norm              avgt   60   176.109 ?   6.595    B/op
> typeName:?gc.churn.G1_Survivor_Space               avgt   60     0.003 ?   0.001  MB/sec
> typeName:?gc.churn.G1_Survivor_Space.norm          avgt   60    ? 10??              B/op
> typeName:?gc.count                                 avgt   60   240.000            counts
> typeName:?gc.time                                  avgt   60   255.000                ms
> 
> patched
> 
> typeName                                           avgt   60    15.787 ?   0.214   ns/op
> typeName:?gc.alloc.rate                            avgt   60  2577.554 ?  32.339  MB/sec
> typeName:?gc.alloc.rate.norm                       avgt   60    64.001 ?   0.001    B/op
> typeName:?gc.churn.G1_Eden_Space                   avgt   60  2574.039 ? 147.774  MB/sec
> typeName:?gc.churn.G1_Eden_Space.norm              avgt   60    63.895 ?   3.511    B/op
> typeName:?gc.churn.G1_Survivor_Space               avgt   60     0.003 ?   0.001  MB/sec
> typeName:?gc.churn.G1_Survivor_Space.norm          avgt   60    ? 10??              B/op
> typeName:?gc.count                                 avgt   60   189.000            counts
> typeName:?gc.time                                  avgt   60   199.000                ms
> 
> I think this patch is likely to improve reflection operations related to arrays.
> 
> If one finds this patch useful, then I'll create a ticket to track this. Also it'd be nice to have a list of classes, that are compiled in the same way as `j.l.Class` (i.e. have no access to `invokedynamic`) so I could look into them for other snippets where two String are joined so `concat`-based optimization is possible.
> 
> Pre-sizing of `StringBuilder` for `Class.gdescriptorString()` and `Class.getCanonicalName0()` is one more improvement opportunity here.

?????? ??????? has updated the pull request with a new target base 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 class-concat
 - Merge branch 'master' into class-concat
 - 8266972: Use String.concat() in j.l.Class.toSting()
 - Use String.concat() where invokedynamic-based String concatenation is not available

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3627/files
  - new: https://git.openjdk.java.net/jdk/pull/3627/files/1637571e..9bb8380e

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

  Stats: 3866 lines in 132 files changed: 2377 ins; 962 del; 527 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3627.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3627/head:pull/3627

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

From plevart at openjdk.java.net  Fri Jul  2 09:04:03 2021
From: plevart at openjdk.java.net (Peter Levart)
Date: Fri, 2 Jul 2021 09:04:03 GMT
Subject: [jdk17] RFR: JDK-8225667: Clarify the behavior of System::gc
 w.r.t. reference processing [v2]
In-Reply-To: <L7M7no8PrSvC4dYWryuET3udnSRQRYSQ5t35v-wVJAA=.57602d75-5ac9-447d-8da8-fc74d0ad6028@github.com>
References: <P5HIv6qhUDaRF1LiEYjyLdvKPUK9CNH81gsb8Ja4UEw=.2a1eab1a-4b88-4d41-85b4-8ffedb39cdc7@github.com>
 <ZpgnqEdpEAzq3oLh7z8Kcb0qF0geRqpY4tFlLId1OpM=.b50e1c35-1906-4b92-ac97-e35c6b5f417e@github.com>
 <KbEQAjBnP0qaE1sUdQ9vvbMY-wJi8iIm9q6gkrGiXkM=.eafef21d-0559-4987-b9d0-b4dcd252c32a@github.com>
 <L7M7no8PrSvC4dYWryuET3udnSRQRYSQ5t35v-wVJAA=.57602d75-5ac9-447d-8da8-fc74d0ad6028@github.com>
Message-ID: <5lpGRmoZ4hfUSSbMCuLT8LmsyTPXkSeBBfmCXdiIdyA=.ea9769b2-6cb1-4705-b1eb-c0c7ffb878ef@github.com>

On Fri, 2 Jul 2021 08:52:28 GMT, Peter Levart <plevart at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/Runtime.java line 662:
>> 
>>> 660:      * or that any particular number of {@link java.lang.ref.Reference Reference}
>>> 661:      * objects will be cleared and enqueued.
>>> 662:      * <p>
>> 
>> Hi Mandy,
>> I'm not a native speaker so this might be wrong thinking: The word "determine" feels to me like saying "cause". But running System.gc never actually causes the change of reachability (well it does, when the Reference object is cleared, the reachability of referent changes from Weakly/Softly/Phantom-reachable to unreachable, but I don't think you had that in mind. Or did you?). What would you say about using word "detect" instead? Please others, do say if my thinking is wrong...
>
> Well, "determine" seems to have both meanings:
> https://www.google.com/search?q=determine
> So by the 2nd meaning, it is good.

... and considering the "Schr?dinger's cat", even the 1st interpretation is correct. You can't know whether the cat is dead or not until you "determine" it's death. This does not mean that you killed it though.

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

PR: https://git.openjdk.java.net/jdk17/pull/183

From alanb at openjdk.java.net  Fri Jul  2 09:17:03 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 2 Jul 2021 09:17:03 GMT
Subject: RFR: 8251329: (zipfs) Files.walkFileTree walks infinitely if zip
 has dir named "." inside [v2]
In-Reply-To: <YPCqIo02ztuhCJjbbrGnaF_FomLwH8ZrRu0JGj3Nc40=.05cc10af-9962-425f-8b90-86261619822e@github.com>
References: <H5Dy39I78mG6FE2N9U5vZnEhGI2zcIaxGvJ8uZBCGM0=.f3ba4976-f985-4002-87f3-da234b3c402d@github.com>
 <YPCqIo02ztuhCJjbbrGnaF_FomLwH8ZrRu0JGj3Nc40=.05cc10af-9962-425f-8b90-86261619822e@github.com>
Message-ID: <vnOKBNmlmQgX_5Q667LTvWpNrmWBBVRdz8L_TyQqC8o=.7a5ff6f9-592f-423e-ab3d-cb1a4e15c8c1@github.com>

On Thu, 1 Jul 2021 13:25:32 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this proposed fix for https://bugs.openjdk.java.net/browse/JDK-8251329?
>> 
>> As noted in that issue, if a zip filesystem created on top of a jar containing a "./" entry is "walked" using the `Files.walkFileTree`, it leads to a infinite never ending iteration (which ultimately fails with Java heap space OOM).
>> 
>> Alan notes in that issue that:
>> 
>>> This is more likely an issue with the zipfs DirectoryStream implementation. A DirectoryStream is specified to not include elements that for the special links to the current or parent directory. It should be rare. 
>> 
>> This indeed turned out to be an issue in the `jdk.nio.zipfs.ZipDirectoryStream#iterator()` implementation where it calls the `jdk.nio.zipfs.ZipFileSystem#iteratorOf(...)` implementation.  The implementation, unlike what the javadoc of `java.nio.file.DirectoryStream` states, was including the "." and ".." paths in its returned iterator:
>> 
>>> The elements returned by the iterator are in no specific order. Some file
>>  systems maintain special links to the directory itself and the directory's
>>   parent directory. Entries representing these links are not returned by the
>>   iterator.
>> 
>> 
>> The proposed fix in this patch checks the paths for "." and "..", similar to what the `sun.nio.fs.UnixDirectoryStream` does in its `isSelfOrParent` and skips those paths from being added into the returned iterator. The `jdk.nio.zipfs.ZipFileSystem#iteratorOf(...)` (where this change has been done) is currently only used by `jdk.nio.zipfs.ZipDirectoryStream#iterator()` and has package-private visibility, so this change shouldn't impact any other usage/expectations.
>> 
>> A new jtreg test has been added to reproduce this issue and verify the fix. Local testing of the `test/jdk/jdk/nio/` (including this new test) went fine without any issues after this change. I will be triggering a `tier1` test locally in a while.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   implement review suggestion - move isSelfOrParent to ZipPath class

The implementation change look good.

I skimmed the test. A helper method that maps a Set<Path> to a modifiable Set<String> would avoid the 10 usages of toString() in the setup, just a suggestion. Also I was puzzled by fs.getRootDirectories().iterator().next() and why this isn't fs.getPath("/").

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

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

From aph at openjdk.java.net  Fri Jul  2 09:44:01 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Fri, 2 Jul 2021 09:44:01 GMT
Subject: RFR: 8188044: We need Math.unsignedMultiplyHigh [v2]
In-Reply-To: <IRMokdcxI2T6fdKxFf3iIPH5LQXz3EXA7rZ9BUS0piI=.4290d61b-73e5-485c-a6b0-447fbf8ff515@github.com>
References: <23ldlDveuxh3c09WTFw5rQTJTAGd-KQHdo5K_KTtFSU=.39e4ccfb-e56e-4473-bee8-3c272cc94771@github.com>
 <IRMokdcxI2T6fdKxFf3iIPH5LQXz3EXA7rZ9BUS0piI=.4290d61b-73e5-485c-a6b0-447fbf8ff515@github.com>
Message-ID: <DBf6kvmAyHaCJOL-N9_U6I2oD_vfZiAxd6uBikVqIkk=.baa649e1-2388-4043-ac38-aa830c7957e1@github.com>

On Thu, 1 Jul 2021 18:08:22 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Please consider this proposal to add a method `unsignedMultiplyHigh(long,long)` to each of `java.lang.Math` and `java.lang.StrictMath`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8188044: Add @see links between multiplyHigh() and unsignedMultiplyHigh().

src/java.base/share/classes/java/lang/Math.java line 1211:

> 1209:         long z1 = t >>> 32;
> 1210: 
> 1211:         return x1 * y1 + z1 + (z0 >>> 32);

Suggestion:

        long result = Math.multiplyHigh(x, y);
        if (x < 0) result += y;
        if (y < 0) result += x;
        return result;

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

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

From aph at openjdk.java.net  Fri Jul  2 09:44:02 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Fri, 2 Jul 2021 09:44:02 GMT
Subject: RFR: 8188044: We need Math.unsignedMultiplyHigh [v2]
In-Reply-To: <DBf6kvmAyHaCJOL-N9_U6I2oD_vfZiAxd6uBikVqIkk=.baa649e1-2388-4043-ac38-aa830c7957e1@github.com>
References: <23ldlDveuxh3c09WTFw5rQTJTAGd-KQHdo5K_KTtFSU=.39e4ccfb-e56e-4473-bee8-3c272cc94771@github.com>
 <IRMokdcxI2T6fdKxFf3iIPH5LQXz3EXA7rZ9BUS0piI=.4290d61b-73e5-485c-a6b0-447fbf8ff515@github.com>
 <DBf6kvmAyHaCJOL-N9_U6I2oD_vfZiAxd6uBikVqIkk=.baa649e1-2388-4043-ac38-aa830c7957e1@github.com>
Message-ID: <cXN8Tz273jZPsLIa7OEy7lVYKI3Ymkzvm3U8pKjYafM=.3c5f1e53-d5b6-48a4-9108-b41cb1648e6c@github.com>

On Fri, 2 Jul 2021 09:37:47 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8188044: Add @see links between multiplyHigh() and unsignedMultiplyHigh().
>
> src/java.base/share/classes/java/lang/Math.java line 1211:
> 
>> 1209:         long z1 = t >>> 32;
>> 1210: 
>> 1211:         return x1 * y1 + z1 + (z0 >>> 32);
> 
> Suggestion:
> 
>         long result = Math.multiplyHigh(x, y);
>         if (x < 0) result += y;
>         if (y < 0) result += x;
>         return result;

This is just subtracting the 2's-complement offset. I guess the idea, longer term, is that this be an intrinsic anyway, but if you do `unsignedMultiplyHigh` this way you'll utilize the existing `multiplyHigh` intrinsic on all platforms that have it.

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

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

From jpai at openjdk.java.net  Fri Jul  2 10:25:29 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Fri, 2 Jul 2021 10:25:29 GMT
Subject: RFR: 8251329: (zipfs) Files.walkFileTree walks infinitely if zip
 has dir named "." inside [v3]
In-Reply-To: <H5Dy39I78mG6FE2N9U5vZnEhGI2zcIaxGvJ8uZBCGM0=.f3ba4976-f985-4002-87f3-da234b3c402d@github.com>
References: <H5Dy39I78mG6FE2N9U5vZnEhGI2zcIaxGvJ8uZBCGM0=.f3ba4976-f985-4002-87f3-da234b3c402d@github.com>
Message-ID: <hUKNLIxq2DB8bCyqQxl7r4ZjNWgq8zsx_MdTyFuXk-I=.520ea0e0-7715-4172-8165-2825b8b39b40@github.com>

> Can I please get a review of this proposed fix for https://bugs.openjdk.java.net/browse/JDK-8251329?
> 
> As noted in that issue, if a zip filesystem created on top of a jar containing a "./" entry is "walked" using the `Files.walkFileTree`, it leads to a infinite never ending iteration (which ultimately fails with Java heap space OOM).
> 
> Alan notes in that issue that:
> 
>> This is more likely an issue with the zipfs DirectoryStream implementation. A DirectoryStream is specified to not include elements that for the special links to the current or parent directory. It should be rare. 
> 
> This indeed turned out to be an issue in the `jdk.nio.zipfs.ZipDirectoryStream#iterator()` implementation where it calls the `jdk.nio.zipfs.ZipFileSystem#iteratorOf(...)` implementation.  The implementation, unlike what the javadoc of `java.nio.file.DirectoryStream` states, was including the "." and ".." paths in its returned iterator:
> 
>> The elements returned by the iterator are in no specific order. Some file
>  systems maintain special links to the directory itself and the directory's
>   parent directory. Entries representing these links are not returned by the
>   iterator.
> 
> 
> The proposed fix in this patch checks the paths for "." and "..", similar to what the `sun.nio.fs.UnixDirectoryStream` does in its `isSelfOrParent` and skips those paths from being added into the returned iterator. The `jdk.nio.zipfs.ZipFileSystem#iteratorOf(...)` (where this change has been done) is currently only used by `jdk.nio.zipfs.ZipDirectoryStream#iterator()` and has package-private visibility, so this change shouldn't impact any other usage/expectations.
> 
> A new jtreg test has been added to reproduce this issue and verify the fix. Local testing of the `test/jdk/jdk/nio/` (including this new test) went fine without any issues after this change. I will be triggering a `tier1` test locally in a while.

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

  implement review suggestions:
   - reduce the toString() calls by creating a helper
   - fs.getPath("/") instead of fs.getRootDirectories().iterator().next()

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4604/files
  - new: https://git.openjdk.java.net/jdk/pull/4604/files/3971ad6f..8e77d289

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

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

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

From jpai at openjdk.java.net  Fri Jul  2 10:31:00 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Fri, 2 Jul 2021 10:31:00 GMT
Subject: RFR: 8251329: (zipfs) Files.walkFileTree walks infinitely if zip
 has dir named "." inside [v3]
In-Reply-To: <hUKNLIxq2DB8bCyqQxl7r4ZjNWgq8zsx_MdTyFuXk-I=.520ea0e0-7715-4172-8165-2825b8b39b40@github.com>
References: <H5Dy39I78mG6FE2N9U5vZnEhGI2zcIaxGvJ8uZBCGM0=.f3ba4976-f985-4002-87f3-da234b3c402d@github.com>
 <hUKNLIxq2DB8bCyqQxl7r4ZjNWgq8zsx_MdTyFuXk-I=.520ea0e0-7715-4172-8165-2825b8b39b40@github.com>
Message-ID: <KVe0boBSrHhaZJ_OP5uDp5yQsFzIOMVEyqQseJFdxp8=.461f56d7-db55-4b60-ac53-fd40ac3ca79b@github.com>

On Fri, 2 Jul 2021 10:25:29 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this proposed fix for https://bugs.openjdk.java.net/browse/JDK-8251329?
>> 
>> As noted in that issue, if a zip filesystem created on top of a jar containing a "./" entry is "walked" using the `Files.walkFileTree`, it leads to a infinite never ending iteration (which ultimately fails with Java heap space OOM).
>> 
>> Alan notes in that issue that:
>> 
>>> This is more likely an issue with the zipfs DirectoryStream implementation. A DirectoryStream is specified to not include elements that for the special links to the current or parent directory. It should be rare. 
>> 
>> This indeed turned out to be an issue in the `jdk.nio.zipfs.ZipDirectoryStream#iterator()` implementation where it calls the `jdk.nio.zipfs.ZipFileSystem#iteratorOf(...)` implementation.  The implementation, unlike what the javadoc of `java.nio.file.DirectoryStream` states, was including the "." and ".." paths in its returned iterator:
>> 
>>> The elements returned by the iterator are in no specific order. Some file
>>  systems maintain special links to the directory itself and the directory's
>>   parent directory. Entries representing these links are not returned by the
>>   iterator.
>> 
>> 
>> The proposed fix in this patch checks the paths for "." and "..", similar to what the `sun.nio.fs.UnixDirectoryStream` does in its `isSelfOrParent` and skips those paths from being added into the returned iterator. The `jdk.nio.zipfs.ZipFileSystem#iteratorOf(...)` (where this change has been done) is currently only used by `jdk.nio.zipfs.ZipDirectoryStream#iterator()` and has package-private visibility, so this change shouldn't impact any other usage/expectations.
>> 
>> A new jtreg test has been added to reproduce this issue and verify the fix. Local testing of the `test/jdk/jdk/nio/` (including this new test) went fine without any issues after this change. I will be triggering a `tier1` test locally in a while.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   implement review suggestions:
>    - reduce the toString() calls by creating a helper
>    - fs.getPath("/") instead of fs.getRootDirectories().iterator().next()

>I skimmed the test. A helper method that maps a Set to a modifiable Set would avoid the 10 usages of toString() in the setup, just a suggestion.

Done. I introduced a helper in the updated version of the PR.

> Also I was puzzled by fs.getRootDirectories().iterator().next() and why this isn't fs.getPath("/").

When I started with a reproducer and then this test, I used the code that the reporter had attached in the JBS issue. That one had used "fs.getRootDirectories().iterator().next()" to show this issue. I just happened to carry that over into the test. I've updated the PR to now use fs.getPath("/") and also verified that this version of the test continues to fail without the fix proposed in this PR and passes with the changes.

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

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

From jpai at openjdk.java.net  Fri Jul  2 11:06:40 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Fri, 2 Jul 2021 11:06:40 GMT
Subject: RFR: 8251329: (zipfs) Files.walkFileTree walks infinitely if zip
 has dir named "." inside [v4]
In-Reply-To: <H5Dy39I78mG6FE2N9U5vZnEhGI2zcIaxGvJ8uZBCGM0=.f3ba4976-f985-4002-87f3-da234b3c402d@github.com>
References: <H5Dy39I78mG6FE2N9U5vZnEhGI2zcIaxGvJ8uZBCGM0=.f3ba4976-f985-4002-87f3-da234b3c402d@github.com>
Message-ID: <FWKKv49jcPmyN0fr_GVK0Sz3DceDPXRF724C45esjF8=.c86aa8c4-8fbd-4b76-90fa-a906323aae8a@github.com>

> Can I please get a review of this proposed fix for https://bugs.openjdk.java.net/browse/JDK-8251329?
> 
> As noted in that issue, if a zip filesystem created on top of a jar containing a "./" entry is "walked" using the `Files.walkFileTree`, it leads to a infinite never ending iteration (which ultimately fails with Java heap space OOM).
> 
> Alan notes in that issue that:
> 
>> This is more likely an issue with the zipfs DirectoryStream implementation. A DirectoryStream is specified to not include elements that for the special links to the current or parent directory. It should be rare. 
> 
> This indeed turned out to be an issue in the `jdk.nio.zipfs.ZipDirectoryStream#iterator()` implementation where it calls the `jdk.nio.zipfs.ZipFileSystem#iteratorOf(...)` implementation.  The implementation, unlike what the javadoc of `java.nio.file.DirectoryStream` states, was including the "." and ".." paths in its returned iterator:
> 
>> The elements returned by the iterator are in no specific order. Some file
>  systems maintain special links to the directory itself and the directory's
>   parent directory. Entries representing these links are not returned by the
>   iterator.
> 
> 
> The proposed fix in this patch checks the paths for "." and "..", similar to what the `sun.nio.fs.UnixDirectoryStream` does in its `isSelfOrParent` and skips those paths from being added into the returned iterator. The `jdk.nio.zipfs.ZipFileSystem#iteratorOf(...)` (where this change has been done) is currently only used by `jdk.nio.zipfs.ZipDirectoryStream#iterator()` and has package-private visibility, so this change shouldn't impact any other usage/expectations.
> 
> A new jtreg test has been added to reproduce this issue and verify the fix. Local testing of the `test/jdk/jdk/nio/` (including this new test) went fine without any issues after this change. I will be triggering a `tier1` test locally in a while.

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

 - Merge latest from upstream master branch to bring in fixes that might help fix the unrelated tier1 failures in Github Actions job runs
 - implement review suggestions:
    - reduce the toString() calls by creating a helper
    - fs.getPath("/") instead of fs.getRootDirectories().iterator().next()
 - implement review suggestion - move isSelfOrParent to ZipPath class
 - 8251329: (zipfs) Files.walkFileTree walks infinitely if zip has dir named "." inside

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4604/files
  - new: https://git.openjdk.java.net/jdk/pull/4604/files/8e77d289..abae52bb

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

  Stats: 10322 lines in 336 files changed: 6220 ins; 2802 del; 1300 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4604.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4604/head:pull/4604

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

From adinn at openjdk.java.net  Fri Jul  2 11:08:59 2021
From: adinn at openjdk.java.net (Andrew Dinn)
Date: Fri, 2 Jul 2021 11:08:59 GMT
Subject: RFR: 8188044: We need Math.unsignedMultiplyHigh [v2]
In-Reply-To: <cXN8Tz273jZPsLIa7OEy7lVYKI3Ymkzvm3U8pKjYafM=.3c5f1e53-d5b6-48a4-9108-b41cb1648e6c@github.com>
References: <23ldlDveuxh3c09WTFw5rQTJTAGd-KQHdo5K_KTtFSU=.39e4ccfb-e56e-4473-bee8-3c272cc94771@github.com>
 <IRMokdcxI2T6fdKxFf3iIPH5LQXz3EXA7rZ9BUS0piI=.4290d61b-73e5-485c-a6b0-447fbf8ff515@github.com>
 <DBf6kvmAyHaCJOL-N9_U6I2oD_vfZiAxd6uBikVqIkk=.baa649e1-2388-4043-ac38-aa830c7957e1@github.com>
 <cXN8Tz273jZPsLIa7OEy7lVYKI3Ymkzvm3U8pKjYafM=.3c5f1e53-d5b6-48a4-9108-b41cb1648e6c@github.com>
Message-ID: <6ACk9pK531fFvDVuVmwn-hmDus1To0Au8XUqS2evoVE=.26c6d744-3ad0-41cb-95d8-ebe25847ee9f@github.com>

On Fri, 2 Jul 2021 09:39:46 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/Math.java line 1211:
>> 
>>> 1209:         long z1 = t >>> 32;
>>> 1210: 
>>> 1211:         return x1 * y1 + z1 + (z0 >>> 32);
>> 
>> Suggestion:
>> 
>>         long result = Math.multiplyHigh(x, y);
>>         if (x < 0) result += y;
>>         if (y < 0) result += x;
>>         return result;
>
> This is just subtracting the 2's-complement offset. I guess the idea, longer term, is that this be an intrinsic anyway, but if you do `unsignedMultiplyHigh` this way you'll utilize the existing `multiplyHigh` intrinsic on all platforms that have it.

You can also do that branchlessly which might prove better

         long result = Math.multiplyHigh(x, y);
         result += (y & (x >> 63));
         result += (x & (y >> 63));
         return result;

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

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

From lancea at openjdk.java.net  Fri Jul  2 11:12:04 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Fri, 2 Jul 2021 11:12:04 GMT
Subject: RFR: 8251329: (zipfs) Files.walkFileTree walks infinitely if zip
 has dir named "." inside [v4]
In-Reply-To: <FWKKv49jcPmyN0fr_GVK0Sz3DceDPXRF724C45esjF8=.c86aa8c4-8fbd-4b76-90fa-a906323aae8a@github.com>
References: <H5Dy39I78mG6FE2N9U5vZnEhGI2zcIaxGvJ8uZBCGM0=.f3ba4976-f985-4002-87f3-da234b3c402d@github.com>
 <FWKKv49jcPmyN0fr_GVK0Sz3DceDPXRF724C45esjF8=.c86aa8c4-8fbd-4b76-90fa-a906323aae8a@github.com>
Message-ID: <FS4dG8muHl9vXW_eryRBZkDsRiquNnNOCLBlwsNVXeU=.1cecfec8-6a90-4cd4-a796-249c9b8c3110@github.com>

On Fri, 2 Jul 2021 11:06:40 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this proposed fix for https://bugs.openjdk.java.net/browse/JDK-8251329?
>> 
>> As noted in that issue, if a zip filesystem created on top of a jar containing a "./" entry is "walked" using the `Files.walkFileTree`, it leads to a infinite never ending iteration (which ultimately fails with Java heap space OOM).
>> 
>> Alan notes in that issue that:
>> 
>>> This is more likely an issue with the zipfs DirectoryStream implementation. A DirectoryStream is specified to not include elements that for the special links to the current or parent directory. It should be rare. 
>> 
>> This indeed turned out to be an issue in the `jdk.nio.zipfs.ZipDirectoryStream#iterator()` implementation where it calls the `jdk.nio.zipfs.ZipFileSystem#iteratorOf(...)` implementation.  The implementation, unlike what the javadoc of `java.nio.file.DirectoryStream` states, was including the "." and ".." paths in its returned iterator:
>> 
>>> The elements returned by the iterator are in no specific order. Some file
>>  systems maintain special links to the directory itself and the directory's
>>   parent directory. Entries representing these links are not returned by the
>>   iterator.
>> 
>> 
>> The proposed fix in this patch checks the paths for "." and "..", similar to what the `sun.nio.fs.UnixDirectoryStream` does in its `isSelfOrParent` and skips those paths from being added into the returned iterator. The `jdk.nio.zipfs.ZipFileSystem#iteratorOf(...)` (where this change has been done) is currently only used by `jdk.nio.zipfs.ZipDirectoryStream#iterator()` and has package-private visibility, so this change shouldn't impact any other usage/expectations.
>> 
>> A new jtreg test has been added to reproduce this issue and verify the fix. Local testing of the `test/jdk/jdk/nio/` (including this new test) went fine without any issues after this change. I will be triggering a `tier1` test locally in a while.
>
> Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge latest from upstream master branch to bring in fixes that might help fix the unrelated tier1 failures in Github Actions job runs
>  - implement review suggestions:
>     - reduce the toString() calls by creating a helper
>     - fs.getPath("/") instead of fs.getRootDirectories().iterator().next()
>  - implement review suggestion - move isSelfOrParent to ZipPath class
>  - 8251329: (zipfs) Files.walkFileTree walks infinitely if zip has dir named "." inside

Hi Jaikiran,

Consider:


        try (var os = Files.newOutputStream(ZIPFILE);
             ZipOutputStream zos = new ZipOutputStream(os)) {
            zos.putNextEntry(new ZipEntry("../Hello.txt"));
            zos.write("Hello World".getBytes(StandardCharsets.UTF_8));
        }


With your proposed fix, you will only return "/" when you walk the the Zip file and we should also return "/Hello.txt"

If. you resolve the path when the Inode entry is created:

           ` name(new ZipPath(null, normalize(name), true).getResolvedPath());`

That should address the issue and also allow you to access the entry.

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

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

From raffaello.giulietti at gmail.com  Fri Jul  2 11:26:16 2021
From: raffaello.giulietti at gmail.com (Raffaello Giulietti)
Date: Fri, 2 Jul 2021 13:26:16 +0200
Subject: RFR: 8188044: We need Math.unsignedMultiplyHigh [v2]
In-Reply-To: <6ACk9pK531fFvDVuVmwn-hmDus1To0Au8XUqS2evoVE=.26c6d744-3ad0-41cb-95d8-ebe25847ee9f@github.com>
References: <23ldlDveuxh3c09WTFw5rQTJTAGd-KQHdo5K_KTtFSU=.39e4ccfb-e56e-4473-bee8-3c272cc94771@github.com>
 <IRMokdcxI2T6fdKxFf3iIPH5LQXz3EXA7rZ9BUS0piI=.4290d61b-73e5-485c-a6b0-447fbf8ff515@github.com>
 <DBf6kvmAyHaCJOL-N9_U6I2oD_vfZiAxd6uBikVqIkk=.baa649e1-2388-4043-ac38-aa830c7957e1@github.com>
 <cXN8Tz273jZPsLIa7OEy7lVYKI3Ymkzvm3U8pKjYafM=.3c5f1e53-d5b6-48a4-9108-b41cb1648e6c@github.com>
 <6ACk9pK531fFvDVuVmwn-hmDus1To0Au8XUqS2evoVE=.26c6d744-3ad0-41cb-95d8-ebe25847ee9f@github.com>
Message-ID: <0a480e9f-708b-bb31-5f68-ab28560e54e1@gmail.com>

... or even as a one liner, like in the test

	return Math.multiplyHigh(x, y) + ((x >> (Long.SIZE - 1)) & y) + ((y >> 
(Long.SIZE - 1)) & x);



On 2021-07-02 13:08, Andrew Dinn wrote:
> On Fri, 2 Jul 2021 09:39:46 GMT, Andrew Haley <aph at openjdk.org> wrote:
> 
>>> src/java.base/share/classes/java/lang/Math.java line 1211:
>>>
>>>> 1209:         long z1 = t >>> 32;
>>>> 1210:
>>>> 1211:         return x1 * y1 + z1 + (z0 >>> 32);
>>>
>>> Suggestion:
>>>
>>>          long result = Math.multiplyHigh(x, y);
>>>          if (x < 0) result += y;
>>>          if (y < 0) result += x;
>>>          return result;
>>
>> This is just subtracting the 2's-complement offset. I guess the idea, longer term, is that this be an intrinsic anyway, but if you do `unsignedMultiplyHigh` this way you'll utilize the existing `multiplyHigh` intrinsic on all platforms that have it.
> 
> You can also do that branchlessly which might prove better
> 
>           long result = Math.multiplyHigh(x, y);
>           result += (y & (x >> 63));
>           result += (x & (y >> 63));
>           return result;
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/4644
> 

From alanb at openjdk.java.net  Fri Jul  2 11:53:02 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 2 Jul 2021 11:53:02 GMT
Subject: [jdk17] RFR: 8269543: The warning for System::setSecurityManager
 should only appear once for each caller [v2]
In-Reply-To: <vPw2xfwQgS1duPSA8DJi8DmTahaKp62qxqtnzZxOos0=.70c45b23-da4c-40fc-8e37-5e65d9570f69@github.com>
References: <2wPGdH3DHTe2qZGNGWufKdvKRpw8UnjeQYYeX8HgKrg=.8589766e-28ee-44f5-80a2-8a1e021f1d3e@github.com>
 <vPw2xfwQgS1duPSA8DJi8DmTahaKp62qxqtnzZxOos0=.70c45b23-da4c-40fc-8e37-5e65d9570f69@github.com>
Message-ID: <aFJLfJ9MywV1I2xstsgH5AlMh8rJjEHbOJK7t0BG3oY=.0c19bfed-3fe4-49fa-b5af-663b76b8663a@github.com>

On Wed, 30 Jun 2021 15:45:25 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Add a cache to record which sources have called `System::setSecurityManager` and only print out warning lines once for each.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update cache key from String to Class

Marked as reviewed by alanb (Reviewer).

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

PR: https://git.openjdk.java.net/jdk17/pull/166

From jai.forums2013 at gmail.com  Fri Jul  2 12:08:43 2021
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Fri, 2 Jul 2021 17:38:43 +0530
Subject: RFR: 8251329: (zipfs) Files.walkFileTree walks infinitely if zip
 has dir named "." inside [v4]
In-Reply-To: <FS4dG8muHl9vXW_eryRBZkDsRiquNnNOCLBlwsNVXeU=.1cecfec8-6a90-4cd4-a796-249c9b8c3110@github.com>
References: <H5Dy39I78mG6FE2N9U5vZnEhGI2zcIaxGvJ8uZBCGM0=.f3ba4976-f985-4002-87f3-da234b3c402d@github.com>
 <FWKKv49jcPmyN0fr_GVK0Sz3DceDPXRF724C45esjF8=.c86aa8c4-8fbd-4b76-90fa-a906323aae8a@github.com>
 <FS4dG8muHl9vXW_eryRBZkDsRiquNnNOCLBlwsNVXeU=.1cecfec8-6a90-4cd4-a796-249c9b8c3110@github.com>
Message-ID: <3d068121-9800-972c-dbd6-cd46b25f6dde@gmail.com>

Hello Lance,

On 02/07/21 4:42 pm, Lance Andersen wrote:
> Hi Jaikiran,
>
> Consider:
>
>
>          try (var os = Files.newOutputStream(ZIPFILE);
>               ZipOutputStream zos = new ZipOutputStream(os)) {
>              zos.putNextEntry(new ZipEntry("../Hello.txt"));
>              zos.write("Hello World".getBytes(StandardCharsets.UTF_8));
>          }
>
>
> With your proposed fix, you will only return "/" when you walk the the Zip file and we should also return "/Hello.txt"

Thank you for noticing this issue in my change and bringing this up. I 
have a question around this use case. Please consider a small variation 
to your example as below:

try (var os = Files.newOutputStream(ZIPFILE);
 ???????????? ZipOutputStream zos = new ZipOutputStream(os)) {
 ??????????? zos.putNextEntry(new ZipEntry("../Hello.txt"));
 ??????????? zos.write("Hello World".getBytes(StandardCharsets.UTF_8));
 ??????????? zos.closeEntry();
 ??????????? zos.putNextEntry(new ZipEntry("/Hello.txt"));
 ??? ??? ??? zos.write("Bye bye".getBytes(StandardCharsets.UTF_8));
 ??? ??? ??? zos.closeEntry();

 ??????? }

Notice that I now have a zip/jar which has 2 differently named entries 
"../Hello.txt" and "/Hello.txt". This creates the archive without any 
issues and those 2 entries are noted in its listing. Now assuming 
someone walks over this jar using the ZipFileSystem, starting at root 
("/"), what should be the expected output? The path(s) returned will end 
up being "/" and "/Hello.txt" but which resource is expected to be 
served in this case? The one which has "Hello World" in it or the one 
which has "Bye bye"? This example can be extended a bit more by 
introducing a "./Hello.txt", in the jar, with yet another different 
content in that entry. Is there some specification for this that I can 
check and adapt the test case accordingly?

-Jaikiran




From dfuchs at openjdk.java.net  Fri Jul  2 13:10:03 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 2 Jul 2021 13:10:03 GMT
Subject: [jdk17] RFR: 8269543: The warning for System::setSecurityManager
 should only appear once for each caller [v2]
In-Reply-To: <vPw2xfwQgS1duPSA8DJi8DmTahaKp62qxqtnzZxOos0=.70c45b23-da4c-40fc-8e37-5e65d9570f69@github.com>
References: <2wPGdH3DHTe2qZGNGWufKdvKRpw8UnjeQYYeX8HgKrg=.8589766e-28ee-44f5-80a2-8a1e021f1d3e@github.com>
 <vPw2xfwQgS1duPSA8DJi8DmTahaKp62qxqtnzZxOos0=.70c45b23-da4c-40fc-8e37-5e65d9570f69@github.com>
Message-ID: <9-2TmhbxjWMwweT6MU1z_NII6-dFS9I9gmfq2DALNR0=.41d9d65a-fec8-4945-a23c-1037915030e7@github.com>

On Wed, 30 Jun 2021 15:45:25 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Add a cache to record which sources have called `System::setSecurityManager` and only print out warning lines once for each.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update cache key from String to Class

Marked as reviewed by dfuchs (Reviewer).

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

PR: https://git.openjdk.java.net/jdk17/pull/166

From Alan.Bateman at oracle.com  Fri Jul  2 13:37:15 2021
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 2 Jul 2021 14:37:15 +0100
Subject: RFR: 8251329: (zipfs) Files.walkFileTree walks infinitely if zip
 has dir named "." inside [v4]
In-Reply-To: <3d068121-9800-972c-dbd6-cd46b25f6dde@gmail.com>
References: <H5Dy39I78mG6FE2N9U5vZnEhGI2zcIaxGvJ8uZBCGM0=.f3ba4976-f985-4002-87f3-da234b3c402d@github.com>
 <FWKKv49jcPmyN0fr_GVK0Sz3DceDPXRF724C45esjF8=.c86aa8c4-8fbd-4b76-90fa-a906323aae8a@github.com>
 <FS4dG8muHl9vXW_eryRBZkDsRiquNnNOCLBlwsNVXeU=.1cecfec8-6a90-4cd4-a796-249c9b8c3110@github.com>
 <3d068121-9800-972c-dbd6-cd46b25f6dde@gmail.com>
Message-ID: <f8a57ce5-4f67-ad37-ef4f-66777bb79257@oracle.com>

On 02/07/2021 13:08, Jaikiran Pai wrote:
>
> Thank you for noticing this issue in my change and bringing this up. I 
> have a question around this use case. Please consider a small 
> variation to your example as below:
>
> try (var os = Files.newOutputStream(ZIPFILE);
> ???????????? ZipOutputStream zos = new ZipOutputStream(os)) {
> ??????????? zos.putNextEntry(new ZipEntry("../Hello.txt"));
> ??????????? zos.write("Hello World".getBytes(StandardCharsets.UTF_8));
> ??????????? zos.closeEntry();
> ??????????? zos.putNextEntry(new ZipEntry("/Hello.txt"));
> ??? ??? ??? zos.write("Bye bye".getBytes(StandardCharsets.UTF_8));
> ??? ??? ??? zos.closeEntry();
>
> ??????? }
>
> Notice that I now have a zip/jar which has 2 differently named entries 
> "../Hello.txt" and "/Hello.txt". This creates the archive without any 
> issues and those 2 entries are noted in its listing. Now assuming 
> someone walks over this jar using the ZipFileSystem, starting at root 
> ("/"), what should be the expected output? The path(s) returned will 
> end up being "/" and "/Hello.txt" but which resource is expected to be 
> served in this case? The one which has "Hello World" in it or the one 
> which has "Bye bye"? This example can be extended a bit more by 
> introducing a "./Hello.txt", in the jar, with yet another different 
> content in that entry. Is there some specification for this that I can 
> check and adapt the test case accordingly?

This is an area where treating a zip file as a virtual file system 
doesn't quite work. We may have to look at zipfs ignoring entries that 
contain "." or ".." name elements or have it throw an exception if they 
are encountered. I think the main thing is that the APIs and access 
behaves consistently.

-Alan

From aph at openjdk.java.net  Fri Jul  2 13:50:58 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Fri, 2 Jul 2021 13:50:58 GMT
Subject: RFR: 8188044: We need Math.unsignedMultiplyHigh [v2]
In-Reply-To: <6ACk9pK531fFvDVuVmwn-hmDus1To0Au8XUqS2evoVE=.26c6d744-3ad0-41cb-95d8-ebe25847ee9f@github.com>
References: <23ldlDveuxh3c09WTFw5rQTJTAGd-KQHdo5K_KTtFSU=.39e4ccfb-e56e-4473-bee8-3c272cc94771@github.com>
 <IRMokdcxI2T6fdKxFf3iIPH5LQXz3EXA7rZ9BUS0piI=.4290d61b-73e5-485c-a6b0-447fbf8ff515@github.com>
 <DBf6kvmAyHaCJOL-N9_U6I2oD_vfZiAxd6uBikVqIkk=.baa649e1-2388-4043-ac38-aa830c7957e1@github.com>
 <cXN8Tz273jZPsLIa7OEy7lVYKI3Ymkzvm3U8pKjYafM=.3c5f1e53-d5b6-48a4-9108-b41cb1648e6c@github.com>
 <6ACk9pK531fFvDVuVmwn-hmDus1To0Au8XUqS2evoVE=.26c6d744-3ad0-41cb-95d8-ebe25847ee9f@github.com>
Message-ID: <t51Fc-XCsi_CdivJZPlp0RR6vMDU5In93PEACupH2kw=.c5f5f6a6-0e12-442b-b424-42df6a2447b2@github.com>

On Fri, 2 Jul 2021 11:06:06 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

> You can also do that branchlessly which might prove better
> 
> ```
>      long result = Math.multiplyHigh(x, y);
>      result += (y & (x >> 63));
>      result += (x & (y >> 63));
>      return result;
> ```
I doubt very much that it would be better, because these days branch prediction is excellent, and we also have conditional select instructions. Exposing the condition helps C2 to eliminate it if the range of args is known. The `if` code is easier to understand.

Benchmark results, with one of the operands changing signs every iteration, 1000 iterations:


Benchmark                  Mode  Cnt     Score    Error  Units
MulHiTest.mulHiTest1   (aph)     avgt    3  1570.587 ? 16.602  ns/op
MulHiTest.mulHiTest2   (adinn)   avgt    3  2237.637 ?  4.740  ns/op

In any case, note that with this optimization the unsigned mulHi is in the nanosecond range, so Good Enough. IMO.

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

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

From aph at openjdk.java.net  Fri Jul  2 14:08:04 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Fri, 2 Jul 2021 14:08:04 GMT
Subject: RFR: 8188044: We need Math.unsignedMultiplyHigh [v2]
In-Reply-To: <t51Fc-XCsi_CdivJZPlp0RR6vMDU5In93PEACupH2kw=.c5f5f6a6-0e12-442b-b424-42df6a2447b2@github.com>
References: <23ldlDveuxh3c09WTFw5rQTJTAGd-KQHdo5K_KTtFSU=.39e4ccfb-e56e-4473-bee8-3c272cc94771@github.com>
 <IRMokdcxI2T6fdKxFf3iIPH5LQXz3EXA7rZ9BUS0piI=.4290d61b-73e5-485c-a6b0-447fbf8ff515@github.com>
 <DBf6kvmAyHaCJOL-N9_U6I2oD_vfZiAxd6uBikVqIkk=.baa649e1-2388-4043-ac38-aa830c7957e1@github.com>
 <cXN8Tz273jZPsLIa7OEy7lVYKI3Ymkzvm3U8pKjYafM=.3c5f1e53-d5b6-48a4-9108-b41cb1648e6c@github.com>
 <6ACk9pK531fFvDVuVmwn-hmDus1To0Au8XUqS2evoVE=.26c6d744-3ad0-41cb-95d8-ebe25847ee9f@github.com>
 <t51Fc-XCsi_CdivJZPlp0RR6vMDU5In93PEACupH2kw=.c5f5f6a6-0e12-442b-b424-42df6a2447b2@github.com>
Message-ID: <-fnw-WjzR-w7-M2bBVyqvNTbJ7YAPn5BE2DvPovQpB4=.61ed745e-c001-4ba3-9c9f-1ddd871df462@github.com>

On Fri, 2 Jul 2021 13:47:40 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> You can also do that branchlessly which might prove better
>> 
>>          long result = Math.multiplyHigh(x, y);
>>          result += (y & (x >> 63));
>>          result += (x & (y >> 63));
>>          return result;
>
>> You can also do that branchlessly which might prove better
>> 
>> ```
>>      long result = Math.multiplyHigh(x, y);
>>      result += (y & (x >> 63));
>>      result += (x & (y >> 63));
>>      return result;
>> ```
> I doubt very much that it would be better, because these days branch prediction is excellent, and we also have conditional select instructions. Exposing the condition helps C2 to eliminate it if the range of args is known. The `if` code is easier to understand.
> 
> Benchmark results, with one of the operands changing signs every iteration, 1000 iterations:
> 
> 
> Benchmark                  Mode  Cnt     Score    Error  Units
> MulHiTest.mulHiTest1   (aph)     avgt    3  1570.587 ? 16.602  ns/op
> MulHiTest.mulHiTest2   (adinn)   avgt    3  2237.637 ?  4.740  ns/op
> 
> In any case, note that with this optimization the unsigned mulHi is in the nanosecond range, so Good Enough. IMO.

But weirdly, it's the other way around on AArch64, but there's little in it:


Benchmark             Mode  Cnt     Score   Error  Units
MulHiTest.mulHiTest1  avgt    3  1492.108 ? 0.301  ns/op
MulHiTest.mulHiTest2  avgt    3  1219.521 ? 1.516  ns/op


but this is only in the case where we have unpredictable branches. Go with simple and easy to understand; it doesn't much matter.

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

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

From rriggs at openjdk.java.net  Fri Jul  2 14:10:15 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 2 Jul 2021 14:10:15 GMT
Subject: RFR: 8188046: java.lang.Math.mutliplyHigh does not run in
 constant time
In-Reply-To: <-XW-J7GWnt6RQmbuvQ1bApn7qC2hNpW4bspCOCG8KRw=.4a315407-7617-47a7-993f-fc0c8e906a0f@github.com>
References: <-XW-J7GWnt6RQmbuvQ1bApn7qC2hNpW4bspCOCG8KRw=.4a315407-7617-47a7-993f-fc0c8e906a0f@github.com>
Message-ID: <UTh1L871uynDTZh1dpNn1fI0Uw8G_7_eGJgyv9dAxcw=.ea81a023-c3a8-4a43-ba95-b22e6f1f2544@github.com>

On Thu, 1 Jul 2021 23:46:00 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Please consider this proposal to remove the fast path in `java.lang.Math.multiplyHigh()` the small performance improvement of which is eclipsed by the branch penalty.

Marked as reviewed by rriggs (Reviewer).

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

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

From albest512 at hotmail.com  Fri Jul  2 14:22:39 2021
From: albest512 at hotmail.com (=?utf-8?B?QWxiZXJ0byBPdGVybyBSb2Ryw61ndWV6?=)
Date: Fri, 2 Jul 2021 14:22:39 +0000
Subject: Methods removeFirstIf in Collection and skipFirst in Stream
Message-ID: <VE1P191MB0879B9C24D3276F4325FA837F41F9@VE1P191MB0879.EURP191.PROD.OUTLOOK.COM>

Hi,

I think it would be interesting adding the following methods:

1) In Collection:
           default boolean removeFirstIf?(Predicate<https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/util/function/Predicate.html><? super E<https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/util/Collection.html>> filter)

2) In Stream:
           Stream<https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/util/stream/Stream.html><T<https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/util/stream/Stream.html>> skipFirst(Predicate<https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/util/function/Predicate.html><? super T<https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/util/stream/Stream.html>> predicate)

The purpose of both methods would be the same. Deleting the first element in the collection that fulfills the predicate.

This could be useful in collections/streams with no duplicate elements where performance would be better than using removeIf from Collection of filter from Stream.

Regards,

Alberto.

From albest512 at hotmail.com  Fri Jul  2 14:26:38 2021
From: albest512 at hotmail.com (=?utf-8?B?QWxiZXJ0byBPdGVybyBSb2Ryw61ndWV6?=)
Date: Fri, 2 Jul 2021 14:26:38 +0000
Subject: Methods removeFirstIf in Collection and skipFirst in Stream
In-Reply-To: <VE1P191MB0879B9C24D3276F4325FA837F41F9@VE1P191MB0879.EURP191.PROD.OUTLOOK.COM>
References: <VE1P191MB0879B9C24D3276F4325FA837F41F9@VE1P191MB0879.EURP191.PROD.OUTLOOK.COM>
Message-ID: <VE1P191MB087944028093CF0865C7F0B2F41F9@VE1P191MB0879.EURP191.PROD.OUTLOOK.COM>

Sorry for the links, the methods would be:

1) In Collection:
           default boolean removeFirstIf?(Predicate<? super E<https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/util/Collection.html>> filter)

2) In Stream:
           Stream<T> skipFirst(Predicate<? super T<https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/util/stream/Stream.html>> predicate)
________________________________
De: Alberto Otero Rodr?guez
Enviado: viernes, 2 de julio de 2021 16:22
Para: core-libs-dev at openjdk.java.net <core-libs-dev at openjdk.java.net>
Asunto: Methods removeFirstIf in Collection and skipFirst in Stream

Hi,

I think it would be interesting adding the following methods:

1) In Collection:
           default boolean removeFirstIf?(Predicate<https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/util/function/Predicate.html><? super E<https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/util/Collection.html>> filter)

2) In Stream:
           Stream<https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/util/stream/Stream.html><T<https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/util/stream/Stream.html>> skipFirst(Predicate<https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/util/function/Predicate.html><? super T<https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/util/stream/Stream.html>> predicate)

The purpose of both methods would be the same. Deleting the first element in the collection that fulfills the predicate.

This could be useful in collections/streams with no duplicate elements where performance would be better than using removeIf from Collection of filter from Stream.

Regards,

Alberto.

From weijun at openjdk.java.net  Fri Jul  2 14:34:55 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 2 Jul 2021 14:34:55 GMT
Subject: [jdk17] Integrated: 8269543: The warning for
 System::setSecurityManager should only appear once for each caller
In-Reply-To: <2wPGdH3DHTe2qZGNGWufKdvKRpw8UnjeQYYeX8HgKrg=.8589766e-28ee-44f5-80a2-8a1e021f1d3e@github.com>
References: <2wPGdH3DHTe2qZGNGWufKdvKRpw8UnjeQYYeX8HgKrg=.8589766e-28ee-44f5-80a2-8a1e021f1d3e@github.com>
Message-ID: <h3cspiMMq_kDpabeYIbNJc73NetxNajHjIlC87i2H-Q=.039d95db-049e-4669-8802-f2a57a982a4c@github.com>

On Mon, 28 Jun 2021 21:09:43 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Add a cache to record which sources have called `System::setSecurityManager` and only print out warning lines once for each.

This pull request has now been integrated.

Changeset: c4ea13ed
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.java.net/jdk17/commit/c4ea13edd036bd6aeb213bb5391dd374d283d382
Stats:     59 lines in 2 files changed: 40 ins; 6 del; 13 mod

8269543: The warning for System::setSecurityManager should only appear once for each caller

Reviewed-by: lancea, alanb, dfuchs

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

PR: https://git.openjdk.java.net/jdk17/pull/166

From aph at redhat.com  Fri Jul  2 14:51:58 2021
From: aph at redhat.com (Andrew Haley)
Date: Fri, 2 Jul 2021 15:51:58 +0100
Subject: RFR: 8188044: We need Math.unsignedMultiplyHigh [v2]
In-Reply-To: <0a480e9f-708b-bb31-5f68-ab28560e54e1@gmail.com>
References: <23ldlDveuxh3c09WTFw5rQTJTAGd-KQHdo5K_KTtFSU=.39e4ccfb-e56e-4473-bee8-3c272cc94771@github.com>
 <IRMokdcxI2T6fdKxFf3iIPH5LQXz3EXA7rZ9BUS0piI=.4290d61b-73e5-485c-a6b0-447fbf8ff515@github.com>
 <DBf6kvmAyHaCJOL-N9_U6I2oD_vfZiAxd6uBikVqIkk=.baa649e1-2388-4043-ac38-aa830c7957e1@github.com>
 <cXN8Tz273jZPsLIa7OEy7lVYKI3Ymkzvm3U8pKjYafM=.3c5f1e53-d5b6-48a4-9108-b41cb1648e6c@github.com>
 <6ACk9pK531fFvDVuVmwn-hmDus1To0Au8XUqS2evoVE=.26c6d744-3ad0-41cb-95d8-ebe25847ee9f@github.com>
 <0a480e9f-708b-bb31-5f68-ab28560e54e1@gmail.com>
Message-ID: <af720d64-1bc7-d4ee-3884-a3d89b8b0e89@redhat.com>

On 7/2/21 12:26 PM, Raffaello Giulietti wrote:
> ... or even as a one liner, like in the test
> 
> 	return Math.multiplyHigh(x, y) + ((x >> (Long.SIZE - 1)) & y) + ((y >> 
> (Long.SIZE - 1)) & x);

It was hard to write, so it should be hard to read too! :-)


From pconcannon at openjdk.java.net  Fri Jul  2 15:17:29 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Fri, 2 Jul 2021 15:17:29 GMT
Subject: RFR: 8269124: Update java.time to use switch expressions (part
 II) [v6]
In-Reply-To: <gWxnxFurKCz661GQXfULGi2g_xpcVXXlJVg0JCMwOoY=.629dc4ac-0633-483a-8436-35c4d66b4c7b@github.com>
References: <gWxnxFurKCz661GQXfULGi2g_xpcVXXlJVg0JCMwOoY=.629dc4ac-0633-483a-8436-35c4d66b4c7b@github.com>
Message-ID: <TevLQGtPGajkMMgzyFWFkeOF5EqUOhWInfxXQOXOU5k=.b7c28c11-196f-459e-acfc-3da0eaed691f@github.com>

> Hi,
> 
> Could someone please review the second half of my update for the `java.time` package to make use of switch expressions?
> 
> This PR was split into two parts due to the large number of files affected.
> 
> Kind regards,
> 
> Patrick

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

 - Merge remote-tracking branch 'origin/master' into JDK-8269124
 - Merge branch 'JDK-8269124' of github.com:pconcannon/jdk into JDK-8269124
 - 8269124: Added instanceof pattern variables
 - Merge remote-tracking branch 'origin/master' into JDK-8269124
 - 8269124: Added missing return
 - 8269124: Added missing brace; fixed build issue
 - 8269124: Update java.time to use switch expressions (part II)

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4552/files
  - new: https://git.openjdk.java.net/jdk/pull/4552/files/3a1b7161..8dede463

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

  Stats: 18116 lines in 555 files changed: 8086 ins; 8092 del; 1938 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4552.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4552/head:pull/4552

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

From raffaello.giulietti at gmail.com  Fri Jul  2 15:30:59 2021
From: raffaello.giulietti at gmail.com (Raffaello Giulietti)
Date: Fri, 2 Jul 2021 17:30:59 +0200
Subject: RFR: 8188044: We need Math.unsignedMultiplyHigh [v2]
In-Reply-To: <t51Fc-XCsi_CdivJZPlp0RR6vMDU5In93PEACupH2kw=.c5f5f6a6-0e12-442b-b424-42df6a2447b2@github.com>
References: <23ldlDveuxh3c09WTFw5rQTJTAGd-KQHdo5K_KTtFSU=.39e4ccfb-e56e-4473-bee8-3c272cc94771@github.com>
 <IRMokdcxI2T6fdKxFf3iIPH5LQXz3EXA7rZ9BUS0piI=.4290d61b-73e5-485c-a6b0-447fbf8ff515@github.com>
 <DBf6kvmAyHaCJOL-N9_U6I2oD_vfZiAxd6uBikVqIkk=.baa649e1-2388-4043-ac38-aa830c7957e1@github.com>
 <cXN8Tz273jZPsLIa7OEy7lVYKI3Ymkzvm3U8pKjYafM=.3c5f1e53-d5b6-48a4-9108-b41cb1648e6c@github.com>
 <6ACk9pK531fFvDVuVmwn-hmDus1To0Au8XUqS2evoVE=.26c6d744-3ad0-41cb-95d8-ebe25847ee9f@github.com>
 <t51Fc-XCsi_CdivJZPlp0RR6vMDU5In93PEACupH2kw=.c5f5f6a6-0e12-442b-b424-42df6a2447b2@github.com>
Message-ID: <5b91946a-42f7-0769-fc64-23321a2b7593@gmail.com>

FWIW, adinn's branchless code together with
PR https://git.openjdk.java.net/jdk/pull/4660
make both methods less vulnerable to timing attacks.


Greetings
Raffaello


On 2021-07-02 15:50, Andrew Haley wrote:
> On Fri, 2 Jul 2021 11:06:06 GMT, Andrew Dinn <adinn at openjdk.org> wrote:
> 
>> You can also do that branchlessly which might prove better
>>
>> ```
>>       long result = Math.multiplyHigh(x, y);
>>       result += (y & (x >> 63));
>>       result += (x & (y >> 63));
>>       return result;
>> ```
> I doubt very much that it would be better, because these days branch prediction is excellent, and we also have conditional select instructions. Exposing the condition helps C2 to eliminate it if the range of args is known. The `if` code is easier to understand.
> 
> Benchmark results, with one of the operands changing signs every iteration, 1000 iterations:
> 
> 
> Benchmark                  Mode  Cnt     Score    Error  Units
> MulHiTest.mulHiTest1   (aph)     avgt    3  1570.587 ? 16.602  ns/op
> MulHiTest.mulHiTest2   (adinn)   avgt    3  2237.637 ?  4.740  ns/op
> 
> In any case, note that with this optimization the unsigned mulHi is in the nanosecond range, so Good Enough. IMO.
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/4644
> 

From adinn at redhat.com  Fri Jul  2 15:55:27 2021
From: adinn at redhat.com (Andrew Dinn)
Date: Fri, 2 Jul 2021 16:55:27 +0100
Subject: RFR: 8188044: We need Math.unsignedMultiplyHigh [v2]
In-Reply-To: <5b91946a-42f7-0769-fc64-23321a2b7593@gmail.com>
References: <23ldlDveuxh3c09WTFw5rQTJTAGd-KQHdo5K_KTtFSU=.39e4ccfb-e56e-4473-bee8-3c272cc94771@github.com>
 <IRMokdcxI2T6fdKxFf3iIPH5LQXz3EXA7rZ9BUS0piI=.4290d61b-73e5-485c-a6b0-447fbf8ff515@github.com>
 <DBf6kvmAyHaCJOL-N9_U6I2oD_vfZiAxd6uBikVqIkk=.baa649e1-2388-4043-ac38-aa830c7957e1@github.com>
 <cXN8Tz273jZPsLIa7OEy7lVYKI3Ymkzvm3U8pKjYafM=.3c5f1e53-d5b6-48a4-9108-b41cb1648e6c@github.com>
 <6ACk9pK531fFvDVuVmwn-hmDus1To0Au8XUqS2evoVE=.26c6d744-3ad0-41cb-95d8-ebe25847ee9f@github.com>
 <t51Fc-XCsi_CdivJZPlp0RR6vMDU5In93PEACupH2kw=.c5f5f6a6-0e12-442b-b424-42df6a2447b2@github.com>
 <5b91946a-42f7-0769-fc64-23321a2b7593@gmail.com>
Message-ID: <ac14ecd4-66f4-0c67-f027-489f66343a61@redhat.com>

On 02/07/2021 16:30, Raffaello Giulietti wrote:
> FWIW, adinn's branchless code together with
> PR https://git.openjdk.java.net/jdk/pull/4660
> make both methods less vulnerable to timing attacks.
That was indeed the point of the change. However, I doubt the difference 
in timing is going to be significant given Andrew's micro-benchmark results.

regards,


Andrew Dinn
-----------
Red Hat Distinguished Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill


From aph at redhat.com  Fri Jul  2 16:10:27 2021
From: aph at redhat.com (Andrew Haley)
Date: Fri, 2 Jul 2021 17:10:27 +0100
Subject: RFR: 8188044: We need Math.unsignedMultiplyHigh [v2]
In-Reply-To: <5b91946a-42f7-0769-fc64-23321a2b7593@gmail.com>
References: <23ldlDveuxh3c09WTFw5rQTJTAGd-KQHdo5K_KTtFSU=.39e4ccfb-e56e-4473-bee8-3c272cc94771@github.com>
 <IRMokdcxI2T6fdKxFf3iIPH5LQXz3EXA7rZ9BUS0piI=.4290d61b-73e5-485c-a6b0-447fbf8ff515@github.com>
 <DBf6kvmAyHaCJOL-N9_U6I2oD_vfZiAxd6uBikVqIkk=.baa649e1-2388-4043-ac38-aa830c7957e1@github.com>
 <cXN8Tz273jZPsLIa7OEy7lVYKI3Ymkzvm3U8pKjYafM=.3c5f1e53-d5b6-48a4-9108-b41cb1648e6c@github.com>
 <6ACk9pK531fFvDVuVmwn-hmDus1To0Au8XUqS2evoVE=.26c6d744-3ad0-41cb-95d8-ebe25847ee9f@github.com>
 <t51Fc-XCsi_CdivJZPlp0RR6vMDU5In93PEACupH2kw=.c5f5f6a6-0e12-442b-b424-42df6a2447b2@github.com>
 <5b91946a-42f7-0769-fc64-23321a2b7593@gmail.com>
Message-ID: <961c45d7-2043-d47d-c8b0-137394e40eeb@redhat.com>

On 7/2/21 4:30 PM, Raffaello Giulietti wrote:
> FWIW, adinn's branchless code together with
> PR https://git.openjdk.java.net/jdk/pull/4660
> make both methods less vulnerable to timing attacks.

I doubt it, because HotSpot generates conditional select instructions for
the popular systems, at least for C2.

I guess it might on a C1-only or pure interpreter system. That certainly
might be an argument for using the shift-and-add magic. With a comment
that would be fine, as the difference in performance doesn't seem to be
worth worrying about. We're looking at sub-nanosecond throughput.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From lance.andersen at oracle.com  Fri Jul  2 16:13:36 2021
From: lance.andersen at oracle.com (Lance Andersen)
Date: Fri, 2 Jul 2021 16:13:36 +0000
Subject: RFR: 8251329: (zipfs) Files.walkFileTree walks infinitely if zip
 has dir named "." inside [v4]
In-Reply-To: <3d068121-9800-972c-dbd6-cd46b25f6dde@gmail.com>
References: <H5Dy39I78mG6FE2N9U5vZnEhGI2zcIaxGvJ8uZBCGM0=.f3ba4976-f985-4002-87f3-da234b3c402d@github.com>
 <FWKKv49jcPmyN0fr_GVK0Sz3DceDPXRF724C45esjF8=.c86aa8c4-8fbd-4b76-90fa-a906323aae8a@github.com>
 <FS4dG8muHl9vXW_eryRBZkDsRiquNnNOCLBlwsNVXeU=.1cecfec8-6a90-4cd4-a796-249c9b8c3110@github.com>
 <3d068121-9800-972c-dbd6-cd46b25f6dde@gmail.com>
Message-ID: <C30F6CF9-02F3-4604-8976-2425B8568326@oracle.com>



On Jul 2, 2021, at 8:08 AM, Jaikiran Pai <jai.forums2013 at gmail.com<mailto:jai.forums2013 at gmail.com>> wrote:

Hello Lance,

On 02/07/21 4:42 pm, Lance Andersen wrote:
Hi Jaikiran,

Consider:


        try (var os = Files.newOutputStream(ZIPFILE);
             ZipOutputStream zos = new ZipOutputStream(os)) {
            zos.putNextEntry(new ZipEntry("../Hello.txt"));
            zos.write("Hello World".getBytes(StandardCharsets.UTF_8));
        }


With your proposed fix, you will only return "/" when you walk the the Zip file and we should also return "/Hello.txt"

Thank you for noticing this issue in my change and bringing this up. I have a question around this use case. Please consider a small variation to your example as below:

try (var os = Files.newOutputStream(ZIPFILE);
             ZipOutputStream zos = new ZipOutputStream(os)) {
            zos.putNextEntry(new ZipEntry("../Hello.txt"));
            zos.write("Hello World".getBytes(StandardCharsets.UTF_8));
            zos.closeEntry();
            zos.putNextEntry(new ZipEntry("/Hello.txt"));
            zos.write("Bye bye".getBytes(StandardCharsets.UTF_8));
            zos.closeEntry();

        }

Notice that I now have a zip/jar which has 2 differently named entries "../Hello.txt" and "/Hello.txt". This creates the archive without any issues and those 2 entries are noted in its listing. Now assuming someone walks over this jar using the ZipFileSystem, starting at root ("/"), what should be the expected output? The path(s) returned will end up being "/" and "/Hello.txt" but which resource is expected to be served in this case? The one which has "Hello World" in it or the one which has "Bye bye"? This example can be extended a bit more by introducing a "./Hello.txt", in the jar, with yet another different content in that entry. Is there some specification for this that I can check and adapt the test case accordingly?


Consider Hello.zip created via:


try (var os = Files.newOutputStream(Path.of("Hello.zip"));
     ZipOutputStream zos = new ZipOutputStream(os)) {
    zos.putNextEntry(new ZipEntry("../Hello.txt"));
    zos.write("Hello".getBytes(StandardCharsets.UTF_8));
    zos.putNextEntry(new ZipEntry("Hello.txt"));
    zos.write("Another Hello".getBytes(StandardCharsets.UTF_8));

}

Winzip does not handle this case well.

InfoZip will :

-------------
unzip ../Hello.zip
Archive:  ../Hello.zip
warning:  skipped "../" path component(s) in ../Hello.txt
  inflating: Hello.txt
replace Hello.txt? [y]es, [n]o, [A]ll, [N]one, [r]ename: r
new name: foo.txt
  inflating: foo.txt
% ls
Hello.txt       foo.txt
 % cat Hello.txt
Hello
 % cat foo.txt
Another Hello
%
????????

This scenario is not well covered in the Zip spec, so we can do what we think is best.

 Personally, I am OK with resolving the path.  The odds of having multiple relative paths to the same file would be a mistake in creating the Zip.

That being said, if we want to follow Alan?s suggestion and throw an Exception, I am OK with that as well.

Either way, we currently cannot access the file via Zip FS due to the call to ZipPath::getResolvedPath() for all access and the path is only normalized when the Inodes are created.

Alan, do you have a specific preference?


-Jaikiran




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



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




From bpb at openjdk.java.net  Fri Jul  2 16:21:15 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Fri, 2 Jul 2021 16:21:15 GMT
Subject: RFR: 8188044: We need Math.unsignedMultiplyHigh [v3]
In-Reply-To: <23ldlDveuxh3c09WTFw5rQTJTAGd-KQHdo5K_KTtFSU=.39e4ccfb-e56e-4473-bee8-3c272cc94771@github.com>
References: <23ldlDveuxh3c09WTFw5rQTJTAGd-KQHdo5K_KTtFSU=.39e4ccfb-e56e-4473-bee8-3c272cc94771@github.com>
Message-ID: <D-AuSm0x9mZuvorpsKgTPck3Mybsi_z63M6zDl9tHDA=.459eacda-c4bb-49d2-95a1-f4cdb76aa37a@github.com>

> Please consider this proposal to add a method `unsignedMultiplyHigh(long,long)` to each of `java.lang.Math` and `java.lang.StrictMath`.

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

  8188044: Use multiplyHigh() to gleverage the inverage the intrinsic

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4644/files
  - new: https://git.openjdk.java.net/jdk/pull/4644/files/0a8fec63..2ad5e395

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

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

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

From aph at openjdk.java.net  Fri Jul  2 16:41:16 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Fri, 2 Jul 2021 16:41:16 GMT
Subject: RFR: 8188044: We need Math.unsignedMultiplyHigh [v4]
In-Reply-To: <7_2wD0p9XFCsTCtzGQthrAz8qgbOPCAMpVqvkLDxWIA=.6a9bc720-bb4b-4b3c-b105-dacc2701190e@github.com>
References: <23ldlDveuxh3c09WTFw5rQTJTAGd-KQHdo5K_KTtFSU=.39e4ccfb-e56e-4473-bee8-3c272cc94771@github.com>
 <7_2wD0p9XFCsTCtzGQthrAz8qgbOPCAMpVqvkLDxWIA=.6a9bc720-bb4b-4b3c-b105-dacc2701190e@github.com>
Message-ID: <VVLf9SWmnZGTRoQvCYdXG9dt6adZpySaJGPLjlGTHzg=.5ef4d3cd-61df-4097-95ae-4ec4149c37c8@github.com>

On Fri, 2 Jul 2021 16:37:21 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Please consider this proposal to add a method `unsignedMultiplyHigh(long,long)` to each of `java.lang.Math` and `java.lang.StrictMath`.
>
> Brian Burkhalter 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:
> 
>   8188044: Use multiplyHigh() to leverage the intrinsic

Marked as reviewed by aph (Reviewer).

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

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

From bpb at openjdk.java.net  Fri Jul  2 16:41:16 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Fri, 2 Jul 2021 16:41:16 GMT
Subject: RFR: 8188044: We need Math.unsignedMultiplyHigh [v4]
In-Reply-To: <23ldlDveuxh3c09WTFw5rQTJTAGd-KQHdo5K_KTtFSU=.39e4ccfb-e56e-4473-bee8-3c272cc94771@github.com>
References: <23ldlDveuxh3c09WTFw5rQTJTAGd-KQHdo5K_KTtFSU=.39e4ccfb-e56e-4473-bee8-3c272cc94771@github.com>
Message-ID: <7_2wD0p9XFCsTCtzGQthrAz8qgbOPCAMpVqvkLDxWIA=.6a9bc720-bb4b-4b3c-b105-dacc2701190e@github.com>

> Please consider this proposal to add a method `unsignedMultiplyHigh(long,long)` to each of `java.lang.Math` and `java.lang.StrictMath`.

Brian Burkhalter 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:

  8188044: Use multiplyHigh() to leverage the intrinsic

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4644/files
  - new: https://git.openjdk.java.net/jdk/pull/4644/files/2ad5e395..a499b2e5

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

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

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

From bpb at openjdk.java.net  Fri Jul  2 16:58:18 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Fri, 2 Jul 2021 16:58:18 GMT
Subject: [jdk17] RFR: 6766844: ByteArrayInputStream#read with a byte array
 of length 0 not consistent with InputStream when at EOF [v2]
In-Reply-To: <8nNGNaJvrmtiLTlJcIazAl5J7iVsBxbhEeAItADAoKc=.824db13a-589c-421e-8595-01ac4e5c27bd@github.com>
References: <8nNGNaJvrmtiLTlJcIazAl5J7iVsBxbhEeAItADAoKc=.824db13a-589c-421e-8595-01ac4e5c27bd@github.com>
Message-ID: <MZ3-8xBveOrZ2SZKqevKuJ-dufr_bs9ZrfkLq4kxBA4=.d1779658-8e77-4c2b-87b0-0baafe1efb7a@github.com>

> Modify the specification of `java.io.ByteArrayInputStream#read(byte[],int,int)` to indicate that `-1` is returned instead of `0` when the stream is at its end and the third parameter, `len`, is zero.

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

  6766844: Correct error messages in test

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

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/189/files
  - new: https://git.openjdk.java.net/jdk17/pull/189/files/5b89ab60..528afc5f

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

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

PR: https://git.openjdk.java.net/jdk17/pull/189

From naoto at openjdk.java.net  Fri Jul  2 16:58:19 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 2 Jul 2021 16:58:19 GMT
Subject: [jdk17] RFR: 6766844: ByteArrayInputStream#read with a byte array
 of length 0 not consistent with InputStream when at EOF [v2]
In-Reply-To: <MZ3-8xBveOrZ2SZKqevKuJ-dufr_bs9ZrfkLq4kxBA4=.d1779658-8e77-4c2b-87b0-0baafe1efb7a@github.com>
References: <8nNGNaJvrmtiLTlJcIazAl5J7iVsBxbhEeAItADAoKc=.824db13a-589c-421e-8595-01ac4e5c27bd@github.com>
 <MZ3-8xBveOrZ2SZKqevKuJ-dufr_bs9ZrfkLq4kxBA4=.d1779658-8e77-4c2b-87b0-0baafe1efb7a@github.com>
Message-ID: <kSAw4A38fOiod2avK5CYY2LnnTfczT8zck3S1hhZGXQ=.577ed503-acc0-437c-9e6e-d5730ae1ca49@github.com>

On Fri, 2 Jul 2021 16:55:18 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Modify the specification of `java.io.ByteArrayInputStream#read(byte[],int,int)` to indicate that `-1` is returned instead of `0` when the stream is at its end and the third parameter, `len`, is zero.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   6766844: Correct error messages in test

test/jdk/java/io/ByteArrayInputStream/ReadAllReadNTransferTo.java line 57:

> 55:         }
> 56:         if (bais.read(new byte[1], 0, 0) != -1) {
> 57:             throw new RuntimeException("read(byte[],int,int) did not return 0");

Should these exception messages be "did not return -1"?

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

PR: https://git.openjdk.java.net/jdk17/pull/189

From bpb at openjdk.java.net  Fri Jul  2 16:58:20 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Fri, 2 Jul 2021 16:58:20 GMT
Subject: [jdk17] RFR: 6766844: ByteArrayInputStream#read with a byte array
 of length 0 not consistent with InputStream when at EOF [v2]
In-Reply-To: <kSAw4A38fOiod2avK5CYY2LnnTfczT8zck3S1hhZGXQ=.577ed503-acc0-437c-9e6e-d5730ae1ca49@github.com>
References: <8nNGNaJvrmtiLTlJcIazAl5J7iVsBxbhEeAItADAoKc=.824db13a-589c-421e-8595-01ac4e5c27bd@github.com>
 <MZ3-8xBveOrZ2SZKqevKuJ-dufr_bs9ZrfkLq4kxBA4=.d1779658-8e77-4c2b-87b0-0baafe1efb7a@github.com>
 <kSAw4A38fOiod2avK5CYY2LnnTfczT8zck3S1hhZGXQ=.577ed503-acc0-437c-9e6e-d5730ae1ca49@github.com>
Message-ID: <m90c7PT1Z56TyukkWmEclSAJEkmVVx6NvvNU8FsKmz8=.f6af6687-ca3a-4eb2-bd8c-4f8ffb59ad7c@github.com>

On Fri, 2 Jul 2021 16:50:11 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   6766844: Correct error messages in test
>
> test/jdk/java/io/ByteArrayInputStream/ReadAllReadNTransferTo.java line 57:
> 
>> 55:         }
>> 56:         if (bais.read(new byte[1], 0, 0) != -1) {
>> 57:             throw new RuntimeException("read(byte[],int,int) did not return 0");
> 
> Should these exception messages be "did not return -1"?

Oh you are correct. Thanks!

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

PR: https://git.openjdk.java.net/jdk17/pull/189

From mchung at openjdk.java.net  Fri Jul  2 17:05:02 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Fri, 2 Jul 2021 17:05:02 GMT
Subject: [jdk17] RFR: JDK-8225667: Clarify the behavior of System::gc
 w.r.t. reference processing [v2]
In-Reply-To: <5lpGRmoZ4hfUSSbMCuLT8LmsyTPXkSeBBfmCXdiIdyA=.ea9769b2-6cb1-4705-b1eb-c0c7ffb878ef@github.com>
References: <P5HIv6qhUDaRF1LiEYjyLdvKPUK9CNH81gsb8Ja4UEw=.2a1eab1a-4b88-4d41-85b4-8ffedb39cdc7@github.com>
 <ZpgnqEdpEAzq3oLh7z8Kcb0qF0geRqpY4tFlLId1OpM=.b50e1c35-1906-4b92-ac97-e35c6b5f417e@github.com>
 <KbEQAjBnP0qaE1sUdQ9vvbMY-wJi8iIm9q6gkrGiXkM=.eafef21d-0559-4987-b9d0-b4dcd252c32a@github.com>
 <L7M7no8PrSvC4dYWryuET3udnSRQRYSQ5t35v-wVJAA=.57602d75-5ac9-447d-8da8-fc74d0ad6028@github.com>
 <5lpGRmoZ4hfUSSbMCuLT8LmsyTPXkSeBBfmCXdiIdyA=.ea9769b2-6cb1-4705-b1eb-c0c7ffb878ef@github.com>
Message-ID: <AYBY6-Y_fLqro94qlnYdK85t7u4bF7LdimuX7HJj6Mo=.54d43833-ea13-4673-9854-59892e2cb52c@github.com>

On Fri, 2 Jul 2021 08:58:35 GMT, Peter Levart <plevart at openjdk.org> wrote:

>> Well, "determine" seems to have both meanings:
>> https://www.google.com/search?q=determine
>> So by the 2nd meaning, it is good.
>
> ... and considering the "Schr?dinger's cat", even the 1st interpretation is correct. You can't know whether the cat is dead or not until you "determine" it's death. This does not mean that you killed it though.

I think "determine" sounds right to me.  "detect" is another possibility but does not apply well in "this effort" as the subject.   This is another way to explain it.

During the execution, there are a number of reachability decision points.  At each reachability decision point, the references are checked. GC determines if the reachability of the referent has changed to the value corresponding to the type of the reference (softly weakly, or phantom reachable), then it clears and enqueues the reference.

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

PR: https://git.openjdk.java.net/jdk17/pull/183

From lance.andersen at oracle.com  Fri Jul  2 17:16:39 2021
From: lance.andersen at oracle.com (Lance Andersen)
Date: Fri, 2 Jul 2021 17:16:39 +0000
Subject: RFR: 8251329: (zipfs) Files.walkFileTree walks infinitely if zip
 has dir named "." inside [v4]
In-Reply-To: <C30F6CF9-02F3-4604-8976-2425B8568326@oracle.com>
References: <H5Dy39I78mG6FE2N9U5vZnEhGI2zcIaxGvJ8uZBCGM0=.f3ba4976-f985-4002-87f3-da234b3c402d@github.com>
 <FWKKv49jcPmyN0fr_GVK0Sz3DceDPXRF724C45esjF8=.c86aa8c4-8fbd-4b76-90fa-a906323aae8a@github.com>
 <FS4dG8muHl9vXW_eryRBZkDsRiquNnNOCLBlwsNVXeU=.1cecfec8-6a90-4cd4-a796-249c9b8c3110@github.com>
 <3d068121-9800-972c-dbd6-cd46b25f6dde@gmail.com>
 <C30F6CF9-02F3-4604-8976-2425B8568326@oracle.com>
Message-ID: <A7AB0C56-5B42-44E3-89DD-C425F46FF84B@oracle.com>



On Jul 2, 2021, at 12:13 PM, Lance Andersen <lance.andersen at oracle.com<mailto:lance.andersen at oracle.com>> wrote:



On Jul 2, 2021, at 8:08 AM, Jaikiran Pai <jai.forums2013 at gmail.com<mailto:jai.forums2013 at gmail.com>> wrote:

Hello Lance,

On 02/07/21 4:42 pm, Lance Andersen wrote:
Hi Jaikiran,

Consider:


        try (var os = Files.newOutputStream(ZIPFILE);
             ZipOutputStream zos = new ZipOutputStream(os)) {
            zos.putNextEntry(new ZipEntry("../Hello.txt"));
            zos.write("Hello World".getBytes(StandardCharsets.UTF_8));
        }


With your proposed fix, you will only return "/" when you walk the the Zip file and we should also return "/Hello.txt"

Thank you for noticing this issue in my change and bringing this up. I have a question around this use case. Please consider a small variation to your example as below:

try (var os = Files.newOutputStream(ZIPFILE);
             ZipOutputStream zos = new ZipOutputStream(os)) {
            zos.putNextEntry(new ZipEntry("../Hello.txt"));
            zos.write("Hello World".getBytes(StandardCharsets.UTF_8));
            zos.closeEntry();
            zos.putNextEntry(new ZipEntry("/Hello.txt"));
            zos.write("Bye bye".getBytes(StandardCharsets.UTF_8));
            zos.closeEntry();

        }

Notice that I now have a zip/jar which has 2 differently named entries "../Hello.txt" and "/Hello.txt". This creates the archive without any issues and those 2 entries are noted in its listing. Now assuming someone walks over this jar using the ZipFileSystem, starting at root ("/"), what should be the expected output? The path(s) returned will end up being "/" and "/Hello.txt" but which resource is expected to be served in this case? The one which has "Hello World" in it or the one which has "Bye bye"? This example can be extended a bit more by introducing a "./Hello.txt", in the jar, with yet another different content in that entry. Is there some specification for this that I can check and adapt the test case accordingly?


Consider Hello.zip created via:


try (var os = Files.newOutputStream(Path.of("Hello.zip"));
     ZipOutputStream zos = new ZipOutputStream(os)) {
    zos.putNextEntry(new ZipEntry("../Hello.txt"));
    zos.write("Hello".getBytes(StandardCharsets.UTF_8));
    zos.putNextEntry(new ZipEntry("Hello.txt"));
    zos.write("Another Hello".getBytes(StandardCharsets.UTF_8));

}

Winzip does not handle this case well.

InfoZip will :

-------------
unzip ../Hello.zip
Archive:  ../Hello.zip
warning:  skipped "../" path component(s) in ../Hello.txt
  inflating: Hello.txt
replace Hello.txt? [y]es, [n]o, [A]ll, [N]one, [r]ename: r
new name: foo.txt
  inflating: foo.txt
% ls
Hello.txt       foo.txt
 % cat Hello.txt
Hello
 % cat foo.txt
Another Hello
%
????????

This scenario is not well covered in the Zip spec, so we can do what we think is best.

 Personally, I am OK with resolving the path.  The odds of having multiple relative paths to the same file would be a mistake in creating the Zip.

That being said, if we want to follow Alan?s suggestion and throw an Exception, I am OK with that as well.

Either way, we currently cannot access the file via Zip FS due to the call to ZipPath::getResolvedPath() for all access and the path is only normalized when the Inodes are created.

Alan, do you have a specific preference?

One more datapoint

Consider:


try (FileSystem zipfs =
             FileSystems.newFileSystem(Path.of("ZipFSHello.zip"), Map.of("create", "true"))) {
    Files.writeString(zipfs.getPath("HelloZipfs.txt"), "Hello");
    Files.writeString(zipfs.getPath("../HelloZipfs.txt"), "A ZipFS Hello");

}


The above will result in a Zip with a single entry of ?HelloZipfs.txt? and a value of ?A ZipFS Hello?

As mentioned in my previous comment, this is due to the use of ZipPath::getResolvedPath() which brings me back to the suggestion of doing the same when we create the Inodes given this is an a virtual FS.

HTH

Best
Lance


-Jaikiran




<oracle_sig_logo.gif>



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

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



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




From naoto at openjdk.java.net  Fri Jul  2 17:15:51 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 2 Jul 2021 17:15:51 GMT
Subject: [jdk17] RFR: 6766844: ByteArrayInputStream#read with a byte array
 of length 0 not consistent with InputStream when at EOF [v2]
In-Reply-To: <MZ3-8xBveOrZ2SZKqevKuJ-dufr_bs9ZrfkLq4kxBA4=.d1779658-8e77-4c2b-87b0-0baafe1efb7a@github.com>
References: <8nNGNaJvrmtiLTlJcIazAl5J7iVsBxbhEeAItADAoKc=.824db13a-589c-421e-8595-01ac4e5c27bd@github.com>
 <MZ3-8xBveOrZ2SZKqevKuJ-dufr_bs9ZrfkLq4kxBA4=.d1779658-8e77-4c2b-87b0-0baafe1efb7a@github.com>
Message-ID: <bFh2JLUvOrA14OQUL-1FFR1a2IUmSKh7kAQsZXMlfVI=.39dc466f-c7e7-46d6-9169-aa245b6a0f39@github.com>

On Fri, 2 Jul 2021 16:58:18 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Modify the specification of `java.io.ByteArrayInputStream#read(byte[],int,int)` to indicate that `-1` is returned instead of `0` when the stream is at its end and the third parameter, `len`, is zero.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   6766844: Correct error messages in test

Marked as reviewed by naoto (Reviewer).

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

PR: https://git.openjdk.java.net/jdk17/pull/189

From lancea at openjdk.java.net  Fri Jul  2 17:21:53 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Fri, 2 Jul 2021 17:21:53 GMT
Subject: [jdk17] RFR: 6766844: ByteArrayInputStream#read with a byte array
 of length 0 not consistent with InputStream when at EOF [v2]
In-Reply-To: <MZ3-8xBveOrZ2SZKqevKuJ-dufr_bs9ZrfkLq4kxBA4=.d1779658-8e77-4c2b-87b0-0baafe1efb7a@github.com>
References: <8nNGNaJvrmtiLTlJcIazAl5J7iVsBxbhEeAItADAoKc=.824db13a-589c-421e-8595-01ac4e5c27bd@github.com>
 <MZ3-8xBveOrZ2SZKqevKuJ-dufr_bs9ZrfkLq4kxBA4=.d1779658-8e77-4c2b-87b0-0baafe1efb7a@github.com>
Message-ID: <sht8rmzoiJL28V_98bRdFu8CCHKtLc3nJpLcYdGPMx0=.808fcdfc-0651-4d1c-b55b-9eeea8d36d70@github.com>

On Fri, 2 Jul 2021 16:58:18 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Modify the specification of `java.io.ByteArrayInputStream#read(byte[],int,int)` to indicate that `-1` is returned instead of `0` when the stream is at its end and the third parameter, `len`, is zero.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   6766844: Correct error messages in test

Marked as reviewed by lancea (Reviewer).

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

PR: https://git.openjdk.java.net/jdk17/pull/189

From darcy at openjdk.java.net  Fri Jul  2 17:22:53 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Fri, 2 Jul 2021 17:22:53 GMT
Subject: RFR: 8188046: java.lang.Math.mutliplyHigh does not run in
 constant time
In-Reply-To: <-XW-J7GWnt6RQmbuvQ1bApn7qC2hNpW4bspCOCG8KRw=.4a315407-7617-47a7-993f-fc0c8e906a0f@github.com>
References: <-XW-J7GWnt6RQmbuvQ1bApn7qC2hNpW4bspCOCG8KRw=.4a315407-7617-47a7-993f-fc0c8e906a0f@github.com>
Message-ID: <ES_UoN6g2tIir_KorXR4akzNhsYO2c0ROfNOratg5Kg=.676052da-74f9-4928-9006-17b0d3437c46@github.com>

On Thu, 1 Jul 2021 23:46:00 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Please consider this proposal to remove the fast path in `java.lang.Math.multiplyHigh()` the small performance improvement of which is eclipsed by the branch penalty.

Marked as reviewed by darcy (Reviewer).

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

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

From joehw at openjdk.java.net  Fri Jul  2 17:30:52 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Fri, 2 Jul 2021 17:30:52 GMT
Subject: [jdk17] RFR: 6766844: ByteArrayInputStream#read with a byte array
 of length 0 not consistent with InputStream when at EOF [v2]
In-Reply-To: <MZ3-8xBveOrZ2SZKqevKuJ-dufr_bs9ZrfkLq4kxBA4=.d1779658-8e77-4c2b-87b0-0baafe1efb7a@github.com>
References: <8nNGNaJvrmtiLTlJcIazAl5J7iVsBxbhEeAItADAoKc=.824db13a-589c-421e-8595-01ac4e5c27bd@github.com>
 <MZ3-8xBveOrZ2SZKqevKuJ-dufr_bs9ZrfkLq4kxBA4=.d1779658-8e77-4c2b-87b0-0baafe1efb7a@github.com>
Message-ID: <aJJaUdYzv9Rz7QuLPRCOyckIeEoAUWj5sJMX_xSkmr4=.fa8e866d-c636-49b8-9b3e-e1619bc879c0@github.com>

On Fri, 2 Jul 2021 16:58:18 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Modify the specification of `java.io.ByteArrayInputStream#read(byte[],int,int)` to indicate that `-1` is returned instead of `0` when the stream is at its end and the third parameter, `len`, is zero.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   6766844: Correct error messages in test

src/java.base/share/classes/java/io/ByteArrayInputStream.java line 161:

> 159:      * Unlike the {@link InputStream#read(byte[],int,int) overridden method}
> 160:      * of {@code InputStream}, this method returns {@code -1} instead of zero
> 161:      * if the end of the stream has been reached and {@code len == 0}.

The statement "return -1 if the end of the stream has been reached and len == 0" gives an impression that it requires both conditions to be met: end of the stream && len==0,  but the tests show -1 is expected if len == 0 without an attempt to read the stream. 

The overridden method stated that "If len is zero, then no bytes are read and 0 is returned", the above note looks like was meant for this statement since the overridden method also return -1 if the stream is at end of file.

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

PR: https://git.openjdk.java.net/jdk17/pull/189

From bpb at openjdk.java.net  Fri Jul  2 17:42:51 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Fri, 2 Jul 2021 17:42:51 GMT
Subject: [jdk17] RFR: 6766844: ByteArrayInputStream#read with a byte array
 of length 0 not consistent with InputStream when at EOF [v2]
In-Reply-To: <aJJaUdYzv9Rz7QuLPRCOyckIeEoAUWj5sJMX_xSkmr4=.fa8e866d-c636-49b8-9b3e-e1619bc879c0@github.com>
References: <8nNGNaJvrmtiLTlJcIazAl5J7iVsBxbhEeAItADAoKc=.824db13a-589c-421e-8595-01ac4e5c27bd@github.com>
 <MZ3-8xBveOrZ2SZKqevKuJ-dufr_bs9ZrfkLq4kxBA4=.d1779658-8e77-4c2b-87b0-0baafe1efb7a@github.com>
 <aJJaUdYzv9Rz7QuLPRCOyckIeEoAUWj5sJMX_xSkmr4=.fa8e866d-c636-49b8-9b3e-e1619bc879c0@github.com>
Message-ID: <MT65cu36cTy8gvXiZkl4n1lIHnQIkz0jDdHxgZdqo10=.568b6083-8f03-4049-98e3-c6abd74b9cc1@github.com>

On Fri, 2 Jul 2021 17:27:34 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   6766844: Correct error messages in test
>
> src/java.base/share/classes/java/io/ByteArrayInputStream.java line 161:
> 
>> 159:      * Unlike the {@link InputStream#read(byte[],int,int) overridden method}
>> 160:      * of {@code InputStream}, this method returns {@code -1} instead of zero
>> 161:      * if the end of the stream has been reached and {@code len == 0}.
> 
> The statement "return -1 if the end of the stream has been reached and len == 0" gives an impression that it requires both conditions to be met: end of the stream && len==0,  but the tests show -1 is expected if len == 0 without an attempt to read the stream. 
> 
> The overridden method stated that "If len is zero, then no bytes are read and 0 is returned", the above note looks like was meant for this statement since the overridden method also return -1 if the stream is at end of file.

Both conditions of the statement are intended to be met. If the stream is at its end then

        if (pos >= count) {
            return -1;
        }

will cause `-1` to be returned because at end of stream the condition `pos >= count` is met.

The overridden method always returns `0` if `len == 0`.:


    public int read(byte b[], int off, int len) throws IOException {
        Objects.checkFromIndexSize(off, len, b.length);
        if (len == 0) {
            return 0;
        }

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

PR: https://git.openjdk.java.net/jdk17/pull/189

From amaembo at gmail.com  Fri Jul  2 17:59:14 2021
From: amaembo at gmail.com (Tagir Valeev)
Date: Sat, 3 Jul 2021 00:59:14 +0700
Subject: Methods removeFirstIf in Collection and skipFirst in Stream
In-Reply-To: <VE1P191MB087944028093CF0865C7F0B2F41F9@VE1P191MB0879.EURP191.PROD.OUTLOOK.COM>
References: <VE1P191MB0879B9C24D3276F4325FA837F41F9@VE1P191MB0879.EURP191.PROD.OUTLOOK.COM>
 <VE1P191MB087944028093CF0865C7F0B2F41F9@VE1P191MB0879.EURP191.PROD.OUTLOOK.COM>
Message-ID: <CAE+3fjbvyRmc9m6p4OFXYakDOqv-or6e_T7MGU6SuL9c5nYAgQ@mail.gmail.com>

Hello!

It's unclear why one might need methods like this. Could you please provide
any real life use cases when such methods could be useful? Thanks.

With best regards,
Tagir Valeev.

??, 2 ???. 2021 ?., 21:28 Alberto Otero Rodr?guez <albest512 at hotmail.com>:

> Sorry for the links, the methods would be:
>
> 1) In Collection:
>            default boolean removeFirstIf?(Predicate<? super E<
> https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/util/Collection.html>>
> filter)
>
> 2) In Stream:
>            Stream<T> skipFirst(Predicate<? super T<
> https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/util/stream/Stream.html>>
> predicate)
> ________________________________
> De: Alberto Otero Rodr?guez
> Enviado: viernes, 2 de julio de 2021 16:22
> Para: core-libs-dev at openjdk.java.net <core-libs-dev at openjdk.java.net>
> Asunto: Methods removeFirstIf in Collection and skipFirst in Stream
>
> Hi,
>
> I think it would be interesting adding the following methods:
>
> 1) In Collection:
>            default boolean removeFirstIf?(Predicate<
> https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/util/function/Predicate.html><?
> super E<
> https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/util/Collection.html>>
> filter)
>
> 2) In Stream:
>            Stream<
> https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/util/stream/Stream.html
> ><T<
> https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/util/stream/Stream.html>>
> skipFirst(Predicate<
> https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/util/function/Predicate.html><?
> super T<
> https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/util/stream/Stream.html>>
> predicate)
>
> The purpose of both methods would be the same. Deleting the first element
> in the collection that fulfills the predicate.
>
> This could be useful in collections/streams with no duplicate elements
> where performance would be better than using removeIf from Collection of
> filter from Stream.
>
> Regards,
>
> Alberto.
>

From darcy at openjdk.java.net  Fri Jul  2 18:11:51 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Fri, 2 Jul 2021 18:11:51 GMT
Subject: RFR: 8188044: We need Math.unsignedMultiplyHigh [v4]
In-Reply-To: <7_2wD0p9XFCsTCtzGQthrAz8qgbOPCAMpVqvkLDxWIA=.6a9bc720-bb4b-4b3c-b105-dacc2701190e@github.com>
References: <23ldlDveuxh3c09WTFw5rQTJTAGd-KQHdo5K_KTtFSU=.39e4ccfb-e56e-4473-bee8-3c272cc94771@github.com>
 <7_2wD0p9XFCsTCtzGQthrAz8qgbOPCAMpVqvkLDxWIA=.6a9bc720-bb4b-4b3c-b105-dacc2701190e@github.com>
Message-ID: <78ZVWASlOMndXDagcmpTE_YmRSKBplYb3p8QjuVAtHk=.36b01695-13ba-454c-b6dd-8126dfa12035@github.com>

On Fri, 2 Jul 2021 16:41:16 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Please consider this proposal to add a method `unsignedMultiplyHigh(long,long)` to each of `java.lang.Math` and `java.lang.StrictMath`.
>
> Brian Burkhalter 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 darcy (Reviewer).

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

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

From bpb at openjdk.java.net  Fri Jul  2 18:18:53 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Fri, 2 Jul 2021 18:18:53 GMT
Subject: Integrated: 8188044: We need Math.unsignedMultiplyHigh
In-Reply-To: <23ldlDveuxh3c09WTFw5rQTJTAGd-KQHdo5K_KTtFSU=.39e4ccfb-e56e-4473-bee8-3c272cc94771@github.com>
References: <23ldlDveuxh3c09WTFw5rQTJTAGd-KQHdo5K_KTtFSU=.39e4ccfb-e56e-4473-bee8-3c272cc94771@github.com>
Message-ID: <xmXO9IG5IvIew5ZBfeDn6LFjyjex_D1eC-YPGAp1204=.517d54b8-12a6-45f1-9ce6-5de2f96bbaf8@github.com>

On Wed, 30 Jun 2021 23:13:06 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Please consider this proposal to add a method `unsignedMultiplyHigh(long,long)` to each of `java.lang.Math` and `java.lang.StrictMath`.

This pull request has now been integrated.

Changeset: ca4bea46
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ca4bea466581217cae2278c98c0fdc568c043818
Stats:     81 lines in 3 files changed: 71 ins; 0 del; 10 mod

8188044: We need Math.unsignedMultiplyHigh

Reviewed-by: rriggs, aph, darcy

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

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

From bpb at openjdk.java.net  Fri Jul  2 18:24:54 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Fri, 2 Jul 2021 18:24:54 GMT
Subject: Integrated: 8188046: java.lang.Math.mutliplyHigh does not run in
 constant time
In-Reply-To: <-XW-J7GWnt6RQmbuvQ1bApn7qC2hNpW4bspCOCG8KRw=.4a315407-7617-47a7-993f-fc0c8e906a0f@github.com>
References: <-XW-J7GWnt6RQmbuvQ1bApn7qC2hNpW4bspCOCG8KRw=.4a315407-7617-47a7-993f-fc0c8e906a0f@github.com>
Message-ID: <EF6kJFzCwcEs0Om3pdJHX6xxRCzTHNzJTIf7WU2-0Ic=.a8f628ec-4072-4cb5-a562-5b6938432b3e@github.com>

On Thu, 1 Jul 2021 23:46:00 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Please consider this proposal to remove the fast path in `java.lang.Math.multiplyHigh()` the small performance improvement of which is eclipsed by the branch penalty.

This pull request has now been integrated.

Changeset: cb795893
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/cb795893be8e6dcf725d8022aca16f657d3cc03c
Stats:     25 lines in 1 file changed: 0 ins; 11 del; 14 mod

8188046: java.lang.Math.mutliplyHigh does not run in constant time

Reviewed-by: rriggs, darcy

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

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

From Alan.Bateman at oracle.com  Fri Jul  2 18:29:19 2021
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 2 Jul 2021 19:29:19 +0100
Subject: RFR: 8251329: (zipfs) Files.walkFileTree walks infinitely if zip
 has dir named "." inside [v4]
In-Reply-To: <A7AB0C56-5B42-44E3-89DD-C425F46FF84B@oracle.com>
References: <H5Dy39I78mG6FE2N9U5vZnEhGI2zcIaxGvJ8uZBCGM0=.f3ba4976-f985-4002-87f3-da234b3c402d@github.com>
 <FWKKv49jcPmyN0fr_GVK0Sz3DceDPXRF724C45esjF8=.c86aa8c4-8fbd-4b76-90fa-a906323aae8a@github.com>
 <FS4dG8muHl9vXW_eryRBZkDsRiquNnNOCLBlwsNVXeU=.1cecfec8-6a90-4cd4-a796-249c9b8c3110@github.com>
 <3d068121-9800-972c-dbd6-cd46b25f6dde@gmail.com>
 <C30F6CF9-02F3-4604-8976-2425B8568326@oracle.com>
 <A7AB0C56-5B42-44E3-89DD-C425F46FF84B@oracle.com>
Message-ID: <d3b474af-b9d4-b8c0-79aa-993e55d679f1@oracle.com>

On 02/07/2021 18:16, Lance Andersen wrote:
> :
>
> That being said, if we want to follow Alan?s suggestion and throw an Exception, I am OK with that as well.
>
> Either way, we currently cannot access the file via Zip FS due to the call to ZipPath::getResolvedPath() for all access and the path is only normalized when the Inodes are created.
>
> Alan, do you have a specific preference?
>
Not yet but if you tolerate these hostile entries then it means that all 
access with relative paths containing a "." or ".." element will be 
ambiguous. It will break relativize, normalize, and maybe other path 
operations. I assume it will break copy/move operations when the source 
is in a zip file and the target is in a non-zip file. I suspect it would 
also need to encode file names when open zip file for read/write access 
because the native file system is used for caching.

-Alan

From joehw at openjdk.java.net  Fri Jul  2 18:46:53 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Fri, 2 Jul 2021 18:46:53 GMT
Subject: [jdk17] RFR: 6766844: ByteArrayInputStream#read with a byte array
 of length 0 not consistent with InputStream when at EOF [v2]
In-Reply-To: <MT65cu36cTy8gvXiZkl4n1lIHnQIkz0jDdHxgZdqo10=.568b6083-8f03-4049-98e3-c6abd74b9cc1@github.com>
References: <8nNGNaJvrmtiLTlJcIazAl5J7iVsBxbhEeAItADAoKc=.824db13a-589c-421e-8595-01ac4e5c27bd@github.com>
 <MZ3-8xBveOrZ2SZKqevKuJ-dufr_bs9ZrfkLq4kxBA4=.d1779658-8e77-4c2b-87b0-0baafe1efb7a@github.com>
 <aJJaUdYzv9Rz7QuLPRCOyckIeEoAUWj5sJMX_xSkmr4=.fa8e866d-c636-49b8-9b3e-e1619bc879c0@github.com>
 <MT65cu36cTy8gvXiZkl4n1lIHnQIkz0jDdHxgZdqo10=.568b6083-8f03-4049-98e3-c6abd74b9cc1@github.com>
Message-ID: <AapXw3qPDA7hh4uK3xSO8wOLwYTVWvGxdGmwxkp-ya8=.bbe7630e-4a41-4088-804c-3b97c4770e22@github.com>

On Fri, 2 Jul 2021 17:40:08 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/ByteArrayInputStream.java line 161:
>> 
>>> 159:      * Unlike the {@link InputStream#read(byte[],int,int) overridden method}
>>> 160:      * of {@code InputStream}, this method returns {@code -1} instead of zero
>>> 161:      * if the end of the stream has been reached and {@code len == 0}.
>> 
>> The statement "return -1 if the end of the stream has been reached and len == 0" gives an impression that it requires both conditions to be met: end of the stream && len==0,  but the tests show -1 is expected if len == 0 without an attempt to read the stream. 
>> 
>> The overridden method stated that "If len is zero, then no bytes are read and 0 is returned", the above note looks like was meant for this statement since the overridden method also return -1 if the stream is at end of file.
>
> Both conditions of the statement are intended to be met. If the stream is at its end then
> 
>         if (pos >= count) {
>             return -1;
>         }
> 
> will cause `-1` to be returned because at end of stream the condition `pos >= count` is met.
> 
> The overridden method always returns `0` if `len == 0`.:
> 
> 
>     public int read(byte b[], int off, int len) throws IOException {
>         Objects.checkFromIndexSize(off, len, b.length);
>         if (len == 0) {
>             return 0;
>         }

Right. I understand. The intention was, unlike the overridden method that returns 0 if len == 0 and -1 if at the end of the stream, this method returns -1 in both cases. A careful reader, after comparing both methods, would understand correctly that the difference is in the case of "len==0". I'm fine if you think this is good enough. Just a thought though that the statement could be interpreted as if both conditions need to be met at the same time (if "and" is taken as "&&", e.g. if (pos>==count && len==0) ). 

Something like the following might be clearer?
     * Unlike the {@link InputStream#read(byte[],int,int) overridden method}
     * of {@code InputStream} that returns {@code -1} if the end of the stream
     * has been reached and {@code 0} if {@code len == 0}, this method returns
     * {@code -1} in both cases.

Just my 2 cents.

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

PR: https://git.openjdk.java.net/jdk17/pull/189

From albest512 at hotmail.com  Fri Jul  2 19:10:54 2021
From: albest512 at hotmail.com (=?utf-8?B?QWxiZXJ0byBPdGVybyBSb2Ryw61ndWV6?=)
Date: Fri, 2 Jul 2021 19:10:54 +0000
Subject: Methods removeFirstIf in Collection and skipFirst in Stream
In-Reply-To: <CAE+3fjbvyRmc9m6p4OFXYakDOqv-or6e_T7MGU6SuL9c5nYAgQ@mail.gmail.com>
References: <VE1P191MB0879B9C24D3276F4325FA837F41F9@VE1P191MB0879.EURP191.PROD.OUTLOOK.COM>
 <VE1P191MB087944028093CF0865C7F0B2F41F9@VE1P191MB0879.EURP191.PROD.OUTLOOK.COM>,
 <CAE+3fjbvyRmc9m6p4OFXYakDOqv-or6e_T7MGU6SuL9c5nYAgQ@mail.gmail.com>
Message-ID: <VE1P191MB08791BC139115FD68BBC4091F41F9@VE1P191MB0879.EURP191.PROD.OUTLOOK.COM>

Hi,

In my case, I have a list of entities related to another entity. In that list obviously there weren't repeated entities (entities with the same id). And I have the id of an entity to be removed from that list.

So, I have the following alternatives which are pretty inefficient:

1) entityList.removeIf(entity -> entityIdToRemove.equals(entity.getId()));

2) entityList = entityList.stream()
                .filter(entity -> !entityIdToRemove.equals(entity.getId()))
                .collect(Collectors.toList());

And I have this other alternative which is too much code:

    Iterator<Entity> iterator = entityList.iterator();
    while (iterator.hasNext()) {
        Entity entity = iterator.next();
        if(entityIdToRemove.equals(entity.getId())) {
            itr.remove();
            break;
        }
    }

So, what I propose would be something like:

1) entityList.removeFirstIf(entity -> entityIdToRemove.equals(entity.getId()));

2) entityList = entityList.stream()
                .skipFirst(entity -> entityIdToRemove.equals(entity.getId()))
                .collect(Collectors.toList());

Regards,

Alberto.
________________________________
De: Tagir Valeev <amaembo at gmail.com>
Enviado: viernes, 2 de julio de 2021 19:59
Para: Alberto Otero Rodr?guez <albest512 at hotmail.com>
Cc: core-libs-dev <core-libs-dev at openjdk.java.net>
Asunto: Re: Methods removeFirstIf in Collection and skipFirst in Stream

Hello!

It's unclear why one might need methods like this. Could you please provide any real life use cases when such methods could be useful? Thanks.

With best regards,
Tagir Valeev.

??, 2 ???. 2021 ?., 21:28 Alberto Otero Rodr?guez <albest512 at hotmail.com<mailto:albest512 at hotmail.com>>:
Sorry for the links, the methods would be:

1) In Collection:
           default boolean removeFirstIf?(Predicate<? super E<https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/util/Collection.html>> filter)

2) In Stream:
           Stream<T> skipFirst(Predicate<? super T<https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/util/stream/Stream.html>> predicate)
________________________________
De: Alberto Otero Rodr?guez
Enviado: viernes, 2 de julio de 2021 16:22
Para: core-libs-dev at openjdk.java.net<mailto:core-libs-dev at openjdk.java.net> <core-libs-dev at openjdk.java.net<mailto:core-libs-dev at openjdk.java.net>>
Asunto: Methods removeFirstIf in Collection and skipFirst in Stream

Hi,

I think it would be interesting adding the following methods:

1) In Collection:
           default boolean removeFirstIf?(Predicate<https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/util/function/Predicate.html><? super E<https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/util/Collection.html>> filter)

2) In Stream:
           Stream<https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/util/stream/Stream.html><T<https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/util/stream/Stream.html>> skipFirst(Predicate<https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/util/function/Predicate.html><? super T<https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/util/stream/Stream.html>> predicate)

The purpose of both methods would be the same. Deleting the first element in the collection that fulfills the predicate.

This could be useful in collections/streams with no duplicate elements where performance would be better than using removeIf from Collection of filter from Stream.

Regards,

Alberto.

From bpb at openjdk.java.net  Fri Jul  2 19:10:51 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Fri, 2 Jul 2021 19:10:51 GMT
Subject: [jdk17] RFR: 6766844: ByteArrayInputStream#read with a byte array
 of length 0 not consistent with InputStream when at EOF [v2]
In-Reply-To: <AapXw3qPDA7hh4uK3xSO8wOLwYTVWvGxdGmwxkp-ya8=.bbe7630e-4a41-4088-804c-3b97c4770e22@github.com>
References: <8nNGNaJvrmtiLTlJcIazAl5J7iVsBxbhEeAItADAoKc=.824db13a-589c-421e-8595-01ac4e5c27bd@github.com>
 <MZ3-8xBveOrZ2SZKqevKuJ-dufr_bs9ZrfkLq4kxBA4=.d1779658-8e77-4c2b-87b0-0baafe1efb7a@github.com>
 <aJJaUdYzv9Rz7QuLPRCOyckIeEoAUWj5sJMX_xSkmr4=.fa8e866d-c636-49b8-9b3e-e1619bc879c0@github.com>
 <MT65cu36cTy8gvXiZkl4n1lIHnQIkz0jDdHxgZdqo10=.568b6083-8f03-4049-98e3-c6abd74b9cc1@github.com>
 <AapXw3qPDA7hh4uK3xSO8wOLwYTVWvGxdGmwxkp-ya8=.bbe7630e-4a41-4088-804c-3b97c4770e22@github.com>
Message-ID: <X8Og4OtbQYVoP3EDoIPSDn6h4DFAOZh4Y21BwUWB8qg=.2c0cc083-592a-4da3-9e9f-cb8c48d8f146@github.com>

On Fri, 2 Jul 2021 18:43:36 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Both conditions of the statement are intended to be met. If the stream is at its end then
>> 
>>         if (pos >= count) {
>>             return -1;
>>         }
>> 
>> will cause `-1` to be returned because at end of stream the condition `pos >= count` is met.
>> 
>> The overridden method always returns `0` if `len == 0`.:
>> 
>> 
>>     public int read(byte b[], int off, int len) throws IOException {
>>         Objects.checkFromIndexSize(off, len, b.length);
>>         if (len == 0) {
>>             return 0;
>>         }
>
> Right. I understand. The intention was, unlike the overridden method that returns 0 if len == 0 and -1 if at the end of the stream, this method returns -1 in both cases. A careful reader, after comparing both methods, would understand correctly that the difference is in the case of "len==0". I'm fine if you think this is good enough. Just a thought though that the statement could be interpreted as if both conditions need to be met at the same time (if "and" is taken as "&&", e.g. if (pos>==count && len==0) ). 
> 
> Something like the following might be clearer?
>      * Unlike the {@link InputStream#read(byte[],int,int) overridden method}
>      * of {@code InputStream} that returns {@code -1} if the end of the stream
>      * has been reached and {@code 0} if {@code len == 0}, this method returns
>      * {@code -1} in both cases.
> 
> Just my 2 cents.

Thanks for the suggestion. I am happy with it as is, but I'll hold off integrating it for now and rethink it later.

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

PR: https://git.openjdk.java.net/jdk17/pull/189

From joehw at openjdk.java.net  Fri Jul  2 19:39:51 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Fri, 2 Jul 2021 19:39:51 GMT
Subject: [jdk17] RFR: 6766844: ByteArrayInputStream#read with a byte array
 of length 0 not consistent with InputStream when at EOF [v2]
In-Reply-To: <MZ3-8xBveOrZ2SZKqevKuJ-dufr_bs9ZrfkLq4kxBA4=.d1779658-8e77-4c2b-87b0-0baafe1efb7a@github.com>
References: <8nNGNaJvrmtiLTlJcIazAl5J7iVsBxbhEeAItADAoKc=.824db13a-589c-421e-8595-01ac4e5c27bd@github.com>
 <MZ3-8xBveOrZ2SZKqevKuJ-dufr_bs9ZrfkLq4kxBA4=.d1779658-8e77-4c2b-87b0-0baafe1efb7a@github.com>
Message-ID: <cUJ28ICMsGE2XE2JvR1td5sM56foNdt0qC5tRTSDFFQ=.66828197-5ae2-49c3-992b-7f6682bd0723@github.com>

On Fri, 2 Jul 2021 16:58:18 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Modify the specification of `java.io.ByteArrayInputStream#read(byte[],int,int)` to indicate that `-1` is returned instead of `0` when the stream is at its end and the third parameter, `len`, is zero.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   6766844: Correct error messages in test

Marked as reviewed by joehw (Reviewer).

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

PR: https://git.openjdk.java.net/jdk17/pull/189

From joehw at openjdk.java.net  Fri Jul  2 19:39:52 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Fri, 2 Jul 2021 19:39:52 GMT
Subject: [jdk17] RFR: 6766844: ByteArrayInputStream#read with a byte array
 of length 0 not consistent with InputStream when at EOF [v2]
In-Reply-To: <X8Og4OtbQYVoP3EDoIPSDn6h4DFAOZh4Y21BwUWB8qg=.2c0cc083-592a-4da3-9e9f-cb8c48d8f146@github.com>
References: <8nNGNaJvrmtiLTlJcIazAl5J7iVsBxbhEeAItADAoKc=.824db13a-589c-421e-8595-01ac4e5c27bd@github.com>
 <MZ3-8xBveOrZ2SZKqevKuJ-dufr_bs9ZrfkLq4kxBA4=.d1779658-8e77-4c2b-87b0-0baafe1efb7a@github.com>
 <aJJaUdYzv9Rz7QuLPRCOyckIeEoAUWj5sJMX_xSkmr4=.fa8e866d-c636-49b8-9b3e-e1619bc879c0@github.com>
 <MT65cu36cTy8gvXiZkl4n1lIHnQIkz0jDdHxgZdqo10=.568b6083-8f03-4049-98e3-c6abd74b9cc1@github.com>
 <AapXw3qPDA7hh4uK3xSO8wOLwYTVWvGxdGmwxkp-ya8=.bbe7630e-4a41-4088-804c-3b97c4770e22@github.com>
 <X8Og4OtbQYVoP3EDoIPSDn6h4DFAOZh4Y21BwUWB8qg=.2c0cc083-592a-4da3-9e9f-cb8c48d8f146@github.com>
Message-ID: <imuqrTpf5AqkRpBU_KuuxSU5r9w-VBlqsEwcaY1szPM=.1d49f5b8-c629-4001-8153-990399b0fc04@github.com>

On Fri, 2 Jul 2021 19:08:09 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Right. I understand. The intention was, unlike the overridden method that returns 0 if len == 0 and -1 if at the end of the stream, this method returns -1 in both cases. A careful reader, after comparing both methods, would understand correctly that the difference is in the case of "len==0". I'm fine if you think this is good enough. Just a thought though that the statement could be interpreted as if both conditions need to be met at the same time (if "and" is taken as "&&", e.g. if (pos>==count && len==0) ). 
>> 
>> Something like the following might be clearer?
>>      * Unlike the {@link InputStream#read(byte[],int,int) overridden method}
>>      * of {@code InputStream} that returns {@code -1} if the end of the stream
>>      * has been reached and {@code 0} if {@code len == 0}, this method returns
>>      * {@code -1} in both cases.
>> 
>> Just my 2 cents.
>
> Thanks for the suggestion. I am happy with it as is, but I'll hold off integrating it for now and rethink it later.

Ok, good to know. Have a great weekend!

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

PR: https://git.openjdk.java.net/jdk17/pull/189

From jwilhelm at openjdk.java.net  Fri Jul  2 19:44:18 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Fri, 2 Jul 2021 19:44:18 GMT
Subject: RFR: Merge jdk17
Message-ID: <htFLpjN9iJUwqIcueYZ_aB_NcPj9lTd03k2b6LePd5c=.f4b96ca5-5e34-484b-b386-01bfb268e00d@github.com>

Forwardport JDK 17 -> JDK 18

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

Commit messages:
 - Merge
 - 8269768: JFR Terminology Refresh
 - 8269775: compiler/codegen/ClearArrayTest.java failed with "assert(false) failed: bad AD file"
 - 8269543: The warning for System::setSecurityManager should only appear once for each caller
 - 8262017: C2: assert(n != __null) failed: Bad immediate dominator info.
 - 8269771: assert(tmp == _callprojs.fallthrough_catchproj) failed: allocation control projection
 - 8265132: C2 compilation fails with assert "missing precedence edge"

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

Changes: https://git.openjdk.java.net/jdk/pull/4673/files
  Stats: 341 lines in 12 files changed: 266 ins; 34 del; 41 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4673.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4673/head:pull/4673

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

From igraves at openjdk.java.net  Fri Jul  2 19:49:51 2021
From: igraves at openjdk.java.net (Ian Graves)
Date: Fri, 2 Jul 2021 19:49:51 GMT
Subject: Integrated: 8268664: The documentation of the Scanner.hasNextLine is
 incorrect
In-Reply-To: <VwR1i9EppglFbwmPnyHKCJZQ8LsgwkOjLJ9fTj-AhqU=.229bf2a8-7628-4bb3-a56f-40850590b34a@github.com>
References: <VwR1i9EppglFbwmPnyHKCJZQ8LsgwkOjLJ9fTj-AhqU=.229bf2a8-7628-4bb3-a56f-40850590b34a@github.com>
Message-ID: <YRkRQFioxmOeInDh36t_ToAHJSprn-HvCAIDl7z9FVc=.1f0aed43-8f44-43d7-b1bf-ca55adaa3a30@github.com>

On Tue, 22 Jun 2021 04:22:34 GMT, Ian Graves <igraves at openjdk.org> wrote:

> 8268664: The documentation of the Scanner.hasNextLine is incorrect

This pull request has now been integrated.

Changeset: 0d0f6a4b
Author:    Ian Graves <igraves at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/0d0f6a4becfb14304f6cea9d3a1d113f049214c0
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

8268664: The documentation of the Scanner.hasNextLine is incorrect

Reviewed-by: rriggs, bpb, iris

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

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

From igraves at openjdk.java.net  Fri Jul  2 20:20:59 2021
From: igraves at openjdk.java.net (Ian Graves)
Date: Fri, 2 Jul 2021 20:20:59 GMT
Subject: RFR: 8214761: Bug in parallel Kahan summation implementation
Message-ID: <inWiS2IlqFmGWsJuVSn1NP2Rn7YoYlADJ-3JeI8pfEs=.d208e206-5d71-4a8f-99e0-800d159d0905@github.com>

8214761: Bug in parallel Kahan summation implementation

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

Commit messages:
 - 8214761: Bug in parallel Kahan summation implementation

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

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

From aph at openjdk.java.net  Fri Jul  2 20:33:47 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Fri, 2 Jul 2021 20:33:47 GMT
Subject: RFR: 8214761: Bug in parallel Kahan summation implementation
In-Reply-To: <inWiS2IlqFmGWsJuVSn1NP2Rn7YoYlADJ-3JeI8pfEs=.d208e206-5d71-4a8f-99e0-800d159d0905@github.com>
References: <inWiS2IlqFmGWsJuVSn1NP2Rn7YoYlADJ-3JeI8pfEs=.d208e206-5d71-4a8f-99e0-800d159d0905@github.com>
Message-ID: <RQhFwIkVpsjKGl3SimlaIAwtugXmYORp4PpyNHVM7jY=.1f3ab8cd-23d5-4705-89f7-c6109264cd8f@github.com>

On Fri, 2 Jul 2021 20:12:39 GMT, Ian Graves <igraves at openjdk.org> wrote:

> 8214761: Bug in parallel Kahan summation implementation

Crikey, how did we get that wrong?
It'd be nice if we had a regression test for this. Can you provide one, please?

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

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

From jwilhelm at openjdk.java.net  Fri Jul  2 20:53:56 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Fri, 2 Jul 2021 20:53:56 GMT
Subject: Integrated: Merge jdk17
In-Reply-To: <htFLpjN9iJUwqIcueYZ_aB_NcPj9lTd03k2b6LePd5c=.f4b96ca5-5e34-484b-b386-01bfb268e00d@github.com>
References: <htFLpjN9iJUwqIcueYZ_aB_NcPj9lTd03k2b6LePd5c=.f4b96ca5-5e34-484b-b386-01bfb268e00d@github.com>
Message-ID: <6-wiHfIsWRpKqKS94UW7KNPg_YlZwc4PtYiVRX9-P2w=.ee4fac91-806c-4f49-bcb4-24f194fccded@github.com>

On Fri, 2 Jul 2021 19:34:35 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 17 -> JDK 18

This pull request has now been integrated.

Changeset: 17f53f2f
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/17f53f2f9c5928395eff9186160924e9a8e9a794
Stats:     341 lines in 12 files changed: 266 ins; 34 del; 41 mod

Merge

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

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

From mcimadamore at openjdk.java.net  Fri Jul  2 21:19:52 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 2 Jul 2021 21:19:52 GMT
Subject: [jdk17] RFR: 8269281: java/foreign/TestUpcall.java times out
In-Reply-To: <WAGKCk0ZtG6QlEKrfcB4uv4Vd7NBenJkCOBqxcoB6Y8=.dc970d5e-a200-42ee-98fa-b97bc4823e38@github.com>
References: <WAGKCk0ZtG6QlEKrfcB4uv4Vd7NBenJkCOBqxcoB6Y8=.dc970d5e-a200-42ee-98fa-b97bc4823e38@github.com>
Message-ID: <rXQjCd5eEZ9eR2vrfxnlXOKyckLikRJSZKSMkp698BA=.03893eb8-3483-44c4-a220-a33895b5adec@github.com>

On Thu, 1 Jul 2021 21:11:44 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> The previous fix to this test which used removed the `VerifyDependency` flag worked well, but we're still observing rare timeouts. Looking at the test reports, it seems likely that slightly increasing the timeout would do the trick.

After an offline discussion we agreed to leave the test unchanged at the moment. It is not immediately clear if the problem is the test (which runs in ~40 seconds) or with specific machines, as we're seeing some very wild spikes. The test uses some logic to prod the GC (so that cleaners are run and off-heap resources are released) - but the same logic is also present in the dual TestDowncall which has never timed out.

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

PR: https://git.openjdk.java.net/jdk17/pull/198

From mcimadamore at openjdk.java.net  Fri Jul  2 21:19:52 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 2 Jul 2021 21:19:52 GMT
Subject: [jdk17] Withdrawn: 8269281: java/foreign/TestUpcall.java times out
In-Reply-To: <WAGKCk0ZtG6QlEKrfcB4uv4Vd7NBenJkCOBqxcoB6Y8=.dc970d5e-a200-42ee-98fa-b97bc4823e38@github.com>
References: <WAGKCk0ZtG6QlEKrfcB4uv4Vd7NBenJkCOBqxcoB6Y8=.dc970d5e-a200-42ee-98fa-b97bc4823e38@github.com>
Message-ID: <U6S36g6ymxRs08ziyReF-KnUWECO6GhteE-rzUyYE-c=.37ea5607-1889-4b31-8ffc-1dfb96431948@github.com>

On Thu, 1 Jul 2021 21:11:44 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> The previous fix to this test which used removed the `VerifyDependency` flag worked well, but we're still observing rare timeouts. Looking at the test reports, it seems likely that slightly increasing the timeout would do the trick.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.java.net/jdk17/pull/198

From github.com+18482851+stefan-zobel at openjdk.java.net  Fri Jul  2 21:34:48 2021
From: github.com+18482851+stefan-zobel at openjdk.java.net (stefan-zobel)
Date: Fri, 2 Jul 2021 21:34:48 GMT
Subject: RFR: 8214761: Bug in parallel Kahan summation implementation
In-Reply-To: <inWiS2IlqFmGWsJuVSn1NP2Rn7YoYlADJ-3JeI8pfEs=.d208e206-5d71-4a8f-99e0-800d159d0905@github.com>
References: <inWiS2IlqFmGWsJuVSn1NP2Rn7YoYlADJ-3JeI8pfEs=.d208e206-5d71-4a8f-99e0-800d159d0905@github.com>
Message-ID: <mlWAGmxAyWE3j375QfPA0cAZ__lfHv4jlMkT41j0EYo=.aeac1341-3d57-4c48-a4a9-b45d76adc138@github.com>

On Fri, 2 Jul 2021 20:12:39 GMT, Ian Graves <igraves at openjdk.org> wrote:

> 8214761: Bug in parallel Kahan summation implementation

src/java.base/share/classes/java/util/DoubleSummaryStatistics.java line 161:

> 159: 
> 160:         //Negating this value because low-order bits are in negated form
> 161:         sumWithCompensation(-other.sumCompensation);

Wouldn't that be `double tmp =  sum - sumCompensation;` in getSum() in line 246 too?

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

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

From asemenyuk at openjdk.java.net  Fri Jul  2 21:51:49 2021
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Fri, 2 Jul 2021 21:51:49 GMT
Subject: RFR: 8268974: GetJREPath() JLI function fails to locate
 libjava.so if not standard Java launcher is used
In-Reply-To: <oq5vGCWMNPHabQvR2nFAaDQopft5bYS7kIXiP0Aso4Q=.0a9ce752-cbe7-4bbc-8719-1098ab6bcf0f@github.com>
References: <FwgeDLBYWTNtFkAm4wFZWWTmRvR7gOrMgLWWA54S-aw=.c4c8e357-ae73-4096-8d0a-5dd5f717fb08@github.com>
 <oq5vGCWMNPHabQvR2nFAaDQopft5bYS7kIXiP0Aso4Q=.0a9ce752-cbe7-4bbc-8719-1098ab6bcf0f@github.com>
Message-ID: <upEtD7i0NoHo4mFnTkxujeLu6V_GZgtWslS7JkpeTNI=.23dc389d-0e5b-495b-a74c-f8c9a8b7f500@github.com>

On Sun, 20 Jun 2021 07:25:54 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> GetApplicationHomeFromDll() fails if the path to libjli.so contains "bin" component (/tmp/bin/HelloWorld/lib/runtime/lib/libjli.so). TruncatePath() looks for "/bin/" first in "/tmp/bin/HelloWorld/lib/runtime/lib/libjli.so" string and then it looks for "/lib/". But this is wrong order as it should look for "/lib/" first. I.e. TruncatePath() should look for "/bin/" and then for "/lib/" if called from GetApplicationHome() and for "/lib/" first and then for "/bin/" if called from GetApplicationHomeFromDll().
>
> Is it possible to add a test for this that is completely independent of jpackage? I think there are a few existing tests that copy the run-time image to a new location for testing purposes.
> 
> We may need to rename the JBS description to make it clearer what this issue is about.
> 
> A minor nit is that "pathisso" will be confusing to anyone looking at this code, maybe find a better name or put a comment in TruncatePath to explain it. I assume the comments at the findLastPathComponent use site will also need to be clarified.

@AlanBateman any input on this issue from you?

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

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

From github.com+18482851+stefan-zobel at openjdk.java.net  Fri Jul  2 22:23:50 2021
From: github.com+18482851+stefan-zobel at openjdk.java.net (stefan-zobel)
Date: Fri, 2 Jul 2021 22:23:50 GMT
Subject: RFR: 8214761: Bug in parallel Kahan summation implementation
In-Reply-To: <inWiS2IlqFmGWsJuVSn1NP2Rn7YoYlADJ-3JeI8pfEs=.d208e206-5d71-4a8f-99e0-800d159d0905@github.com>
References: <inWiS2IlqFmGWsJuVSn1NP2Rn7YoYlADJ-3JeI8pfEs=.d208e206-5d71-4a8f-99e0-800d159d0905@github.com>
Message-ID: <lA3siFnhI0NdJssNM8-0IsZhsQQ5vvnX-byFAFHCSNA=.03ea6a3c-724a-495b-b31f-4443a2f9a005@github.com>

On Fri, 2 Jul 2021 20:12:39 GMT, Ian Graves <igraves at openjdk.org> wrote:

> 8214761: Bug in parallel Kahan summation implementation

What about `Collectors.computeFinalSum()` - should this be `double tmp = summands[0] + summands[1];` or `double tmp = summands[0] - summands[1];` ?

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

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

From asemenyuk at openjdk.java.net  Fri Jul  2 22:39:02 2021
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Fri, 2 Jul 2021 22:39:02 GMT
Subject: [jdk17] RFR: 8269185: Directories in /opt/runtimepackagetest and
 /path/to/jdk-17 are different
Message-ID: <BscK-vZBXNNXFMaWXULkoVjQWO8z0zmF8ZePhJ7Zg_k=.adcc22b8-b896-4a3f-bb6b-233ecf0db7d1@github.com>

Disable stripping to prevent rpmbuild from modifying executables

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

Commit messages:
 - Disable executables stripping

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

PR: https://git.openjdk.java.net/jdk17/pull/207

From github.com+18482851+stefan-zobel at openjdk.java.net  Fri Jul  2 22:41:52 2021
From: github.com+18482851+stefan-zobel at openjdk.java.net (stefan-zobel)
Date: Fri, 2 Jul 2021 22:41:52 GMT
Subject: RFR: 8214761: Bug in parallel Kahan summation implementation
In-Reply-To: <RQhFwIkVpsjKGl3SimlaIAwtugXmYORp4PpyNHVM7jY=.1f3ab8cd-23d5-4705-89f7-c6109264cd8f@github.com>
References: <inWiS2IlqFmGWsJuVSn1NP2Rn7YoYlADJ-3JeI8pfEs=.d208e206-5d71-4a8f-99e0-800d159d0905@github.com>
 <RQhFwIkVpsjKGl3SimlaIAwtugXmYORp4PpyNHVM7jY=.1f3ab8cd-23d5-4705-89f7-c6109264cd8f@github.com>
Message-ID: <qIUJ4gRtAJItqD85TeddzhtEWl_wTDtfWyuZrjqjpvY=.94cd5416-7360-4cf4-b190-828bb5b198fb@github.com>

On Fri, 2 Jul 2021 20:30:24 GMT, Andrew Haley <aph at openjdk.org> wrote:

> Crikey, how did we get that wrong?
> It'd be nice if we had a regression test for this. Can you provide one, please?

I found this: https://mail.openjdk.java.net/pipermail/core-libs-dev/2018-December/057239.html
Ivan Gerasimov already tackled this back then. His webrev still exists and it contains a simple regression test.

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

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

From almatvee at openjdk.java.net  Sat Jul  3 00:06:50 2021
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Sat, 3 Jul 2021 00:06:50 GMT
Subject: [jdk17] RFR: 8269185: Directories in /opt/runtimepackagetest and
 /path/to/jdk-17 are different
In-Reply-To: <BscK-vZBXNNXFMaWXULkoVjQWO8z0zmF8ZePhJ7Zg_k=.adcc22b8-b896-4a3f-bb6b-233ecf0db7d1@github.com>
References: <BscK-vZBXNNXFMaWXULkoVjQWO8z0zmF8ZePhJ7Zg_k=.adcc22b8-b896-4a3f-bb6b-233ecf0db7d1@github.com>
Message-ID: <CXShdWkgpecXOqmQitcJf0aVXkS6IXmcJYOtm661-eE=.2967fdff-2068-4f95-99b0-3d13ab29fae9@github.com>

On Fri, 2 Jul 2021 22:17:09 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Disable stripping to prevent rpmbuild from modifying executables

Marked as reviewed by almatvee (Reviewer).

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

PR: https://git.openjdk.java.net/jdk17/pull/207

From alanb at openjdk.java.net  Sat Jul  3 07:44:55 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sat, 3 Jul 2021 07:44:55 GMT
Subject: RFR: 8268974: GetJREPath() JLI function fails to locate
 libjava.so if not standard Java launcher is used
In-Reply-To: <oq5vGCWMNPHabQvR2nFAaDQopft5bYS7kIXiP0Aso4Q=.0a9ce752-cbe7-4bbc-8719-1098ab6bcf0f@github.com>
References: <FwgeDLBYWTNtFkAm4wFZWWTmRvR7gOrMgLWWA54S-aw=.c4c8e357-ae73-4096-8d0a-5dd5f717fb08@github.com>
 <oq5vGCWMNPHabQvR2nFAaDQopft5bYS7kIXiP0Aso4Q=.0a9ce752-cbe7-4bbc-8719-1098ab6bcf0f@github.com>
Message-ID: <KvvdkHkQaVO4NCuUPLr99AMHJTCF6d_EGPaTMJFCfSA=.96d77bc0-2596-48b7-8193-1f46a8684ee7@github.com>

On Sun, 20 Jun 2021 07:25:54 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> GetApplicationHomeFromDll() fails if the path to libjli.so contains "bin" component (/tmp/bin/HelloWorld/lib/runtime/lib/libjli.so). TruncatePath() looks for "/bin/" first in "/tmp/bin/HelloWorld/lib/runtime/lib/libjli.so" string and then it looks for "/lib/". But this is wrong order as it should look for "/lib/" first. I.e. TruncatePath() should look for "/bin/" and then for "/lib/" if called from GetApplicationHome() and for "/lib/" first and then for "/bin/" if called from GetApplicationHomeFromDll().
>
> Is it possible to add a test for this that is completely independent of jpackage? I think there are a few existing tests that copy the run-time image to a new location for testing purposes.
> 
> We may need to rename the JBS description to make it clearer what this issue is about.
> 
> A minor nit is that "pathisso" will be confusing to anyone looking at this code, maybe find a better name or put a comment in TruncatePath to explain it. I assume the comments at the findLastPathComponent use site will also need to be clarified.

> @AlanBateman any input on this issue from you?

Same comment as before, I think we should try to add a test.  If a native test that links to libjli isn't feasible then a jpackage test that creates the scenario that Maurizio ran should be okay.

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

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

From jpai at openjdk.java.net  Sat Jul  3 16:19:25 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Sat, 3 Jul 2021 16:19:25 GMT
Subject: RFR: 8190753: (zipfs): Accessing a large entry (> 2^31 bytes)
 leads to a negative initial size for ByteArrayOutputStream [v3]
In-Reply-To: <zbLFjaCUglo5tfRWa1pl1CvwRiorO0jIpbvdwp52I04=.98e2a64e-b9d7-4e02-b1bb-73795e95e501@github.com>
References: <0GJVLeCPoDI4FePU-Z-NMwJHaS2XyH9S28LgqI1LNB8=.e32743dc-a6dd-475d-88ab-16ed3f46beab@github.com>
 <zbLFjaCUglo5tfRWa1pl1CvwRiorO0jIpbvdwp52I04=.98e2a64e-b9d7-4e02-b1bb-73795e95e501@github.com>
Message-ID: <gUbGHIfxWL0JgKqLVXyX-hRcbBRPtYCMr2PMZy7_S4E=.4a9eb7d0-db93-4754-98a3-43fba7f0d3e9@github.com>

On Wed, 30 Jun 2021 16:05:40 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this proposed fix for the issue reported in https://bugs.openjdk.java.net/browse/JDK-8190753?
>> 
>> The commit here checks for the size of the zip entry before trying to create a `ByteArrayOutputStream` for that entry's content. A new jtreg test has been included in this commit to reproduce the issue and verify the fix.
>> 
>> P.S: It's still a bit arguable whether it's a good idea to create the `ByteArrayOutputStream` with an initial size potentially as large as the `MAX_ARRAY_SIZE` or whether it's better to just use some smaller default value. However, I think that can be addressed separately while dealing with https://bugs.openjdk.java.net/browse/JDK-8011146
>
> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - an initial proposed test for testing compressed size entry greater than 2gb
>  - minor summary update on test

Based on the inputs received, I've now updated this PR to enhance the ZipFS to allow for rolling over the outputstream data, into a temporary file after reaching a threshold. Details follow:

- A new "tempFileThreshold" property has been introduced for ZipFileSystem. This property can be passed like other existing properties when creating the filesystem. The value of this property is expected to be a size in bytes and represents the threshold which will be used to decide whether and when to use a temporary file for outputstreams of zip file entries returned by the ZipFileSystem.

- The "tempFileThreshold" property is optional and if not set to any explicit value will default to 10MB. In other words, this feature is by default enabled, without the user having to do any specific configuration (not even the existing "useTempFile" property is requried to be set).

- To disable the threshold based temp file creation feature, a value of 0 or a negative value can be passed.

- A new (internal) `FileRolloverOutputStream` has been introduced in `ZipFileSystem` and forms the core of this enhancement. It extends the `ByteArrayOutputStream` and its write methods have the additional ability to rollover the current and subsequently written data into a temporary file representing that zip file entry.

- A new `ZipFSOutputStreamTest` has been added with the sole focus of verifying the usage of this new "tempFileThreshold" property.

- The previously added `LargeEntrySizeTest` and the manual `LargeCompressedEntrySizeTest` continue to stay and are mainly there to test the large file sizes and deflated sizes of the zip entries and verify that the original reported JBS issue is fixed by this enhancement. One important thing to note about these tests is that I've now removed the explicit "@requires" (memory) requirements, since after this enhancement (with "tempFileThreshold" by default enabled as in those tests), it no longer should require any specific high memory systems to run these tests.

There are still some decisions to be made:

1. Should we introduce this new property or should we enhance the existing "useTempFile" property to allow a size to be passed? Specifically, can we/should we use that existing property to allow users to set the following values:

	- "true", this would imply the temp file feature is enabled always irrespective of the zip entry size. This is how the value of "true" is currently handled before the patch in this PR. So no change in behaviour.

	- a byte size, represented as a `String` or an integer. This would imply that the user wants to enable the temp file feature, but only when the size or compressed size of the zip entry reaches a threshold specified by this value. This would mean that for sizes lesser than this the ZipFS implementation would use a ByteArrayOutputStream and would only rollover to a temp file when the threshold is reached.

	- "false", this would disable the temp file feature completely and outputstreams for zip entries of the ZipFS instance will always use ByteArrayOutputStream

	- value of "0" or "-1". This would be the same as specifying "false" value.

Using the existing property and just one property to control the temp file creation semantics will help avoid having to deal with 2 different properties ("useTempFile" and the "tempFileThreshold"). Plus it would also prevent any potentially conflicting user specified values for them. For example, we won't have to decide what to do when a user sets useTempFile=false and tempFileThreshold=1234.

If we do decide to introduce this new property then some small amount of additional work needs to be done in this implementation to make sure semantically conflicting values for these 2 properties are handled correctly. I decided to skip that part in this round of the PR till we reached a decision about the properties.

2. Given that this is a new enhancement, I believe this requires a CSR.

3. Should this PR be now linked to https://bugs.openjdk.java.net/browse/JDK-8011146 instead of https://bugs.openjdk.java.net/browse/JDK-8190753?

4. I've never previously created a manual test case. The `LargeCompressedEntrySizeTest` in this PR is expected to be a manual test case (given how long it might take to run on various different systems). The only difference between this test case and other jtreg automated tests is the absence of a `@test` on this one. Is this how manual tests are written or is there some other way?

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

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

From jpai at openjdk.java.net  Sat Jul  3 16:19:23 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Sat, 3 Jul 2021 16:19:23 GMT
Subject: RFR: 8190753: (zipfs): Accessing a large entry (> 2^31 bytes)
 leads to a negative initial size for ByteArrayOutputStream [v4]
In-Reply-To: <0GJVLeCPoDI4FePU-Z-NMwJHaS2XyH9S28LgqI1LNB8=.e32743dc-a6dd-475d-88ab-16ed3f46beab@github.com>
References: <0GJVLeCPoDI4FePU-Z-NMwJHaS2XyH9S28LgqI1LNB8=.e32743dc-a6dd-475d-88ab-16ed3f46beab@github.com>
Message-ID: <DngsxlE20UMkL9y5TnLw25-JNl_59vHt5lDATmImLXU=.444fba1b-d80b-4002-956b-4bd41dcb4c43@github.com>

> Can I please get a review for this proposed fix for the issue reported in https://bugs.openjdk.java.net/browse/JDK-8190753?
> 
> The commit here checks for the size of the zip entry before trying to create a `ByteArrayOutputStream` for that entry's content. A new jtreg test has been included in this commit to reproduce the issue and verify the fix.
> 
> P.S: It's still a bit arguable whether it's a good idea to create the `ByteArrayOutputStream` with an initial size potentially as large as the `MAX_ARRAY_SIZE` or whether it's better to just use some smaller default value. However, I think that can be addressed separately while dealing with https://bugs.openjdk.java.net/browse/JDK-8011146

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

  Introduce a way to allow outputstream returned by ZipOutputStream to rollover into a temporary file during writes, if the data size exceeds a threshold

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4607/files
  - new: https://git.openjdk.java.net/jdk/pull/4607/files/f519aa47..5c5f2694

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

  Stats: 362 lines in 4 files changed: 330 ins; 18 del; 14 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4607.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4607/head:pull/4607

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

From jpai at openjdk.java.net  Sun Jul  4 07:17:44 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Sun, 4 Jul 2021 07:17:44 GMT
Subject: RFR: 8190753: (zipfs): Accessing a large entry (> 2^31 bytes)
 leads to a negative initial size for ByteArrayOutputStream [v5]
In-Reply-To: <0GJVLeCPoDI4FePU-Z-NMwJHaS2XyH9S28LgqI1LNB8=.e32743dc-a6dd-475d-88ab-16ed3f46beab@github.com>
References: <0GJVLeCPoDI4FePU-Z-NMwJHaS2XyH9S28LgqI1LNB8=.e32743dc-a6dd-475d-88ab-16ed3f46beab@github.com>
Message-ID: <Q42bQKkj0HlPbz6BtWxgD0m6x89OmBO8i6V27l9qStw=.b2b56b19-19b5-41cf-af8f-b7c2b79b8dde@github.com>

> Can I please get a review for this proposed fix for the issue reported in https://bugs.openjdk.java.net/browse/JDK-8190753?
> 
> The commit here checks for the size of the zip entry before trying to create a `ByteArrayOutputStream` for that entry's content. A new jtreg test has been included in this commit to reproduce the issue and verify the fix.
> 
> P.S: It's still a bit arguable whether it's a good idea to create the `ByteArrayOutputStream` with an initial size potentially as large as the `MAX_ARRAY_SIZE` or whether it's better to just use some smaller default value. However, I think that can be addressed separately while dealing with https://bugs.openjdk.java.net/browse/JDK-8011146

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

  propagate back the original checked IOException to the callers

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4607/files
  - new: https://git.openjdk.java.net/jdk/pull/4607/files/5c5f2694..a9dfd8cd

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

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

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

From Alan.Bateman at oracle.com  Sun Jul  4 15:17:26 2021
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sun, 4 Jul 2021 16:17:26 +0100
Subject: RFR: 8190753: (zipfs): Accessing a large entry (> 2^31 bytes)
 leads to a negative initial size for ByteArrayOutputStream [v3]
In-Reply-To: <gUbGHIfxWL0JgKqLVXyX-hRcbBRPtYCMr2PMZy7_S4E=.4a9eb7d0-db93-4754-98a3-43fba7f0d3e9@github.com>
References: <0GJVLeCPoDI4FePU-Z-NMwJHaS2XyH9S28LgqI1LNB8=.e32743dc-a6dd-475d-88ab-16ed3f46beab@github.com>
 <zbLFjaCUglo5tfRWa1pl1CvwRiorO0jIpbvdwp52I04=.98e2a64e-b9d7-4e02-b1bb-73795e95e501@github.com>
 <gUbGHIfxWL0JgKqLVXyX-hRcbBRPtYCMr2PMZy7_S4E=.4a9eb7d0-db93-4754-98a3-43fba7f0d3e9@github.com>
Message-ID: <d0d8e38b-2bbe-ae22-add9-644fa2339e3d@oracle.com>

On 03/07/2021 17:19, Jaikiran Pai wrote:
> :
>
>
> There are still some decisions to be made:
>
> 1. Should we introduce this new property or should we enhance the existing "useTempFile" property to allow a size to be passed?
It's an implementation tuning knob and highly unlikely to be in the 
environment specified to newFileSystem. So I think the simplest is to 
just leave it out, it can always be added at a later time if there is a 
new real need. The default that you've chosen (10MB) looks a reasonable 
value to start with.

BTW: The documented properties that can specified in the environment are 
in jdk.zipfs's module description. The useTempFile property is not 
listed here as it was never a documented/supported property that dates 
back to early iterations of the zip file system when it was a demo.

As the PR has now expanded to do JDK-8011146 (and it doesn't matter if 
you use that JBS issue or continue with JDK-8190753) then I think the 
priority should be to be confident with the security.

> 4. I've never previously created a manual test case. The `LargeCompressedEntrySizeTest` in this PR is expected to be a manual test case (given how long it might take to run on various different systems). The only difference between this test case and other jtreg automated tests is the absence of a `@test` on this one. Is this how manual tests are written or is there some other way?
>
We avoid manual tests as there is no guarantee that they will be run. So 
maybe we'll need to explore the scenario a bit further to see if there 
is some way to come up with an automated test. The jtreg foo for manual 
tests is `@run main/manual LargeCompressedEntrySizeTest`. You'll see a 
few examples in the test suite but I don't know if they are ever run.

-Alan

From github.com+10835776+stsypanov at openjdk.java.net  Sun Jul  4 21:35:31 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Sun, 4 Jul 2021 21:35:31 GMT
Subject: RFR: 8269665: Clean-up toString() methods of some primitive
 wrappers [v2]
In-Reply-To: <-UpwLOaXO_2aSn1SpXnPNBu1NluvTcoWgBfz1XvZSv4=.6f3e58b9-d4c4-4004-ac64-b4debe32b3cd@github.com>
References: <-UpwLOaXO_2aSn1SpXnPNBu1NluvTcoWgBfz1XvZSv4=.6f3e58b9-d4c4-4004-ac64-b4debe32b3cd@github.com>
Message-ID: <DSygzbB6__37mNeWuw6ujaV7ko2XD8pVHOP0G-qW7xA=.88e39403-8fd5-4350-a613-fa5ff1326176@github.com>

> As of JDK 17 some of primitive wrappers, e.g. `Long`, `Integer`, `Double` and `Float` in their implementations of `Object.toString()` delegate to own utility `toString(primitive)` methods.
> 
> Unlike those, `Boolean`, `Byte`, `Character` and `Short` just duplicate the contents of utility methods in implementations of `Object.toString()`.
> 
> Yet another issue is a tiny discrepancy in implementation related to `Byte` and `Short` (see the first):
> 
> public static String toString(byte b) {
>     return Integer.toString((int)b, 10);
> }
> 
> public String toString() {
>     return Integer.toString((int)value);
> }
> 
> Unlike in overriden method, In utility one they explicitly specify radix which can be skipped, as implementation of `Integer.toString(int,int)` has a fast-path for radix 10, ending in `Integer.toString(int)`. This simplification gives tiny improvement, see benchmark:
> 
> @BenchmarkMode(Mode.AverageTime)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"})
> public class ByteToStringBenchmark {
>     @Benchmark
>     public String byteToString() {
>         return Byte.toString((byte) 1);
>     }
> }
> 
> Results:
> 
> before
> 
> Benchmark                                                            Mode  Cnt     Score     Error   Units
> ByteToStringBenchmark.byteToString                                   avgt   30    11,648 ?   1,906   ns/op
> ByteToStringBenchmark.byteToString:?gc.alloc.rate                    avgt   30  3288,576 ? 418,119  MB/sec
> ByteToStringBenchmark.byteToString:?gc.alloc.rate.norm               avgt   30    48,001 ?   0,001    B/op
> ByteToStringBenchmark.byteToString:?gc.churn.G1_Eden_Space           avgt   30  3301,804 ? 455,932  MB/sec
> ByteToStringBenchmark.byteToString:?gc.churn.G1_Eden_Space.norm      avgt   30    48,158 ?   2,085    B/op
> ByteToStringBenchmark.byteToString:?gc.churn.G1_Survivor_Space       avgt   30     0,004 ?   0,001  MB/sec
> ByteToStringBenchmark.byteToString:?gc.churn.G1_Survivor_Space.norm  avgt   30    ? 10??              B/op
> ByteToStringBenchmark.byteToString:?gc.count                         avgt   30   202,000            counts
> ByteToStringBenchmark.byteToString:?gc.time                          avgt   30   413,000                ms
> 
> after
> 
> Benchmark                                                            Mode  Cnt     Score     Error   Units
> ByteToStringBenchmark.byteToString                                   avgt   30    10,016 ?   0,530   ns/op
> ByteToStringBenchmark.byteToString:?gc.alloc.rate                    avgt   30  3673,700 ? 167,450  MB/sec
> ByteToStringBenchmark.byteToString:?gc.alloc.rate.norm               avgt   30    48,001 ?   0,001    B/op
> ByteToStringBenchmark.byteToString:?gc.churn.G1_Eden_Space           avgt   30  3662,406 ? 205,978  MB/sec
> ByteToStringBenchmark.byteToString:?gc.churn.G1_Eden_Space.norm      avgt   30    47,870 ?   1,750    B/op
> ByteToStringBenchmark.byteToString:?gc.churn.G1_Survivor_Space       avgt   30     0,004 ?   0,002  MB/sec
> ByteToStringBenchmark.byteToString:?gc.churn.G1_Survivor_Space.norm  avgt   30    ? 10??              B/op
> ByteToStringBenchmark.byteToString:?gc.count                         avgt   30   224,000            counts
> ByteToStringBenchmark.byteToString:?gc.time                          avgt   30   358,000                ms

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

 - 8269665: Update copy-right year
 - 8269665: Reuse String.valueOf(boolean)

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4633/files
  - new: https://git.openjdk.java.net/jdk/pull/4633/files/7a5fe65c..e939d72b

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

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

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

From jpai at openjdk.java.net  Mon Jul  5 04:30:27 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Mon, 5 Jul 2021 04:30:27 GMT
Subject: RFR: 8190753: (zipfs): Accessing a large entry (> 2^31 bytes)
 leads to a negative initial size for ByteArrayOutputStream [v6]
In-Reply-To: <0GJVLeCPoDI4FePU-Z-NMwJHaS2XyH9S28LgqI1LNB8=.e32743dc-a6dd-475d-88ab-16ed3f46beab@github.com>
References: <0GJVLeCPoDI4FePU-Z-NMwJHaS2XyH9S28LgqI1LNB8=.e32743dc-a6dd-475d-88ab-16ed3f46beab@github.com>
Message-ID: <gwRe2sf5P1rr17Ue63VGQPMG2TvLPNvUlHCBg1jUFyA=.fefe46bd-fd6f-4dd6-84d1-1b32ee385884@github.com>

> Can I please get a review for this proposed fix for the issue reported in https://bugs.openjdk.java.net/browse/JDK-8190753?
> 
> The commit here checks for the size of the zip entry before trying to create a `ByteArrayOutputStream` for that entry's content. A new jtreg test has been included in this commit to reproduce the issue and verify the fix.
> 
> P.S: It's still a bit arguable whether it's a good idea to create the `ByteArrayOutputStream` with an initial size potentially as large as the `MAX_ARRAY_SIZE` or whether it's better to just use some smaller default value. However, I think that can be addressed separately while dealing with https://bugs.openjdk.java.net/browse/JDK-8011146

Jaikiran Pai has updated the pull request incrementally with three additional commits since the last revision:

 - remove no longer used constant
 - use jtreg's construct of manual test
 - Implement Alan's review suggestion - don't expose the threshold as a configuration property, instead set it internally to a specific value

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4607/files
  - new: https://git.openjdk.java.net/jdk/pull/4607/files/a9dfd8cd..50e64d74

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

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

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

From jpai at openjdk.java.net  Mon Jul  5 04:37:47 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Mon, 5 Jul 2021 04:37:47 GMT
Subject: RFR: 8190753: (zipfs): Accessing a large entry (> 2^31 bytes)
 leads to a negative initial size for ByteArrayOutputStream [v7]
In-Reply-To: <0GJVLeCPoDI4FePU-Z-NMwJHaS2XyH9S28LgqI1LNB8=.e32743dc-a6dd-475d-88ab-16ed3f46beab@github.com>
References: <0GJVLeCPoDI4FePU-Z-NMwJHaS2XyH9S28LgqI1LNB8=.e32743dc-a6dd-475d-88ab-16ed3f46beab@github.com>
Message-ID: <g-lSUDwcKWnS0sjsg7eeeII_nuMvhes_WpDdiYijhK4=.3f9de433-95de-4b17-a49e-ff5a3ec222e0@github.com>

> Can I please get a review for this proposed fix for the issue reported in https://bugs.openjdk.java.net/browse/JDK-8190753?
> 
> The commit here checks for the size of the zip entry before trying to create a `ByteArrayOutputStream` for that entry's content. A new jtreg test has been included in this commit to reproduce the issue and verify the fix.
> 
> P.S: It's still a bit arguable whether it's a good idea to create the `ByteArrayOutputStream` with an initial size potentially as large as the `MAX_ARRAY_SIZE` or whether it's better to just use some smaller default value. However, I think that can be addressed separately while dealing with https://bugs.openjdk.java.net/browse/JDK-8011146

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

  minor update to comment on FileRolloverOutputStream class

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4607/files
  - new: https://git.openjdk.java.net/jdk/pull/4607/files/50e64d74..0fdbcea6

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

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

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

From jai.forums2013 at gmail.com  Mon Jul  5 05:22:29 2021
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Mon, 5 Jul 2021 10:52:29 +0530
Subject: RFR: 8190753: (zipfs): Accessing a large entry (> 2^31 bytes)
 leads to a negative initial size for ByteArrayOutputStream [v3]
In-Reply-To: <d0d8e38b-2bbe-ae22-add9-644fa2339e3d@oracle.com>
References: <0GJVLeCPoDI4FePU-Z-NMwJHaS2XyH9S28LgqI1LNB8=.e32743dc-a6dd-475d-88ab-16ed3f46beab@github.com>
 <zbLFjaCUglo5tfRWa1pl1CvwRiorO0jIpbvdwp52I04=.98e2a64e-b9d7-4e02-b1bb-73795e95e501@github.com>
 <gUbGHIfxWL0JgKqLVXyX-hRcbBRPtYCMr2PMZy7_S4E=.4a9eb7d0-db93-4754-98a3-43fba7f0d3e9@github.com>
 <d0d8e38b-2bbe-ae22-add9-644fa2339e3d@oracle.com>
Message-ID: <d8759650-0932-e04a-857f-a902e3e16f2d@gmail.com>

Hello Alan,

On 04/07/21 8:47 pm, Alan Bateman wrote:
> On 03/07/2021 17:19, Jaikiran Pai wrote:
>> :
>>
>>
>> There are still some decisions to be made:
>>
>> 1. Should we introduce this new property or should we enhance the 
>> existing "useTempFile" property to allow a size to be passed?
> It's an implementation tuning knob and highly unlikely to be in the 
> environment specified to newFileSystem. So I think the simplest is to 
> just leave it out, it can always be added at a later time if there is 
> a new real need. The default that you've chosen (10MB) looks a 
> reasonable value to start with.
>
> BTW: The documented properties that can specified in the environment 
> are in jdk.zipfs's module description. The useTempFile property is not 
> listed here as it was never a documented/supported property that dates 
> back to early iterations of the zip file system when it was a demo.

I've updated the PR to make this an internal implementation detail/value 
and not expect it to be a configuration passed during the creation of 
the file system. This also allowed me to simplify some of this new code 
to no longer check for 0 or negative values for this property and other 
related semantics.


>
> As the PR has now expanded to do JDK-8011146 (and it doesn't matter if 
> you use that JBS issue or continue with JDK-8190753) then I think the 
> priority should be to be confident with the security.
>
Couple of things that I can think of when it comes to security is making 
sure the temp file is created in the right location and right set of 
permissions and making sure that the temp file isn't left behind after 
the filesystem is closed or after the zip entry is no longer relevant. 
When it comes to temp file creation, the code in this PR uses existing 
constructs/code that's present in this jdk.nio.zipfs.ZipFileSystem 
class. I will take a detailed look at this part once I get to my 
workstation later today. Are there any other security aspects that we 
need to think about?


>> 4. I've never previously created a manual test case. The 
>> `LargeCompressedEntrySizeTest` in this PR is expected to be a manual 
>> test case (given how long it might take to run on various different 
>> systems). The only difference between this test case and other jtreg 
>> automated tests is the absence of a `@test` on this one. Is this how 
>> manual tests are written or is there some other way?
>>
> We avoid manual tests as there is no guarantee that they will be run. 
> So maybe we'll need to explore the scenario a bit further to see if 
> there is some way to come up with an automated test. The jtreg foo for 
> manual tests is `@run main/manual LargeCompressedEntrySizeTest`. 
> You'll see a few examples in the test suite but I don't know if they 
> are ever run.

I have updated the PR to use jtreg's construct of @run testng/manual to 
mark this as a manual test. I will post the timing of this test case 
later today after I run the latest version locally and see how long it's 
taking.

-Jaikiran




From yyang at openjdk.java.net  Mon Jul  5 06:04:50 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Mon, 5 Jul 2021 06:04:50 GMT
Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex,
 FromIndexSize} where possible
In-Reply-To: <wnnvM-AabtvXj6GyY15k2WngzWJhz6OXWfs_PygCaWU=.17e6e99b-e808-4c9e-89cc-4af2213e301e@github.com>
References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
 <wnnvM-AabtvXj6GyY15k2WngzWJhz6OXWfs_PygCaWU=.17e6e99b-e808-4c9e-89cc-4af2213e301e@github.com>
Message-ID: <u2TRSykc6zsKvQKGF74xka3w2odK2m0dx0HmEP0BwZc=.c8dfba1f-55b4-4e8e-a2ad-5286097ea203@github.com>

On Thu, 17 Jun 2021 05:16:14 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in the whole JDK codebase.
>
> Class loading order is different to class initialization order.
> 
> There are a lot more tests than just tier1. :) I don't expect many, if any, tests to be looking for a specific IOOBE message, and I can't see an easy way to find such tests without running them.  If core-libs folk are okay with this update then I guess we can just handle any test failures if they arise. But I'll run this through our tier 1-3 testing.
> 
> Thanks,
> David

@dholmes-ora @AlanBateman @PaulSandoz do you have any comments on the latest version? Thanks.

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

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

From dholmes at openjdk.java.net  Mon Jul  5 06:32:54 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 5 Jul 2021 06:32:54 GMT
Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex,
 FromIndexSize} where possible
In-Reply-To: <u2TRSykc6zsKvQKGF74xka3w2odK2m0dx0HmEP0BwZc=.c8dfba1f-55b4-4e8e-a2ad-5286097ea203@github.com>
References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
 <wnnvM-AabtvXj6GyY15k2WngzWJhz6OXWfs_PygCaWU=.17e6e99b-e808-4c9e-89cc-4af2213e301e@github.com>
 <u2TRSykc6zsKvQKGF74xka3w2odK2m0dx0HmEP0BwZc=.c8dfba1f-55b4-4e8e-a2ad-5286097ea203@github.com>
Message-ID: <rKyGMmub9-W1VGCGX86Wkh9f-GdRcUtEupSXLY1Jarw=.67f42692-0937-4a4a-9331-4c5a641dc2ea@github.com>

On Mon, 5 Jul 2021 06:01:23 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> Class loading order is different to class initialization order.
>> 
>> There are a lot more tests than just tier1. :) I don't expect many, if any, tests to be looking for a specific IOOBE message, and I can't see an easy way to find such tests without running them.  If core-libs folk are okay with this update then I guess we can just handle any test failures if they arise. But I'll run this through our tier 1-3 testing.
>> 
>> Thanks,
>> David
>
> @dholmes-ora @AlanBateman @PaulSandoz do you have any comments on the latest version? Thanks.

@kelthuzadx  I did not see any response to my query about the change in initialization (not load) order. I also remain concerned about introducing cross dependencies between core classes (e.g. String now uses Precondition, so does that impact Precondition using String?) But these are things for the core-libs folk to be concerned about, or not.

Cheers,
David

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

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

From jpai at openjdk.java.net  Mon Jul  5 07:42:26 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Mon, 5 Jul 2021 07:42:26 GMT
Subject: RFR: 8190753: (zipfs): Accessing a large entry (> 2^31 bytes)
 leads to a negative initial size for ByteArrayOutputStream [v8]
In-Reply-To: <0GJVLeCPoDI4FePU-Z-NMwJHaS2XyH9S28LgqI1LNB8=.e32743dc-a6dd-475d-88ab-16ed3f46beab@github.com>
References: <0GJVLeCPoDI4FePU-Z-NMwJHaS2XyH9S28LgqI1LNB8=.e32743dc-a6dd-475d-88ab-16ed3f46beab@github.com>
Message-ID: <ehuksZQILsWLXcuvxgtRGIq7Lqwl146QQpIVHanMoIs=.9cad7f15-24b8-4bf6-99db-cbf3ef3cccbf@github.com>

> Can I please get a review for this proposed fix for the issue reported in https://bugs.openjdk.java.net/browse/JDK-8190753?
> 
> The commit here checks for the size of the zip entry before trying to create a `ByteArrayOutputStream` for that entry's content. A new jtreg test has been included in this commit to reproduce the issue and verify the fix.
> 
> P.S: It's still a bit arguable whether it's a good idea to create the `ByteArrayOutputStream` with an initial size potentially as large as the `MAX_ARRAY_SIZE` or whether it's better to just use some smaller default value. However, I think that can be addressed separately while dealing with https://bugs.openjdk.java.net/browse/JDK-8011146

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

  reorganize the tests now that the temp file creation threshold isn't exposed as a user configurable value

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4607/files
  - new: https://git.openjdk.java.net/jdk/pull/4607/files/0fdbcea6..c1ec9e12

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

  Stats: 200 lines in 3 files changed: 1 ins; 184 del; 15 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4607.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4607/head:pull/4607

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

From yyang at openjdk.java.net  Mon Jul  5 08:06:54 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Mon, 5 Jul 2021 08:06:54 GMT
Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex,
 FromIndexSize} where possible
In-Reply-To: <u2TRSykc6zsKvQKGF74xka3w2odK2m0dx0HmEP0BwZc=.c8dfba1f-55b4-4e8e-a2ad-5286097ea203@github.com>
References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
 <wnnvM-AabtvXj6GyY15k2WngzWJhz6OXWfs_PygCaWU=.17e6e99b-e808-4c9e-89cc-4af2213e301e@github.com>
 <u2TRSykc6zsKvQKGF74xka3w2odK2m0dx0HmEP0BwZc=.c8dfba1f-55b4-4e8e-a2ad-5286097ea203@github.com>
Message-ID: <MGaJGRNH13DuTwOv-AhcTnmRWHnXIDT8Lh3gNYzRu6E=.9ce30156-e8cc-4d30-8959-7a77f0f840eb@github.com>

On Mon, 5 Jul 2021 06:01:23 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> Class loading order is different to class initialization order.
>> 
>> There are a lot more tests than just tier1. :) I don't expect many, if any, tests to be looking for a specific IOOBE message, and I can't see an easy way to find such tests without running them.  If core-libs folk are okay with this update then I guess we can just handle any test failures if they arise. But I'll run this through our tier 1-3 testing.
>> 
>> Thanks,
>> David
>
> @dholmes-ora @AlanBateman @PaulSandoz do you have any comments on the latest version? Thanks.

> @kelthuzadx I did not see any response to my query about the change in initialization (not load) order. I also remain concerned about introducing cross dependencies between core classes (e.g. String now uses Precondition, so does that impact Precondition using String?) But these are things for the core-libs folk to be concerned about, or not.
> 
> Cheers,
> David

Hi David, the following are initialization orders:

$./java -Xlog:class+init -version
[0.255s][info][class,init] 0 Initializing 'java/lang/Object'(no method) (0x0000000800000e18)
[0.255s][info][class,init] 1 Initializing 'java/lang/CharSequence'(no method) (0x000000080006ba68)
[0.255s][info][class,init] 2 Initializing 'java/lang/String' (0x000000080000e978)
[0.255s][info][class,init] 3 Initializing 'java/util/Comparator'(no method) (0x00000008000fd760)
[0.255s][info][class,init] 4 Initializing 'java/lang/String$CaseInsensitiveComparator'(no method) (0x0000000800130988)
[0.255s][info][class,init] 5 Initializing 'java/lang/System' (0x0000000800008c68)
[0.256s][info][class,init] 6 Initializing 'java/lang/reflect/AnnotatedElement'(no method) (0x0000000800001f88)
[0.256s][info][class,init] 7 Initializing 'java/lang/reflect/Type'(no method) (0x0000000800002930)
[0.256s][info][class,init] 8 Initializing 'java/lang/Class' (0x0000000800001830)
[0.256s][info][class,init] 9 Initializing 'java/lang/ThreadGroup'(no method) (0x000000080001d348)
[0.257s][info][class,init] 10 Initializing 'java/lang/Thread' (0x000000080001c470)
[0.258s][info][class,init] 11 Initializing 'java/security/AccessController' (0x0000000800009a80)
[0.258s][info][class,init] 12 Initializing 'java/security/AccessControlContext' (0x00000008000743c8)
[0.258s][info][class,init] 13 Initializing 'java/lang/Module' (0x000000080000bab0)
[0.259s][info][class,init] 14 Initializing 'java/lang/Module$ArchivedData' (0x00000008001a05a8)
[0.259s][info][class,init] 15 Initializing 'jdk/internal/misc/CDS' (0x0000000800018bf8)
[0.259s][info][class,init] 16 Initializing 'java/lang/Iterable'(no method) (0x000000080008be28)
[0.259s][info][class,init] 17 Initializing 'java/util/Collection'(no method) (0x000000080008c028)
[0.260s][info][class,init] 18 Initializing 'java/util/AbstractCollection'(no method) (0x00000008000381e0)
[0.260s][info][class,init] 19 Initializing 'java/util/ImmutableCollections$AbstractImmutableCollection'(no method) (0x000000080008c2f8)
[0.260s][info][class,init] 20 Initializing 'java/util/Set'(no method) (0x00000008000189f8)
[0.260s][info][class,init] 21 Initializing 'java/util/ImmutableCollections$AbstractImmutableSet'(no method) (0x000000080008d018)
[0.260s][info][class,init] 22 Initializing 'java/util/ImmutableCollections$Set12'(no method) (0x000000080008ba18)
[0.369s][info][class,init] 23 Initializing 'jdk/internal/misc/UnsafeConstants' (0x00000008000b4ea0)
[0.369s][info][class,init] 24 Initializing 'java/lang/reflect/AccessibleObject' (0x000000080005b4d8)
[0.370s][info][class,init] 25 Initializing 'java/lang/reflect/ReflectAccess'(no method) (0x0000000800013610)
[0.370s][info][class,init] 26 Initializing 'jdk/internal/access/SharedSecrets' (0x0000000800013408)
[0.370s][info][class,init] 27 Initializing 'java/lang/invoke/MethodHandles' (0x0000000800131720)
[0.371s][info][class,init] 28 Initializing 'java/lang/invoke/MemberName' (0x00000008000de230)
[0.371s][info][class,init] 29 Initializing 'java/lang/invoke/MemberName$Factory' (0x0000000800023468)
[0.372s][info][class,init] 30 Initializing 'java/security/Permission'(no method) (0x0000000800023020)
[0.372s][info][class,init] 31 Initializing 'java/security/BasicPermission'(no method) (0x0000000800025de8)
[0.372s][info][class,init] 32 Initializing 'java/lang/reflect/ReflectPermission'(no method) (0x0000000800025b98)
[0.372s][info][class,init] 33 Initializing 'java/lang/StringLatin1' (0x0000000800022e18)
[0.373s][info][class,init] 34 Initializing 'java/lang/invoke/MethodHandles$Lookup' (0x00000008000e3708)
[0.373s][info][class,init] 35 Initializing 'java/util/Objects'(no method) (0x000000080008b810)
[0.374s][info][class,init] 36 Initializing 'jdk/internal/reflect/Reflection' (0x000000080000fb28)
[0.374s][info][class,init] 37 Initializing 'java/util/ImmutableCollections' (0x000000080008d420)
[0.374s][info][class,init] 38 Initializing 'java/util/List'(no method) (0x000000080008e460)
[0.374s][info][class,init] 39 Initializing 'java/util/ImmutableCollections$AbstractImmutableList'(no method) (0x000000080008c670)
[0.374s][info][class,init] 40 Initializing 'java/util/ImmutableCollections$ListN'(no method) (0x00000008001d2ad0)
[0.374s][info][class,init] 41 Initializing 'java/util/ImmutableCollections$SetN'(no method) (0x000000080018fd58)
[0.375s][info][class,init] 42 Initializing 'java/util/Map'(no method) (0x0000000800018368)
[0.375s][info][class,init] 43 Initializing 'java/util/AbstractMap'(no method) (0x0000000800057d08)
[0.375s][info][class,init] 44 Initializing 'java/util/ImmutableCollections$AbstractImmutableMap'(no method) (0x000000080011aef8)
[0.375s][info][class,init] 45 Initializing 'java/util/ImmutableCollections$MapN'(no method) (0x000000080018a888)
[0.487s][info][class,init] 46 Initializing 'java/lang/Math' (0x0000000800027918)
[0.488s][info][class,init] 47 Initializing 'java/lang/Number'(no method) (0x000000080003fd18)
[0.488s][info][class,init] 48 Initializing 'java/lang/Float' (0x0000000800048978)
[0.488s][info][class,init] 49 Initializing 'java/lang/Double' (0x000000080004a478)
[0.488s][info][class,init] 50 Initializing 'java/util/HashMap'(no method) (0x000000080011a6a0)
[0.489s][info][class,init] 51 Initializing 'java/lang/Integer' (0x000000080004bb58)
[0.489s][info][class,init] 52 Initializing 'java/util/AbstractSet'(no method) (0x000000080011ced8)
[0.489s][info][class,init] 53 Initializing 'java/util/ImmutableCollections$MapN$1'(no method) (0x00000008001e0f10)
[0.489s][info][class,init] 54 Initializing 'java/util/Iterator'(no method) (0x00000008000047d8)
[0.489s][info][class,init] 55 Initializing 'java/util/ImmutableCollections$MapN$MapNIterator'(no method) (0x00000008000192c0)
[0.490s][info][class,init] 56 Initializing 'java/util/KeyValueHolder'(no method) (0x000000080016d540)
[0.490s][info][class,init] 57 Initializing 'java/util/HashMap$Node'(no method) (0x000000080016c8f8)
[0.491s][info][class,init] 58 Initializing 'java/util/concurrent/ConcurrentMap'(no method) (0x00000008001872d8)
[0.491s][info][class,init] 59 Initializing 'java/util/concurrent/ConcurrentHashMap' (0x000000080000e3d0)
[0.491s][info][class,init] 60 Initializing 'java/lang/Runtime' (0x000000080016c650)
[0.491s][info][class,init] 61 Initializing 'java/io/ObjectStreamField'(no method) (0x00000008000fd960)
[0.492s][info][class,init] 62 Initializing 'jdk/internal/misc/Unsafe' (0x0000000800010140)
[0.493s][info][class,init] 63 Initializing 'jdk/internal/reflect/ReflectionFactory$GetReflectionFactoryAction'(no method) (0x0000000800146b08)
[0.494s][info][class,init] 64 Initializing 'jdk/internal/reflect/ReflectionFactory' (0x000000080005a630)
[0.494s][info][class,init] 65 Initializing 'java/lang/ref/Reference' (0x00000008000533f8)
[0.494s][info][class,init] 66 Initializing 'java/lang/ref/Reference$ReferenceHandler' (0x0000000800054af8)
[0.495s][info][class,init] 67 Initializing 'java/lang/ref/PhantomReference'(no method) (0x0000000800053640)
[0.495s][info][class,init] 68 Initializing 'jdk/internal/ref/Cleaner' (0x00000008000548a0)
[0.495s][info][class,init] 69 Initializing 'java/lang/ref/ReferenceQueue' (0x000000080005a1a8)
[0.495s][info][class,init] 70 Initializing 'java/lang/ref/ReferenceQueue$Null'(no method) (0x000000080005a3e8)
[0.495s][info][class,init] 71 Initializing 'java/lang/ref/ReferenceQueue$Lock'(no method) (0x00000008001f3cd8)
[0.496s][info][class,init] 72 Initializing 'java/lang/ref/Reference$1'(no method) (0x000000080005aab0)
[0.496s][info][class,init] 73 Initializing 'java/lang/reflect/Executable'(no method) (0x000000080005b798)
[0.496s][info][class,init] 74 Initializing 'java/lang/reflect/Method'(no method) (0x000000080005c430)
[0.496s][info][class,init] 75 Initializing 'java/lang/ref/FinalReference'(no method) (0x00000008000553d8)
[0.496s][info][class,init] 76 Initializing 'java/lang/ref/Finalizer' (0x0000000800055620)
[0.496s][info][class,init] 77 Initializing 'java/lang/ref/Finalizer$FinalizerThread'(no method) (0x000000080017e790)
[0.497s][info][class,init] 78 Initializing 'java/lang/System$2'(no method) (0x0000000800015b68)
[0.498s][info][class,init] 79 Initializing 'jdk/internal/util/SystemProps' (0x0000000800015960)
[0.498s][info][class,init] 80 Initializing 'jdk/internal/util/SystemProps$Raw'(no method) (0x000000080009e300)
[0.499s][info][class,init] 81 Initializing 'jdk/internal/misc/VM' (0x000000080000fd30)
[0.500s][info][class,init] 82 Initializing 'java/lang/StringConcatHelper' (0x0000000800016308)
[0.500s][info][class,init] 83 Initializing 'java/lang/Byte' (0x0000000800040330)
[0.500s][info][class,init] 84 Initializing 'java/lang/VersionProps' (0x0000000800016100)
[0.502s][info][class,init] 85 Initializing 'java/util/Arrays' (0x0000000800027b20)
[0.502s][info][class,init] 86 Initializing 'java/lang/Character' (0x000000080003e1c8)
[0.502s][info][class,init] 87 Initializing 'java/lang/CharacterData'(no method) (0x00000008000449a8)
[0.503s][info][class,init] 88 Initializing 'java/lang/CharacterDataLatin1' (0x0000000800044638)
[0.503s][info][class,init] 89 Initializing 'java/lang/Integer$IntegerCache' (0x000000080003fb10)
[0.624s][info][class,init] 90 Initializing 'java/util/Dictionary'(no method) (0x0000000800016970)
[0.624s][info][class,init] 91 Initializing 'java/util/Hashtable'(no method) (0x0000000800016bb0)
[0.624s][info][class,init] 92 Initializing 'java/util/Properties' (0x0000000800016510)
[0.624s][info][class,init] 93 Initializing 'java/util/HashMap$EntrySet'(no method) (0x00000008001f0b48)
[0.624s][info][class,init] 94 Initializing 'java/util/HashMap$HashIterator'(no method) (0x00000008000199f0)
[0.624s][info][class,init] 95 Initializing 'java/util/HashMap$EntryIterator'(no method) (0x0000000800019c00)
[0.625s][info][class,init] 96 Initializing 'java/util/concurrent/ConcurrentHashMap$Node'(no method) (0x00000008001be7b8)
[0.626s][info][class,init] 97 Initializing 'jdk/internal/util/StaticProperty' (0x00000008000197e8)
[0.626s][info][class,init] 98 Initializing 'java/io/InputStream'(no method) (0x000000080001a100)
[0.626s][info][class,init] 99 Initializing 'java/io/FileInputStream' (0x0000000800019e48)
[0.627s][info][class,init] 100 Initializing 'java/io/FileDescriptor' (0x000000080001ac70)
[0.627s][info][class,init] 101 Initializing 'java/io/FileDescriptor$1'(no method) (0x00000008001fe1d8)
[0.627s][info][class,init] 102 Initializing 'java/io/OutputStream'(no method) (0x0000000800013cf8)
[0.628s][info][class,init] 103 Initializing 'java/io/FileOutputStream' (0x000000080001ae80)
[0.628s][info][class,init] 104 Initializing 'java/io/FilterInputStream'(no method) (0x000000080001b630)
[0.628s][info][class,init] 105 Initializing 'java/io/BufferedInputStream' (0x000000080001b378)
[0.628s][info][class,init] 106 Initializing 'java/io/FilterOutputStream'(no method) (0x0000000800013f70)
[0.629s][info][class,init] 107 Initializing 'java/io/PrintStream'(no method) (0x0000000800013948)
[0.629s][info][class,init] 108 Initializing 'java/io/BufferedOutputStream'(no method) (0x0000000800018568)
[0.629s][info][class,init] 109 Initializing 'java/nio/charset/Charset' (0x000000080009e0a0)
[0.629s][info][class,init] 110 Initializing 'java/nio/charset/spi/CharsetProvider'(no method) (0x00000008001f45c8)
[0.629s][info][class,init] 111 Initializing 'sun/nio/cs/StandardCharsets' (0x00000008001f47e0)
[0.629s][info][class,init] 112 Initializing 'java/lang/ThreadLocal' (0x0000000800027d28)
[0.630s][info][class,init] 113 Initializing 'java/util/concurrent/atomic/AtomicInteger' (0x0000000800027f70)
[0.630s][info][class,init] 114 Initializing 'sun/nio/cs/Unicode'(no method) (0x000000080009eba8)
[0.630s][info][class,init] 115 Initializing 'sun/nio/cs/UTF_8' (0x000000080009ee28)
[0.631s][info][class,init] 116 Initializing 'java/io/Writer'(no method) (0x00000008000fa5e0)
[0.631s][info][class,init] 117 Initializing 'java/io/OutputStreamWriter'(no method) (0x00000008000fb258)
[0.631s][info][class,init] 118 Initializing 'sun/nio/cs/StreamEncoder' (0x00000008000fc1e0)
[0.632s][info][class,init] 119 Initializing 'java/nio/charset/CharsetEncoder' (0x00000008000f98c0)
[0.632s][info][class,init] 120 Initializing 'sun/nio/cs/UTF_8$Encoder'(no method) (0x00000008010403e0)
[0.632s][info][class,init] 121 Initializing 'java/nio/charset/CodingErrorAction' (0x00000008000b6120)
[0.633s][info][class,init] 122 Initializing 'java/nio/Buffer' (0x000000080007e418)
[0.635s][info][class,init] 123 Initializing 'jdk/internal/misc/ScopedMemoryAccess' (0x00000008000b52a8)
[0.636s][info][class,init] 124 Initializing 'java/nio/Buffer$1'(no method) (0x00000008001d5338)
[0.636s][info][class,init] 125 Initializing 'java/nio/ByteBuffer' (0x0000000800084418)
[0.637s][info][class,init] 126 Initializing 'java/nio/HeapByteBuffer' (0x0000000800207160)
[0.637s][info][class,init] 127 Initializing 'java/nio/ByteOrder' (0x000000080001bf60)
[0.638s][info][class,init] 128 Initializing 'java/io/BufferedWriter' (0x000000080001c170)
[0.638s][info][class,init] 129 Initializing 'java/lang/Terminator' (0x000000080001bd58)
[0.638s][info][class,init] 130 Initializing 'java/lang/Terminator$1'(no method) (0x0000000800091328)
[0.638s][info][class,init] 131 Initializing 'jdk/internal/misc/Signal' (0x0000000800091118)
[0.639s][info][class,init] 132 Initializing 'java/util/Hashtable$Entry'(no method) (0x0000000800188278)
[0.639s][info][class,init] 133 Initializing 'jdk/internal/misc/Signal$Handler' (0x0000000800091550)
[0.639s][info][class,init] 134 Initializing 'jdk/internal/misc/Signal$NativeHandler'(no method) (0x000000080020dd80)
[0.639s][info][class,init] 135 Initializing 'jdk/internal/misc/OSEnvironment'(no method) (0x0000000800037dc8)
[0.640s][info][class,init] 136 Initializing 'java/lang/Throwable' (0x00000008000339d8)
[0.640s][info][class,init] 137 Initializing 'java/util/Collections' (0x0000000800037bc0)
[0.640s][info][class,init] 138 Initializing 'java/util/Collections$EmptySet'(no method) (0x000000080011d2e0)
[0.640s][info][class,init] 139 Initializing 'java/util/AbstractList'(no method) (0x000000080008e660)
[0.640s][info][class,init] 140 Initializing 'java/util/Collections$EmptyList'(no method) (0x00000008001c97d0)
[0.641s][info][class,init] 141 Initializing 'java/util/Collections$EmptyMap'(no method) (0x0000000800058498)
[0.641s][info][class,init] 142 Initializing 'java/lang/Error'(no method) (0x0000000800035558)
[0.641s][info][class,init] 143 Initializing 'java/lang/VirtualMachineError'(no method) (0x00000008000357b8)
[0.641s][info][class,init] 144 Initializing 'java/lang/OutOfMemoryError'(no method) (0x0000000800099da8)
[0.641s][info][class,init] 145 Initializing 'java/lang/Exception'(no method) (0x0000000800033c38)
[0.641s][info][class,init] 146 Initializing 'java/lang/RuntimeException'(no method) (0x0000000800034e08)
[0.641s][info][class,init] 147 Initializing 'java/lang/NullPointerException'(no method) (0x0000000800099950)
[0.641s][info][class,init] 148 Initializing 'java/lang/ClassCastException'(no method) (0x000000080009a5f8)
[0.641s][info][class,init] 149 Initializing 'java/lang/ArrayStoreException'(no method) (0x0000000800035ed8)
[0.641s][info][class,init] 150 Initializing 'java/lang/ArithmeticException'(no method) (0x00000008000996f0)
[0.641s][info][class,init] 151 Initializing 'java/lang/StackOverflowError'(no method) (0x0000000800035a18)
[0.641s][info][class,init] 152 Initializing 'java/lang/IllegalMonitorStateException'(no method) (0x00000008000570e0)
[0.641s][info][class,init] 153 Initializing 'java/lang/IllegalArgumentException'(no method) (0x0000000800035068)
[0.643s][info][class,init] 154 Initializing 'java/lang/invoke/MethodHandle' (0x00000008000c8200)
[0.644s][info][class,init] 155 Initializing 'java/lang/invoke/MethodHandleStatics' (0x000000080001e260)
[0.644s][info][class,init] 156 Initializing 'sun/security/action/GetPropertyAction'(no method) (0x00000008000fa3a8)
[0.644s][info][class,init] 157 Initializing 'java/lang/Boolean' (0x0000000800038f10)
[0.645s][info][class,init] 158 Initializing 'java/lang/invoke/ResolvedMethodName'(no method) (0x00000008000e1fc0)
[0.645s][info][class,init] 159 Initializing 'java/lang/invoke/MethodHandleNatives' (0x00000008000e22b0)
[0.645s][info][class,init] 160 Initializing 'jdk/internal/module/ModuleBootstrap' (0x000000080001e058)
[0.646s][info][class,init] 161 Initializing 'sun/invoke/util/VerifyAccess' (0x000000080007a938)
[0.646s][info][class,init] 162 Initializing 'java/lang/reflect/Modifier'(no method) (0x000000080007a730)
[0.647s][info][class,init] 163 Initializing 'java/lang/module/ModuleDescriptor' (0x000000080013a608)
[0.647s][info][class,init] 164 Initializing 'java/lang/module/ModuleDescriptor$1'(no method) (0x000000080007a258)
[0.647s][info][class,init] 165 Initializing 'java/io/File' (0x0000000800079ec0)
[0.648s][info][class,init] 166 Initializing 'java/io/DefaultFileSystem'(no method) (0x00000008000afa80)
[0.648s][info][class,init] 167 Initializing 'java/io/FileSystem' (0x00000008000adb08)
[0.648s][info][class,init] 168 Initializing 'java/io/UnixFileSystem' (0x00000008000addf0)
[0.649s][info][class,init] 169 Initializing 'java/lang/AbstractStringBuilder' (0x000000080006c268)
[0.649s][info][class,init] 170 Initializing 'java/lang/StringBuilder'(no method) (0x000000080000f478)
[0.650s][info][class,init] 171 Initializing 'jdk/internal/util/ArraysSupport' (0x00000008000ad900)
[0.650s][info][class,init] 172 Initializing 'jdk/internal/module/ModulePatcher' (0x00000008001945b0)
[0.651s][info][class,init] 173 Initializing 'jdk/internal/module/ModuleBootstrap$Counters' (0x0000000800192aa8)
[0.651s][info][class,init] 174 Initializing 'jdk/internal/module/ArchivedBootLayer' (0x0000000800192890)
[0.651s][info][class,init] 175 Initializing 'java/lang/ModuleLayer' (0x0000000800175c40)
[0.651s][info][class,init] 176 Initializing 'java/lang/module/Configuration' (0x000000080018e820)
[0.918s][info][class,init] 177 Initializing 'jdk/internal/loader/AbstractClassLoaderValue' (0x000000080018eeb0)
[0.918s][info][class,init] 178 Initializing 'jdk/internal/loader/ClassLoaderValue'(no method) (0x000000080018f0f8)
[0.918s][info][class,init] 179 Initializing 'java/util/ImmutableCollections$List12'(no method) (0x000000080008cb40)
[0.918s][info][class,init] 180 Initializing 'java/lang/module/ResolvedModule'(no method) (0x00000008001917c8)
[0.918s][info][class,init] 181 Initializing 'java/lang/module/ModuleReference'(no method) (0x00000008000d1f40)
[0.918s][info][class,init] 182 Initializing 'jdk/internal/module/ModuleReferenceImpl'(no method) (0x000000080018bf00)
[0.918s][info][class,init] 183 Initializing 'java/lang/module/ModuleDescriptor$Version'(no method) (0x000000080018ceb8)
[0.918s][info][class,init] 184 Initializing 'java/util/ArrayList' (0x000000080000dea8)
[0.919s][info][class,init] 185 Initializing 'java/lang/module/ModuleDescriptor$Requires' (0x0000000800178b80)
[0.919s][info][class,init] 186 Initializing 'java/lang/Enum'(no method) (0x0000000800007880)
[0.919s][info][class,init] 187 Initializing 'java/lang/module/ModuleDescriptor$Requires$Modifier' (0x0000000800094980)
[0.919s][info][class,init] 188 Initializing 'java/lang/module/ModuleDescriptor$Exports'(no method) (0x0000000800178958)
[0.919s][info][class,init] 189 Initializing 'java/lang/module/ModuleDescriptor$Provides'(no method) (0x000000080018d0e0)
[0.919s][info][class,init] 190 Initializing 'java/net/URI' (0x0000000800192228)
[0.920s][info][class,init] 191 Initializing 'java/net/URI$1'(no method) (0x000000080022bb10)
[0.920s][info][class,init] 192 Initializing 'jdk/internal/module/SystemModuleFinders$2'(no method) (0x000000080018bcc8)
[0.920s][info][class,init] 193 Initializing 'jdk/internal/module/SystemModuleFinders$3'(no method) (0x00000008001947c0)
[0.920s][info][class,init] 194 Initializing 'jdk/internal/module/ModuleTarget'(no method) (0x0000000800225ca0)
[0.920s][info][class,init] 195 Initializing 'jdk/internal/module/ModuleHashes'(no method) (0x00000008001941a0)
[0.920s][info][class,init] 196 Initializing 'java/util/Collections$UnmodifiableMap'(no method) (0x0000000800213c70)
[0.920s][info][class,init] 197 Initializing 'java/lang/module/ModuleDescriptor$Opens'(no method) (0x0000000800178730)
[0.920s][info][class,init] 198 Initializing 'java/util/HashSet' (0x000000080011cac8)
[0.920s][info][class,init] 199 Initializing 'java/lang/ClassLoader' (0x0000000800008e70)
[0.921s][info][class,init] 200 Initializing 'java/security/SecureClassLoader' (0x0000000800009450)
[0.921s][info][class,init] 201 Initializing 'java/lang/ClassLoader$ParallelLoaders' (0x000000080000f270)
[0.921s][info][class,init] 202 Initializing 'java/util/WeakHashMap' (0x0000000800057948)
[0.922s][info][class,init] 203 Initializing 'java/util/Collections$SetFromMap'(no method) (0x000000080021a8c8)
[0.922s][info][class,init] 204 Initializing 'java/util/WeakHashMap$KeySet'(no method) (0x000000080017b698)
[0.922s][info][class,init] 205 Initializing 'java/lang/ref/WeakReference'(no method) (0x0000000800055a20)
[0.922s][info][class,init] 206 Initializing 'java/util/WeakHashMap$Entry'(no method) (0x00000008000576a8)
[0.923s][info][class,init] 207 Initializing 'jdk/internal/loader/BuiltinClassLoader' (0x0000000800009748)
[0.923s][info][class,init] 208 Initializing 'jdk/internal/loader/ArchivedClassLoaders' (0x00000008001bda48)
[0.923s][info][class,init] 209 Initializing 'jdk/internal/loader/ClassLoaders$BootClassLoader'(no method) (0x00000008001be2c8)
[0.923s][info][class,init] 210 Initializing 'java/security/ProtectionDomain' (0x000000080000ec18)
[0.923s][info][class,init] 211 Initializing 'java/security/ProtectionDomain$JavaSecurityAccessImpl'(no method) (0x000000080017b240)
[0.923s][info][class,init] 212 Initializing 'java/security/CodeSource'(no method) (0x000000080000ee38)
[0.923s][info][class,init] 213 Initializing 'java/security/Principal'(no method) (0x000000080017be08)
[0.923s][info][class,init] 214 Initializing 'java/security/ProtectionDomain$Key'(no method) (0x000000080017b038)
[0.923s][info][class,init] 215 Initializing 'jdk/internal/loader/NativeLibraries' (0x000000080000f060)
[0.924s][info][class,init] 216 Initializing 'java/util/ArrayDeque'(no method) (0x0000000800169620)
[0.924s][info][class,init] 217 Initializing 'jdk/internal/module/ServicesCatalog' (0x000000080013cb28)
[0.924s][info][class,init] 218 Initializing 'java/util/concurrent/CopyOnWriteArrayList'(no method) (0x0000000800231220)
[0.924s][info][class,init] 219 Initializing 'jdk/internal/module/ServicesCatalog$ServiceProvider'(no method) (0x0000000800231730)
[0.924s][info][class,init] 220 Initializing 'jdk/internal/loader/ClassLoaders$PlatformClassLoader' (0x00000008000990b8)
[0.924s][info][class,init] 221 Initializing 'jdk/internal/loader/BuiltinClassLoader$LoadedModule'(no method) (0x000000080018ec80)
[1.051s][info][class,init] 222 Initializing 'jdk/internal/loader/ClassLoaders$AppClassLoader' (0x0000000800096cc0)
[1.176s][info][class,init] 223 Initializing 'jdk/internal/loader/BootLoader' (0x000000080013c1d8)
[1.176s][info][class,init] 224 Initializing 'jdk/internal/loader/ClassLoaders' (0x000000080000ff38)
[1.177s][info][class,init] 225 Initializing 'jdk/internal/loader/URLClassPath' (0x00000008001b60c8)
[1.178s][info][class,init] 226 Initializing 'java/net/URL' (0x0000000800075b88)
[1.178s][info][class,init] 227 Initializing 'java/net/URL$DefaultFactory' (0x0000000800094250)
[1.178s][info][class,init] 228 Initializing 'java/net/URL$3'(no method) (0x0000000800093e28)
[1.179s][info][class,init] 229 Initializing 'java/io/File$PathStatus' (0x0000000800094738)
[1.180s][info][class,init] 230 Initializing 'sun/net/www/ParseUtil' (0x0000000800093c20)
[1.180s][info][class,init] 231 Initializing 'java/util/HexFormat' (0x0000000800096088)
[1.181s][info][class,init] 232 Initializing 'java/net/URLStreamHandler'(no method) (0x00000008001b3148)
[1.181s][info][class,init] 233 Initializing 'sun/net/www/protocol/file/Handler'(no method) (0x00000008001b38f8)
[1.182s][info][class,init] 234 Initializing 'sun/net/util/IPAddressUtil' (0x0000000800090688)
[1.183s][info][class,init] 235 Initializing 'jdk/internal/util/Preconditions'(no method) (0x0000000800090480)
[1.184s][info][class,init] 236 Initializing 'java/lang/invoke/StringConcatFactory' (0x000000080001e468)
[1.185s][info][class,init] 237 Initializing 'java/util/function/Function'(no method) (0x00000008001151e8)
[1.185s][info][class,init] 238 Initializing 'java/lang/invoke/StringConcatFactory$1'(no method) (0x0000000800235200)
[1.185s][info][class,init] 239 Initializing 'java/lang/invoke/StringConcatFactory$2'(no method) (0x0000000800235770)
[1.185s][info][class,init] 240 Initializing 'java/lang/invoke/StringConcatFactory$3'(no method) (0x0000000800043b98)
[1.187s][info][class,init] 241 Initializing 'java/nio/CharBuffer' (0x0000000800081918)
[1.187s][info][class,init] 242 Initializing 'java/nio/HeapCharBuffer' (0x0000000800081f90)
[1.188s][info][class,init] 243 Initializing 'java/nio/charset/CoderResult' (0x00000008000b5a90)
openjdk version "18-internal" 2022-03-15
OpenJDK Runtime Environment (slowdebug build 18-internal+0-adhoc.qingfengyy.jdktip)
OpenJDK 64-Bit Server VM (slowdebug build 18-internal+0-adhoc.qingfengyy.jdktip, mixed mode, sharing)
[1.192s][info][class,init] 244 Initializing 'java/lang/Shutdown' (0x0000000800050c98)
[1.192s][info][class,init] 245 Initializing 'java/lang/Shutdown$Lock'(no method) (0x00000008000264d8)

$./java -Xlog:class+init -version
[0.020s][info][class,init] 0 Initializing java/lang/Object'java/lang/Object'(no method) (0x0000000800000d68)
[0.020s][info][class,init] 1 Initializing java/lang/CharSequence'java/lang/CharSequence'(no method) (0x0000000800065478)
[0.020s][info][class,init] 2 Initializing java/lang/String'java/lang/String' (0x000000080000e4a0)
[0.020s][info][class,init] 3 Initializing java/util/Comparator'java/util/Comparator'(no method) (0x00000008000ea748)
[0.020s][info][class,init] 4 Initializing java/lang/String$CaseInsensitiveComparator'java/lang/String$CaseInsensitiveComparator'(no method) (0x000000080011ba70)
[0.020s][info][class,init] 5 Initializing java/lang/System'java/lang/System' (0x00000008000088f8)
[0.020s][info][class,init] 6 Initializing java/lang/reflect/AnnotatedElement'java/lang/reflect/AnnotatedElement'(no method) (0x0000000800001eb0)
[0.020s][info][class,init] 7 Initializing java/lang/reflect/Type'java/lang/reflect/Type'(no method) (0x00000008000027e0)
[0.020s][info][class,init] 8 Initializing java/lang/Class'java/lang/Class' (0x0000000800001750)
[0.020s][info][class,init] 9 Initializing java/lang/ThreadGroup'java/lang/ThreadGroup'(no method) (0x000000080001c1e8)
[0.020s][info][class,init] 10 Initializing java/lang/Thread'java/lang/Thread' (0x000000080001b3d0)
[0.020s][info][class,init] 11 Initializing java/security/AccessController'java/security/AccessController' (0x0000000800009738)
[0.020s][info][class,init] 12 Initializing java/security/AccessControlContext'java/security/AccessControlContext' (0x000000080006d2c8)
[0.020s][info][class,init] 13 Initializing java/lang/Module'java/lang/Module' (0x000000080000b5c0)
[0.021s][info][class,init] 14 Initializing java/lang/Module$ArchivedData'java/lang/Module$ArchivedData' (0x0000000800186270)
[0.021s][info][class,init] 15 Initializing jdk/internal/misc/CDS'jdk/internal/misc/CDS' (0x0000000800017d08)
[0.021s][info][class,init] 16 Initializing java/lang/Iterable'java/lang/Iterable'(no method) (0x0000000800082f10)
[0.021s][info][class,init] 17 Initializing java/util/Collection'java/util/Collection'(no method) (0x0000000800083118)
[0.021s][info][class,init] 18 Initializing java/util/AbstractCollection'java/util/AbstractCollection'(no method) (0x00000008000357c8)
[0.021s][info][class,init] 19 Initializing java/util/ImmutableCollections$AbstractImmutableCollection'java/util/ImmutableCollections$AbstractImmutableCollection'(no method) (0x00000008000833d0)
[0.021s][info][class,init] 20 Initializing java/util/Set'java/util/Set'(no method) (0x0000000800017b00)
[0.021s][info][class,init] 21 Initializing java/util/ImmutableCollections$AbstractImmutableSet'java/util/ImmutableCollections$AbstractImmutableSet'(no method) (0x0000000800084108)
[0.021s][info][class,init] 22 Initializing java/util/ImmutableCollections$Set12'java/util/ImmutableCollections$Set12'(no method) (0x0000000800082af8)
[0.021s][info][class,init] 23 Initializing jdk/internal/misc/UnsafeConstants'jdk/internal/misc/UnsafeConstants' (0x00000008000a7ff0)
[0.021s][info][class,init] 24 Initializing java/lang/reflect/AccessibleObject'java/lang/reflect/AccessibleObject' (0x0000000800056450)
[0.021s][info][class,init] 25 Initializing java/lang/reflect/ReflectAccess'java/lang/reflect/ReflectAccess'(no method) (0x0000000800012c50)
[0.021s][info][class,init] 26 Initializing jdk/internal/access/SharedSecrets'jdk/internal/access/SharedSecrets' (0x0000000800012a40)
[0.021s][info][class,init] 27 Initializing java/lang/invoke/MethodHandles'java/lang/invoke/MethodHandles' (0x000000080011c780)
[0.021s][info][class,init] 28 Initializing java/lang/invoke/MemberName'java/lang/invoke/MemberName' (0x00000008000cdbb8)
[0.021s][info][class,init] 29 Initializing java/lang/invoke/MemberName$Factory'java/lang/invoke/MemberName$Factory' (0x0000000800021bb0)
[0.021s][info][class,init] 30 Initializing java/security/Permission'java/security/Permission'(no method) (0x0000000800021758)
[0.021s][info][class,init] 31 Initializing java/security/BasicPermission'java/security/BasicPermission'(no method) (0x0000000800024338)
[0.021s][info][class,init] 32 Initializing java/lang/reflect/ReflectPermission'java/lang/reflect/ReflectPermission'(no method) (0x00000008000240e0)
[0.021s][info][class,init] 33 Initializing java/lang/StringLatin1'java/lang/StringLatin1' (0x0000000800021548)
[0.022s][info][class,init] 34 Initializing java/lang/invoke/MethodHandles$Lookup'java/lang/invoke/MethodHandles$Lookup' (0x00000008000d2af8)
[0.022s][info][class,init] 35 Initializing java/util/Objects'java/util/Objects'(no method) (0x00000008000828e8)
[0.022s][info][class,init] 36 Initializing jdk/internal/reflect/Reflection'jdk/internal/reflect/Reflection' (0x000000080000f688)
[0.022s][info][class,init] 37 Initializing java/util/ImmutableCollections'java/util/ImmutableCollections' (0x0000000800084518)
[0.022s][info][class,init] 38 Initializing java/util/List'java/util/List'(no method) (0x0000000800085330)
[0.022s][info][class,init] 39 Initializing java/util/ImmutableCollections$AbstractImmutableList'java/util/ImmutableCollections$AbstractImmutableList'(no method) (0x0000000800083750)
[0.022s][info][class,init] 40 Initializing java/util/ImmutableCollections$ListN'java/util/ImmutableCollections$ListN'(no method) (0x0000000800170ea0)
[0.022s][info][class,init] 41 Initializing java/util/ImmutableCollections$SetN'java/util/ImmutableCollections$SetN'(no method) (0x0000000800170a88)
[0.022s][info][class,init] 42 Initializing java/util/Map'java/util/Map'(no method) (0x00000008000174b0)
[0.022s][info][class,init] 43 Initializing java/util/AbstractMap'java/util/AbstractMap'(no method) (0x0000000800052fb8)
[0.022s][info][class,init] 44 Initializing java/util/ImmutableCollections$AbstractImmutableMap'java/util/ImmutableCollections$AbstractImmutableMap'(no method) (0x00000008001706e0)
[0.022s][info][class,init] 45 Initializing java/util/ImmutableCollections$MapN'java/util/ImmutableCollections$MapN'(no method) (0x0000000800172340)
[0.022s][info][class,init] 46 Initializing java/lang/Math'java/lang/Math' (0x0000000800025dc8)
[0.022s][info][class,init] 47 Initializing java/lang/Number'java/lang/Number'(no method) (0x000000080003cc38)
[0.022s][info][class,init] 48 Initializing java/lang/Float'java/lang/Float' (0x0000000800044c98)
[0.022s][info][class,init] 49 Initializing java/lang/Double'java/lang/Double' (0x0000000800046560)
[0.022s][info][class,init] 50 Initializing java/util/HashMap'java/util/HashMap'(no method) (0x00000008000efe78)
[0.022s][info][class,init] 51 Initializing java/lang/Integer'java/lang/Integer' (0x0000000800047a18)
[0.022s][info][class,init] 52 Initializing java/util/AbstractSet'java/util/AbstractSet'(no method) (0x0000000800109688)
[0.022s][info][class,init] 53 Initializing java/util/ImmutableCollections$MapN$1'java/util/ImmutableCollections$MapN$1'(no method) (0x00000008001c28d8)
[0.022s][info][class,init] 54 Initializing java/util/Iterator'java/util/Iterator'(no method) (0x0000000800004680)
[0.022s][info][class,init] 55 Initializing java/util/ImmutableCollections$MapN$MapNIterator'java/util/ImmutableCollections$MapN$MapNIterator'(no method) (0x00000008000183c8)
[0.022s][info][class,init] 56 Initializing java/util/KeyValueHolder'java/util/KeyValueHolder'(no method) (0x0000000800155370)
[0.022s][info][class,init] 57 Initializing java/util/HashMap$Node'java/util/HashMap$Node'(no method) (0x0000000800154778)
[0.023s][info][class,init] 58 Initializing java/util/concurrent/ConcurrentMap'java/util/concurrent/ConcurrentMap'(no method) (0x000000080016d3b0)
[0.023s][info][class,init] 59 Initializing java/util/concurrent/ConcurrentHashMap'java/util/concurrent/ConcurrentHashMap' (0x000000080000def0)
[0.023s][info][class,init] 60 Initializing java/lang/Runtime'java/lang/Runtime' (0x00000008001544c8)
[0.023s][info][class,init] 61 Initializing java/io/ObjectStreamField'java/io/ObjectStreamField'(no method) (0x00000008000ea950)
[0.023s][info][class,init] 62 Initializing jdk/internal/misc/Unsafe'jdk/internal/misc/Unsafe' (0x000000080000fcb8)
[0.023s][info][class,init] 63 Initializing jdk/internal/reflect/ReflectionFactory$GetReflectionFactoryAction'jdk/internal/reflect/ReflectionFactory$GetReflectionFactoryAction'(no method) (0x00000008001308b8)
[0.023s][info][class,init] 64 Initializing jdk/internal/reflect/ReflectionFactory'jdk/internal/reflect/ReflectionFactory' (0x00000008000556c0)
[0.023s][info][class,init] 65 Initializing java/lang/ref/Reference'java/lang/ref/Reference' (0x000000080004e880)
[0.023s][info][class,init] 66 Initializing java/lang/ref/Reference$ReferenceHandler'java/lang/ref/Reference$ReferenceHandler' (0x000000080004ff10)
[0.023s][info][class,init] 67 Initializing java/lang/ref/PhantomReference'java/lang/ref/PhantomReference'(no method) (0x000000080004ead0)
[0.023s][info][class,init] 68 Initializing jdk/internal/ref/Cleaner'jdk/internal/ref/Cleaner' (0x000000080004fcb0)
[0.023s][info][class,init] 69 Initializing java/lang/ref/ReferenceQueue'java/lang/ref/ReferenceQueue' (0x0000000800055228)
[0.023s][info][class,init] 70 Initializing java/lang/ref/ReferenceQueue$Null'java/lang/ref/ReferenceQueue$Null'(no method) (0x0000000800055470)
[0.023s][info][class,init] 71 Initializing java/lang/ref/ReferenceQueue$Lock'java/lang/ref/ReferenceQueue$Lock'(no method) (0x00000008001d49d8)
[0.023s][info][class,init] 72 Initializing java/lang/ref/Reference$1'java/lang/ref/Reference$1'(no method) (0x0000000800055af8)
[0.023s][info][class,init] 73 Initializing java/lang/reflect/Executable'java/lang/reflect/Executable'(no method) (0x0000000800056718)
[0.023s][info][class,init] 74 Initializing java/lang/reflect/Method'java/lang/reflect/Method'(no method) (0x00000008000573d0)
[0.023s][info][class,init] 75 Initializing java/lang/ref/FinalReference'java/lang/ref/FinalReference'(no method) (0x0000000800050768)
[0.023s][info][class,init] 76 Initializing java/lang/ref/Finalizer'java/lang/ref/Finalizer' (0x00000008000509b8)
[0.023s][info][class,init] 77 Initializing java/lang/ref/Finalizer$FinalizerThread'java/lang/ref/Finalizer$FinalizerThread'(no method) (0x00000008000d2f70)
[0.024s][info][class,init] 78 Initializing java/lang/System$2'java/lang/System$2'(no method) (0x0000000800014f90)
[0.024s][info][class,init] 79 Initializing jdk/internal/util/SystemProps'jdk/internal/util/SystemProps' (0x0000000800014d80)
[0.024s][info][class,init] 80 Initializing jdk/internal/misc/VM'jdk/internal/misc/VM' (0x000000080000f898)
[0.024s][info][class,init] 81 Initializing jdk/internal/util/SystemProps$Raw'jdk/internal/util/SystemProps$Raw'(no method) (0x0000000800094718)
[0.024s][info][class,init] 82 Initializing java/lang/StringConcatHelper'java/lang/StringConcatHelper' (0x0000000800015740)
[0.024s][info][class,init] 83 Initializing java/lang/Byte'java/lang/Byte' (0x000000080003d268)
[0.024s][info][class,init] 84 Initializing java/lang/VersionProps'java/lang/VersionProps' (0x0000000800015530)
[0.024s][info][class,init] 85 Initializing java/util/Arrays'java/util/Arrays' (0x0000000800025fd8)
[0.025s][info][class,init] 86 Initializing java/lang/Character'java/lang/Character' (0x000000080003b0f0)
[0.025s][info][class,init] 87 Initializing java/lang/CharacterData'java/lang/CharacterData'(no method) (0x0000000800041218)
[0.025s][info][class,init] 88 Initializing java/lang/CharacterDataLatin1'java/lang/CharacterDataLatin1' (0x0000000800040ea0)
[0.025s][info][class,init] 89 Initializing java/lang/Integer$IntegerCache'java/lang/Integer$IntegerCache' (0x000000080003ca28)
[0.025s][info][class,init] 90 Initializing java/util/Dictionary'java/util/Dictionary'(no method) (0x0000000800015db8)
[0.025s][info][class,init] 91 Initializing java/util/Hashtable'java/util/Hashtable'(no method) (0x0000000800016000)
[0.025s][info][class,init] 92 Initializing java/util/Properties'java/util/Properties' (0x0000000800015950)
[0.025s][info][class,init] 93 Initializing java/util/HashMap$EntrySet'java/util/HashMap$EntrySet'(no method) (0x00000008001d1a30)
[0.025s][info][class,init] 94 Initializing java/util/HashMap$HashIterator'java/util/HashMap$HashIterator'(no method) (0x0000000800018af0)
[0.025s][info][class,init] 95 Initializing java/util/HashMap$EntryIterator'java/util/HashMap$EntryIterator'(no method) (0x0000000800018d08)
[0.025s][info][class,init] 96 Initializing java/util/concurrent/ConcurrentHashMap$Node'java/util/concurrent/ConcurrentHashMap$Node'(no method) (0x00000008001a2628)
[0.025s][info][class,init] 97 Initializing jdk/internal/util/StaticProperty'jdk/internal/util/StaticProperty' (0x00000008000188e0)
[0.025s][info][class,init] 98 Initializing java/io/InputStream'java/io/InputStream'(no method) (0x0000000800019218)
[0.025s][info][class,init] 99 Initializing java/io/FileInputStream'java/io/FileInputStream' (0x0000000800018f58)
[0.025s][info][class,init] 100 Initializing java/io/FileDescriptor'java/io/FileDescriptor' (0x0000000800019ca8)
[0.025s][info][class,init] 101 Initializing java/io/FileDescriptor$1'java/io/FileDescriptor$1'(no method) (0x00000008001ddf68)
[0.025s][info][class,init] 102 Initializing java/io/OutputStream'java/io/OutputStream'(no method) (0x0000000800013348)
[0.025s][info][class,init] 103 Initializing java/io/FileOutputStream'java/io/FileOutputStream' (0x0000000800019ec0)
[0.025s][info][class,init] 104 Initializing java/io/FilterInputStream'java/io/FilterInputStream'(no method) (0x000000080001a620)
[0.025s][info][class,init] 105 Initializing java/io/BufferedInputStream'java/io/BufferedInputStream' (0x000000080001a360)
[0.025s][info][class,init] 106 Initializing java/io/FilterOutputStream'java/io/FilterOutputStream'(no method) (0x00000008000135c8)
[0.025s][info][class,init] 107 Initializing java/io/PrintStream'java/io/PrintStream'(no method) (0x0000000800012f90)
[0.025s][info][class,init] 108 Initializing java/io/BufferedOutputStream'java/io/BufferedOutputStream'(no method) (0x00000008000176b8)
[0.026s][info][class,init] 109 Initializing java/nio/charset/Charset'java/nio/charset/Charset' (0x00000008000944b0)
[0.026s][info][class,init] 110 Initializing java/nio/charset/spi/CharsetProvider'java/nio/charset/spi/CharsetProvider'(no method) (0x00000008001d5290)
[0.026s][info][class,init] 111 Initializing sun/nio/cs/StandardCharsets'sun/nio/cs/StandardCharsets' (0x00000008001d54b0)
[0.026s][info][class,init] 112 Initializing java/lang/ThreadLocal'java/lang/ThreadLocal' (0x00000008000261e8)
[0.026s][info][class,init] 113 Initializing java/util/concurrent/atomic/AtomicInteger'java/util/concurrent/atomic/AtomicInteger' (0x0000000800026438)
[0.026s][info][class,init] 114 Initializing sun/nio/cs/Unicode'sun/nio/cs/Unicode'(no method) (0x0000000800094f30)
[0.026s][info][class,init] 115 Initializing sun/nio/cs/UTF_8'sun/nio/cs/UTF_8' (0x00000008000951b8)
[0.026s][info][class,init] 116 Initializing java/io/Writer'java/io/Writer'(no method) (0x00000008000e7ae0)
[0.026s][info][class,init] 117 Initializing java/io/OutputStreamWriter'java/io/OutputStreamWriter'(no method) (0x00000008000e8660)
[0.026s][info][class,init] 118 Initializing sun/nio/cs/StreamEncoder'sun/nio/cs/StreamEncoder' (0x00000008000e9490)
[0.026s][info][class,init] 119 Initializing java/nio/charset/CharsetEncoder'java/nio/charset/CharsetEncoder' (0x00000008000e6e98)
[0.026s][info][class,init] 120 Initializing sun/nio/cs/UTF_8$Encoder'sun/nio/cs/UTF_8$Encoder'(no method) (0x0000000800c403f0)
[0.026s][info][class,init] 121 Initializing java/nio/charset/CodingErrorAction'java/nio/charset/CodingErrorAction' (0x00000008000a9278)
[0.026s][info][class,init] 122 Initializing java/nio/Buffer'java/nio/Buffer' (0x00000008000767a8)
[0.027s][info][class,init] 123 Initializing jdk/internal/misc/ScopedMemoryAccess'jdk/internal/misc/ScopedMemoryAccess' (0x00000008000a83e0)
[0.027s][info][class,init] 124 Initializing java/nio/Buffer$1'java/nio/Buffer$1'(no method) (0x00000008001b7460)
[0.027s][info][class,init] 125 Initializing java/nio/ByteBuffer'java/nio/ByteBuffer' (0x000000080007c050)
[0.027s][info][class,init] 126 Initializing java/nio/HeapByteBuffer'java/nio/HeapByteBuffer' (0x00000008001e5660)
[0.027s][info][class,init] 127 Initializing java/nio/ByteOrder'java/nio/ByteOrder' (0x000000080001aeb0)
[0.027s][info][class,init] 128 Initializing java/io/BufferedWriter'java/io/BufferedWriter' (0x000000080001b0c8)
[0.027s][info][class,init] 129 Initializing java/lang/Terminator'java/lang/Terminator' (0x000000080001aca0)
[0.027s][info][class,init] 130 Initializing java/lang/Terminator$1'java/lang/Terminator$1'(no method) (0x0000000800087e58)
[0.027s][info][class,init] 131 Initializing jdk/internal/misc/Signal'jdk/internal/misc/Signal' (0x0000000800087c40)
[0.027s][info][class,init] 132 Initializing java/util/Hashtable$Entry'java/util/Hashtable$Entry'(no method) (0x000000080016e1d8)
[0.027s][info][class,init] 133 Initializing jdk/internal/misc/Signal$Handler'jdk/internal/misc/Signal$Handler' (0x0000000800088088)
[0.027s][info][class,init] 134 Initializing jdk/internal/misc/Signal$NativeHandler'jdk/internal/misc/Signal$NativeHandler'(no method) (0x00000008001eb878)
[0.027s][info][class,init] 135 Initializing jdk/internal/misc/OSEnvironment'jdk/internal/misc/OSEnvironment'(no method) (0x00000008000353a0)
[0.027s][info][class,init] 136 Initializing java/lang/Throwable'java/lang/Throwable' (0x00000008000310c0)
[0.027s][info][class,init] 137 Initializing java/util/Collections'java/util/Collections' (0x0000000800035190)
[0.027s][info][class,init] 138 Initializing java/util/Collections$EmptySet'java/util/Collections$EmptySet'(no method) (0x0000000800109a98)
[0.027s][info][class,init] 139 Initializing java/util/AbstractList'java/util/AbstractList'(no method) (0x0000000800085538)
[0.027s][info][class,init] 140 Initializing java/util/Collections$EmptyList'java/util/Collections$EmptyList'(no method) (0x00000008001acf38)
[0.027s][info][class,init] 141 Initializing java/util/Collections$EmptyMap'java/util/Collections$EmptyMap'(no method) (0x0000000800053758)
[0.027s][info][class,init] 142 Initializing java/lang/Error'java/lang/Error'(no method) (0x0000000800032b90)
[0.027s][info][class,init] 143 Initializing java/lang/VirtualMachineError'java/lang/VirtualMachineError'(no method) (0x0000000800032df8)
[0.027s][info][class,init] 144 Initializing java/lang/OutOfMemoryError'java/lang/OutOfMemoryError'(no method) (0x0000000800090428)
[0.027s][info][class,init] 145 Initializing java/lang/Exception'java/lang/Exception'(no method) (0x0000000800031328)
[0.027s][info][class,init] 146 Initializing java/lang/RuntimeException'java/lang/RuntimeException'(no method) (0x0000000800032470)
[0.027s][info][class,init] 147 Initializing java/lang/NullPointerException'java/lang/NullPointerException'(no method) (0x000000080008ffc0)
[0.027s][info][class,init] 148 Initializing java/lang/ClassCastException'java/lang/ClassCastException'(no method) (0x0000000800090c18)
[0.027s][info][class,init] 149 Initializing java/lang/ArrayStoreException'java/lang/ArrayStoreException'(no method) (0x0000000800033530)
[0.027s][info][class,init] 150 Initializing java/lang/ArithmeticException'java/lang/ArithmeticException'(no method) (0x000000080008fd58)
[0.027s][info][class,init] 151 Initializing java/lang/StackOverflowError'java/lang/StackOverflowError'(no method) (0x0000000800033060)
[0.027s][info][class,init] 152 Initializing java/lang/IllegalMonitorStateException'java/lang/IllegalMonitorStateException'(no method) (0x0000000800052390)
[0.027s][info][class,init] 153 Initializing java/lang/IllegalArgumentException'java/lang/IllegalArgumentException'(no method) (0x00000008000326d8)
[0.028s][info][class,init] 154 Initializing java/lang/invoke/MethodHandle'java/lang/invoke/MethodHandle' (0x00000008000b93d0)
[0.028s][info][class,init] 155 Initializing java/lang/invoke/MethodHandleStatics'java/lang/invoke/MethodHandleStatics' (0x000000080001d020)
[0.028s][info][class,init] 156 Initializing sun/security/action/GetPropertyAction'sun/security/action/GetPropertyAction'(no method) (0x00000008000e78a0)
[0.028s][info][class,init] 157 Initializing java/lang/Boolean'java/lang/Boolean' (0x00000008000363d8)
[0.028s][info][class,init] 158 Initializing java/lang/invoke/ResolvedMethodName'java/lang/invoke/ResolvedMethodName'(no method) (0x00000008000d13b0)
[0.028s][info][class,init] 159 Initializing java/lang/invoke/MethodHandleNatives'java/lang/invoke/MethodHandleNatives' (0x00000008000d1698)
[0.028s][info][class,init] 160 Initializing jdk/internal/module/ModuleBootstrap'jdk/internal/module/ModuleBootstrap' (0x000000080001ce10)
[0.029s][info][class,init] 161 Initializing sun/invoke/util/VerifyAccess'sun/invoke/util/VerifyAccess' (0x0000000800073250)
[0.029s][info][class,init] 162 Initializing java/lang/reflect/Modifier'java/lang/reflect/Modifier'(no method) (0x0000000800073040)
[0.029s][info][class,init] 163 Initializing java/lang/module/ModuleDescriptor'java/lang/module/ModuleDescriptor' (0x0000000800124e20)
[0.029s][info][class,init] 164 Initializing java/lang/module/ModuleDescriptor$1'java/lang/module/ModuleDescriptor$1'(no method) (0x0000000800072b58)
[0.029s][info][class,init] 165 Initializing java/io/File'java/io/File' (0x00000008000727b8)
[0.029s][info][class,init] 166 Initializing java/io/DefaultFileSystem'java/io/DefaultFileSystem'(no method) (0x00000008000a4818)
[0.029s][info][class,init] 167 Initializing java/io/FileSystem'java/io/FileSystem' (0x00000008000a2b00)
[0.029s][info][class,init] 168 Initializing java/io/UnixFileSystem'java/io/UnixFileSystem' (0x00000008000a2df0)
[0.029s][info][class,init] 169 Initializing java/lang/AbstractStringBuilder'java/lang/AbstractStringBuilder' (0x0000000800065f28)
[0.029s][info][class,init] 170 Initializing java/lang/StringBuilder'java/lang/StringBuilder'(no method) (0x000000080000efc8)
[0.029s][info][class,init] 171 Initializing jdk/internal/util/ArraysSupport'jdk/internal/util/ArraysSupport' (0x00000008000a28f0)
[0.029s][info][class,init] 172 Initializing jdk/internal/module/ModulePatcher'jdk/internal/module/ModulePatcher' (0x000000080017b118)
[0.029s][info][class,init] 173 Initializing jdk/internal/module/ModuleBootstrap$Counters'jdk/internal/module/ModuleBootstrap$Counters' (0x0000000800179690)
[0.029s][info][class,init] 174 Initializing jdk/internal/module/ArchivedBootLayer'jdk/internal/module/ArchivedBootLayer' (0x0000000800179470)
[0.029s][info][class,init] 175 Initializing java/lang/ModuleLayer'java/lang/ModuleLayer' (0x000000080015d020)
[0.029s][info][class,init] 176 Initializing java/lang/module/Configuration'java/lang/module/Configuration' (0x0000000800175a90)
[0.029s][info][class,init] 177 Initializing jdk/internal/loader/AbstractClassLoaderValue'jdk/internal/loader/AbstractClassLoaderValue' (0x0000000800176138)
[0.029s][info][class,init] 178 Initializing jdk/internal/loader/ClassLoaderValue'jdk/internal/loader/ClassLoaderValue'(no method) (0x0000000800176388)
[0.029s][info][class,init] 179 Initializing java/util/ImmutableCollections$List12'java/util/ImmutableCollections$List12'(no method) (0x0000000800083c28)
[0.029s][info][class,init] 180 Initializing java/lang/module/ResolvedModule'java/lang/module/ResolvedModule'(no method) (0x0000000800178410)
[0.029s][info][class,init] 181 Initializing java/lang/module/ModuleReference'java/lang/module/ModuleReference'(no method) (0x00000008000c26a0)
[0.029s][info][class,init] 182 Initializing jdk/internal/module/ModuleReferenceImpl'jdk/internal/module/ModuleReferenceImpl'(no method) (0x0000000800173380)
[0.030s][info][class,init] 183 Initializing java/lang/module/ModuleDescriptor$Version'java/lang/module/ModuleDescriptor$Version'(no method) (0x0000000800174260)
[0.030s][info][class,init] 184 Initializing java/util/ArrayList'java/util/ArrayList' (0x000000080000d9c0)
[0.030s][info][class,init] 185 Initializing java/lang/module/ModuleDescriptor$Requires'java/lang/module/ModuleDescriptor$Requires' (0x000000080015fd68)
[0.030s][info][class,init] 186 Initializing java/lang/Enum'java/lang/Enum'(no method) (0x0000000800007540)
[0.030s][info][class,init] 187 Initializing java/lang/module/ModuleDescriptor$Requires$Modifier'java/lang/module/ModuleDescriptor$Requires$Modifier' (0x000000080008b318)
[0.030s][info][class,init] 188 Initializing java/lang/module/ModuleDescriptor$Provides'java/lang/module/ModuleDescriptor$Provides'(no method) (0x0000000800174490)
[0.030s][info][class,init] 189 Initializing java/net/URI'java/net/URI' (0x0000000800178df0)
[0.030s][info][class,init] 190 Initializing java/net/URI$1'java/net/URI$1'(no method) (0x00000008002076e8)
[0.030s][info][class,init] 191 Initializing jdk/internal/module/SystemModuleFinders$2'jdk/internal/module/SystemModuleFinders$2'(no method) (0x0000000800173140)
[0.030s][info][class,init] 192 Initializing jdk/internal/module/SystemModuleFinders$3'jdk/internal/module/SystemModuleFinders$3'(no method) (0x000000080017b330)
[0.030s][info][class,init] 193 Initializing java/lang/module/ModuleDescriptor$Exports'java/lang/module/ModuleDescriptor$Exports'(no method) (0x000000080015fb38)
[0.030s][info][class,init] 194 Initializing jdk/internal/module/ModuleTarget'jdk/internal/module/ModuleTarget'(no method) (0x0000000800201e38)
[0.030s][info][class,init] 195 Initializing jdk/internal/module/ModuleHashes'jdk/internal/module/ModuleHashes'(no method) (0x000000080017acf8)
[0.030s][info][class,init] 196 Initializing java/util/Collections$UnmodifiableMap'java/util/Collections$UnmodifiableMap'(no method) (0x00000008001f1118)
[0.030s][info][class,init] 197 Initializing java/lang/module/ModuleDescriptor$Opens'java/lang/module/ModuleDescriptor$Opens'(no method) (0x000000080015f908)
[0.030s][info][class,init] 198 Initializing java/util/HashSet'java/util/HashSet' (0x0000000800109270)
[0.030s][info][class,init] 199 Initializing java/lang/ClassLoader'java/lang/ClassLoader' (0x0000000800008b08)
[0.030s][info][class,init] 200 Initializing java/security/SecureClassLoader'java/security/SecureClassLoader' (0x00000008000090f8)
[0.030s][info][class,init] 201 Initializing java/lang/ClassLoader$ParallelLoaders'java/lang/ClassLoader$ParallelLoaders' (0x000000080000edb8)
[0.030s][info][class,init] 202 Initializing java/util/WeakHashMap'java/util/WeakHashMap' (0x0000000800052bf0)
[0.030s][info][class,init] 203 Initializing java/util/Collections$SetFromMap'java/util/Collections$SetFromMap'(no method) (0x00000008001f7808)
[0.030s][info][class,init] 204 Initializing java/util/WeakHashMap$KeySet'java/util/WeakHashMap$KeySet'(no method) (0x00000008001626b0)
[0.030s][info][class,init] 205 Initializing java/lang/ref/WeakReference'java/lang/ref/WeakReference'(no method) (0x0000000800050d80)
[0.030s][info][class,init] 206 Initializing java/util/WeakHashMap$Entry'java/util/WeakHashMap$Entry'(no method) (0x0000000800052948)
[0.030s][info][class,init] 207 Initializing jdk/internal/loader/BuiltinClassLoader'jdk/internal/loader/BuiltinClassLoader' (0x00000008000093f8)
[0.030s][info][class,init] 208 Initializing jdk/internal/loader/ArchivedClassLoaders'jdk/internal/loader/ArchivedClassLoaders' (0x00000008001a1958)
[0.030s][info][class,init] 209 Initializing jdk/internal/loader/ClassLoaders$BootClassLoader'jdk/internal/loader/ClassLoaders$BootClassLoader'(no method) (0x00000008001a2150)
[0.030s][info][class,init] 210 Initializing java/security/ProtectionDomain'java/security/ProtectionDomain' (0x000000080000e748)
[0.030s][info][class,init] 211 Initializing java/security/ProtectionDomain$JavaSecurityAccessImpl'java/security/ProtectionDomain$JavaSecurityAccessImpl'(no method) (0x0000000800162248)
[0.030s][info][class,init] 212 Initializing java/security/CodeSource'java/security/CodeSource'(no method) (0x000000080000e970)
[0.030s][info][class,init] 213 Initializing java/security/Principal'java/security/Principal'(no method) (0x0000000800162db8)
[0.030s][info][class,init] 214 Initializing java/security/ProtectionDomain$Key'java/security/ProtectionDomain$Key'(no method) (0x0000000800162038)
[0.030s][info][class,init] 215 Initializing jdk/internal/loader/NativeLibraries'jdk/internal/loader/NativeLibraries' (0x000000080000eba0)
[0.030s][info][class,init] 216 Initializing java/util/ArrayDeque'java/util/ArrayDeque'(no method) (0x00000008001518f0)
[0.030s][info][class,init] 217 Initializing jdk/internal/module/ServicesCatalog'jdk/internal/module/ServicesCatalog' (0x0000000800127108)
[0.031s][info][class,init] 218 Initializing java/util/concurrent/CopyOnWriteArrayList'java/util/concurrent/CopyOnWriteArrayList'(no method) (0x000000080020c928)
[0.031s][info][class,init] 219 Initializing jdk/internal/module/ServicesCatalog$ServiceProvider'jdk/internal/module/ServicesCatalog$ServiceProvider'(no method) (0x000000080020ce40)
[0.031s][info][class,init] 220 Initializing jdk/internal/loader/ClassLoaders$PlatformClassLoader'jdk/internal/loader/ClassLoaders$PlatformClassLoader' (0x000000080008f768)
[0.031s][info][class,init] 221 Initializing jdk/internal/loader/BuiltinClassLoader$LoadedModule'jdk/internal/loader/BuiltinClassLoader$LoadedModule'(no method) (0x0000000800175f00)
[0.031s][info][class,init] 222 Initializing jdk/internal/loader/ClassLoaders$AppClassLoader'jdk/internal/loader/ClassLoaders$AppClassLoader' (0x000000080008d498)
[0.031s][info][class,init] 223 Initializing jdk/internal/loader/BootLoader'jdk/internal/loader/BootLoader' (0x00000008001267b0)
[0.031s][info][class,init] 224 Initializing jdk/internal/loader/ClassLoaders'jdk/internal/loader/ClassLoaders' (0x000000080000faa8)
[0.031s][info][class,init] 225 Initializing jdk/internal/loader/URLClassPath'jdk/internal/loader/URLClassPath' (0x000000080019a988)
[0.031s][info][class,init] 226 Initializing java/net/URL'java/net/URL' (0x000000080006e8e0)
[0.031s][info][class,init] 227 Initializing java/net/URL$DefaultFactory'java/net/URL$DefaultFactory' (0x000000080008abf0)
[0.031s][info][class,init] 228 Initializing java/net/URL$3'java/net/URL$3'(no method) (0x000000080008a7b8)
[0.031s][info][class,init] 229 Initializing java/io/File$PathStatus'java/io/File$PathStatus' (0x000000080008b0c8)
[0.031s][info][class,init] 230 Initializing sun/net/www/ParseUtil'sun/net/www/ParseUtil' (0x000000080008a5a8)
[0.031s][info][class,init] 231 Initializing java/util/HexFormat'java/util/HexFormat' (0x000000080008c9e8)
[0.031s][info][class,init] 232 Initializing java/net/URLStreamHandler'java/net/URLStreamHandler'(no method) (0x0000000800197d98)
[0.031s][info][class,init] 233 Initializing sun/net/www/protocol/file/Handler'sun/net/www/protocol/file/Handler'(no method) (0x0000000800198480)
[0.031s][info][class,init] 234 Initializing sun/net/util/IPAddressUtil'sun/net/util/IPAddressUtil' (0x00000008000872f8)
[0.032s][info][class,init] 235 Initializing jdk/internal/util/Preconditions'jdk/internal/util/Preconditions'(no method) (0x00000008000870e8)
[0.032s][info][class,init] 236 Initializing java/lang/invoke/StringConcatFactory'java/lang/invoke/StringConcatFactory' (0x000000080001d230)
[0.032s][info][class,init] 237 Initializing java/util/function/Function'java/util/function/Function'(no method) (0x00000008001034f8)
[0.032s][info][class,init] 238 Initializing java/lang/invoke/StringConcatFactory$1'java/lang/invoke/StringConcatFactory$1'(no method) (0x0000000800210430)
[0.032s][info][class,init] 239 Initializing java/lang/invoke/StringConcatFactory$2'java/lang/invoke/StringConcatFactory$2'(no method) (0x0000000800210978)
[0.032s][info][class,init] 240 Initializing java/lang/invoke/StringConcatFactory$3'java/lang/invoke/StringConcatFactory$3'(no method) (0x0000000800040450)
[0.032s][info][class,init] 241 Initializing java/nio/CharBuffer'java/nio/CharBuffer' (0x00000008000798f8)
[0.032s][info][class,init] 242 Initializing java/nio/HeapCharBuffer'java/nio/HeapCharBuffer' (0x0000000800079f80)
[0.032s][info][class,init] 243 Initializing java/nio/charset/CoderResult'java/nio/charset/CoderResult' (0x00000008000a8bd0)
openjdk version "18-internal" 2022-03-15
OpenJDK Runtime Environment (build 18-internal+0-adhoc.qingfengyy.jdktip)
OpenJDK 64-Bit Server VM (build 18-internal+0-adhoc.qingfengyy.jdktip, mixed mode, sharing)
[0.033s][info][class,init] 244 Initializing java/lang/Shutdown'java/lang/Shutdown' (0x000000080004c3a0)
[0.033s][info][class,init] 245 Initializing java/lang/Shutdown$Lock'java/lang/Shutdown$Lock'(no method) (0x0000000800024a40)

It looks this patch will not affect the initialization order.

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

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

From pconcannon at openjdk.java.net  Mon Jul  5 09:11:52 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Mon, 5 Jul 2021 09:11:52 GMT
Subject: Integrated: 8269124: Update java.time to use switch expressions (part
 II)
In-Reply-To: <gWxnxFurKCz661GQXfULGi2g_xpcVXXlJVg0JCMwOoY=.629dc4ac-0633-483a-8436-35c4d66b4c7b@github.com>
References: <gWxnxFurKCz661GQXfULGi2g_xpcVXXlJVg0JCMwOoY=.629dc4ac-0633-483a-8436-35c4d66b4c7b@github.com>
Message-ID: <nB91h1JmMGUXSWVT-jkPrABxMkHskQUimG3UfClD9ps=.2e893422-a66e-4562-9899-c6be9955b0c7@github.com>

On Tue, 22 Jun 2021 10:50:17 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

> Hi,
> 
> Could someone please review the second half of my update for the `java.time` package to make use of switch expressions?
> 
> This PR was split into two parts due to the large number of files affected.
> 
> Kind regards,
> 
> Patrick

This pull request has now been integrated.

Changeset: 8a7b380e
Author:    Patrick Concannon <pconcannon at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/8a7b380ebb1484c6eca9ed64130aaee4a63c473a
Stats:     371 lines in 16 files changed: 1 ins; 49 del; 321 mod

8269124: Update java.time to use switch expressions (part II)

Reviewed-by: dfuchs, vtewari, aefimov, iris, lancea, naoto

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

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

From dfuchs at openjdk.java.net  Mon Jul  5 11:29:07 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Mon, 5 Jul 2021 11:29:07 GMT
Subject: [jdk17] RFR: 8269772: [macos-aarch64] test compilation failed with
 "SocketException: No buffer space available"
Message-ID: <peb9XuwB6sz2hcL2fJ0JPP3KpQhuHraqldsTUlp_72Q=.2262df95-97c5-47c6-8f68-475b216665f0@github.com>

Please find here a trivial fix for:

8269772: [macos-aarch64] test compilation failed with "SocketException: No buffer space available"

Running several of the websocket tests concurrently on some of the CI machines is causing resource exhaustion, because resources are only freed after the TIMED_WAIT delay has expired once the tests have finished.
The proposed solution is to run these tests in exclusive dir mode.

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

Commit messages:
 - 8269772: [macos-aarch64] test compilation failed with "SocketException: No buffer space available"

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

PR: https://git.openjdk.java.net/jdk17/pull/210

From github.com+5709644+fdesu at openjdk.java.net  Tue Jul  6 08:22:52 2021
From: github.com+5709644+fdesu at openjdk.java.net (Sergei Ustimenko)
Date: Tue, 6 Jul 2021 08:22:52 GMT
Subject: RFR: 8268788: Annotations with lambda expressions can still cause
 AnnotationFormatError
In-Reply-To: <bpL0zFO_yqPTN3RmIqZDewVVo6ONeHrd9C8IWW4tWqI=.b966fff2-f54b-4fed-9c5a-2c341cbc52b5@github.com>
References: <bpL0zFO_yqPTN3RmIqZDewVVo6ONeHrd9C8IWW4tWqI=.b966fff2-f54b-4fed-9c5a-2c341cbc52b5@github.com>
Message-ID: <k0iSZHPU3aoeg_i0cAzaJBrgsf_g0lTIqrvH_lGieBg=.af73d6e2-55fb-4381-a004-2bd13f2d1f07@github.com>

On Wed, 30 Jun 2021 20:08:27 GMT, Sergei Ustimenko <github.com+5709644+fdesu at openjdk.org> wrote:

> Change #3294 helps to avoid `AnnotaionFormatException` in `sun.reflect.annotation.AnnotationInvocationHandler.validateAnnotationMethods`. While it fixes the case with e.g. `Runnable`  that generates the synthetic method without parameters, validation still fails on synthetic methods that have parameters e.g. `Function`, `BiFunction`, etc.
> 
> This change removes the restriction on parameters count to be zero i.e. lambdas with parameters
> would be skipped from validation.

Hi, I would appreciate if anyone could take a look and let me know their opinion. Removing the `parameters count  == 0` condition from the sun.reflect.annotation.AnnotationInvocationHandler:507 fixes the problem, though I'm not entirely sure if it brings some risks with it.

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

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

From mcimadamore at openjdk.java.net  Tue Jul  6 09:57:53 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 6 Jul 2021 09:57:53 GMT
Subject: [jdk17] RFR: 8268766: Desugaring of pattern matching enum switch
 should be improved [v6]
In-Reply-To: <DZSIdsWsALvwnPyeyqWxzNtM6p6pE03YWsCQNRqemnI=.27ca4e43-bac6-4cc5-b96e-792447ccc400@github.com>
References: <3xKa946t0s_eRqnj0vfgjkfurBvZqKGe1QkYk-0lNO0=.518519f5-a2cb-44ed-946c-09e517e7c5d2@github.com>
 <DZSIdsWsALvwnPyeyqWxzNtM6p6pE03YWsCQNRqemnI=.27ca4e43-bac6-4cc5-b96e-792447ccc400@github.com>
Message-ID: <KLh44iEbEu-VPRsTqVMe4wq2dRYqchdswwEvnEAVc_Q=.2c027719-518f-4962-91c8-f46cc02ad14d@github.com>

On Wed, 30 Jun 2021 10:23:32 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Currently, an enum switch with patterns is desugared in a very non-standard, and potentially slow, way. It would be better to use the standard `typeSwitch` bootstrap to classify the enum constants. The bootstrap needs to accept enum constants as labels in order to allow this. A complication is that if an enum constant is missing, that is not an incompatible change for the switch, and the switch should simply work as if the case for the missing constant didn't exist. So, the proposed solution is to have a new bootstrap `enumSwitch` that accepts `String`s in place of the enum constants, and will internally convert them to the appropriate enum constants, and then it will find the proper case similarly to `typeSwitch`.
>> 
>> How does this look?
>
> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:
> 
>  - Reflecting review comments.
>  - Merge branch 'master' into JDK-8268766
>  - Improving javadoc.
>  - Updating javadoc, as suggested.
>  - Updating javadoc, code and tests as suggested.
>  - Creating a new bootstrap method for (pattern matching) enum switches, as suggested.
>  - Adding and fixing test.
>  - Merging master.
>  - 8268766: Desugaring of pattern matching enum switch should be improved

Looks good - added minor cosmetic comments

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 205:

> 203:      *
> 204:      * @param lookup Represents a lookup context with the accessibility
> 205:      *               privileges of the caller.  When used with {@code invokedynamic},

Suggestion:

     *               privileges of the caller. When used with {@code invokedynamic},

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 216:

> 214:      * @throws NullPointerException if any argument is {@code null}
> 215:      * @throws IllegalArgumentException if any element in the labels array is null, if the
> 216:      * invocation type is not a method type of first parameter of an enum type,

Suggestion:

     * invocation type is not a method type whose first parameter type is an enum type,

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 217:

> 215:      * @throws IllegalArgumentException if any element in the labels array is null, if the
> 216:      * invocation type is not a method type of first parameter of an enum type,
> 217:      * second parameter of type {@code int} and with {@code int} as its return type,

Suggestion:

     * second parameter of type {@code int} and whose return type is {@code int},

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

Marked as reviewed by mcimadamore (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/81

From chegar at openjdk.java.net  Tue Jul  6 10:17:50 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Tue, 6 Jul 2021 10:17:50 GMT
Subject: [jdk17] RFR: 8269772: [macos-aarch64] test compilation failed
 with "SocketException: No buffer space available"
In-Reply-To: <peb9XuwB6sz2hcL2fJ0JPP3KpQhuHraqldsTUlp_72Q=.2262df95-97c5-47c6-8f68-475b216665f0@github.com>
References: <peb9XuwB6sz2hcL2fJ0JPP3KpQhuHraqldsTUlp_72Q=.2262df95-97c5-47c6-8f68-475b216665f0@github.com>
Message-ID: <rkT0OmDVGnG5CfNFXgzkNqRnv4zgvrYhkolGuyHGe6c=.997b1f14-2611-48c6-8753-a40d156216ac@github.com>

On Mon, 5 Jul 2021 11:21:39 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Please find here a trivial fix for:
> 
> 8269772: [macos-aarch64] test compilation failed with "SocketException: No buffer space available"
> 
> Running several of the websocket tests concurrently on some of the CI machines is causing resource exhaustion, because resources are only freed after the TIMED_WAIT delay has expired once the tests have finished.
> The proposed solution is to run these tests in exclusive dir mode.

Marked as reviewed by chegar (Reviewer).

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

PR: https://git.openjdk.java.net/jdk17/pull/210

From avoitylov at openjdk.java.net  Tue Jul  6 11:18:55 2021
From: avoitylov at openjdk.java.net (Aleksei Voitylov)
Date: Tue, 6 Jul 2021 11:18:55 GMT
Subject: Integrated: 8266310: deadlock between System.loadLibrary and JNI
 FindClass loading another class
In-Reply-To: <G1Dj5KxeKo9tRDZp1FnOMORM39XHS-qfyvrdzj-0ejg=.fd465e4e-46a9-4034-a49f-aec40218cd11@github.com>
References: <G1Dj5KxeKo9tRDZp1FnOMORM39XHS-qfyvrdzj-0ejg=.fd465e4e-46a9-4034-a49f-aec40218cd11@github.com>
Message-ID: <ACgxLRSOo6-ZuPc_UJs4GSgEYONanmQcclZW_B1aNS8=.0047e9e4-2b87-4864-9747-e47d9f483db9@github.com>

On Tue, 11 May 2021 13:10:30 GMT, Aleksei Voitylov <avoitylov at openjdk.org> wrote:

> Please review this PR which fixes the deadlock in ClassLoader between the two lock objects - a lock object associated with the class being loaded, and the ClassLoader.loadedLibraryNames hash map, locked during the native library load operation.
> 
> Problem being fixed:
> 
> The initial reproducer demonstrated a deadlock between the JarFile/ZipFile and the hash map. That deadlock exists even when the ZipFile/JarFile lock is removed because there's another lock object in the class loader, associated with the name of the class being loaded. Such objects are stored in ClassLoader.parallelLockMap. The deadlock occurs when JNI_OnLoad() loads exactly the same class, whose signature is being verified in another thread.
> 
> Proposed fix:
> 
> The proposed patch suggests to get rid of locking loadedLibraryNames hash map and synchronize on each entry name, as it's done with class names in see ClassLoader.getClassLoadingLock(name) method.
> 
> The patch introduces nativeLibraryLockMap which holds the lock objects for each library name, and the getNativeLibraryLock() private method is used to lazily initialize the corresponding lock object. nativeLibraryContext was changed to ThreadLocal, so that in any concurrent thread it would have a NativeLibrary object on top of the stack, that's being currently loaded/unloaded in that thread. nativeLibraryLockMap accumulates the names of all native libraries loaded - in line with class loading code, it is not explicitly cleared.
> 
> Testing:  jtreg and jck testing with no regressions. A new regression test was developed.

This pull request has now been integrated.

Changeset: e47803a8
Author:    Aleksei Voitylov <avoitylov at openjdk.org>
Committer: Alexander Scherbatiy <alexsch at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e47803a84feb6d831c6c6158708d29b4fffc99c9
Stats:     913 lines in 10 files changed: 894 ins; 1 del; 18 mod

8266310: deadlock between System.loadLibrary and JNI FindClass loading another class

Reviewed-by: dholmes, plevart, chegar, mchung

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

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

From joe.darcy at oracle.com  Tue Jul  6 14:01:21 2021
From: joe.darcy at oracle.com (Joe Darcy)
Date: Tue, 6 Jul 2021 07:01:21 -0700
Subject: RFR: 8268788: Annotations with lambda expressions can still cause
 AnnotationFormatError
In-Reply-To: <k0iSZHPU3aoeg_i0cAzaJBrgsf_g0lTIqrvH_lGieBg=.af73d6e2-55fb-4381-a004-2bd13f2d1f07@github.com>
References: <bpL0zFO_yqPTN3RmIqZDewVVo6ONeHrd9C8IWW4tWqI=.b966fff2-f54b-4fed-9c5a-2c341cbc52b5@github.com>
 <k0iSZHPU3aoeg_i0cAzaJBrgsf_g0lTIqrvH_lGieBg=.af73d6e2-55fb-4381-a004-2bd13f2d1f07@github.com>
Message-ID: <61b87863-7f62-9ddd-eb03-39ef62ad7b0a@oracle.com>

Hello,

I should be able to look at this within the next week or two; thanks,

-Joe

On 7/6/2021 1:22 AM, Sergei Ustimenko wrote:
> On Wed, 30 Jun 2021 20:08:27 GMT, Sergei Ustimenko <github.com+5709644+fdesu at openjdk.org> wrote:
>
>> Change #3294 helps to avoid `AnnotaionFormatException` in `sun.reflect.annotation.AnnotationInvocationHandler.validateAnnotationMethods`. While it fixes the case with e.g. `Runnable`  that generates the synthetic method without parameters, validation still fails on synthetic methods that have parameters e.g. `Function`, `BiFunction`, etc.
>>
>> This change removes the restriction on parameters count to be zero i.e. lambdas with parameters
>> would be skipped from validation.
> Hi, I would appreciate if anyone could take a look and let me know their opinion. Removing the `parameters count  == 0` condition from the sun.reflect.annotation.AnnotationInvocationHandler:507 fixes the problem, though I'm not entirely sure if it brings some risks with it.
>
> -------------
>
> PR: https://git.openjdk.java.net/jdk/pull/4642

From mchung at openjdk.java.net  Tue Jul  6 15:03:49 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 6 Jul 2021 15:03:49 GMT
Subject: [jdk17] Integrated: JDK-8225667: Clarify the behavior of System::gc
 w.r.t. reference processing
In-Reply-To: <P5HIv6qhUDaRF1LiEYjyLdvKPUK9CNH81gsb8Ja4UEw=.2a1eab1a-4b88-4d41-85b4-8ffedb39cdc7@github.com>
References: <P5HIv6qhUDaRF1LiEYjyLdvKPUK9CNH81gsb8Ja4UEw=.2a1eab1a-4b88-4d41-85b4-8ffedb39cdc7@github.com>
Message-ID: <1EkeUCIldt7ndOvo7DkpCMp183EQJn971cYPpQRqCVc=.f8ada7fd-c5ff-4438-949b-bf7e04e3c0db@github.com>

On Wed, 30 Jun 2021 18:24:24 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> This spec clarification is a follow-up to [JDK-8224760](https://bugs.openjdk.java.net/browse/JDK-8224760?focusedCommentId=14268320&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14268320) w.r.t. reference processing.  Since there is no guarantee for any memory reclamation by the invocation of `System::gc`, the spec should also clarify that there is no guarantee in determining the change of reachability of any objects or any particular number of `Reference` objects be enqueued and cleared.
> 
> CSR:
>    https://bugs.openjdk.java.net/browse/JDK-8269690

This pull request has now been integrated.

Changeset: 3a690240
Author:    Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.java.net/jdk17/commit/3a690240336bda8582a15ca52f4dcb78be323dcd
Stats:     9 lines in 2 files changed: 9 ins; 0 del; 0 mod

8225667: Clarify the behavior of System::gc w.r.t. reference processing

Reviewed-by: rriggs, kbarrett, tschatzl

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

PR: https://git.openjdk.java.net/jdk17/pull/183

From github.com+10835776+stsypanov at openjdk.java.net  Tue Jul  6 15:12:17 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Tue, 6 Jul 2021 15:12:17 GMT
Subject: RFR: 8266972: Use String.concat() in j.l.Class where
 invokedynamic-based String concatenation is not available [v5]
In-Reply-To: <mmH_gQ8uVQa6VMhBzCMHjdgL7wpmwll5DKxnfuS0U9A=.82977d2b-d934-471e-94b6-dd5ef90c037c@github.com>
References: <mmH_gQ8uVQa6VMhBzCMHjdgL7wpmwll5DKxnfuS0U9A=.82977d2b-d934-471e-94b6-dd5ef90c037c@github.com>
Message-ID: <4sqsossvJYA8izzYLGmgQJbIG4EUC26lG06xKAAiqMw=.c2ce0df4-3f9b-4499-b442-8a147b0d830f@github.com>

> Hello, from discussion in https://github.com/openjdk/jdk/pull/3464 I've found out, that in a few of JDK core classes, e.g. in `j.l.Class` expressions like `baseName.replace('.', '/') + '/' + name` are not compiled into `invokedynamic`-based code, but into one using `StringBuilder`. This happens due to some bootstraping issues.
> 
> However the code like
> 
> private String getSimpleName0() {
>     if (isArray()) {
>         return getComponentType().getSimpleName() + "[]";
>     }
>     //...
> }
> 
> can be improved via replacement of `+` with `String.concat()` call.
> 
> I've used this benchmark to measure impact:
> 
> @State(Scope.Thread)
> @BenchmarkMode(Mode.AverageTime)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"})
> public class ClassMethodsBenchmark {
>   private final Class<? extends Object[]> arrayClass = Object[].class;
>   private Method descriptorString;
> 
>   @Setup
>   public void setUp() throws NoSuchMethodException {
>     //fore some reason compiler doesn't allow me to call Class.descriptorString() directly
>     descriptorString = Class.class.getDeclaredMethod("descriptorString");
>   }
> 
>   @Benchmark
>   public Object descriptorString() throws Exception {
>     return descriptorString.invoke(arrayClass);
>   }
> 
>   @Benchmark
>   public Object typeName() {
>     return arrayClass.getTypeName();
>   }
> }
> 
> and got those results
> 
>                                                    Mode  Cnt     Score     Error   Units
> descriptorString                                   avgt   60    91.480 ?   1.839   ns/op
> descriptorString:?gc.alloc.rate.norm               avgt   60   404.008 ?   4.033    B/op
> descriptorString:?gc.churn.G1_Eden_Space           avgt   60  2791.866 ? 181.589  MB/sec
> descriptorString:?gc.churn.G1_Eden_Space.norm      avgt   60   401.702 ?  26.047    B/op
> descriptorString:?gc.churn.G1_Survivor_Space       avgt   60     0.003 ?   0.001  MB/sec
> descriptorString:?gc.churn.G1_Survivor_Space.norm  avgt   60    ? 10??              B/op
> descriptorString:?gc.count                         avgt   60   205.000            counts
> descriptorString:?gc.time                          avgt   60   216.000                ms
> 
> patched
>                                                    Mode  Cnt     Score     Error   Units
> descriptorString                                   avgt   60    65.016 ?   3.446   ns/op
> descriptorString:?gc.alloc.rate                    avgt   60  2844.240 ? 115.719  MB/sec
> descriptorString:?gc.alloc.rate.norm               avgt   60   288.006 ?   0.001    B/op
> descriptorString:?gc.churn.G1_Eden_Space           avgt   60  2832.996 ? 206.939  MB/sec
> descriptorString:?gc.churn.G1_Eden_Space.norm      avgt   60   286.955 ?  17.853    B/op
> descriptorString:?gc.churn.G1_Survivor_Space       avgt   60     0.003 ?   0.001  MB/sec
> descriptorString:?gc.churn.G1_Survivor_Space.norm  avgt   60    ? 10??              B/op
> descriptorString:?gc.count                         avgt   60   208.000            counts
> descriptorString:?gc.time                          avgt   60   228.000                ms
> -----------------
> typeName                                           avgt   60    34.273 ?   0.480   ns/op
> typeName:?gc.alloc.rate                            avgt   60  3265.356 ?  45.113  MB/sec
> typeName:?gc.alloc.rate.norm                       avgt   60   176.004 ?   0.001    B/op
> typeName:?gc.churn.G1_Eden_Space                   avgt   60  3268.454 ? 134.458  MB/sec
> typeName:?gc.churn.G1_Eden_Space.norm              avgt   60   176.109 ?   6.595    B/op
> typeName:?gc.churn.G1_Survivor_Space               avgt   60     0.003 ?   0.001  MB/sec
> typeName:?gc.churn.G1_Survivor_Space.norm          avgt   60    ? 10??              B/op
> typeName:?gc.count                                 avgt   60   240.000            counts
> typeName:?gc.time                                  avgt   60   255.000                ms
> 
> patched
> 
> typeName                                           avgt   60    15.787 ?   0.214   ns/op
> typeName:?gc.alloc.rate                            avgt   60  2577.554 ?  32.339  MB/sec
> typeName:?gc.alloc.rate.norm                       avgt   60    64.001 ?   0.001    B/op
> typeName:?gc.churn.G1_Eden_Space                   avgt   60  2574.039 ? 147.774  MB/sec
> typeName:?gc.churn.G1_Eden_Space.norm              avgt   60    63.895 ?   3.511    B/op
> typeName:?gc.churn.G1_Survivor_Space               avgt   60     0.003 ?   0.001  MB/sec
> typeName:?gc.churn.G1_Survivor_Space.norm          avgt   60    ? 10??              B/op
> typeName:?gc.count                                 avgt   60   189.000            counts
> typeName:?gc.time                                  avgt   60   199.000                ms
> 
> I think this patch is likely to improve reflection operations related to arrays.
> 
> If one finds this patch useful, then I'll create a ticket to track this. Also it'd be nice to have a list of classes, that are compiled in the same way as `j.l.Class` (i.e. have no access to `invokedynamic`) so I could look into them for other snippets where two String are joined so `concat`-based optimization is possible.
> 
> Pre-sizing of `StringBuilder` for `Class.gdescriptorString()` and `Class.getCanonicalName0()` is one more improvement opportunity here.

?????? ??????? has updated the pull request with a new target base 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 class-concat
 - Merge branch 'master' into class-concat
 - Merge branch 'master' into class-concat
 - 8266972: Use String.concat() in j.l.Class.toSting()
 - Use String.concat() where invokedynamic-based String concatenation is not available

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3627/files
  - new: https://git.openjdk.java.net/jdk/pull/3627/files/9bb8380e..4fd6dc00

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

  Stats: 13994 lines in 197 files changed: 1994 ins; 11351 del; 649 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3627.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3627/head:pull/3627

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

From igraves at openjdk.java.net  Tue Jul  6 18:22:50 2021
From: igraves at openjdk.java.net (Ian Graves)
Date: Tue, 6 Jul 2021 18:22:50 GMT
Subject: RFR: 8214761: Bug in parallel Kahan summation implementation
In-Reply-To: <mlWAGmxAyWE3j375QfPA0cAZ__lfHv4jlMkT41j0EYo=.aeac1341-3d57-4c48-a4a9-b45d76adc138@github.com>
References: <inWiS2IlqFmGWsJuVSn1NP2Rn7YoYlADJ-3JeI8pfEs=.d208e206-5d71-4a8f-99e0-800d159d0905@github.com>
 <mlWAGmxAyWE3j375QfPA0cAZ__lfHv4jlMkT41j0EYo=.aeac1341-3d57-4c48-a4a9-b45d76adc138@github.com>
Message-ID: <7c3Lr3y9tjbDg_i73wlWPIfBAnNHqKGQRB7Dpn3reBI=.401a8f46-384a-44ab-89f2-60477489f2fe@github.com>

On Fri, 2 Jul 2021 21:30:56 GMT, stefan-zobel <github.com+18482851+stefan-zobel at openjdk.org> wrote:

>> 8214761: Bug in parallel Kahan summation implementation
>
> src/java.base/share/classes/java/util/DoubleSummaryStatistics.java line 161:
> 
>> 159: 
>> 160:         //Negating this value because low-order bits are in negated form
>> 161:         sumWithCompensation(-other.sumCompensation);
> 
> Wouldn't that be `double tmp =  sum - sumCompensation;` in getSum() in line 246 too?

Good catch will review and make the change.

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

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

From vdyakov at openjdk.java.net  Tue Jul  6 18:35:52 2021
From: vdyakov at openjdk.java.net (Victor Dyakov)
Date: Tue, 6 Jul 2021 18:35:52 GMT
Subject: [jdk17] RFR: 8269185: Directories in /opt/runtimepackagetest and
 /path/to/jdk-17 are different
In-Reply-To: <CXShdWkgpecXOqmQitcJf0aVXkS6IXmcJYOtm661-eE=.2967fdff-2068-4f95-99b0-3d13ab29fae9@github.com>
References: <BscK-vZBXNNXFMaWXULkoVjQWO8z0zmF8ZePhJ7Zg_k=.adcc22b8-b896-4a3f-bb6b-233ecf0db7d1@github.com>
 <CXShdWkgpecXOqmQitcJf0aVXkS6IXmcJYOtm661-eE=.2967fdff-2068-4f95-99b0-3d13ab29fae9@github.com>
Message-ID: <A2Ly7lJPNXjkvzsvsItYAR3WyoBNXypV5BFoFQ5uVqs=.ba2751f7-2e9d-4cbb-a734-ccb3c4ba9cd7@github.com>

On Sat, 3 Jul 2021 00:03:55 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> Disable stripping to prevent rpmbuild from modifying executables
>
> Marked as reviewed by almatvee (Reviewer).

@sashamatveev @herrick please review

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

PR: https://git.openjdk.java.net/jdk17/pull/207

From mchung at openjdk.java.net  Tue Jul  6 19:20:54 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 6 Jul 2021 19:20:54 GMT
Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex,
 FromIndexSize} where possible
In-Reply-To: <rKyGMmub9-W1VGCGX86Wkh9f-GdRcUtEupSXLY1Jarw=.67f42692-0937-4a4a-9331-4c5a641dc2ea@github.com>
References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
 <wnnvM-AabtvXj6GyY15k2WngzWJhz6OXWfs_PygCaWU=.17e6e99b-e808-4c9e-89cc-4af2213e301e@github.com>
 <u2TRSykc6zsKvQKGF74xka3w2odK2m0dx0HmEP0BwZc=.c8dfba1f-55b4-4e8e-a2ad-5286097ea203@github.com>
 <rKyGMmub9-W1VGCGX86Wkh9f-GdRcUtEupSXLY1Jarw=.67f42692-0937-4a4a-9331-4c5a641dc2ea@github.com>
Message-ID: <T47LfOAok-UF2NOA0biHXQjDRKbuyDc1HBXfw6LEPkM=.7cde602e-98f5-4906-9968-048ccedbc692@github.com>

On Mon, 5 Jul 2021 06:29:58 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> @dholmes-ora @AlanBateman @PaulSandoz do you have any comments on the latest version? Thanks.
>
> @kelthuzadx  I did not see any response to my query about the change in initialization (not load) order. I also remain concerned about introducing cross dependencies between core classes (e.g. String now uses Precondition, so does that impact Precondition using String?) But these are things for the core-libs folk to be concerned about, or not.
> 
> Cheers,
> David

> @dholmes-ora @AlanBateman @PaulSandoz do you have any comments on the latest version? Thanks.

Alan and Paul are currently on vacation.  I'm reviewing it.

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

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

From mchung at openjdk.java.net  Tue Jul  6 19:20:53 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 6 Jul 2021 19:20:53 GMT
Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex,
 FromIndexSize} where possible [v8]
In-Reply-To: <imrXHsfJUsxhjLQpbPTeYPTKUff42FGED1cdeB76ST8=.d7c474cb-ebad-4f63-8f88-13494086e0e6@github.com>
References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
 <imrXHsfJUsxhjLQpbPTeYPTKUff42FGED1cdeB76ST8=.d7c474cb-ebad-4f63-8f88-13494086e0e6@github.com>
Message-ID: <5xrgLnNfr6-3_nkV_85gde_VX7BWv5nSr4rL7wYHJlg=.e22fc877-564e-4a9f-a2cd-ec7e2a30b6e5@github.com>

On Wed, 23 Jun 2021 03:54:55 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in the whole JDK codebase.
>
> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   tests rely on IOOBE exception message

I suggest to separate the client changes (both src and test) in a separate PR for the client review.

I review the rest of the files, which looks okay to me.   I will take another pass carefully.

src/java.base/share/classes/java/util/concurrent/CopyOnWriteArrayList.java needs to be updated in JSR 166 upstream repo.    Better to file a separate issue for this change to ensure that gets fixed in the upstream project.

test/jdk/java/lang/StringBuffer/Exceptions.java line 73:

> 71:                 new StringBuffer();
> 72:             }
> 73:         });

Nit: The above formatting (line 70-97) is inconsistent with the formatting in line 110-124.   It'd be good to use the same formatting.

test/jdk/java/lang/StringBuilder/Exceptions.java line 73:

> 71:                 new StringBuilder();
> 72:             }
> 73:         });

Nit: it'd be good to make the formatting of all calls to tryCatch method consistent.

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

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

From jlahoda at openjdk.java.net  Tue Jul  6 20:29:47 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Tue, 6 Jul 2021 20:29:47 GMT
Subject: RFR: 8266407: remove
 jdk.internal.javac.PreviewFeature.Feature.SEALED_CLASSES
In-Reply-To: <GNaTedXAgT98ozB6uRfAVrsel4FUY6cgHKUXoZIpAgg=.fca69fa4-56a9-4f4c-ba26-8ad8232afa36@github.com>
References: <GNaTedXAgT98ozB6uRfAVrsel4FUY6cgHKUXoZIpAgg=.fca69fa4-56a9-4f4c-ba26-8ad8232afa36@github.com>
Message-ID: <2ovX7bjHRuUbakjgD91wxfwrR9DJ0_ikRwUaVwFKCfs=.cd3f652c-3766-4aa8-881b-71e51924ab7d@github.com>

On Wed, 23 Jun 2021 20:57:24 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Enum constant: jdk.internal.javac.PreviewFeature.Feature.SEALED_CLASSES was not removed when Sealed Classes were made final because the build was failing without it. Now that the feature is final we should be able to safely removed it. This is the intention of this patch.
> 
> TIA,
> Vicente

lgtm

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

Marked as reviewed by jlahoda (Reviewer).

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

From duke at openjdk.java.net  Tue Jul  6 20:48:55 2021
From: duke at openjdk.java.net (duke)
Date: Tue, 6 Jul 2021 20:48:55 GMT
Subject: Withdrawn: 8266013: Unexpected replacement character handling on
 stateful CharsetEncoder
In-Reply-To: <SoeZ13f8UIKlpsttywQzetNsNB6YjXdKNWOzPsnxDNA=.36e520b1-97a6-40aa-9f93-69265f54d553@github.com>
References: <SoeZ13f8UIKlpsttywQzetNsNB6YjXdKNWOzPsnxDNA=.36e520b1-97a6-40aa-9f93-69265f54d553@github.com>
Message-ID: <AM511_UNL5J87PjDnNqJFUxxBEw1PXBISJFnP9rpd7U=.2ef9a8a8-dda4-4914-8252-6d241fdf9588@github.com>

On Tue, 27 Apr 2021 16:49:08 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

> When an invalid character is converted by getBytes() method, the character is converted to replacement byte data.
> Shift code (SO/SI) may not be added into right place by EBCDIC Mix charset.
> EBCDIC Mix charset encoder is stateful encoder.
> Shift code should be added by switching character set.
> On x-IBM1364, "\u3000\uD800" should be converted to "\x0E\x40\x40\x0F\x6F", but "\x0E\x40\x40\x6F\x0F"
> SI is not in right place.
> 
> Also ISO2022 related charsets use escape sequence to switch character set.
> But same kind of issue is there.

This pull request has been closed without being integrated.

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

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

From jwilhelm at openjdk.java.net  Tue Jul  6 22:26:28 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Tue, 6 Jul 2021 22:26:28 GMT
Subject: RFR: Merge jdk17
Message-ID: <v-b4Iei0QwZ6unKa8SfxrM1W65SNvfvyWaHDNDB4ezg=.fbcd8f51-d88a-4be3-8535-4234379fc703@github.com>

Forwardport JDK 17 -> JDK 18

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

Commit messages:
 - Merge
 - 8269825: [TESTBUG] Missing testing for x86 KNL platforms
 - 8269955: ProblemList compiler/vectorapi/VectorCastShape[64|128]Test.java tests on x86
 - 8268966: AArch64: 'bad AD file' in some vector conversion tests
 - 8225667: Clarify the behavior of System::gc w.r.t. reference processing
 - 8269568: JVM crashes when running VectorMask query tests
 - 8269661: JNI_GetStringCritical does not lock char array
 - 8269575: C2: assert(false) failed: graph should be schedulable after JDK-8252372
 - 8268883: C2: assert(false) failed: unscheduable graph
 - 8268369: SIGSEGV in PhaseCFG::implicit_null_check due to missing null check

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

Changes: https://git.openjdk.java.net/jdk/pull/4698/files
  Stats: 3666 lines in 51 files changed: 2827 ins; 351 del; 488 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4698.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4698/head:pull/4698

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

From jwilhelm at openjdk.java.net  Tue Jul  6 23:05:13 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Tue, 6 Jul 2021 23:05:13 GMT
Subject: RFR: Merge jdk17 [v2]
In-Reply-To: <v-b4Iei0QwZ6unKa8SfxrM1W65SNvfvyWaHDNDB4ezg=.fbcd8f51-d88a-4be3-8535-4234379fc703@github.com>
References: <v-b4Iei0QwZ6unKa8SfxrM1W65SNvfvyWaHDNDB4ezg=.fbcd8f51-d88a-4be3-8535-4234379fc703@github.com>
Message-ID: <uCGTSXxUkRNdxpqJlwaEMKkZIwDoBrSkwhxlIpWf_WU=.39b0cd32-099f-4199-bb3e-a9577a9f8a42@github.com>

> Forwardport JDK 17 -> JDK 18

Jesper Wilhelmsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 164 commits:

 - Merge
 - 8269935: ProblemList runtime/jni/checked/TestPrimitiveArrayCriticalWithBadParam.java on windows
   
   Reviewed-by: jjg
 - 8269917: Insert missing commas in copyrights in java.net
   
   Reviewed-by: chegar, dfuchs
 - 8253119: Remove the legacy PlainSocketImpl and PlainDatagramSocketImpl implementation
   
   Reviewed-by: alanb, dfuchs, chegar
 - 8269692: sun.net.httpserver.ServerImpl::createContext should throw IAE
   
   Reviewed-by: dfuchs
 - 8269697: JNI_GetPrimitiveArrayCritical() should not accept object array
   
   Reviewed-by: kbarrett, dholmes
 - 8266310: deadlock between System.loadLibrary and JNI FindClass loading another class
   
   Reviewed-by: dholmes, plevart, chegar, mchung
 - 8269882: stack-use-after-scope in NewObjectA
   
   Reviewed-by: kbarrett
 - 8269672: C1: Remove unaligned move on all architectures
   
   Co-authored-by: Martin Doerr <mdoerr at openjdk.org>
   Reviewed-by: thartmann
 - 8267956: C1 code cleanup
   
   Reviewed-by: thartmann
 - ... and 154 more: https://git.openjdk.java.net/jdk/compare/0d1cd3a7...b68ba015

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

Changes: https://git.openjdk.java.net/jdk/pull/4698/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4698&range=01
  Stats: 46385 lines in 833 files changed: 20688 ins; 22823 del; 2874 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4698.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4698/head:pull/4698

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

From jwilhelm at openjdk.java.net  Tue Jul  6 23:05:14 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Tue, 6 Jul 2021 23:05:14 GMT
Subject: Integrated: Merge jdk17
In-Reply-To: <v-b4Iei0QwZ6unKa8SfxrM1W65SNvfvyWaHDNDB4ezg=.fbcd8f51-d88a-4be3-8535-4234379fc703@github.com>
References: <v-b4Iei0QwZ6unKa8SfxrM1W65SNvfvyWaHDNDB4ezg=.fbcd8f51-d88a-4be3-8535-4234379fc703@github.com>
Message-ID: <WODnqRu2xve0hH4bB_AkXy2UcBOE0DG60kwMsYQGOHY=.778e5e3d-683c-4372-9dca-96059b5d4663@github.com>

On Tue, 6 Jul 2021 22:16:07 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 17 -> JDK 18

This pull request has now been integrated.

Changeset: 7a4f08ae
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/7a4f08ae32ede32beb05f6e5e0a266943b91b1ee
Stats:     3666 lines in 51 files changed: 2827 ins; 351 del; 488 mod

Merge

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

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

From vromero at openjdk.java.net  Tue Jul  6 23:08:57 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Tue, 6 Jul 2021 23:08:57 GMT
Subject: Integrated: 8266407: remove
 jdk.internal.javac.PreviewFeature.Feature.SEALED_CLASSES
In-Reply-To: <GNaTedXAgT98ozB6uRfAVrsel4FUY6cgHKUXoZIpAgg=.fca69fa4-56a9-4f4c-ba26-8ad8232afa36@github.com>
References: <GNaTedXAgT98ozB6uRfAVrsel4FUY6cgHKUXoZIpAgg=.fca69fa4-56a9-4f4c-ba26-8ad8232afa36@github.com>
Message-ID: <o9E4PErBXNQcqpys3sxsifZmgFg88TW-B9XasB43VpM=.55cf7908-4299-4f08-81be-ec7ca40a8f32@github.com>

On Wed, 23 Jun 2021 20:57:24 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Enum constant: jdk.internal.javac.PreviewFeature.Feature.SEALED_CLASSES was not removed when Sealed Classes were made final because the build was failing without it. Now that the feature is final we should be able to safely removed it. This is the intention of this patch.
> 
> TIA,
> Vicente

This pull request has now been integrated.

Changeset: 01c29d8f
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/01c29d8f2c865009c0d5379ba2e2cd4d3015f018
Stats:     4 lines in 1 file changed: 0 ins; 4 del; 0 mod

8266407: remove jdk.internal.javac.PreviewFeature.Feature.SEALED_CLASSES

Reviewed-by: jlahoda

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

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

From duke at openjdk.java.net  Wed Jul  7 00:46:55 2021
From: duke at openjdk.java.net (duke)
Date: Wed, 7 Jul 2021 00:46:55 GMT
Subject: Withdrawn: 8266578: Disambiguate BigDecimal description of scale
In-Reply-To: <zYi0BeuAeqGR9D_Nyi8SZj8NsHr-JTzjDrYTvHlZiow=.2e7489e8-369c-4040-9345-d836d828e985@github.com>
References: <zYi0BeuAeqGR9D_Nyi8SZj8NsHr-JTzjDrYTvHlZiow=.2e7489e8-369c-4040-9345-d836d828e985@github.com>
Message-ID: <uEIa-A-2VSCxxqfdzqGK_52Jy6DsOwO27hFNKa1xeC4=.c087269d-12f1-4113-9047-bc03478edfb8@github.com>

On Fri, 9 Oct 2020 16:14:59 GMT, Ignasi Marimon-Clos <github.com+762126+ignasi35 at openjdk.org> wrote:

> The API Docs for `BigDecimal` introduce the meaning of `scale`. The current writeup can be missleading when presenting the meaning of a `scale` value that's negative. Hopefully, with this PR, the sentence is more clear.
> 
> The ambiguity is on this sentence:
> 
>> If negative, the unscaled value of the number is ...
> 
> Instead, I suggest the more verbose:
> 
>> If the scale is negative, the unscaled value of the number is ...
> 
> To keep symmetry, I've also reviewed the positive case from:
> 
>> If zero or positive, the scale is the number of digits ...
> 
> to: 
> 
>> If the scale is zero or positive, the scale is the number of digits ...

This pull request has been closed without being integrated.

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

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

From yyang at openjdk.java.net  Wed Jul  7 02:18:12 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Wed, 7 Jul 2021 02:18:12 GMT
Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex,
 FromIndexSize} where possible [v9]
In-Reply-To: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
Message-ID: <Ya5eZhM6WCzGfHV2UzYNXEQVV8obE5xRhfzJg9JuNyQ=.4e951e8c-ccc6-4573-9db8-091f230d6742@github.com>

> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in the whole JDK codebase.

Yi Yang has updated the pull request incrementally with four additional commits since the last revision:

 - restore code format
 - restore code format
 - restore code format
 - restore code format

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4507/files
  - new: https://git.openjdk.java.net/jdk/pull/4507/files/ab1b509d..f43ffc3a

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

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

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

From yyang at openjdk.java.net  Wed Jul  7 02:18:13 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Wed, 7 Jul 2021 02:18:13 GMT
Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex,
 FromIndexSize} where possible [v8]
In-Reply-To: <5xrgLnNfr6-3_nkV_85gde_VX7BWv5nSr4rL7wYHJlg=.e22fc877-564e-4a9f-a2cd-ec7e2a30b6e5@github.com>
References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
 <imrXHsfJUsxhjLQpbPTeYPTKUff42FGED1cdeB76ST8=.d7c474cb-ebad-4f63-8f88-13494086e0e6@github.com>
 <5xrgLnNfr6-3_nkV_85gde_VX7BWv5nSr4rL7wYHJlg=.e22fc877-564e-4a9f-a2cd-ec7e2a30b6e5@github.com>
Message-ID: <7AYfiggiXSOnvK9Vi3mIUmJMT54MQqBQRygezjGvXPU=.33f0f6bb-0fa9-4f03-9151-c7c68afadbc1@github.com>

On Tue, 6 Jul 2021 19:06:43 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   tests rely on IOOBE exception message
>
> test/jdk/java/lang/StringBuffer/Exceptions.java line 73:
> 
>> 71:                 new StringBuffer();
>> 72:             }
>> 73:         });
> 
> Nit: The above formatting (line 70-97) is inconsistent with the formatting in line 110-124.   It'd be good to use the same formatting.

Hi Mandy, thanks for reviewing this. 

> I suggest to separate the client changes (both src and test) in a separate PR for the client review.

Does "client changes" means changes involving src/java.desktop and test/java/awt?

> src/java.base/share/classes/java/util/concurrent/CopyOnWriteArrayList.java needs to be updated in JSR 166 upstream repo. Better to file a separate issue for this change to ensure that gets fixed in the upstream project.

Can you please paste a link for that? I'm not sure where I can find JSR 166 upstream repo..

> Nit: The above formatting (line 70-97) is inconsistent with the formatting in line 110-124. It'd be good to use the same formatting.

Restored.

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

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

From yyang at openjdk.java.net  Wed Jul  7 02:23:19 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Wed, 7 Jul 2021 02:23:19 GMT
Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex,
 FromIndexSize} where possible [v10]
In-Reply-To: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
Message-ID: <B94vxaOc5uZ44iZ_uwLPB9dJ9nuXp7gSazGq_Qwfkvo=.12ae4ddc-f30d-4437-9ade-78fe579b6162@github.com>

> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in the whole JDK codebase.

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

 - restore code format
 - restore code format

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4507/files
  - new: https://git.openjdk.java.net/jdk/pull/4507/files/f43ffc3a..903f0305

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

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

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

From vtewari at openjdk.java.net  Wed Jul  7 04:27:51 2021
From: vtewari at openjdk.java.net (Vyom Tewari)
Date: Wed, 7 Jul 2021 04:27:51 GMT
Subject: [jdk17] RFR: 8269772: [macos-aarch64] test compilation failed
 with "SocketException: No buffer space available"
In-Reply-To: <peb9XuwB6sz2hcL2fJ0JPP3KpQhuHraqldsTUlp_72Q=.2262df95-97c5-47c6-8f68-475b216665f0@github.com>
References: <peb9XuwB6sz2hcL2fJ0JPP3KpQhuHraqldsTUlp_72Q=.2262df95-97c5-47c6-8f68-475b216665f0@github.com>
Message-ID: <zfQxIe-T90C7JrFHehg-v8fNdiDW0q0jw2q298Eyw8k=.86e4145f-b1c2-424f-a3ea-0571956ec6cc@github.com>

On Mon, 5 Jul 2021 11:21:39 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Please find here a trivial fix for:
> 
> 8269772: [macos-aarch64] test compilation failed with "SocketException: No buffer space available"
> 
> Running several of the websocket tests concurrently on some of the CI machines is causing resource exhaustion, because resources are only freed after the TIMED_WAIT delay has expired once the tests have finished.
> The proposed solution is to run these tests in exclusive dir mode.

Marked as reviewed by vtewari (Committer).

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

PR: https://git.openjdk.java.net/jdk17/pull/210

From jlahoda at openjdk.java.net  Wed Jul  7 06:08:13 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Wed, 7 Jul 2021 06:08:13 GMT
Subject: [jdk17] RFR: 8268766: Desugaring of pattern matching enum switch
 should be improved [v7]
In-Reply-To: <3xKa946t0s_eRqnj0vfgjkfurBvZqKGe1QkYk-0lNO0=.518519f5-a2cb-44ed-946c-09e517e7c5d2@github.com>
References: <3xKa946t0s_eRqnj0vfgjkfurBvZqKGe1QkYk-0lNO0=.518519f5-a2cb-44ed-946c-09e517e7c5d2@github.com>
Message-ID: <bZr8fPegXetaH0ohHKkL2jm2jCdyej9ijKqxPyoeAjI=.ebf12a35-1785-423d-93ba-8e1afb273bec@github.com>

> Currently, an enum switch with patterns is desugared in a very non-standard, and potentially slow, way. It would be better to use the standard `typeSwitch` bootstrap to classify the enum constants. The bootstrap needs to accept enum constants as labels in order to allow this. A complication is that if an enum constant is missing, that is not an incompatible change for the switch, and the switch should simply work as if the case for the missing constant didn't exist. So, the proposed solution is to have a new bootstrap `enumSwitch` that accepts `String`s in place of the enum constants, and will internally convert them to the appropriate enum constants, and then it will find the proper case similarly to `typeSwitch`.
> 
> How does this look?

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

  Apply suggestions from code review
  
  Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/81/files
  - new: https://git.openjdk.java.net/jdk17/pull/81/files/ca79b2bd..469254a4

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

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

PR: https://git.openjdk.java.net/jdk17/pull/81

From dfuchs at openjdk.java.net  Wed Jul  7 07:53:49 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 7 Jul 2021 07:53:49 GMT
Subject: [jdk17] Integrated: 8269772: [macos-aarch64] test compilation failed
 with "SocketException: No buffer space available"
In-Reply-To: <peb9XuwB6sz2hcL2fJ0JPP3KpQhuHraqldsTUlp_72Q=.2262df95-97c5-47c6-8f68-475b216665f0@github.com>
References: <peb9XuwB6sz2hcL2fJ0JPP3KpQhuHraqldsTUlp_72Q=.2262df95-97c5-47c6-8f68-475b216665f0@github.com>
Message-ID: <m8gNy6kO6Yv_ShW1LSw_-ue7gZV8-kffaF0hvPx2V0M=.e87a953e-1421-4807-8d85-adfd16a1504f@github.com>

On Mon, 5 Jul 2021 11:21:39 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Please find here a trivial fix for:
> 
> 8269772: [macos-aarch64] test compilation failed with "SocketException: No buffer space available"
> 
> Running several of the websocket tests concurrently on some of the CI machines is causing resource exhaustion, because resources are only freed after the TIMED_WAIT delay has expired once the tests have finished.
> The proposed solution is to run these tests in exclusive dir mode.

This pull request has now been integrated.

Changeset: a49b1dc7
Author:    Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.java.net/jdk17/commit/a49b1dc7042d8893d9ff2cdaeae05203dd18bba4
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8269772: [macos-aarch64] test compilation failed with "SocketException: No buffer space available"

Reviewed-by: chegar, vtewari

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

PR: https://git.openjdk.java.net/jdk17/pull/210

From mcimadamore at openjdk.java.net  Wed Jul  7 09:46:52 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 7 Jul 2021 09:46:52 GMT
Subject: [jdk17] RFR: 8268766: Desugaring of pattern matching enum switch
 should be improved [v7]
In-Reply-To: <bZr8fPegXetaH0ohHKkL2jm2jCdyej9ijKqxPyoeAjI=.ebf12a35-1785-423d-93ba-8e1afb273bec@github.com>
References: <3xKa946t0s_eRqnj0vfgjkfurBvZqKGe1QkYk-0lNO0=.518519f5-a2cb-44ed-946c-09e517e7c5d2@github.com>
 <bZr8fPegXetaH0ohHKkL2jm2jCdyej9ijKqxPyoeAjI=.ebf12a35-1785-423d-93ba-8e1afb273bec@github.com>
Message-ID: <4qlXx3Wr0P_28ZEfODwiLKdkiyBm9c6Zqg6J5SV4Nzk=.23c35dee-de62-4514-b07d-8ef1024cb9e6@github.com>

On Wed, 7 Jul 2021 06:08:13 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Currently, an enum switch with patterns is desugared in a very non-standard, and potentially slow, way. It would be better to use the standard `typeSwitch` bootstrap to classify the enum constants. The bootstrap needs to accept enum constants as labels in order to allow this. A complication is that if an enum constant is missing, that is not an incompatible change for the switch, and the switch should simply work as if the case for the missing constant didn't exist. So, the proposed solution is to have a new bootstrap `enumSwitch` that accepts `String`s in place of the enum constants, and will internally convert them to the appropriate enum constants, and then it will find the proper case similarly to `typeSwitch`.
>> 
>> How does this look?
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply suggestions from code review
>   
>   Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>

Marked as reviewed by mcimadamore (Reviewer).

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

PR: https://git.openjdk.java.net/jdk17/pull/81

From herrick at openjdk.java.net  Wed Jul  7 11:17:49 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Wed, 7 Jul 2021 11:17:49 GMT
Subject: [jdk17] RFR: 8269185: Directories in /opt/runtimepackagetest and
 /path/to/jdk-17 are different
In-Reply-To: <BscK-vZBXNNXFMaWXULkoVjQWO8z0zmF8ZePhJ7Zg_k=.adcc22b8-b896-4a3f-bb6b-233ecf0db7d1@github.com>
References: <BscK-vZBXNNXFMaWXULkoVjQWO8z0zmF8ZePhJ7Zg_k=.adcc22b8-b896-4a3f-bb6b-233ecf0db7d1@github.com>
Message-ID: <4_0uNtDUPY47o5bEioxDatmao9aYYaoOFzXjrf73CHs=.57876a98-9ce1-43d4-9810-bc122f28bd44@github.com>

On Fri, 2 Jul 2021 22:17:09 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Disable stripping to prevent rpmbuild from modifying executables

Marked as reviewed by herrick (Reviewer).

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

PR: https://git.openjdk.java.net/jdk17/pull/207

From jlahoda at openjdk.java.net  Wed Jul  7 12:10:16 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Wed, 7 Jul 2021 12:10:16 GMT
Subject: [jdk17] RFR: 8268766: Desugaring of pattern matching enum switch
 should be improved [v8]
In-Reply-To: <3xKa946t0s_eRqnj0vfgjkfurBvZqKGe1QkYk-0lNO0=.518519f5-a2cb-44ed-946c-09e517e7c5d2@github.com>
References: <3xKa946t0s_eRqnj0vfgjkfurBvZqKGe1QkYk-0lNO0=.518519f5-a2cb-44ed-946c-09e517e7c5d2@github.com>
Message-ID: <hqsVuFvP7CwQJLmySfxkCEH_kQKTKaGYSNlcGjDdL6M=.faa8f655-403b-46de-b4c1-9f8987914aaa@github.com>

> Currently, an enum switch with patterns is desugared in a very non-standard, and potentially slow, way. It would be better to use the standard `typeSwitch` bootstrap to classify the enum constants. The bootstrap needs to accept enum constants as labels in order to allow this. A complication is that if an enum constant is missing, that is not an incompatible change for the switch, and the switch should simply work as if the case for the missing constant didn't exist. So, the proposed solution is to have a new bootstrap `enumSwitch` that accepts `String`s in place of the enum constants, and will internally convert them to the appropriate enum constants, and then it will find the proper case similarly to `typeSwitch`.
> 
> How does this look?

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

  If the pattern type is a supertype of the selector type, use selector type rather than the pattern type when constructing the bootstrap method parameters.

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

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/81/files
  - new: https://git.openjdk.java.net/jdk17/pull/81/files/469254a4..d970402e

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

  Stats: 30 lines in 2 files changed: 27 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/81.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/81/head:pull/81

PR: https://git.openjdk.java.net/jdk17/pull/81

From jlahoda at openjdk.java.net  Wed Jul  7 12:36:52 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Wed, 7 Jul 2021 12:36:52 GMT
Subject: [jdk17] RFR: 8268766: Desugaring of pattern matching enum switch
 should be improved [v8]
In-Reply-To: <hqsVuFvP7CwQJLmySfxkCEH_kQKTKaGYSNlcGjDdL6M=.faa8f655-403b-46de-b4c1-9f8987914aaa@github.com>
References: <3xKa946t0s_eRqnj0vfgjkfurBvZqKGe1QkYk-0lNO0=.518519f5-a2cb-44ed-946c-09e517e7c5d2@github.com>
 <hqsVuFvP7CwQJLmySfxkCEH_kQKTKaGYSNlcGjDdL6M=.faa8f655-403b-46de-b4c1-9f8987914aaa@github.com>
Message-ID: <ZeDJF6knx-Pt42ZGsg5wVRvgPnsvF0KX7-wrrBwfcK4=.15e66fb9-9af4-482a-b464-1b779ad37436@github.com>

On Wed, 7 Jul 2021 12:10:16 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Currently, an enum switch with patterns is desugared in a very non-standard, and potentially slow, way. It would be better to use the standard `typeSwitch` bootstrap to classify the enum constants. The bootstrap needs to accept enum constants as labels in order to allow this. A complication is that if an enum constant is missing, that is not an incompatible change for the switch, and the switch should simply work as if the case for the missing constant didn't exist. So, the proposed solution is to have a new bootstrap `enumSwitch` that accepts `String`s in place of the enum constants, and will internally convert them to the appropriate enum constants, and then it will find the proper case similarly to `typeSwitch`.
>> 
>> How does this look?
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   If the pattern type is a supertype of the selector type, use selector type rather than the pattern type when constructing the bootstrap method parameters.

There turned out to be a bug in the patch: considering a switch over enum like:

    E e = ...;
    switch (e) {
        case Object o -> {}
    }


(Or, even worse, `case Object o && <guard> ->`), the patch will generate `Object.class` as a static parameter to the `enumSwitch` bootstrap method. But the method (rightfully) requires the enum class as the static parameter. https://github.com/openjdk/jdk17/pull/81/commits/d970402e969d76a017cdfdcbc6556f6d9a9f3bfa tweaks the code generation to produce `E.class` instead of `Object.class`.

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

PR: https://git.openjdk.java.net/jdk17/pull/81

From rriggs at openjdk.java.net  Wed Jul  7 14:55:18 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 7 Jul 2021 14:55:18 GMT
Subject: [jdk17] RFR: JDK-8268826: Cleanup Override in Context-Specific
 Deserialization Filters [v7]
In-Reply-To: <CJnObVc7b8bI_aw1MiWQ4RQLb5UbhEnAy2yloODfEw0=.95dc7b4a-dba8-48d5-a9e6-cbb1bd8daef9@github.com>
References: <CJnObVc7b8bI_aw1MiWQ4RQLb5UbhEnAy2yloODfEw0=.95dc7b4a-dba8-48d5-a9e6-cbb1bd8daef9@github.com>
Message-ID: <jIwjXH_zGYrf6fsjx8Xme8iw4_mgLGUnFYnu2n6kgxI=.99f1c434-c7c6-4eef-849e-e68b2778f74d@github.com>

> Remove the unnecessary special case "OVERRIDE" in jdk.serialFilterFactory property.
> Fix description in the example of a filter allowing platform classes.
> Suppress some warnings about use of SecurityManager in tests.

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

  Update SerialFactoryExample.PredicateFilter to match the OIF implementation
  Test cleanup; enable logging of serialization on the command line (remove static)
  Remove obsolete comment about jdk.serialFilter
  Fix typo in StaticProperty.java

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

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/85/files
  - new: https://git.openjdk.java.net/jdk17/pull/85/files/ca66a7b4..e48f4d74

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

  Stats: 22 lines in 4 files changed: 9 ins; 7 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/85.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/85/head:pull/85

PR: https://git.openjdk.java.net/jdk17/pull/85

From fdesu at protonmail.com  Wed Jul  7 16:17:12 2021
From: fdesu at protonmail.com (Sergei Ustimenko)
Date: Wed, 07 Jul 2021 16:17:12 +0000
Subject: RFR: 8268788: Annotations with lambda expressions can still cause
 AnnotationFormatError
In-Reply-To: <61b87863-7f62-9ddd-eb03-39ef62ad7b0a@oracle.com>
References: <bpL0zFO_yqPTN3RmIqZDewVVo6ONeHrd9C8IWW4tWqI=.b966fff2-f54b-4fed-9c5a-2c341cbc52b5@github.com>
 <k0iSZHPU3aoeg_i0cAzaJBrgsf_g0lTIqrvH_lGieBg=.af73d6e2-55fb-4381-a004-2bd13f2d1f07@github.com>
 <61b87863-7f62-9ddd-eb03-39ef62ad7b0a@oracle.com>
Message-ID: <8pwIBg6_KtZTixWXLCh3NeC9uj3b1QXuMs_DiAuJCdGCNdYzC7qszQQOrZoaqsVRXpBuXRdbKv1bb4CNtFbNJZRoz6KQhaSgGhDgKHmwAxo=@protonmail.com>

Hi Joe,

Thanks, I appreciate your feedback very much!

There was one more thing I wanted to discuss: there is something that
might be improved in the AnnotationInvocationHandler#validateAnnotationMethods
and I wanted to know if it makes sense to go ahead with the change.

There are `if` statements that set the variable called `valid` to false
in case validation fails. Later, depending on the value of the `valid`, an
instance of AnnotationFormatError being thrown. I was thinking if it makes sense
to simplify the validation loop (this is not the complete diff - just gives a
gist of what I mean):

@@ -493,10 +493,7 @@ class AnnotationInvocationHandler implements InvocationHandler, Serializable {
          * Specification citations below are from JLS
          * 9.6.1. Annotation Type Elements
          */
-        boolean valid = true;
-        Method currentMethod = null;
         for(Method method : memberMethods) {
-            currentMethod = method;
             int modifiers = method.getModifiers();
             // Skip over methods that may be a static initializer or
             // similar construct. A static initializer may be used for
@@ -524,8 +521,7 @@ class AnnotationInvocationHandler implements InvocationHandler, Serializable {
                 method.isDefault() ||
                 method.getParameterCount() != 0 ||
                 method.getExceptionTypes().length != 0) {
-                valid = false;
-                break;
+                throw newAnnotationFormatErrorOf(method);
             }

 ...
         }
-        if (valid)
-            return;
-        else
-            throw new AnnotationFormatError("Malformed method on an annotation type: " +
-                                            currentMethod.toString());
+    }
+
+    private static AnnotationFormatError newAnnotationFormatErrorOf(Method malformedMethod) {
+        return new AnnotationFormatError("Malformed method on an annotation type: " + malformedMethod);
     }


What do you think? Does it make sense?

Thanks,
Sergei



??????? Original Message ???????

On Tuesday, July 6th, 2021 at 16:01, Joe Darcy <joe.darcy at oracle.com> wrote:

> Hello,
>
> I should be able to look at this within the next week or two; thanks,
>
> -Joe
>


From mchung at openjdk.java.net  Wed Jul  7 16:25:49 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 7 Jul 2021 16:25:49 GMT
Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex,
 FromIndexSize} where possible [v8]
In-Reply-To: <7AYfiggiXSOnvK9Vi3mIUmJMT54MQqBQRygezjGvXPU=.33f0f6bb-0fa9-4f03-9151-c7c68afadbc1@github.com>
References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
 <imrXHsfJUsxhjLQpbPTeYPTKUff42FGED1cdeB76ST8=.d7c474cb-ebad-4f63-8f88-13494086e0e6@github.com>
 <5xrgLnNfr6-3_nkV_85gde_VX7BWv5nSr4rL7wYHJlg=.e22fc877-564e-4a9f-a2cd-ec7e2a30b6e5@github.com>
 <7AYfiggiXSOnvK9Vi3mIUmJMT54MQqBQRygezjGvXPU=.33f0f6bb-0fa9-4f03-9151-c7c68afadbc1@github.com>
Message-ID: <TD8q3evwKPIVqbq6hTb4A7Oek3YuVLlb0qpvrvxkDus=.356e7fab-68e4-45d3-97f4-f8641eb57997@github.com>

On Wed, 7 Jul 2021 02:10:10 GMT, Yi Yang <yyang at openjdk.org> wrote:

> Does "client changes" means changes involving src/java.desktop and test/java/awt?

src/java.desktop, test/java/awt, and test/javax/imageio

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

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

From mcimadamore at openjdk.java.net  Wed Jul  7 16:39:49 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 7 Jul 2021 16:39:49 GMT
Subject: [jdk17] RFR: 8268766: Desugaring of pattern matching enum switch
 should be improved [v8]
In-Reply-To: <hqsVuFvP7CwQJLmySfxkCEH_kQKTKaGYSNlcGjDdL6M=.faa8f655-403b-46de-b4c1-9f8987914aaa@github.com>
References: <3xKa946t0s_eRqnj0vfgjkfurBvZqKGe1QkYk-0lNO0=.518519f5-a2cb-44ed-946c-09e517e7c5d2@github.com>
 <hqsVuFvP7CwQJLmySfxkCEH_kQKTKaGYSNlcGjDdL6M=.faa8f655-403b-46de-b4c1-9f8987914aaa@github.com>
Message-ID: <vQhZ1ghyS-FW6XqR4BGc6jmgDwi-Eny8LXMv0_eU9nE=.53018389-75c7-4a44-a75b-860545e514ee@github.com>

On Wed, 7 Jul 2021 12:10:16 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Currently, an enum switch with patterns is desugared in a very non-standard, and potentially slow, way. It would be better to use the standard `typeSwitch` bootstrap to classify the enum constants. The bootstrap needs to accept enum constants as labels in order to allow this. A complication is that if an enum constant is missing, that is not an incompatible change for the switch, and the switch should simply work as if the case for the missing constant didn't exist. So, the proposed solution is to have a new bootstrap `enumSwitch` that accepts `String`s in place of the enum constants, and will internally convert them to the appropriate enum constants, and then it will find the proper case similarly to `typeSwitch`.
>> 
>> How does this look?
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   If the pattern type is a supertype of the selector type, use selector type rather than the pattern type when constructing the bootstrap method parameters.

Good catch - should we also add test for when an enum implements an interface?


enum Foo implements A { ... }

Foo foo = ...
switch(foo) {
   case A a: ...
}


I think the patch you have should work since you are using subtyping.

Another thing to consider: should we be worried about type erasure turning the selector type into some weird, unexpected type? I don't think that should be the case, given that if a type variable has a bound E, where E is an enum, the erasure should always be E (as E is a "class" type, so should win, even in intersections).

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

Marked as reviewed by mcimadamore (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/81

From asemenyuk at openjdk.java.net  Wed Jul  7 17:00:54 2021
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Wed, 7 Jul 2021 17:00:54 GMT
Subject: [jdk17] Integrated: 8269185: Directories in /opt/runtimepackagetest
 and /path/to/jdk-17 are different
In-Reply-To: <BscK-vZBXNNXFMaWXULkoVjQWO8z0zmF8ZePhJ7Zg_k=.adcc22b8-b896-4a3f-bb6b-233ecf0db7d1@github.com>
References: <BscK-vZBXNNXFMaWXULkoVjQWO8z0zmF8ZePhJ7Zg_k=.adcc22b8-b896-4a3f-bb6b-233ecf0db7d1@github.com>
Message-ID: <wTc05wHRBlkqTUKeRYQeY021b0c-eVmAPwOgrcO9Irk=.e612ce98-d4f0-40f7-9492-9f349a3315e3@github.com>

On Fri, 2 Jul 2021 22:17:09 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Disable stripping to prevent rpmbuild from modifying executables

This pull request has now been integrated.

Changeset: 6000950b
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.java.net/jdk17/commit/6000950b339e4346292b69079f16ce0d4c278246
Stats:     2 lines in 1 file changed: 2 ins; 0 del; 0 mod

8269185: Directories in /opt/runtimepackagetest and /path/to/jdk-17 are different

Reviewed-by: almatvee, herrick

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

PR: https://git.openjdk.java.net/jdk17/pull/207

From mchung at openjdk.java.net  Wed Jul  7 17:10:56 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 7 Jul 2021 17:10:56 GMT
Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex,
 FromIndexSize} where possible [v8]
In-Reply-To: <TD8q3evwKPIVqbq6hTb4A7Oek3YuVLlb0qpvrvxkDus=.356e7fab-68e4-45d3-97f4-f8641eb57997@github.com>
References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
 <imrXHsfJUsxhjLQpbPTeYPTKUff42FGED1cdeB76ST8=.d7c474cb-ebad-4f63-8f88-13494086e0e6@github.com>
 <5xrgLnNfr6-3_nkV_85gde_VX7BWv5nSr4rL7wYHJlg=.e22fc877-564e-4a9f-a2cd-ec7e2a30b6e5@github.com>
 <7AYfiggiXSOnvK9Vi3mIUmJMT54MQqBQRygezjGvXPU=.33f0f6bb-0fa9-4f03-9151-c7c68afadbc1@github.com>
 <TD8q3evwKPIVqbq6hTb4A7Oek3YuVLlb0qpvrvxkDus=.356e7fab-68e4-45d3-97f4-f8641eb57997@github.com>
Message-ID: <5oJGpGnTSIbs8geLeAbp7aU6KWKkrDIgg4lpw-uJh10=.0ea96922-78ed-429c-9db1-ba92dd613549@github.com>

On Wed, 7 Jul 2021 16:22:25 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Hi Mandy, thanks for reviewing this. 
>> 
>>> I suggest to separate the client changes (both src and test) in a separate PR for the client review.
>> 
>> Does "client changes" means changes involving src/java.desktop and test/java/awt?
>> 
>>> src/java.base/share/classes/java/util/concurrent/CopyOnWriteArrayList.java needs to be updated in JSR 166 upstream repo. Better to file a separate issue for this change to ensure that gets fixed in the upstream project.
>> 
>> Can you please paste a link for that? I'm not sure where I can find JSR 166 upstream repo..
>> 
>>> Nit: The above formatting (line 70-97) is inconsistent with the formatting in line 110-124. It'd be good to use the same formatting.
>> 
>> Restored.
>
>> Does "client changes" means changes involving src/java.desktop and test/java/awt?
> 
> src/java.desktop, test/java/awt, and test/javax/imageio

> > src/java.base/share/classes/java/util/concurrent/CopyOnWriteArrayList.java needs to be updated in JSR 166 upstream repo. Better to file a separate issue for this change to ensure that gets fixed in the upstream project.
> 
> Can you please paste a link for that? I'm not sure where I can find JSR 166 upstream repo..

What I meant is to file a JBS issue for this change and revert the change in this patch.   That can be fixed when the next JSR 166 changes are imported to JDK. 

I wasn't sure if this is the right repo:  http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/

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

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

From asemenyuk at openjdk.java.net  Wed Jul  7 18:54:23 2021
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Wed, 7 Jul 2021 18:54:23 GMT
Subject: RFR: 8268974: GetJREPath() JLI function fails to locate
 libjava.so if not standard Java launcher is used [v3]
In-Reply-To: <FwgeDLBYWTNtFkAm4wFZWWTmRvR7gOrMgLWWA54S-aw=.c4c8e357-ae73-4096-8d0a-5dd5f717fb08@github.com>
References: <FwgeDLBYWTNtFkAm4wFZWWTmRvR7gOrMgLWWA54S-aw=.c4c8e357-ae73-4096-8d0a-5dd5f717fb08@github.com>
Message-ID: <iqDRgCi6AhP_-glU39aIAA6iDyc2RlGxyp-jnv8pTZc=.fe790adf-69b4-4aae-ad31-1531058c9b32@github.com>

> GetApplicationHomeFromDll() fails if the path to libjli.so contains "bin" component (/tmp/bin/HelloWorld/lib/runtime/lib/libjli.so). TruncatePath() looks for "/bin/" first in "/tmp/bin/HelloWorld/lib/runtime/lib/libjli.so" string and then it looks for "/lib/". But this is wrong order as it should look for "/lib/" first. I.e. TruncatePath() should look for "/bin/" and then for "/lib/" if called from GetApplicationHome() and for "/lib/" first and then for "/bin/" if called from GetApplicationHomeFromDll().

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

  Test added

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4534/files
  - new: https://git.openjdk.java.net/jdk/pull/4534/files/18aa7427..19ac6551

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

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

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

From asemenyuk at openjdk.java.net  Wed Jul  7 18:54:25 2021
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Wed, 7 Jul 2021 18:54:25 GMT
Subject: RFR: 8268974: GetJREPath() JLI function fails to locate
 libjava.so if not standard Java launcher is used
In-Reply-To: <KvvdkHkQaVO4NCuUPLr99AMHJTCF6d_EGPaTMJFCfSA=.96d77bc0-2596-48b7-8193-1f46a8684ee7@github.com>
References: <FwgeDLBYWTNtFkAm4wFZWWTmRvR7gOrMgLWWA54S-aw=.c4c8e357-ae73-4096-8d0a-5dd5f717fb08@github.com>
 <oq5vGCWMNPHabQvR2nFAaDQopft5bYS7kIXiP0Aso4Q=.0a9ce752-cbe7-4bbc-8719-1098ab6bcf0f@github.com>
 <KvvdkHkQaVO4NCuUPLr99AMHJTCF6d_EGPaTMJFCfSA=.96d77bc0-2596-48b7-8193-1f46a8684ee7@github.com>
Message-ID: <8sHYmh1CixF2kYq48hqZVNjL5Oeu07018155IyP_a5Y=.460de368-8166-4408-bab7-c031ec0ecb69@github.com>

On Sat, 3 Jul 2021 07:41:40 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Is it possible to add a test for this that is completely independent of jpackage? I think there are a few existing tests that copy the run-time image to a new location for testing purposes.
>> 
>> We may need to rename the JBS description to make it clearer what this issue is about.
>> 
>> A minor nit is that "pathisso" will be confusing to anyone looking at this code, maybe find a better name or put a comment in TruncatePath to explain it. I assume the comments at the findLastPathComponent use site will also need to be clarified.
>
>> @AlanBateman any input on this issue from you?
> 
> Same comment as before, I think we should try to add a test.  If a native test that links to libjli isn't feasible then a jpackage test that creates the scenario that Maurizio ran should be okay.

@AlanBateman jpackage test reproducing the issue added.

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

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

From herrick at openjdk.java.net  Wed Jul  7 19:02:57 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Wed, 7 Jul 2021 19:02:57 GMT
Subject: RFR: 8268974: GetJREPath() JLI function fails to locate
 libjava.so if not standard Java launcher is used [v3]
In-Reply-To: <iqDRgCi6AhP_-glU39aIAA6iDyc2RlGxyp-jnv8pTZc=.fe790adf-69b4-4aae-ad31-1531058c9b32@github.com>
References: <FwgeDLBYWTNtFkAm4wFZWWTmRvR7gOrMgLWWA54S-aw=.c4c8e357-ae73-4096-8d0a-5dd5f717fb08@github.com>
 <iqDRgCi6AhP_-glU39aIAA6iDyc2RlGxyp-jnv8pTZc=.fe790adf-69b4-4aae-ad31-1531058c9b32@github.com>
Message-ID: <w5Zr0uKtrJsdq5wS8-KL5wELUh5WZjdt_gT8gYKxizQ=.a8464a1f-7d1f-431d-b8ba-0bf472fda54d@github.com>

On Wed, 7 Jul 2021 18:54:23 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> GetApplicationHomeFromDll() fails if the path to libjli.so contains "bin" component (/tmp/bin/HelloWorld/lib/runtime/lib/libjli.so). TruncatePath() looks for "/bin/" first in "/tmp/bin/HelloWorld/lib/runtime/lib/libjli.so" string and then it looks for "/lib/". But this is wrong order as it should look for "/lib/" first. I.e. TruncatePath() should look for "/bin/" and then for "/lib/" if called from GetApplicationHome() and for "/lib/" first and then for "/bin/" if called from GetApplicationHomeFromDll().
>
> Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test added

Marked as reviewed by herrick (Reviewer).

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

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

From rriggs at openjdk.java.net  Wed Jul  7 19:12:16 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 7 Jul 2021 19:12:16 GMT
Subject: [jdk17] RFR: 8269929: (test) Add diagnostic info to
 ProceessBuilder/Basic.java for unexpected output
Message-ID: <OAs2f_zsyfLoPfmrP7JCjhajLay3ybPVX5IrRII6Z0g=.b1cf83cb-74c2-4cd2-affa-5359828691ec@github.com>

The test java/lang/ProcessBuilder/Basic.java continues to fail intermittently with unexpected output from the VM.
It appears that destroying the process causes a vm thread to fail to be started.
Extend the delay between starting the child and destroying it.
Add diagnostics to be specific about which case failed.
Incidentally, suppress compiler warnings about SecurityManager use.

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

Commit messages:
 - Extend delay before destorying child to allow more vm startup to complete.

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

PR: https://git.openjdk.java.net/jdk17/pull/228

From iris at openjdk.java.net  Wed Jul  7 19:36:52 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Wed, 7 Jul 2021 19:36:52 GMT
Subject: [jdk17] RFR: 8269929: (test) Add diagnostic info to
 ProceessBuilder/Basic.java for unexpected output
In-Reply-To: <OAs2f_zsyfLoPfmrP7JCjhajLay3ybPVX5IrRII6Z0g=.b1cf83cb-74c2-4cd2-affa-5359828691ec@github.com>
References: <OAs2f_zsyfLoPfmrP7JCjhajLay3ybPVX5IrRII6Z0g=.b1cf83cb-74c2-4cd2-affa-5359828691ec@github.com>
Message-ID: <rYzh75z_lTw7K-DbTSG1A7JPeqjE8ZlvlJ_lD-ufbFM=.6bf068a1-a0fd-409c-8842-74cb1f5a649a@github.com>

On Wed, 7 Jul 2021 19:05:14 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The test java/lang/ProcessBuilder/Basic.java continues to fail intermittently with unexpected output from the VM.
> It appears that destroying the process causes a vm thread to fail to be started.
> Extend the delay between starting the child and destroying it.
> Add diagnostics to be specific about which case failed.
> Incidentally, suppress compiler warnings about SecurityManager use.

Marked as reviewed by iris (Reviewer).

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

PR: https://git.openjdk.java.net/jdk17/pull/228

From bpb at openjdk.java.net  Wed Jul  7 19:56:48 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 7 Jul 2021 19:56:48 GMT
Subject: [jdk17] RFR: 8269929: (test) Add diagnostic info to
 ProceessBuilder/Basic.java for unexpected output
In-Reply-To: <OAs2f_zsyfLoPfmrP7JCjhajLay3ybPVX5IrRII6Z0g=.b1cf83cb-74c2-4cd2-affa-5359828691ec@github.com>
References: <OAs2f_zsyfLoPfmrP7JCjhajLay3ybPVX5IrRII6Z0g=.b1cf83cb-74c2-4cd2-affa-5359828691ec@github.com>
Message-ID: <yk0Q-kO_OrdBTvzntVONHZdbwvC3Fm7_jmb7hxlVZHc=.9971e607-3c60-43c7-88ff-2bf04fe737c4@github.com>

On Wed, 7 Jul 2021 19:05:14 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The test java/lang/ProcessBuilder/Basic.java continues to fail intermittently with unexpected output from the VM.
> It appears that destroying the process causes a vm thread to fail to be started.
> Extend the delay between starting the child and destroying it.
> Add diagnostics to be specific about which case failed.
> Incidentally, suppress compiler warnings about SecurityManager use.

+1

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

Marked as reviewed by bpb (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/228

From naoto at openjdk.java.net  Wed Jul  7 20:13:49 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 7 Jul 2021 20:13:49 GMT
Subject: [jdk17] RFR: 8269929: (test) Add diagnostic info to
 ProceessBuilder/Basic.java for unexpected output
In-Reply-To: <OAs2f_zsyfLoPfmrP7JCjhajLay3ybPVX5IrRII6Z0g=.b1cf83cb-74c2-4cd2-affa-5359828691ec@github.com>
References: <OAs2f_zsyfLoPfmrP7JCjhajLay3ybPVX5IrRII6Z0g=.b1cf83cb-74c2-4cd2-affa-5359828691ec@github.com>
Message-ID: <l6__2xa-n-U6GgIFppegphZwjeK19O0Bpv1tGCm9Amc=.321c09e2-8269-475a-bd25-06d4c524e189@github.com>

On Wed, 7 Jul 2021 19:05:14 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The test java/lang/ProcessBuilder/Basic.java continues to fail intermittently with unexpected output from the VM.
> It appears that destroying the process causes a vm thread to fail to be started.
> Extend the delay between starting the child and destroying it.
> Add diagnostics to be specific about which case failed.
> Incidentally, suppress compiler warnings about SecurityManager use.

Looks good.

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

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/228

From bpb at openjdk.java.net  Wed Jul  7 20:36:01 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 7 Jul 2021 20:36:01 GMT
Subject: RFR: 6506405: Math.abs(float) is slow
In-Reply-To: <101iFqz6Ghvzu84BSMu6OyB-8sgTyx32uvfc5R-YTjg=.6a958f74-16cb-4388-a793-abad94093aa9@github.com>
References: <101iFqz6Ghvzu84BSMu6OyB-8sgTyx32uvfc5R-YTjg=.6a958f74-16cb-4388-a793-abad94093aa9@github.com>
Message-ID: <ryWWSwNiSFn36zi4nB7yoJsX4CE6V9wSCGB7eC4vNxU=.3de74f10-2b9c-41a1-9e9c-21ae4cb476dd@github.com>

On Wed, 7 Jul 2021 20:28:37 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Please consider this change to make the `float` and `double` versions of `java.lang.Math.abs()` branch-free.

With this change there is no measurable effect on performance on macOS, but on Linux there is approximately a 10% throughput improvement.

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

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

From bpb at openjdk.java.net  Wed Jul  7 20:36:01 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 7 Jul 2021 20:36:01 GMT
Subject: RFR: 6506405: Math.abs(float) is slow
Message-ID: <101iFqz6Ghvzu84BSMu6OyB-8sgTyx32uvfc5R-YTjg=.6a958f74-16cb-4388-a793-abad94093aa9@github.com>

Please consider this change to make the `float` and `double` versions of `java.lang.Math.abs()` branch-free.

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

Commit messages:
 - 6506405: Math.abs(float) is slow

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

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

From forax at openjdk.java.net  Wed Jul  7 21:06:48 2021
From: forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Wed, 7 Jul 2021 21:06:48 GMT
Subject: RFR: 6506405: Math.abs(float) is slow
In-Reply-To: <101iFqz6Ghvzu84BSMu6OyB-8sgTyx32uvfc5R-YTjg=.6a958f74-16cb-4388-a793-abad94093aa9@github.com>
References: <101iFqz6Ghvzu84BSMu6OyB-8sgTyx32uvfc5R-YTjg=.6a958f74-16cb-4388-a793-abad94093aa9@github.com>
Message-ID: <7Whc8qiSdRtYReSkRSN36Ts3KffzdiP_Ho54W4YVQfg=.1294edd5-40ac-47d3-9e08-1859956b0cdd@github.com>

On Wed, 7 Jul 2021 20:28:37 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Please consider this change to make the `float` and `double` versions of `java.lang.Math.abs()` branch-free.

Your patch change the semantics, actually
  `Math.abs(Integer.MIN_VALUE) == Integer.MIN_VALUE`
with your patch
  `Math.abs(Integer.MIN_VALUE) == Integer.MAX_VALUE`

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

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

From bpb at openjdk.java.net  Wed Jul  7 21:11:52 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 7 Jul 2021 21:11:52 GMT
Subject: RFR: 6506405: Math.abs(float) is slow
In-Reply-To: <101iFqz6Ghvzu84BSMu6OyB-8sgTyx32uvfc5R-YTjg=.6a958f74-16cb-4388-a793-abad94093aa9@github.com>
References: <101iFqz6Ghvzu84BSMu6OyB-8sgTyx32uvfc5R-YTjg=.6a958f74-16cb-4388-a793-abad94093aa9@github.com>
Message-ID: <n6hxvcqpbSiDHLIFm-nKK8T6mwKXb2C5hlY3kKz60sI=.6759f48c-c368-4a5d-9f95-d94803b2d2db@github.com>

On Wed, 7 Jul 2021 20:28:37 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Please consider this change to make the `float` and `double` versions of `java.lang.Math.abs()` branch-free.

Good catch. Well that?s not good. If it needs to catch a special case it?s probably not worth doing. given the small improvement for the general case. None of the existing tests catch this corner case.

On Jul 7, 2021, at 2:03 PM, R?mi Forax ***@***.******@***.***>> wrote:


Your patch change the semantics, actually
Math.abs(Integer.MIN_VALUE) == Integer.MIN_VALUE
with your patch
Math.abs(Integer.MIN_VALUE) == Integer.MAX_VALUE

?
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/4711*issuecomment-875931239__;Iw!!ACWV5N9M2RV99hQ!cfR3MocdWRA_0gP-3VpRbM_stXXf7VTtD7tPX9aQ07WkId8ihoEhwiCQ_wUCotsYgmlw$>, or unsubscribe<https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/ARBIJVLTH4NIS5WBNTXX26DTWS6KZANCNFSM477LZKTQ__;!!ACWV5N9M2RV99hQ!cfR3MocdWRA_0gP-3VpRbM_stXXf7VTtD7tPX9aQ07WkId8ihoEhwiCQ_wUCotXRvaVx$>.

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

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

From rriggs at openjdk.java.net  Wed Jul  7 21:49:48 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 7 Jul 2021 21:49:48 GMT
Subject: [jdk17] Integrated: 8269929: (test) Add diagnostic info to
 ProceessBuilder/Basic.java for unexpected output
In-Reply-To: <OAs2f_zsyfLoPfmrP7JCjhajLay3ybPVX5IrRII6Z0g=.b1cf83cb-74c2-4cd2-affa-5359828691ec@github.com>
References: <OAs2f_zsyfLoPfmrP7JCjhajLay3ybPVX5IrRII6Z0g=.b1cf83cb-74c2-4cd2-affa-5359828691ec@github.com>
Message-ID: <IQptJuBBGv95JiAswU5_xAsxYrRlhqfhY24NAOjTG1U=.7a729a72-3458-4530-836c-230e649dd433@github.com>

On Wed, 7 Jul 2021 19:05:14 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The test java/lang/ProcessBuilder/Basic.java continues to fail intermittently with unexpected output from the VM.
> It appears that destroying the process causes a vm thread to fail to be started.
> Extend the delay between starting the child and destroying it.
> Add diagnostics to be specific about which case failed.
> Incidentally, suppress compiler warnings about SecurityManager use.

This pull request has now been integrated.

Changeset: c812bbbe
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.java.net/jdk17/commit/c812bbbe8fe86fe960eebfe5c1ce224251981cea
Stats:     7 lines in 1 file changed: 5 ins; 0 del; 2 mod

8269929: (test) Add diagnostic info to ProceessBuilder/Basic.java for unexpected output

Reviewed-by: iris, bpb, naoto

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

PR: https://git.openjdk.java.net/jdk17/pull/228

From darcy at openjdk.java.net  Wed Jul  7 22:25:51 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 7 Jul 2021 22:25:51 GMT
Subject: RFR: 6506405: Math.abs(float) is slow
In-Reply-To: <101iFqz6Ghvzu84BSMu6OyB-8sgTyx32uvfc5R-YTjg=.6a958f74-16cb-4388-a793-abad94093aa9@github.com>
References: <101iFqz6Ghvzu84BSMu6OyB-8sgTyx32uvfc5R-YTjg=.6a958f74-16cb-4388-a793-abad94093aa9@github.com>
Message-ID: <h9ATT0apsortF4uos_7zeU7D6AO3FAQZZjKvB38pouE=.4db373bb-9648-4f4b-91c4-6c54a8f70166@github.com>

On Wed, 7 Jul 2021 20:28:37 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Please consider this change to make the `float` and `double` versions of `java.lang.Math.abs()` branch-free.

> 
> Good catch. Well that?s not good. If it needs to catch a special case it?s probably not worth doing. given the small improvement for the general case. None of the existing tests catch this corner case. On Jul 7, 2021, at 2:03 PM, R?mi Forax ***@***.******@***.***>> wrote: Your patch change the semantics, actually Math.abs(Integer.MIN_VALUE) == Integer.MIN_VALUE with your patch Math.abs(Integer.MIN_VALUE) == Integer.MAX_VALUE ? 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/4711*issuecomment-875931239__;Iw!!ACWV5N9M2RV99hQ!cfR3MocdWRA_0gP-3VpRbM_stXXf7VTtD7tPX9aQ07WkId8ihoEhwiCQ_wUCotsYgmlw$](https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/4711*issuecomment-875931239__;Iw!!ACWV5N9M2RV99hQ!cfR3MocdWRA_0gP-3VpRbM_stXXf7VTtD7tPX9aQ07WkId8ihoEhwiCQ_wUCotsYgmlw%24)>, or unsubscribe<[https://urldefense.com/v3/__https://github.com/notifications/unsubsc
 ribe-auth/ARBIJVLTH4NIS5WBNTXX26DTWS6KZANCNFSM477LZKTQ__;!!ACWV5N9M2RV99hQ!cfR3MocdWRA_0gP-3VpRbM_stXXf7VTtD7tPX9aQ07WkId8ihoEhwiCQ_wUCotXRvaVx$](https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/ARBIJVLTH4NIS5WBNTXX26DTWS6KZANCNFSM477LZKTQ__;!!ACWV5N9M2RV99hQ!cfR3MocdWRA_0gP-3VpRbM_stXXf7VTtD7tPX9aQ07WkId8ihoEhwiCQ_wUCotXRvaVx%24)>.



> 
> 
> Your patch change the semantics, actually
> `Math.abs(Integer.MIN_VALUE) == Integer.MIN_VALUE`
> with your patch
> `Math.abs(Integer.MIN_VALUE) == Integer.MAX_VALUE`

Does it? The overriding of int arguments shouldn't be affected.

-Joe

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

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

From asemenyuk at openjdk.java.net  Wed Jul  7 22:29:33 2021
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Wed, 7 Jul 2021 22:29:33 GMT
Subject: RFR: 8268974: GetJREPath() JLI function fails to locate
 libjava.so if not standard Java launcher is used [v4]
In-Reply-To: <FwgeDLBYWTNtFkAm4wFZWWTmRvR7gOrMgLWWA54S-aw=.c4c8e357-ae73-4096-8d0a-5dd5f717fb08@github.com>
References: <FwgeDLBYWTNtFkAm4wFZWWTmRvR7gOrMgLWWA54S-aw=.c4c8e357-ae73-4096-8d0a-5dd5f717fb08@github.com>
Message-ID: <oJgLNo0Ycql5u9rhDq_9muYGqMbmzUv69N7UbGv5ujk=.ffbe9ebf-61f9-42f5-95f1-3ae30b9ab047@github.com>

> GetApplicationHomeFromDll() fails if the path to libjli.so contains "bin" component (/tmp/bin/HelloWorld/lib/runtime/lib/libjli.so). TruncatePath() looks for "/bin/" first in "/tmp/bin/HelloWorld/lib/runtime/lib/libjli.so" string and then it looks for "/lib/". But this is wrong order as it should look for "/lib/" first. I.e. TruncatePath() should look for "/bin/" and then for "/lib/" if called from GetApplicationHome() and for "/lib/" first and then for "/bin/" if called from GetApplicationHomeFromDll().

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 'master' into JDK-8268974
 - Test added
 - - Comments updated.
   - pathisso -> pathisdll.
 - 8268974: jpackage fails to handle --dest option containing "bin" folder

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4534/files
  - new: https://git.openjdk.java.net/jdk/pull/4534/files/19ac6551..7934b977

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

  Stats: 88952 lines in 1561 files changed: 47547 ins; 34348 del; 7057 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4534.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4534/head:pull/4534

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

From forax at openjdk.java.net  Wed Jul  7 22:46:50 2021
From: forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Wed, 7 Jul 2021 22:46:50 GMT
Subject: RFR: 6506405: Math.abs(float) is slow
In-Reply-To: <h9ATT0apsortF4uos_7zeU7D6AO3FAQZZjKvB38pouE=.4db373bb-9648-4f4b-91c4-6c54a8f70166@github.com>
References: <101iFqz6Ghvzu84BSMu6OyB-8sgTyx32uvfc5R-YTjg=.6a958f74-16cb-4388-a793-abad94093aa9@github.com>
 <h9ATT0apsortF4uos_7zeU7D6AO3FAQZZjKvB38pouE=.4db373bb-9648-4f4b-91c4-6c54a8f70166@github.com>
Message-ID: <keDqbRxVBrV02oDXPfkwcGHwh4YoX_msiVWFkNMFCKs=.b5919b65-8f91-4b76-810c-57eaafbbfcaf@github.com>

On Wed, 7 Jul 2021 22:22:45 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> 
> > Your patch change the semantics, actually
> > `Math.abs(Integer.MIN_VALUE) == Integer.MIN_VALUE`
> > with your patch
> > `Math.abs(Integer.MIN_VALUE) == Integer.MAX_VALUE`
> 
> Does it? The overriding of int arguments shouldn't be affected.

You are right, it does not change abs(int) so it should be Ok.

> 
> -Joe

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

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

From bpb at openjdk.java.net  Wed Jul  7 23:56:48 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 7 Jul 2021 23:56:48 GMT
Subject: RFR: 6506405: Math.abs(float) is slow
In-Reply-To: <101iFqz6Ghvzu84BSMu6OyB-8sgTyx32uvfc5R-YTjg=.6a958f74-16cb-4388-a793-abad94093aa9@github.com>
References: <101iFqz6Ghvzu84BSMu6OyB-8sgTyx32uvfc5R-YTjg=.6a958f74-16cb-4388-a793-abad94093aa9@github.com>
Message-ID: <9p6x1DIafk9Q7jyHx8cU7DRI4z-9pEXtehilrsSrT30=.cb1cca2b-c507-41c3-9dfc-851ef35c23a2@github.com>

On Wed, 7 Jul 2021 20:28:37 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Please consider this change to make the `float` and `double` versions of `java.lang.Math.abs()` branch-free.

On Jul 7, 2021, at 3:44 PM, R?mi Forax ***@***.******@***.***>> wrote:


Your patch change the semantics, actually
Math.abs(Integer.MIN_VALUE) == Integer.MIN_VALUE
with your patch
Math.abs(Integer.MIN_VALUE) == Integer.MAX_VALUE

Does it? The overriding of int arguments shouldn't be affected.

You are right, it does not change abs(int) so it should be Ok.

I checked it earlier and it is OK.

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

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

From jwilhelm at openjdk.java.net  Thu Jul  8 00:09:13 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Thu, 8 Jul 2021 00:09:13 GMT
Subject: RFR: Merge jdk17
Message-ID: <5Qsuuw4QmXh-KAdwTuPuzaZkTpnHotcFJFndDEpgzsw=.041cd433-2a77-4e6d-b941-bd6bccd81699@github.com>

Forwardport JDK 17 -> JDK 18

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

Commit messages:
 - Merge
 - 8269929: (test) Add diagnostic info to ProceessBuilder/Basic.java for unexpected output
 - 8269185: Directories in /opt/runtimepackagetest and /path/to/jdk-17 are different
 - 8269879: [PPC64] C2: Math.rint intrinsic uses wrong rounding mode
 - 8266036: class file for sun.misc.Contended not found
 - 8269772: [macos-aarch64] test compilation failed with "SocketException: No buffer space available"
 - 8268859: jshell throws exception while parsing illegal "case true"
 - 8269802: javac fails to compile nested pattern matching switches
 - 8269830: SA's vm object vtable matching code sometimes matches on incorrect type
 - 8268778: CDS check_excluded_classes needs DumpTimeTable_lock

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

Changes: https://git.openjdk.java.net/jdk/pull/4713/files
  Stats: 1083 lines in 36 files changed: 629 ins; 278 del; 176 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4713.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4713/head:pull/4713

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

From bpb at openjdk.java.net  Thu Jul  8 00:20:50 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 8 Jul 2021 00:20:50 GMT
Subject: [jdk17] RFR: 6766844: ByteArrayInputStream#read with a byte array
 of length 0 not consistent with InputStream when at EOF [v2]
In-Reply-To: <imuqrTpf5AqkRpBU_KuuxSU5r9w-VBlqsEwcaY1szPM=.1d49f5b8-c629-4001-8153-990399b0fc04@github.com>
References: <8nNGNaJvrmtiLTlJcIazAl5J7iVsBxbhEeAItADAoKc=.824db13a-589c-421e-8595-01ac4e5c27bd@github.com>
 <MZ3-8xBveOrZ2SZKqevKuJ-dufr_bs9ZrfkLq4kxBA4=.d1779658-8e77-4c2b-87b0-0baafe1efb7a@github.com>
 <aJJaUdYzv9Rz7QuLPRCOyckIeEoAUWj5sJMX_xSkmr4=.fa8e866d-c636-49b8-9b3e-e1619bc879c0@github.com>
 <MT65cu36cTy8gvXiZkl4n1lIHnQIkz0jDdHxgZdqo10=.568b6083-8f03-4049-98e3-c6abd74b9cc1@github.com>
 <AapXw3qPDA7hh4uK3xSO8wOLwYTVWvGxdGmwxkp-ya8=.bbe7630e-4a41-4088-804c-3b97c4770e22@github.com>
 <X8Og4OtbQYVoP3EDoIPSDn6h4DFAOZh4Y21BwUWB8qg=.2c0cc083-592a-4da3-9e9f-cb8c48d8f146@github.com>
 <imuqrTpf5AqkRpBU_KuuxSU5r9w-VBlqsEwcaY1szPM=.1d49f5b8-c629-4001-8153-990399b0fc04@github.com>
Message-ID: <HjB7cFRflLYP-_wde5yI5oegHbQnTSd5Jj1chSI9qdg=.dadecff4-a5db-411b-8061-39c5c579d7fb@github.com>

On Fri, 2 Jul 2021 19:36:01 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Thanks for the suggestion. I am happy with it as is, but I'll hold off integrating it for now and rethink it later.
>
> Ok, good to know. Have a great weekend!

I am inclined to leave the wording alone barring serious objections to the contrary.

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

PR: https://git.openjdk.java.net/jdk17/pull/189

From darcy at openjdk.java.net  Thu Jul  8 00:43:49 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 8 Jul 2021 00:43:49 GMT
Subject: RFR: 6506405: Math.abs(float) is slow
In-Reply-To: <101iFqz6Ghvzu84BSMu6OyB-8sgTyx32uvfc5R-YTjg=.6a958f74-16cb-4388-a793-abad94093aa9@github.com>
References: <101iFqz6Ghvzu84BSMu6OyB-8sgTyx32uvfc5R-YTjg=.6a958f74-16cb-4388-a793-abad94093aa9@github.com>
Message-ID: <3nnGgxuFionbb8UyYAyk_TmZNjEI4PAxHFwcpLrHt4c=.cbe06838-d065-48be-b516-1f4cf21f8564@github.com>

On Wed, 7 Jul 2021 20:28:37 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Please consider this change to make the `float` and `double` versions of `java.lang.Math.abs()` branch-free.

src/java.base/share/classes/java/lang/Math.java line 1530:

> 1528:     @IntrinsicCandidate
> 1529:     public static float abs(float a) {
> 1530:         return Float.intBitsToFloat(Float.floatToRawIntBits(a) & 0x7fffffff);

I'd like to see a brief comment on these methods along the lines of "zero out sign bit in the representation." Using underscores in the literal to better group the digits or using the constants in jdk.internal.math.DoubleConsts.

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

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

From bpb at openjdk.java.net  Thu Jul  8 00:43:49 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 8 Jul 2021 00:43:49 GMT
Subject: RFR: 6506405: Math.abs(float) is slow
In-Reply-To: <3nnGgxuFionbb8UyYAyk_TmZNjEI4PAxHFwcpLrHt4c=.cbe06838-d065-48be-b516-1f4cf21f8564@github.com>
References: <101iFqz6Ghvzu84BSMu6OyB-8sgTyx32uvfc5R-YTjg=.6a958f74-16cb-4388-a793-abad94093aa9@github.com>
 <3nnGgxuFionbb8UyYAyk_TmZNjEI4PAxHFwcpLrHt4c=.cbe06838-d065-48be-b516-1f4cf21f8564@github.com>
Message-ID: <AnJv-KFhzV1vXuup48EMgqzERv_vcjH8hxRnN4rhQOU=.f8db0d2b-a689-49f2-9f48-3ac60b5983a0@github.com>

On Thu, 8 Jul 2021 00:38:45 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Please consider this change to make the `float` and `double` versions of `java.lang.Math.abs()` branch-free.
>
> src/java.base/share/classes/java/lang/Math.java line 1530:
> 
>> 1528:     @IntrinsicCandidate
>> 1529:     public static float abs(float a) {
>> 1530:         return Float.intBitsToFloat(Float.floatToRawIntBits(a) & 0x7fffffff);
> 
> I'd like to see a brief comment on these methods along the lines of "zero out sign bit in the representation." Using underscores in the literal to better group the digits or using the constants in jdk.internal.math.DoubleConsts.

There is no specific constant in `{Float,Double}Consts` to mask all but the sign bit, but I had thought it might be good to add one there.

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

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

From darcy at openjdk.java.net  Thu Jul  8 00:48:47 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 8 Jul 2021 00:48:47 GMT
Subject: RFR: 6506405: Math.abs(float) is slow
In-Reply-To: <ryWWSwNiSFn36zi4nB7yoJsX4CE6V9wSCGB7eC4vNxU=.3de74f10-2b9c-41a1-9e9c-21ae4cb476dd@github.com>
References: <101iFqz6Ghvzu84BSMu6OyB-8sgTyx32uvfc5R-YTjg=.6a958f74-16cb-4388-a793-abad94093aa9@github.com>
 <ryWWSwNiSFn36zi4nB7yoJsX4CE6V9wSCGB7eC4vNxU=.3de74f10-2b9c-41a1-9e9c-21ae4cb476dd@github.com>
Message-ID: <fOQMEZRrM7jbHTMNrq55E54iFZmMjst2IlkIaa2rluI=.df1ad9cf-117e-40a3-b863-dc3365788d4e@github.com>

On Wed, 7 Jul 2021 20:29:37 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> 
> 
> With this change there is no measurable effect on performance on macOS, but on Linux there is approximately a 10% throughput improvement.

The improvement is with the default options, without turning intrinsics off?

I'm somewhat indifferent toward the change. On platforms with intrinsics, the intrinsic hardware instruction should run quickly regardless of how the Java code is implemented. On older versions of the platform the bitwise conversion (longBitsToDouble and friends) was slow, so the floating-point operations would be faster. However, the bitwise conversion should now be fast everywhere.

As a minor behavioral difference, the behavior on some NaN values would change in terms of which NaN was returned as a result, but any NaN is allowed by the spec.

If the new code is faster with intrinsics enabled on a common platform, I'd be happy to review a slightly refactored version of the PR.

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

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

From joe.darcy at oracle.com  Thu Jul  8 00:50:21 2021
From: joe.darcy at oracle.com (Joe Darcy)
Date: Wed, 7 Jul 2021 17:50:21 -0700
Subject: RFR: 6506405: Math.abs(float) is slow
In-Reply-To: <AnJv-KFhzV1vXuup48EMgqzERv_vcjH8hxRnN4rhQOU=.f8db0d2b-a689-49f2-9f48-3ac60b5983a0@github.com>
References: <101iFqz6Ghvzu84BSMu6OyB-8sgTyx32uvfc5R-YTjg=.6a958f74-16cb-4388-a793-abad94093aa9@github.com>
 <3nnGgxuFionbb8UyYAyk_TmZNjEI4PAxHFwcpLrHt4c=.cbe06838-d065-48be-b516-1f4cf21f8564@github.com>
 <AnJv-KFhzV1vXuup48EMgqzERv_vcjH8hxRnN4rhQOU=.f8db0d2b-a689-49f2-9f48-3ac60b5983a0@github.com>
Message-ID: <ff72384c-cf56-e143-9bcd-a88f400c35bc@oracle.com>

On 7/7/2021 5:43 PM, Brian Burkhalter wrote:
> On Thu, 8 Jul 2021 00:38:45 GMT, Joe Darcy <darcy at openjdk.org> wrote:
>
>>> Please consider this change to make the `float` and `double` versions of `java.lang.Math.abs()` branch-free.
>> src/java.base/share/classes/java/lang/Math.java line 1530:
>>
>>> 1528:     @IntrinsicCandidate
>>> 1529:     public static float abs(float a) {
>>> 1530:         return Float.intBitsToFloat(Float.floatToRawIntBits(a) & 0x7fffffff);
>> I'd like to see a brief comment on these methods along the lines of "zero out sign bit in the representation." Using underscores in the literal to better group the digits or using the constants in jdk.internal.math.DoubleConsts.
> There is no specific constant in `{Float,Double}Consts` to mask all but the sign bit, but I had thought it might be good to add one there


The sign bit mask can be bit-wise complemented though :-)

-Joe


From jwilhelm at openjdk.java.net  Thu Jul  8 01:01:08 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Thu, 8 Jul 2021 01:01:08 GMT
Subject: Integrated: Merge jdk17
In-Reply-To: <5Qsuuw4QmXh-KAdwTuPuzaZkTpnHotcFJFndDEpgzsw=.041cd433-2a77-4e6d-b941-bd6bccd81699@github.com>
References: <5Qsuuw4QmXh-KAdwTuPuzaZkTpnHotcFJFndDEpgzsw=.041cd433-2a77-4e6d-b941-bd6bccd81699@github.com>
Message-ID: <aR7I10NllN3IUYv2fFGqbNJiqNGHWOCGJbu1oPfkHnE=.3023ca05-f5a5-4053-a9aa-0a299da41680@github.com>

On Thu, 8 Jul 2021 00:01:43 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 17 -> JDK 18

This pull request has now been integrated.

Changeset: 270fbcb3
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/270fbcb3f5755baf045fa6dec3fba459d32c32e1
Stats:     1083 lines in 36 files changed: 629 ins; 278 del; 176 mod

Merge

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

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

From jwilhelm at openjdk.java.net  Thu Jul  8 01:01:07 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Thu, 8 Jul 2021 01:01:07 GMT
Subject: RFR: Merge jdk17 [v2]
In-Reply-To: <5Qsuuw4QmXh-KAdwTuPuzaZkTpnHotcFJFndDEpgzsw=.041cd433-2a77-4e6d-b941-bd6bccd81699@github.com>
References: <5Qsuuw4QmXh-KAdwTuPuzaZkTpnHotcFJFndDEpgzsw=.041cd433-2a77-4e6d-b941-bd6bccd81699@github.com>
Message-ID: <T8ZKUYz_moDDFWXemuiH6AHfTv2rC1ysSDBJskzCknY=.3b17f7a7-8c39-4728-b06d-0a5cd4710a1a@github.com>

> Forwardport JDK 17 -> JDK 18

Jesper Wilhelmsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 180 commits:

 - Merge
 - 8264735: Make dynamic dump repeatable
   
   Reviewed-by: ccheung, iklam
 - 8269481: SctpMultiChannel never releases own file descriptor
   
   Reviewed-by: alanb, chegar
 - 8270027: ProblemList jdk/jfr/event/oldobject/TestObjectSize.java on macOS-x64
   
   Reviewed-by: mgronlun
 - 8267303: Replace MinObjectAlignmentSize usages for non-Java heap objects
   
   Reviewed-by: kbarrett, tschatzl, minqi
 - 8268635: Corrupt oop in ClassLoaderData
   
   Reviewed-by: iklam, dholmes
 - 8269923: runtime/jni/checked/TestPrimitiveArrayCriticalWithBadParam.java failed with "FATAL ERROR in native method: Primitive type array expected but not received for JNI array operation"
   
   Reviewed-by: dcubed, dholmes
 - 8269761: idea.sh missing .exe suffix when invoking javac on WSL
   
   Reviewed-by: mcimadamore, erikj
 - 8269294: Verify_before/after_young_collection should execute all verification
   
   Reviewed-by: iwalulya, kbarrett
 - 8269908: Move MemoryService::track_memory_usage call into G1MonitoringScope
   
   Reviewed-by: ayang, kbarrett
 - ... and 170 more: https://git.openjdk.java.net/jdk/compare/c812bbbe...e5695159

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

Changes: https://git.openjdk.java.net/jdk/pull/4713/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4713&range=01
  Stats: 46991 lines in 850 files changed: 21189 ins; 22881 del; 2921 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4713.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4713/head:pull/4713

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

From bpb at openjdk.java.net  Thu Jul  8 01:05:16 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 8 Jul 2021 01:05:16 GMT
Subject: RFR: 6506405: Math.abs(float) is slow [v2]
In-Reply-To: <101iFqz6Ghvzu84BSMu6OyB-8sgTyx32uvfc5R-YTjg=.6a958f74-16cb-4388-a793-abad94093aa9@github.com>
References: <101iFqz6Ghvzu84BSMu6OyB-8sgTyx32uvfc5R-YTjg=.6a958f74-16cb-4388-a793-abad94093aa9@github.com>
Message-ID: <a6dTrhE64I49kW2H2BiYfS1otWfFYehpqxFqWIsFk1A=.c1ce2233-2768-4981-9c6d-7314d2d4c52c@github.com>

> Please consider this change to make the `float` and `double` versions of `java.lang.Math.abs()` branch-free.

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

  6506405: Add comments, use new consts for masking

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4711/files
  - new: https://git.openjdk.java.net/jdk/pull/4711/files/60d461fc..ba950f60

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

  Stats: 22 lines in 3 files changed: 17 ins; 0 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4711.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4711/head:pull/4711

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

From darcy at openjdk.java.net  Thu Jul  8 01:10:04 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 8 Jul 2021 01:10:04 GMT
Subject: RFR: 6506405: Math.abs(float) is slow [v2]
In-Reply-To: <a6dTrhE64I49kW2H2BiYfS1otWfFYehpqxFqWIsFk1A=.c1ce2233-2768-4981-9c6d-7314d2d4c52c@github.com>
References: <101iFqz6Ghvzu84BSMu6OyB-8sgTyx32uvfc5R-YTjg=.6a958f74-16cb-4388-a793-abad94093aa9@github.com>
 <a6dTrhE64I49kW2H2BiYfS1otWfFYehpqxFqWIsFk1A=.c1ce2233-2768-4981-9c6d-7314d2d4c52c@github.com>
Message-ID: <JpBc5ESc67oLH3ALO0WVVakvqRR8UNpgJj81KvWcoMY=.a36d005a-c9a4-4405-b801-5837e694667f@github.com>

On Thu, 8 Jul 2021 01:05:16 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Please consider this change to make the `float` and `double` versions of `java.lang.Math.abs()` branch-free.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   6506405: Add comments, use new consts for masking

Marked as reviewed by darcy (Reviewer).

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

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

From brian.burkhalter at oracle.com  Thu Jul  8 01:20:31 2021
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Thu, 8 Jul 2021 01:20:31 +0000
Subject: RFR: 6506405: Math.abs(float) is slow
In-Reply-To: <ff72384c-cf56-e143-9bcd-a88f400c35bc@oracle.com>
References: <101iFqz6Ghvzu84BSMu6OyB-8sgTyx32uvfc5R-YTjg=.6a958f74-16cb-4388-a793-abad94093aa9@github.com>
 <3nnGgxuFionbb8UyYAyk_TmZNjEI4PAxHFwcpLrHt4c=.cbe06838-d065-48be-b516-1f4cf21f8564@github.com>
 <AnJv-KFhzV1vXuup48EMgqzERv_vcjH8hxRnN4rhQOU=.f8db0d2b-a689-49f2-9f48-3ac60b5983a0@github.com>
 <ff72384c-cf56-e143-9bcd-a88f400c35bc@oracle.com>
Message-ID: <8E9F3DA4-033D-4953-B679-D348DC7731AF@oracle.com>


On Jul 7, 2021, at 5:50 PM, Joe Darcy <joe.darcy at oracle.com<mailto:joe.darcy at oracle.com>> wrote:

There is no specific constant in `{Float,Double}Consts` to mask all but the sign bit, but I had thought it might be good to add one there


The sign bit mask can be bit-wise complemented though :-)

I had it that way initially and removed it.

From mseledtsov at openjdk.java.net  Thu Jul  8 02:05:11 2021
From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov)
Date: Thu, 8 Jul 2021 02:05:11 GMT
Subject: [jdk17] RFR: 8269840: Update Platform.isDefaultCDSArchiveSupported()
 to return true for Linux-aarch64
Message-ID: <1GSVRAF5kJwh_CHY393jxWIJrLmCEfPudtwus2Wju4U=.e9880721-a8d8-4e85-9f85-6b0206b4ad22@github.com>

Now that "JDK-8268212 Build linux-aarch64 natively" added support for default CDS archive, time to update test configuration for this platform. This is a very small one-line change.

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

Commit messages:
 - 8269840: Update Platform.isDefaultCDSArchiveSupported() to return true for Linux-aarch64

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

PR: https://git.openjdk.java.net/jdk17/pull/229

From mseledtsov at openjdk.java.net  Thu Jul  8 02:05:11 2021
From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov)
Date: Thu, 8 Jul 2021 02:05:11 GMT
Subject: [jdk17] RFR: 8269840: Update
 Platform.isDefaultCDSArchiveSupported() to return true for Linux-aarch64
In-Reply-To: <1GSVRAF5kJwh_CHY393jxWIJrLmCEfPudtwus2Wju4U=.e9880721-a8d8-4e85-9f85-6b0206b4ad22@github.com>
References: <1GSVRAF5kJwh_CHY393jxWIJrLmCEfPudtwus2Wju4U=.e9880721-a8d8-4e85-9f85-6b0206b4ad22@github.com>
Message-ID: <CuGSat5unCtvU-dYz1rmpCe1EdmGIJkMAhzGXuH0uyA=.8df46575-8e0e-4b32-adf5-80ff2417d381@github.com>

On Thu, 8 Jul 2021 01:59:25 GMT, Mikhailo Seledtsov <mseledtsov at openjdk.org> wrote:

> Now that "JDK-8268212 Build linux-aarch64 natively" added support for default CDS archive, time to update test configuration for this platform. This is a very small one-line change.

Testing:
Grepped test sources for isDefaultCDSArchiveSupported. Found the following tests references:
test/hotspot/jtreg/runtime/cds/CheckDefaultArchiveFile.java,test/hotspot/jtreg/runtime/cds/CheckSharingWithDefaultArchive.java,test/lib-test/jdk/test/lib/TestMutuallyExclusivePlatformPredicates.java

Running these tests on Linux-aarch64.

@ioilam @calvinccheung @lmesnik Could you please review this one-liner when you have a chance?

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

PR: https://git.openjdk.java.net/jdk17/pull/229

From minqi at openjdk.java.net  Thu Jul  8 02:28:52 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Thu, 8 Jul 2021 02:28:52 GMT
Subject: [jdk17] RFR: 8269840: Update
 Platform.isDefaultCDSArchiveSupported() to return true for Linux-aarch64
In-Reply-To: <1GSVRAF5kJwh_CHY393jxWIJrLmCEfPudtwus2Wju4U=.e9880721-a8d8-4e85-9f85-6b0206b4ad22@github.com>
References: <1GSVRAF5kJwh_CHY393jxWIJrLmCEfPudtwus2Wju4U=.e9880721-a8d8-4e85-9f85-6b0206b4ad22@github.com>
Message-ID: <VGHjfbUdXsrzQOmKv8iSg1gBYs85hepgvNkFcJ6C060=.33760b4d-5645-47cf-93ad-9ce556206efe@github.com>

On Thu, 8 Jul 2021 01:59:25 GMT, Mikhailo Seledtsov <mseledtsov at openjdk.org> wrote:

> Now that "JDK-8268212 Build linux-aarch64 natively" added support for default CDS archive, time to update test configuration for this platform. This is a very small one-line change.

LGTM.

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

Marked as reviewed by minqi (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/229

From yyang at openjdk.java.net  Thu Jul  8 02:42:15 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Thu, 8 Jul 2021 02:42:15 GMT
Subject: RFR: 8270056: Generated lambda class can not access protected static
 method of target class
Message-ID: <bDVkalKu_hLAwlGagLIkFol-aLy98PngVw8FrLc0pRM=.0670192d-ae03-4d31-82bb-097e20ae4ffd@github.com>

Generated lambda class can not access protected static method of the target class. The following exception is thrown when executing the attached reproducible program:


Exception in thread "main" java.lang.IllegalAccessError: class AccessProtectedStaticMethodFromSuper$B$$Lambda$15/0x0000000800b8ea48 tried to access protected method 'void AccessProtectedStaticMethodFromSuper$A.func()' (AccessProtectedStaticMethodFromSuper$B$$Lambda$15/0x0000000800b8ea48 is in unnamed module of loader AccessProtectedStaticMethodFromSuper$1Loader @71dac704; AccessProtectedStaticMethodFromSuper$A is in unnamed module of loader AccessProtectedStaticMethodFromSuper$1Loader @39ed3c8d)
	at AccessProtectedStaticMethodFromSuper.main(AccessProtectedStaticMethodFromSuper.java:51)


This issue is similar to JDK-8254975(#767) with slight differences: generated lambda proxy calls static protected method rather than protected member method.

The proposed fix 1) tries to use MethodHandle instead of invoking forwarded directly(since the lambda class has no access to the resolved method) and 2) does not force accepting an implClass as the first argument when invoking a static method.

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

Commit messages:
 - proposed fix

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

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

From yyang at openjdk.java.net  Thu Jul  8 03:12:26 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Thu, 8 Jul 2021 03:12:26 GMT
Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex,
 FromIndexSize} for java.base [v8]
In-Reply-To: <5oJGpGnTSIbs8geLeAbp7aU6KWKkrDIgg4lpw-uJh10=.0ea96922-78ed-429c-9db1-ba92dd613549@github.com>
References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
 <imrXHsfJUsxhjLQpbPTeYPTKUff42FGED1cdeB76ST8=.d7c474cb-ebad-4f63-8f88-13494086e0e6@github.com>
 <5xrgLnNfr6-3_nkV_85gde_VX7BWv5nSr4rL7wYHJlg=.e22fc877-564e-4a9f-a2cd-ec7e2a30b6e5@github.com>
 <7AYfiggiXSOnvK9Vi3mIUmJMT54MQqBQRygezjGvXPU=.33f0f6bb-0fa9-4f03-9151-c7c68afadbc1@github.com>
 <TD8q3evwKPIVqbq6hTb4A7Oek3YuVLlb0qpvrvxkDus=.356e7fab-68e4-45d3-97f4-f8641eb57997@github.com>
 <5oJGpGnTSIbs8geLeAbp7aU6KWKkrDIgg4lpw-uJh10=.0ea96922-78ed-429c-9db1-ba92dd613549@github.com>
Message-ID: <zuVoAYcrfUuDsT-IGeI7p8ui3aDwbUe48fdQJVqF20A=.e0854d3d-47b2-4e31-96ee-ebf150e8f1dd@github.com>

On Wed, 7 Jul 2021 17:08:19 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>>> Does "client changes" means changes involving src/java.desktop and test/java/awt?
>> 
>> src/java.desktop, test/java/awt, and test/javax/imageio
>
>> > src/java.base/share/classes/java/util/concurrent/CopyOnWriteArrayList.java needs to be updated in JSR 166 upstream repo. Better to file a separate issue for this change to ensure that gets fixed in the upstream project.
>> 
>> Can you please paste a link for that? I'm not sure where I can find JSR 166 upstream repo..
> 
> What I meant is to file a JBS issue for this change and revert the change in this patch.   That can be fixed when the next JSR 166 changes are imported to JDK. 
> 
> I wasn't sure if this is the right repo:  http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/

Okay. I've filed https://bugs.openjdk.java.net/browse/JDK-8270057 and https://bugs.openjdk.java.net/browse/JDK-8270058 for JSR 166 and client code respectively. These codes have been restored.

(Sorry for force-pushing, my mistake..)

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

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

From yyang at openjdk.java.net  Thu Jul  8 03:12:24 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Thu, 8 Jul 2021 03:12:24 GMT
Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex,
 FromIndexSize} for java.base [v11]
In-Reply-To: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
Message-ID: <QM4u0adwYkgwPAp9Rr4v5M_2tC0EaWO9kctj8pXKt-U=.102e4127-2fe4-4be6-aa46-74f6cb040c44@github.com>

> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in the whole JDK codebase.

Yi Yang 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:

  restore JSR166; restore java.desktop

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4507/files
  - new: https://git.openjdk.java.net/jdk/pull/4507/files/903f0305..a9e7dbc8

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

  Stats: 49 lines in 7 files changed: 24 ins; 7 del; 18 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4507.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4507/head:pull/4507

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

From iklam at openjdk.java.net  Thu Jul  8 03:18:52 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Thu, 8 Jul 2021 03:18:52 GMT
Subject: [jdk17] RFR: 8269840: Update
 Platform.isDefaultCDSArchiveSupported() to return true for Linux-aarch64
In-Reply-To: <1GSVRAF5kJwh_CHY393jxWIJrLmCEfPudtwus2Wju4U=.e9880721-a8d8-4e85-9f85-6b0206b4ad22@github.com>
References: <1GSVRAF5kJwh_CHY393jxWIJrLmCEfPudtwus2Wju4U=.e9880721-a8d8-4e85-9f85-6b0206b4ad22@github.com>
Message-ID: <VhIk5Pd0yA3UG7cC4Lrp6wM5v2CWStNsyium_-2BfU4=.9788c24b-da9c-4017-96ad-00bb887ea1dd@github.com>

On Thu, 8 Jul 2021 01:59:25 GMT, Mikhailo Seledtsov <mseledtsov at openjdk.org> wrote:

> Now that "JDK-8268212 Build linux-aarch64 natively" added support for default CDS archive, time to update test configuration for this platform. This is a very small one-line change.

Looks good, but this returns true also for osx-aarch64 and windows-aarch64, so the comment message needs to be updated.

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

Marked as reviewed by iklam (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/229

From uschindler at apache.org  Thu Jul  8 07:09:01 2021
From: uschindler at apache.org (Uwe Schindler)
Date: Thu, 08 Jul 2021 07:09:01 +0000
Subject: RFR: 6506405: Math.abs(float) is slow [v2]
In-Reply-To: <a6dTrhE64I49kW2H2BiYfS1otWfFYehpqxFqWIsFk1A=.c1ce2233-2768-4981-9c6d-7314d2d4c52c@github.com>
References: <101iFqz6Ghvzu84BSMu6OyB-8sgTyx32uvfc5R-YTjg=.6a958f74-16cb-4388-a793-abad94093aa9@github.com>
 <a6dTrhE64I49kW2H2BiYfS1otWfFYehpqxFqWIsFk1A=.c1ce2233-2768-4981-9c6d-7314d2d4c52c@github.com>
Message-ID: <573F1E35-7D09-4267-AA59-9F894ED9772E@apache.org>

On a quick review of version 2, I noticed that the double constant is declared as integer with same value like the float one.

I think that's wrong, but I wonder why the asserts still pass.

Uwe

Am July 8, 2021 1:05:16 AM UTC schrieb Brian Burkhalter <bpb at openjdk.java.net>:
>> Please consider this change to make the `float` and `double` versions
>of `java.lang.Math.abs()` branch-free.
>
>Brian Burkhalter has updated the pull request incrementally with one
>additional commit since the last revision:
>
>  6506405: Add comments, use new consts for masking
>
>-------------
>
>Changes:
>  - all: https://git.openjdk.java.net/jdk/pull/4711/files
>- new:
>https://git.openjdk.java.net/jdk/pull/4711/files/60d461fc..ba950f60
>
>Webrevs:
> - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4711&range=01
> - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4711&range=00-01
>
>  Stats: 22 lines in 3 files changed: 17 ins; 0 del; 5 mod
>  Patch: https://git.openjdk.java.net/jdk/pull/4711.diff
>Fetch: git fetch https://git.openjdk.java.net/jdk
>pull/4711/head:pull/4711
>
>PR: https://git.openjdk.java.net/jdk/pull/4711

From uschindler at openjdk.java.net  Thu Jul  8 07:08:50 2021
From: uschindler at openjdk.java.net (Uwe Schindler)
Date: Thu, 8 Jul 2021 07:08:50 GMT
Subject: RFR: 6506405: Math.abs(float) is slow [v2]
In-Reply-To: <a6dTrhE64I49kW2H2BiYfS1otWfFYehpqxFqWIsFk1A=.c1ce2233-2768-4981-9c6d-7314d2d4c52c@github.com>
References: <101iFqz6Ghvzu84BSMu6OyB-8sgTyx32uvfc5R-YTjg=.6a958f74-16cb-4388-a793-abad94093aa9@github.com>
 <a6dTrhE64I49kW2H2BiYfS1otWfFYehpqxFqWIsFk1A=.c1ce2233-2768-4981-9c6d-7314d2d4c52c@github.com>
Message-ID: <LXEqq3ZWXz_CpiWnVd7s151Snue7AUdUpQodwzn2bOU=.cfd55401-ecde-40d3-8ed7-aec7c6db1ef2@github.com>

On Thu, 8 Jul 2021 01:05:16 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Please consider this change to make the `float` and `double` versions of `java.lang.Math.abs()` branch-free.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   6506405: Add comments, use new consts for masking

I am a bit confused about the double constant being an int.

src/java.base/share/classes/jdk/internal/math/DoubleConsts.java line 80:

> 78:      * significand fields) of a {@code double}.
> 79:      */
> 80:     public static final int     MAG_BIT_MASK = 0x7FFFFFFF;

Why is this an int in the DoubleConst class? It now differs also from previous patch, value is different, too.

I wonder why the asserts don't catch this!

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

Changes requested by uschindler (Author).

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

From fweimer at openjdk.java.net  Thu Jul  8 07:26:51 2021
From: fweimer at openjdk.java.net (Florian Weimer)
Date: Thu, 8 Jul 2021 07:26:51 GMT
Subject: RFR: 6506405: Math.abs(float) is slow
In-Reply-To: <fOQMEZRrM7jbHTMNrq55E54iFZmMjst2IlkIaa2rluI=.df1ad9cf-117e-40a3-b863-dc3365788d4e@github.com>
References: <101iFqz6Ghvzu84BSMu6OyB-8sgTyx32uvfc5R-YTjg=.6a958f74-16cb-4388-a793-abad94093aa9@github.com>
 <ryWWSwNiSFn36zi4nB7yoJsX4CE6V9wSCGB7eC4vNxU=.3de74f10-2b9c-41a1-9e9c-21ae4cb476dd@github.com>
 <fOQMEZRrM7jbHTMNrq55E54iFZmMjst2IlkIaa2rluI=.df1ad9cf-117e-40a3-b863-dc3365788d4e@github.com>
Message-ID: <tR3jEYOLRoZ-l5FI-4ufi_apUJCHv30uviQDyEA5NCE=.73c2b22b-997a-4c15-aaa9-ac38b8a4e13a@github.com>

On Thu, 8 Jul 2021 00:45:48 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> However, the bitwise conversion should now be fast everywhere.

Doesn't it require moves between general-purpose and floating-point registers? Those have to go through memory for some targets (including old x86, where the ISA supports it, but implementations were slow).

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

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

From github.com+10835776+stsypanov at openjdk.java.net  Thu Jul  8 08:57:53 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Thu, 8 Jul 2021 08:57:53 GMT
Subject: RFR: 8266972: Use String.concat() in j.l.Class where
 invokedynamic-based String concatenation is not available [v5]
In-Reply-To: <Ul8iloNoGtv9XMaK7mH661wZTnz1dctIWbNsIhDGPBs=.41c9b36f-e755-41c3-a73b-65d7ef955a21@github.com>
References: <mmH_gQ8uVQa6VMhBzCMHjdgL7wpmwll5DKxnfuS0U9A=.82977d2b-d934-471e-94b6-dd5ef90c037c@github.com>
 <NG4eZhQnumyWdjyWk7l4uMHaPS3lcHFBPkbxWUhl4qc=.12f6d6d9-43c4-4fd4-bbbe-2bfea31513f2@github.com>
 <VbVHWMZQdUbmK_zlWH_QP_Nu1c6vHeReo4Pqmr6vERA=.d5e1f831-dc82-44c3-a66d-3cda1dc03c11@github.com>
 <Ul8iloNoGtv9XMaK7mH661wZTnz1dctIWbNsIhDGPBs=.41c9b36f-e755-41c3-a73b-65d7ef955a21@github.com>
Message-ID: <G8KOeMA3ofodUB9tpME_Jc8AjHIKHBUOXYgNndrcZu4=.506e4813-ffb2-4a5c-b0a7-a575dd864fa5@github.com>

On Wed, 12 May 2021 13:12:07 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> But isn't `componentType.descriptorString()` does this itself? Also multi-dimensional arrays are quite an infrequent usecase, aren't they?
>
> Yeah, it's just an optimization. Current code wouldbuild "[[..[[LFoo;" by recursively going down to `Foo`, build and return "LFoo;", then do "[" + "LFoo;", and so on. Infrequent enough that we can ignore it, sure, but since it's effectively reducing the algorithmic complexity from O(n*m) to O(n+m) I should at least mention it.

I see that `TestPrimitiveArrayCriticalWithBadParam` constantly fails, so I'd probably revert this change

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

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

From github.com+10835776+stsypanov at openjdk.java.net  Thu Jul  8 09:06:20 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Thu, 8 Jul 2021 09:06:20 GMT
Subject: RFR: 8266972: Use String.concat() in j.l.Class where
 invokedynamic-based String concatenation is not available [v6]
In-Reply-To: <mmH_gQ8uVQa6VMhBzCMHjdgL7wpmwll5DKxnfuS0U9A=.82977d2b-d934-471e-94b6-dd5ef90c037c@github.com>
References: <mmH_gQ8uVQa6VMhBzCMHjdgL7wpmwll5DKxnfuS0U9A=.82977d2b-d934-471e-94b6-dd5ef90c037c@github.com>
Message-ID: <pSSe2idBWzR11qMt9rFIWh2U3ttT_iw6dlnnTbiB9oQ=.b98493d4-1668-40d5-a027-183173c1756b@github.com>

> Hello, from discussion in https://github.com/openjdk/jdk/pull/3464 I've found out, that in a few of JDK core classes, e.g. in `j.l.Class` expressions like `baseName.replace('.', '/') + '/' + name` are not compiled into `invokedynamic`-based code, but into one using `StringBuilder`. This happens due to some bootstraping issues.
> 
> However the code like
> 
> private String getSimpleName0() {
>     if (isArray()) {
>         return getComponentType().getSimpleName() + "[]";
>     }
>     //...
> }
> 
> can be improved via replacement of `+` with `String.concat()` call.
> 
> I've used this benchmark to measure impact:
> 
> @State(Scope.Thread)
> @BenchmarkMode(Mode.AverageTime)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"})
> public class ClassMethodsBenchmark {
>   private final Class<? extends Object[]> arrayClass = Object[].class;
>   private Method descriptorString;
> 
>   @Setup
>   public void setUp() throws NoSuchMethodException {
>     //fore some reason compiler doesn't allow me to call Class.descriptorString() directly
>     descriptorString = Class.class.getDeclaredMethod("descriptorString");
>   }
> 
>   @Benchmark
>   public Object descriptorString() throws Exception {
>     return descriptorString.invoke(arrayClass);
>   }
> 
>   @Benchmark
>   public Object typeName() {
>     return arrayClass.getTypeName();
>   }
> }
> 
> and got those results
> 
>                                                    Mode  Cnt     Score     Error   Units
> descriptorString                                   avgt   60    91.480 ?   1.839   ns/op
> descriptorString:?gc.alloc.rate.norm               avgt   60   404.008 ?   4.033    B/op
> descriptorString:?gc.churn.G1_Eden_Space           avgt   60  2791.866 ? 181.589  MB/sec
> descriptorString:?gc.churn.G1_Eden_Space.norm      avgt   60   401.702 ?  26.047    B/op
> descriptorString:?gc.churn.G1_Survivor_Space       avgt   60     0.003 ?   0.001  MB/sec
> descriptorString:?gc.churn.G1_Survivor_Space.norm  avgt   60    ? 10??              B/op
> descriptorString:?gc.count                         avgt   60   205.000            counts
> descriptorString:?gc.time                          avgt   60   216.000                ms
> 
> patched
>                                                    Mode  Cnt     Score     Error   Units
> descriptorString                                   avgt   60    65.016 ?   3.446   ns/op
> descriptorString:?gc.alloc.rate                    avgt   60  2844.240 ? 115.719  MB/sec
> descriptorString:?gc.alloc.rate.norm               avgt   60   288.006 ?   0.001    B/op
> descriptorString:?gc.churn.G1_Eden_Space           avgt   60  2832.996 ? 206.939  MB/sec
> descriptorString:?gc.churn.G1_Eden_Space.norm      avgt   60   286.955 ?  17.853    B/op
> descriptorString:?gc.churn.G1_Survivor_Space       avgt   60     0.003 ?   0.001  MB/sec
> descriptorString:?gc.churn.G1_Survivor_Space.norm  avgt   60    ? 10??              B/op
> descriptorString:?gc.count                         avgt   60   208.000            counts
> descriptorString:?gc.time                          avgt   60   228.000                ms
> -----------------
> typeName                                           avgt   60    34.273 ?   0.480   ns/op
> typeName:?gc.alloc.rate                            avgt   60  3265.356 ?  45.113  MB/sec
> typeName:?gc.alloc.rate.norm                       avgt   60   176.004 ?   0.001    B/op
> typeName:?gc.churn.G1_Eden_Space                   avgt   60  3268.454 ? 134.458  MB/sec
> typeName:?gc.churn.G1_Eden_Space.norm              avgt   60   176.109 ?   6.595    B/op
> typeName:?gc.churn.G1_Survivor_Space               avgt   60     0.003 ?   0.001  MB/sec
> typeName:?gc.churn.G1_Survivor_Space.norm          avgt   60    ? 10??              B/op
> typeName:?gc.count                                 avgt   60   240.000            counts
> typeName:?gc.time                                  avgt   60   255.000                ms
> 
> patched
> 
> typeName                                           avgt   60    15.787 ?   0.214   ns/op
> typeName:?gc.alloc.rate                            avgt   60  2577.554 ?  32.339  MB/sec
> typeName:?gc.alloc.rate.norm                       avgt   60    64.001 ?   0.001    B/op
> typeName:?gc.churn.G1_Eden_Space                   avgt   60  2574.039 ? 147.774  MB/sec
> typeName:?gc.churn.G1_Eden_Space.norm              avgt   60    63.895 ?   3.511    B/op
> typeName:?gc.churn.G1_Survivor_Space               avgt   60     0.003 ?   0.001  MB/sec
> typeName:?gc.churn.G1_Survivor_Space.norm          avgt   60    ? 10??              B/op
> typeName:?gc.count                                 avgt   60   189.000            counts
> typeName:?gc.time                                  avgt   60   199.000                ms
> 
> I think this patch is likely to improve reflection operations related to arrays.
> 
> If one finds this patch useful, then I'll create a ticket to track this. Also it'd be nice to have a list of classes, that are compiled in the same way as `j.l.Class` (i.e. have no access to `invokedynamic`) so I could look into them for other snippets where two String are joined so `concat`-based optimization is possible.
> 
> Pre-sizing of `StringBuilder` for `Class.gdescriptorString()` and `Class.getCanonicalName0()` is one more improvement opportunity here.

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

 - Merge remote-tracking branch 'origin/class-concat' into class-concat
 - Merge branch 'master' into class-concat
 - Merge branch 'master' into class-concat
 - 8266972: Revert change in Class.descriptorString()
 - Merge branch 'master' into class-concat
 - Merge branch 'master' into class-concat
 - 8266972: Use String.concat() in j.l.Class.toSting()
 - Use String.concat() where invokedynamic-based String concatenation is not available

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3627/files
  - new: https://git.openjdk.java.net/jdk/pull/3627/files/4fd6dc00..aba59d3d

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

  Stats: 5870 lines in 156 files changed: 4241 ins; 755 del; 874 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3627.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3627/head:pull/3627

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

From jlahoda at openjdk.java.net  Thu Jul  8 09:17:16 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Thu, 8 Jul 2021 09:17:16 GMT
Subject: [jdk17] RFR: 8268766: Desugaring of pattern matching enum switch
 should be improved [v9]
In-Reply-To: <3xKa946t0s_eRqnj0vfgjkfurBvZqKGe1QkYk-0lNO0=.518519f5-a2cb-44ed-946c-09e517e7c5d2@github.com>
References: <3xKa946t0s_eRqnj0vfgjkfurBvZqKGe1QkYk-0lNO0=.518519f5-a2cb-44ed-946c-09e517e7c5d2@github.com>
Message-ID: <dm2UfqPlvsA2ex6N1iigTDRPFr9szudlNEsd5dKCGek=.19847b26-4eb6-4e9e-93bf-2bed4ad90de3@github.com>

> Currently, an enum switch with patterns is desugared in a very non-standard, and potentially slow, way. It would be better to use the standard `typeSwitch` bootstrap to classify the enum constants. The bootstrap needs to accept enum constants as labels in order to allow this. A complication is that if an enum constant is missing, that is not an incompatible change for the switch, and the switch should simply work as if the case for the missing constant didn't exist. So, the proposed solution is to have a new bootstrap `enumSwitch` that accepts `String`s in place of the enum constants, and will internally convert them to the appropriate enum constants, and then it will find the proper case similarly to `typeSwitch`.
> 
> How does this look?

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

  Adding a testcase for an enum that implements an interface.

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

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/81/files
  - new: https://git.openjdk.java.net/jdk17/pull/81/files/d970402e..fe3de7d7

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

  Stats: 25 lines in 1 file changed: 24 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/81.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/81/head:pull/81

PR: https://git.openjdk.java.net/jdk17/pull/81

From mcimadamore at openjdk.java.net  Thu Jul  8 09:24:49 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 8 Jul 2021 09:24:49 GMT
Subject: [jdk17] RFR: 8268766: Desugaring of pattern matching enum switch
 should be improved [v9]
In-Reply-To: <dm2UfqPlvsA2ex6N1iigTDRPFr9szudlNEsd5dKCGek=.19847b26-4eb6-4e9e-93bf-2bed4ad90de3@github.com>
References: <3xKa946t0s_eRqnj0vfgjkfurBvZqKGe1QkYk-0lNO0=.518519f5-a2cb-44ed-946c-09e517e7c5d2@github.com>
 <dm2UfqPlvsA2ex6N1iigTDRPFr9szudlNEsd5dKCGek=.19847b26-4eb6-4e9e-93bf-2bed4ad90de3@github.com>
Message-ID: <nTTK8HMo4tsjN_rzYem2UqJPByJ8t6x9mf5g9GEus54=.2b7581d4-a3a5-4d76-984d-cb0bd26362a6@github.com>

On Thu, 8 Jul 2021 09:17:16 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Currently, an enum switch with patterns is desugared in a very non-standard, and potentially slow, way. It would be better to use the standard `typeSwitch` bootstrap to classify the enum constants. The bootstrap needs to accept enum constants as labels in order to allow this. A complication is that if an enum constant is missing, that is not an incompatible change for the switch, and the switch should simply work as if the case for the missing constant didn't exist. So, the proposed solution is to have a new bootstrap `enumSwitch` that accepts `String`s in place of the enum constants, and will internally convert them to the appropriate enum constants, and then it will find the proper case similarly to `typeSwitch`.
>> 
>> How does this look?
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adding a testcase for an enum that implements an interface.

Looks good

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

Marked as reviewed by mcimadamore (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/81

From github.com+10835776+stsypanov at openjdk.java.net  Thu Jul  8 09:32:02 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Thu, 8 Jul 2021 09:32:02 GMT
Subject: RFR: 8263561: Re-examine uses of LinkedList [v4]
In-Reply-To: <eCQ8oFDjAJgFR3SG0K7GlaM1lxivFOkQGkIi-i7I7Xw=.bd379708-2bb4-4d52-81e3-175fb7a9c46b@github.com>
References: <eCQ8oFDjAJgFR3SG0K7GlaM1lxivFOkQGkIi-i7I7Xw=.bd379708-2bb4-4d52-81e3-175fb7a9c46b@github.com>
Message-ID: <HKWDbXjH2i_rbOzyRaCheEGZCop9nB5hkfdOUlGMCQU=.72d4db7e-f057-4151-913b-f836da3262ce@github.com>

> After I've renamed remove branch GitHub for some reason has closed original https://github.com/openjdk/jdk/pull/2744, so I've decided to recreate it.

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

 - Merge branch 'master' into 8263561
 - Merge branch 'master' into 8263561
 - Merge branch 'master' into 8263561
 - Merge branch 'master' into 8263561
   
   # Conflicts:
   #	src/java.base/unix/classes/sun/net/dns/ResolverConfigurationImpl.java
 - Merge branch 'master' into purge-linked-list
 - 8263561: Use sized constructor where reasonable
 - 8263561: Use interface List instead of particular type where possible
 - 8263561: Rename requestList -> requests
 - 8263561: Re-examine uses of LinkedList

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

Changes: https://git.openjdk.java.net/jdk/pull/4304/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4304&range=03
  Stats: 48 lines in 9 files changed: 0 ins; 2 del; 46 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4304.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4304/head:pull/4304

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

From github.com+10835776+stsypanov at openjdk.java.net  Thu Jul  8 09:37:18 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Thu, 8 Jul 2021 09:37:18 GMT
Subject: RFR: 8268113: Re-use Long.hashCode() where possible [v9]
In-Reply-To: <7TGw6Vzvw38bqmNOQsuVuGXMe98OqH25nmexLUghcMU=.5e7b347c-0d83-4e54-acc3-9847c08cdc29@github.com>
References: <7TGw6Vzvw38bqmNOQsuVuGXMe98OqH25nmexLUghcMU=.5e7b347c-0d83-4e54-acc3-9847c08cdc29@github.com>
Message-ID: <hwghF042fNQbpp7FJQGcySNsRa_koP8n9gsndheJ0Ys=.d6e86f3f-1170-47fb-aa98-46feb1f3e61a@github.com>

> There is a few JDK classes duplicating the contents of Long.hashCode() for hash code calculation. They should explicitly delegate to Long.hashCode().

?????? ??????? has updated the pull request with a new target base 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 8268113
 - Merge branch 'master' into 8268113
 - Merge branch 'master' into 8268113
 - Merge branch 'master' into 8268113
 - Merge branch 'master' into 8268113
 - Merge branch 'master' into 8268113
 - 8268113: Inline local vars where reasonable
 - 8268113: Delegate to Double.hashCode()
 - 8268113: Re-use Long.hashCode() where possible

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4309/files
  - new: https://git.openjdk.java.net/jdk/pull/4309/files/4ec7c829..a72a09b6

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

  Stats: 23569 lines in 424 files changed: 8574 ins; 13030 del; 1965 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4309.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4309/head:pull/4309

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

From aph at openjdk.java.net  Thu Jul  8 09:46:45 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Thu, 8 Jul 2021 09:46:45 GMT
Subject: RFR: 6506405: Math.abs(float) is slow [v2]
In-Reply-To: <a6dTrhE64I49kW2H2BiYfS1otWfFYehpqxFqWIsFk1A=.c1ce2233-2768-4981-9c6d-7314d2d4c52c@github.com>
References: <101iFqz6Ghvzu84BSMu6OyB-8sgTyx32uvfc5R-YTjg=.6a958f74-16cb-4388-a793-abad94093aa9@github.com>
 <a6dTrhE64I49kW2H2BiYfS1otWfFYehpqxFqWIsFk1A=.c1ce2233-2768-4981-9c6d-7314d2d4c52c@github.com>
Message-ID: <zR8beQDtJKBakwHKPorFtbv7ej7JHUnK3XLU12XwHS4=.53725c64-1c43-4b3d-b66d-f07fae8f7f47@github.com>

On Thu, 8 Jul 2021 01:05:16 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Please consider this change to make the `float` and `double` versions of `java.lang.Math.abs()` branch-free.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   6506405: Add comments, use new consts for masking

Moves between GPRs and FPRs are often slow. There's a 10-cycle latency on some AArch64, so we avoid it whenever we can. Mind you, we don't care about this patch because we always generate FABS from an intrinsic anyway.

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

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

From aph at openjdk.java.net  Thu Jul  8 10:50:54 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Thu, 8 Jul 2021 10:50:54 GMT
Subject: RFR: 6506405: Math.abs(float) is slow [v2]
In-Reply-To: <zR8beQDtJKBakwHKPorFtbv7ej7JHUnK3XLU12XwHS4=.53725c64-1c43-4b3d-b66d-f07fae8f7f47@github.com>
References: <101iFqz6Ghvzu84BSMu6OyB-8sgTyx32uvfc5R-YTjg=.6a958f74-16cb-4388-a793-abad94093aa9@github.com>
 <a6dTrhE64I49kW2H2BiYfS1otWfFYehpqxFqWIsFk1A=.c1ce2233-2768-4981-9c6d-7314d2d4c52c@github.com>
 <zR8beQDtJKBakwHKPorFtbv7ej7JHUnK3XLU12XwHS4=.53725c64-1c43-4b3d-b66d-f07fae8f7f47@github.com>
Message-ID: <CjcdjymndD7ZVob-NxTi3QzmZclxnHA7vM3Z8DDef5c=.7dc4ac45-d44a-45cb-8376-5ad55396154d@github.com>

On Thu, 8 Jul 2021 09:43:35 GMT, Andrew Haley <aph at openjdk.org> wrote:

> Moves between GPRs and FPRs are often slow. There's a 10-cycle latency on some AArch64, so we avoid it whenever we can. Mind you, we don't care about this patch because we always generate FABS from an intrinsic anyway.

For avoidance of doubt, that's the round-trip latency.

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

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

From joe.darcy at oracle.com  Thu Jul  8 11:26:55 2021
From: joe.darcy at oracle.com (Joe Darcy)
Date: Thu, 8 Jul 2021 04:26:55 -0700
Subject: RFR: 6506405: Math.abs(float) is slow [v2]
In-Reply-To: <CjcdjymndD7ZVob-NxTi3QzmZclxnHA7vM3Z8DDef5c=.7dc4ac45-d44a-45cb-8376-5ad55396154d@github.com>
References: <101iFqz6Ghvzu84BSMu6OyB-8sgTyx32uvfc5R-YTjg=.6a958f74-16cb-4388-a793-abad94093aa9@github.com>
 <a6dTrhE64I49kW2H2BiYfS1otWfFYehpqxFqWIsFk1A=.c1ce2233-2768-4981-9c6d-7314d2d4c52c@github.com>
 <zR8beQDtJKBakwHKPorFtbv7ej7JHUnK3XLU12XwHS4=.53725c64-1c43-4b3d-b66d-f07fae8f7f47@github.com>
 <CjcdjymndD7ZVob-NxTi3QzmZclxnHA7vM3Z8DDef5c=.7dc4ac45-d44a-45cb-8376-5ad55396154d@github.com>
Message-ID: <68727dfc-b197-cd72-37e6-f5cee34c17fd@oracle.com>

On 7/8/2021 3:50 AM, Andrew Haley wrote:
> On Thu, 8 Jul 2021 09:43:35 GMT, Andrew Haley <aph at openjdk.org> wrote:
>
>> Moves between GPRs and FPRs are often slow. There's a 10-cycle latency on some AArch64, so we avoid it whenever we can. Mind you, we don't care about this patch because we always generate FABS from an intrinsic anyway.
> For avoidance of doubt, that's the round-trip latency.
>
> -------------
>
> PR: https://git.openjdk.java.net/jdk/pull/4711


For coding this functionality in Java, the natural way to do this uses 
either an if statement or the bit-wise conversion, which usually implies 
GPRs to/from FPRs movement. I don't see a way to avoid both an if 
statement and bitwise conversion.

-Joe


From jlahoda at openjdk.java.net  Thu Jul  8 12:00:02 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Thu, 8 Jul 2021 12:00:02 GMT
Subject: [jdk17] Integrated: 8268766: Desugaring of pattern matching enum
 switch should be improved
In-Reply-To: <3xKa946t0s_eRqnj0vfgjkfurBvZqKGe1QkYk-0lNO0=.518519f5-a2cb-44ed-946c-09e517e7c5d2@github.com>
References: <3xKa946t0s_eRqnj0vfgjkfurBvZqKGe1QkYk-0lNO0=.518519f5-a2cb-44ed-946c-09e517e7c5d2@github.com>
Message-ID: <STa6bp1K-DI1yZyl7iMmt8ZoC9en5Ot_UPpZf5hJ7sE=.02e9eb2c-e9c7-417e-a570-45865c0ec347@github.com>

On Wed, 16 Jun 2021 15:15:25 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Currently, an enum switch with patterns is desugared in a very non-standard, and potentially slow, way. It would be better to use the standard `typeSwitch` bootstrap to classify the enum constants. The bootstrap needs to accept enum constants as labels in order to allow this. A complication is that if an enum constant is missing, that is not an incompatible change for the switch, and the switch should simply work as if the case for the missing constant didn't exist. So, the proposed solution is to have a new bootstrap `enumSwitch` that accepts `String`s in place of the enum constants, and will internally convert them to the appropriate enum constants, and then it will find the proper case similarly to `typeSwitch`.
> 
> How does this look?

This pull request has now been integrated.

Changeset: fa08cc62
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.java.net/jdk17/commit/fa08cc62df10e4b6e3cbc45d4e889191d67048c4
Stats:     470 lines in 7 files changed: 329 ins; 68 del; 73 mod

8268766: Desugaring of pattern matching enum switch should be improved

Reviewed-by: mcimadamore, psandoz

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

PR: https://git.openjdk.java.net/jdk17/pull/81

From yyang at openjdk.java.net  Thu Jul  8 12:00:14 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Thu, 8 Jul 2021 12:00:14 GMT
Subject: RFR: 8270057: Use Objects.checkFromToIndex for
 j.u.c.CopyOnWriteArrayList
Message-ID: <wdDziL-vJEHrIR5PCSI7RA33E-OGDNFO58BL8GDnJsw=.51ae86bb-0cb8-4fd4-8e3c-2dbad7694c68@github.com>

After JDK-8265518(#3615), it's possible to replace all variants of checkIndex by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in the whole JDK codebase.

As Mandy suggested, I create this PR for changes involving  JUC changes.

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

Commit messages:
 - replace

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

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

From whuang at openjdk.java.net  Thu Jul  8 12:29:08 2021
From: whuang at openjdk.java.net (Wang Huang)
Date: Thu, 8 Jul 2021 12:29:08 GMT
Subject: RFR: 8268231: Aarch64: Use ldp in intrinsics for String.compareTo
Message-ID: <XwW4MjGSYmSHa2ZbzrOfvoZi1pe8LJAK7YIKtmNhaDM=.d39df32e-8698-4608-9184-3b19cd175d1a@github.com>

Dear all, 
    Can you do me a favor to review this patch. This patch use `ldp` to implement String.compareTo.
   
* We add a JMH test case 
* Here is the result of this test case
 
Benchmark	                       |(size)| Mode| Cnt|Score | Error	 |Units	
---------------------------------|------|-----|----|------|--------|-----
StringCompare.compareLL       |  64  | avgt| 5  |7.992 | ?	0.005|us/op
StringCompare.compareLL       |  72  | avgt| 5  |15.029| ?	0.006|us/op
StringCompare.compareLL       |  80  | avgt| 5  |14.655| ?	0.011|us/op
StringCompare.compareLL       |  91  | avgt| 5  |16.363| ?	0.12 |us/op
StringCompare.compareLL       |  101 | avgt| 5  |16.966| ?	0.007|us/op
StringCompare.compareLL       |  121 | avgt| 5  |19.276| ?	0.006|us/op
StringCompare.compareLL       |  181 | avgt| 5  |19.002| ?	0.417|us/op
StringCompare.compareLL       |  256 | avgt| 5  |24.707| ?	0.041|us/op
StringCompare.compareLLWithLdp|  64  | avgt| 5  |8.001	| ?	0.121|us/op
StringCompare.compareLLWithLdp|  72  | avgt| 5  |11.573| ?	0.003|us/op
StringCompare.compareLLWithLdp|  80  | avgt| 5  |6.861 | ?	0.004|us/op
StringCompare.compareLLWithLdp|  91  | avgt| 5  |12.774| ?	0.201|us/op
StringCompare.compareLLWithLdp|  101 | avgt| 5  |8.691 | ?	0.004|us/op
StringCompare.compareLLWithLdp|  121 | avgt| 5  |11.091| ?	1.342|us/op
StringCompare.compareLLWithLdp|  181 | avgt| 5  |14.64 | ?	0.581|us/op
StringCompare.compareLLWithLdp|  256 | avgt| 5  |25.879| ?	1.775|us/op
StringCompare.compareUU       |  64  | avgt| 5  |13.476| ?	0.01 |us/op
StringCompare.compareUU       |  72  | avgt| 5  |15.078| ?	0.006|us/op
StringCompare.compareUU       |  80  | avgt| 5  |23.512| ?	0.011|us/op
StringCompare.compareUU       |  91  | avgt| 5  |24.284| ?	0.008|us/op
StringCompare.compareUU       |  101 | avgt| 5  |20.707| ?	0.017|us/op
StringCompare.compareUU       |  121 | avgt| 5  |29.302| ?	0.011|us/op
StringCompare.compareUU       |  181 | avgt| 5  |39.31	| ?	0.016|us/op
StringCompare.compareUU       |  256 | avgt| 5  |54.592| ?	0.392|us/op
StringCompare.compareUUWithLdp|  64  | avgt| 5  |16.389| ?	0.008|us/op
StringCompare.compareUUWithLdp|  72  | avgt| 5  |10.71 | ?	0.158|us/op
StringCompare.compareUUWithLdp|  80  | avgt| 5  |11.488| ?	0.024|us/op
StringCompare.compareUUWithLdp|  91  | avgt| 5  |13.412| ?	0.006|us/op
StringCompare.compareUUWithLdp|  101 | avgt| 5  |16.245| ?	0.434|us/op
StringCompare.compareUUWithLdp|  121 | avgt| 5  |16.597| ?	0.016|us/op
StringCompare.compareUUWithLdp|  181 | avgt| 5  |27.373| ?	0.017|us/op
StringCompare.compareUUWithLdp|  256 | avgt| 5  |41.74 | ?	3.5	 |us/op

>From this table, we can see that in most cases, our patch is better than old one.

Thank you for your review. Any suggestions are welcome.

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

Commit messages:
 - 8268231: Aarch64: Use ldp in intrinsics for String.compareTo

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

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

From bpb at openjdk.java.net  Thu Jul  8 15:34:16 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 8 Jul 2021 15:34:16 GMT
Subject: RFR: 6506405: Math.abs(float) is slow [v3]
In-Reply-To: <101iFqz6Ghvzu84BSMu6OyB-8sgTyx32uvfc5R-YTjg=.6a958f74-16cb-4388-a793-abad94093aa9@github.com>
References: <101iFqz6Ghvzu84BSMu6OyB-8sgTyx32uvfc5R-YTjg=.6a958f74-16cb-4388-a793-abad94093aa9@github.com>
Message-ID: <Hp1mFLsNNgO6wY_9MASQPYvZFPteQduZwIBtNfL__vg=.29b3f9b4-17e5-4a40-a21c-4c3568eca331@github.com>

> Please consider this change to make the `float` and `double` versions of `java.lang.Math.abs()` branch-free.

Brian Burkhalter 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:

  6506405: Add comments, use new consts for masking

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4711/files
  - new: https://git.openjdk.java.net/jdk/pull/4711/files/ba950f60..174c8293

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

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

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

From bpb at openjdk.java.net  Thu Jul  8 15:34:17 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 8 Jul 2021 15:34:17 GMT
Subject: RFR: 6506405: Math.abs(float) is slow [v2]
In-Reply-To: <a6dTrhE64I49kW2H2BiYfS1otWfFYehpqxFqWIsFk1A=.c1ce2233-2768-4981-9c6d-7314d2d4c52c@github.com>
References: <101iFqz6Ghvzu84BSMu6OyB-8sgTyx32uvfc5R-YTjg=.6a958f74-16cb-4388-a793-abad94093aa9@github.com>
 <a6dTrhE64I49kW2H2BiYfS1otWfFYehpqxFqWIsFk1A=.c1ce2233-2768-4981-9c6d-7314d2d4c52c@github.com>
Message-ID: <eSr_yKqplkvFQswE5Zp7nCO7F_HoMR_-FnFUa7zS4ow=.b6965bc8-a411-4505-9eb4-cd4ecae45259@github.com>

On Thu, 8 Jul 2021 01:05:16 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Please consider this change to make the `float` and `double` versions of `java.lang.Math.abs()` branch-free.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   6506405: Add comments, use new consts for masking

Corrected stupid `DoubleConsts.MAG_BIT_MASK` error via force-push.

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

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

From darcy at openjdk.java.net  Thu Jul  8 15:48:57 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 8 Jul 2021 15:48:57 GMT
Subject: RFR: 6506405: Math.abs(float) is slow [v3]
In-Reply-To: <Hp1mFLsNNgO6wY_9MASQPYvZFPteQduZwIBtNfL__vg=.29b3f9b4-17e5-4a40-a21c-4c3568eca331@github.com>
References: <101iFqz6Ghvzu84BSMu6OyB-8sgTyx32uvfc5R-YTjg=.6a958f74-16cb-4388-a793-abad94093aa9@github.com>
 <Hp1mFLsNNgO6wY_9MASQPYvZFPteQduZwIBtNfL__vg=.29b3f9b4-17e5-4a40-a21c-4c3568eca331@github.com>
Message-ID: <6_fzTJMaZSvjv12UzeNH2VH9f_2pmrICFWEzqaNvcBE=.4af94ebf-02bb-4d51-9998-c9f5758fbb26@github.com>

On Thu, 8 Jul 2021 15:34:16 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Please consider this change to make the `float` and `double` versions of `java.lang.Math.abs()` branch-free.
>
> Brian Burkhalter 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/math/DoubleConsts.java line 80:

> 78:      * significand fields) of a {@code double}.
> 79:      */
> 80:     public static final long    MAG_BIT_MASK = 0x7FFFFFFFFFFFFFFFL;

Might be more "obviously correct" if these new fields were initialized as ~SIGN_BIT_MASK.

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

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

From bpb at openjdk.java.net  Thu Jul  8 15:53:18 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 8 Jul 2021 15:53:18 GMT
Subject: RFR: 6506405: Math.abs(float) is slow [v4]
In-Reply-To: <101iFqz6Ghvzu84BSMu6OyB-8sgTyx32uvfc5R-YTjg=.6a958f74-16cb-4388-a793-abad94093aa9@github.com>
References: <101iFqz6Ghvzu84BSMu6OyB-8sgTyx32uvfc5R-YTjg=.6a958f74-16cb-4388-a793-abad94093aa9@github.com>
Message-ID: <hSGt_2dLYMl2uTHz4DQp8D8yvhdC93M4TBxquRC-bUc=.70ab0fc4-b34e-41bf-83dc-311e937d73b5@github.com>

> Please consider this change to make the `float` and `double` versions of `java.lang.Math.abs()` branch-free.

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

  6506405: Set MAG_BIT_MASKs to bit-wise complements of SIGN_BIT_MASKs

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4711/files
  - new: https://git.openjdk.java.net/jdk/pull/4711/files/174c8293..9c35e74a

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

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

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

From darcy at openjdk.java.net  Thu Jul  8 17:05:53 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 8 Jul 2021 17:05:53 GMT
Subject: RFR: 6506405: Math.abs(float) is slow [v4]
In-Reply-To: <hSGt_2dLYMl2uTHz4DQp8D8yvhdC93M4TBxquRC-bUc=.70ab0fc4-b34e-41bf-83dc-311e937d73b5@github.com>
References: <101iFqz6Ghvzu84BSMu6OyB-8sgTyx32uvfc5R-YTjg=.6a958f74-16cb-4388-a793-abad94093aa9@github.com>
 <hSGt_2dLYMl2uTHz4DQp8D8yvhdC93M4TBxquRC-bUc=.70ab0fc4-b34e-41bf-83dc-311e937d73b5@github.com>
Message-ID: <unqdqQQyTbmlGcjMxyEoEcX0IGt4wjjg5bjikWIhRss=.4e020e4b-666a-4318-9563-96821cd9e066@github.com>

On Thu, 8 Jul 2021 15:53:18 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Please consider this change to make the `float` and `double` versions of `java.lang.Math.abs()` branch-free.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   6506405: Set MAG_BIT_MASKs to bit-wise complements of SIGN_BIT_MASKs

Marked as reviewed by darcy (Reviewer).

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

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

From bpb at openjdk.java.net  Thu Jul  8 18:15:23 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 8 Jul 2021 18:15:23 GMT
Subject: RFR: 6506405: Math.abs(float) is slow [v5]
In-Reply-To: <101iFqz6Ghvzu84BSMu6OyB-8sgTyx32uvfc5R-YTjg=.6a958f74-16cb-4388-a793-abad94093aa9@github.com>
References: <101iFqz6Ghvzu84BSMu6OyB-8sgTyx32uvfc5R-YTjg=.6a958f74-16cb-4388-a793-abad94093aa9@github.com>
Message-ID: <EEMmha55jEwlxnby9QOpfj8VCggPUjF8uw42sLXWvx8=.c1fc135e-176e-4f35-a6e7-a3feae63148e@github.com>

> Please consider this change to make the `float` and `double` versions of `java.lang.Math.abs()` branch-free.

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

  6506405: Add some tests

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4711/files
  - new: https://git.openjdk.java.net/jdk/pull/4711/files/9c35e74a..5ac31ec4

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

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

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

From joe.darcy at oracle.com  Thu Jul  8 18:25:14 2021
From: joe.darcy at oracle.com (Joe Darcy)
Date: Thu, 8 Jul 2021 11:25:14 -0700
Subject: RFR: 6506405: Math.abs(float) is slow [v2]
In-Reply-To: <68727dfc-b197-cd72-37e6-f5cee34c17fd@oracle.com>
References: <101iFqz6Ghvzu84BSMu6OyB-8sgTyx32uvfc5R-YTjg=.6a958f74-16cb-4388-a793-abad94093aa9@github.com>
 <a6dTrhE64I49kW2H2BiYfS1otWfFYehpqxFqWIsFk1A=.c1ce2233-2768-4981-9c6d-7314d2d4c52c@github.com>
 <zR8beQDtJKBakwHKPorFtbv7ej7JHUnK3XLU12XwHS4=.53725c64-1c43-4b3d-b66d-f07fae8f7f47@github.com>
 <CjcdjymndD7ZVob-NxTi3QzmZclxnHA7vM3Z8DDef5c=.7dc4ac45-d44a-45cb-8376-5ad55396154d@github.com>
 <68727dfc-b197-cd72-37e6-f5cee34c17fd@oracle.com>
Message-ID: <d16527b8-1706-438a-701b-ffbf2b1906e0@oracle.com>

PS The benefit of an intrinsic in a case like this is being to use a 
platform-optimized implementation, trading off native instruction, 
floating-point branch, and bitwise conversion costs.

-Joe

On 7/8/2021 4:26 AM, Joe Darcy wrote:
> On 7/8/2021 3:50 AM, Andrew Haley wrote:
>> On Thu, 8 Jul 2021 09:43:35 GMT, Andrew Haley <aph at openjdk.org> wrote:
>>
>>> Moves between GPRs and FPRs are often slow. There's a 10-cycle 
>>> latency on some AArch64, so we avoid it whenever we can. Mind you, 
>>> we don't care about this patch because we always generate FABS from 
>>> an intrinsic anyway.
>> For avoidance of doubt, that's the round-trip latency.
>>
>> -------------
>>
>> PR: https://git.openjdk.java.net/jdk/pull/4711
>
>
> For coding this functionality in Java, the natural way to do this uses 
> either an if statement or the bit-wise conversion, which usually 
> implies GPRs to/from FPRs movement. I don't see a way to avoid both an 
> if statement and bitwise conversion.
>
> -Joe
>

From bpb at openjdk.java.net  Thu Jul  8 19:08:56 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 8 Jul 2021 19:08:56 GMT
Subject: [jdk17] Integrated: 6766844: ByteArrayInputStream#read with a byte
 array of length 0 not consistent with InputStream when at EOF
In-Reply-To: <8nNGNaJvrmtiLTlJcIazAl5J7iVsBxbhEeAItADAoKc=.824db13a-589c-421e-8595-01ac4e5c27bd@github.com>
References: <8nNGNaJvrmtiLTlJcIazAl5J7iVsBxbhEeAItADAoKc=.824db13a-589c-421e-8595-01ac4e5c27bd@github.com>
Message-ID: <bUT0b-fK9WMT1WsLUc0Nb07cLsJ6mH99gjBGWhuTmc4=.28c84b73-1efb-4ced-8b12-efa35d9654e4@github.com>

On Wed, 30 Jun 2021 23:00:24 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Modify the specification of `java.io.ByteArrayInputStream#read(byte[],int,int)` to indicate that `-1` is returned instead of `0` when the stream is at its end and the third parameter, `len`, is zero.

This pull request has now been integrated.

Changeset: f46a9172
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk17/commit/f46a9172700a3e2d63cb772e604120bb6f60d4b0
Stats:     18 lines in 2 files changed: 12 ins; 1 del; 5 mod

6766844: ByteArrayInputStream#read with a byte array of length 0 not consistent with InputStream when at EOF

Reviewed-by: naoto, lancea, joehw

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

PR: https://git.openjdk.java.net/jdk17/pull/189

From mchung at openjdk.java.net  Thu Jul  8 19:22:54 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Thu, 8 Jul 2021 19:22:54 GMT
Subject: RFR: 8270056: Generated lambda class can not access protected
 static method of target class
In-Reply-To: <bDVkalKu_hLAwlGagLIkFol-aLy98PngVw8FrLc0pRM=.0670192d-ae03-4d31-82bb-097e20ae4ffd@github.com>
References: <bDVkalKu_hLAwlGagLIkFol-aLy98PngVw8FrLc0pRM=.0670192d-ae03-4d31-82bb-097e20ae4ffd@github.com>
Message-ID: <ddcJ9yqSUu8sQgI0FSDrb95w-mGzu4GXWxU5DNWfC2M=.1093d29b-d7ea-4e56-9d52-e31144033e6a@github.com>

On Thu, 8 Jul 2021 02:32:45 GMT, Yi Yang <yyang at openjdk.org> wrote:

> Generated lambda class can not access protected static method of the target class. The following exception is thrown when executing the attached reproducible program:
> 
> 
> Exception in thread "main" java.lang.IllegalAccessError: class AccessProtectedStaticMethodFromSuper$B$$Lambda$15/0x0000000800b8ea48 tried to access protected method 'void AccessProtectedStaticMethodFromSuper$A.func()' (AccessProtectedStaticMethodFromSuper$B$$Lambda$15/0x0000000800b8ea48 is in unnamed module of loader AccessProtectedStaticMethodFromSuper$1Loader @71dac704; AccessProtectedStaticMethodFromSuper$A is in unnamed module of loader AccessProtectedStaticMethodFromSuper$1Loader @39ed3c8d)
> 	at AccessProtectedStaticMethodFromSuper.main(AccessProtectedStaticMethodFromSuper.java:51)
> 
> 
> This issue is similar to JDK-8254975(#767) with slight differences: generated lambda proxy calls static protected method rather than protected member method.
> 
> The proposed fix 1) tries to use MethodHandle instead of invoking forwardee directly(since the lambda class has no access to the resolved method) and 2) does not force accepting an implClass as the first argument when invoking a static method.
> 
> Testing:
> - test/jdk/java/ with release mode
> - presubmit tests

Good catch.   It should check if the target class (not `implClass`) and the declaring class of the implementation's method handle are in the same package if it's protected.

I prefer to add the new test case in the existing test `test/jdk/java/lang/invoke/lambda/superProtectedMethod/SuperMethodTest.java`.   The test's name may be made clearer to rename to `ProtectedMethodInOtherPackage` (something like that)

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

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

From mchung at openjdk.java.net  Thu Jul  8 19:49:59 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Thu, 8 Jul 2021 19:49:59 GMT
Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex,
 FromIndexSize} for java.base [v11]
In-Reply-To: <QM4u0adwYkgwPAp9Rr4v5M_2tC0EaWO9kctj8pXKt-U=.102e4127-2fe4-4be6-aa46-74f6cb040c44@github.com>
References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
 <QM4u0adwYkgwPAp9Rr4v5M_2tC0EaWO9kctj8pXKt-U=.102e4127-2fe4-4be6-aa46-74f6cb040c44@github.com>
Message-ID: <rO7C7Dyhzdh1fAomVfcSvFQ0DiLPoVMobB64YN17FKE=.aa256d50-5264-4060-b43e-4258751aa809@github.com>

On Thu, 8 Jul 2021 03:12:24 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in the whole JDK codebase.
>
> Yi Yang 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:
> 
>   restore JSR166; restore java.desktop

Looks good.  Thanks for separating the other files from this patch.   I also did a test run on tier1-3 that looks clean.

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

Marked as reviewed by mchung (Reviewer).

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

From mseledtsov at openjdk.java.net  Thu Jul  8 19:52:53 2021
From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov)
Date: Thu, 8 Jul 2021 19:52:53 GMT
Subject: [jdk17] RFR: 8269840: Update
 Platform.isDefaultCDSArchiveSupported() to return true for aarch64 platforms
In-Reply-To: <1GSVRAF5kJwh_CHY393jxWIJrLmCEfPudtwus2Wju4U=.e9880721-a8d8-4e85-9f85-6b0206b4ad22@github.com>
References: <1GSVRAF5kJwh_CHY393jxWIJrLmCEfPudtwus2Wju4U=.e9880721-a8d8-4e85-9f85-6b0206b4ad22@github.com>
Message-ID: <vYaIFzFONpFgzPZCxVvDBUkKYnXGLALmVHMjWQd6YB4=.01aa97e6-43d8-41ad-a0ef-3a0b50fcc538@github.com>

On Thu, 8 Jul 2021 01:59:25 GMT, Mikhailo Seledtsov <mseledtsov at openjdk.org> wrote:

> Now that "JDK-8268212 Build linux-aarch64 natively" added support for default CDS archive, time to update test configuration for this platform. This is a very small one-line change.

Thanks Ioi. I have updated the issue description and PR description to "Update Platform.isDefaultCDSArchiveSupported() to return true for aarch64 platforms". I can test on Linux-aarch64 and MacOsx-aarch64. I presume Windows-aarch64 is built natively by the OpenJDK community members (if it is built and tested), then this should be fine.

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

PR: https://git.openjdk.java.net/jdk17/pull/229

From herrick at openjdk.java.net  Thu Jul  8 20:13:15 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Thu, 8 Jul 2021 20:13:15 GMT
Subject: RFR: JDK-8269387: jpackage --add-launcher should have option to not
 create shortcuts for additional launchers
Message-ID: <gO8--JRs2F9hyLuR5gnanY-KYiH-wYSexmUbDGeaP0Q=.e8fa9a64-1018-427f-b1f9-72fc48671b21@github.com>

JDK-8269387: jpackage --add-launcher should have option to not create shortcuts for additional launchers

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

Commit messages:
 - JDK-8269387: jpackage --add-launcher should have option to not create shortcuts for additional launchers
 - JDK-8269387: jpackage --add-launcher should have option to not create shortcuts for additional launchers
 - JDK-8269387: jpackage --add-launcher should have option to not create shortcuts for additional launchers
 - JDK-8269387: jpackage --add-launcher should have option to not create shortcuts for additional launchers

Changes: https://git.openjdk.java.net/jdk/pull/4730/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4730&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8269387
  Stats: 298 lines in 11 files changed: 240 ins; 5 del; 53 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4730.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4730/head:pull/4730

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

From kcr at openjdk.java.net  Thu Jul  8 20:42:52 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 8 Jul 2021 20:42:52 GMT
Subject: RFR: JDK-8269387: jpackage --add-launcher should have option to
 not create shortcuts for additional launchers
In-Reply-To: <gO8--JRs2F9hyLuR5gnanY-KYiH-wYSexmUbDGeaP0Q=.e8fa9a64-1018-427f-b1f9-72fc48671b21@github.com>
References: <gO8--JRs2F9hyLuR5gnanY-KYiH-wYSexmUbDGeaP0Q=.e8fa9a64-1018-427f-b1f9-72fc48671b21@github.com>
Message-ID: <JQ7iHh4WOeyPBPZH3c48Wruv0yhO6PWUFgwJPkKllZY=.310190f9-728c-4f4b-846c-0765a7b8f5b3@github.com>

On Thu, 8 Jul 2021 19:25:33 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> JDK-8269387: jpackage --add-launcher should have option to not create shortcuts for additional launchers

This will need a CSR (so you or someone with a Reviewer role should indicate this with the `/csr` command).

Also, can you summarize the changes in this PR, including the added command line options?

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

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

From asemenyuk at openjdk.java.net  Thu Jul  8 21:12:55 2021
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Thu, 8 Jul 2021 21:12:55 GMT
Subject: RFR: JDK-8269387: jpackage --add-launcher should have option to
 not create shortcuts for additional launchers
In-Reply-To: <gO8--JRs2F9hyLuR5gnanY-KYiH-wYSexmUbDGeaP0Q=.e8fa9a64-1018-427f-b1f9-72fc48671b21@github.com>
References: <gO8--JRs2F9hyLuR5gnanY-KYiH-wYSexmUbDGeaP0Q=.e8fa9a64-1018-427f-b1f9-72fc48671b21@github.com>
Message-ID: <ryJLaT_QvzGLURJHBv8a4rUN5ja3-oI0xsG4QB-xAe4=.52c3a55f-d926-4d92-b39a-c4178b8b05f2@github.com>

On Thu, 8 Jul 2021 19:25:33 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> JDK-8269387: jpackage --add-launcher should have option to not create shortcuts for additional launchers

src/jdk.jpackage/share/classes/jdk/jpackage/internal/AddLauncherArguments.java line 39:

> 37: 
> 38: /*
> 39:  * AddLauncherArguments

Class comment needs to be updated. Currently it says:

 * The add-launcher properties file may have any of:
 *
 * appVersion
 * module
 * main-jar
 * main-class
 * icon
 * arguments
 * java-options
 * win-console
 * linux-app-category

src/jdk.jpackage/share/classes/jdk/jpackage/internal/AddLauncherArguments.java line 125:

> 123:                 (value == null) ? null : Path.of(value));
> 124: 
> 125:         Arguments.putUnlessNull(bundleParams, SHORTCUT_HINT.getID(),

I think it would be better to add platform-specific options only if jpackage runs on that platform:

if (Platform.isWindows())  {
    Arguments.putUnlessNull(bundleParams, SHORTCUT_HINT.getID(), getOptionValue(CLIOptions.WIN_SHORTCUT_HINT));
    Arguments.putUnlessNull(bundleParams, MENU_HINT.getID(), getOptionValue(CLIOptions.WIN_MENU_HINT));
}

if (Platform.isLinux())  {
    Arguments.putUnlessNull(bundleParams, SHORTCUT_HINT.getID(), getOptionValue(CLIOptions.LINUX_SHORTCUT_HINT));
}

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

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

From asemenyuk at openjdk.java.net  Thu Jul  8 21:18:50 2021
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Thu, 8 Jul 2021 21:18:50 GMT
Subject: RFR: JDK-8269387: jpackage --add-launcher should have option to
 not create shortcuts for additional launchers
In-Reply-To: <gO8--JRs2F9hyLuR5gnanY-KYiH-wYSexmUbDGeaP0Q=.e8fa9a64-1018-427f-b1f9-72fc48671b21@github.com>
References: <gO8--JRs2F9hyLuR5gnanY-KYiH-wYSexmUbDGeaP0Q=.e8fa9a64-1018-427f-b1f9-72fc48671b21@github.com>
Message-ID: <jtlb92hfuj0OIduQuRvHVgyl6Y9jPIz469DpmphyGYY=.c65fad0b-c40a-444a-8804-49a4e8e516ea@github.com>

On Thu, 8 Jul 2021 19:25:33 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> JDK-8269387: jpackage --add-launcher should have option to not create shortcuts for additional launchers

src/jdk.jpackage/share/classes/jdk/jpackage/internal/AppImageFile.java line 259:

> 257:         for (var name : names) {
> 258:             launchers.add(new LauncherInfo(name, true, true));
> 259:         }

This block of code can be simplified down to:
`ADD_LAUNCHERS.fetchFrom(params).stream().map(APP_NAME::fetchFrom).map(name -> new LauncherInfo(name, true, true)).forEach(launchers::add);`
 
No need in intermediate `names` list.

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

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

From asemenyuk at openjdk.java.net  Thu Jul  8 21:27:58 2021
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Thu, 8 Jul 2021 21:27:58 GMT
Subject: RFR: JDK-8269387: jpackage --add-launcher should have option to
 not create shortcuts for additional launchers
In-Reply-To: <gO8--JRs2F9hyLuR5gnanY-KYiH-wYSexmUbDGeaP0Q=.e8fa9a64-1018-427f-b1f9-72fc48671b21@github.com>
References: <gO8--JRs2F9hyLuR5gnanY-KYiH-wYSexmUbDGeaP0Q=.e8fa9a64-1018-427f-b1f9-72fc48671b21@github.com>
Message-ID: <ePMllja5HFJKnzZnwdddkPJBdeOleO7Vfg8vUx9309s=.36c97bac-3103-47ef-934f-8f3881da8def@github.com>

On Thu, 8 Jul 2021 19:25:33 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> JDK-8269387: jpackage --add-launcher should have option to not create shortcuts for additional launchers

test/jdk/tools/jpackage/share/AddLShortcutTest.java line 2:

> 1: /*
> 2:  * Copyright (c) 2018, 2020, Oracle and/or its affiliates. All rights reserved.

Copyright year should be 2021

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

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

From asemenyuk at openjdk.java.net  Thu Jul  8 21:34:56 2021
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Thu, 8 Jul 2021 21:34:56 GMT
Subject: RFR: JDK-8269387: jpackage --add-launcher should have option to
 not create shortcuts for additional launchers
In-Reply-To: <gO8--JRs2F9hyLuR5gnanY-KYiH-wYSexmUbDGeaP0Q=.e8fa9a64-1018-427f-b1f9-72fc48671b21@github.com>
References: <gO8--JRs2F9hyLuR5gnanY-KYiH-wYSexmUbDGeaP0Q=.e8fa9a64-1018-427f-b1f9-72fc48671b21@github.com>
Message-ID: <-dZe_dpuoNGejYnHPSZBY4aRI4o1pcETkWOQeOMMPZc=.e9a4112d-effb-49dd-ad3b-e2aed9ee4bc6@github.com>

On Thu, 8 Jul 2021 19:25:33 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> JDK-8269387: jpackage --add-launcher should have option to not create shortcuts for additional launchers

Review

test/jdk/tools/jpackage/share/AddLShortcutTest.java line 46:

> 44:  */
> 45: 
> 46: /*

Why do you need two jtreg @test-s if there is only one test method in the test class? They are 100% duplicates.

test/jdk/tools/jpackage/share/AddLShortcutTest.java line 72:

> 70:  */
> 71: 
> 72: public class AddLShortcutTest {

How does the test tests shortcuts?

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

Changes requested by asemenyuk (Reviewer).

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

From bchristi at openjdk.java.net  Thu Jul  8 21:44:53 2021
From: bchristi at openjdk.java.net (Brent Christian)
Date: Thu, 8 Jul 2021 21:44:53 GMT
Subject: [jdk17] RFR: 8268826: Cleanup Override in Context-Specific
 Deserialization Filters [v7]
In-Reply-To: <jIwjXH_zGYrf6fsjx8Xme8iw4_mgLGUnFYnu2n6kgxI=.99f1c434-c7c6-4eef-849e-e68b2778f74d@github.com>
References: <CJnObVc7b8bI_aw1MiWQ4RQLb5UbhEnAy2yloODfEw0=.95dc7b4a-dba8-48d5-a9e6-cbb1bd8daef9@github.com>
 <jIwjXH_zGYrf6fsjx8Xme8iw4_mgLGUnFYnu2n6kgxI=.99f1c434-c7c6-4eef-849e-e68b2778f74d@github.com>
Message-ID: <wJns4TP8exS3BCf9T9F5iKygmglh3OUsuoRGDuAP8N0=.8ec9395b-7f22-416b-8113-36211c5fc844@github.com>

On Wed, 7 Jul 2021 14:55:18 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Remove the unnecessary special case "OVERRIDE" in jdk.serialFilterFactory property.
>> Fix description in the example of a filter allowing platform classes.
>> Suppress some warnings about use of SecurityManager in tests.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update SerialFactoryExample.PredicateFilter to match the OIF implementation
>   Test cleanup; enable logging of serialization on the command line (remove static)
>   Remove obsolete comment about jdk.serialFilter
>   Fix typo in StaticProperty.java

Marked as reviewed by bchristi (Reviewer).

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

PR: https://git.openjdk.java.net/jdk17/pull/85

From naoto at openjdk.java.net  Thu Jul  8 22:07:15 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 8 Jul 2021 22:07:15 GMT
Subject: RFR: 8260265: UTF-8 by Default
Message-ID: <-F4rYMOBcR8vg_mtYrJ--Ovx9d5bDLTF2p40uV5QqMM=.9cfd49ad-be84-4455-9695-138203395b21@github.com>

This is an implementation for the `JEP 400: UTF-8 by Default`. The gist of the changes is `Charset.defaultCharset()` returning `UTF-8` and `file.encoding` system property being added in the spec, but another notable modification is in `java.io.PrintStream` where it continues to use the `Console` encoding as the default charset instead of `UTF-8`. Other changes are mostly clarification of the term "default charset" and their links. Corresponding CSR has also been drafted.

JEP 400: https://bugs.openjdk.java.net/browse/JDK-8187041
CSR: https://bugs.openjdk.java.net/browse/JDK-8260266

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

Commit messages:
 - 8260265: UTF-8 by Default

Changes: https://git.openjdk.java.net/jdk/pull/4733/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4733&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8260265
  Stats: 297 lines in 18 files changed: 184 ins; 9 del; 104 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4733.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4733/head:pull/4733

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

From jwilhelm at openjdk.java.net  Thu Jul  8 22:15:23 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Thu, 8 Jul 2021 22:15:23 GMT
Subject: RFR: Merge jdk17
Message-ID: <y-DVCB0lU5f7L-IK2D8fbdBpPnPK0TP5GW8X5_MG9l4=.602d06f4-92e2-413e-88c3-3c9cd5af7802@github.com>

Forwardport JDK 17 -> JDK 18

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

Commit messages:
 - Merge
 - 8269722: NPE in HtmlDocletWriter
 - 8270109: ProblemList 4 SA tests on macOS-aarch64
 - 6766844: ByteArrayInputStream#read with a byte array of length 0 not consistent with InputStream when at EOF
 - 8269738: AssertionError when combining pattern matching and function closure
 - 8269828: corrections in some instruction patterns for KNL x86 platform
 - 8268766: Desugaring of pattern matching enum switch should be improved
 - 8270006: Switches with 'case null:' should be exhaustive
 - 8269746: C2: assert(!in->is_CFG()) failed: CFG Node with no controlling input?

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

Changes: https://git.openjdk.java.net/jdk/pull/4734/files
  Stats: 675 lines in 22 files changed: 514 ins; 69 del; 92 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4734.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4734/head:pull/4734

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

From jwilhelm at openjdk.java.net  Thu Jul  8 23:26:58 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Thu, 8 Jul 2021 23:26:58 GMT
Subject: Integrated: Merge jdk17
In-Reply-To: <y-DVCB0lU5f7L-IK2D8fbdBpPnPK0TP5GW8X5_MG9l4=.602d06f4-92e2-413e-88c3-3c9cd5af7802@github.com>
References: <y-DVCB0lU5f7L-IK2D8fbdBpPnPK0TP5GW8X5_MG9l4=.602d06f4-92e2-413e-88c3-3c9cd5af7802@github.com>
Message-ID: <6ALwXMfEvort2mrUB7Rb6uPlC5PrajJvaCgSgjT9fLE=.75f30de8-dbe4-4688-9515-974bfd752bc6@github.com>

On Thu, 8 Jul 2021 22:06:32 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 17 -> JDK 18

This pull request has now been integrated.

Changeset: dfd6b2be
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/dfd6b2be7d2cc312bf550a475be91072259f88af
Stats:     675 lines in 22 files changed: 514 ins; 69 del; 92 mod

Merge

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

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

From jwilhelm at openjdk.java.net  Thu Jul  8 23:26:57 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Thu, 8 Jul 2021 23:26:57 GMT
Subject: RFR: Merge jdk17 [v2]
In-Reply-To: <y-DVCB0lU5f7L-IK2D8fbdBpPnPK0TP5GW8X5_MG9l4=.602d06f4-92e2-413e-88c3-3c9cd5af7802@github.com>
References: <y-DVCB0lU5f7L-IK2D8fbdBpPnPK0TP5GW8X5_MG9l4=.602d06f4-92e2-413e-88c3-3c9cd5af7802@github.com>
Message-ID: <_0-tAFx8fVm6a77TjBchf_Wvh8Ja3pdsOxTtErgRLHM=.5b1936a7-0bf3-47ac-b852-bbfc5b89c975@github.com>

> Forwardport JDK 17 -> JDK 18

Jesper Wilhelmsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 192 commits:

 - Merge
 - 8269827: JMH tests for AES/GCM byte[] and bytebuffers
   
   Reviewed-by: ecaspole, weijun
 - 8268965: TCP Connection Reset when connecting simple socket to SSL server
   
   Reviewed-by: xuelei
 - 8270096: Shenandoah: Optimize gc/shenandoah/TestRefprocSanity.java for interpreter mode
   
   Reviewed-by: zgu
 - 8269962: SA has unused Hashtable, Dictionary classes
   
   Reviewed-by: cjplummer, iklam, dholmes
 - 8270021: Incorrect log decorators in gc/g1/plab/TestPLABEvacuationFailure.java
   
   Reviewed-by: tschatzl, iwalulya
 - 8270064: Problem list tools/jdeprscan/tests/jdk/jdeprscan/TestRelease.java due to JDK-8270060
   
   Reviewed-by: mcimadamore
 - 8267982: Set the node after peephole optimization to be removed
   
   Reviewed-by: kvn, thartmann
 - 8269886: Inaccurate error message for compressed hprof test
   
   Reviewed-by: dholmes, cjplummer
 - 8269803: G1: remove unnecessary NoRefDiscovery
   
   Reviewed-by: tschatzl, kbarrett
 - ... and 182 more: https://git.openjdk.java.net/jdk/compare/64016338...f59792e7

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

Changes: https://git.openjdk.java.net/jdk/pull/4734/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4734&range=01
  Stats: 48561 lines in 880 files changed: 21838 ins; 23621 del; 3102 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4734.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4734/head:pull/4734

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

From mseledtsov at openjdk.java.net  Fri Jul  9 01:58:55 2021
From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov)
Date: Fri, 9 Jul 2021 01:58:55 GMT
Subject: [jdk17] Integrated: 8269840: Update
 Platform.isDefaultCDSArchiveSupported() to return true for aarch64 platforms
In-Reply-To: <1GSVRAF5kJwh_CHY393jxWIJrLmCEfPudtwus2Wju4U=.e9880721-a8d8-4e85-9f85-6b0206b4ad22@github.com>
References: <1GSVRAF5kJwh_CHY393jxWIJrLmCEfPudtwus2Wju4U=.e9880721-a8d8-4e85-9f85-6b0206b4ad22@github.com>
Message-ID: <YVKRRiGaG5KaqhDnQZoJMLU_1x930F3XKfxEi_zG_eQ=.830302d2-a640-4539-ad1c-a9635e2a3d65@github.com>

On Thu, 8 Jul 2021 01:59:25 GMT, Mikhailo Seledtsov <mseledtsov at openjdk.org> wrote:

> Now that "JDK-8268212 Build linux-aarch64 natively" added support for default CDS archive, time to update test configuration for this platform. This is a very small one-line change.

This pull request has now been integrated.

Changeset: 46c610cb
Author:    Mikhailo Seledtsov <mseledtsov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk17/commit/46c610cbd84fc19c3f6591c9a6672768fb90c481
Stats:     1 line in 1 file changed: 0 ins; 1 del; 0 mod

8269840: Update Platform.isDefaultCDSArchiveSupported() to return true for aarch64 platforms

Reviewed-by: minqi, iklam

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

PR: https://git.openjdk.java.net/jdk17/pull/229

From mseledtsov at openjdk.java.net  Fri Jul  9 01:58:55 2021
From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov)
Date: Fri, 9 Jul 2021 01:58:55 GMT
Subject: [jdk17] RFR: 8269840: Update
 Platform.isDefaultCDSArchiveSupported() to return true for aarch64 platforms
In-Reply-To: <1GSVRAF5kJwh_CHY393jxWIJrLmCEfPudtwus2Wju4U=.e9880721-a8d8-4e85-9f85-6b0206b4ad22@github.com>
References: <1GSVRAF5kJwh_CHY393jxWIJrLmCEfPudtwus2Wju4U=.e9880721-a8d8-4e85-9f85-6b0206b4ad22@github.com>
Message-ID: <RwnUzh4RkTu6nlYokfxdEh0kvATBWxr7098D9CGTBGI=.1af1583c-ed78-4f06-aef4-97d1408542c6@github.com>

On Thu, 8 Jul 2021 01:59:25 GMT, Mikhailo Seledtsov <mseledtsov at openjdk.org> wrote:

> Now that "JDK-8268212 Build linux-aarch64 natively" added support for default CDS archive, time to update test configuration for this platform. This is a very small one-line change.

Yumin, Ioi, thanks for the review. 

All relevant tests passed.

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

PR: https://git.openjdk.java.net/jdk17/pull/229

From yyang at openjdk.java.net  Fri Jul  9 02:28:46 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Fri, 9 Jul 2021 02:28:46 GMT
Subject: RFR: 8270056: Generated lambda class can not access protected
 static method of target class [v2]
In-Reply-To: <bDVkalKu_hLAwlGagLIkFol-aLy98PngVw8FrLc0pRM=.0670192d-ae03-4d31-82bb-097e20ae4ffd@github.com>
References: <bDVkalKu_hLAwlGagLIkFol-aLy98PngVw8FrLc0pRM=.0670192d-ae03-4d31-82bb-097e20ae4ffd@github.com>
Message-ID: <_LeMw6o1tDoArS2pXfbYsiqmMRlPEFChmfksP3Z7tj8=.cc9a1db1-2db0-44cd-acc3-4e4e9027b68e@github.com>

> Generated lambda class can not access protected static method of the target class. The following exception is thrown when executing the attached reproducible program:
> 
> 
> Exception in thread "main" java.lang.IllegalAccessError: class AccessProtectedStaticMethodFromSuper$B$$Lambda$15/0x0000000800b8ea48 tried to access protected method 'void AccessProtectedStaticMethodFromSuper$A.func()' (AccessProtectedStaticMethodFromSuper$B$$Lambda$15/0x0000000800b8ea48 is in unnamed module of loader AccessProtectedStaticMethodFromSuper$1Loader @71dac704; AccessProtectedStaticMethodFromSuper$A is in unnamed module of loader AccessProtectedStaticMethodFromSuper$1Loader @39ed3c8d)
> 	at AccessProtectedStaticMethodFromSuper.main(AccessProtectedStaticMethodFromSuper.java:51)
> 
> 
> This issue is similar to JDK-8254975(#767) with slight differences: generated lambda proxy calls static protected method rather than protected member method.
> 
> The proposed fix 1) tries to use MethodHandle instead of invoking forwardee directly(since the lambda class has no access to the resolved method) and 2) does not force accepting an implClass as the first argument when invoking a static method.
> 
> Testing:
> - test/jdk/java/ with release mode
> - presubmit tests

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

  rename SuperMethodTest -> ProtectedMethodInOtherPackage; add test case within it;

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4714/files
  - new: https://git.openjdk.java.net/jdk/pull/4714/files/840e39f3..8aa4e1d7

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

  Stats: 416 lines in 3 files changed: 178 ins; 238 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4714.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4714/head:pull/4714

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

From mgronlun at openjdk.java.net  Fri Jul  9 08:50:28 2021
From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Fri, 9 Jul 2021 08:50:28 GMT
Subject: RFR: 8266936: Add a finalization JFR event
Message-ID: <PpWS13N5Xk6jE-2GGuVjVbd9KgG11x85fFDHww7fMeA=.cbfa8c67-2ead-4db5-ade3-f2bc45565b11@github.com>

Greetings,

Object.finalize() was deprecated in JDK9. There is an ongoing effort to replace and mitigate Object.finalize() uses in the JDK libraries; please see https://bugs.openjdk.java.net/browse/JDK-8253568 for more information. 

We would also like to assist users in replacing and mitigating uses in non-JDK code.

Hence, this changeset adds a periodic JFR event to help identify which classes are overriding Object.finalize().

Thanks
Markus

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

Commit messages:
 - whitespace
 - update
 - update
 - whitespace
 - 8266936-alt: Add a finalization JFR event
 - shortcut calling Jfr::is_recording()
 - 8266936: Add a finalization JFR event

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

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

From aph at openjdk.java.net  Fri Jul  9 09:17:51 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Fri, 9 Jul 2021 09:17:51 GMT
Subject: RFR: 8268231: Aarch64: Use ldp in intrinsics for String.compareTo
In-Reply-To: <XwW4MjGSYmSHa2ZbzrOfvoZi1pe8LJAK7YIKtmNhaDM=.d39df32e-8698-4608-9184-3b19cd175d1a@github.com>
References: <XwW4MjGSYmSHa2ZbzrOfvoZi1pe8LJAK7YIKtmNhaDM=.d39df32e-8698-4608-9184-3b19cd175d1a@github.com>
Message-ID: <HfEFs8bJk69hqKifYHumIr1i4Kuc_XhtxvvRWG793Jk=.3fa019c3-91fc-469b-a99e-d5a393443ce3@github.com>

On Thu, 8 Jul 2021 11:50:36 GMT, Wang Huang <whuang at openjdk.org> wrote:

> Dear all, 
>     Can you do me a favor to review this patch. This patch use `ldp` to implement String.compareTo.
>    
> * We add a JMH test case 
> * Here is the result of this test case
>  
> Benchmark	                       |(size)| Mode| Cnt|Score | Error	 |Units	
> ---------------------------------|------|-----|----|------|--------|-----
> StringCompare.compareLL       |  64  | avgt| 5  |7.992 | ?	0.005|us/op
> StringCompare.compareLL       |  72  | avgt| 5  |15.029| ?	0.006|us/op
> StringCompare.compareLL       |  80  | avgt| 5  |14.655| ?	0.011|us/op
> StringCompare.compareLL       |  91  | avgt| 5  |16.363| ?	0.12 |us/op
> StringCompare.compareLL       |  101 | avgt| 5  |16.966| ?	0.007|us/op
> StringCompare.compareLL       |  121 | avgt| 5  |19.276| ?	0.006|us/op
> StringCompare.compareLL       |  181 | avgt| 5  |19.002| ?	0.417|us/op
> StringCompare.compareLL       |  256 | avgt| 5  |24.707| ?	0.041|us/op
> StringCompare.compareLLWithLdp|  64  | avgt| 5  |8.001	| ?	0.121|us/op
> StringCompare.compareLLWithLdp|  72  | avgt| 5  |11.573| ?	0.003|us/op
> StringCompare.compareLLWithLdp|  80  | avgt| 5  |6.861 | ?	0.004|us/op
> StringCompare.compareLLWithLdp|  91  | avgt| 5  |12.774| ?	0.201|us/op
> StringCompare.compareLLWithLdp|  101 | avgt| 5  |8.691 | ?	0.004|us/op
> StringCompare.compareLLWithLdp|  121 | avgt| 5  |11.091| ?	1.342|us/op
> StringCompare.compareLLWithLdp|  181 | avgt| 5  |14.64 | ?	0.581|us/op
> StringCompare.compareLLWithLdp|  256 | avgt| 5  |25.879| ?	1.775|us/op
> StringCompare.compareUU       |  64  | avgt| 5  |13.476| ?	0.01 |us/op
> StringCompare.compareUU       |  72  | avgt| 5  |15.078| ?	0.006|us/op
> StringCompare.compareUU       |  80  | avgt| 5  |23.512| ?	0.011|us/op
> StringCompare.compareUU       |  91  | avgt| 5  |24.284| ?	0.008|us/op
> StringCompare.compareUU       |  101 | avgt| 5  |20.707| ?	0.017|us/op
> StringCompare.compareUU       |  121 | avgt| 5  |29.302| ?	0.011|us/op
> StringCompare.compareUU       |  181 | avgt| 5  |39.31	| ?	0.016|us/op
> StringCompare.compareUU       |  256 | avgt| 5  |54.592| ?	0.392|us/op
> StringCompare.compareUUWithLdp|  64  | avgt| 5  |16.389| ?	0.008|us/op
> StringCompare.compareUUWithLdp|  72  | avgt| 5  |10.71 | ?	0.158|us/op
> StringCompare.compareUUWithLdp|  80  | avgt| 5  |11.488| ?	0.024|us/op
> StringCompare.compareUUWithLdp|  91  | avgt| 5  |13.412| ?	0.006|us/op
> StringCompare.compareUUWithLdp|  101 | avgt| 5  |16.245| ?	0.434|us/op
> StringCompare.compareUUWithLdp|  121 | avgt| 5  |16.597| ?	0.016|us/op
> StringCompare.compareUUWithLdp|  181 | avgt| 5  |27.373| ?	0.017|us/op
> StringCompare.compareUUWithLdp|  256 | avgt| 5  |41.74 | ?	3.5	 |us/op
> 
> From this table, we can see that in most cases, our patch is better than old one.
> 
> Thank you for your review. Any suggestions are welcome.

I'm quite tempted to approve this. It looks generally better, simpler, and easier to understand than what we have today. However, the improvement isn't great, and I suspect is mostly because of the reduction in traffic between Base and Vector registers.
What happens if you rewrite `compare_string_16_bytes_same()` to use `ldp` ?

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

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

From mbaesken at openjdk.java.net  Fri Jul  9 11:17:32 2021
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Fri, 9 Jul 2021 11:17:32 GMT
Subject: RFR: JDK-8266490: Extend the OSContainer API to support the pids
 controller of cgroups [v3]
In-Reply-To: <MWenVRe4ptn5aua0DUHvxb-sdbu-Ykl9x0GlhmxKHhY=.1fb8901e-36c3-4c07-a6ed-b653120807de@github.com>
References: <MWenVRe4ptn5aua0DUHvxb-sdbu-Ykl9x0GlhmxKHhY=.1fb8901e-36c3-4c07-a6ed-b653120807de@github.com>
Message-ID: <42XR7tr8DLQJfVW41iHaTjARZqBYB_QvLP9cq6CHa8I=.80538a01-23e2-405c-a8af-d308c234fef3@github.com>

> Hello, please review this PR; it extend the OSContainer API in order to also support the pids controller of cgroups.
> 
> I noticed that unlike the other controllers "cpu", "cpuset", "cpuacct", "memory"  on some older Linux distros (SLES 12.1, RHEL 7.1) the pids controller might not be there (or not fully supported) so it was added as optional  , see the coding
> 
> 
>   if (!cg_infos[PIDS_IDX]._data_complete) {
>     log_debug(os, container)("Optional cgroup v1 pids subsystem not found");
>     // keep the other controller info, pids is optional
>   }

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

  test and small adjustments suggested by Severin

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4518/files
  - new: https://git.openjdk.java.net/jdk/pull/4518/files/afd7bf61..f5527143

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

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

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

From mbaesken at openjdk.java.net  Fri Jul  9 11:38:56 2021
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Fri, 9 Jul 2021 11:38:56 GMT
Subject: RFR: JDK-8266490: Extend the OSContainer API to support the pids
 controller of cgroups [v2]
In-Reply-To: <4TD_2jJOnOQ6-D2eCFdJzF3tQg_H-Vm6IrFcyX_xSIw=.028fbe3f-bc04-4b9c-8b35-a6a450a80f7f@github.com>
References: <MWenVRe4ptn5aua0DUHvxb-sdbu-Ykl9x0GlhmxKHhY=.1fb8901e-36c3-4c07-a6ed-b653120807de@github.com>
 <OO_Lxoony0VmDrg-VdikAu0xjQSceEUO-7wlPKIEZjc=.7a15039a-15d3-4b7c-aa7e-f44e3736f68d@github.com>
 <4TD_2jJOnOQ6-D2eCFdJzF3tQg_H-Vm6IrFcyX_xSIw=.028fbe3f-bc04-4b9c-8b35-a6a450a80f7f@github.com>
Message-ID: <PRpXuavlV1Kl2wQcs81cA-ZxJg9feDzoSMHBjDSlfM0=.e5492d2f-c99d-4ec9-8586-1b80b96ea8f5@github.com>

On Tue, 29 Jun 2021 08:21:51 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> This looks pretty good now. Looking forward to seeing container tests for this new code.

Hi Severin , I did some adjustments following your suggestions.
I added docker based test coding for testing pids-limit (with limits and also with unlimited value).
I noticed that on our ppc64le based Linux ,  the message "WARNING: Your kernel does not support pids limit capabilities or the cgroup is not mounted. PIDs limit discarded."   shows up , and the docker "--pids-limit"  limitation does not work because of this. 
So I had to take this into account.

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

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

From github.com+10835776+stsypanov at openjdk.java.net  Fri Jul  9 11:58:03 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Fri, 9 Jul 2021 11:58:03 GMT
Subject: RFR: 8270160: Remove redundant bounds check from
 AbstractStringBuilder.charAt()
Message-ID: <Rs2IOOVA4Rt-72REaifI9rMAtle9N-CLgkGSH7Q7xH0=.bfadc544-a1ad-41dd-9222-b0dec3dbed65@github.com>

`AbstractStringBuilder.charAt(int)` does bounds check before calling `charAt()` (for non-latin Strings):

@Override
public char charAt(int index) {
    checkIndex(index, count);
    if (isLatin1()) {
        return (char)(value[index] & 0xff);
    }
    return StringUTF16.charAt(value, index);
}

This can be improved by removing bounds check from ASB.charAt() in favour of one in String*.charAt(). This gives slight improvement:

before
Benchmark                           Mode  Cnt  Score   Error  Units
StringBuilderCharAtBenchmark.latin  avgt   50  2,768 ? 0,004  ns/op
StringBuilderCharAtBenchmark.utf    avgt   50  2,778 ? 0,014  ns/op

after
Benchmark                           Mode  Cnt  Score   Error  Units
StringBuilderCharAtBenchmark.latin  avgt   50  2,434 ? 0,004  ns/op
StringBuilderCharAtBenchmark.utf    avgt   50  2,631 ? 0,004  ns/op

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

Commit messages:
 - 8270160 Remove redundant bounds check from AbstractStringBuilder.charAt()

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

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

From jai.forums2013 at gmail.com  Fri Jul  9 12:43:44 2021
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Fri, 9 Jul 2021 18:13:44 +0530
Subject: RFR: 8190753: (zipfs): Accessing a large entry (> 2^31 bytes)
 leads to a negative initial size for ByteArrayOutputStream [v3]
In-Reply-To: <d8759650-0932-e04a-857f-a902e3e16f2d@gmail.com>
References: <0GJVLeCPoDI4FePU-Z-NMwJHaS2XyH9S28LgqI1LNB8=.e32743dc-a6dd-475d-88ab-16ed3f46beab@github.com>
 <zbLFjaCUglo5tfRWa1pl1CvwRiorO0jIpbvdwp52I04=.98e2a64e-b9d7-4e02-b1bb-73795e95e501@github.com>
 <gUbGHIfxWL0JgKqLVXyX-hRcbBRPtYCMr2PMZy7_S4E=.4a9eb7d0-db93-4754-98a3-43fba7f0d3e9@github.com>
 <d0d8e38b-2bbe-ae22-add9-644fa2339e3d@oracle.com>
 <d8759650-0932-e04a-857f-a902e3e16f2d@gmail.com>
Message-ID: <ec5c75c3-93fe-9f2a-a31f-ff2e8be477d9@gmail.com>


On 05/07/21 10:52 am, Jaikiran Pai wrote:
>
>>> 4. I've never previously created a manual test case. The 
>>> `LargeCompressedEntrySizeTest` in this PR is expected to be a manual 
>>> test case (given how long it might take to run on various different 
>>> systems). The only difference between this test case and other jtreg 
>>> automated tests is the absence of a `@test` on this one. Is this how 
>>> manual tests are written or is there some other way?
>>>
>> We avoid manual tests as there is no guarantee that they will be run. 
>> So maybe we'll need to explore the scenario a bit further to see if 
>> there is some way to come up with an automated test. The jtreg foo 
>> for manual tests is `@run main/manual LargeCompressedEntrySizeTest`. 
>> You'll see a few examples in the test suite but I don't know if they 
>> are ever run.
>
> I have updated the PR to use jtreg's construct of @run testng/manual 
> to mark this as a manual test. I will post the timing of this test 
> case later today after I run the latest version locally and see how 
> long it's taking.
>
On my local setup, the LargeCompressedEntrySizeTest (latest version of 
this PR) consistently takes between 205 to 215 seconds to complete (so 
between 3 to 4 minutes). Is that something that will allow it to be 
added as part of automated tests or is it too long for automated tests?

-Jaikiran


From sgehwolf at openjdk.java.net  Fri Jul  9 13:44:56 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Fri, 9 Jul 2021 13:44:56 GMT
Subject: RFR: JDK-8266490: Extend the OSContainer API to support the pids
 controller of cgroups [v2]
In-Reply-To: <PRpXuavlV1Kl2wQcs81cA-ZxJg9feDzoSMHBjDSlfM0=.e5492d2f-c99d-4ec9-8586-1b80b96ea8f5@github.com>
References: <MWenVRe4ptn5aua0DUHvxb-sdbu-Ykl9x0GlhmxKHhY=.1fb8901e-36c3-4c07-a6ed-b653120807de@github.com>
 <OO_Lxoony0VmDrg-VdikAu0xjQSceEUO-7wlPKIEZjc=.7a15039a-15d3-4b7c-aa7e-f44e3736f68d@github.com>
 <4TD_2jJOnOQ6-D2eCFdJzF3tQg_H-Vm6IrFcyX_xSIw=.028fbe3f-bc04-4b9c-8b35-a6a450a80f7f@github.com>
 <PRpXuavlV1Kl2wQcs81cA-ZxJg9feDzoSMHBjDSlfM0=.e5492d2f-c99d-4ec9-8586-1b80b96ea8f5@github.com>
Message-ID: <DXWQW5zdXAT9GAqWnWxbN7sYEpLA5i2szlBz4IsNKRM=.0698e1aa-d4ba-49a7-8a20-299302436fa7@github.com>

On Fri, 9 Jul 2021 11:35:34 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> > This looks pretty good now. Looking forward to seeing container tests for this new code.
> 
> Hi Severin , I did some adjustments following your suggestions.
> I added docker based test coding for testing pids-limit (with limits and also with unlimited value).
> I noticed that on our ppc64le based Linux , the message "WARNING: Your kernel does not support pids limit capabilities or the cgroup is not mounted. PIDs limit discarded." shows up , and the docker "--pids-limit" limitation does not work because of this.
> So I had to take this into account.

OK. Please also add a test on the hotspot side. You may want to add relevant parts to `TestMisc.java`.

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

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

From mbaesken at openjdk.java.net  Fri Jul  9 13:56:52 2021
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Fri, 9 Jul 2021 13:56:52 GMT
Subject: RFR: JDK-8266490: Extend the OSContainer API to support the pids
 controller of cgroups [v2]
In-Reply-To: <DXWQW5zdXAT9GAqWnWxbN7sYEpLA5i2szlBz4IsNKRM=.0698e1aa-d4ba-49a7-8a20-299302436fa7@github.com>
References: <MWenVRe4ptn5aua0DUHvxb-sdbu-Ykl9x0GlhmxKHhY=.1fb8901e-36c3-4c07-a6ed-b653120807de@github.com>
 <OO_Lxoony0VmDrg-VdikAu0xjQSceEUO-7wlPKIEZjc=.7a15039a-15d3-4b7c-aa7e-f44e3736f68d@github.com>
 <4TD_2jJOnOQ6-D2eCFdJzF3tQg_H-Vm6IrFcyX_xSIw=.028fbe3f-bc04-4b9c-8b35-a6a450a80f7f@github.com>
 <PRpXuavlV1Kl2wQcs81cA-ZxJg9feDzoSMHBjDSlfM0=.e5492d2f-c99d-4ec9-8586-1b80b96ea8f5@github.com>
 <DXWQW5zdXAT9GAqWnWxbN7sYEpLA5i2szlBz4IsNKRM=.0698e1aa-d4ba-49a7-8a20-299302436fa7@github.com>
Message-ID: <ga__j-XfZjoFwlZi_Q69nCEYziyadbRwe7LId7RRxdA=.9a8f37e2-e77b-4857-ad14-273eded6caf2@github.com>

On Fri, 9 Jul 2021 13:42:15 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> OK. Please also add a test on the hotspot side. You may want to add relevant parts to `TestMisc.java`.

Thanks for the suggestion, I will look into TestMisc.java .

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

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

From darcy at openjdk.java.net  Fri Jul  9 14:03:56 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Fri, 9 Jul 2021 14:03:56 GMT
Subject: RFR: 6506405: Math.abs(float) is slow [v5]
In-Reply-To: <EEMmha55jEwlxnby9QOpfj8VCggPUjF8uw42sLXWvx8=.c1fc135e-176e-4f35-a6e7-a3feae63148e@github.com>
References: <101iFqz6Ghvzu84BSMu6OyB-8sgTyx32uvfc5R-YTjg=.6a958f74-16cb-4388-a793-abad94093aa9@github.com>
 <EEMmha55jEwlxnby9QOpfj8VCggPUjF8uw42sLXWvx8=.c1fc135e-176e-4f35-a6e7-a3feae63148e@github.com>
Message-ID: <eL6wwYd_x6bUWz4i6keOKtOhF6kT54PLzxaSfSoHNTY=.c57428ab-2dba-4949-bd79-fa855a57fba7@github.com>

On Thu, 8 Jul 2021 18:15:23 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Please consider this change to make the `float` and `double` versions of `java.lang.Math.abs()` branch-free.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   6506405: Add some tests

test/jdk/java/lang/Math/AbsTests.java line 35:

> 33:  */
> 34: public class AbsTests {
> 35:     private static final float  EULER_F   = (float)Math.exp(1.0);

Could use Math.E here instead.

test/jdk/java/lang/Math/AbsTests.java line 168:

> 166:     private static float testInRangeFloatAbs() {
> 167:         int errors = 0;
> 168:         float[][] testCases  = {

For the particulars of the test vector for abs, another way to structure this would be a 1-D array of positive numbers where nested test loops used the test value and its negation as the input with the positive number as the expected value.

test/jdk/java/lang/Math/AbsTests.java line 198:

> 196:                            float argument, float expected) {
> 197:         float result = absFunc.apply(argument);
> 198:         if (result != expected) {

I suggest looking at some other math test for the "equivalent" test idiom so that NaNs could be used in the test vector.

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

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

From rriggs at openjdk.java.net  Fri Jul  9 14:37:06 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 9 Jul 2021 14:37:06 GMT
Subject: [jdk17] Integrated: 8268826: Cleanup Override in Context-Specific
 Deserialization Filters
In-Reply-To: <CJnObVc7b8bI_aw1MiWQ4RQLb5UbhEnAy2yloODfEw0=.95dc7b4a-dba8-48d5-a9e6-cbb1bd8daef9@github.com>
References: <CJnObVc7b8bI_aw1MiWQ4RQLb5UbhEnAy2yloODfEw0=.95dc7b4a-dba8-48d5-a9e6-cbb1bd8daef9@github.com>
Message-ID: <q4sS0269wr6zFXpcl7XpO7gLvjASzOj7AH39LXbq6sc=.a1db7ee4-8afc-4b74-89be-12fffe9bcdc5@github.com>

On Wed, 16 Jun 2021 20:22:17 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Remove the unnecessary special case "OVERRIDE" in jdk.serialFilterFactory property.
> Fix description in the example of a filter allowing platform classes.
> Suppress some warnings about use of SecurityManager in tests.

This pull request has now been integrated.

Changeset: 6889a39a
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.java.net/jdk17/commit/6889a39a3f124d2442584cb7646b2d6a18745e78
Stats:     261 lines in 13 files changed: 158 ins; 50 del; 53 mod

8268826: Cleanup Override in Context-Specific Deserialization Filters

Reviewed-by: dfuchs, bchristi

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

PR: https://git.openjdk.java.net/jdk17/pull/85

From mcimadamore at openjdk.java.net  Fri Jul  9 15:07:23 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 9 Jul 2021 15:07:23 GMT
Subject: [jdk17] RFR: 8269281: java/foreign/Test{Down,Up}call.java time out
Message-ID: <vghOiqn9I9ouV5b6Ux7wfBnsTNOABHmbUc45oSPnJJ4=.91ff7181-04e8-470d-a57e-e4f47d1f18e1@github.com>

After some more investigation, I have been able to at least partially reproduce on my Linux box. While I can't get to same slowdown as we're seeing in test machines, I did notice that in fastdebug mode, TestUpcall is a lot slower than in release mode.

The underlying issue is that these tests are generating a lot of "throwaway" method handles. Method handles are typically stored in fields - when that happens, creating a method handle with same shape as one that has already been created typically works ok, w/o overhead, because there's a cache in the MethodType class which stores already generated lambda forms (by method handle kind). This cache is a SofteReference cahce, so, if the system is under memory pressure, the GC is of course free to null out all these cached values, in which case a new lambda form will be generated, and a new class will be loaded.

When looking at both TestDowncall and TestUpcall, in their current form, it is possible to observe a fairly large amount of classes being loaded and unloaded. Since the test generates many garbage, the GC is under pressure, and that causes entries in the lambda form cache to be evicted. The fact that one of the tests also explicitly calls out to `System::gc` doesn't help, and probably adds to the churn.

Since it is very hard, if not impossible, to fix the test so that all the required method handle are retained for the entire duration of the test (since we create different variations of same handles, based on the test being run), I believe the best solution would be to reduce the number of test combinations being executed.

This patch adds the ability to specify a sampling factor - which reduces the size of the test combinations being executed. Note that we also have a fuller test (which is never run automatically, but can be ran by hand: `TestMatrix`) - this test does not specify any sampling factor, so when developers run this stress test manually they will still run the whole shebang (which is what you want if you are tweaking the logic in the foreign support).

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

Commit messages:
 - * Remove calls to System.gc()

Changes: https://git.openjdk.java.net/jdk17/pull/238/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=238&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8269281
  Stats: 17 lines in 3 files changed: 6 ins; 7 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/238.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/238/head:pull/238

PR: https://git.openjdk.java.net/jdk17/pull/238

From lance.andersen at oracle.com  Fri Jul  9 16:11:48 2021
From: lance.andersen at oracle.com (Lance Andersen)
Date: Fri, 9 Jul 2021 16:11:48 +0000
Subject: RFR: 8190753: (zipfs): Accessing a large entry (> 2^31 bytes)
 leads to a negative initial size for ByteArrayOutputStream [v3]
In-Reply-To: <ec5c75c3-93fe-9f2a-a31f-ff2e8be477d9@gmail.com>
References: <0GJVLeCPoDI4FePU-Z-NMwJHaS2XyH9S28LgqI1LNB8=.e32743dc-a6dd-475d-88ab-16ed3f46beab@github.com>
 <zbLFjaCUglo5tfRWa1pl1CvwRiorO0jIpbvdwp52I04=.98e2a64e-b9d7-4e02-b1bb-73795e95e501@github.com>
 <gUbGHIfxWL0JgKqLVXyX-hRcbBRPtYCMr2PMZy7_S4E=.4a9eb7d0-db93-4754-98a3-43fba7f0d3e9@github.com>
 <d0d8e38b-2bbe-ae22-add9-644fa2339e3d@oracle.com>
 <d8759650-0932-e04a-857f-a902e3e16f2d@gmail.com>
 <ec5c75c3-93fe-9f2a-a31f-ff2e8be477d9@gmail.com>
Message-ID: <0FDCCD5F-4D35-46E8-B5E1-DEE83CC663A8@oracle.com>

Hi Jaikiran,

On Jul 9, 2021, at 8:43 AM, Jaikiran Pai <jai.forums2013 at gmail.com<mailto:jai.forums2013 at gmail.com>> wrote:


On 05/07/21 10:52 am, Jaikiran Pai wrote:

4. I've never previously created a manual test case. The `LargeCompressedEntrySizeTest` in this PR is expected to be a manual test case (given how long it might take to run on various different systems). The only difference between this test case and other jtreg automated tests is the absence of a `@test` on this one. Is this how manual tests are written or is there some other way?

We avoid manual tests as there is no guarantee that they will be run. So maybe we'll need to explore the scenario a bit further to see if there is some way to come up with an automated test. The jtreg foo for manual tests is `@run main/manual LargeCompressedEntrySizeTest`. You'll see a few examples in the test suite but I don't know if they are ever run.

I have updated the PR to use jtreg's construct of @run testng/manual to mark this as a manual test. I will post the timing of this test case later today after I run the latest version locally and see how long it's taking.

On my local setup, the LargeCompressedEntrySizeTest (latest version of this PR) consistently takes between 205 to 215 seconds to complete (so between 3 to 4 minutes). Is that something that will allow it to be added as part of automated tests or is it too long for automated tests?

Thank you for the info.  This test needs to remain a manual test.

I have a full test run going and will finish my review later today or tomorrow

Best
Lance

-Jaikiran

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



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




From bpb at openjdk.java.net  Fri Jul  9 17:27:18 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Fri, 9 Jul 2021 17:27:18 GMT
Subject: RFR: 6506405: Math.abs(float) is slow [v6]
In-Reply-To: <101iFqz6Ghvzu84BSMu6OyB-8sgTyx32uvfc5R-YTjg=.6a958f74-16cb-4388-a793-abad94093aa9@github.com>
References: <101iFqz6Ghvzu84BSMu6OyB-8sgTyx32uvfc5R-YTjg=.6a958f74-16cb-4388-a793-abad94093aa9@github.com>
Message-ID: <8udhrVxSH84i8EixXNy3fAtUeymvx0EyWHFlrYtMKtk=.f6d9a214-a075-4427-8c1d-dc811fb83e2a@github.com>

> Please consider this change to make the `float` and `double` versions of `java.lang.Math.abs()` branch-free.

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

  6506405: Clean up test

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4711/files
  - new: https://git.openjdk.java.net/jdk/pull/4711/files/5ac31ec4..50236937

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

  Stats: 94 lines in 1 file changed: 21 ins; 40 del; 33 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4711.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4711/head:pull/4711

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

From bpb at openjdk.java.net  Fri Jul  9 17:27:20 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Fri, 9 Jul 2021 17:27:20 GMT
Subject: RFR: 6506405: Math.abs(float) is slow [v5]
In-Reply-To: <eL6wwYd_x6bUWz4i6keOKtOhF6kT54PLzxaSfSoHNTY=.c57428ab-2dba-4949-bd79-fa855a57fba7@github.com>
References: <101iFqz6Ghvzu84BSMu6OyB-8sgTyx32uvfc5R-YTjg=.6a958f74-16cb-4388-a793-abad94093aa9@github.com>
 <EEMmha55jEwlxnby9QOpfj8VCggPUjF8uw42sLXWvx8=.c1fc135e-176e-4f35-a6e7-a3feae63148e@github.com>
 <eL6wwYd_x6bUWz4i6keOKtOhF6kT54PLzxaSfSoHNTY=.c57428ab-2dba-4949-bd79-fa855a57fba7@github.com>
Message-ID: <Q9jPqyGT_lK7SH31GbSm0mtlwx1Mkq_x4jqYqlXIAOQ=.e1dc3bf5-4842-4a8d-a8cc-11602c9db537@github.com>

On Fri, 9 Jul 2021 13:54:39 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   6506405: Add some tests
>
> test/jdk/java/lang/Math/AbsTests.java line 35:
> 
>> 33:  */
>> 34: public class AbsTests {
>> 35:     private static final float  EULER_F   = (float)Math.exp(1.0);
> 
> Could use Math.E here instead.

Yeah that was lame.

> test/jdk/java/lang/Math/AbsTests.java line 168:
> 
>> 166:     private static float testInRangeFloatAbs() {
>> 167:         int errors = 0;
>> 168:         float[][] testCases  = {
> 
> For the particulars of the test vector for abs, another way to structure this would be a 1-D array of positive numbers where nested test loops used the test value and its negation as the input with the positive number as the expected value.

Changed to 1-D array but can be either positive or negative.

> test/jdk/java/lang/Math/AbsTests.java line 198:
> 
>> 196:                            float argument, float expected) {
>> 197:         float result = absFunc.apply(argument);
>> 198:         if (result != expected) {
> 
> I suggest looking at some other math test for the "equivalent" test idiom so that NaNs could be used in the test vector.

Added `NaN` check in latest update but might be suspect.

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

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

From mchung at openjdk.java.net  Fri Jul  9 17:30:52 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Fri, 9 Jul 2021 17:30:52 GMT
Subject: RFR: 8270056: Generated lambda class can not access protected
 static method of target class [v2]
In-Reply-To: <_LeMw6o1tDoArS2pXfbYsiqmMRlPEFChmfksP3Z7tj8=.cc9a1db1-2db0-44cd-acc3-4e4e9027b68e@github.com>
References: <bDVkalKu_hLAwlGagLIkFol-aLy98PngVw8FrLc0pRM=.0670192d-ae03-4d31-82bb-097e20ae4ffd@github.com>
 <_LeMw6o1tDoArS2pXfbYsiqmMRlPEFChmfksP3Z7tj8=.cc9a1db1-2db0-44cd-acc3-4e4e9027b68e@github.com>
Message-ID: <HBPK6vYUCTeHF6ig-uqsjJ9aA8VODhNDnI_yLU3bwzg=.50d3930a-f72b-4279-839d-016051cff343@github.com>

On Fri, 9 Jul 2021 02:28:46 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> Generated lambda class can not access protected static method of the target class. The following exception is thrown when executing the attached reproducible program:
>> 
>> 
>> Exception in thread "main" java.lang.IllegalAccessError: class AccessProtectedStaticMethodFromSuper$B$$Lambda$15/0x0000000800b8ea48 tried to access protected method 'void AccessProtectedStaticMethodFromSuper$A.func()' (AccessProtectedStaticMethodFromSuper$B$$Lambda$15/0x0000000800b8ea48 is in unnamed module of loader AccessProtectedStaticMethodFromSuper$1Loader @71dac704; AccessProtectedStaticMethodFromSuper$A is in unnamed module of loader AccessProtectedStaticMethodFromSuper$1Loader @39ed3c8d)
>> 	at AccessProtectedStaticMethodFromSuper.main(AccessProtectedStaticMethodFromSuper.java:51)
>> 
>> 
>> This issue is similar to JDK-8254975(#767) with slight differences: generated lambda proxy calls static protected method rather than protected member method.
>> 
>> The proposed fix 1) tries to use MethodHandle instead of invoking forwardee directly(since the lambda class has no access to the resolved method) and 2) does not force accepting an implClass as the first argument when invoking a static method.
>> 
>> Testing:
>> - test/jdk/java/ with release mode
>> - presubmit tests
>
> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rename SuperMethodTest -> ProtectedMethodInOtherPackage; add test case within it;

The class name needs to be renamed as well.  Also the classname in the `@run` command.

test/jdk/java/lang/invoke/lambda/superProtectedMethod/ProtectedMethodInOtherPackage.java line 105:

> 103: 
> 104:     @Test
> 105:     public static void splitPackage1() throws Throwable {

perhaps the method name can be `protectedStaticMethodInSplitPackage`

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

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

From herrick at openjdk.java.net  Fri Jul  9 17:59:35 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Fri, 9 Jul 2021 17:59:35 GMT
Subject: RFR: JDK-8269387: jpackage --add-launcher should have option to
 not create shortcuts for additional launchers [v2]
In-Reply-To: <gO8--JRs2F9hyLuR5gnanY-KYiH-wYSexmUbDGeaP0Q=.e8fa9a64-1018-427f-b1f9-72fc48671b21@github.com>
References: <gO8--JRs2F9hyLuR5gnanY-KYiH-wYSexmUbDGeaP0Q=.e8fa9a64-1018-427f-b1f9-72fc48671b21@github.com>
Message-ID: <yzB_YzhJ2Z6t-KXEHdfiHgT4AvOSNkePwrduogMcYu0=.c1686354-354c-4db8-a69d-4658a20d73dc@github.com>

> JDK-8269387: jpackage --add-launcher should have option to not create shortcuts for additional launchers

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

  JDK-8269387: jpackage --add-launcher should have option to not create shortcuts for additional launchers

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4730/files
  - new: https://git.openjdk.java.net/jdk/pull/4730/files/8b6402c6..3fe30059

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

  Stats: 62 lines in 7 files changed: 12 ins; 30 del; 20 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4730.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4730/head:pull/4730

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

From bchristi at openjdk.java.net  Fri Jul  9 18:24:48 2021
From: bchristi at openjdk.java.net (Brent Christian)
Date: Fri, 9 Jul 2021 18:24:48 GMT
Subject: RFR: 8266936: Add a finalization JFR event
In-Reply-To: <PpWS13N5Xk6jE-2GGuVjVbd9KgG11x85fFDHww7fMeA=.cbfa8c67-2ead-4db5-ade3-f2bc45565b11@github.com>
References: <PpWS13N5Xk6jE-2GGuVjVbd9KgG11x85fFDHww7fMeA=.cbfa8c67-2ead-4db5-ade3-f2bc45565b11@github.com>
Message-ID: <ANS_l90VsfrHHQtSsKSncu3vBnT1SsTqzrRWxhwgVU0=.6612244d-ca1f-4613-bdc1-84fb2928c993@github.com>

On Thu, 8 Jul 2021 19:47:26 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> Greetings,
> 
> Object.finalize() was deprecated in JDK9. There is an ongoing effort to replace and mitigate Object.finalize() uses in the JDK libraries; please see https://bugs.openjdk.java.net/browse/JDK-8253568 for more information. 
> 
> We would also like to assist users in replacing and mitigating uses in non-JDK code.
> 
> Hence, this changeset adds a periodic JFR event to help identify which classes are overriding Object.finalize().
> 
> Thanks
> Markus

src/hotspot/share/jfr/metadata/metadata.xml line 1084:

> 1082:   </Event>
> 1083: 
> 1084:   <Event name="Finalizer" category="Java Application" label="Finalizer" thread="false" startTime="false" period="endChunk">

Would it make sense for this event to be under the "Java Virtual Machine, GC" category?

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

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

From bpb at openjdk.java.net  Fri Jul  9 21:30:22 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Fri, 9 Jul 2021 21:30:22 GMT
Subject: RFR: 6506405: Math.abs(float) is slow [v7]
In-Reply-To: <101iFqz6Ghvzu84BSMu6OyB-8sgTyx32uvfc5R-YTjg=.6a958f74-16cb-4388-a793-abad94093aa9@github.com>
References: <101iFqz6Ghvzu84BSMu6OyB-8sgTyx32uvfc5R-YTjg=.6a958f74-16cb-4388-a793-abad94093aa9@github.com>
Message-ID: <97rRnbGmalBAWvZcZCenc7KoJ2MQc02d_PeVENUCag8=.230afbd8-737c-435a-8cb1-40a91ddc6f84@github.com>

> Please consider this change to make the `float` and `double` versions of `java.lang.Math.abs()` branch-free.

Brian Burkhalter 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:

  6506405: Clean up test

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4711/files
  - new: https://git.openjdk.java.net/jdk/pull/4711/files/50236937..b66e628e

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

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

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

From darcy at openjdk.java.net  Fri Jul  9 22:12:53 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Fri, 9 Jul 2021 22:12:53 GMT
Subject: RFR: 6506405: Math.abs(float) is slow [v7]
In-Reply-To: <97rRnbGmalBAWvZcZCenc7KoJ2MQc02d_PeVENUCag8=.230afbd8-737c-435a-8cb1-40a91ddc6f84@github.com>
References: <101iFqz6Ghvzu84BSMu6OyB-8sgTyx32uvfc5R-YTjg=.6a958f74-16cb-4388-a793-abad94093aa9@github.com>
 <97rRnbGmalBAWvZcZCenc7KoJ2MQc02d_PeVENUCag8=.230afbd8-737c-435a-8cb1-40a91ddc6f84@github.com>
Message-ID: <_M2SabZDsrjiiQ8ygsFF0TzB6NGvGA5ue27dRhc67MI=.ffa5e0e7-524b-4937-a56d-e3f9e89d37b1@github.com>

On Fri, 9 Jul 2021 21:30:22 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Please consider this change to make the `float` and `double` versions of `java.lang.Math.abs()` branch-free.
>
> Brian Burkhalter 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/math/DoubleConsts.java line 89:

> 87:                 ((SIGN_BIT_MASK & SIGNIF_BIT_MASK) == 0L) &&
> 88:                 ((EXP_BIT_MASK & SIGNIF_BIT_MASK) == 0L)) &&
> 89:                 ((SIGN_BIT_MASK | MAG_BIT_MASK) == ~0));

Nit: please use "~0L" instead so the long-ness of 0 is explicit.

test/jdk/java/lang/Math/AbsTests.java line 202:

> 200:             return Float.floatToRawIntBits(result) !=
> 201:                 Float.floatToRawIntBits(f) ? 1 : 0;
> 202:         } else if ((f >= 0 && result != f) || (f < 0 && result != -f)) {

Please look at the Tests.java file in the jdk/test/java/lang/Math directory. One of the methods like

    public static int test(String testName, double input,
                           double result, double expected

will be helpful here; e.g.

Tests.test("Math.abs", f, Math.abs(-f), f)

I would also add combination for StrictMath.abs and negations:

Tests.test("Math.abs", f, Math.abs(f), f)
Tests.test("StrictMath.abs", -f, Math.abs(f), f)
Tests.test("StrictMath.abs", f, Math.abs(f), f)

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

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

From bpb at openjdk.java.net  Fri Jul  9 22:52:19 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Fri, 9 Jul 2021 22:52:19 GMT
Subject: RFR: 6506405: Math.abs(float) is slow [v8]
In-Reply-To: <101iFqz6Ghvzu84BSMu6OyB-8sgTyx32uvfc5R-YTjg=.6a958f74-16cb-4388-a793-abad94093aa9@github.com>
References: <101iFqz6Ghvzu84BSMu6OyB-8sgTyx32uvfc5R-YTjg=.6a958f74-16cb-4388-a793-abad94093aa9@github.com>
Message-ID: <S34rnhTGtjFtEXgFFJ-1GKkizvXrYo6h_NWTBDp8PDc=.16a2988a-2ffd-4069-b497-8ce8ae59ffe5@github.com>

> Please consider this change to make the `float` and `double` versions of `java.lang.Math.abs()` branch-free.

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

  6506405: More test cleanup

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4711/files
  - new: https://git.openjdk.java.net/jdk/pull/4711/files/b66e628e..f23fa829

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

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

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

From bpb at openjdk.java.net  Fri Jul  9 22:52:20 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Fri, 9 Jul 2021 22:52:20 GMT
Subject: RFR: 6506405: Math.abs(float) is slow [v7]
In-Reply-To: <_M2SabZDsrjiiQ8ygsFF0TzB6NGvGA5ue27dRhc67MI=.ffa5e0e7-524b-4937-a56d-e3f9e89d37b1@github.com>
References: <101iFqz6Ghvzu84BSMu6OyB-8sgTyx32uvfc5R-YTjg=.6a958f74-16cb-4388-a793-abad94093aa9@github.com>
 <97rRnbGmalBAWvZcZCenc7KoJ2MQc02d_PeVENUCag8=.230afbd8-737c-435a-8cb1-40a91ddc6f84@github.com>
 <_M2SabZDsrjiiQ8ygsFF0TzB6NGvGA5ue27dRhc67MI=.ffa5e0e7-524b-4937-a56d-e3f9e89d37b1@github.com>
Message-ID: <xx-zP9cpSLXhoEBgugJ7t05GAA50pbySZ65wVidH59w=.fdd03ead-3075-438c-99a9-6e730950892a@github.com>

On Fri, 9 Jul 2021 22:02:14 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Brian Burkhalter 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/math/DoubleConsts.java line 89:
> 
>> 87:                 ((SIGN_BIT_MASK & SIGNIF_BIT_MASK) == 0L) &&
>> 88:                 ((EXP_BIT_MASK & SIGNIF_BIT_MASK) == 0L)) &&
>> 89:                 ((SIGN_BIT_MASK | MAG_BIT_MASK) == ~0));
> 
> Nit: please use "~0L" instead so the long-ness of 0 is explicit.

Fixed.

> test/jdk/java/lang/Math/AbsTests.java line 202:
> 
>> 200:             return Float.floatToRawIntBits(result) !=
>> 201:                 Float.floatToRawIntBits(f) ? 1 : 0;
>> 202:         } else if ((f >= 0 && result != f) || (f < 0 && result != -f)) {
> 
> Please look at the Tests.java file in the jdk/test/java/lang/Math directory. One of the methods like
> 
>     public static int test(String testName, double input,
>                            double result, double expected
> 
> will be helpful here; e.g.
> 
> Tests.test("Math.abs", f, Math.abs(-f), f)
> 
> I would also add combination for StrictMath.abs and negations:
> 
> Tests.test("Math.abs", f, Math.abs(f), f)
> Tests.test("StrictMath.abs", -f, Math.abs(f), f)
> Tests.test("StrictMath.abs", f, Math.abs(f), f)

Modified.

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

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

From jwilhelm at openjdk.java.net  Sat Jul 10 00:26:17 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Sat, 10 Jul 2021 00:26:17 GMT
Subject: RFR: Merge jdk17
Message-ID: <SP49dQpNPpQ1QCEm4fxMpkoQo5Gb89HqN0ShAoYgGNI=.69904abb-e40b-465e-84b6-69be2b4dae3c@github.com>

Forwardport JDK 17 -> JDK 18

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

Commit messages:
 - Merge
 - 8268826: Cleanup Override in Context-Specific Deserialization Filters
 - 8261147: C2: Node is wrongly marked as reduction resulting in a wrong execution due to wrong vector instructions
 - 8270151: IncompatibleClassChangeError on empty pattern switch statement case
 - 8269146: Missing unreported constraints on pattern and other case label combination
 - 8269952: compiler/vectorapi/VectorCastShape*Test.java tests failed on avx2 machines
 - 8269840: Update Platform.isDefaultCDSArchiveSupported() to return true for aarch64 platforms

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

Changes: https://git.openjdk.java.net/jdk/pull/4748/files
  Stats: 691 lines in 29 files changed: 544 ins; 66 del; 81 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4748.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4748/head:pull/4748

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

From jwilhelm at openjdk.java.net  Sat Jul 10 01:26:52 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Sat, 10 Jul 2021 01:26:52 GMT
Subject: Integrated: Merge jdk17
In-Reply-To: <SP49dQpNPpQ1QCEm4fxMpkoQo5Gb89HqN0ShAoYgGNI=.69904abb-e40b-465e-84b6-69be2b4dae3c@github.com>
References: <SP49dQpNPpQ1QCEm4fxMpkoQo5Gb89HqN0ShAoYgGNI=.69904abb-e40b-465e-84b6-69be2b4dae3c@github.com>
Message-ID: <uwSUP02G4aGoL3n5ohqqf9C7CLQkNDZhY5KCYAuH4jE=.04a63845-c9e5-4f15-85b2-7ebbbd856a41@github.com>

On Sat, 10 Jul 2021 00:17:07 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 17 -> JDK 18

This pull request has now been integrated.

Changeset: ec975c6a
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ec975c6a055688c014e709917dcfc340037e684f
Stats:     691 lines in 29 files changed: 544 ins; 66 del; 81 mod

Merge

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

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

From asemenyuk at openjdk.java.net  Sat Jul 10 03:25:55 2021
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Sat, 10 Jul 2021 03:25:55 GMT
Subject: RFR: JDK-8269387: jpackage --add-launcher should have option to
 not create shortcuts for additional launchers [v2]
In-Reply-To: <yzB_YzhJ2Z6t-KXEHdfiHgT4AvOSNkePwrduogMcYu0=.c1686354-354c-4db8-a69d-4658a20d73dc@github.com>
References: <gO8--JRs2F9hyLuR5gnanY-KYiH-wYSexmUbDGeaP0Q=.e8fa9a64-1018-427f-b1f9-72fc48671b21@github.com>
 <yzB_YzhJ2Z6t-KXEHdfiHgT4AvOSNkePwrduogMcYu0=.c1686354-354c-4db8-a69d-4658a20d73dc@github.com>
Message-ID: <6oSfEiztHLEPX_YEpYr7_RcxSe9iGA2j4YT8l7GAyEY=.ee98b0cb-43ad-4c7c-9ae7-f9633e1b9be3@github.com>

On Fri, 9 Jul 2021 17:59:35 GMT, Andy Herrick <herrick at openjdk.org> wrote:

>> JDK-8269387: jpackage --add-launcher should have option to not create shortcuts for additional launchers
>
> Andy Herrick has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8269387: jpackage --add-launcher should have option to not create shortcuts for additional launchers

Changes requested by asemenyuk (Reviewer).

test/jdk/tools/jpackage/helpers/jdk/jpackage/test/AdditionalLauncher.java line 84:

> 82:     }
> 83: 
> 84:     public AdditionalLauncher setShortcuts(boolean menu, boolean desktop) {

I'd expect verifyShortcuts() method added to this class and called from verify() similar to how verifyIcon() is called. This would make AddLShortcutTest.java do some automatic testing of shortcuts.

Something like this:

    private void verify(JPackageCommand cmd) throws IOException {
        verifyIcon(cmd);
        verifyShortcuts(cmd);
        ...
    }

   public AdditionalLauncher setShortcuts(boolean menu, boolean desktop) {
        withMenuShortcut = menu;
        withDesktopShortcut = desktop;
        return this;
    }
    
    private void verifyShortcuts(JPackageCommand cmd) throws IOException {
        if (TKit.isLinux() && !cmd.isImagePackageType() && withMenuShortcut != null) {
            Path desktopFile = LinuxHelper.getDesktopFile(cmd, name);
            if (withMenuShortcut) {
                TKit.assertFileExists(desktopFile);
            } else {
                TKit.assertPathExists(desktopFile, false);
            }
        }
    }

    private Boolean withMenuShortcut;
    private Boolean withDesktopShortcut;

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

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

From mgronlun at openjdk.java.net  Sat Jul 10 10:14:49 2021
From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sat, 10 Jul 2021 10:14:49 GMT
Subject: RFR: 8266936: Add a finalization JFR event
In-Reply-To: <ANS_l90VsfrHHQtSsKSncu3vBnT1SsTqzrRWxhwgVU0=.6612244d-ca1f-4613-bdc1-84fb2928c993@github.com>
References: <PpWS13N5Xk6jE-2GGuVjVbd9KgG11x85fFDHww7fMeA=.cbfa8c67-2ead-4db5-ade3-f2bc45565b11@github.com>
 <ANS_l90VsfrHHQtSsKSncu3vBnT1SsTqzrRWxhwgVU0=.6612244d-ca1f-4613-bdc1-84fb2928c993@github.com>
Message-ID: <lXRZCxtJxbTnrRhyIVfS7mSse7cvC4orEQ-0MvypVsg=.b5e0cd52-fb35-403d-8ac9-6886e48049cf@github.com>

On Fri, 9 Jul 2021 18:21:25 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Greetings,
>> 
>> Object.finalize() was deprecated in JDK9. There is an ongoing effort to replace and mitigate Object.finalize() uses in the JDK libraries; please see https://bugs.openjdk.java.net/browse/JDK-8253568 for more information. 
>> 
>> We would also like to assist users in replacing and mitigating uses in non-JDK code.
>> 
>> Hence, this changeset adds a periodic JFR event to help identify which classes are overriding Object.finalize().
>> 
>> Thanks
>> Markus
>
> src/hotspot/share/jfr/metadata/metadata.xml line 1084:
> 
>> 1082:   </Event>
>> 1083: 
>> 1084:   <Event name="Finalizer" category="Java Application" label="Finalizer" thread="false" startTime="false" period="endChunk">
> 
> Would it make sense for this event to be under the "Java Virtual Machine, GC" category?

My argument for placing the event in the Java Application category:

The finalization concept is, or maybe more correctly has been, reified in the Java language. The Java programmer decides to enlist the exposed functionality, similar to Java language Exceptions and Errors. JFR already represents events for these latter concepts in the Java Application category because programmers directly interact with and, in contrast to many events in the JVM category, have more control over them.

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

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

From vromero at openjdk.java.net  Sat Jul 10 19:13:18 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Sat, 10 Jul 2021 19:13:18 GMT
Subject: [jdk17] RFR: 8270025: DynamicCallSiteDesc::withArgs doesn't throw NPE
Message-ID: <j7TtUsU8eNi_NXDTP7ID2tCH5pc_XsGkHcZW522eqyg=.561a4dc2-60ef-41e0-af82-1cdfc4ff21f3@github.com>

Please review this PR that is fixing a mismatch between the implementation for method `java.lang.constant.DynamicCallSiteDesc::withArgs` and its implementation. I made a mistake while working on a recent CSR [JDK-8224985](https://bugs.openjdk.java.net/browse/JDK-8224985) and fixed the API but mistakenly thought that the implementation was in sync with the spec. This is why this change is also including a unit test of the API for `java.lang.constant.DynamicCallSiteDesc` module for method `resolveCallSiteDesc` which is covered in test `IndyDescTest` in the same test suite. Also this change needs a CSR while fixing the implementation of method `::withArgs` I realized that the API of the varargs overloaded version of method `::of` needed some rewording too as it is invoking the same private constructor `::withArgs` is invoking. So it didn't make sense for the API of one method to be more restrictive than the other. Please review also the accompanying CSR.

Thanks,
Vicente

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

Commit messages:
 - 8270025: DynamicCallSiteDesc.withArgs doesn't throw NPE

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

PR: https://git.openjdk.java.net/jdk17/pull/242

From lancea at openjdk.java.net  Sun Jul 11 20:38:55 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Sun, 11 Jul 2021 20:38:55 GMT
Subject: RFR: 8190753: (zipfs): Accessing a large entry (> 2^31 bytes)
 leads to a negative initial size for ByteArrayOutputStream [v8]
In-Reply-To: <ehuksZQILsWLXcuvxgtRGIq7Lqwl146QQpIVHanMoIs=.9cad7f15-24b8-4bf6-99db-cbf3ef3cccbf@github.com>
References: <0GJVLeCPoDI4FePU-Z-NMwJHaS2XyH9S28LgqI1LNB8=.e32743dc-a6dd-475d-88ab-16ed3f46beab@github.com>
 <ehuksZQILsWLXcuvxgtRGIq7Lqwl146QQpIVHanMoIs=.9cad7f15-24b8-4bf6-99db-cbf3ef3cccbf@github.com>
Message-ID: <vhRP_xqkq0g3topmOPn1JdTpaXtEDTKuI72fdNd6hSw=.86d4f9c6-197a-48de-94a5-0cbe54ad41ff@github.com>

On Mon, 5 Jul 2021 07:42:26 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this proposed fix for the issue reported in https://bugs.openjdk.java.net/browse/JDK-8190753?
>> 
>> The commit here checks for the size of the zip entry before trying to create a `ByteArrayOutputStream` for that entry's content. A new jtreg test has been included in this commit to reproduce the issue and verify the fix.
>> 
>> P.S: It's still a bit arguable whether it's a good idea to create the `ByteArrayOutputStream` with an initial size potentially as large as the `MAX_ARRAY_SIZE` or whether it's better to just use some smaller default value. However, I think that can be addressed separately while dealing with https://bugs.openjdk.java.net/browse/JDK-8011146
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reorganize the tests now that the temp file creation threshold isn't exposed as a user configurable value

I think the updates made to Zip FS look better.   Alan is on vacation so I would prefer to wait until he gets back and give him a chance to provide any last thoughts on the change to Zip FS.

The manual test looks OK and is a good addition

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

Marked as reviewed by lancea (Reviewer).

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

From jai.forums2013 at gmail.com  Mon Jul 12 01:19:47 2021
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Mon, 12 Jul 2021 06:49:47 +0530
Subject: RFR: 8190753: (zipfs): Accessing a large entry (> 2^31 bytes)
 leads to a negative initial size for ByteArrayOutputStream [v8]
In-Reply-To: <vhRP_xqkq0g3topmOPn1JdTpaXtEDTKuI72fdNd6hSw=.86d4f9c6-197a-48de-94a5-0cbe54ad41ff@github.com>
References: <0GJVLeCPoDI4FePU-Z-NMwJHaS2XyH9S28LgqI1LNB8=.e32743dc-a6dd-475d-88ab-16ed3f46beab@github.com>
 <ehuksZQILsWLXcuvxgtRGIq7Lqwl146QQpIVHanMoIs=.9cad7f15-24b8-4bf6-99db-cbf3ef3cccbf@github.com>
 <vhRP_xqkq0g3topmOPn1JdTpaXtEDTKuI72fdNd6hSw=.86d4f9c6-197a-48de-94a5-0cbe54ad41ff@github.com>
Message-ID: <9b331e83-3352-fbed-265b-38c6d2f22139@gmail.com>


On 12/07/21 2:08 am, Lance Andersen wrote:
> On Mon, 5 Jul 2021 07:42:26 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:
>
>>> Can I please get a review for this proposed fix for the issue reported in https://bugs.openjdk.java.net/browse/JDK-8190753?
>>>
>>> The commit here checks for the size of the zip entry before trying to create a `ByteArrayOutputStream` for that entry's content. A new jtreg test has been included in this commit to reproduce the issue and verify the fix.
>>>
>>> P.S: It's still a bit arguable whether it's a good idea to create the `ByteArrayOutputStream` with an initial size potentially as large as the `MAX_ARRAY_SIZE` or whether it's better to just use some smaller default value. However, I think that can be addressed separately while dealing with https://bugs.openjdk.java.net/browse/JDK-8011146
>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>>
>>    reorganize the tests now that the temp file creation threshold isn't exposed as a user configurable value
> I think the updates made to Zip FS look better.   Alan is on vacation so I would prefer to wait until he gets back and give him a chance to provide any last thoughts on the change to Zip FS.
>
> The manual test looks OK and is a good addition


Thank you for the reviews and running the tests, Lance. I'll wait for 
Alan to be back for his reviews.

-Jaikiran


From yyang at openjdk.java.net  Mon Jul 12 02:57:26 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Mon, 12 Jul 2021 02:57:26 GMT
Subject: RFR: 8270056: Generated lambda class can not access protected
 static method of target class [v3]
In-Reply-To: <bDVkalKu_hLAwlGagLIkFol-aLy98PngVw8FrLc0pRM=.0670192d-ae03-4d31-82bb-097e20ae4ffd@github.com>
References: <bDVkalKu_hLAwlGagLIkFol-aLy98PngVw8FrLc0pRM=.0670192d-ae03-4d31-82bb-097e20ae4ffd@github.com>
Message-ID: <DAhbX7xSvkeFyciIno4DmNTikp8yYq5lrXIDctPsMEc=.18b4b4fd-551f-46de-90f8-4e96257076c0@github.com>

> Generated lambda class can not access protected static method of the target class. The following exception is thrown when executing the attached reproducible program:
> 
> 
> Exception in thread "main" java.lang.IllegalAccessError: class AccessProtectedStaticMethodFromSuper$B$$Lambda$15/0x0000000800b8ea48 tried to access protected method 'void AccessProtectedStaticMethodFromSuper$A.func()' (AccessProtectedStaticMethodFromSuper$B$$Lambda$15/0x0000000800b8ea48 is in unnamed module of loader AccessProtectedStaticMethodFromSuper$1Loader @71dac704; AccessProtectedStaticMethodFromSuper$A is in unnamed module of loader AccessProtectedStaticMethodFromSuper$1Loader @39ed3c8d)
> 	at AccessProtectedStaticMethodFromSuper.main(AccessProtectedStaticMethodFromSuper.java:51)
> 
> 
> This issue is similar to JDK-8254975(#767) with slight differences: generated lambda proxy calls static protected method rather than protected member method.
> 
> The proposed fix 1) tries to use MethodHandle instead of invoking forwardee directly(since the lambda class has no access to the resolved method) and 2) does not force accepting an implClass as the first argument when invoking a static method.
> 
> Testing:
> - test/jdk/java/ with release mode
> - presubmit tests

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

  mistake

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4714/files
  - new: https://git.openjdk.java.net/jdk/pull/4714/files/8aa4e1d7..1d4ad2ca

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

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

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

From yyang at openjdk.java.net  Mon Jul 12 05:24:57 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Mon, 12 Jul 2021 05:24:57 GMT
Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex,
 FromIndexSize} for java.base [v11]
In-Reply-To: <QM4u0adwYkgwPAp9Rr4v5M_2tC0EaWO9kctj8pXKt-U=.102e4127-2fe4-4be6-aa46-74f6cb040c44@github.com>
References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
 <QM4u0adwYkgwPAp9Rr4v5M_2tC0EaWO9kctj8pXKt-U=.102e4127-2fe4-4be6-aa46-74f6cb040c44@github.com>
Message-ID: <fAce1CcdIOiW48sazVB_56DhApB92Lr0gXN6zqOCAYo=.ee084537-89c5-473a-9bab-18dd1edd833b@github.com>

On Thu, 8 Jul 2021 03:12:24 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in the whole JDK codebase.
>
> Yi Yang has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR.

I'm not familiar with the review process of core-lib group. Is it sufficient for merging with one approval? Should I have more reviews for this? ??

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

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

From whuang at openjdk.java.net  Mon Jul 12 09:14:25 2021
From: whuang at openjdk.java.net (Wang Huang)
Date: Mon, 12 Jul 2021 09:14:25 GMT
Subject: RFR: 8268231: Aarch64: Use ldp in intrinsics for String.compareTo
 [v2]
In-Reply-To: <XwW4MjGSYmSHa2ZbzrOfvoZi1pe8LJAK7YIKtmNhaDM=.d39df32e-8698-4608-9184-3b19cd175d1a@github.com>
References: <XwW4MjGSYmSHa2ZbzrOfvoZi1pe8LJAK7YIKtmNhaDM=.d39df32e-8698-4608-9184-3b19cd175d1a@github.com>
Message-ID: <4E6St8xE9eEeKfntwFWka1oBRy7IuAjXW8iA1h8GuqA=.5be4869c-a286-4dfd-a0fb-fcb10e75f921@github.com>

> Dear all, 
>     Can you do me a favor to review this patch. This patch use `ldp` to implement String.compareTo.
>    
> * We add a JMH test case 
> * Here is the result of this test case
>  
> Benchmark	                       |(size)| Mode| Cnt|Score | Error	 |Units	
> ---------------------------------|------|-----|----|------|--------|-----
> StringCompare.compareLL       |  64  | avgt| 5  |7.992 | ?	0.005|us/op
> StringCompare.compareLL       |  72  | avgt| 5  |15.029| ?	0.006|us/op
> StringCompare.compareLL       |  80  | avgt| 5  |14.655| ?	0.011|us/op
> StringCompare.compareLL       |  91  | avgt| 5  |16.363| ?	0.12 |us/op
> StringCompare.compareLL       |  101 | avgt| 5  |16.966| ?	0.007|us/op
> StringCompare.compareLL       |  121 | avgt| 5  |19.276| ?	0.006|us/op
> StringCompare.compareLL       |  181 | avgt| 5  |19.002| ?	0.417|us/op
> StringCompare.compareLL       |  256 | avgt| 5  |24.707| ?	0.041|us/op
> StringCompare.compareLLWithLdp|  64  | avgt| 5  |8.001	| ?	0.121|us/op
> StringCompare.compareLLWithLdp|  72  | avgt| 5  |11.573| ?	0.003|us/op
> StringCompare.compareLLWithLdp|  80  | avgt| 5  |6.861 | ?	0.004|us/op
> StringCompare.compareLLWithLdp|  91  | avgt| 5  |12.774| ?	0.201|us/op
> StringCompare.compareLLWithLdp|  101 | avgt| 5  |8.691 | ?	0.004|us/op
> StringCompare.compareLLWithLdp|  121 | avgt| 5  |11.091| ?	1.342|us/op
> StringCompare.compareLLWithLdp|  181 | avgt| 5  |14.64 | ?	0.581|us/op
> StringCompare.compareLLWithLdp|  256 | avgt| 5  |25.879| ?	1.775|us/op
> StringCompare.compareUU       |  64  | avgt| 5  |13.476| ?	0.01 |us/op
> StringCompare.compareUU       |  72  | avgt| 5  |15.078| ?	0.006|us/op
> StringCompare.compareUU       |  80  | avgt| 5  |23.512| ?	0.011|us/op
> StringCompare.compareUU       |  91  | avgt| 5  |24.284| ?	0.008|us/op
> StringCompare.compareUU       |  101 | avgt| 5  |20.707| ?	0.017|us/op
> StringCompare.compareUU       |  121 | avgt| 5  |29.302| ?	0.011|us/op
> StringCompare.compareUU       |  181 | avgt| 5  |39.31	| ?	0.016|us/op
> StringCompare.compareUU       |  256 | avgt| 5  |54.592| ?	0.392|us/op
> StringCompare.compareUUWithLdp|  64  | avgt| 5  |16.389| ?	0.008|us/op
> StringCompare.compareUUWithLdp|  72  | avgt| 5  |10.71 | ?	0.158|us/op
> StringCompare.compareUUWithLdp|  80  | avgt| 5  |11.488| ?	0.024|us/op
> StringCompare.compareUUWithLdp|  91  | avgt| 5  |13.412| ?	0.006|us/op
> StringCompare.compareUUWithLdp|  101 | avgt| 5  |16.245| ?	0.434|us/op
> StringCompare.compareUUWithLdp|  121 | avgt| 5  |16.597| ?	0.016|us/op
> StringCompare.compareUUWithLdp|  181 | avgt| 5  |27.373| ?	0.017|us/op
> StringCompare.compareUUWithLdp|  256 | avgt| 5  |41.74 | ?	3.5	 |us/op
> 
> From this table, we can see that in most cases, our patch is better than old one.
> 
> Thank you for your review. Any suggestions are welcome.

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

  draft of refactor

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4722/files
  - new: https://git.openjdk.java.net/jdk/pull/4722/files/c5e29b9f..2ae667b9

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

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

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

From whuang at openjdk.java.net  Mon Jul 12 09:14:26 2021
From: whuang at openjdk.java.net (Wang Huang)
Date: Mon, 12 Jul 2021 09:14:26 GMT
Subject: RFR: 8268231: Aarch64: Use ldp in intrinsics for String.compareTo
In-Reply-To: <HfEFs8bJk69hqKifYHumIr1i4Kuc_XhtxvvRWG793Jk=.3fa019c3-91fc-469b-a99e-d5a393443ce3@github.com>
References: <XwW4MjGSYmSHa2ZbzrOfvoZi1pe8LJAK7YIKtmNhaDM=.d39df32e-8698-4608-9184-3b19cd175d1a@github.com>
 <HfEFs8bJk69hqKifYHumIr1i4Kuc_XhtxvvRWG793Jk=.3fa019c3-91fc-469b-a99e-d5a393443ce3@github.com>
Message-ID: <wvl4GiFiBs9Bo93TZ-P6YUvaKZxdU2R-EJQoYk-JeGs=.9b16a419-d510-4625-9d53-edad6dbcc3b5@github.com>

On Fri, 9 Jul 2021 09:15:18 GMT, Andrew Haley <aph at openjdk.org> wrote:

> I'm quite tempted to approve this. It looks generally better, simpler, and easier to understand than what we have today. However, the improvement isn't great, and I suspect is mostly because of the reduction in traffic between Base and Vector registers.
> What happens if you rewrite `compare_string_16_bytes_same()` to use `ldp` ?

I refacted `compare_string_16_bytes_same()` as a draft, the performance comparision is listed here,
Benchmark                                      |(diff_pos)|(size) | Mode | Cnt |  Score|  Error | Units
-----------------------------------------------|----------|-------|------|-----|-------|--------|------
StringCompare.compareLLDiffStrings             |         7|   128 | avgt |   5 |  4.252|? 0.001 | us/op
StringCompare.compareLLDiffStrings             |        15|   128 | avgt |   5 |  4.714|? 0.001 | us/op
StringCompare.compareLLDiffStrings             |        31|   128 | avgt |   5 |  6.139|? 0.445 | us/op
StringCompare.compareLLDiffStrings             |        47|   128 | avgt |   5 | 13.861|? 0.001 | us/op
StringCompare.compareLLDiffStrings             |        63|   128 | avgt |   5 |  8.823|? 0.007 | us/op
StringCompare.compareLLDiffStringsWithLdp      |         7|   128 | avgt |   5 |  3.867|? 0.001 | us/op
StringCompare.compareLLDiffStringsWithLdp      |        15|   128 | avgt |   5 |  5.571|? 0.756 | us/op
StringCompare.compareLLDiffStringsWithLdp      |        31|   128 | avgt |   5 |  5.408|? 0.001 | us/op
StringCompare.compareLLDiffStringsWithLdp      |        47|   128 | avgt |   5 |  6.896|? 0.825 | us/op
StringCompare.compareLLDiffStringsWithLdp      |        63|   128 | avgt |   5 |  6.787|? 0.001 | us/op
StringCompare.compareLLDiffStringsWithRefactor |         7|   128 | avgt |   5 |  3.481|? 0.001 | us/op
StringCompare.compareLLDiffStringsWithRefactor |        15|   128 | avgt |   5 | 10.023|? 0.012 | us/op
StringCompare.compareLLDiffStringsWithRefactor |        31|   128 | avgt |   5 |  5.627|? 0.017 | us/op
StringCompare.compareLLDiffStringsWithRefactor |        47|   128 | avgt |   5 | 13.369|? 0.544 | us/op
StringCompare.compareLLDiffStringsWithRefactor |        63|   128 | avgt |   5 |  8.382|? 0.988 | us/op

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

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

From github.com+762126+ignasi35 at openjdk.java.net  Mon Jul 12 12:44:57 2021
From: github.com+762126+ignasi35 at openjdk.java.net (Ignasi Marimon-Clos)
Date: Mon, 12 Jul 2021 12:44:57 GMT
Subject: RFR: 8266578: Disambiguate BigDecimal description of scale
In-Reply-To: <zYi0BeuAeqGR9D_Nyi8SZj8NsHr-JTzjDrYTvHlZiow=.2e7489e8-369c-4040-9345-d836d828e985@github.com>
References: <zYi0BeuAeqGR9D_Nyi8SZj8NsHr-JTzjDrYTvHlZiow=.2e7489e8-369c-4040-9345-d836d828e985@github.com>
Message-ID: <TwYKi1WPJFSq2gzbrbcZnxKKEjvLWpETvMcl_Oie1-0=.13df20c4-12fe-441e-b7c5-d174b20f2b33@github.com>

On Fri, 9 Oct 2020 16:14:59 GMT, Ignasi Marimon-Clos <github.com+762126+ignasi35 at openjdk.org> wrote:

> The API Docs for `BigDecimal` introduce the meaning of `scale`. The current writeup can be missleading when presenting the meaning of a `scale` value that's negative. Hopefully, with this PR, the sentence is more clear.
> 
> The ambiguity is on this sentence:
> 
>> If negative, the unscaled value of the number is ...
> 
> Instead, I suggest the more verbose:
> 
>> If the scale is negative, the unscaled value of the number is ...
> 
> To keep symmetry, I've also reviewed the positive case from:
> 
>> If zero or positive, the scale is the number of digits ...
> 
> to: 
> 
>> If the scale is zero or positive, the scale is the number of digits ...

Apologies on the incredible delay. I've been offline on sick leave and barely returning to work.

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

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

From jlaskey at openjdk.java.net  Mon Jul 12 14:35:08 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Mon, 12 Jul 2021 14:35:08 GMT
Subject: [jdk17] RFR: JDK-8270075 SplittableRandom extends
 AbstractSplittableGenerator
Message-ID: <hoRUR3GWahF1SY7g0B9YRCxmEHZqO4BMQTuOjqHzFys=.b1187f71-1b60-4970-a17c-088e13535ff0@github.com>

Random.AbstractSplittableGenerator is an internal class that should not be exposed in a public API.

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

Commit messages:
 - Remove public exposure of AbstractSplittableGenerator

Changes: https://git.openjdk.java.net/jdk17/pull/243/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=243&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8270075
  Stats: 48 lines in 1 file changed: 29 ins; 1 del; 18 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/243.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/243/head:pull/243

PR: https://git.openjdk.java.net/jdk17/pull/243

From aph at openjdk.java.net  Mon Jul 12 15:32:04 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Mon, 12 Jul 2021 15:32:04 GMT
Subject: RFR: 8268231: Aarch64: Use ldp in intrinsics for String.compareTo
 [v2]
In-Reply-To: <4E6St8xE9eEeKfntwFWka1oBRy7IuAjXW8iA1h8GuqA=.5be4869c-a286-4dfd-a0fb-fcb10e75f921@github.com>
References: <XwW4MjGSYmSHa2ZbzrOfvoZi1pe8LJAK7YIKtmNhaDM=.d39df32e-8698-4608-9184-3b19cd175d1a@github.com>
 <4E6St8xE9eEeKfntwFWka1oBRy7IuAjXW8iA1h8GuqA=.5be4869c-a286-4dfd-a0fb-fcb10e75f921@github.com>
Message-ID: <g_ps23br-bqqZzwg3S1hG2j-92MxJLgI6nvVULcW2fQ=.3cba87e1-8b6a-48b3-95a6-0e991e837693@github.com>

On Mon, 12 Jul 2021 09:14:25 GMT, Wang Huang <whuang at openjdk.org> wrote:

>> Dear all, 
>>     Can you do me a favor to review this patch. This patch use `ldp` to implement String.compareTo.
>>    
>> * We add a JMH test case 
>> * Here is the result of this test case
>>  
>> Benchmark	                       |(size)| Mode| Cnt|Score | Error	 |Units	
>> ---------------------------------|------|-----|----|------|--------|-----
>> StringCompare.compareLL       |  64  | avgt| 5  |7.992 | ?	0.005|us/op
>> StringCompare.compareLL       |  72  | avgt| 5  |15.029| ?	0.006|us/op
>> StringCompare.compareLL       |  80  | avgt| 5  |14.655| ?	0.011|us/op
>> StringCompare.compareLL       |  91  | avgt| 5  |16.363| ?	0.12 |us/op
>> StringCompare.compareLL       |  101 | avgt| 5  |16.966| ?	0.007|us/op
>> StringCompare.compareLL       |  121 | avgt| 5  |19.276| ?	0.006|us/op
>> StringCompare.compareLL       |  181 | avgt| 5  |19.002| ?	0.417|us/op
>> StringCompare.compareLL       |  256 | avgt| 5  |24.707| ?	0.041|us/op
>> StringCompare.compareLLWithLdp|  64  | avgt| 5  |8.001	| ?	0.121|us/op
>> StringCompare.compareLLWithLdp|  72  | avgt| 5  |11.573| ?	0.003|us/op
>> StringCompare.compareLLWithLdp|  80  | avgt| 5  |6.861 | ?	0.004|us/op
>> StringCompare.compareLLWithLdp|  91  | avgt| 5  |12.774| ?	0.201|us/op
>> StringCompare.compareLLWithLdp|  101 | avgt| 5  |8.691 | ?	0.004|us/op
>> StringCompare.compareLLWithLdp|  121 | avgt| 5  |11.091| ?	1.342|us/op
>> StringCompare.compareLLWithLdp|  181 | avgt| 5  |14.64 | ?	0.581|us/op
>> StringCompare.compareLLWithLdp|  256 | avgt| 5  |25.879| ?	1.775|us/op
>> StringCompare.compareUU       |  64  | avgt| 5  |13.476| ?	0.01 |us/op
>> StringCompare.compareUU       |  72  | avgt| 5  |15.078| ?	0.006|us/op
>> StringCompare.compareUU       |  80  | avgt| 5  |23.512| ?	0.011|us/op
>> StringCompare.compareUU       |  91  | avgt| 5  |24.284| ?	0.008|us/op
>> StringCompare.compareUU       |  101 | avgt| 5  |20.707| ?	0.017|us/op
>> StringCompare.compareUU       |  121 | avgt| 5  |29.302| ?	0.011|us/op
>> StringCompare.compareUU       |  181 | avgt| 5  |39.31	| ?	0.016|us/op
>> StringCompare.compareUU       |  256 | avgt| 5  |54.592| ?	0.392|us/op
>> StringCompare.compareUUWithLdp|  64  | avgt| 5  |16.389| ?	0.008|us/op
>> StringCompare.compareUUWithLdp|  72  | avgt| 5  |10.71 | ?	0.158|us/op
>> StringCompare.compareUUWithLdp|  80  | avgt| 5  |11.488| ?	0.024|us/op
>> StringCompare.compareUUWithLdp|  91  | avgt| 5  |13.412| ?	0.006|us/op
>> StringCompare.compareUUWithLdp|  101 | avgt| 5  |16.245| ?	0.434|us/op
>> StringCompare.compareUUWithLdp|  121 | avgt| 5  |16.597| ?	0.016|us/op
>> StringCompare.compareUUWithLdp|  181 | avgt| 5  |27.373| ?	0.017|us/op
>> StringCompare.compareUUWithLdp|  256 | avgt| 5  |41.74 | ?	3.5	 |us/op
>> 
>> From this table, we can see that in most cases, our patch is better than old one.
>> 
>> Thank you for your review. Any suggestions are welcome.
>
> Wang Huang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   draft of refactor

Two machines to compare here, Apple M1 and ThunderX2:


Benchmark                                       (diff_pos)  (size)  Mode  Cnt  Score   Error  Units
StringCompare.compareLLDiffStrings                       7     128  avgt    3  2.194 ? 0.001  us/op
StringCompare.compareLLDiffStrings                      15     128  avgt    3  2.195 ? 0.018  us/op
StringCompare.compareLLDiffStrings                      31     128  avgt    3  2.508 ? 0.003  us/op
StringCompare.compareLLDiffStrings                      47     128  avgt    3  2.821 ? 0.001  us/op
StringCompare.compareLLDiffStrings                      63     128  avgt    3  3.446 ? 0.003  us/op
StringCompare.compareLLDiffStringsWithLdp                7     128  avgt    3  2.194 ? 0.001  us/op
StringCompare.compareLLDiffStringsWithLdp               15     128  avgt    3  2.195 ? 0.001  us/op
StringCompare.compareLLDiffStringsWithLdp               31     128  avgt    3  2.508 ? 0.001  us/op
StringCompare.compareLLDiffStringsWithLdp               47     128  avgt    3  2.510 ? 0.006  us/op
StringCompare.compareLLDiffStringsWithLdp               63     128  avgt    3  2.824 ? 0.003  us/op
StringCompare.compareLLDiffStringsWithRefactor           7     128  avgt    3  1.882 ? 0.018  us/op
StringCompare.compareLLDiffStringsWithRefactor          15     128  avgt    3  2.019 ? 0.002  us/op
StringCompare.compareLLDiffStringsWithRefactor          31     128  avgt    3  2.355 ? 0.003  us/op
StringCompare.compareLLDiffStringsWithRefactor          47     128  avgt    3  2.821 ? 0.010  us/op
StringCompare.compareLLDiffStringsWithRefactor          63     128  avgt    3  3.135 ? 0.002  us/op


Benchmark                                       (diff_pos)  (size)  Mode  Cnt   Score   Error  Units
StringCompare.compareLLDiffStrings                       7     128  avgt    3   6.014 ? 0.016  us/op
StringCompare.compareLLDiffStrings                      15     128  avgt    3   6.431 ? 0.030  us/op
StringCompare.compareLLDiffStrings                      31     128  avgt    3   7.214 ? 0.012  us/op
StringCompare.compareLLDiffStrings                      47     128  avgt    3   8.816 ? 0.011  us/op
StringCompare.compareLLDiffStrings                      63     128  avgt    3  10.283 ? 0.033  us/op
StringCompare.compareLLDiffStringsWithLdp                7     128  avgt    3   5.214 ? 0.002  us/op
StringCompare.compareLLDiffStringsWithLdp               15     128  avgt    3   6.899 ? 0.359  us/op
StringCompare.compareLLDiffStringsWithLdp               31     128  avgt    3   7.309 ? 0.038  us/op
StringCompare.compareLLDiffStringsWithLdp               47     128  avgt    3   7.723 ? 0.080  us/op
StringCompare.compareLLDiffStringsWithLdp               63     128  avgt    3   9.822 ? 0.103  us/op
StringCompare.compareLLDiffStringsWithRefactor           7     128  avgt    3   4.814 ? 0.002  us/op
StringCompare.compareLLDiffStringsWithRefactor          15     128  avgt    3   8.395 ? 0.259  us/op
StringCompare.compareLLDiffStringsWithRefactor          31     128  avgt    3   7.615 ? 0.004  us/op
StringCompare.compareLLDiffStringsWithRefactor          47     128  avgt    3   8.817 ? 0.013  us/op
StringCompare.compareLLDiffStringsWithRefactor          63     128  avgt    3  10.413 ? 0.002  us/op

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

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

From aph at openjdk.java.net  Mon Jul 12 15:41:55 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Mon, 12 Jul 2021 15:41:55 GMT
Subject: RFR: 8268231: Aarch64: Use ldp in intrinsics for String.compareTo
 [v2]
In-Reply-To: <4E6St8xE9eEeKfntwFWka1oBRy7IuAjXW8iA1h8GuqA=.5be4869c-a286-4dfd-a0fb-fcb10e75f921@github.com>
References: <XwW4MjGSYmSHa2ZbzrOfvoZi1pe8LJAK7YIKtmNhaDM=.d39df32e-8698-4608-9184-3b19cd175d1a@github.com>
 <4E6St8xE9eEeKfntwFWka1oBRy7IuAjXW8iA1h8GuqA=.5be4869c-a286-4dfd-a0fb-fcb10e75f921@github.com>
Message-ID: <Lek9D7969HKQkO_NK5FQsog9Nz2WxJVyDe3hkKwJBAs=.e473bc04-7633-4047-af95-675aa452a69d@github.com>

On Mon, 12 Jul 2021 09:14:25 GMT, Wang Huang <whuang at openjdk.org> wrote:

>> Dear all, 
>>     Can you do me a favor to review this patch. This patch use `ldp` to implement String.compareTo.
>>    
>> * We add a JMH test case 
>> * Here is the result of this test case
>>  
>> Benchmark	                       |(size)| Mode| Cnt|Score | Error	 |Units	
>> ---------------------------------|------|-----|----|------|--------|-----
>> StringCompare.compareLL       |  64  | avgt| 5  |7.992 | ?	0.005|us/op
>> StringCompare.compareLL       |  72  | avgt| 5  |15.029| ?	0.006|us/op
>> StringCompare.compareLL       |  80  | avgt| 5  |14.655| ?	0.011|us/op
>> StringCompare.compareLL       |  91  | avgt| 5  |16.363| ?	0.12 |us/op
>> StringCompare.compareLL       |  101 | avgt| 5  |16.966| ?	0.007|us/op
>> StringCompare.compareLL       |  121 | avgt| 5  |19.276| ?	0.006|us/op
>> StringCompare.compareLL       |  181 | avgt| 5  |19.002| ?	0.417|us/op
>> StringCompare.compareLL       |  256 | avgt| 5  |24.707| ?	0.041|us/op
>> StringCompare.compareLLWithLdp|  64  | avgt| 5  |8.001	| ?	0.121|us/op
>> StringCompare.compareLLWithLdp|  72  | avgt| 5  |11.573| ?	0.003|us/op
>> StringCompare.compareLLWithLdp|  80  | avgt| 5  |6.861 | ?	0.004|us/op
>> StringCompare.compareLLWithLdp|  91  | avgt| 5  |12.774| ?	0.201|us/op
>> StringCompare.compareLLWithLdp|  101 | avgt| 5  |8.691 | ?	0.004|us/op
>> StringCompare.compareLLWithLdp|  121 | avgt| 5  |11.091| ?	1.342|us/op
>> StringCompare.compareLLWithLdp|  181 | avgt| 5  |14.64 | ?	0.581|us/op
>> StringCompare.compareLLWithLdp|  256 | avgt| 5  |25.879| ?	1.775|us/op
>> StringCompare.compareUU       |  64  | avgt| 5  |13.476| ?	0.01 |us/op
>> StringCompare.compareUU       |  72  | avgt| 5  |15.078| ?	0.006|us/op
>> StringCompare.compareUU       |  80  | avgt| 5  |23.512| ?	0.011|us/op
>> StringCompare.compareUU       |  91  | avgt| 5  |24.284| ?	0.008|us/op
>> StringCompare.compareUU       |  101 | avgt| 5  |20.707| ?	0.017|us/op
>> StringCompare.compareUU       |  121 | avgt| 5  |29.302| ?	0.011|us/op
>> StringCompare.compareUU       |  181 | avgt| 5  |39.31	| ?	0.016|us/op
>> StringCompare.compareUU       |  256 | avgt| 5  |54.592| ?	0.392|us/op
>> StringCompare.compareUUWithLdp|  64  | avgt| 5  |16.389| ?	0.008|us/op
>> StringCompare.compareUUWithLdp|  72  | avgt| 5  |10.71 | ?	0.158|us/op
>> StringCompare.compareUUWithLdp|  80  | avgt| 5  |11.488| ?	0.024|us/op
>> StringCompare.compareUUWithLdp|  91  | avgt| 5  |13.412| ?	0.006|us/op
>> StringCompare.compareUUWithLdp|  101 | avgt| 5  |16.245| ?	0.434|us/op
>> StringCompare.compareUUWithLdp|  121 | avgt| 5  |16.597| ?	0.016|us/op
>> StringCompare.compareUUWithLdp|  181 | avgt| 5  |27.373| ?	0.017|us/op
>> StringCompare.compareUUWithLdp|  256 | avgt| 5  |41.74 | ?	3.5	 |us/op
>> 
>> From this table, we can see that in most cases, our patch is better than old one.
>> 
>> Thank you for your review. Any suggestions are welcome.
>
> Wang Huang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   draft of refactor

And with longer strings, M1 and ThunderX2:


Benchmark                                       (diff_pos)  (size)  Mode  Cnt   Score   Error  Units
StringCompare.compareLLDiffStrings                    1023    1024  avgt    3  50.849 ? 0.087  us/op
StringCompare.compareLLDiffStringsWithLdp             1023    1024  avgt    3  23.676 ? 0.015  us/op
StringCompare.compareLLDiffStringsWithRefactor        1023    1024  avgt    3  28.967 ? 0.168  us/op


StringCompare.compareLLDiffStrings                    1023    1024  avgt    3  98.681 ? 0.026  us/op
StringCompare.compareLLDiffStringsWithLdp             1023    1024  avgt    3  82.576 ? 0.656  us/op
StringCompare.compareLLDiffStringsWithRefactor        1023    1024  avgt    3  98.801 ? 0.321  us/op

LDP wins on M1 here, but on ThunderX2 it makes almost no difference at all. And how often are we comparing such long strings?
I don't know what to think, really. It seems that we're near to a place where we're optimizing for micro-architecture, and I don't want to see that here. On the other hand, using LDP is not worse anywhere, so we should allow it.

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

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

From github.com+154109+jglick at openjdk.java.net  Mon Jul 12 16:34:57 2021
From: github.com+154109+jglick at openjdk.java.net (Jesse Glick)
Date: Mon, 12 Jul 2021 16:34:57 GMT
Subject: RFR: 8260265: UTF-8 by Default
In-Reply-To: <-F4rYMOBcR8vg_mtYrJ--Ovx9d5bDLTF2p40uV5QqMM=.9cfd49ad-be84-4455-9695-138203395b21@github.com>
References: <-F4rYMOBcR8vg_mtYrJ--Ovx9d5bDLTF2p40uV5QqMM=.9cfd49ad-be84-4455-9695-138203395b21@github.com>
Message-ID: <uBMMpNp9ZaUliWdEBivZv5KPoXt6e8kNbs2Dd6Dn5-o=.32159ec7-a320-4484-8e81-931d657b2871@github.com>

On Thu, 8 Jul 2021 21:23:00 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is an implementation for the `JEP 400: UTF-8 by Default`. The gist of the changes is `Charset.defaultCharset()` returning `UTF-8` and `file.encoding` system property being added in the spec, but another notable modification is in `java.io.PrintStream` where it continues to use the `Console` encoding as the default charset instead of `UTF-8`. Other changes are mostly clarification of the term "default charset" and their links. Corresponding CSR has also been drafted.
> 
> JEP 400: https://bugs.openjdk.java.net/browse/JDK-8187041
> CSR: https://bugs.openjdk.java.net/browse/JDK-8260266

I would have expected `System.out` and `.err` to use the console encoding, but application-constructed `PrintStream`s to use UTF-8 by default.

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

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

From jvernee at openjdk.java.net  Mon Jul 12 16:57:00 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Mon, 12 Jul 2021 16:57:00 GMT
Subject: [jdk17] RFR: 8270025: DynamicCallSiteDesc::withArgs doesn't throw
 NPE
In-Reply-To: <j7TtUsU8eNi_NXDTP7ID2tCH5pc_XsGkHcZW522eqyg=.561a4dc2-60ef-41e0-af82-1cdfc4ff21f3@github.com>
References: <j7TtUsU8eNi_NXDTP7ID2tCH5pc_XsGkHcZW522eqyg=.561a4dc2-60ef-41e0-af82-1cdfc4ff21f3@github.com>
Message-ID: <4AvO9TzKoVUQtwr1bZIFcfdNtZSmhWHFdzH9U9ZRuWk=.9b63e6b4-2ac8-4799-a26c-c8eb3a203469@github.com>

On Sat, 10 Jul 2021 19:03:36 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Please review this PR that is fixing a mismatch between the implementation for method `java.lang.constant.DynamicCallSiteDesc::withArgs` and its implementation. I made a mistake while working on a recent CSR [JDK-8224985](https://bugs.openjdk.java.net/browse/JDK-8224985) and fixed the API but mistakenly thought that the implementation was in sync with the spec. This is why this change is also including a unit test of the API for `java.lang.constant.DynamicCallSiteDesc` modulo method `resolveCallSiteDesc` which is covered in test `IndyDescTest` in the same test suite. Also this change needs a CSR as while fixing the implementation of method `::withArgs` I realized that the API of the varargs overloaded version of method `::of` needed some rewording too as it is invoking the same private constructor `::withArgs` is invoking. So it didn't make sense for the API of one method to be more restrictive than the other. Please review also the accompanying CSR.
> 
> Thanks,
> Vicente

LGTM

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

Marked as reviewed by jvernee (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/242

From mchung at openjdk.java.net  Mon Jul 12 16:56:58 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Mon, 12 Jul 2021 16:56:58 GMT
Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex,
 FromIndexSize} for java.base [v11]
In-Reply-To: <fAce1CcdIOiW48sazVB_56DhApB92Lr0gXN6zqOCAYo=.ee084537-89c5-473a-9bab-18dd1edd833b@github.com>
References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
 <QM4u0adwYkgwPAp9Rr4v5M_2tC0EaWO9kctj8pXKt-U=.102e4127-2fe4-4be6-aa46-74f6cb040c44@github.com>
 <fAce1CcdIOiW48sazVB_56DhApB92Lr0gXN6zqOCAYo=.ee084537-89c5-473a-9bab-18dd1edd833b@github.com>
Message-ID: <J0v7qsbP9BgGowSx1KSS-mH8ZJBJe3ATtgCmdXRe4R8=.e919d281-1c8e-43b0-84c0-8dca1f3d6740@github.com>

On Mon, 12 Jul 2021 05:21:34 GMT, Yi Yang <yyang at openjdk.org> wrote:

> I'm not familiar with the review process of core-lib group. Is it sufficient for merging with one approval? Should I have more reviews for this? ??

It depends on the change.

For this patch, it's good to get another reviewer to look through it.

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

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

From github.com+762126+ignasi35 at openjdk.java.net  Mon Jul 12 16:57:55 2021
From: github.com+762126+ignasi35 at openjdk.java.net (Ignasi Marimon-Clos)
Date: Mon, 12 Jul 2021 16:57:55 GMT
Subject: Integrated: 8266578: Disambiguate BigDecimal description of scale
In-Reply-To: <zYi0BeuAeqGR9D_Nyi8SZj8NsHr-JTzjDrYTvHlZiow=.2e7489e8-369c-4040-9345-d836d828e985@github.com>
References: <zYi0BeuAeqGR9D_Nyi8SZj8NsHr-JTzjDrYTvHlZiow=.2e7489e8-369c-4040-9345-d836d828e985@github.com>
Message-ID: <CSHIZYHObWifiT59KSStnnWISFbVt7yumWn5b_iWFgI=.985c0c05-18f8-4ad7-8b90-12586ba27571@github.com>

On Fri, 9 Oct 2020 16:14:59 GMT, Ignasi Marimon-Clos <github.com+762126+ignasi35 at openjdk.org> wrote:

> The API Docs for `BigDecimal` introduce the meaning of `scale`. The current writeup can be missleading when presenting the meaning of a `scale` value that's negative. Hopefully, with this PR, the sentence is more clear.
> 
> The ambiguity is on this sentence:
> 
>> If negative, the unscaled value of the number is ...
> 
> Instead, I suggest the more verbose:
> 
>> If the scale is negative, the unscaled value of the number is ...
> 
> To keep symmetry, I've also reviewed the positive case from:
> 
>> If zero or positive, the scale is the number of digits ...
> 
> to: 
> 
>> If the scale is zero or positive, the scale is the number of digits ...

This pull request has now been integrated.

Changeset: 1aef372e
Author:    Ignasi Marimon-Clos <ignasi35 at gmail.com>
Committer: Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/1aef372ed89a48f4eac0ac03b2b3520348713efb
Stats:     6 lines in 1 file changed: 1 ins; 0 del; 5 mod

8266578: Disambiguate BigDecimal description of scale

Reviewed-by: darcy, bpb

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

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

From jvernee at openjdk.java.net  Mon Jul 12 17:13:58 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Mon, 12 Jul 2021 17:13:58 GMT
Subject: [jdk17] RFR: 8269281: java/foreign/Test{Down,
 Up}call.java time out
In-Reply-To: <vghOiqn9I9ouV5b6Ux7wfBnsTNOABHmbUc45oSPnJJ4=.91ff7181-04e8-470d-a57e-e4f47d1f18e1@github.com>
References: <vghOiqn9I9ouV5b6Ux7wfBnsTNOABHmbUc45oSPnJJ4=.91ff7181-04e8-470d-a57e-e4f47d1f18e1@github.com>
Message-ID: <q2TwQ-9AchoEOXG6JnSc4WqAEqr0QhGhVl-H7TEqO00=.ea010b70-e3e7-4f52-a519-a8f7c4c23f64@github.com>

On Fri, 9 Jul 2021 15:01:15 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> After some more investigation, I have been able to at least partially reproduce on my Linux box. While I can't get to same slowdown as we're seeing in test machines, I did notice that in fastdebug mode, TestUpcall is a lot slower than in release mode.
> 
> The underlying issue is that these tests are generating a lot of "throwaway" method handles. Method handles are typically stored in fields - when that happens, creating a method handle with same shape as one that has already been created typically works ok, w/o overhead, because there's a cache in the MethodType class which stores already generated lambda forms (by method handle kind). This cache is a SofteReference cahce, so, if the system is under memory pressure, the GC is of course free to null out all these cached values, in which case a new lambda form will be generated, and a new class will be loaded.
> 
> When looking at both TestDowncall and TestUpcall, in their current form, it is possible to observe a fairly large amount of classes being loaded and unloaded. Since the test generates many garbage, the GC is under pressure, and that causes entries in the lambda form cache to be evicted. The fact that one of the tests also explicitly calls out to `System::gc` doesn't help, and probably adds to the churn.
> 
> Since it is very hard, if not impossible, to fix the test so that all the required method handle are retained for the entire duration of the test (since we create different variations of same handles, based on the test being run), I believe the best solution would be to reduce the number of test combinations being executed.
> 
> This patch adds the ability to specify a sampling factor - which reduces the size of the test combinations being executed. Note that we also have a fuller test (which is never run automatically, but can be ran by hand: `TestMatrix`) - this test does not specify any sampling factor, so when developers run this stress test manually they will still run the whole shebang (which is what you want if you are tweaking the logic in the foreign support).

LGTM

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

Marked as reviewed by jvernee (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/238

From mchung at openjdk.java.net  Mon Jul 12 17:18:51 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Mon, 12 Jul 2021 17:18:51 GMT
Subject: [jdk17] RFR: 8270025: DynamicCallSiteDesc::withArgs doesn't throw
 NPE
In-Reply-To: <j7TtUsU8eNi_NXDTP7ID2tCH5pc_XsGkHcZW522eqyg=.561a4dc2-60ef-41e0-af82-1cdfc4ff21f3@github.com>
References: <j7TtUsU8eNi_NXDTP7ID2tCH5pc_XsGkHcZW522eqyg=.561a4dc2-60ef-41e0-af82-1cdfc4ff21f3@github.com>
Message-ID: <-QThU6KUWjdcq2-JA77e8PXlDn29De9xWreYyXKMplI=.1d19fc15-fa7d-472c-a1ec-77fe0d0ff3e0@github.com>

On Sat, 10 Jul 2021 19:03:36 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Please review this PR that is fixing a mismatch between the implementation for method `java.lang.constant.DynamicCallSiteDesc::withArgs` and its implementation. I made a mistake while working on a recent CSR [JDK-8224985](https://bugs.openjdk.java.net/browse/JDK-8224985) and fixed the API but mistakenly thought that the implementation was in sync with the spec. This is why this change is also including a unit test of the API for `java.lang.constant.DynamicCallSiteDesc` modulo method `resolveCallSiteDesc` which is covered in test `IndyDescTest` in the same test suite. Also this change needs a CSR as while fixing the implementation of method `::withArgs` I realized that the API of the varargs overloaded version of method `::of` needed some rewording too as it is invoking the same private constructor `::withArgs` is invoking. So it didn't make sense for the API of one method to be more restrictive than the other. Please review also the accompanying CSR.
> 
> Thanks,
> Vicente

Looks good.  Minor suggestions in the test.

test/jdk/java/lang/constant/DynamicCallSiteDescTest.java line 60:

> 58:                             "bootstrap",
> 59:                             ClassDesc.of("java.lang.invoke.CallSite")
> 60:                     ),

A minor suggestion: you can have the return `DirectMethodHandleDesc` in a local variable to be used in all `DynamicCallSiteDesc::of` calls that would avoid copy-n-paste of same `ConstantDescs::ofCallsiteBootstrap` call.

test/jdk/java/lang/constant/DynamicCallSiteDescTest.java line 64:

> 62:                     MethodTypeDesc.ofDescriptor("()I")
> 63:             );
> 64:             throw new AssertionError("IllegalArgumentException expected");

Suggestion:

            fail("IllegalArgumentException expected");


Same for other `throw new AssertionError(...)`

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

Marked as reviewed by mchung (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/242

From vromero at openjdk.java.net  Mon Jul 12 17:38:53 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Mon, 12 Jul 2021 17:38:53 GMT
Subject: [jdk17] RFR: 8270025: DynamicCallSiteDesc::withArgs doesn't throw
 NPE
In-Reply-To: <-QThU6KUWjdcq2-JA77e8PXlDn29De9xWreYyXKMplI=.1d19fc15-fa7d-472c-a1ec-77fe0d0ff3e0@github.com>
References: <j7TtUsU8eNi_NXDTP7ID2tCH5pc_XsGkHcZW522eqyg=.561a4dc2-60ef-41e0-af82-1cdfc4ff21f3@github.com>
 <-QThU6KUWjdcq2-JA77e8PXlDn29De9xWreYyXKMplI=.1d19fc15-fa7d-472c-a1ec-77fe0d0ff3e0@github.com>
Message-ID: <V1bUaebcqLFxGtzshiddlgMXu4Ifn-Knnt-73oWnssc=.2e87a348-7736-4072-8659-e4f22708c3b9@github.com>

On Mon, 12 Jul 2021 17:11:01 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Please review this PR that is fixing a mismatch between the implementation for method `java.lang.constant.DynamicCallSiteDesc::withArgs` and its implementation. I made a mistake while working on a recent CSR [JDK-8224985](https://bugs.openjdk.java.net/browse/JDK-8224985) and fixed the API but mistakenly thought that the implementation was in sync with the spec. This is why this change is also including a unit test of the API for `java.lang.constant.DynamicCallSiteDesc` modulo method `resolveCallSiteDesc` which is covered in test `IndyDescTest` in the same test suite. Also this change needs a CSR as while fixing the implementation of method `::withArgs` I realized that the API of the varargs overloaded version of method `::of` needed some rewording too as it is invoking the same private constructor `::withArgs` is invoking. So it didn't make sense for the API of one method to be more restrictive than the other. Please review also the accompanying CSR.
>> 
>> Thanks,
>> Vicente
>
> test/jdk/java/lang/constant/DynamicCallSiteDescTest.java line 60:
> 
>> 58:                             "bootstrap",
>> 59:                             ClassDesc.of("java.lang.invoke.CallSite")
>> 60:                     ),
> 
> A minor suggestion: you can have the return `DirectMethodHandleDesc` in a local variable to be used in all `DynamicCallSiteDesc::of` calls that would avoid copy-n-paste of same `ConstantDescs::ofCallsiteBootstrap` call.

will do

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

PR: https://git.openjdk.java.net/jdk17/pull/242

From mchung at openjdk.java.net  Mon Jul 12 17:43:57 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Mon, 12 Jul 2021 17:43:57 GMT
Subject: RFR: 8270056: Generated lambda class can not access protected
 static method of target class [v3]
In-Reply-To: <DAhbX7xSvkeFyciIno4DmNTikp8yYq5lrXIDctPsMEc=.18b4b4fd-551f-46de-90f8-4e96257076c0@github.com>
References: <bDVkalKu_hLAwlGagLIkFol-aLy98PngVw8FrLc0pRM=.0670192d-ae03-4d31-82bb-097e20ae4ffd@github.com>
 <DAhbX7xSvkeFyciIno4DmNTikp8yYq5lrXIDctPsMEc=.18b4b4fd-551f-46de-90f8-4e96257076c0@github.com>
Message-ID: <HxTzC2R91-PMYDCCX-Jygh3SHYOYzs3D-xg9p-xmEVk=.20066cf1-4768-446c-b117-9f6c07ba6cb5@github.com>

On Mon, 12 Jul 2021 02:57:26 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> Generated lambda class can not access protected static method of the target class. The following exception is thrown when executing the attached reproducible program:
>> 
>> 
>> Exception in thread "main" java.lang.IllegalAccessError: class AccessProtectedStaticMethodFromSuper$B$$Lambda$15/0x0000000800b8ea48 tried to access protected method 'void AccessProtectedStaticMethodFromSuper$A.func()' (AccessProtectedStaticMethodFromSuper$B$$Lambda$15/0x0000000800b8ea48 is in unnamed module of loader AccessProtectedStaticMethodFromSuper$1Loader @71dac704; AccessProtectedStaticMethodFromSuper$A is in unnamed module of loader AccessProtectedStaticMethodFromSuper$1Loader @39ed3c8d)
>> 	at AccessProtectedStaticMethodFromSuper.main(AccessProtectedStaticMethodFromSuper.java:51)
>> 
>> 
>> This issue is similar to JDK-8254975(#767) with slight differences: generated lambda proxy calls static protected method rather than protected member method.
>> 
>> The proposed fix 1) tries to use MethodHandle instead of invoking forwardee directly(since the lambda class has no access to the resolved method) and 2) does not force accepting an implClass as the first argument when invoking a static method.
>> 
>> Testing:
>> - test/jdk/java/ with release mode
>> - presubmit tests
>
> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   mistake

Looks good.

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

Marked as reviewed by mchung (Reviewer).

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

From vromero at openjdk.java.net  Mon Jul 12 17:48:04 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Mon, 12 Jul 2021 17:48:04 GMT
Subject: [jdk17] RFR: 8270025: DynamicCallSiteDesc::withArgs doesn't throw
 NPE [v2]
In-Reply-To: <j7TtUsU8eNi_NXDTP7ID2tCH5pc_XsGkHcZW522eqyg=.561a4dc2-60ef-41e0-af82-1cdfc4ff21f3@github.com>
References: <j7TtUsU8eNi_NXDTP7ID2tCH5pc_XsGkHcZW522eqyg=.561a4dc2-60ef-41e0-af82-1cdfc4ff21f3@github.com>
Message-ID: <ZaWBTilH6EXukMIM08wzUEECGEh5n-6YWpVxAwXgmuU=.7564bd80-0511-4a9d-8222-6a16bb24eac8@github.com>

> Please review this PR that is fixing a mismatch between the implementation for method `java.lang.constant.DynamicCallSiteDesc::withArgs` and its implementation. I made a mistake while working on a recent CSR [JDK-8224985](https://bugs.openjdk.java.net/browse/JDK-8224985) and fixed the API but mistakenly thought that the implementation was in sync with the spec. This is why this change is also including a unit test of the API for `java.lang.constant.DynamicCallSiteDesc` modulo method `resolveCallSiteDesc` which is covered in test `IndyDescTest` in the same test suite. Also this change needs a CSR as while fixing the implementation of method `::withArgs` I realized that the API of the varargs overloaded version of method `::of` needed some rewording too as it is invoking the same private constructor `::withArgs` is invoking. So it didn't make sense for the API of one method to be more restrictive than the other. Please review also the accompanying CSR.
> 
> Thanks,
> Vicente

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

  addressing review comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/242/files
  - new: https://git.openjdk.java.net/jdk17/pull/242/files/602a85c4..f7fddc99

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

  Stats: 42 lines in 1 file changed: 8 ins; 20 del; 14 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/242.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/242/head:pull/242

PR: https://git.openjdk.java.net/jdk17/pull/242

From bpb at openjdk.java.net  Mon Jul 12 17:59:32 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Mon, 12 Jul 2021 17:59:32 GMT
Subject: RFR: 6506405: Math.abs(float) is slow [v9]
In-Reply-To: <101iFqz6Ghvzu84BSMu6OyB-8sgTyx32uvfc5R-YTjg=.6a958f74-16cb-4388-a793-abad94093aa9@github.com>
References: <101iFqz6Ghvzu84BSMu6OyB-8sgTyx32uvfc5R-YTjg=.6a958f74-16cb-4388-a793-abad94093aa9@github.com>
Message-ID: <T1q1PLl4AGffBBsflTT6zEQKKMW3pYvci4wp_k-uotU=.9341f86f-4d09-4ebd-8f95-65e28a749179@github.com>

> Please consider this change to make the `float` and `double` versions of `java.lang.Math.abs()` branch-free.

Brian Burkhalter 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:

  6506405: More test cleanup

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4711/files
  - new: https://git.openjdk.java.net/jdk/pull/4711/files/f23fa829..c061d49f

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

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

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

From vromero at openjdk.java.net  Mon Jul 12 18:06:30 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Mon, 12 Jul 2021 18:06:30 GMT
Subject: [jdk17] RFR: 8270025: DynamicCallSiteDesc::withArgs doesn't throw
 NPE [v3]
In-Reply-To: <j7TtUsU8eNi_NXDTP7ID2tCH5pc_XsGkHcZW522eqyg=.561a4dc2-60ef-41e0-af82-1cdfc4ff21f3@github.com>
References: <j7TtUsU8eNi_NXDTP7ID2tCH5pc_XsGkHcZW522eqyg=.561a4dc2-60ef-41e0-af82-1cdfc4ff21f3@github.com>
Message-ID: <GDhwG7YJlq-hZsixNX6a8E1DJpVv94LJnKigK8TM5r0=.bf686d9d-0ec0-468b-9c32-a4a9a38ac4ce@github.com>

> Please review this PR that is fixing a mismatch between the implementation for method `java.lang.constant.DynamicCallSiteDesc::withArgs` and its implementation. I made a mistake while working on a recent CSR [JDK-8224985](https://bugs.openjdk.java.net/browse/JDK-8224985) and fixed the API but mistakenly thought that the implementation was in sync with the spec. This is why this change is also including a unit test of the API for `java.lang.constant.DynamicCallSiteDesc` modulo method `resolveCallSiteDesc` which is covered in test `IndyDescTest` in the same test suite. Also this change needs a CSR as while fixing the implementation of method `::withArgs` I realized that the API of the varargs overloaded version of method `::of` needed some rewording too as it is invoking the same private constructor `::withArgs` is invoking. So it didn't make sense for the API of one method to be more restrictive than the other. Please review also the accompanying CSR.
> 
> Thanks,
> Vicente

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

  review comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/242/files
  - new: https://git.openjdk.java.net/jdk17/pull/242/files/f7fddc99..6702a42f

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

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

PR: https://git.openjdk.java.net/jdk17/pull/242

From mchung at openjdk.java.net  Mon Jul 12 18:06:33 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Mon, 12 Jul 2021 18:06:33 GMT
Subject: [jdk17] RFR: 8270025: DynamicCallSiteDesc::withArgs doesn't throw
 NPE [v3]
In-Reply-To: <GDhwG7YJlq-hZsixNX6a8E1DJpVv94LJnKigK8TM5r0=.bf686d9d-0ec0-468b-9c32-a4a9a38ac4ce@github.com>
References: <j7TtUsU8eNi_NXDTP7ID2tCH5pc_XsGkHcZW522eqyg=.561a4dc2-60ef-41e0-af82-1cdfc4ff21f3@github.com>
 <GDhwG7YJlq-hZsixNX6a8E1DJpVv94LJnKigK8TM5r0=.bf686d9d-0ec0-468b-9c32-a4a9a38ac4ce@github.com>
Message-ID: <q4gTGaF5irpPKTlfW9yXfaTk6fgFnB9_Q2y5aJgTSfk=.6d211700-0f29-4822-a050-7e5a4348fa95@github.com>

On Mon, 12 Jul 2021 18:02:54 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Please review this PR that is fixing a mismatch between the implementation for method `java.lang.constant.DynamicCallSiteDesc::withArgs` and its implementation. I made a mistake while working on a recent CSR [JDK-8224985](https://bugs.openjdk.java.net/browse/JDK-8224985) and fixed the API but mistakenly thought that the implementation was in sync with the spec. This is why this change is also including a unit test of the API for `java.lang.constant.DynamicCallSiteDesc` modulo method `resolveCallSiteDesc` which is covered in test `IndyDescTest` in the same test suite. Also this change needs a CSR as while fixing the implementation of method `::withArgs` I realized that the API of the varargs overloaded version of method `::of` needed some rewording too as it is invoking the same private constructor `::withArgs` is invoking. So it didn't make sense for the API of one method to be more restrictive than the other. Please review also the accompanying CSR.
>> 
>> Thanks,
>> Vicente
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comments

Marked as reviewed by mchung (Reviewer).

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

PR: https://git.openjdk.java.net/jdk17/pull/242

From mchung at openjdk.java.net  Mon Jul 12 18:30:00 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Mon, 12 Jul 2021 18:30:00 GMT
Subject: RFR: 8266936: Add a finalization JFR event
In-Reply-To: <PpWS13N5Xk6jE-2GGuVjVbd9KgG11x85fFDHww7fMeA=.cbfa8c67-2ead-4db5-ade3-f2bc45565b11@github.com>
References: <PpWS13N5Xk6jE-2GGuVjVbd9KgG11x85fFDHww7fMeA=.cbfa8c67-2ead-4db5-ade3-f2bc45565b11@github.com>
Message-ID: <KAHLDtNCO770DeITJTyiveMrshxVLgqztvooOPRxc3M=.82211166-17e8-439f-98e8-535e4c04ba3b@github.com>

On Thu, 8 Jul 2021 19:47:26 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> Greetings,
> 
> Object.finalize() was deprecated in JDK9. There is an ongoing effort to replace and mitigate Object.finalize() uses in the JDK libraries; please see https://bugs.openjdk.java.net/browse/JDK-8253568 for more information. 
> 
> We also like to assist users in replacing and mitigating uses in non-JDK code.
> 
> Hence, this changeset adds a periodic JFR event to help identify which classes are overriding Object.finalize().
> 
> Thanks
> Markus

This approach inspecting the loaded classes periodically as well as tracking the classes being unloaded looks good.   A class with the same class name may be loaded from different class loader and could also be loaded from different code source.  It'd be useful for the finalizer event to include the code source which is passed from defineClass to help identify where the class was loaded from.

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

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

From bpb at openjdk.java.net  Mon Jul 12 19:46:08 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Mon, 12 Jul 2021 19:46:08 GMT
Subject: RFR: 8211002: test/jdk/java/lang/Math/PowTests.java skips testing for
 non-corner-case values
Message-ID: <CTD8-ciAhD-kPjiC0ic6qbOOE3XObK7JoFCTOVpLflM=.7970b30d-a3b0-4a7f-81c0-860894d56b94@github.com>

Please consider this proposal to add some test coverage comparing `Math` and `StrictMath` results of `pow()`.

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

Commit messages:
 - 8211002: test/jdk/java/lang/Math/PowTests.java skips testing for non-corner-case values

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

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

From rriggs at openjdk.java.net  Mon Jul 12 19:49:53 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Mon, 12 Jul 2021 19:49:53 GMT
Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex,
 FromIndexSize} for java.base [v11]
In-Reply-To: <QM4u0adwYkgwPAp9Rr4v5M_2tC0EaWO9kctj8pXKt-U=.102e4127-2fe4-4be6-aa46-74f6cb040c44@github.com>
References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
 <QM4u0adwYkgwPAp9Rr4v5M_2tC0EaWO9kctj8pXKt-U=.102e4127-2fe4-4be6-aa46-74f6cb040c44@github.com>
Message-ID: <sgRG6_cJ5_--BLqBtV9jmmNxbq0kmbEFC0oDRFekDwY=.3353ef2b-9f25-4552-a64a-d07027c4b21b@github.com>

On Thu, 8 Jul 2021 03:12:24 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in the whole JDK codebase.
>
> Yi Yang 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:
> 
>   restore JSR166; restore java.desktop

Looks good.

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

Marked as reviewed by rriggs (Reviewer).

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

From rriggs at openjdk.java.net  Mon Jul 12 19:58:52 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Mon, 12 Jul 2021 19:58:52 GMT
Subject: [jdk17] RFR: JDK-8270075 SplittableRandom extends
 AbstractSplittableGenerator
In-Reply-To: <hoRUR3GWahF1SY7g0B9YRCxmEHZqO4BMQTuOjqHzFys=.b1187f71-1b60-4970-a17c-088e13535ff0@github.com>
References: <hoRUR3GWahF1SY7g0B9YRCxmEHZqO4BMQTuOjqHzFys=.b1187f71-1b60-4970-a17c-088e13535ff0@github.com>
Message-ID: <0zeSiIG4-trQykXWynXcJ3PWE8tMUI7szviGl24ntkY=.239b7e24-7ec2-4da6-afc8-2f9bb1f2878e@github.com>

On Mon, 12 Jul 2021 14:26:23 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

> Random.AbstractSplittableGenerator is an internal class that should not be exposed in a public API.

Marked as reviewed by rriggs (Reviewer).

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

PR: https://git.openjdk.java.net/jdk17/pull/243

From bpb at openjdk.java.net  Mon Jul 12 20:45:53 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Mon, 12 Jul 2021 20:45:53 GMT
Subject: [jdk17] RFR: JDK-8270075 SplittableRandom extends
 AbstractSplittableGenerator
In-Reply-To: <hoRUR3GWahF1SY7g0B9YRCxmEHZqO4BMQTuOjqHzFys=.b1187f71-1b60-4970-a17c-088e13535ff0@github.com>
References: <hoRUR3GWahF1SY7g0B9YRCxmEHZqO4BMQTuOjqHzFys=.b1187f71-1b60-4970-a17c-088e13535ff0@github.com>
Message-ID: <qj33podzPCeVNzQDvbTgAoHmP6oKyfsW2q48c_QFPWI=.66cba6ea-3662-4246-8ccc-4805993a6ba8@github.com>

On Mon, 12 Jul 2021 14:26:23 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

> Random.AbstractSplittableGenerator is an internal class that should not be exposed in a public API.

Marked as reviewed by bpb (Reviewer).

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

PR: https://git.openjdk.java.net/jdk17/pull/243

From yyang at openjdk.java.net  Tue Jul 13 02:23:52 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Tue, 13 Jul 2021 02:23:52 GMT
Subject: RFR: 8270056: Generated lambda class can not access protected
 static method of target class [v3]
In-Reply-To: <DAhbX7xSvkeFyciIno4DmNTikp8yYq5lrXIDctPsMEc=.18b4b4fd-551f-46de-90f8-4e96257076c0@github.com>
References: <bDVkalKu_hLAwlGagLIkFol-aLy98PngVw8FrLc0pRM=.0670192d-ae03-4d31-82bb-097e20ae4ffd@github.com>
 <DAhbX7xSvkeFyciIno4DmNTikp8yYq5lrXIDctPsMEc=.18b4b4fd-551f-46de-90f8-4e96257076c0@github.com>
Message-ID: <ifdj_GKLnrbtvBRQiZJZ1mBAT9iPZihWA9jouuuI1xw=.e56320ef-5dae-4ba3-a62b-4f0f0dc4ecd6@github.com>

On Mon, 12 Jul 2021 02:57:26 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> Generated lambda class can not access protected static method of the target class. The following exception is thrown when executing the attached reproducible program:
>> 
>> 
>> Exception in thread "main" java.lang.IllegalAccessError: class AccessProtectedStaticMethodFromSuper$B$$Lambda$15/0x0000000800b8ea48 tried to access protected method 'void AccessProtectedStaticMethodFromSuper$A.func()' (AccessProtectedStaticMethodFromSuper$B$$Lambda$15/0x0000000800b8ea48 is in unnamed module of loader AccessProtectedStaticMethodFromSuper$1Loader @71dac704; AccessProtectedStaticMethodFromSuper$A is in unnamed module of loader AccessProtectedStaticMethodFromSuper$1Loader @39ed3c8d)
>> 	at AccessProtectedStaticMethodFromSuper.main(AccessProtectedStaticMethodFromSuper.java:51)
>> 
>> 
>> This issue is similar to JDK-8254975(#767) with slight differences: generated lambda proxy calls static protected method rather than protected member method.
>> 
>> The proposed fix 1) tries to use MethodHandle instead of invoking forwardee directly(since the lambda class has no access to the resolved method) and 2) does not force accepting an implClass as the first argument when invoking a static method.
>> 
>> Testing:
>> - test/jdk/java/ with release mode
>> - presubmit tests
>
> Yi Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   mistake

Thanks Mandy for review!

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

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

From yyang at openjdk.java.net  Tue Jul 13 02:28:04 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Tue, 13 Jul 2021 02:28:04 GMT
Subject: Integrated: 8270056: Generated lambda class can not access protected
 static method of target class
In-Reply-To: <bDVkalKu_hLAwlGagLIkFol-aLy98PngVw8FrLc0pRM=.0670192d-ae03-4d31-82bb-097e20ae4ffd@github.com>
References: <bDVkalKu_hLAwlGagLIkFol-aLy98PngVw8FrLc0pRM=.0670192d-ae03-4d31-82bb-097e20ae4ffd@github.com>
Message-ID: <gSyayya-IKbB_FQ6UXPdDjnNfP9npyUn4p0U5UqcO1U=.1e04371b-3657-4192-92e7-98f7815c5f00@github.com>

On Thu, 8 Jul 2021 02:32:45 GMT, Yi Yang <yyang at openjdk.org> wrote:

> Generated lambda class can not access protected static method of the target class. The following exception is thrown when executing the attached reproducible program:
> 
> 
> Exception in thread "main" java.lang.IllegalAccessError: class AccessProtectedStaticMethodFromSuper$B$$Lambda$15/0x0000000800b8ea48 tried to access protected method 'void AccessProtectedStaticMethodFromSuper$A.func()' (AccessProtectedStaticMethodFromSuper$B$$Lambda$15/0x0000000800b8ea48 is in unnamed module of loader AccessProtectedStaticMethodFromSuper$1Loader @71dac704; AccessProtectedStaticMethodFromSuper$A is in unnamed module of loader AccessProtectedStaticMethodFromSuper$1Loader @39ed3c8d)
> 	at AccessProtectedStaticMethodFromSuper.main(AccessProtectedStaticMethodFromSuper.java:51)
> 
> 
> This issue is similar to JDK-8254975(#767) with slight differences: generated lambda proxy calls static protected method rather than protected member method.
> 
> The proposed fix 1) tries to use MethodHandle instead of invoking forwardee directly(since the lambda class has no access to the resolved method) and 2) does not force accepting an implClass as the first argument when invoking a static method.
> 
> Testing:
> - test/jdk/java/ with release mode
> - presubmit tests

This pull request has now been integrated.

Changeset: 07e90524
Author:    Yi Yang <yyang at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/07e90524576f159fc16523430f1db62327c89a3b
Stats:     324 lines in 3 files changed: 181 ins; 141 del; 2 mod

8270056: Generated lambda class can not access protected static method of target class

Co-authored-by: NekoCaffeine <nekocaffeine at qq.com>
Reviewed-by: mchung

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

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

From yyang at openjdk.java.net  Tue Jul 13 02:38:00 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Tue, 13 Jul 2021 02:38:00 GMT
Subject: Integrated: 8268698: Use Objects.check{Index, FromToIndex,
 FromIndexSize} for java.base
In-Reply-To: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
Message-ID: <4Gub7lCLaidzVMPjzkZNJD2kC9X_F7RMtYuNY0c80S4=.5f60cd93-799c-4cd2-8ad9-eb549b0bf281@github.com>

On Wed, 16 Jun 2021 08:08:47 GMT, Yi Yang <yyang at openjdk.org> wrote:

> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in the whole JDK codebase.

This pull request has now been integrated.

Changeset: afe957cd
Author:    Yi Yang <yyang at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/afe957cd9741810a113ea165a635a117c0ea556f
Stats:     357 lines in 40 files changed: 73 ins; 171 del; 113 mod

8268698: Use Objects.check{Index,FromToIndex,FromIndexSize} for java.base

Reviewed-by: mchung, rriggs

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

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

From yyang at openjdk.java.net  Tue Jul 13 02:37:59 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Tue, 13 Jul 2021 02:37:59 GMT
Subject: RFR: 8268698: Use Objects.check{Index, FromToIndex,
 FromIndexSize} for java.base [v11]
In-Reply-To: <QM4u0adwYkgwPAp9Rr4v5M_2tC0EaWO9kctj8pXKt-U=.102e4127-2fe4-4be6-aa46-74f6cb040c44@github.com>
References: <0YP_xUmJDBHd4ZRlKxsn-DuRa8OSLcahyZlFGHuvWOw=.c6c29818-7fc9-46a7-8951-8d197bdfde57@github.com>
 <QM4u0adwYkgwPAp9Rr4v5M_2tC0EaWO9kctj8pXKt-U=.102e4127-2fe4-4be6-aa46-74f6cb040c44@github.com>
Message-ID: <Wv9f3s9E44AxjCG_1izKI9RFdCCta08e2bsJ82JwaH8=.d33f7caa-1904-4f23-9ad0-d27cdd5152db@github.com>

On Thu, 8 Jul 2021 03:12:24 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> After JDK-8265518(#3615), it's possible to replace all variants of checkIndex by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in the whole JDK codebase.
>
> Yi Yang 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.

Thanks Mandy and Roger for reviews!

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

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

From yyang at openjdk.java.net  Tue Jul 13 03:16:16 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Tue, 13 Jul 2021 03:16:16 GMT
Subject: [jdk17] RFR: 8270056: Generated lambda class can not access protected
 static method of target class
Message-ID: <N8VMxxFr16sfeaZs-xs5gzTjeQRWVClQ3pwsTNsf3tQ=.26197799-c262-495e-9d1a-7b0b03ddb1f3@github.com>

Hi all,

this pull request contains a backport of commit 07e90524 from the openjdk/jdk repository.

The commit being backported was authored by Yi Yang on 13 Jul 2021 and was reviewed by Mandy Chung.

Thanks!

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

Commit messages:
 - Backport 07e90524576f159fc16523430f1db62327c89a3b

Changes: https://git.openjdk.java.net/jdk17/pull/245/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=245&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8270056
  Stats: 324 lines in 3 files changed: 181 ins; 141 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/245.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/245/head:pull/245

PR: https://git.openjdk.java.net/jdk17/pull/245

From whuang at openjdk.java.net  Tue Jul 13 03:32:55 2021
From: whuang at openjdk.java.net (Wang Huang)
Date: Tue, 13 Jul 2021 03:32:55 GMT
Subject: RFR: 8268231: Aarch64: Use ldp in intrinsics for String.compareTo
 [v2]
In-Reply-To: <Lek9D7969HKQkO_NK5FQsog9Nz2WxJVyDe3hkKwJBAs=.e473bc04-7633-4047-af95-675aa452a69d@github.com>
References: <XwW4MjGSYmSHa2ZbzrOfvoZi1pe8LJAK7YIKtmNhaDM=.d39df32e-8698-4608-9184-3b19cd175d1a@github.com>
 <4E6St8xE9eEeKfntwFWka1oBRy7IuAjXW8iA1h8GuqA=.5be4869c-a286-4dfd-a0fb-fcb10e75f921@github.com>
 <Lek9D7969HKQkO_NK5FQsog9Nz2WxJVyDe3hkKwJBAs=.e473bc04-7633-4047-af95-675aa452a69d@github.com>
Message-ID: <Hp9ztyMuHsPXzvT3a02a8JV-0OnqtzpAfxAWT4Yd_oM=.b210d127-b91f-4565-8a06-dea5dfffbca3@github.com>

On Mon, 12 Jul 2021 15:36:29 GMT, Andrew Haley <aph at openjdk.org> wrote:

> And with longer strings, M1 and ThunderX2:
> 
> ```
> Benchmark                                       (diff_pos)  (size)  Mode  Cnt   Score   Error  Units
> StringCompare.compareLLDiffStrings                    1023    1024  avgt    3  50.849 ? 0.087  us/op
> StringCompare.compareLLDiffStringsWithLdp             1023    1024  avgt    3  23.676 ? 0.015  us/op
> StringCompare.compareLLDiffStringsWithRefactor        1023    1024  avgt    3  28.967 ? 0.168  us/op
> ```
> 
> ```
> StringCompare.compareLLDiffStrings                    1023    1024  avgt    3  98.681 ? 0.026  us/op
> StringCompare.compareLLDiffStringsWithLdp             1023    1024  avgt    3  82.576 ? 0.656  us/op
> StringCompare.compareLLDiffStringsWithRefactor        1023    1024  avgt    3  98.801 ? 0.321  us/op
> ```
> 
> LDP wins on M1 here, but on ThunderX2 it makes almost no difference at all. And how often are we comparing such long strings?
> I don't know what to think, really. It seems that we're near to a place where we're optimizing for micro-architecture, and I don't want to see that here. On the other hand, using LDP is not worse anywhere, so we should allow it.

Thank you for your suggestion. I inspect the result and find that the result of my first commit (c5e29b9fedae7e1d24056a6fae8aff04afeb3889) is better. Because of that , I will choose the version without refacting `compare_string_16_bytes_same` as the final version.

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

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

From whuang at openjdk.java.net  Tue Jul 13 07:37:31 2021
From: whuang at openjdk.java.net (Wang Huang)
Date: Tue, 13 Jul 2021 07:37:31 GMT
Subject: RFR: 8268231: Aarch64: Use ldp in intrinsics for String.compareTo
 [v3]
In-Reply-To: <XwW4MjGSYmSHa2ZbzrOfvoZi1pe8LJAK7YIKtmNhaDM=.d39df32e-8698-4608-9184-3b19cd175d1a@github.com>
References: <XwW4MjGSYmSHa2ZbzrOfvoZi1pe8LJAK7YIKtmNhaDM=.d39df32e-8698-4608-9184-3b19cd175d1a@github.com>
Message-ID: <B4QlLNxlUxwMUmJjgZG6e82vGN2tlnJeKsQ_1QCNlOE=.b99f2103-318f-40f1-89d6-1069dc0ba22d@github.com>

> Dear all, 
>     Can you do me a favor to review this patch. This patch use `ldp` to implement String.compareTo.
>    
> * We add a JMH test case 
> * Here is the result of this test case
>  
> Benchmark	                       |(size)| Mode| Cnt|Score | Error	 |Units	
> ---------------------------------|------|-----|----|------|--------|-----
> StringCompare.compareLL       |  64  | avgt| 5  |7.992 | ?	0.005|us/op
> StringCompare.compareLL       |  72  | avgt| 5  |15.029| ?	0.006|us/op
> StringCompare.compareLL       |  80  | avgt| 5  |14.655| ?	0.011|us/op
> StringCompare.compareLL       |  91  | avgt| 5  |16.363| ?	0.12 |us/op
> StringCompare.compareLL       |  101 | avgt| 5  |16.966| ?	0.007|us/op
> StringCompare.compareLL       |  121 | avgt| 5  |19.276| ?	0.006|us/op
> StringCompare.compareLL       |  181 | avgt| 5  |19.002| ?	0.417|us/op
> StringCompare.compareLL       |  256 | avgt| 5  |24.707| ?	0.041|us/op
> StringCompare.compareLLWithLdp|  64  | avgt| 5  |8.001	| ?	0.121|us/op
> StringCompare.compareLLWithLdp|  72  | avgt| 5  |11.573| ?	0.003|us/op
> StringCompare.compareLLWithLdp|  80  | avgt| 5  |6.861 | ?	0.004|us/op
> StringCompare.compareLLWithLdp|  91  | avgt| 5  |12.774| ?	0.201|us/op
> StringCompare.compareLLWithLdp|  101 | avgt| 5  |8.691 | ?	0.004|us/op
> StringCompare.compareLLWithLdp|  121 | avgt| 5  |11.091| ?	1.342|us/op
> StringCompare.compareLLWithLdp|  181 | avgt| 5  |14.64 | ?	0.581|us/op
> StringCompare.compareLLWithLdp|  256 | avgt| 5  |25.879| ?	1.775|us/op
> StringCompare.compareUU       |  64  | avgt| 5  |13.476| ?	0.01 |us/op
> StringCompare.compareUU       |  72  | avgt| 5  |15.078| ?	0.006|us/op
> StringCompare.compareUU       |  80  | avgt| 5  |23.512| ?	0.011|us/op
> StringCompare.compareUU       |  91  | avgt| 5  |24.284| ?	0.008|us/op
> StringCompare.compareUU       |  101 | avgt| 5  |20.707| ?	0.017|us/op
> StringCompare.compareUU       |  121 | avgt| 5  |29.302| ?	0.011|us/op
> StringCompare.compareUU       |  181 | avgt| 5  |39.31	| ?	0.016|us/op
> StringCompare.compareUU       |  256 | avgt| 5  |54.592| ?	0.392|us/op
> StringCompare.compareUUWithLdp|  64  | avgt| 5  |16.389| ?	0.008|us/op
> StringCompare.compareUUWithLdp|  72  | avgt| 5  |10.71 | ?	0.158|us/op
> StringCompare.compareUUWithLdp|  80  | avgt| 5  |11.488| ?	0.024|us/op
> StringCompare.compareUUWithLdp|  91  | avgt| 5  |13.412| ?	0.006|us/op
> StringCompare.compareUUWithLdp|  101 | avgt| 5  |16.245| ?	0.434|us/op
> StringCompare.compareUUWithLdp|  121 | avgt| 5  |16.597| ?	0.016|us/op
> StringCompare.compareUUWithLdp|  181 | avgt| 5  |27.373| ?	0.017|us/op
> StringCompare.compareUUWithLdp|  256 | avgt| 5  |41.74 | ?	3.5	 |us/op
> 
> From this table, we can see that in most cases, our patch is better than old one.
> 
> Thank you for your review. Any suggestions are welcome.

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

  refact codes

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4722/files
  - new: https://git.openjdk.java.net/jdk/pull/4722/files/2ae667b9..3fa9afcb

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

  Stats: 167 lines in 3 files changed: 0 ins; 153 del; 14 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4722.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4722/head:pull/4722

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

From mcimadamore at openjdk.java.net  Tue Jul 13 10:56:53 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 13 Jul 2021 10:56:53 GMT
Subject: [jdk17] Integrated: 8269281: java/foreign/Test{Down,
 Up}call.java time out
In-Reply-To: <vghOiqn9I9ouV5b6Ux7wfBnsTNOABHmbUc45oSPnJJ4=.91ff7181-04e8-470d-a57e-e4f47d1f18e1@github.com>
References: <vghOiqn9I9ouV5b6Ux7wfBnsTNOABHmbUc45oSPnJJ4=.91ff7181-04e8-470d-a57e-e4f47d1f18e1@github.com>
Message-ID: <e6xdUWlVV3U2wlXFSdcz0vpp8LKKOG_Izz2WfJHp3Xk=.669ffce5-73c3-4acb-a317-1a13dc615632@github.com>

On Fri, 9 Jul 2021 15:01:15 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> After some more investigation, I have been able to at least partially reproduce on my Linux box. While I can't get to same slowdown as we're seeing in test machines, I did notice that in fastdebug mode, TestUpcall is a lot slower than in release mode.
> 
> The underlying issue is that these tests are generating a lot of "throwaway" method handles. Method handles are typically stored in fields - when that happens, creating a method handle with same shape as one that has already been created typically works ok, w/o overhead, because there's a cache in the MethodType class which stores already generated lambda forms (by method handle kind). This cache is a SofteReference cahce, so, if the system is under memory pressure, the GC is of course free to null out all these cached values, in which case a new lambda form will be generated, and a new class will be loaded.
> 
> When looking at both TestDowncall and TestUpcall, in their current form, it is possible to observe a fairly large amount of classes being loaded and unloaded. Since the test generates many garbage, the GC is under pressure, and that causes entries in the lambda form cache to be evicted. The fact that one of the tests also explicitly calls out to `System::gc` doesn't help, and probably adds to the churn.
> 
> Since it is very hard, if not impossible, to fix the test so that all the required method handle are retained for the entire duration of the test (since we create different variations of same handles, based on the test being run), I believe the best solution would be to reduce the number of test combinations being executed.
> 
> This patch adds the ability to specify a sampling factor - which reduces the size of the test combinations being executed. Note that we also have a fuller test (which is never run automatically, but can be ran by hand: `TestMatrix`) - this test does not specify any sampling factor, so when developers run this stress test manually they will still run the whole shebang (which is what you want if you are tweaking the logic in the foreign support).

This pull request has now been integrated.

Changeset: b2416b60
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.java.net/jdk17/commit/b2416b60fbe1117cc502d5ecdd8356d42d27fddb
Stats:     17 lines in 3 files changed: 6 ins; 7 del; 4 mod

8269281: java/foreign/Test{Down,Up}call.java time out

Reviewed-by: jvernee

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

PR: https://git.openjdk.java.net/jdk17/pull/238

From mbien42 at gmail.com  Tue Jul 13 12:45:13 2021
From: mbien42 at gmail.com (Michael Bien)
Date: Tue, 13 Jul 2021 14:45:13 +0200
Subject: SplittableGenerator of JEP 356
Message-ID: <b1d04ced-0449-d928-f539-fd6a194f9656@gmail.com>

Hello,

i was wondering if SplittableGenerator.split(SplittableGenerator source) 
is missing out on a potential usecase when the source itself is not 
splittable. The implementation looks like it only requires basic calls 
which could be also provided by the RandomGenerator interface as source.

best regards,

michael


From jlaskey at openjdk.java.net  Tue Jul 13 12:49:24 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Tue, 13 Jul 2021 12:49:24 GMT
Subject: [jdk17] RFR: JDK-8270075 SplittableRandom extends
 AbstractSplittableGenerator [v2]
In-Reply-To: <hoRUR3GWahF1SY7g0B9YRCxmEHZqO4BMQTuOjqHzFys=.b1187f71-1b60-4970-a17c-088e13535ff0@github.com>
References: <hoRUR3GWahF1SY7g0B9YRCxmEHZqO4BMQTuOjqHzFys=.b1187f71-1b60-4970-a17c-088e13535ff0@github.com>
Message-ID: <48KP584om7BFwZ3IBS5r9bhQhZyco5Xah_cb7hNX0Ag=.9dfd5495-7c2f-4c7d-a6be-6d4b6f139fa2@github.com>

> Random.AbstractSplittableGenerator is an internal class that should not be exposed in a public API.

Jim Laskey has updated the pull request with a new target base 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 8270075
 - Remove public exposure of AbstractSplittableGenerator

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

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/243/files
  - new: https://git.openjdk.java.net/jdk17/pull/243/files/02e18b7f..37972ea8

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

  Stats: 221 lines in 14 files changed: 155 ins; 18 del; 48 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/243.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/243/head:pull/243

PR: https://git.openjdk.java.net/jdk17/pull/243

From attila at openjdk.java.net  Tue Jul 13 13:08:05 2021
From: attila at openjdk.java.net (Attila Szegedi)
Date: Tue, 13 Jul 2021 13:08:05 GMT
Subject: RFR: 8268113: Re-use Long.hashCode() where possible [v9]
In-Reply-To: <_TQh_iGjI3byKr1pc0gr7GZnCiyeKubYIy4rkLwbipY=.08915956-df4e-411e-b985-edd411a5bdc3@github.com>
References: <7TGw6Vzvw38bqmNOQsuVuGXMe98OqH25nmexLUghcMU=.5e7b347c-0d83-4e54-acc3-9847c08cdc29@github.com>
 <_TQh_iGjI3byKr1pc0gr7GZnCiyeKubYIy4rkLwbipY=.08915956-df4e-411e-b985-edd411a5bdc3@github.com>
Message-ID: <P1bleKY0ErOGoARqX7TwlWUMToCFitDwdEtpPbZPFI0=.0c62cbca-c3a2-4734-b267-415ba99bf399@github.com>

On Wed, 2 Jun 2021 14:11:07 GMT, ?????? ??????? <github.com+10835776+stsypanov 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 ten additional commits since the last revision:
>> 
>>  - Merge branch 'master' into 8268113
>>  - Merge branch 'master' into 8268113
>>  - Merge branch 'master' into 8268113
>>  - Merge branch 'master' into 8268113
>>  - Merge branch 'master' into 8268113
>>  - Merge branch 'master' into 8268113
>>  - 8268113: Inline local vars where reasonable
>>  - 8268113: Delegate to Double.hashCode()
>>  - 8268113: Re-use Long.hashCode() where possible
>
> src/java.base/share/classes/java/util/BitSet.java line 1040:
> 
>> 1038:             h ^= words[i] * (i + 1);
>> 1039: 
>> 1040:         return Long.hashCode(h);
> 
> Here `>>` instead of `>>>` in original code seems to be a typo

It is specified as `>>` in JavaDoc just above the implementation. As the algorithm is part of the public API and thus part of the specification, I don't think you can change it just here in the implementation; you'd need to at least submit a CSR for it.

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

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

From vlivanov at openjdk.java.net  Tue Jul 13 14:03:56 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Tue, 13 Jul 2021 14:03:56 GMT
Subject: [jdk17] RFR: 8269240:
 java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC
In-Reply-To: <PqFCdTWCSge_X14Rc5aNAo2pr5uliZ9jT0iYltvef3g=.7467c1a4-ad15-48a3-a495-75b655acf69c@github.com>
References: <PqFCdTWCSge_X14Rc5aNAo2pr5uliZ9jT0iYltvef3g=.7467c1a4-ad15-48a3-a495-75b655acf69c@github.com>
Message-ID: <-CKmdxtDz9PebGwjDU6XEUMukYMC9CKmW2rhm6xZKWM=.8a88e29e-7b17-4647-9848-7a5bd2927fef@github.com>

On Fri, 25 Jun 2021 17:38:32 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> This patch rewrites the prologue and epilogue of panama upcalls, in order to fix the test failure from the title.
> 
> Previously, we did a call to potentially attach the current thread to the VM, and then afterwards did the same suspend and stack reguard checks that we do on the back-edge of a native downcall. Then, on the back edge of the upcall we did another conditional call to detach the thread.
> 
> The suspend and reguard checks on the front-edge are incorrect, so I've changed the 2 calls to mimic what is done by JavaCallWrapper instead (with attach and detach included), and removed the old suspend and stack reguard checks.
> 
> FWIW, this removes the JavaFrameAnchor save/restore MacroAssembler code. This is now written in C++. Also, MacroAssembler code was added to save/restore the result of the upcall around the call on the back-edge, which was previously missing. Since the new code allocates a handle block as well, I've added handling for those oops to frame & OptimizedUpcallBlob.
> 
> Testing: local running of `jdk_foreign` on Windows and Linux (WSL). Tier 1-3

Looks good.

src/hotspot/cpu/x86/frame_x86.cpp line 356:

> 354: }
> 355: 
> 356: OptimizedEntryBlob::FrameData* OptimizedEntryBlob::frame_data_for_frame(const frame& frame) const {

It makes sense to assert that `frame` refers to optimized entry frame (`assert(frame->is_optimized_entry_frame(), "wrong frame");`.

src/hotspot/share/runtime/thread.hpp line 1128:

> 1126: 
> 1127:  private:
> 1128:   DEBUG_ONLY(void verify_frame_info();)

If you declare `verify_frame_info` as returning a `bool` (and just put a `return true;` at the end of `JavaThread::verify_frame_info()`), you can call it as:

assert(verify_frame_info(), "unexpected frame info");

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

Marked as reviewed by vlivanov (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/149

From mbien42 at gmail.com  Tue Jul 13 14:52:18 2021
From: mbien42 at gmail.com (Michael Bien)
Date: Tue, 13 Jul 2021 16:52:18 +0200
Subject: SplittableGenerator of JEP 356
In-Reply-To: <b1d04ced-0449-d928-f539-fd6a194f9656@gmail.com>
References: <b1d04ced-0449-d928-f539-fd6a194f9656@gmail.com>
Message-ID: <0e598ac8-1db1-aca7-8b31-b301fd3f0605@gmail.com>

just wanted to add that the JEP says: "SplittableRandomGenerator extends 
RandomGenerator and also provides
methods named split and splits. Splittability allows the user to spawn a 
new RandomGenerator from an existing RandomGenerator that will generally 
produce statistically independent results."

which adds to my suspicion that this might be a api bug.

-michael

On 13.07.21 14:45, Michael Bien wrote:
> Hello,
>
> i was wondering if SplittableGenerator.split(SplittableGenerator 
> source) is missing out on a potential usecase when the source itself 
> is not splittable. The implementation looks like it only requires 
> basic calls which could be also provided by the RandomGenerator 
> interface as source.
>
> best regards,
>
> michael
>


From jvernee at openjdk.java.net  Tue Jul 13 15:01:57 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Tue, 13 Jul 2021 15:01:57 GMT
Subject: [jdk17] RFR: 8269240:
 java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC
In-Reply-To: <-CKmdxtDz9PebGwjDU6XEUMukYMC9CKmW2rhm6xZKWM=.8a88e29e-7b17-4647-9848-7a5bd2927fef@github.com>
References: <PqFCdTWCSge_X14Rc5aNAo2pr5uliZ9jT0iYltvef3g=.7467c1a4-ad15-48a3-a495-75b655acf69c@github.com>
 <-CKmdxtDz9PebGwjDU6XEUMukYMC9CKmW2rhm6xZKWM=.8a88e29e-7b17-4647-9848-7a5bd2927fef@github.com>
Message-ID: <COfhH43wnMDmJRyZMfM1HGsmw13KyRoJnI1petdtAFU=.c4aaf2d9-abd9-4f5d-ac85-d92ea92c1f98@github.com>

On Tue, 13 Jul 2021 13:52:18 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> This patch rewrites the prologue and epilogue of panama upcalls, in order to fix the test failure from the title.
>> 
>> Previously, we did a call to potentially attach the current thread to the VM, and then afterwards did the same suspend and stack reguard checks that we do on the back-edge of a native downcall. Then, on the back edge of the upcall we did another conditional call to detach the thread.
>> 
>> The suspend and reguard checks on the front-edge are incorrect, so I've changed the 2 calls to mimic what is done by JavaCallWrapper instead (with attach and detach included), and removed the old suspend and stack reguard checks.
>> 
>> FWIW, this removes the JavaFrameAnchor save/restore MacroAssembler code. This is now written in C++. Also, MacroAssembler code was added to save/restore the result of the upcall around the call on the back-edge, which was previously missing. Since the new code allocates a handle block as well, I've added handling for those oops to frame & OptimizedUpcallBlob.
>> 
>> Testing: local running of `jdk_foreign` on Windows and Linux (WSL). Tier 1-3
>
> src/hotspot/cpu/x86/frame_x86.cpp line 356:
> 
>> 354: }
>> 355: 
>> 356: OptimizedEntryBlob::FrameData* OptimizedEntryBlob::frame_data_for_frame(const frame& frame) const {
> 
> It makes sense to assert that `frame` refers to optimized entry frame (`assert(frame->is_optimized_entry_frame(), "wrong frame");`.

Good idea. Thanks

> src/hotspot/share/runtime/thread.hpp line 1128:
> 
>> 1126: 
>> 1127:  private:
>> 1128:   DEBUG_ONLY(void verify_frame_info();)
> 
> If you declare `verify_frame_info` as returning a `bool` (and just put a `return true;` at the end of `JavaThread::verify_frame_info()`), you can call it as:
> 
> assert(verify_frame_info(), "unexpected frame info");

Thanks for the suggestion. I'd like to keep it the way it is though, so that the assert message contains the `has_last_frame` & `java_call_counter` values. (this was one of the reason I did this refactor as well, since the assert I was hitting out of those 3 didn't contain that info).

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

PR: https://git.openjdk.java.net/jdk17/pull/149

From jvernee at openjdk.java.net  Tue Jul 13 15:16:26 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Tue, 13 Jul 2021 15:16:26 GMT
Subject: [jdk17] RFR: 8269240:
 java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC
 [v2]
In-Reply-To: <PqFCdTWCSge_X14Rc5aNAo2pr5uliZ9jT0iYltvef3g=.7467c1a4-ad15-48a3-a495-75b655acf69c@github.com>
References: <PqFCdTWCSge_X14Rc5aNAo2pr5uliZ9jT0iYltvef3g=.7467c1a4-ad15-48a3-a495-75b655acf69c@github.com>
Message-ID: <o-O6F0omoRjgCjD28Ir79_QYw2xdT_1SlIu2h0eLqH0=.a9e4053d-4464-40de-94df-39fc98e4eaaf@github.com>

> This patch rewrites the prologue and epilogue of panama upcalls, in order to fix the test failure from the title.
> 
> Previously, we did a call to potentially attach the current thread to the VM, and then afterwards did the same suspend and stack reguard checks that we do on the back-edge of a native downcall. Then, on the back edge of the upcall we did another conditional call to detach the thread.
> 
> The suspend and reguard checks on the front-edge are incorrect, so I've changed the 2 calls to mimic what is done by JavaCallWrapper instead (with attach and detach included), and removed the old suspend and stack reguard checks.
> 
> FWIW, this removes the JavaFrameAnchor save/restore MacroAssembler code. This is now written in C++. Also, MacroAssembler code was added to save/restore the result of the upcall around the call on the back-edge, which was previously missing. Since the new code allocates a handle block as well, I've added handling for those oops to frame & OptimizedUpcallBlob.
> 
> Testing: local running of `jdk_foreign` on Windows and Linux (WSL). Tier 1-3

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

  Assert frame is correct type in frame_data_for_frame

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

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/149/files
  - new: https://git.openjdk.java.net/jdk17/pull/149/files/c90416f5..211bf316

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

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

PR: https://git.openjdk.java.net/jdk17/pull/149

From mchung at openjdk.java.net  Tue Jul 13 16:30:16 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 13 Jul 2021 16:30:16 GMT
Subject: [jdk17] RFR: 8270056: Generated lambda class can not access
 protected static method of target class
In-Reply-To: <N8VMxxFr16sfeaZs-xs5gzTjeQRWVClQ3pwsTNsf3tQ=.26197799-c262-495e-9d1a-7b0b03ddb1f3@github.com>
References: <N8VMxxFr16sfeaZs-xs5gzTjeQRWVClQ3pwsTNsf3tQ=.26197799-c262-495e-9d1a-7b0b03ddb1f3@github.com>
Message-ID: <2vcjh-FZWm0DMcF60UEUsG9nDXsTH9Q8Gvzgw4HBqjw=.eb826c0a-de9a-42b8-b15f-d180bc699f6c@github.com>

On Tue, 13 Jul 2021 03:06:12 GMT, Yi Yang <yyang at openjdk.org> wrote:

> Hi all,
> 
> this pull request contains a backport of commit 07e90524 from the openjdk/jdk repository.
> 
> The commit being backported was authored by Yi Yang on 13 Jul 2021 and was reviewed by Mandy Chung.
> 
> Thanks!

Marked as reviewed by mchung (Reviewer).

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

PR: https://git.openjdk.java.net/jdk17/pull/245

From herrick at openjdk.java.net  Tue Jul 13 16:39:01 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Tue, 13 Jul 2021 16:39:01 GMT
Subject: RFR: JDK-8269387: jpackage --add-launcher should have option to
 not create shortcuts for additional launchers [v3]
In-Reply-To: <gO8--JRs2F9hyLuR5gnanY-KYiH-wYSexmUbDGeaP0Q=.e8fa9a64-1018-427f-b1f9-72fc48671b21@github.com>
References: <gO8--JRs2F9hyLuR5gnanY-KYiH-wYSexmUbDGeaP0Q=.e8fa9a64-1018-427f-b1f9-72fc48671b21@github.com>
Message-ID: <RT-r32OmJKqm882vtWvvwNk7jyPC1-CFhBZtb9bstHQ=.0d75ac7a-816b-424c-bce9-22e0514b785f@github.com>

> JDK-8269387: jpackage --add-launcher should have option to not create shortcuts for additional launchers

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

  JDK-8269387: jpackage --add-launcher should have option to not create shortcuts for additional launchers

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4730/files
  - new: https://git.openjdk.java.net/jdk/pull/4730/files/3fe30059..d88b1dc7

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

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

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

From james.laskey at oracle.com  Tue Jul 13 16:58:59 2021
From: james.laskey at oracle.com (Jim Laskey)
Date: Tue, 13 Jul 2021 16:58:59 +0000
Subject: SplittableGenerator of JEP 356
In-Reply-To: <0e598ac8-1db1-aca7-8b31-b301fd3f0605@gmail.com>
References: <b1d04ced-0449-d928-f539-fd6a194f9656@gmail.com>
 <0e598ac8-1db1-aca7-8b31-b301fd3f0605@gmail.com>
Message-ID: <37006C97-8AD6-4AC7-A97D-469864B076B2@oracle.com>

From Guy:

You are right that the comment in the JEP was a little loose, and that the implementation(s) of the split/splits methods could in principle draw random values from a RandomGenerator that is not itself splittable. There might even be applications for such functionality.

However, we chose not to support that more general functionality for a fairly subtle reason: there are concerns that if a PNRG is less than perfect, using it as a source of entropy for seeding a PRNG that uses a different algorithm might result in unexpected correlations that could drastically reduce the quality of the output of the new PRNG instance. Restricting the implementation of the split method so that it always constructs a new generator of the same class has allowed us the opportunity to test each class separately and independently for quality of output when the split method is used.

Programmers who know what they are doing can get the effect of the more general split functionality by calling constructors explicitly. This forces them to think about the specific algorithms. For example:

RandomGenerator r = new SplittableRandom();
RandomGenerator g = new L64X256MixRandom(r.nextLong(), r.nextLong(),
                   r.nextLong(), r.nextLong(), r.nextLong(), r.nextLong());

The programmer may then reason that, in this specific case, the fact that the period of r is only 2^64 implies that the last four values generated cannot all be zero, which is one desideratum for g to have good quality. (The programmer would also have the responsibility to decide more generally whether this particular combination of entropy source and generated instance will in fact have good quality.)

?Guy Steele


> On Jul 13, 2021, at 11:52 AM, Michael Bien <mbien42 at gmail.com> wrote:
> 
> just wanted to add that the JEP says: "SplittableRandomGenerator extends RandomGenerator and also provides
> methods named split and splits. Splittability allows the user to spawn a new RandomGenerator from an existing RandomGenerator that will generally produce statistically independent results."
> 
> which adds to my suspicion that this might be a api bug.
> 
> -michael
> 
> On 13.07.21 14:45, Michael Bien wrote:
>> Hello,
>> 
>> i was wondering if SplittableGenerator.split(SplittableGenerator source) is missing out on a potential usecase when the source itself is not splittable. The implementation looks like it only requires basic calls which could be also provided by the RandomGenerator interface as source.
>> 
>> best regards,
>> 
>> michael
>> 
> 


From vlivanov at openjdk.java.net  Tue Jul 13 17:09:12 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Tue, 13 Jul 2021 17:09:12 GMT
Subject: [jdk17] RFR: 8269240:
 java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC
 [v2]
In-Reply-To: <COfhH43wnMDmJRyZMfM1HGsmw13KyRoJnI1petdtAFU=.c4aaf2d9-abd9-4f5d-ac85-d92ea92c1f98@github.com>
References: <PqFCdTWCSge_X14Rc5aNAo2pr5uliZ9jT0iYltvef3g=.7467c1a4-ad15-48a3-a495-75b655acf69c@github.com>
 <-CKmdxtDz9PebGwjDU6XEUMukYMC9CKmW2rhm6xZKWM=.8a88e29e-7b17-4647-9848-7a5bd2927fef@github.com>
 <COfhH43wnMDmJRyZMfM1HGsmw13KyRoJnI1petdtAFU=.c4aaf2d9-abd9-4f5d-ac85-d92ea92c1f98@github.com>
Message-ID: <DlbU1RvRgWn5eDTYXKRHRek6xO41mHz0qm5A0YqecBo=.8082071a-7309-40e1-afd8-4cf4d7b8858d@github.com>

On Tue, 13 Jul 2021 14:59:07 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> src/hotspot/share/runtime/thread.hpp line 1128:
>> 
>>> 1126: 
>>> 1127:  private:
>>> 1128:   DEBUG_ONLY(void verify_frame_info();)
>> 
>> If you declare `verify_frame_info` as returning a `bool` (and just put a `return true;` at the end of `JavaThread::verify_frame_info()`), you can call it as:
>> 
>> assert(verify_frame_info(), "unexpected frame info");
>
> Thanks for the suggestion. I'd like to keep it the way it is though, so that the assert message contains the `has_last_frame` & `java_call_counter` values. (this was one of the reason I did this refactor as well, since the assert I was hitting out of those 3 didn't contain that info).

You can keep the assert inside `verify_frame_info()` which dumps additional data. (Yes, it's a bit confusing: assert inside an assert :-) )

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

PR: https://git.openjdk.java.net/jdk17/pull/149

From vlivanov at openjdk.java.net  Tue Jul 13 17:09:12 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Tue, 13 Jul 2021 17:09:12 GMT
Subject: [jdk17] RFR: 8269240:
 java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC
 [v2]
In-Reply-To: <DlbU1RvRgWn5eDTYXKRHRek6xO41mHz0qm5A0YqecBo=.8082071a-7309-40e1-afd8-4cf4d7b8858d@github.com>
References: <PqFCdTWCSge_X14Rc5aNAo2pr5uliZ9jT0iYltvef3g=.7467c1a4-ad15-48a3-a495-75b655acf69c@github.com>
 <-CKmdxtDz9PebGwjDU6XEUMukYMC9CKmW2rhm6xZKWM=.8a88e29e-7b17-4647-9848-7a5bd2927fef@github.com>
 <COfhH43wnMDmJRyZMfM1HGsmw13KyRoJnI1petdtAFU=.c4aaf2d9-abd9-4f5d-ac85-d92ea92c1f98@github.com>
 <DlbU1RvRgWn5eDTYXKRHRek6xO41mHz0qm5A0YqecBo=.8082071a-7309-40e1-afd8-4cf4d7b8858d@github.com>
Message-ID: <uXN7rpU_bJywhFrrHhPJsEkpwGOSHjCiHDh5IJUqJlM=.32f02c37-a936-44b6-8c4e-92e0d39f492e@github.com>

On Tue, 13 Jul 2021 17:05:25 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Thanks for the suggestion. I'd like to keep it the way it is though, so that the assert message contains the `has_last_frame` & `java_call_counter` values. (this was one of the reason I did this refactor as well, since the assert I was hitting out of those 3 didn't contain that info).
>
> You can keep the assert inside `verify_frame_info()` which dumps additional data. (Yes, it's a bit confusing: assert inside an assert :-) )

FTR I'm fine with it either way.

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

PR: https://git.openjdk.java.net/jdk17/pull/149

From bpb at openjdk.java.net  Tue Jul 13 17:32:24 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Tue, 13 Jul 2021 17:32:24 GMT
Subject: RFR: 8075806: divideExact is missing in java.lang.Math
Message-ID: <8nZ1xpS-Ir7KIEuaryZ0bQ2upeqcMy9TBm7-afE5lek=.22ec71c9-49d7-4994-aa1e-638c9d522510@github.com>

Please consider this proposal to add `divideExact()` methods for integral data types to `java.lang.Math` thereby rounding out "exact" support to all four basic arithmetic operations.

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

Commit messages:
 - 8075806: divideExact is missing in java.lang.Math

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

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

From asemenyuk at openjdk.java.net  Tue Jul 13 17:46:15 2021
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Tue, 13 Jul 2021 17:46:15 GMT
Subject: RFR: JDK-8269387: jpackage --add-launcher should have option to
 not create shortcuts for additional launchers [v3]
In-Reply-To: <RT-r32OmJKqm882vtWvvwNk7jyPC1-CFhBZtb9bstHQ=.0d75ac7a-816b-424c-bce9-22e0514b785f@github.com>
References: <gO8--JRs2F9hyLuR5gnanY-KYiH-wYSexmUbDGeaP0Q=.e8fa9a64-1018-427f-b1f9-72fc48671b21@github.com>
 <RT-r32OmJKqm882vtWvvwNk7jyPC1-CFhBZtb9bstHQ=.0d75ac7a-816b-424c-bce9-22e0514b785f@github.com>
Message-ID: <c0c64Bhc3iwfjXCJfjSjGPBS3XiWhIZ7N4p75J3z4Qk=.2878d4ae-9206-4826-bf0e-de055ef443fc@github.com>

On Tue, 13 Jul 2021 16:39:01 GMT, Andy Herrick <herrick at openjdk.org> wrote:

>> JDK-8269387: jpackage --add-launcher should have option to not create shortcuts for additional launchers
>
> Andy Herrick has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8269387: jpackage --add-launcher should have option to not create shortcuts for additional launchers

Changes requested by asemenyuk (Reviewer).

test/jdk/tools/jpackage/helpers/jdk/jpackage/test/AdditionalLauncher.java line 87:

> 85:         withMenuShortcut = menu;
> 86:         withShortcut = shortcut;
> 87:         if (TKit.isLinux()) {

I'd move add `addRawProperties()` calls to `initialize()` method. This will prevent multiple `addRawProperties()` calls for "linux-shortcut" and "win-shortcut" properties in case `setShortcuts()` method is called multiple times.

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

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

From vromero at openjdk.java.net  Tue Jul 13 17:52:25 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Tue, 13 Jul 2021 17:52:25 GMT
Subject: [jdk17] RFR: 8270025: DynamicCallSiteDesc::withArgs doesn't throw
 NPE [v3]
In-Reply-To: <GDhwG7YJlq-hZsixNX6a8E1DJpVv94LJnKigK8TM5r0=.bf686d9d-0ec0-468b-9c32-a4a9a38ac4ce@github.com>
References: <j7TtUsU8eNi_NXDTP7ID2tCH5pc_XsGkHcZW522eqyg=.561a4dc2-60ef-41e0-af82-1cdfc4ff21f3@github.com>
 <GDhwG7YJlq-hZsixNX6a8E1DJpVv94LJnKigK8TM5r0=.bf686d9d-0ec0-468b-9c32-a4a9a38ac4ce@github.com>
Message-ID: <rml6wLtgOa_1cLsTIdjOjAyPC5G_ORZBecwkQ3ng_Ow=.3797d18b-2c0b-42cc-813a-ecdcb2089eee@github.com>

On Mon, 12 Jul 2021 18:06:30 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Please review this PR that is fixing a mismatch between the implementation for method `java.lang.constant.DynamicCallSiteDesc::withArgs` and its implementation. I made a mistake while working on a recent CSR [JDK-8224985](https://bugs.openjdk.java.net/browse/JDK-8224985) and fixed the API but mistakenly thought that the implementation was in sync with the spec. This is why this change is also including a unit test of the API for `java.lang.constant.DynamicCallSiteDesc` modulo method `resolveCallSiteDesc` which is covered in test `IndyDescTest` in the same test suite. Also this change needs a CSR as while fixing the implementation of method `::withArgs` I realized that the API of the varargs overloaded version of method `::of` needed some rewording too as it is invoking the same private constructor `::withArgs` is invoking. So it didn't make sense for the API of one method to be more restrictive than the other. Please review also the accompanying CSR.
>> 
>> Thanks,
>> Vicente
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comments

thanks for the reviews!

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

PR: https://git.openjdk.java.net/jdk17/pull/242

From vromero at openjdk.java.net  Tue Jul 13 17:52:28 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Tue, 13 Jul 2021 17:52:28 GMT
Subject: [jdk17] Integrated: 8270025: DynamicCallSiteDesc::withArgs doesn't
 throw NPE
In-Reply-To: <j7TtUsU8eNi_NXDTP7ID2tCH5pc_XsGkHcZW522eqyg=.561a4dc2-60ef-41e0-af82-1cdfc4ff21f3@github.com>
References: <j7TtUsU8eNi_NXDTP7ID2tCH5pc_XsGkHcZW522eqyg=.561a4dc2-60ef-41e0-af82-1cdfc4ff21f3@github.com>
Message-ID: <AOq9WTOjLP3AzT_6-2Jwnzoev4_KQiAT19bD5-A4Dh4=.dee858aa-1ef6-4cbe-a5fd-966239b9c79e@github.com>

On Sat, 10 Jul 2021 19:03:36 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Please review this PR that is fixing a mismatch between the implementation for method `java.lang.constant.DynamicCallSiteDesc::withArgs` and its implementation. I made a mistake while working on a recent CSR [JDK-8224985](https://bugs.openjdk.java.net/browse/JDK-8224985) and fixed the API but mistakenly thought that the implementation was in sync with the spec. This is why this change is also including a unit test of the API for `java.lang.constant.DynamicCallSiteDesc` modulo method `resolveCallSiteDesc` which is covered in test `IndyDescTest` in the same test suite. Also this change needs a CSR as while fixing the implementation of method `::withArgs` I realized that the API of the varargs overloaded version of method `::of` needed some rewording too as it is invoking the same private constructor `::withArgs` is invoking. So it didn't make sense for the API of one method to be more restrictive than the other. Please review also the accompanying CSR.
> 
> Thanks,
> Vicente

This pull request has now been integrated.

Changeset: 8583aab3
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.java.net/jdk17/commit/8583aab374c3c2ad94c88e7f649d81ce5f319a5f
Stats:     197 lines in 2 files changed: 195 ins; 0 del; 2 mod

8270025: DynamicCallSiteDesc::withArgs doesn't throw NPE

Reviewed-by: jvernee, mchung

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

PR: https://git.openjdk.java.net/jdk17/pull/242

From bpb at openjdk.java.net  Tue Jul 13 18:32:15 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Tue, 13 Jul 2021 18:32:15 GMT
Subject: RFR: 8075806: divideExact is missing in java.lang.Math
In-Reply-To: <8nZ1xpS-Ir7KIEuaryZ0bQ2upeqcMy9TBm7-afE5lek=.22ec71c9-49d7-4994-aa1e-638c9d522510@github.com>
References: <8nZ1xpS-Ir7KIEuaryZ0bQ2upeqcMy9TBm7-afE5lek=.22ec71c9-49d7-4994-aa1e-638c9d522510@github.com>
Message-ID: <KXCqu3FGThwKft_GNhfST3gXeczBYawiOr1vDVBKNDo=.68de1fb3-5280-4596-9ecd-6d479727180f@github.com>

On Tue, 13 Jul 2021 17:21:52 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Please consider this proposal to add `divideExact()` methods for integral data types to `java.lang.Math` thereby rounding out "exact" support to all four basic arithmetic operations.

Note: The `StrictMath` equivalents were intentionally omitted until the review converges to a consensus.

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

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

From darcy at openjdk.java.net  Tue Jul 13 23:32:12 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 13 Jul 2021 23:32:12 GMT
Subject: RFR: 8211002: test/jdk/java/lang/Math/PowTests.java skips testing
 for non-corner-case values
In-Reply-To: <CTD8-ciAhD-kPjiC0ic6qbOOE3XObK7JoFCTOVpLflM=.7970b30d-a3b0-4a7f-81c0-860894d56b94@github.com>
References: <CTD8-ciAhD-kPjiC0ic6qbOOE3XObK7JoFCTOVpLflM=.7970b30d-a3b0-4a7f-81c0-860894d56b94@github.com>
Message-ID: <68WE7DbWSJuaBPba4UWiP3BFSkVK-XNHotA4UOXi98g=.6e78b5ae-a711-4212-9447-0aea7fbca515@github.com>

On Mon, 12 Jul 2021 19:39:13 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Please consider this proposal to add some test coverage comparing `Math` and `StrictMath` results of `pow()`.

test/jdk/java/lang/Math/PowTests.java line 65:

> 63:         int failures = 0;
> 64:         if (Double.isNaN(smResult)) {
> 65:             if (!Double.isNaN(mResult)) failures = 1;

Pretty sure the Tests.testUlpDiff call will handle two NaNs as well as NaN/non-NaN argument.

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

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

From darcy at openjdk.java.net  Tue Jul 13 23:40:20 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 13 Jul 2021 23:40:20 GMT
Subject: RFR: 8211002: test/jdk/java/lang/Math/PowTests.java skips testing
 for non-corner-case values
In-Reply-To: <CTD8-ciAhD-kPjiC0ic6qbOOE3XObK7JoFCTOVpLflM=.7970b30d-a3b0-4a7f-81c0-860894d56b94@github.com>
References: <CTD8-ciAhD-kPjiC0ic6qbOOE3XObK7JoFCTOVpLflM=.7970b30d-a3b0-4a7f-81c0-860894d56b94@github.com>
Message-ID: <380z1zRvLb1hfwQ59T4vAyBJpO61FbNZ64sw8Qon1M8=.9f534e29-7352-4676-a1aa-6d0da380ee97@github.com>

On Mon, 12 Jul 2021 19:39:13 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Please consider this proposal to add some test coverage comparing `Math` and `StrictMath` results of `pow()`.

test/jdk/java/lang/Math/PowTests.java line 69:

> 67:             failures += Tests.testUlpDiff(
> 68:                 "StrictMath.pow(double, double) vs Math.pow(double, double)",
> 69:                 input1, input2, mResult, smResult, 1.0

In theory at least, one pow method could round an ulp up and the other could round an ulp down so the difference should be 2 ulps (ignoring the special case of values straddling a power of two).

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

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

From jwilhelm at openjdk.java.net  Wed Jul 14 00:22:49 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Wed, 14 Jul 2021 00:22:49 GMT
Subject: RFR: Merge jdk17
Message-ID: <8R4n8NuSxB6bvN-nX-OpZ4gW1MKS-Q0B5eBNoIif7n0=.dd765279-93e5-47c9-9f1d-47e282e04e5f@github.com>

Forwardport JDK 17 -> JDK 18

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

Commit messages:
 - Merge
 - 8270025: DynamicCallSiteDesc::withArgs doesn't throw NPE
 - 8270184: [TESTBUG] Add coverage for jvmci ResolvedJavaType.toJavaName() for lambdas
 - 8269281: java/foreign/Test{Down,Up}call.java time out
 - 8269635: Stress test SEGV while emitting OldObjectSample
 - 8269525: Deadlock during Volano with JFR
 - 8259848: Interim javadoc build does not support platform links
 - 8269795: C2: Out of bounds array load floats above its range check in loop peeling resulting in SEGV
 - 8270203: Missing build dependency between jdk.jfr-gendata and buildtools-hotspot

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

Changes: https://git.openjdk.java.net/jdk/pull/4771/files
  Stats: 388 lines in 13 files changed: 322 ins; 18 del; 48 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4771.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4771/head:pull/4771

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

From yyang at openjdk.java.net  Wed Jul 14 00:49:21 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Wed, 14 Jul 2021 00:49:21 GMT
Subject: [jdk17] Integrated: 8270056: Generated lambda class can not access
 protected static method of target class
In-Reply-To: <N8VMxxFr16sfeaZs-xs5gzTjeQRWVClQ3pwsTNsf3tQ=.26197799-c262-495e-9d1a-7b0b03ddb1f3@github.com>
References: <N8VMxxFr16sfeaZs-xs5gzTjeQRWVClQ3pwsTNsf3tQ=.26197799-c262-495e-9d1a-7b0b03ddb1f3@github.com>
Message-ID: <cCNOGRpsTWLmXFj0r8Kj3S1QAOX4XwhlIWL76OU9XJI=.43489046-fb12-4354-b605-483f58c50ff3@github.com>

On Tue, 13 Jul 2021 03:06:12 GMT, Yi Yang <yyang at openjdk.org> wrote:

> Hi all,
> 
> this pull request contains a backport of commit 07e90524 from the openjdk/jdk repository.
> 
> The commit being backported was authored by Yi Yang on 13 Jul 2021 and was reviewed by Mandy Chung.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 0f547071
Author:    Yi Yang <yyang at openjdk.org>
URL:       https://git.openjdk.java.net/jdk17/commit/0f5470715e98e222474f575abc95457682d5818a
Stats:     324 lines in 3 files changed: 181 ins; 141 del; 2 mod

8270056: Generated lambda class can not access protected static method of target class

Reviewed-by: mchung
Backport-of: 07e90524576f159fc16523430f1db62327c89a3b

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

PR: https://git.openjdk.java.net/jdk17/pull/245

From mbien42 at gmail.com  Wed Jul 14 00:45:53 2021
From: mbien42 at gmail.com (Michael Bien)
Date: Wed, 14 Jul 2021 02:45:53 +0200
Subject: SplittableGenerator of JEP 356
In-Reply-To: <37006C97-8AD6-4AC7-A97D-469864B076B2@oracle.com>
References: <b1d04ced-0449-d928-f539-fd6a194f9656@gmail.com>
 <0e598ac8-1db1-aca7-8b31-b301fd3f0605@gmail.com>
 <37006C97-8AD6-4AC7-A97D-469864B076B2@oracle.com>
Message-ID: <81b168ec-d161-f864-46e0-42c7860b9528@gmail.com>

Thank you for the explanation,

This makes sense - I only wanted to bring it up in the (unlikely) case 
it was an oversight.

My thinking was that there might be a potential use case of something like:

 ??? private static final SecureRandom shared_source = new 
SecureRandom(); // thread safe source
 ??? private static final SplittableGenerator shared_splitter
 ??????????? = 
RandomGeneratorFactory.<SplittableGenerator>of("L32X64MixRandom").create();

 ??? private final RandomGenerator local_random = 
shared_splitter.split(shared_source);? // not secure but local

Which would exploit the fact that secure random is thread safe and a 
pretty good source from my understanding. This could be used when the 
contention on the source is not a big concern.

A much better (and contention free) way is to split before forking a 
task with only SplittableGenerators involved, which is probably another 
good reason to not encourage the code above by enforcing 
SplittableGenerators in the API.

best regards,
michael


On 13.07.21 18:58, Jim Laskey wrote:
>  From Guy:
>
> You are right that the comment in the JEP was a little loose, and that the implementation(s) of the split/splits methods could in principle draw random values from a RandomGenerator that is not itself splittable. There might even be applications for such functionality.
>
> However, we chose not to support that more general functionality for a fairly subtle reason: there are concerns that if a PNRG is less than perfect, using it as a source of entropy for seeding a PRNG that uses a different algorithm might result in unexpected correlations that could drastically reduce the quality of the output of the new PRNG instance. Restricting the implementation of the split method so that it always constructs a new generator of the same class has allowed us the opportunity to test each class separately and independently for quality of output when the split method is used.
>
> Programmers who know what they are doing can get the effect of the more general split functionality by calling constructors explicitly. This forces them to think about the specific algorithms. For example:
>
> RandomGenerator r = new SplittableRandom();
> RandomGenerator g = new L64X256MixRandom(r.nextLong(), r.nextLong(),
>                     r.nextLong(), r.nextLong(), r.nextLong(), r.nextLong());
>
> The programmer may then reason that, in this specific case, the fact that the period of r is only 2^64 implies that the last four values generated cannot all be zero, which is one desideratum for g to have good quality. (The programmer would also have the responsibility to decide more generally whether this particular combination of entropy source and generated instance will in fact have good quality.)
>
> ?Guy Steele
>
>
>> On Jul 13, 2021, at 11:52 AM, Michael Bien <mbien42 at gmail.com> wrote:
>>
>> just wanted to add that the JEP says: "SplittableRandomGenerator extends RandomGenerator and also provides
>> methods named split and splits. Splittability allows the user to spawn a new RandomGenerator from an existing RandomGenerator that will generally produce statistically independent results."
>>
>> which adds to my suspicion that this might be a api bug.
>>
>> -michael
>>
>> On 13.07.21 14:45, Michael Bien wrote:
>>> Hello,
>>>
>>> i was wondering if SplittableGenerator.split(SplittableGenerator source) is missing out on a potential usecase when the source itself is not splittable. The implementation looks like it only requires basic calls which could be also provided by the RandomGenerator interface as source.
>>>
>>> best regards,
>>>
>>> michael
>>>


From dholmes at openjdk.java.net  Wed Jul 14 01:01:15 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 14 Jul 2021 01:01:15 GMT
Subject: [jdk17] RFR: 8269240:
 java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC
 [v2]
In-Reply-To: <o-O6F0omoRjgCjD28Ir79_QYw2xdT_1SlIu2h0eLqH0=.a9e4053d-4464-40de-94df-39fc98e4eaaf@github.com>
References: <PqFCdTWCSge_X14Rc5aNAo2pr5uliZ9jT0iYltvef3g=.7467c1a4-ad15-48a3-a495-75b655acf69c@github.com>
 <o-O6F0omoRjgCjD28Ir79_QYw2xdT_1SlIu2h0eLqH0=.a9e4053d-4464-40de-94df-39fc98e4eaaf@github.com>
Message-ID: <e7gBayKnokRzWTDb2LQFrP8eikV-UrRN_Y0JGCzY55w=.962eb647-c232-47b5-95c2-4844d8a36204@github.com>

On Tue, 13 Jul 2021 15:16:26 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> This patch rewrites the prologue and epilogue of panama upcalls, in order to fix the test failure from the title.
>> 
>> Previously, we did a call to potentially attach the current thread to the VM, and then afterwards did the same suspend and stack reguard checks that we do on the back-edge of a native downcall. Then, on the back edge of the upcall we did another conditional call to detach the thread.
>> 
>> The suspend and reguard checks on the front-edge are incorrect, so I've changed the 2 calls to mimic what is done by JavaCallWrapper instead (with attach and detach included), and removed the old suspend and stack reguard checks.
>> 
>> FWIW, this removes the JavaFrameAnchor save/restore MacroAssembler code. This is now written in C++. Also, MacroAssembler code was added to save/restore the result of the upcall around the call on the back-edge, which was previously missing. Since the new code allocates a handle block as well, I've added handling for those oops to frame & OptimizedUpcallBlob.
>> 
>> Testing: local running of `jdk_foreign` on Windows and Linux (WSL). Tier 1-3
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Assert frame is correct type in frame_data_for_frame

Hi Jorn,

I can't comment on all the details here - especially in the x86_64 upcall handler code. The mapping to JavaCallWrapper seems reasonable but there are a few differences that I'm now assuming stem from the fact upcalls start _thread_in_native while JCW starts from _thread_in_vm?

Some minor comments and queries below (mostly issues with existing code that you copied).

Thanks,
David

src/hotspot/share/prims/universalUpcallHandler.cpp line 76:

> 74: 
> 75: // modelled after JavaCallWrapper::JavaCallWrapper
> 76: Thread* ProgrammableUpcallHandler::on_entry(OptimizedEntryBlob::FrameData* context) {

This should return JavaThread not Thread.

src/hotspot/share/prims/universalUpcallHandler.cpp line 77:

> 75: // modelled after JavaCallWrapper::JavaCallWrapper
> 76: Thread* ProgrammableUpcallHandler::on_entry(OptimizedEntryBlob::FrameData* context) {
> 77:   JavaThread* thread = maybe_attach_and_get_thread(&context->should_detach)->as_Java_thread();

Nit: if `maybe_attach_and_get_thread` has to return a JavaThread it should be typed to return a JavaThread.

src/hotspot/share/prims/universalUpcallHandler.cpp line 86:

> 84:   context->new_handles = JNIHandleBlock::allocate_block(thread);
> 85: 
> 86:   // After this, we are official in Java Code. This needs to be done before we change any of the thread local

typo: s/official/officially/
(I see this was copied from Javacalls)

src/hotspot/share/prims/universalUpcallHandler.cpp line 92:

> 90:   // Make sure that we handle asynchronous stops and suspends _before_ we clear all thread state
> 91:   // in OptimizedEntryBlob::FrameData. This way, we can decide if we need to do any pd actions
> 92:   // to prepare for stop/suspend (flush register windows on sparcs, cache sp, or other state).

No sparcs any more (again I see this was copied from Javacalls)

src/hotspot/share/prims/universalUpcallHandler.cpp line 114:

> 112:   thread->set_active_handles(context->new_handles);     // install new handle block and reset Java frame linkage
> 113: 
> 114:   assert (thread->thread_state() != _thread_in_native, "cannot set native pc to NULL");

You transitioned to _thread_in_Java above so how can you possibly have changed state again ?? (okay again copied from javaCalls ...)

src/hotspot/share/prims/universalUpcallHandler.cpp line 117:

> 115: 
> 116:   // clear any pending exception in thread (native calls start with no exception pending)
> 117:   if(clear_pending_exception) {

Nit: space after 'if'

src/hotspot/share/prims/universalUpcallHandler.cpp line 121:

> 119:   }
> 120: 
> 121:   MACOS_AARCH64_ONLY(thread->enable_wx(WXExec));

Not clear why this is needed? JavaCallWrapper doesn't use it.

src/hotspot/share/prims/universalUpcallHandler.cpp line 146:

> 144:   // Do this after the transition because this allows us to put an assert
> 145:   // the Java->native transition which checks to see that stack is not walkable
> 146:   // on sparc/ia64 which will catch violations of the reseting of last_Java_frame

Again archaic comment copied across :)

src/hotspot/share/runtime/thread.cpp line 1972:

> 1970:          (has_last_Java_frame() && java_call_counter() > 0),
> 1971:          "unexpected frame info: has_last_frame=%d, java_call_counter=%d",
> 1972:          has_last_Java_frame(), java_call_counter());

I see this was relocated code, but as has_last_java_frame() returns bool, it shouldn't be treated as an int without a cast (or better use %s and report true or false).

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

PR: https://git.openjdk.java.net/jdk17/pull/149

From dholmes at openjdk.java.net  Wed Jul 14 01:01:16 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 14 Jul 2021 01:01:16 GMT
Subject: [jdk17] RFR: 8269240:
 java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC
 [v2]
In-Reply-To: <ebTR3Fg3FnrWIJX847RkbgTBN0Ma9rWbdyVR8WR0dhs=.349b6255-e6c7-46d8-b2df-8cd4d4dd13e8@github.com>
References: <PqFCdTWCSge_X14Rc5aNAo2pr5uliZ9jT0iYltvef3g=.7467c1a4-ad15-48a3-a495-75b655acf69c@github.com>
 <ebTR3Fg3FnrWIJX847RkbgTBN0Ma9rWbdyVR8WR0dhs=.349b6255-e6c7-46d8-b2df-8cd4d4dd13e8@github.com>
Message-ID: <VW5GuwT6ccFopn__J_mIvIBaso53uR8i81DtuEh2AuM=.a5adb7ea-7a24-41d5-a1d0-cd972792dad6@github.com>

On Fri, 25 Jun 2021 21:04:27 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Assert frame is correct type in frame_data_for_frame
>
> src/hotspot/share/runtime/safepoint.cpp line 931:
> 
>> 929:     // See if return type is an oop.
>> 930:     bool return_oop = nm->method()->is_returning_oop();
>> 931:     HandleMark hm(self);
> 
> I was seeing an `assert(_handle_mark_nesting > 1) failed: memory leak: allocating handle outside HandleMark` when the existing code allocates the Handle for `return_value` in the code down below. It seems to be a simple case of a missing handle mark, so I've added it here. (looking at the stack trace in the error log, the caller frame is native code, so I don't think we can expect the caller to have a HandleMark).

How does native code reach a safepoint polling point?

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

PR: https://git.openjdk.java.net/jdk17/pull/149

From jwilhelm at openjdk.java.net  Wed Jul 14 01:10:29 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Wed, 14 Jul 2021 01:10:29 GMT
Subject: Integrated: Merge jdk17
In-Reply-To: <8R4n8NuSxB6bvN-nX-OpZ4gW1MKS-Q0B5eBNoIif7n0=.dd765279-93e5-47c9-9f1d-47e282e04e5f@github.com>
References: <8R4n8NuSxB6bvN-nX-OpZ4gW1MKS-Q0B5eBNoIif7n0=.dd765279-93e5-47c9-9f1d-47e282e04e5f@github.com>
Message-ID: <5EuAHb-D3XlzTzriaMpMRYvuN7F7Rsga91-2nbN_X1s=.639bf5f5-df8a-4dbf-bd9c-efe2b21a5cbe@github.com>

On Wed, 14 Jul 2021 00:13:41 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 17 -> JDK 18

This pull request has now been integrated.

Changeset: 4a7ccf36
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/4a7ccf36e9a3978c437db3efe892dd23e8a0b772
Stats:     388 lines in 13 files changed: 322 ins; 18 del; 48 mod

Merge

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

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

From ngasson at openjdk.java.net  Wed Jul 14 08:51:14 2021
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Wed, 14 Jul 2021 08:51:14 GMT
Subject: RFR: 8268231: Aarch64: Use ldp in intrinsics for String.compareTo
 [v3]
In-Reply-To: <B4QlLNxlUxwMUmJjgZG6e82vGN2tlnJeKsQ_1QCNlOE=.b99f2103-318f-40f1-89d6-1069dc0ba22d@github.com>
References: <XwW4MjGSYmSHa2ZbzrOfvoZi1pe8LJAK7YIKtmNhaDM=.d39df32e-8698-4608-9184-3b19cd175d1a@github.com>
 <B4QlLNxlUxwMUmJjgZG6e82vGN2tlnJeKsQ_1QCNlOE=.b99f2103-318f-40f1-89d6-1069dc0ba22d@github.com>
Message-ID: <nulsSsZPVaoQA13GVqYV0_3EY7duVRYPkz-vhZBfibg=.fc7a36e3-0f29-4a7e-91cc-141f9f82365a@github.com>

On Tue, 13 Jul 2021 07:37:31 GMT, Wang Huang <whuang at openjdk.org> wrote:

>> Dear all, 
>>     Can you do me a favor to review this patch. This patch use `ldp` to implement String.compareTo.
>>    
>> * We add a JMH test case 
>> * Here is the result of this test case
>>  
>> Benchmark	                       |(size)| Mode| Cnt|Score | Error	 |Units	
>> ---------------------------------|------|-----|----|------|--------|-----
>> StringCompare.compareLL       |  64  | avgt| 5  |7.992 | ?	0.005|us/op
>> StringCompare.compareLL       |  72  | avgt| 5  |15.029| ?	0.006|us/op
>> StringCompare.compareLL       |  80  | avgt| 5  |14.655| ?	0.011|us/op
>> StringCompare.compareLL       |  91  | avgt| 5  |16.363| ?	0.12 |us/op
>> StringCompare.compareLL       |  101 | avgt| 5  |16.966| ?	0.007|us/op
>> StringCompare.compareLL       |  121 | avgt| 5  |19.276| ?	0.006|us/op
>> StringCompare.compareLL       |  181 | avgt| 5  |19.002| ?	0.417|us/op
>> StringCompare.compareLL       |  256 | avgt| 5  |24.707| ?	0.041|us/op
>> StringCompare.compareLLWithLdp|  64  | avgt| 5  |8.001	| ?	0.121|us/op
>> StringCompare.compareLLWithLdp|  72  | avgt| 5  |11.573| ?	0.003|us/op
>> StringCompare.compareLLWithLdp|  80  | avgt| 5  |6.861 | ?	0.004|us/op
>> StringCompare.compareLLWithLdp|  91  | avgt| 5  |12.774| ?	0.201|us/op
>> StringCompare.compareLLWithLdp|  101 | avgt| 5  |8.691 | ?	0.004|us/op
>> StringCompare.compareLLWithLdp|  121 | avgt| 5  |11.091| ?	1.342|us/op
>> StringCompare.compareLLWithLdp|  181 | avgt| 5  |14.64 | ?	0.581|us/op
>> StringCompare.compareLLWithLdp|  256 | avgt| 5  |25.879| ?	1.775|us/op
>> StringCompare.compareUU       |  64  | avgt| 5  |13.476| ?	0.01 |us/op
>> StringCompare.compareUU       |  72  | avgt| 5  |15.078| ?	0.006|us/op
>> StringCompare.compareUU       |  80  | avgt| 5  |23.512| ?	0.011|us/op
>> StringCompare.compareUU       |  91  | avgt| 5  |24.284| ?	0.008|us/op
>> StringCompare.compareUU       |  101 | avgt| 5  |20.707| ?	0.017|us/op
>> StringCompare.compareUU       |  121 | avgt| 5  |29.302| ?	0.011|us/op
>> StringCompare.compareUU       |  181 | avgt| 5  |39.31	| ?	0.016|us/op
>> StringCompare.compareUU       |  256 | avgt| 5  |54.592| ?	0.392|us/op
>> StringCompare.compareUUWithLdp|  64  | avgt| 5  |16.389| ?	0.008|us/op
>> StringCompare.compareUUWithLdp|  72  | avgt| 5  |10.71 | ?	0.158|us/op
>> StringCompare.compareUUWithLdp|  80  | avgt| 5  |11.488| ?	0.024|us/op
>> StringCompare.compareUUWithLdp|  91  | avgt| 5  |13.412| ?	0.006|us/op
>> StringCompare.compareUUWithLdp|  101 | avgt| 5  |16.245| ?	0.434|us/op
>> StringCompare.compareUUWithLdp|  121 | avgt| 5  |16.597| ?	0.016|us/op
>> StringCompare.compareUUWithLdp|  181 | avgt| 5  |27.373| ?	0.017|us/op
>> StringCompare.compareUUWithLdp|  256 | avgt| 5  |41.74 | ?	3.5	 |us/op
>> 
>> From this table, we can see that in most cases, our patch is better than old one.
>> 
>> Thank you for your review. Any suggestions are welcome.
>
> Wang Huang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   refact codes

Have you tested when the data in the `byte[]` array is not 16B aligned? With the default JVM options the array data naturally starts 16B into the object, but you can force a different alignment with e.g. `-XX:-UseCompressedClassPointers`. I tried that on N1 and it's very slightly slower than with the 16B alignment, but still faster than the non-LDP version for length 1024 strings. On A72 the difference is a bit bigger but again faster than non-LDP.

N1, -UseCompressedClassPointers


Benchmark                                  (diff_pos)  (size)  Mode  Cnt    Score   Error  Units
StringCompare.compareLLDiffStrings               1023    1024  avgt    5   67.789 ? 0.095  us/op
StringCompare.compareLLDiffStringsWithLdp        1023    1024  avgt    5   45.912 ? 0.059  us/op
StringCompare.compareUUDiffStrings               1023    1024  avgt    5  133.365 ? 0.086  us/op
StringCompare.compareUUDiffStringsWithLdp        1023    1024  avgt    5   89.009 ? 0.312  us/op


N1, +UseCompressedClassPointers


Benchmark                                  (diff_pos)  (size)  Mode  Cnt    Score   Error  Units
StringCompare.compareLLDiffStrings               1023    1024  avgt    5   67.878 ? 0.156  us/op
StringCompare.compareLLDiffStringsWithLdp        1023    1024  avgt    5   46.487 ? 0.115  us/op
StringCompare.compareUUDiffStrings               1023    1024  avgt    5  133.576 ? 0.111  us/op
StringCompare.compareUUDiffStringsWithLdp        1023    1024  avgt    5   90.462 ? 0.176  us/op


A72, -UseCompressedClassPointers


Benchmark                                  (diff_pos)  (size)  Mode  Cnt    Score   Error  Units
StringCompare.compareLLDiffStrings               1023    1024  avgt    5  122.697 ? 0.235  us/op
StringCompare.compareLLDiffStringsWithLdp        1023    1024  avgt    5   73.883 ? 0.136  us/op
StringCompare.compareUUDiffStrings               1023    1024  avgt    5  243.022 ? 0.457  us/op
StringCompare.compareUUDiffStringsWithLdp        1023    1024  avgt    5  150.659 ? 0.313  us/op


A72, +UseCompressedClassPointers


Benchmark                                  (diff_pos)  (size)  Mode  Cnt    Score   Error  Units
StringCompare.compareLLDiffStrings               1023    1024  avgt    5  122.754 ? 0.563  us/op
StringCompare.compareLLDiffStringsWithLdp        1023    1024  avgt    5   68.513 ? 0.282  us/op
StringCompare.compareUUDiffStrings               1023    1024  avgt    5  243.043 ? 0.882  us/op
StringCompare.compareUUDiffStringsWithLdp        1023    1024  avgt    5  139.152 ? 0.333  us/op

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 4966:

> 4964: 
> 4965:     __ bind(LESS8);                          // directly load last 8 bytes
> 4966:     if(!isLL) {

The indentation of the `if` seems wrong here: shouldn't it line up with the assembly block like the `if` on line 4989? Also needs a space before the parenthesis.

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 4990:

> 4988:       __ lsrv(tmp2, tmp2, rscratch2);
> 4989:       if (isLL) {
> 4990:           __ uxtbw(tmp1, tmp1);

Convention is to indent with two spaces but have four here.

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

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

From eliu at openjdk.java.net  Wed Jul 14 10:01:20 2021
From: eliu at openjdk.java.net (Eric Liu)
Date: Wed, 14 Jul 2021 10:01:20 GMT
Subject: RFR: 8266054: VectorAPI rotate operation optimization [v9]
In-Reply-To: <NISLS29-RSnN4cZqyhx20Eou9qH2JFhD7UTmvO8pCGU=.79dcc9ed-4a6c-4bba-bac4-7923bd1cf230@github.com>
References: <OZ2u4DDNaYF3WiR5uU6NWvzPMKV3j8QAO_mZyLP3Isg=.594e3514-8a5a-442c-ac1a-ca6c6d14e963@github.com>
 <NISLS29-RSnN4cZqyhx20Eou9qH2JFhD7UTmvO8pCGU=.79dcc9ed-4a6c-4bba-bac4-7923bd1cf230@github.com>
Message-ID: <CAPS3SDcBttIB9NQaZXobZhVPKgyJWr3xc723XKFWv0=.0470cd42-1ade-45ad-bc02-f457b152d3a1@github.com>

On Wed, 30 Jun 2021 11:02:41 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Current VectorAPI Java side implementation expresses rotateLeft and rotateRight operation using following operations:-
>> 
>>     vec1 = lanewise(VectorOperators.LSHL, n)
>>     vec2 = lanewise(VectorOperators.LSHR, n)
>>     res = lanewise(VectorOperations.OR, vec1 , vec2)
>> 
>> This patch moves above handling from Java side to C2 compiler which facilitates dismantling the rotate operation if target ISA does not support a direct rotate instruction.
>> 
>> AVX512 added vector rotate instructions vpro[rl][v][dq] which operate over long and integer type vectors. For other cases (i.e. sub-word type vectors or for targets which do not support direct rotate operations )   instruction sequence comprising of vector SHIFT (LEFT/RIGHT) and vector OR is emitted.
>> 
>> Please find below the performance data for included JMH benchmark.
>> Machine:  Cascade Lake Server (Intel(R) Xeon(R) Platinum 8280 CPU @ 2.70GHz)
>> 
>> 
>> Benchmark | (TESTSIZE) | Shift | Baseline AVX3 (ops/ms) | Withopt? AVX3 (ops/ms) | Gain % | Baseline AVX2 (ops/ms) | Withopt AVX2 (ops/ms) | Gain %
>> -- | -- | -- | -- | -- | -- | -- | -- | --
>> ? | ? | ? | ? | ? | ? | ? | ? | ?
>> RotateBenchmark.testRotateLeftB | 128.00 | 7.00 | 17223.35 | 17094.69 | -0.75 | 17008.32 | 17488.06 | 2.82
>> RotateBenchmark.testRotateLeftB | 128.00 | 7.00 | 8944.98 | 8811.34 | -1.49 | 8878.17 | 9218.68 | 3.84
>> RotateBenchmark.testRotateLeftB | 128.00 | 15.00 | 17195.75 | 17137.32 | -0.34 | 16789.01 | 17780.34 | 5.90
>> RotateBenchmark.testRotateLeftB | 128.00 | 15.00 | 9052.67 | 8838.60 | -2.36 | 8814.62 | 9206.01 | 4.44
>> RotateBenchmark.testRotateLeftB | 128.00 | 31.00 | 17100.19 | 16950.64 | -0.87 | 16827.73 | 17720.37 | 5.30
>> RotateBenchmark.testRotateLeftB | 128.00 | 31.00 | 9079.95 | 8471.26 | -6.70 | 8888.44 | 9167.68 | 3.14
>> RotateBenchmark.testRotateLeftB | 256.00 | 7.00 | 21231.33 | 21513.08 | 1.33 | 21824.51 | 21479.48 | -1.58
>> RotateBenchmark.testRotateLeftB | 256.00 | 7.00 | 11103.62 | 11180.16 | 0.69 | 11173.67 | 11529.22 | 3.18
>> RotateBenchmark.testRotateLeftB | 256.00 | 15.00 | 21119.14 | 21552.04 | 2.05 | 21693.05 | 21915.37 | 1.02
>> RotateBenchmark.testRotateLeftB | 256.00 | 15.00 | 11048.68 | 11094.20 | 0.41 | 11049.90 | 11439.07 | 3.52
>> RotateBenchmark.testRotateLeftB | 256.00 | 31.00 | 21506.31 | 21391.41 | -0.53 | 21263.18 | 21986.29 | 3.40
>> RotateBenchmark.testRotateLeftB | 256.00 | 31.00 | 11056.12 | 11232.78 | 1.60 | 10941.59 | 11397.09 | 4.16
>> RotateBenchmark.testRotateLeftB | 512.00 | 7.00 | 17976.56 | 18180.85 | 1.14 | 1212.26 | 2533.34 | 108.98
>> RotateBenchmark.testRotateLeftB | 512.00 | 15.00 | 17553.70 | 18219.07 | 3.79 | 1256.73 | 2537.41 | 101.91
>> RotateBenchmark.testRotateLeftB | 512.00 | 31.00 | 17618.03 | 17738.15 | 0.68 | 1214.69 | 2533.83 | 108.60
>> RotateBenchmark.testRotateLeftI | 128.00 | 7.00 | 7258.87 | 7468.88 | 2.89 | 7115.12 | 7117.26 | 0.03
>> RotateBenchmark.testRotateLeftI | 128.00 | 7.00 | 3586.65 | 3950.85 | 10.15 | 3532.17 | 3595.80 | 1.80
>> RotateBenchmark.testRotateLeftI | 128.00 | 7.00 | 1835.07 | 1999.68 | 8.97 | 1789.90 | 1819.93 | 1.68
>> RotateBenchmark.testRotateLeftI | 128.00 | 15.00 | 7273.36 | 7410.91 | 1.89 | 7198.60 | 6994.79 | -2.83
>> RotateBenchmark.testRotateLeftI | 128.00 | 15.00 | 3674.98 | 3926.27 | 6.84 | 3549.90 | 3755.09 | 5.78
>> RotateBenchmark.testRotateLeftI | 128.00 | 15.00 | 1840.94 | 1882.25 | 2.24 | 1801.56 | 1872.89 | 3.96
>> RotateBenchmark.testRotateLeftI | 128.00 | 31.00 | 7457.11 | 7361.48 | -1.28 | 6975.33 | 7385.94 | 5.89
>> RotateBenchmark.testRotateLeftI | 128.00 | 31.00 | 3570.74 | 3929.30 | 10.04 | 3635.37 | 3736.67 | 2.79
>> RotateBenchmark.testRotateLeftI | 128.00 | 31.00 | 1902.32 | 1960.46 | 3.06 | 1812.32 | 1813.88 | 0.09
>> RotateBenchmark.testRotateLeftI | 256.00 | 7.00 | 11174.24 | 12044.52 | 7.79 | 11509.87 | 11273.44 | -2.05
>> RotateBenchmark.testRotateLeftI | 256.00 | 7.00 | 5981.47 | 6073.70 | 1.54 | 5593.66 | 5661.93 | 1.22
>> RotateBenchmark.testRotateLeftI | 256.00 | 7.00 | 2932.49 | 3069.54 | 4.67 | 2950.86 | 2892.42 | -1.98
>> RotateBenchmark.testRotateLeftI | 256.00 | 15.00 | 11764.11 | 12098.63 | 2.84 | 11069.52 | 11476.93 | 3.68
>> RotateBenchmark.testRotateLeftI | 256.00 | 15.00 | 5855.20 | 6080.40 | 3.85 | 5919.11 | 5607.04 | -5.27
>> RotateBenchmark.testRotateLeftI | 256.00 | 15.00 | 2989.05 | 3048.56 | 1.99 | 2902.63 | 2821.83 | -2.78
>> RotateBenchmark.testRotateLeftI | 256.00 | 31.00 | 11652.84 | 11965.40 | 2.68 | 11525.62 | 11459.83 | -0.57
>> RotateBenchmark.testRotateLeftI | 256.00 | 31.00 | 5851.82 | 6164.94 | 5.35 | 5882.60 | 5842.30 | -0.69
>> RotateBenchmark.testRotateLeftI | 256.00 | 31.00 | 3015.99 | 3043.79 | 0.92 | 2963.71 | 2947.97 | -0.53
>> RotateBenchmark.testRotateLeftI | 512.00 | 7.00 | 16029.15 | 16189.79 | 1.00 | 860.43 | 2339.32 | 171.88
>> RotateBenchmark.testRotateLeftI | 512.00 | 7.00 | 8078.25 | 8081.84 | 0.04 | 427.39 | 1147.92 | 168.59
>> RotateBenchmark.testRotateLeftI | 512.00 | 7.00 | 4021.49 | 4294.03 | 6.78 | 209.25 | 582.28 | 178.27
>> RotateBenchmark.testRotateLeftI | 512.00 | 15.00 | 15912.98 | 16329.03 | 2.61 | 848.23 | 2296.78 | 170.77
>> RotateBenchmark.testRotateLeftI | 512.00 | 15.00 | 8054.10 | 8306.37 | 3.13 | 429.93 | 1146.90 | 166.77
>> RotateBenchmark.testRotateLeftI | 512.00 | 15.00 | 4102.58 | 4071.08 | -0.77 | 217.86 | 582.20 | 167.24
>> RotateBenchmark.testRotateLeftI | 512.00 | 31.00 | 16177.79 | 16287.85 | 0.68 | 857.84 | 2243.15 | 161.49
>> RotateBenchmark.testRotateLeftI | 512.00 | 31.00 | 8187.47 | 8410.48 | 2.72 | 434.60 | 1128.20 | 159.60
>> RotateBenchmark.testRotateLeftI | 512.00 | 31.00 | 4109.15 | 4233.80 | 3.03 | 208.71 | 572.43 | 174.27
>> RotateBenchmark.testRotateLeftL | 128.00 | 7.00 | 3755.09 | 3930.29 | 4.67 | 3604.19 | 3598.47 | -0.16
>> RotateBenchmark.testRotateLeftL | 128.00 | 7.00 | 1829.03 | 1957.39 | 7.02 | 1833.95 | 1808.38 | -1.39
>> RotateBenchmark.testRotateLeftL | 128.00 | 7.00 | 915.35 | 970.55 | 6.03 | 916.25 | 899.08 | -1.87
>> RotateBenchmark.testRotateLeftL | 128.00 | 15.00 | 3664.85 | 3812.26 | 4.02 | 3629.37 | 3579.23 | -1.38
>> RotateBenchmark.testRotateLeftL | 128.00 | 15.00 | 1829.51 | 1877.76 | 2.64 | 1781.05 | 1807.57 | 1.49
>> RotateBenchmark.testRotateLeftL | 128.00 | 15.00 | 913.37 | 953.42 | 4.38 | 912.26 | 908.73 | -0.39
>> RotateBenchmark.testRotateLeftL | 128.00 | 31.00 | 3648.45 | 3899.20 | 6.87 | 3552.67 | 3581.04 | 0.80
>> RotateBenchmark.testRotateLeftL | 128.00 | 31.00 | 1816.50 | 1959.68 | 7.88 | 1820.88 | 1819.71 | -0.06
>> RotateBenchmark.testRotateLeftL | 128.00 | 31.00 | 901.05 | 955.13 | 6.00 | 913.74 | 907.90 | -0.64
>> RotateBenchmark.testRotateLeftL | 256.00 | 7.00 | 5850.99 | 6108.64 | 4.40 | 5882.65 | 5755.21 | -2.17
>> RotateBenchmark.testRotateLeftL | 256.00 | 7.00 | 2962.21 | 3060.47 | 3.32 | 2955.20 | 2909.18 | -1.56
>> RotateBenchmark.testRotateLeftL | 256.00 | 7.00 | 1480.46 | 1534.72 | 3.66 | 1467.78 | 1430.60 | -2.53
>> RotateBenchmark.testRotateLeftL | 256.00 | 15.00 | 5858.23 | 6047.51 | 3.23 | 5770.02 | 5773.19 | 0.05
>> RotateBenchmark.testRotateLeftL | 256.00 | 15.00 | 2951.49 | 3096.53 | 4.91 | 2885.21 | 2899.31 | 0.49
>> RotateBenchmark.testRotateLeftL | 256.00 | 15.00 | 1486.26 | 1527.94 | 2.80 | 1441.93 | 1454.25 | 0.85
>> RotateBenchmark.testRotateLeftL | 256.00 | 31.00 | 5873.21 | 6089.75 | 3.69 | 5767.58 | 5664.11 | -1.79
>> RotateBenchmark.testRotateLeftL | 256.00 | 31.00 | 2969.67 | 3081.39 | 3.76 | 2878.50 | 2905.86 | 0.95
>> RotateBenchmark.testRotateLeftL | 256.00 | 31.00 | 1452.21 | 1520.03 | 4.67 | 1430.30 | 1485.63 | 3.87
>> RotateBenchmark.testRotateLeftL | 512.00 | 7.00 | 8088.65 | 8443.63 | 4.39 | 455.67 | 1226.33 | 169.13
>> RotateBenchmark.testRotateLeftL | 512.00 | 7.00 | 4011.95 | 4120.25 | 2.70 | 229.77 | 619.87 | 169.77
>> RotateBenchmark.testRotateLeftL | 512.00 | 7.00 | 2090.57 | 2109.53 | 0.91 | 115.21 | 310.36 | 169.37
>> RotateBenchmark.testRotateLeftL | 512.00 | 15.00 | 8166.84 | 8557.28 | 4.78 | 457.67 | 1242.86 | 171.56
>> RotateBenchmark.testRotateLeftL | 512.00 | 15.00 | 4137.02 | 4287.95 | 3.65 | 227.26 | 624.80 | 174.93
>> RotateBenchmark.testRotateLeftL | 512.00 | 15.00 | 2095.01 | 2102.86 | 0.37 | 114.26 | 310.83 | 172.03
>> RotateBenchmark.testRotateLeftL | 512.00 | 31.00 | 8082.68 | 8400.56 | 3.93 | 459.59 | 1230.07 | 167.64
>> RotateBenchmark.testRotateLeftL | 512.00 | 31.00 | 4047.67 | 4147.58 | 2.47 | 229.01 | 606.38 | 164.78
>> RotateBenchmark.testRotateLeftL | 512.00 | 31.00 | 2086.83 | 2126.72 | 1.91 | 111.93 | 305.66 | 173.08
>> RotateBenchmark.testRotateLeftS | 128.00 | 7.00 | 13597.19 | 13255.09 | -2.52 | 13818.39 | 13242.40 | -4.17
>> RotateBenchmark.testRotateLeftS | 128.00 | 7.00 | 7028.26 | 6826.59 | -2.87 | 6765.15 | 6907.87 | 2.11
>> RotateBenchmark.testRotateLeftS | 128.00 | 7.00 | 3570.40 | 3468.01 | -2.87 | 3449.66 | 3533.50 | 2.43
>> RotateBenchmark.testRotateLeftS | 128.00 | 15.00 | 13615.99 | 13464.40 | -1.11 | 13330.02 | 13870.57 | 4.06
>> RotateBenchmark.testRotateLeftS | 128.00 | 15.00 | 7043.31 | 6763.34 | -3.97 | 6928.88 | 7063.57 | 1.94
>> RotateBenchmark.testRotateLeftS | 128.00 | 15.00 | 3495.12 | 3537.62 | 1.22 | 3503.41 | 3457.67 | -1.31
>> RotateBenchmark.testRotateLeftS | 128.00 | 31.00 | 13591.66 | 13665.84 | 0.55 | 13773.27 | 13126.08 | -4.70
>> RotateBenchmark.testRotateLeftS | 128.00 | 31.00 | 7027.08 | 7011.24 | -0.23 | 6974.98 | 6815.50 | -2.29
>> RotateBenchmark.testRotateLeftS | 128.00 | 31.00 | 3568.28 | 3569.62 | 0.04 | 3580.67 | 3463.58 | -3.27
>> RotateBenchmark.testRotateLeftS | 256.00 | 7.00 | 21154.03 | 21416.32 | 1.24 | 21187.01 | 21401.61 | 1.01
>> RotateBenchmark.testRotateLeftS | 256.00 | 7.00 | 11194.24 | 10865.47 | -2.94 | 11063.19 | 10977.60 | -0.77
>> RotateBenchmark.testRotateLeftS | 256.00 | 7.00 | 5797.80 | 5523.94 | -4.72 | 5654.63 | 5468.78 | -3.29
>> RotateBenchmark.testRotateLeftS | 256.00 | 15.00 | 21333.89 | 21412.74 | 0.37 | 21610.94 | 20908.96 | -3.25
>> RotateBenchmark.testRotateLeftS | 256.00 | 15.00 | 11327.07 | 11113.48 | -1.89 | 11148.25 | 10678.14 | -4.22
>> RotateBenchmark.testRotateLeftS | 256.00 | 15.00 | 5810.69 | 5569.72 | -4.15 | 5663.26 | 5618.87 | -0.78
>> RotateBenchmark.testRotateLeftS | 256.00 | 31.00 | 21753.20 | 21198.43 | -2.55 | 21567.90 | 21929.81 | 1.68
>> RotateBenchmark.testRotateLeftS | 256.00 | 31.00 | 11517.08 | 11039.64 | -4.15 | 11103.08 | 10871.59 | -2.08
>> RotateBenchmark.testRotateLeftS | 256.00 | 31.00 | 5897.16 | 5606.75 | -4.92 | 5459.87 | 5604.12 | 2.64
>> RotateBenchmark.testRotateLeftS | 512.00 | 7.00 | 29748.53 | 28883.73 | -2.91 | 1549.02 | 3928.53 | 153.61
>> RotateBenchmark.testRotateLeftS | 512.00 | 7.00 | 15197.09 | 15878.19 | 4.48 | 772.59 | 1924.35 | 149.08
>> RotateBenchmark.testRotateLeftS | 512.00 | 7.00 | 8046.30 | 8081.19 | 0.43 | 388.11 | 990.28 | 155.16
>> RotateBenchmark.testRotateLeftS | 512.00 | 15.00 | 30618.04 | 29419.19 | -3.92 | 1524.22 | 3915.97 | 156.92
>> RotateBenchmark.testRotateLeftS | 512.00 | 15.00 | 15854.43 | 15846.37 | -0.05 | 766.09 | 1953.60 | 155.01
>> RotateBenchmark.testRotateLeftS | 512.00 | 15.00 | 7814.77 | 7899.30 | 1.08 | 390.82 | 970.37 | 148.29
>> RotateBenchmark.testRotateLeftS | 512.00 | 31.00 | 29596.82 | 28538.69 | -3.58 | 1530.45 | 3906.91 | 155.28
>> RotateBenchmark.testRotateLeftS | 512.00 | 31.00 | 15662.48 | 15849.25 | 1.19 | 778.08 | 1934.31 | 148.60
>> RotateBenchmark.testRotateLeftS | 512.00 | 31.00 | 8121.14 | 7758.59 | -4.46 | 392.78 | 959.73 | 144.34
>> RotateBenchmark.testRotateRightB | 128.00 | 7.00 | 17465.84 | 17069.34 | -2.27 | 16849.73 | 17842.08 | 5.89
>> RotateBenchmark.testRotateRightB | 128.00 | 7.00 | 9049.19 | 8864.15 | -2.04 | 8786.67 | 9105.34 | 3.63
>> RotateBenchmark.testRotateRightB | 128.00 | 15.00 | 17703.38 | 17070.98 | -3.57 | 16595.85 | 17784.68 | 7.16
>> RotateBenchmark.testRotateRightB | 128.00 | 15.00 | 9007.68 | 8817.41 | -2.11 | 8704.49 | 9185.87 | 5.53
>> RotateBenchmark.testRotateRightB | 128.00 | 31.00 | 17531.05 | 16983.40 | -3.12 | 16947.69 | 17655.40 | 4.18
>> RotateBenchmark.testRotateRightB | 128.00 | 31.00 | 8986.30 | 8794.15 | -2.14 | 8816.62 | 9225.95 | 4.64
>> RotateBenchmark.testRotateRightB | 256.00 | 7.00 | 21293.95 | 21506.74 | 1.00 | 21163.29 | 21854.03 | 3.26
>> RotateBenchmark.testRotateRightB | 256.00 | 7.00 | 11258.47 | 11072.92 | -1.65 | 11118.12 | 11338.96 | 1.99
>> RotateBenchmark.testRotateRightB | 256.00 | 15.00 | 21253.36 | 21292.37 | 0.18 | 21224.39 | 21763.88 | 2.54
>> RotateBenchmark.testRotateRightB | 256.00 | 15.00 | 11064.80 | 11198.35 | 1.21 | 10960.98 | 11294.14 | 3.04
>> RotateBenchmark.testRotateRightB | 256.00 | 31.00 | 21358.14 | 21346.21 | -0.06 | 21487.25 | 21854.42 | 1.71
>> RotateBenchmark.testRotateRightB | 256.00 | 31.00 | 11045.61 | 11208.26 | 1.47 | 10907.03 | 11415.18 | 4.66
>> RotateBenchmark.testRotateRightB | 512.00 | 7.00 | 17898.61 | 18307.54 | 2.28 | 1214.65 | 2546.64 | 109.66
>> RotateBenchmark.testRotateRightB | 512.00 | 15.00 | 17909.25 | 18242.51 | 1.86 | 1215.05 | 2563.98 | 111.02
>> RotateBenchmark.testRotateRightB | 512.00 | 31.00 | 17883.35 | 17928.44 | 0.25 | 1220.77 | 2543.30 | 108.34
>> RotateBenchmark.testRotateRightI | 128.00 | 7.00 | 7139.97 | 7626.72 | 6.82 | 6994.86 | 7075.65 | 1.15
>> RotateBenchmark.testRotateRightI | 128.00 | 7.00 | 3657.37 | 3898.34 | 6.59 | 3617.06 | 3576.12 | -1.13
>> RotateBenchmark.testRotateRightI | 128.00 | 7.00 | 1804.26 | 1969.19 | 9.14 | 1796.62 | 1858.84 | 3.46
>> RotateBenchmark.testRotateRightI | 128.00 | 15.00 | 7404.31 | 7760.09 | 4.80 | 7036.77 | 7401.52 | 5.18
>> RotateBenchmark.testRotateRightI | 128.00 | 15.00 | 3600.52 | 3956.35 | 9.88 | 3595.28 | 3560.36 | -0.97
>> RotateBenchmark.testRotateRightI | 128.00 | 15.00 | 1813.32 | 1966.41 | 8.44 | 1839.95 | 1852.53 | 0.68
>> RotateBenchmark.testRotateRightI | 128.00 | 31.00 | 7118.48 | 7724.81 | 8.52 | 7151.56 | 7021.09 | -1.82
>> RotateBenchmark.testRotateRightI | 128.00 | 31.00 | 3529.70 | 3881.63 | 9.97 | 3623.08 | 3601.01 | -0.61
>> RotateBenchmark.testRotateRightI | 128.00 | 31.00 | 1823.61 | 1961.34 | 7.55 | 1786.86 | 1748.85 | -2.13
>> RotateBenchmark.testRotateRightI | 256.00 | 7.00 | 11697.98 | 11835.25 | 1.17 | 11513.16 | 11184.87 | -2.85
>> RotateBenchmark.testRotateRightI | 256.00 | 7.00 | 5890.11 | 6102.57 | 3.61 | 5658.79 | 5696.08 | 0.66
>> RotateBenchmark.testRotateRightI | 256.00 | 7.00 | 2964.94 | 3070.26 | 3.55 | 2945.00 | 2962.08 | 0.58
>> RotateBenchmark.testRotateRightI | 256.00 | 15.00 | 11562.51 | 12151.29 | 5.09 | 11404.17 | 11120.28 | -2.49
>> RotateBenchmark.testRotateRightI | 256.00 | 15.00 | 5702.93 | 6130.57 | 7.50 | 5799.54 | 5779.08 | -0.35
>> RotateBenchmark.testRotateRightI | 256.00 | 15.00 | 2861.96 | 3051.44 | 6.62 | 2943.99 | 2860.65 | -2.83
>> RotateBenchmark.testRotateRightI | 256.00 | 31.00 | 11203.13 | 11710.59 | 4.53 | 11363.18 | 11112.16 | -2.21
>> RotateBenchmark.testRotateRightI | 256.00 | 31.00 | 5893.97 | 6070.71 | 3.00 | 5776.67 | 5648.84 | -2.21
>> RotateBenchmark.testRotateRightI | 256.00 | 31.00 | 2971.83 | 3046.76 | 2.52 | 2903.35 | 2833.88 | -2.39
>> RotateBenchmark.testRotateRightI | 512.00 | 7.00 | 16064.71 | 15851.35 | -1.33 | 861.93 | 2256.88 | 161.84
>> RotateBenchmark.testRotateRightI | 512.00 | 7.00 | 7916.80 | 8462.65 | 6.89 | 430.23 | 1147.30 | 166.67
>> RotateBenchmark.testRotateRightI | 512.00 | 7.00 | 4104.64 | 4068.28 | -0.89 | 216.30 | 572.86 | 164.84
>> RotateBenchmark.testRotateRightI | 512.00 | 15.00 | 16133.09 | 16281.59 | 0.92 | 856.36 | 2229.58 | 160.35
>> RotateBenchmark.testRotateRightI | 512.00 | 15.00 | 8127.26 | 8117.59 | -0.12 | 419.16 | 1176.42 | 180.66
>> RotateBenchmark.testRotateRightI | 512.00 | 15.00 | 4080.11 | 4063.26 | -0.41 | 218.32 | 571.93 | 161.97
>> RotateBenchmark.testRotateRightI | 512.00 | 31.00 | 15834.26 | 16314.64 | 3.03 | 865.96 | 2297.74 | 165.34
>> RotateBenchmark.testRotateRightI | 512.00 | 31.00 | 7965.62 | 8270.48 | 3.83 | 428.55 | 1148.87 | 168.08
>> RotateBenchmark.testRotateRightI | 512.00 | 31.00 | 4161.69 | 4034.76 | -3.05 | 215.63 | 570.19 | 164.43
>> RotateBenchmark.testRotateRightL | 128.00 | 7.00 | 3556.70 | 3877.08 | 9.01 | 3596.46 | 3558.32 | -1.06
>> RotateBenchmark.testRotateRightL | 128.00 | 7.00 | 1772.93 | 1993.86 | 12.46 | 1856.79 | 1783.22 | -3.96
>> RotateBenchmark.testRotateRightL | 128.00 | 7.00 | 908.66 | 1000.37 | 10.09 | 944.79 | 922.91 | -2.32
>> RotateBenchmark.testRotateRightL | 128.00 | 15.00 | 3742.44 | 3748.41 | 0.16 | 3788.07 | 3570.67 | -5.74
>> RotateBenchmark.testRotateRightL | 128.00 | 15.00 | 1817.53 | 1985.69 | 9.25 | 1892.38 | 1833.16 | -3.13
>> RotateBenchmark.testRotateRightL | 128.00 | 15.00 | 941.03 | 952.68 | 1.24 | 915.79 | 910.21 | -0.61
>> RotateBenchmark.testRotateRightL | 128.00 | 31.00 | 3649.48 | 3896.56 | 6.77 | 3637.59 | 3557.53 | -2.20
>> RotateBenchmark.testRotateRightL | 128.00 | 31.00 | 1840.12 | 1997.19 | 8.54 | 1821.47 | 1799.82 | -1.19
>> RotateBenchmark.testRotateRightL | 128.00 | 31.00 | 901.33 | 995.67 | 10.47 | 909.20 | 902.73 | -0.71
>> RotateBenchmark.testRotateRightL | 256.00 | 7.00 | 5789.93 | 5960.54 | 2.95 | 5758.14 | 5736.30 | -0.38
>> RotateBenchmark.testRotateRightL | 256.00 | 7.00 | 2963.20 | 3063.30 | 3.38 | 2943.48 | 2833.84 | -3.72
>> RotateBenchmark.testRotateRightL | 256.00 | 7.00 | 1501.81 | 1510.23 | 0.56 | 1463.85 | 1462.26 | -0.11
>> RotateBenchmark.testRotateRightL | 256.00 | 15.00 | 5870.05 | 5951.43 | 1.39 | 5794.74 | 5604.58 | -3.28
>> RotateBenchmark.testRotateRightL | 256.00 | 15.00 | 2971.36 | 3047.00 | 2.55 | 2931.19 | 2907.30 | -0.82
>> RotateBenchmark.testRotateRightL | 256.00 | 15.00 | 1473.97 | 1530.54 | 3.84 | 1473.45 | 1442.40 | -2.11
>> RotateBenchmark.testRotateRightL | 256.00 | 31.00 | 5858.08 | 6080.49 | 3.80 | 5863.69 | 5549.85 | -5.35
>> RotateBenchmark.testRotateRightL | 256.00 | 31.00 | 2916.24 | 3045.77 | 4.44 | 2981.59 | 2815.07 | -5.58
>> RotateBenchmark.testRotateRightL | 256.00 | 31.00 | 1441.20 | 1531.56 | 6.27 | 1492.47 | 1473.25 | -1.29
>> RotateBenchmark.testRotateRightL | 512.00 | 7.00 | 8147.24 | 8310.05 | 2.00 | 469.45 | 1235.21 | 163.12
>> RotateBenchmark.testRotateRightL | 512.00 | 7.00 | 4142.95 | 4258.86 | 2.80 | 234.14 | 615.52 | 162.88
>> RotateBenchmark.testRotateRightL | 512.00 | 7.00 | 2095.48 | 2087.20 | -0.40 | 113.55 | 311.19 | 174.05
>> RotateBenchmark.testRotateRightL | 512.00 | 15.00 | 8222.94 | 8246.58 | 0.29 | 458.91 | 1244.32 | 171.15
>> RotateBenchmark.testRotateRightL | 512.00 | 15.00 | 4160.04 | 4226.46 | 1.60 | 227.78 | 625.38 | 174.56
>> RotateBenchmark.testRotateRightL | 512.00 | 15.00 | 2064.63 | 2162.44 | 4.74 | 113.27 | 314.15 | 177.36
>> RotateBenchmark.testRotateRightL | 512.00 | 31.00 | 8157.94 | 8466.90 | 3.79 | 450.26 | 1221.90 | 171.37
>> RotateBenchmark.testRotateRightL | 512.00 | 31.00 | 4039.74 | 4283.33 | 6.03 | 224.82 | 612.68 | 172.53
>> RotateBenchmark.testRotateRightL | 512.00 | 31.00 | 2066.88 | 2147.51 | 3.90 | 110.97 | 303.43 | 173.42
>> RotateBenchmark.testRotateRightS | 128.00 | 7.00 | 13548.39 | 13245.87 | -2.23 | 13490.93 | 13084.76 | -3.01
>> RotateBenchmark.testRotateRightS | 128.00 | 7.00 | 7020.16 | 6768.85 | -3.58 | 6991.39 | 7044.32 | 0.76
>> RotateBenchmark.testRotateRightS | 128.00 | 7.00 | 3550.50 | 3505.19 | -1.28 | 3507.12 | 3612.86 | 3.01
>> RotateBenchmark.testRotateRightS | 128.00 | 15.00 | 13743.43 | 13325.44 | -3.04 | 13696.15 | 13255.80 | -3.22
>> RotateBenchmark.testRotateRightS | 128.00 | 15.00 | 6856.02 | 6969.18 | 1.65 | 6886.29 | 6834.12 | -0.76
>> RotateBenchmark.testRotateRightS | 128.00 | 15.00 | 3569.53 | 3492.76 | -2.15 | 3539.02 | 3470.02 | -1.95
>> RotateBenchmark.testRotateRightS | 128.00 | 31.00 | 13704.18 | 13495.07 | -1.53 | 13649.14 | 13583.87 | -0.48
>> RotateBenchmark.testRotateRightS | 128.00 | 31.00 | 7011.77 | 6953.93 | -0.82 | 6978.28 | 6740.30 | -3.41
>> RotateBenchmark.testRotateRightS | 128.00 | 31.00 | 3591.62 | 3620.12 | 0.79 | 3502.04 | 3510.05 | 0.23
>> RotateBenchmark.testRotateRightS | 256.00 | 7.00 | 21950.71 | 22113.60 | 0.74 | 21484.27 | 21596.64 | 0.52
>> RotateBenchmark.testRotateRightS | 256.00 | 7.00 | 11616.88 | 11099.73 | -4.45 | 11188.29 | 10737.68 | -4.03
>> RotateBenchmark.testRotateRightS | 256.00 | 7.00 | 5872.72 | 5579.12 | -5.00 | 5784.05 | 5454.57 | -5.70
>> RotateBenchmark.testRotateRightS | 256.00 | 15.00 | 22017.83 | 20817.97 | -5.45 | 21934.65 | 21356.90 | -2.63
>> RotateBenchmark.testRotateRightS | 256.00 | 15.00 | 11414.27 | 11044.86 | -3.24 | 11454.35 | 11140.34 | -2.74
>> RotateBenchmark.testRotateRightS | 256.00 | 15.00 | 5786.64 | 5634.05 | -2.64 | 5724.93 | 5639.99 | -1.48
>> RotateBenchmark.testRotateRightS | 256.00 | 31.00 | 21754.77 | 21466.01 | -1.33 | 21140.67 | 21970.03 | 3.92
>> RotateBenchmark.testRotateRightS | 256.00 | 31.00 | 11676.46 | 11358.64 | -2.72 | 11204.90 | 11213.48 | 0.08
>> RotateBenchmark.testRotateRightS | 256.00 | 31.00 | 5728.20 | 5772.49 | 0.77 | 5594.33 | 5544.25 | -0.90
>> RotateBenchmark.testRotateRightS | 512.00 | 7.00 | 30247.03 | 30179.41 | -0.22 | 1538.75 | 3975.82 | 158.38
>> RotateBenchmark.testRotateRightS | 512.00 | 7.00 | 15988.73 | 15621.42 | -2.30 | 776.04 | 1910.91 | 146.24
>> RotateBenchmark.testRotateRightS | 512.00 | 7.00 | 8115.84 | 8025.28 | -1.12 | 389.12 | 984.46 | 152.99
>> RotateBenchmark.testRotateRightS | 512.00 | 15.00 | 30110.91 | 30200.69 | 0.30 | 1532.49 | 3983.77 | 159.95
>> RotateBenchmark.testRotateRightS | 512.00 | 15.00 | 15957.90 | 15690.73 | -1.67 | 774.90 | 1931.00 | 149.19
>> RotateBenchmark.testRotateRightS | 512.00 | 15.00 | 8113.26 | 8037.93 | -0.93 | 391.90 | 965.53 | 146.37
>> RotateBenchmark.testRotateRightS | 512.00 | 31.00 | 29816.97 | 29891.54 | 0.25 | 1538.12 | 3881.93 | 152.38
>> RotateBenchmark.testRotateRightS | 512.00 | 31.00 | 15405.95 | 15619.17 | 1.38 | 762.49 | 1871.00 | 145.38
>> RotateBenchmark.testRotateRightS | 512.00 | 31.00 | 7919.80 | 7957.35 | 0.47 | 393.63 | 972.49 | 147.06
>
> Jatin Bhateja 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 http://github.com/openjdk/jdk into JDK-8266054
>  - Merge http://github.com/openjdk/jdk into JDK-8266054
>  - Merge http://github.com/openjdk/jdk into JDK-8266054
>  - Merge branch 'JDK-8266054' of http://github.com/jatin-bhateja/jdk into JDK-8266054
>  - 8266054: Removing redundant teat templates.
>  - 8266054: Code reorganization for efficient sharing of logic to check rotate operation support on a target platform.
>  - 8266054: Removing redundant test templates.
>  - 8266054: Review comments resolution.
>  - 8266054: Review comments resolution.
>  - 8266054: Review comments resolution.
>  - ... and 3 more: https://git.openjdk.java.net/jdk/compare/a0f32cb1...c60355d7

Just some format issues when I tried to use this benchmark.

test/micro/org/openjdk/bench/jdk/incubator/vector/RotateBenchmark.java line 85:

> 83:             longinp[i] = i;
> 84:         }
> 85:         for (int i = 0 ; i < specialvalsbyte.length; i++) {

Suggestion:

        for (int i = 0; i < specialvalsbyte.length; i++) {


Please remove this kind of space.

test/micro/org/openjdk/bench/jdk/incubator/vector/RotateBenchmark.java line 102:

> 100:     public void testRotateLeftB(Blackhole bh) {
> 101:         ByteVector bytevec = null;
> 102:         for (int j = 0 ; j < size; j+= bspecies.length()) {

Suggestion:

        for (int j = 0 ; j < size; j += bspecies.length()) {

Needs a space between `+=`.

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

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

From jlaskey at openjdk.java.net  Wed Jul 14 11:54:16 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Wed, 14 Jul 2021 11:54:16 GMT
Subject: [jdk17] Integrated: JDK-8270075 SplittableRandom extends
 AbstractSplittableGenerator
In-Reply-To: <hoRUR3GWahF1SY7g0B9YRCxmEHZqO4BMQTuOjqHzFys=.b1187f71-1b60-4970-a17c-088e13535ff0@github.com>
References: <hoRUR3GWahF1SY7g0B9YRCxmEHZqO4BMQTuOjqHzFys=.b1187f71-1b60-4970-a17c-088e13535ff0@github.com>
Message-ID: <vdGQPRalwYKl9P9rBvPCWsNQNi6UnL4eN3D_qMIbOFQ=.39015aab-584a-4807-97c9-b7a26889df5c@github.com>

On Mon, 12 Jul 2021 14:26:23 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

> Random.AbstractSplittableGenerator is an internal class that should not be exposed in a public API.

This pull request has now been integrated.

Changeset: 3bbd2332
Author:    Jim Laskey <jlaskey at openjdk.org>
URL:       https://git.openjdk.java.net/jdk17/commit/3bbd2332bd4876b5529ccdf90e5e5d6c515e9d58
Stats:     48 lines in 1 file changed: 29 ins; 1 del; 18 mod

8270075: SplittableRandom extends AbstractSplittableGenerator

Reviewed-by: rriggs, bpb

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

PR: https://git.openjdk.java.net/jdk17/pull/243

From jlaskey at openjdk.java.net  Wed Jul 14 12:04:11 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Wed, 14 Jul 2021 12:04:11 GMT
Subject: [jdk17] Integrated: 8266313: (JEP-356) - RandomGenerator spec
 implementation requirements tightly coupled to JDK internal classes
In-Reply-To: <o5oBHfWY5OpJKiiBGoeb4waLyThN91a11S7bhnPM_5Y=.6ce9cf3e-b73d-467c-b655-ae4098a1f1f7@github.com>
References: <o5oBHfWY5OpJKiiBGoeb4waLyThN91a11S7bhnPM_5Y=.6ce9cf3e-b73d-467c-b655-ae4098a1f1f7@github.com>
Message-ID: <RZlHIyvNy4rcSR1nPf2POedz7nkjEePenOrtoARWrfg=.bfc79d41-ba7f-435b-933e-6aa24e62c9b8@github.com>

On Fri, 25 Jun 2021 18:53:59 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

> The wording of the @implSpec referred to internal methods in the description. The patch rewords the @implSpec to be more descriptive of the algorithm than the methods used.

This pull request has now been integrated.

Changeset: 72db09b1
Author:    Jim Laskey <jlaskey at openjdk.org>
URL:       https://git.openjdk.java.net/jdk17/commit/72db09b1f393722074cae2fbff0fc369f0f2718c
Stats:     54 lines in 2 files changed: 23 ins; 4 del; 27 mod

8266313: (JEP-356) - RandomGenerator spec implementation requirements tightly coupled to JDK internal classes

Reviewed-by: rriggs

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

PR: https://git.openjdk.java.net/jdk17/pull/151

From github.com+10835776+stsypanov at openjdk.java.net  Wed Jul 14 12:40:14 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Wed, 14 Jul 2021 12:40:14 GMT
Subject: RFR: 8268113: Re-use Long.hashCode() where possible [v9]
In-Reply-To: <P1bleKY0ErOGoARqX7TwlWUMToCFitDwdEtpPbZPFI0=.0c62cbca-c3a2-4734-b267-415ba99bf399@github.com>
References: <7TGw6Vzvw38bqmNOQsuVuGXMe98OqH25nmexLUghcMU=.5e7b347c-0d83-4e54-acc3-9847c08cdc29@github.com>
 <_TQh_iGjI3byKr1pc0gr7GZnCiyeKubYIy4rkLwbipY=.08915956-df4e-411e-b985-edd411a5bdc3@github.com>
 <P1bleKY0ErOGoARqX7TwlWUMToCFitDwdEtpPbZPFI0=.0c62cbca-c3a2-4734-b267-415ba99bf399@github.com>
Message-ID: <kSkTAfbM5U7mmIY7zgGfNxaJKFg6ESLoULuug9zIh5s=.854709a6-b430-4b44-a6fd-7a0bd8ca8c5b@github.com>

On Tue, 13 Jul 2021 13:04:36 GMT, Attila Szegedi <attila at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/BitSet.java line 1040:
>> 
>>> 1038:             h ^= words[i] * (i + 1);
>>> 1039: 
>>> 1040:         return Long.hashCode(h);
>> 
>> Here `>>` instead of `>>>` in original code seems to be a typo
>
> It is specified as `>>` in JavaDoc just above the implementation. As the algorithm is part of the public API and thus part of the specification, I don't think you can change it just here in the implementation; you'd need to at least submit a CSR for it.

Good point! I'll then revert this change

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

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

From github.com+12575901+gbaso at openjdk.java.net  Wed Jul 14 12:45:17 2021
From: github.com+12575901+gbaso at openjdk.java.net (Giacomo Baso)
Date: Wed, 14 Jul 2021 12:45:17 GMT
Subject: RFR: 8260265: UTF-8 by Default
In-Reply-To: <-F4rYMOBcR8vg_mtYrJ--Ovx9d5bDLTF2p40uV5QqMM=.9cfd49ad-be84-4455-9695-138203395b21@github.com>
References: <-F4rYMOBcR8vg_mtYrJ--Ovx9d5bDLTF2p40uV5QqMM=.9cfd49ad-be84-4455-9695-138203395b21@github.com>
Message-ID: <hVB_4QQWVmsnUgqcTXGIS_KT2zacBhMpkHjEXTZVpmo=.dd2c4d41-4b24-4c23-8e1d-39620180e64d@github.com>

On Thu, 8 Jul 2021 21:23:00 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is an implementation for the `JEP 400: UTF-8 by Default`. The gist of the changes is `Charset.defaultCharset()` returning `UTF-8` and `file.encoding` system property being added in the spec, but another notable modification is in `java.io.PrintStream` where it continues to use the `Console` encoding as the default charset instead of `UTF-8`. Other changes are mostly clarification of the term "default charset" and their links. Corresponding CSR has also been drafted.
> 
> JEP 400: https://bugs.openjdk.java.net/browse/JDK-8187041
> CSR: https://bugs.openjdk.java.net/browse/JDK-8260266

> Consider an application that creates a java.io.FileWriter with its one-argument constructor and then uses it to write some text to a file. The resulting file will contain a sequence of bytes encoded using the default charset of the JDK running the application. A second application, run on a different machine or by a different user on the same machine, creates a java.io.FileReader with its one-argument constructor and uses it to read the bytes in that file. The resulting text contains a sequence of characters decoded using the default charset of the JDK running the second application. If the default charset differs between the JDK of the first application and the JDK of the second application, then the resulting text may be silently corrupted or incomplete, since these APIs replace erroneous input rather than fail.

It's even worse than that, because many OpenSSH installs are configured by default to [forward](https://man.openbsd.org/ssh_config.5#SendEnv) and [accept](https://man.openbsd.org/sshd_config.5#AcceptEnv) the user locale (see e.g. for [RHEL 7](https://access.redhat.com/solutions/974273)).

So a single application, on a single remote machine, can be unknowingly started by a single user with different locales, and therefore different encodings, depending on how the user connected to the remote machine. For example, on Windows connecting via powershell results in `LANG=en_US.UTF-8`, while using WSL2 results in `LANG=C.UTF-8`. On Java 11 in a RHEL7 machine, `file.encoding` results in `UTF-8` in the first case, but `ANSI_X3.4-1968` in the second, leading to a default charset `ASCII`.

Worth mentioning is also that `Charset.forName("default")` is just an alias to `ASCII`, per `sun.nio.cs.StandardCharsets$Aliases`.

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

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

From github.com+10835776+stsypanov at openjdk.java.net  Wed Jul 14 12:47:43 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Wed, 14 Jul 2021 12:47:43 GMT
Subject: RFR: 8268113: Re-use Long.hashCode() where possible [v10]
In-Reply-To: <7TGw6Vzvw38bqmNOQsuVuGXMe98OqH25nmexLUghcMU=.5e7b347c-0d83-4e54-acc3-9847c08cdc29@github.com>
References: <7TGw6Vzvw38bqmNOQsuVuGXMe98OqH25nmexLUghcMU=.5e7b347c-0d83-4e54-acc3-9847c08cdc29@github.com>
Message-ID: <Gr0Inz8Szvq_9_XqMLpsOM3K-NSVYzKbwd3cDMsTJsQ=.0dfd998d-1423-4e5a-9df0-372e186c5632@github.com>

> There is a few JDK classes duplicating the contents of Long.hashCode() for hash code calculation. They should explicitly delegate to Long.hashCode().

?????? ??????? has updated the pull request with a new target base 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:

 - 8270160 Revert changes in BitSet.hashCode
 - Merge branch 'master' into 8268113
 - 8270160 Revert changes in BitSet.hashCode
 - Merge branch 'master' into 8268113
 - Merge branch 'master' into 8268113
 - Merge branch 'master' into 8268113
 - Merge branch 'master' into 8268113
 - Merge branch 'master' into 8268113
 - Merge branch 'master' into 8268113
 - 8268113: Inline local vars where reasonable
 - ... and 2 more: https://git.openjdk.java.net/jdk/compare/2f04364f...1d619c73

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4309/files
  - new: https://git.openjdk.java.net/jdk/pull/4309/files/a72a09b6..1d619c73

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

  Stats: 6977 lines in 323 files changed: 3755 ins; 2117 del; 1105 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4309.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4309/head:pull/4309

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

From ngasson at openjdk.java.net  Wed Jul 14 12:55:13 2021
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Wed, 14 Jul 2021 12:55:13 GMT
Subject: RFR: 8268231: Aarch64: Use ldp in intrinsics for String.compareTo
 [v3]
In-Reply-To: <nulsSsZPVaoQA13GVqYV0_3EY7duVRYPkz-vhZBfibg=.fc7a36e3-0f29-4a7e-91cc-141f9f82365a@github.com>
References: <XwW4MjGSYmSHa2ZbzrOfvoZi1pe8LJAK7YIKtmNhaDM=.d39df32e-8698-4608-9184-3b19cd175d1a@github.com>
 <B4QlLNxlUxwMUmJjgZG6e82vGN2tlnJeKsQ_1QCNlOE=.b99f2103-318f-40f1-89d6-1069dc0ba22d@github.com>
 <nulsSsZPVaoQA13GVqYV0_3EY7duVRYPkz-vhZBfibg=.fc7a36e3-0f29-4a7e-91cc-141f9f82365a@github.com>
Message-ID: <BC0mfNEkBfE2XcbwVbg3IjZGfFkz1l4gaUGvsBiBIEc=.aabb7a33-0004-42c5-a6dd-35fc650c8280@github.com>

On Wed, 14 Jul 2021 08:47:56 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

> I tried that on N1 and it's very slightly slower than with the 16B alignment

Sorry, ignore that, the result is actually the other way round. Not sure what's going on there, but there's no significant difference.

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

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

From darcy at openjdk.java.net  Wed Jul 14 15:28:12 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 14 Jul 2021 15:28:12 GMT
Subject: RFR: 6506405: Math.abs(float) is slow [v9]
In-Reply-To: <T1q1PLl4AGffBBsflTT6zEQKKMW3pYvci4wp_k-uotU=.9341f86f-4d09-4ebd-8f95-65e28a749179@github.com>
References: <101iFqz6Ghvzu84BSMu6OyB-8sgTyx32uvfc5R-YTjg=.6a958f74-16cb-4388-a793-abad94093aa9@github.com>
 <T1q1PLl4AGffBBsflTT6zEQKKMW3pYvci4wp_k-uotU=.9341f86f-4d09-4ebd-8f95-65e28a749179@github.com>
Message-ID: <SUJwkebOXuXfj1Bk47Yc3nWIXuMKuii0A2yJIt-ywoo=.f86c21a7-8970-486e-a88b-8bdeab6ad762@github.com>

On Mon, 12 Jul 2021 17:59:32 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Please consider this change to make the `float` and `double` versions of `java.lang.Math.abs()` branch-free.
>
> Brian Burkhalter 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 darcy (Reviewer).

Updated tests look fine. Next time I'm in the neighborhood of the jdk/test/java/lang/Math/Tests.java code, I'll look to add some overloads to make it more lambda/method reference friendly.

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

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

From rriggs at openjdk.java.net  Wed Jul 14 15:46:15 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 14 Jul 2021 15:46:15 GMT
Subject: RFR: 8260265: UTF-8 by Default
In-Reply-To: <-F4rYMOBcR8vg_mtYrJ--Ovx9d5bDLTF2p40uV5QqMM=.9cfd49ad-be84-4455-9695-138203395b21@github.com>
References: <-F4rYMOBcR8vg_mtYrJ--Ovx9d5bDLTF2p40uV5QqMM=.9cfd49ad-be84-4455-9695-138203395b21@github.com>
Message-ID: <UeYH9TsbiwM8PkBGqoEaanv8umkXj-pOdrDVA7lZelk=.2b55829d-f622-43f7-88fa-e35ef5ee29f3@github.com>

On Thu, 8 Jul 2021 21:23:00 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is an implementation for the `JEP 400: UTF-8 by Default`. The gist of the changes is `Charset.defaultCharset()` returning `UTF-8` and `file.encoding` system property being added in the spec, but another notable modification is in `java.io.PrintStream` where it continues to use the `Console` encoding as the default charset instead of `UTF-8`. Other changes are mostly clarification of the term "default charset" and their links. Corresponding CSR has also been drafted.
> 
> JEP 400: https://bugs.openjdk.java.net/browse/JDK-8187041
> CSR: https://bugs.openjdk.java.net/browse/JDK-8260266

src/java.base/share/classes/java/io/ByteArrayOutputStream.java line 291:

> 289:      * method, which takes an encoding-name or charset argument,
> 290:      * or the {@code toString()} method, which uses the default
> 291:      * charset.

Fold to previous line.

src/java.base/share/classes/java/io/Console.java line 587:

> 585:                 try {
> 586:                     cs = Charset.forName(csname);
> 587:                 } catch (Exception ignored) { }

A separate enhancement...
I've long thought that should be a way to avoid the exception here.
For example,  a Charset.forName(csname, default);
The caller might have a default in mind or supply null and then be able to test for null.

src/java.base/share/classes/java/io/FileReader.java line 41:

> 39:  * @see InputStreamReader
> 40:  * @see FileInputStream
> 41:  * @see java.nio.charset.Charset#defaultCharset()

The @ see duplicates the link above, the javadoc can do without the @ see.

src/java.base/share/classes/java/io/InputStreamReader.java line 39:

> 37:  * java.nio.charset.Charset charset}.  The charset that it uses
> 38:  * may be specified by name or may be given explicitly, or the
> 39:  * {@link Charset#defaultCharset() default charset} may be accepted.

"may be accepted" seems like the API has some choice in the matter. 
Perhaps "accepted" -> "used".
And in other classes below if there's a suitable replacement.

src/java.base/share/classes/java/io/PrintStream.java line 49:

> 47:  * <p> All characters printed by a {@code PrintStream} are converted into
> 48:  * bytes using the given encoding or charset, or the default
> 49:  * console charset if not specified.

JEP 400 doesn't give a rationale for using the console charset for PrintStream.
PrintStreams are used for output to files and other media other than just a tty/console.
The charset of system.out/err should use the console charset.

src/java.base/share/classes/java/lang/System.java line 802:

> 800:      * <tr><th scope="row">{@systemProperty file.encoding}</th>
> 801:      *     <td>The name of the default charset. Users may specify
> 802:      *     {@code UTF-8} or {@code COMPAT} on the command line to the value.

The wording could imply that only those two values can be supplied.
It could be rephrased to say that *if* the property is supplied on the command line
it overrides the default UTF-8.

src/java.base/share/classes/java/net/URLDecoder.java line 92:

> 90: 
> 91:     // The default charset
> 92:     static String dfltEncName = URLEncoder.dfltEncName;

Perhaps add the value of file.encoding to the StaticProperties either as a string or as the Charset.
That would allow a few different lookups of the property to be simplified.

src/java.base/share/classes/java/net/URLEncoder.java line 165:

> 163:         try {
> 164:             str = encode(s, dfltEncName);
> 165:         } catch (UnsupportedEncodingException e) {

Perhaps a separate cleanup, the Charset should be cached, not just the name and use the `encode(s, charset)` method.

src/java.base/share/classes/java/nio/charset/Charset.java line 601:

> 599:      * value designates {@code COMPAT}, the default charset is derived from
> 600:      * the {@code native.encoding} system property, which typically depends
> 601:      * upon the locale and charset of the underlying operating system.

The description in java.lang.System of the file.encoding property does not indicate it is 'implementation specific'.
In that context, it appears to be part of the JavaSE spec.
Having the spec in a single place with references to it from others could avoid duplication.

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

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

From bpb at openjdk.java.net  Wed Jul 14 15:54:16 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 14 Jul 2021 15:54:16 GMT
Subject: Integrated: 6506405: Math.abs(float) is slow
In-Reply-To: <101iFqz6Ghvzu84BSMu6OyB-8sgTyx32uvfc5R-YTjg=.6a958f74-16cb-4388-a793-abad94093aa9@github.com>
References: <101iFqz6Ghvzu84BSMu6OyB-8sgTyx32uvfc5R-YTjg=.6a958f74-16cb-4388-a793-abad94093aa9@github.com>
Message-ID: <_OQa4cfyUqG0X9jFQJScsdo3Q0XI9wPkHIpyi6Nu-R4=.84bf98b6-5180-47ff-8cee-46083714703b@github.com>

On Wed, 7 Jul 2021 20:28:37 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Please consider this change to make the `float` and `double` versions of `java.lang.Math.abs()` branch-free.

This pull request has now been integrated.

Changeset: c0d4efff
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c0d4efff3c7b853cd663726b668d49d01e0f8ee0
Stats:     129 lines in 4 files changed: 121 ins; 0 del; 8 mod

6506405: Math.abs(float) is slow

Reviewed-by: darcy

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

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

From github.com+154109+jglick at openjdk.java.net  Wed Jul 14 16:23:13 2021
From: github.com+154109+jglick at openjdk.java.net (Jesse Glick)
Date: Wed, 14 Jul 2021 16:23:13 GMT
Subject: RFR: 8260265: UTF-8 by Default
In-Reply-To: <UeYH9TsbiwM8PkBGqoEaanv8umkXj-pOdrDVA7lZelk=.2b55829d-f622-43f7-88fa-e35ef5ee29f3@github.com>
References: <-F4rYMOBcR8vg_mtYrJ--Ovx9d5bDLTF2p40uV5QqMM=.9cfd49ad-be84-4455-9695-138203395b21@github.com>
 <UeYH9TsbiwM8PkBGqoEaanv8umkXj-pOdrDVA7lZelk=.2b55829d-f622-43f7-88fa-e35ef5ee29f3@github.com>
Message-ID: <CfPGzp7d9VB6tJmMvdwQywehKXTRZ2EvZ6TPh7Kr8U4=.e54a31b2-6c08-47f3-9a89-42d9f74f944a@github.com>

On Wed, 14 Jul 2021 15:09:41 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> This is an implementation for the `JEP 400: UTF-8 by Default`. The gist of the changes is `Charset.defaultCharset()` returning `UTF-8` and `file.encoding` system property being added in the spec, but another notable modification is in `java.io.PrintStream` where it continues to use the `Console` encoding as the default charset instead of `UTF-8`. Other changes are mostly clarification of the term "default charset" and their links. Corresponding CSR has also been drafted.
>> 
>> JEP 400: https://bugs.openjdk.java.net/browse/JDK-8187041
>> CSR: https://bugs.openjdk.java.net/browse/JDK-8260266
>
> src/java.base/share/classes/java/io/PrintStream.java line 49:
> 
>> 47:  * <p> All characters printed by a {@code PrintStream} are converted into
>> 48:  * bytes using the given encoding or charset, or the default
>> 49:  * console charset if not specified.
> 
> JEP 400 doesn't give a rationale for using the console charset for PrintStream.
> PrintStreams are used for output to files and other media other than just a tty/console.
> The charset of system.out/err should use the console charset.

This was my thinking in https://github.com/openjdk/jdk/pull/4733#issuecomment-876793372.

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

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

From bpb at openjdk.java.net  Wed Jul 14 16:43:48 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 14 Jul 2021 16:43:48 GMT
Subject: RFR: 8211002: test/jdk/java/lang/Math/PowTests.java skips testing
 for non-corner-case values [v2]
In-Reply-To: <CTD8-ciAhD-kPjiC0ic6qbOOE3XObK7JoFCTOVpLflM=.7970b30d-a3b0-4a7f-81c0-860894d56b94@github.com>
References: <CTD8-ciAhD-kPjiC0ic6qbOOE3XObK7JoFCTOVpLflM=.7970b30d-a3b0-4a7f-81c0-860894d56b94@github.com>
Message-ID: <lmK9ADp0JZWq70DBBupJhygkCGlXsSHWqo1RBdMwTyY=.be1aed71-1ea2-4d82-bef7-713262d437b0@github.com>

> Please consider this proposal to add some test coverage comparing `Math` and `StrictMath` results of `pow()`.

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

  8211002: Change so that Tests.testUlpDiff() handles the NaNs and accepts a ulp tolerance of 2

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4758/files
  - new: https://git.openjdk.java.net/jdk/pull/4758/files/0cebcfc8..2fe3ff35

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

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

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

From bpb at openjdk.java.net  Wed Jul 14 16:43:52 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 14 Jul 2021 16:43:52 GMT
Subject: RFR: 8211002: test/jdk/java/lang/Math/PowTests.java skips testing
 for non-corner-case values [v2]
In-Reply-To: <68WE7DbWSJuaBPba4UWiP3BFSkVK-XNHotA4UOXi98g=.6e78b5ae-a711-4212-9447-0aea7fbca515@github.com>
References: <CTD8-ciAhD-kPjiC0ic6qbOOE3XObK7JoFCTOVpLflM=.7970b30d-a3b0-4a7f-81c0-860894d56b94@github.com>
 <68WE7DbWSJuaBPba4UWiP3BFSkVK-XNHotA4UOXi98g=.6e78b5ae-a711-4212-9447-0aea7fbca515@github.com>
Message-ID: <-yoe9UmfGYWk5fi8yqyxSj23kRf0e2EURqQSBjXfZjU=.ff68ebf0-e05f-4b1b-90a3-f1947e214449@github.com>

On Tue, 13 Jul 2021 23:29:38 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8211002: Change so that Tests.testUlpDiff() handles the NaNs and accepts a ulp tolerance of 2
>
> test/jdk/java/lang/Math/PowTests.java line 65:
> 
>> 63:         int failures = 0;
>> 64:         if (Double.isNaN(smResult)) {
>> 65:             if (!Double.isNaN(mResult)) failures = 1;
> 
> Pretty sure the Tests.testUlpDiff call will handle two NaNs as well as NaN/non-NaN argument.

Looks like that is true.

> test/jdk/java/lang/Math/PowTests.java line 69:
> 
>> 67:             failures += Tests.testUlpDiff(
>> 68:                 "StrictMath.pow(double, double) vs Math.pow(double, double)",
>> 69:                 input1, input2, mResult, smResult, 1.0
> 
> In theory at least, one pow method could round an ulp up and the other could round an ulp down so the difference should be 2 ulps (ignoring the special case of values straddling a power of two).

Good point.

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

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

From darcy at openjdk.java.net  Wed Jul 14 16:48:15 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 14 Jul 2021 16:48:15 GMT
Subject: RFR: 8075806: divideExact is missing in java.lang.Math
In-Reply-To: <8nZ1xpS-Ir7KIEuaryZ0bQ2upeqcMy9TBm7-afE5lek=.22ec71c9-49d7-4994-aa1e-638c9d522510@github.com>
References: <8nZ1xpS-Ir7KIEuaryZ0bQ2upeqcMy9TBm7-afE5lek=.22ec71c9-49d7-4994-aa1e-638c9d522510@github.com>
Message-ID: <K-P-25qjIB0Ew7ytkAj_JoqdO3yi0JU7Czm6weusicc=.8d76ae2e-96cd-4842-aff2-959f36a6726b@github.com>

On Tue, 13 Jul 2021 17:21:52 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Please consider this proposal to add `divideExact()` methods for integral data types to `java.lang.Math` thereby rounding out "exact" support to all four basic arithmetic operations.

Are there examples in the JDK or its tests where a method with this definition would be used?

src/java.base/share/classes/java/lang/Math.java line 1008:

> 1006:      * Returns the quotient of the arguments, throwing an exception if the
> 1007:      * result overflows an {@code int}.  Such overflow can occur if and only
> 1008:      * if either {@code y} is zero, or both {@code x} is

I think the divide by zero case should be discussed separately from overflow.

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

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

From herrick at openjdk.java.net  Wed Jul 14 16:50:39 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Wed, 14 Jul 2021 16:50:39 GMT
Subject: RFR: JDK-8269387: jpackage --add-launcher should have option to
 not create shortcuts for additional launchers [v4]
In-Reply-To: <gO8--JRs2F9hyLuR5gnanY-KYiH-wYSexmUbDGeaP0Q=.e8fa9a64-1018-427f-b1f9-72fc48671b21@github.com>
References: <gO8--JRs2F9hyLuR5gnanY-KYiH-wYSexmUbDGeaP0Q=.e8fa9a64-1018-427f-b1f9-72fc48671b21@github.com>
Message-ID: <5fBBBZc7EnRAlikfeDllziaiB1jskH_Dy6VWh9Qp9ZE=.48aa8637-7c6d-4936-869d-22a31793362e@github.com>

> JDK-8269387: jpackage --add-launcher should have option to not create shortcuts for additional launchers

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

  JDK-8269387: jpackage --add-launcher should have option to not create shortcuts for additional launchers

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4730/files
  - new: https://git.openjdk.java.net/jdk/pull/4730/files/d88b1dc7..96758fe8

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

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

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

From github.com+1701815+mkarg at openjdk.java.net  Wed Jul 14 17:48:17 2021
From: github.com+1701815+mkarg at openjdk.java.net (Markus KARG)
Date: Wed, 14 Jul 2021 17:48:17 GMT
Subject: RFR: 8265891: (ch) InputStream returned by
 Channels.newInputStream should override transferTo [v3]
In-Reply-To: <aS5i72i7KLnTndIFIA_94OUjEgyuwXiHDHu1H898QtE=.0fcdd01c-2219-4318-86d7-8826941b6f41@github.com>
References: <XlU5gCBUEa4qTTz8yhMeElh95FuiPcFYQ_nj_WYvbLE=.6e9fc6a4-f3b1-4faf-91f0-d8b06f875780@github.com>
 <aS5i72i7KLnTndIFIA_94OUjEgyuwXiHDHu1H898QtE=.0fcdd01c-2219-4318-86d7-8826941b6f41@github.com>
Message-ID: <8kSiVkKwbP0EbOfpVHO9HLMPHM58ySG-ZLwZjMdCpUk=.ff8a4d7b-085d-487d-ba47-f072a439ce6a@github.com>

On Fri, 2 Jul 2021 06:20:29 GMT, Markus KARG <github.com+1701815+mkarg at openjdk.org> wrote:

>> This PR-*draft* is **work in progress** and an invitation to discuss a possible solution for issue [JDK-8265891](https://bugs.openjdk.java.net/browse/JDK-8265891). It is *not yet* intended for a final review.
>> 
>> As proposed in JDK-8265891, this PR provides an implementation for `Channels.newInputStream().transferTo()` which provide superior performance compared to the current implementation. The changes are:
>> * Prevents transfers through the JVM heap as much as possibly by offloading to deeper levels via NIO, hence allowing the operating system to optimize the transfer.
>> * Using more JRE heap in the fallback case when no NIO is possible (still only KiBs, hence mostl ynegligible even on SBCs) to better perform on modern hardware / fast I/O devides.
>> 
>> Using JMH I have benchmarked both, the original implementation and this implementation, and (depending on the used hardware and use case) performance change was approx. doubled performance. So this PoC proofs that it makes sense to finalize this work and turn it into an actual OpenJDK contribution. 
>> 
>> I encourage everybody to discuss this draft:
>> * Are there valid arguments for *not* doing this change?
>> * Is there a *better* way to improve performance of `Channels.newInputStream().transferTo()`?
>> * How to go on from here: What is missing to get this ready for an actual review?
>
> Markus KARG has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR.

I cloned the `InputStream/TransferTo` test in a way which uses providers, but when started to implement the providers I noticed that a huge amount of *empty* source code is needed just to make the compiler happy: `FileChannel` already has dozens of abstract methods I have to override but they never will be used by any of the tests... Having that said, it would be good if I would be allowed to spare us thousands of useless codelines:
* May I just implement the `content()` test or do you insist on me really implementing *all* the tests found in `InputStream/TransferTo` for *each* of the overloaded `transferTo` implementations?
* May I use a mocking framework to actually just provide *partial* implementations of the channels, or do you insist on me actually overloading *all* methods of *all* channels in actual Java source code just for the sake of making the compiler happy?

While I understand the necessity of tests, and while I am convinced that the performance benefit outweighs the weeks of work this would imply just for adding all those test code, I actually like to propose that I only cover the `content()` tests plus using Mockito, so we would have 80% of the benefit for 20% of the coding costs.

WDYT?

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

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

From bpb at openjdk.java.net  Wed Jul 14 18:38:15 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 14 Jul 2021 18:38:15 GMT
Subject: RFR: 8265891: (ch) InputStream returned by
 Channels.newInputStream should override transferTo [v3]
In-Reply-To: <aS5i72i7KLnTndIFIA_94OUjEgyuwXiHDHu1H898QtE=.0fcdd01c-2219-4318-86d7-8826941b6f41@github.com>
References: <XlU5gCBUEa4qTTz8yhMeElh95FuiPcFYQ_nj_WYvbLE=.6e9fc6a4-f3b1-4faf-91f0-d8b06f875780@github.com>
 <aS5i72i7KLnTndIFIA_94OUjEgyuwXiHDHu1H898QtE=.0fcdd01c-2219-4318-86d7-8826941b6f41@github.com>
Message-ID: <xBg2xYkt8KnJCohvSQW13aIyNAEhQIG9PVzLUAV1lQM=.771005fb-080f-4828-acc4-1ebf63a42a21@github.com>

On Fri, 2 Jul 2021 06:20:29 GMT, Markus KARG <github.com+1701815+mkarg at openjdk.org> wrote:

>> This PR-*draft* is **work in progress** and an invitation to discuss a possible solution for issue [JDK-8265891](https://bugs.openjdk.java.net/browse/JDK-8265891). It is *not yet* intended for a final review.
>> 
>> As proposed in JDK-8265891, this PR provides an implementation for `Channels.newInputStream().transferTo()` which provide superior performance compared to the current implementation. The changes are:
>> * Prevents transfers through the JVM heap as much as possibly by offloading to deeper levels via NIO, hence allowing the operating system to optimize the transfer.
>> * Using more JRE heap in the fallback case when no NIO is possible (still only KiBs, hence mostl ynegligible even on SBCs) to better perform on modern hardware / fast I/O devides.
>> 
>> Using JMH I have benchmarked both, the original implementation and this implementation, and (depending on the used hardware and use case) performance change was approx. doubled performance. So this PoC proofs that it makes sense to finalize this work and turn it into an actual OpenJDK contribution. 
>> 
>> I encourage everybody to discuss this draft:
>> * Are there valid arguments for *not* doing this change?
>> * Is there a *better* way to improve performance of `Channels.newInputStream().transferTo()`?
>> * How to go on from here: What is missing to get this ready for an actual review?
>
> Markus KARG 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:
> 
>   Draft: Renaming i and separating code into several methods
>   
>   Signed-off-by: Markus Karg <markus at headcrashing.eu>

Mockito is not approved for distribution and/or hosting by Java (Oracle JDK / OpenJDK).

I understand not wanting to have a lot of useless code. Have you looked into other tests which have implemented Providers?

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

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

From raffaello.giulietti at gmail.com  Wed Jul 14 19:26:35 2021
From: raffaello.giulietti at gmail.com (Raffaello Giulietti)
Date: Wed, 14 Jul 2021 21:26:35 +0200
Subject: RFR: 8075806: divideExact is missing in java.lang.Math
In-Reply-To: <8nZ1xpS-Ir7KIEuaryZ0bQ2upeqcMy9TBm7-afE5lek=.22ec71c9-49d7-4994-aa1e-638c9d522510@github.com>
References: <8nZ1xpS-Ir7KIEuaryZ0bQ2upeqcMy9TBm7-afE5lek=.22ec71c9-49d7-4994-aa1e-638c9d522510@github.com>
Message-ID: <86ee0fd4-84b5-4a83-8a6f-4508b2667b64@gmail.com>

One could also divide first and then check the result:

int q = x / y;
if ((x & y & q) >= 0) {
     return r;
}
throw new ArithmeticException("integer overflow");

No idea about relative perf.



On 2021-07-13 19:32, Brian Burkhalter wrote:
> Please consider this proposal to add `divideExact()` methods for integral data types to `java.lang.Math` thereby rounding out "exact" support to all four basic arithmetic operations.
> 
> -------------
> 
> Commit messages:
>   - 8075806: divideExact is missing in java.lang.Math
> 
> Changes: https://git.openjdk.java.net/jdk/pull/4770/files
>   Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4770&range=00
>    Issue: https://bugs.openjdk.java.net/browse/JDK-8075806
>    Stats: 109 lines in 2 files changed: 100 ins; 5 del; 4 mod
>    Patch: https://git.openjdk.java.net/jdk/pull/4770.diff
>    Fetch: git fetch https://git.openjdk.java.net/jdk pull/4770/head:pull/4770
> 
> PR: https://git.openjdk.java.net/jdk/pull/4770
> 

From raffaello.giulietti at gmail.com  Wed Jul 14 19:32:18 2021
From: raffaello.giulietti at gmail.com (Raffaello Giulietti)
Date: Wed, 14 Jul 2021 21:32:18 +0200
Subject: RFR: 8075806: divideExact is missing in java.lang.Math
In-Reply-To: <86ee0fd4-84b5-4a83-8a6f-4508b2667b64@gmail.com>
References: <8nZ1xpS-Ir7KIEuaryZ0bQ2upeqcMy9TBm7-afE5lek=.22ec71c9-49d7-4994-aa1e-638c9d522510@github.com>
 <86ee0fd4-84b5-4a83-8a6f-4508b2667b64@gmail.com>
Message-ID: <7c6a8ad5-7a9d-7d3f-3dfb-4032600a283d@gmail.com>

Sorry, typo

int q = x / y;
if ((x & y & q) >= 0) {
      return q;  // q, not r
}
throw new ArithmeticException("integer overflow");


On 2021-07-14 21:26, Raffaello Giulietti wrote:
> One could also divide first and then check the result:
> 
> int q = x / y;
> if ((x & y & q) >= 0) {
>  ??? return r;
> }
> throw new ArithmeticException("integer overflow");
> 
> No idea about relative perf.
> 
> 
> 
> On 2021-07-13 19:32, Brian Burkhalter wrote:
>> Please consider this proposal to add `divideExact()` methods for 
>> integral data types to `java.lang.Math` thereby rounding out "exact" 
>> support to all four basic arithmetic operations.
>>
>> -------------
>>
>> Commit messages:
>> ? - 8075806: divideExact is missing in java.lang.Math
>>
>> Changes: https://git.openjdk.java.net/jdk/pull/4770/files
>> ? Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4770&range=00
>> ?? Issue: https://bugs.openjdk.java.net/browse/JDK-8075806
>> ?? Stats: 109 lines in 2 files changed: 100 ins; 5 del; 4 mod
>> ?? Patch: https://git.openjdk.java.net/jdk/pull/4770.diff
>> ?? Fetch: git fetch https://git.openjdk.java.net/jdk 
>> pull/4770/head:pull/4770
>>
>> PR: https://git.openjdk.java.net/jdk/pull/4770
>>

From bpb at openjdk.java.net  Wed Jul 14 19:33:16 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 14 Jul 2021 19:33:16 GMT
Subject: RFR: 8075806: divideExact is missing in java.lang.Math
In-Reply-To: <8nZ1xpS-Ir7KIEuaryZ0bQ2upeqcMy9TBm7-afE5lek=.22ec71c9-49d7-4994-aa1e-638c9d522510@github.com>
References: <8nZ1xpS-Ir7KIEuaryZ0bQ2upeqcMy9TBm7-afE5lek=.22ec71c9-49d7-4994-aa1e-638c9d522510@github.com>
Message-ID: <XIHfu9d2j2fFpP1G8LYYWXxnp1eCTnLz6kZiHfVnfhU=.cace5460-b4ed-4ca4-86fb-76325c6ced3a@github.com>

On Tue, 13 Jul 2021 17:21:52 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Please consider this proposal to add `divideExact()` methods for integral data types to `java.lang.Math` thereby rounding out "exact" support to all four basic arithmetic operations.

Thanks. I was thinking of leveraging the `negateExact()` intrinsic instead:


        // Leverage a potential intrinsic of negateExact()
        return y == -1 ? Math.negateExact(x) : x/y;

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

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

From bpb at openjdk.java.net  Wed Jul 14 19:53:14 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 14 Jul 2021 19:53:14 GMT
Subject: RFR: 8075806: divideExact is missing in java.lang.Math
In-Reply-To: <8nZ1xpS-Ir7KIEuaryZ0bQ2upeqcMy9TBm7-afE5lek=.22ec71c9-49d7-4994-aa1e-638c9d522510@github.com>
References: <8nZ1xpS-Ir7KIEuaryZ0bQ2upeqcMy9TBm7-afE5lek=.22ec71c9-49d7-4994-aa1e-638c9d522510@github.com>
Message-ID: <2KZuSkbfRYbI2gP1PuUx3OpOjikPXl1jEnHAV7Ww5-Y=.3399a3fe-40d8-48ac-bd0f-c488ac880598@github.com>

On Tue, 13 Jul 2021 17:21:52 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Please consider this proposal to add `divideExact()` methods for integral data types to `java.lang.Math` thereby rounding out "exact" support to all four basic arithmetic operations.

@rgiulietti Actually your trick is the fastest: `yours > via negateExact() > original`. Thanks!

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

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

From raffaello.giulietti at gmail.com  Wed Jul 14 19:57:23 2021
From: raffaello.giulietti at gmail.com (Raffaello Giulietti)
Date: Wed, 14 Jul 2021 21:57:23 +0200
Subject: RFR: 8075806: divideExact is missing in java.lang.Math
In-Reply-To: <2KZuSkbfRYbI2gP1PuUx3OpOjikPXl1jEnHAV7Ww5-Y=.3399a3fe-40d8-48ac-bd0f-c488ac880598@github.com>
References: <8nZ1xpS-Ir7KIEuaryZ0bQ2upeqcMy9TBm7-afE5lek=.22ec71c9-49d7-4994-aa1e-638c9d522510@github.com>
 <2KZuSkbfRYbI2gP1PuUx3OpOjikPXl1jEnHAV7Ww5-Y=.3399a3fe-40d8-48ac-bd0f-c488ac880598@github.com>
Message-ID: <dd09862b-97ee-ed0a-c013-b9f3fa752194@gmail.com>

Mysteries of JIT compilation...


On 2021-07-14 21:53, Brian Burkhalter wrote:
> On Tue, 13 Jul 2021 17:21:52 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:
> 
>> Please consider this proposal to add `divideExact()` methods for integral data types to `java.lang.Math` thereby rounding out "exact" support to all four basic arithmetic operations.
> 
> @rgiulietti Actually your trick is the fastest: `yours > via negateExact() > original`. Thanks!
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/4770
> 

From bpb at openjdk.java.net  Wed Jul 14 19:59:49 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 14 Jul 2021 19:59:49 GMT
Subject: RFR: 8075806: divideExact is missing in java.lang.Math [v2]
In-Reply-To: <8nZ1xpS-Ir7KIEuaryZ0bQ2upeqcMy9TBm7-afE5lek=.22ec71c9-49d7-4994-aa1e-638c9d522510@github.com>
References: <8nZ1xpS-Ir7KIEuaryZ0bQ2upeqcMy9TBm7-afE5lek=.22ec71c9-49d7-4994-aa1e-638c9d522510@github.com>
Message-ID: <cxqiOS_vGCa2uEgWnvYg-GXWxxehHsLeYotV3y9gJQA=.eb92bf2f-4f3b-413b-9ec5-bc0ac26f7f28@github.com>

> Please consider this proposal to add `divideExact()` methods for integral data types to `java.lang.Math` thereby rounding out "exact" support to all four basic arithmetic operations.

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

  8075806: Separate div-by-0 verbiage; change impl

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4770/files
  - new: https://git.openjdk.java.net/jdk/pull/4770/files/db216a6d..6843e666

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

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

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

From bpb at openjdk.java.net  Wed Jul 14 19:59:52 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 14 Jul 2021 19:59:52 GMT
Subject: RFR: 8075806: divideExact is missing in java.lang.Math [v2]
In-Reply-To: <K-P-25qjIB0Ew7ytkAj_JoqdO3yi0JU7Czm6weusicc=.8d76ae2e-96cd-4842-aff2-959f36a6726b@github.com>
References: <8nZ1xpS-Ir7KIEuaryZ0bQ2upeqcMy9TBm7-afE5lek=.22ec71c9-49d7-4994-aa1e-638c9d522510@github.com>
 <K-P-25qjIB0Ew7ytkAj_JoqdO3yi0JU7Czm6weusicc=.8d76ae2e-96cd-4842-aff2-959f36a6726b@github.com>
Message-ID: <xu1rZQoWb02rVYIBnRoQalXAHsT3TvSw2CfYJoZhlWY=.c86812a4-f0cd-48d9-ae45-78f731432d4c@github.com>

On Wed, 14 Jul 2021 16:43:32 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8075806: Separate div-by-0 verbiage; change impl
>
> src/java.base/share/classes/java/lang/Math.java line 1008:
> 
>> 1006:      * Returns the quotient of the arguments, throwing an exception if the
>> 1007:      * result overflows an {@code int}.  Such overflow can occur if and only
>> 1008:      * if either {@code y} is zero, or both {@code x} is
> 
> I think the divide by zero case should be discussed separately from overflow.

Fixed.

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

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

From bpb at openjdk.java.net  Wed Jul 14 20:02:15 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 14 Jul 2021 20:02:15 GMT
Subject: RFR: 8075806: divideExact is missing in java.lang.Math
In-Reply-To: <K-P-25qjIB0Ew7ytkAj_JoqdO3yi0JU7Czm6weusicc=.8d76ae2e-96cd-4842-aff2-959f36a6726b@github.com>
References: <8nZ1xpS-Ir7KIEuaryZ0bQ2upeqcMy9TBm7-afE5lek=.22ec71c9-49d7-4994-aa1e-638c9d522510@github.com>
 <K-P-25qjIB0Ew7ytkAj_JoqdO3yi0JU7Czm6weusicc=.8d76ae2e-96cd-4842-aff2-959f36a6726b@github.com>
Message-ID: <Q5XZ_LlkJgmKGaPHe2el19hhamG7UPx5niYUt1ksL28=.c07106c3-2664-4b36-975f-7650cc8e4ecb@github.com>

On Wed, 14 Jul 2021 16:45:20 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Are there examples in the JDK or its tests where a method with this definition would be used?

I have not identified any as yet. I did verify however that there are no uses in `open/src/**/*.java` of either `absExact()` or `negateExact()`, only their implementations in `[Strict]Math`.

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

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

From naoto at openjdk.java.net  Wed Jul 14 21:01:56 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 14 Jul 2021 21:01:56 GMT
Subject: RFR: 8260265: UTF-8 by Default
In-Reply-To: <hVB_4QQWVmsnUgqcTXGIS_KT2zacBhMpkHjEXTZVpmo=.dd2c4d41-4b24-4c23-8e1d-39620180e64d@github.com>
References: <-F4rYMOBcR8vg_mtYrJ--Ovx9d5bDLTF2p40uV5QqMM=.9cfd49ad-be84-4455-9695-138203395b21@github.com>
 <hVB_4QQWVmsnUgqcTXGIS_KT2zacBhMpkHjEXTZVpmo=.dd2c4d41-4b24-4c23-8e1d-39620180e64d@github.com>
Message-ID: <WhLFPaxwhQQL5bLycgb2MLB_mc0bhhW12qCVIJ1QOQU=.63c1679f-e0fd-48e2-b6a2-3b5c16ff4d68@github.com>

On Wed, 14 Jul 2021 12:39:46 GMT, Giacomo Baso <github.com+12575901+gbaso at openjdk.org> wrote:

> > Consider an application that creates a java.io.FileWriter with its one-argument constructor and then uses it to write some text to a file. The resulting file will contain a sequence of bytes encoded using the default charset of the JDK running the application. A second application, run on a different machine or by a different user on the same machine, creates a java.io.FileReader with its one-argument constructor and uses it to read the bytes in that file. The resulting text contains a sequence of characters decoded using the default charset of the JDK running the second application. If the default charset differs between the JDK of the first application and the JDK of the second application, then the resulting text may be silently corrupted or incomplete, since these APIs replace erroneous input rather than fail.
> 
> It's even worse than that, because many OpenSSH installs are configured by default to [forward](https://man.openbsd.org/ssh_config.5#SendEnv) and [accept](https://man.openbsd.org/sshd_config.5#AcceptEnv) the user locale (see e.g. for [RHEL 7](https://access.redhat.com/solutions/974273)).
> 
> So a single application, on a single remote machine, can be unknowingly started by a single user with different locales, and therefore different encodings, depending on how the user connected to the remote machine. For example, on Windows connecting via powershell results in `LANG=en_US.UTF-8`, while using WSL2 results in `LANG=C.UTF-8`. On Java 11 in a RHEL7 machine, `file.encoding` results in `UTF-8` in the first case, but `ANSI_X3.4-1968` in the second, leading to a default charset `ASCII`.
> 
> Worth mentioning is also that `Charset.forName("default")` is just an alias to `ASCII`, per `sun.nio.cs.StandardCharsets$Aliases`.

Thanks. Updated the JEP.

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

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

From naoto at openjdk.java.net  Wed Jul 14 21:01:55 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 14 Jul 2021 21:01:55 GMT
Subject: RFR: 8260265: UTF-8 by Default [v2]
In-Reply-To: <-F4rYMOBcR8vg_mtYrJ--Ovx9d5bDLTF2p40uV5QqMM=.9cfd49ad-be84-4455-9695-138203395b21@github.com>
References: <-F4rYMOBcR8vg_mtYrJ--Ovx9d5bDLTF2p40uV5QqMM=.9cfd49ad-be84-4455-9695-138203395b21@github.com>
Message-ID: <B7ffcQKrPzIYizQPvFASYg-pMwGAtOo-_2K5ZJLrrB8=.0a9b02df-570c-44a7-adde-6aff7ad6840d@github.com>

> This is an implementation for the `JEP 400: UTF-8 by Default`. The gist of the changes is `Charset.defaultCharset()` returning `UTF-8` and `file.encoding` system property being added in the spec, but another notable modification is in `java.io.PrintStream` where it continues to use the `Console` encoding as the default charset instead of `UTF-8`. Other changes are mostly clarification of the term "default charset" and their links. Corresponding CSR has also been drafted.
> 
> JEP 400: https://bugs.openjdk.java.net/browse/JDK-8187041
> CSR: https://bugs.openjdk.java.net/browse/JDK-8260266

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 three additional commits since the last revision:

 - Reflects review comments
 - Merge branch 'master' into JDK-8260265
 - 8260265: UTF-8 by Default

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4733/files
  - new: https://git.openjdk.java.net/jdk/pull/4733/files/107210cf..981200f7

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

  Stats: 6434 lines in 314 files changed: 3877 ins; 1452 del; 1105 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4733.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4733/head:pull/4733

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

From naoto at openjdk.java.net  Wed Jul 14 21:02:06 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 14 Jul 2021 21:02:06 GMT
Subject: RFR: 8260265: UTF-8 by Default [v2]
In-Reply-To: <UeYH9TsbiwM8PkBGqoEaanv8umkXj-pOdrDVA7lZelk=.2b55829d-f622-43f7-88fa-e35ef5ee29f3@github.com>
References: <-F4rYMOBcR8vg_mtYrJ--Ovx9d5bDLTF2p40uV5QqMM=.9cfd49ad-be84-4455-9695-138203395b21@github.com>
 <UeYH9TsbiwM8PkBGqoEaanv8umkXj-pOdrDVA7lZelk=.2b55829d-f622-43f7-88fa-e35ef5ee29f3@github.com>
Message-ID: <9b5I8UB7Gga5-GGr5MOQ9XkQczDYXLFULQqboIFq-yw=.dd407e26-aa6d-45d5-8bfc-c12cacb6b008@github.com>

On Wed, 14 Jul 2021 14:55:39 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> 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 three additional commits since the last revision:
>> 
>>  - Reflects review comments
>>  - Merge branch 'master' into JDK-8260265
>>  - 8260265: UTF-8 by Default
>
> src/java.base/share/classes/java/io/Console.java line 587:
> 
>> 585:                 try {
>> 586:                     cs = Charset.forName(csname);
>> 587:                 } catch (Exception ignored) { }
> 
> A separate enhancement...
> I've long thought that should be a way to avoid the exception here.
> For example,  a Charset.forName(csname, default);
> The caller might have a default in mind or supply null and then be able to test for null.

Agreed. Will file an RFE for this.

> src/java.base/share/classes/java/io/FileReader.java line 41:
> 
>> 39:  * @see InputStreamReader
>> 40:  * @see FileInputStream
>> 41:  * @see java.nio.charset.Charset#defaultCharset()
> 
> The @ see duplicates the link above, the javadoc can do without the @ see.

If I remove that `@see`, I don't see the link in `See Also` section. Am I missing something?

> src/java.base/share/classes/java/lang/System.java line 802:
> 
>> 800:      * <tr><th scope="row">{@systemProperty file.encoding}</th>
>> 801:      *     <td>The name of the default charset. Users may specify
>> 802:      *     {@code UTF-8} or {@code COMPAT} on the command line to the value.
> 
> The wording could imply that only those two values can be supplied.
> It could be rephrased to say that *if* the property is supplied on the command line
> it overrides the default UTF-8.

That was intentional. Only those two are supported, others continue to work as before (but not supported).

> src/java.base/share/classes/java/nio/charset/Charset.java line 601:
> 
>> 599:      * value designates {@code COMPAT}, the default charset is derived from
>> 600:      * the {@code native.encoding} system property, which typically depends
>> 601:      * upon the locale and charset of the underlying operating system.
> 
> The description in java.lang.System of the file.encoding property does not indicate it is 'implementation specific'.
> In that context, it appears to be part of the JavaSE spec.
> Having the spec in a single place with references to it from others could avoid duplication.

`file.encoding` is listed under `@implNote` tag in `System.getProperties()`, so it is implementation-specific.

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

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

From naoto at openjdk.java.net  Wed Jul 14 21:02:07 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 14 Jul 2021 21:02:07 GMT
Subject: RFR: 8260265: UTF-8 by Default [v2]
In-Reply-To: <CfPGzp7d9VB6tJmMvdwQywehKXTRZ2EvZ6TPh7Kr8U4=.e54a31b2-6c08-47f3-9a89-42d9f74f944a@github.com>
References: <-F4rYMOBcR8vg_mtYrJ--Ovx9d5bDLTF2p40uV5QqMM=.9cfd49ad-be84-4455-9695-138203395b21@github.com>
 <UeYH9TsbiwM8PkBGqoEaanv8umkXj-pOdrDVA7lZelk=.2b55829d-f622-43f7-88fa-e35ef5ee29f3@github.com>
 <CfPGzp7d9VB6tJmMvdwQywehKXTRZ2EvZ6TPh7Kr8U4=.e54a31b2-6c08-47f3-9a89-42d9f74f944a@github.com>
Message-ID: <43ZOj506cWqOBeux12Q8eBEE_iCtGWW_6YiCzazQDiY=.a29fcbce-3195-4fa0-b22b-4b8f4fefc1b5@github.com>

On Wed, 14 Jul 2021 16:20:28 GMT, Jesse Glick <github.com+154109+jglick at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/PrintStream.java line 49:
>> 
>>> 47:  * <p> All characters printed by a {@code PrintStream} are converted into
>>> 48:  * bytes using the given encoding or charset, or the default
>>> 49:  * console charset if not specified.
>> 
>> JEP 400 doesn't give a rationale for using the console charset for PrintStream.
>> PrintStreams are used for output to files and other media other than just a tty/console.
>> The charset of system.out/err should use the console charset.
>
> This was my thinking in https://github.com/openjdk/jdk/pull/4733#issuecomment-876793372.

OK, I am now conviced. Modified not to default to Console.charset() for generic PrintStream w/o charset constructor.

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

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

From rriggs at openjdk.java.net  Wed Jul 14 21:09:15 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 14 Jul 2021 21:09:15 GMT
Subject: RFR: 8260265: UTF-8 by Default [v2]
In-Reply-To: <9b5I8UB7Gga5-GGr5MOQ9XkQczDYXLFULQqboIFq-yw=.dd407e26-aa6d-45d5-8bfc-c12cacb6b008@github.com>
References: <-F4rYMOBcR8vg_mtYrJ--Ovx9d5bDLTF2p40uV5QqMM=.9cfd49ad-be84-4455-9695-138203395b21@github.com>
 <UeYH9TsbiwM8PkBGqoEaanv8umkXj-pOdrDVA7lZelk=.2b55829d-f622-43f7-88fa-e35ef5ee29f3@github.com>
 <9b5I8UB7Gga5-GGr5MOQ9XkQczDYXLFULQqboIFq-yw=.dd407e26-aa6d-45d5-8bfc-c12cacb6b008@github.com>
Message-ID: <9jHHvVP67dsNtuMevEoMYxNq9P35RXOygFNlqCg3rdI=.228cb59e-3924-4d8b-961e-1e6e28f4ee38@github.com>

On Wed, 14 Jul 2021 20:53:34 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/FileReader.java line 41:
>> 
>>> 39:  * @see InputStreamReader
>>> 40:  * @see FileInputStream
>>> 41:  * @see java.nio.charset.Charset#defaultCharset()
>> 
>> The @ see duplicates the link above, the javadoc can do without the @ see.
>
> If I remove that `@see`, I don't see the link in `See Also` section. Am I missing something?

In my view the @ linkplain is sufficient to allow the reader to navigate; but YMMV.

>> src/java.base/share/classes/java/lang/System.java line 802:
>> 
>>> 800:      * <tr><th scope="row">{@systemProperty file.encoding}</th>
>>> 801:      *     <td>The name of the default charset. Users may specify
>>> 802:      *     {@code UTF-8} or {@code COMPAT} on the command line to the value.
>> 
>> The wording could imply that only those two values can be supplied.
>> It could be rephrased to say that *if* the property is supplied on the command line
>> it overrides the default UTF-8.
>
> That was intentional. Only those two are supported, others continue to work as before (but not supported).

Still it leaves an uncomfortable feeling, perhaps remedied by an "other values have unspecified behavior"
or the "other values are implementation specific".

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

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

From duke at openjdk.java.net  Wed Jul 14 21:12:17 2021
From: duke at openjdk.java.net (duke)
Date: Wed, 14 Jul 2021 21:12:17 GMT
Subject: Withdrawn: 8266936: Add a finalization JFR event
In-Reply-To: <AF0NVw4J824FO3M0kCZ1Z-VmCf6OSygLe-j33HPRkV4=.8220fedc-97b3-4778-a9d8-4c6f8057d308@github.com>
References: <AF0NVw4J824FO3M0kCZ1Z-VmCf6OSygLe-j33HPRkV4=.8220fedc-97b3-4778-a9d8-4c6f8057d308@github.com>
Message-ID: <xX2223NYZk1puuxwXpwtgg91ReBVOckZyce3of0wZUQ=.5e44fc15-e5f8-4628-bfdf-381dca476336@github.com>

On Tue, 18 May 2021 20:55:10 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> Please review this enhancement to add a new JFR event, generated whenever a finalizer is run.
> (The makeup is similar to the Deserialization event, [JDK-8261160](https://bugs.openjdk.java.net/browse/JDK-8261160).)
> 
> The event's only datum (beyond those common to all jfr events) is the class of the object that was finalized.
> 
> The Category for the event:
> `"Java Virtual Machine" / "GC" / "Finalization"`
> is what made sense to me, even though the event is generated from library code.
> 
> Along with the new regtest, I added a run mode to the basic finalizer test to enable jfr.
> Automated testing looks good so far.
> 
> Thanks,
> -Brent

This pull request has been closed without being integrated.

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

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

From jwilhelm at openjdk.java.net  Wed Jul 14 21:43:43 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Wed, 14 Jul 2021 21:43:43 GMT
Subject: RFR: Merge jdk17
Message-ID: <mGFja6UZbJ_96gghTVJxjyMQfLBeFCWO27006sRTdKo=.a280d3bc-fc00-4333-ae62-75e6a9c978d5@github.com>

Forwardport JDK 17 -> JDK 18

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

Commit messages:
 - Merge
 - 8270422: Test build/AbsPathsInImage.java fails after JDK-8259848
 - 8266313: (JEP-356) - RandomGenerator spec implementation requirements tightly coupled to JDK internal classes
 - 8270075: SplittableRandom extends AbstractSplittableGenerator
 - 8266889: [macosx-aarch64] Crash with SIGBUS in MarkActivationClosure::do_code_blob during vmTestbase/nsk/jvmti/.../bi04t002 test run
 - 8259499: Handling type arguments from outer classes for inner class in javadoc
 - 8268620: InfiniteLoopException test may fail on x86 platforms
 - 8269865: Async UL needs to handle ERANGE on exceeding SEM_VALUE_MAX
 - 8270056: Generated lambda class can not access protected static method of target class

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

Changes: https://git.openjdk.java.net/jdk/pull/4786/files
  Stats: 328 lines in 19 files changed: 240 ins; 14 del; 74 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4786.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4786/head:pull/4786

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

From naoto at openjdk.java.net  Wed Jul 14 22:02:40 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 14 Jul 2021 22:02:40 GMT
Subject: RFR: 8260265: UTF-8 by Default [v3]
In-Reply-To: <9jHHvVP67dsNtuMevEoMYxNq9P35RXOygFNlqCg3rdI=.228cb59e-3924-4d8b-961e-1e6e28f4ee38@github.com>
References: <-F4rYMOBcR8vg_mtYrJ--Ovx9d5bDLTF2p40uV5QqMM=.9cfd49ad-be84-4455-9695-138203395b21@github.com>
 <UeYH9TsbiwM8PkBGqoEaanv8umkXj-pOdrDVA7lZelk=.2b55829d-f622-43f7-88fa-e35ef5ee29f3@github.com>
 <9b5I8UB7Gga5-GGr5MOQ9XkQczDYXLFULQqboIFq-yw=.dd407e26-aa6d-45d5-8bfc-c12cacb6b008@github.com>
 <9jHHvVP67dsNtuMevEoMYxNq9P35RXOygFNlqCg3rdI=.228cb59e-3924-4d8b-961e-1e6e28f4ee38@github.com>
Message-ID: <ApQgEa7t4c-rJb0m7OJz_YyLIMox_iA_x6FNwANqG7Q=.c8839572-de05-4ffd-9718-d0eb3e62f023@github.com>

On Wed, 14 Jul 2021 21:03:53 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> That was intentional. Only those two are supported, others continue to work as before (but not supported).
>
> Still it leaves an uncomfortable feeling, perhaps remedied by an "other values have unspecified behavior"
> or the "other values are implementation specific".

Added the clarifying sentence to the spec.

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

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

From naoto at openjdk.java.net  Wed Jul 14 22:02:40 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 14 Jul 2021 22:02:40 GMT
Subject: RFR: 8260265: UTF-8 by Default [v3]
In-Reply-To: <-F4rYMOBcR8vg_mtYrJ--Ovx9d5bDLTF2p40uV5QqMM=.9cfd49ad-be84-4455-9695-138203395b21@github.com>
References: <-F4rYMOBcR8vg_mtYrJ--Ovx9d5bDLTF2p40uV5QqMM=.9cfd49ad-be84-4455-9695-138203395b21@github.com>
Message-ID: <nh0COXGKraL-xbyigkatGYMkOj7JK7YRk2C5Untg3uw=.406ec387-4d67-4755-aedb-e84126569ed6@github.com>

> This is an implementation for the `JEP 400: UTF-8 by Default`. The gist of the changes is `Charset.defaultCharset()` returning `UTF-8` and `file.encoding` system property being added in the spec, but another notable modification is in `java.io.PrintStream` where it continues to use the `Console` encoding as the default charset instead of `UTF-8`. Other changes are mostly clarification of the term "default charset" and their links. Corresponding CSR has also been drafted.
> 
> JEP 400: https://bugs.openjdk.java.net/browse/JDK-8187041
> CSR: https://bugs.openjdk.java.net/browse/JDK-8260266

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

  Reflects comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4733/files
  - new: https://git.openjdk.java.net/jdk/pull/4733/files/981200f7..182dcb6d

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

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

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

From naoto at openjdk.java.net  Wed Jul 14 22:07:16 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 14 Jul 2021 22:07:16 GMT
Subject: RFR: 8260265: UTF-8 by Default [v3]
In-Reply-To: <9b5I8UB7Gga5-GGr5MOQ9XkQczDYXLFULQqboIFq-yw=.dd407e26-aa6d-45d5-8bfc-c12cacb6b008@github.com>
References: <-F4rYMOBcR8vg_mtYrJ--Ovx9d5bDLTF2p40uV5QqMM=.9cfd49ad-be84-4455-9695-138203395b21@github.com>
 <UeYH9TsbiwM8PkBGqoEaanv8umkXj-pOdrDVA7lZelk=.2b55829d-f622-43f7-88fa-e35ef5ee29f3@github.com>
 <9b5I8UB7Gga5-GGr5MOQ9XkQczDYXLFULQqboIFq-yw=.dd407e26-aa6d-45d5-8bfc-c12cacb6b008@github.com>
Message-ID: <B4IYyQ47yWU9NusI4IJZibVl74IkROB9wMw9zI-1F3c=.03c5ddce-0ff7-4852-9ee6-b83e72561902@github.com>

On Wed, 14 Jul 2021 20:52:54 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/Console.java line 587:
>> 
>>> 585:                 try {
>>> 586:                     cs = Charset.forName(csname);
>>> 587:                 } catch (Exception ignored) { }
>> 
>> A separate enhancement...
>> I've long thought that should be a way to avoid the exception here.
>> For example,  a Charset.forName(csname, default);
>> The caller might have a default in mind or supply null and then be able to test for null.
>
> Agreed. Will file an RFE for this.

https://bugs.openjdk.java.net/browse/JDK-8270490

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

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

From asemenyuk at openjdk.java.net  Wed Jul 14 22:25:16 2021
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Wed, 14 Jul 2021 22:25:16 GMT
Subject: RFR: JDK-8269387: jpackage --add-launcher should have option to
 not create shortcuts for additional launchers [v4]
In-Reply-To: <5fBBBZc7EnRAlikfeDllziaiB1jskH_Dy6VWh9Qp9ZE=.48aa8637-7c6d-4936-869d-22a31793362e@github.com>
References: <gO8--JRs2F9hyLuR5gnanY-KYiH-wYSexmUbDGeaP0Q=.e8fa9a64-1018-427f-b1f9-72fc48671b21@github.com>
 <5fBBBZc7EnRAlikfeDllziaiB1jskH_Dy6VWh9Qp9ZE=.48aa8637-7c6d-4936-869d-22a31793362e@github.com>
Message-ID: <NpR1h6A24m6Q8nfAv899cdt4WjzrYhG5DENotWWxPgk=.54d4f4a5-3d48-4211-997e-9e4afdf1da95@github.com>

On Wed, 14 Jul 2021 16:50:39 GMT, Andy Herrick <herrick at openjdk.org> wrote:

>> JDK-8269387: jpackage --add-launcher should have option to not create shortcuts for additional launchers
>
> Andy Herrick has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8269387: jpackage --add-launcher should have option to not create shortcuts for additional launchers

Marked as reviewed by asemenyuk (Reviewer).

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

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

From jwilhelm at openjdk.java.net  Wed Jul 14 22:41:17 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Wed, 14 Jul 2021 22:41:17 GMT
Subject: Integrated: Merge jdk17
In-Reply-To: <mGFja6UZbJ_96gghTVJxjyMQfLBeFCWO27006sRTdKo=.a280d3bc-fc00-4333-ae62-75e6a9c978d5@github.com>
References: <mGFja6UZbJ_96gghTVJxjyMQfLBeFCWO27006sRTdKo=.a280d3bc-fc00-4333-ae62-75e6a9c978d5@github.com>
Message-ID: <sGptrGoMWdfmglTBg4lrKMFgV97Fo8frf7llENg52ts=.1cdeff58-963c-4352-a72c-9c29187244b3@github.com>

On Wed, 14 Jul 2021 21:35:34 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 17 -> JDK 18

This pull request has now been integrated.

Changeset: 7d0edb57
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/7d0edb5743aacfc22f76ee8aa7b03d7dc0f90dca
Stats:     328 lines in 19 files changed: 240 ins; 14 del; 74 mod

Merge

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

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

From almatvee at openjdk.java.net  Wed Jul 14 23:33:10 2021
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Wed, 14 Jul 2021 23:33:10 GMT
Subject: RFR: JDK-8269387: jpackage --add-launcher should have option to
 not create shortcuts for additional launchers [v4]
In-Reply-To: <5fBBBZc7EnRAlikfeDllziaiB1jskH_Dy6VWh9Qp9ZE=.48aa8637-7c6d-4936-869d-22a31793362e@github.com>
References: <gO8--JRs2F9hyLuR5gnanY-KYiH-wYSexmUbDGeaP0Q=.e8fa9a64-1018-427f-b1f9-72fc48671b21@github.com>
 <5fBBBZc7EnRAlikfeDllziaiB1jskH_Dy6VWh9Qp9ZE=.48aa8637-7c6d-4936-869d-22a31793362e@github.com>
Message-ID: <rVyeOoR9G9-stUKy8X6o1Ga1fmp4NcpCNTL0ancJi0I=.1e7faa6b-778e-4c8f-8317-64c21df7b67e@github.com>

On Wed, 14 Jul 2021 16:50:39 GMT, Andy Herrick <herrick at openjdk.org> wrote:

>> JDK-8269387: jpackage --add-launcher should have option to not create shortcuts for additional launchers
>
> Andy Herrick has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8269387: jpackage --add-launcher should have option to not create shortcuts for additional launchers

Marked as reviewed by almatvee (Reviewer).

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

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

From henryjen at openjdk.java.net  Wed Jul 14 23:55:15 2021
From: henryjen at openjdk.java.net (Henry Jen)
Date: Wed, 14 Jul 2021 23:55:15 GMT
Subject: RFR: 8236569: -Xss not multiple of 4K does not work for the main
 thread on macOS [v5]
In-Reply-To: <Y2sqCUuxdLi6yvPQMy9LCi_UfIw_-07j797zsJ_WHzI=.7de11f2f-1019-4241-9bde-1a4dee830810@github.com>
References: <4MLFDLQaF5jyv5Nee-RfP6zREmqUk2tgSmveCDXUDWo=.b9381e50-213b-49bb-9894-933a537ef3ab@github.com>
 <HIrHmTwFZsUjUS_pJN9ObXhu5yUJIfkIaBOcbkZISmU=.856a68f5-2914-4c6d-82fa-8853b7b9e345@github.com>
 <Y2sqCUuxdLi6yvPQMy9LCi_UfIw_-07j797zsJ_WHzI=.7de11f2f-1019-4241-9bde-1a4dee830810@github.com>
Message-ID: <CRKN1_U7ONxbB6EicTexDoupaUaeZXWAVpNo2jxGrTc=.27fb2c29-2632-4f93-befc-f2b749c4d2ca@github.com>

On Tue, 8 Jun 2021 13:37:10 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Henry Jen has updated the pull request with a new target base 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:
>> 
>>  - Cast type
>>  - Merge
>>  - Change java -X output for -Xss
>>  - Merge
>>  - Only try to round-up when current value failed
>>  - Avoid overflow on page size
>>  - JDK-8236569: -Xss not multiple of 4K does not work for the main thread on macOS
>
> Please make sure the failing tests have nothing to do with your patch. `gc/shenandoah/compiler/TestLinkToNativeRBP.java`
>  sounds at least suggestive.

Still pending CSR, also considering adapt hotspot align up as suggested by @tstuefe.

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

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

From whuang at openjdk.java.net  Thu Jul 15 03:30:50 2021
From: whuang at openjdk.java.net (Wang Huang)
Date: Thu, 15 Jul 2021 03:30:50 GMT
Subject: RFR: 8268231: Aarch64: Use ldp in intrinsics for String.compareTo
 [v3]
In-Reply-To: <nulsSsZPVaoQA13GVqYV0_3EY7duVRYPkz-vhZBfibg=.fc7a36e3-0f29-4a7e-91cc-141f9f82365a@github.com>
References: <XwW4MjGSYmSHa2ZbzrOfvoZi1pe8LJAK7YIKtmNhaDM=.d39df32e-8698-4608-9184-3b19cd175d1a@github.com>
 <B4QlLNxlUxwMUmJjgZG6e82vGN2tlnJeKsQ_1QCNlOE=.b99f2103-318f-40f1-89d6-1069dc0ba22d@github.com>
 <nulsSsZPVaoQA13GVqYV0_3EY7duVRYPkz-vhZBfibg=.fc7a36e3-0f29-4a7e-91cc-141f9f82365a@github.com>
Message-ID: <-l81L4M4MYzGm5OlJUGZmXKAIwmbw7Rm6t_7TxGIrq4=.b6266d5a-5396-4fa0-afa1-0264dfa6abfe@github.com>

On Wed, 14 Jul 2021 08:27:36 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

>> Wang Huang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   refact codes
>
> src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 4990:
> 
>> 4988:       __ lsrv(tmp2, tmp2, rscratch2);
>> 4989:       if (isLL) {
>> 4990:           __ uxtbw(tmp1, tmp1);
> 
> Convention is to indent with two spaces but have four here.

Thank you for your suggestion. I have fixed the style and add unalign test case in my new commit.

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

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

From whuang at openjdk.java.net  Thu Jul 15 03:30:46 2021
From: whuang at openjdk.java.net (Wang Huang)
Date: Thu, 15 Jul 2021 03:30:46 GMT
Subject: RFR: 8268231: Aarch64: Use ldp in intrinsics for String.compareTo
 [v4]
In-Reply-To: <XwW4MjGSYmSHa2ZbzrOfvoZi1pe8LJAK7YIKtmNhaDM=.d39df32e-8698-4608-9184-3b19cd175d1a@github.com>
References: <XwW4MjGSYmSHa2ZbzrOfvoZi1pe8LJAK7YIKtmNhaDM=.d39df32e-8698-4608-9184-3b19cd175d1a@github.com>
Message-ID: <F6md9mVnN7YiAwVrRTrLGaRVOGJp2PRCBUpaDRm__j4=.9a428b99-30d9-4c76-823a-19412c282ceb@github.com>

> Dear all, 
>     Can you do me a favor to review this patch. This patch use `ldp` to implement String.compareTo.
>    
> * We add a JMH test case 
> * Here is the result of this test case
>  
> Benchmark	                       |(size)| Mode| Cnt|Score | Error	 |Units	
> ---------------------------------|------|-----|----|------|--------|-----
> StringCompare.compareLL       |  64  | avgt| 5  |7.992 | ?	0.005|us/op
> StringCompare.compareLL       |  72  | avgt| 5  |15.029| ?	0.006|us/op
> StringCompare.compareLL       |  80  | avgt| 5  |14.655| ?	0.011|us/op
> StringCompare.compareLL       |  91  | avgt| 5  |16.363| ?	0.12 |us/op
> StringCompare.compareLL       |  101 | avgt| 5  |16.966| ?	0.007|us/op
> StringCompare.compareLL       |  121 | avgt| 5  |19.276| ?	0.006|us/op
> StringCompare.compareLL       |  181 | avgt| 5  |19.002| ?	0.417|us/op
> StringCompare.compareLL       |  256 | avgt| 5  |24.707| ?	0.041|us/op
> StringCompare.compareLLWithLdp|  64  | avgt| 5  |8.001	| ?	0.121|us/op
> StringCompare.compareLLWithLdp|  72  | avgt| 5  |11.573| ?	0.003|us/op
> StringCompare.compareLLWithLdp|  80  | avgt| 5  |6.861 | ?	0.004|us/op
> StringCompare.compareLLWithLdp|  91  | avgt| 5  |12.774| ?	0.201|us/op
> StringCompare.compareLLWithLdp|  101 | avgt| 5  |8.691 | ?	0.004|us/op
> StringCompare.compareLLWithLdp|  121 | avgt| 5  |11.091| ?	1.342|us/op
> StringCompare.compareLLWithLdp|  181 | avgt| 5  |14.64 | ?	0.581|us/op
> StringCompare.compareLLWithLdp|  256 | avgt| 5  |25.879| ?	1.775|us/op
> StringCompare.compareUU       |  64  | avgt| 5  |13.476| ?	0.01 |us/op
> StringCompare.compareUU       |  72  | avgt| 5  |15.078| ?	0.006|us/op
> StringCompare.compareUU       |  80  | avgt| 5  |23.512| ?	0.011|us/op
> StringCompare.compareUU       |  91  | avgt| 5  |24.284| ?	0.008|us/op
> StringCompare.compareUU       |  101 | avgt| 5  |20.707| ?	0.017|us/op
> StringCompare.compareUU       |  121 | avgt| 5  |29.302| ?	0.011|us/op
> StringCompare.compareUU       |  181 | avgt| 5  |39.31	| ?	0.016|us/op
> StringCompare.compareUU       |  256 | avgt| 5  |54.592| ?	0.392|us/op
> StringCompare.compareUUWithLdp|  64  | avgt| 5  |16.389| ?	0.008|us/op
> StringCompare.compareUUWithLdp|  72  | avgt| 5  |10.71 | ?	0.158|us/op
> StringCompare.compareUUWithLdp|  80  | avgt| 5  |11.488| ?	0.024|us/op
> StringCompare.compareUUWithLdp|  91  | avgt| 5  |13.412| ?	0.006|us/op
> StringCompare.compareUUWithLdp|  101 | avgt| 5  |16.245| ?	0.434|us/op
> StringCompare.compareUUWithLdp|  121 | avgt| 5  |16.597| ?	0.016|us/op
> StringCompare.compareUUWithLdp|  181 | avgt| 5  |27.373| ?	0.017|us/op
> StringCompare.compareUUWithLdp|  256 | avgt| 5  |41.74 | ?	3.5	 |us/op
> 
> From this table, we can see that in most cases, our patch is better than old one.
> 
> Thank you for your review. Any suggestions are welcome.

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

  fix style and add unalign test case

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4722/files
  - new: https://git.openjdk.java.net/jdk/pull/4722/files/3fa9afcb..c85cd126

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

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

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

From jbhateja at openjdk.java.net  Thu Jul 15 08:34:42 2021
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Thu, 15 Jul 2021 08:34:42 GMT
Subject: RFR: 8266054: VectorAPI rotate operation optimization [v10]
In-Reply-To: <OZ2u4DDNaYF3WiR5uU6NWvzPMKV3j8QAO_mZyLP3Isg=.594e3514-8a5a-442c-ac1a-ca6c6d14e963@github.com>
References: <OZ2u4DDNaYF3WiR5uU6NWvzPMKV3j8QAO_mZyLP3Isg=.594e3514-8a5a-442c-ac1a-ca6c6d14e963@github.com>
Message-ID: <j-MimQL3RfOga-_XaS0UWHPsmDp99CyUer8f_bFptmo=.231d4cc0-e9ee-47d8-ad6c-41adcf114367@github.com>

> Current VectorAPI Java side implementation expresses rotateLeft and rotateRight operation using following operations:-
> 
>     vec1 = lanewise(VectorOperators.LSHL, n)
>     vec2 = lanewise(VectorOperators.LSHR, n)
>     res = lanewise(VectorOperations.OR, vec1 , vec2)
> 
> This patch moves above handling from Java side to C2 compiler which facilitates dismantling the rotate operation if target ISA does not support a direct rotate instruction.
> 
> AVX512 added vector rotate instructions vpro[rl][v][dq] which operate over long and integer type vectors. For other cases (i.e. sub-word type vectors or for targets which do not support direct rotate operations )   instruction sequence comprising of vector SHIFT (LEFT/RIGHT) and vector OR is emitted.
> 
> Please find below the performance data for included JMH benchmark.
> Machine:  Cascade Lake Server (Intel(R) Xeon(R) Platinum 8280 CPU @ 2.70GHz)
> 
> 
> Benchmark | (TESTSIZE) | Shift | Baseline AVX3 (ops/ms) | Withopt? AVX3 (ops/ms) | Gain % | Baseline AVX2 (ops/ms) | Withopt AVX2 (ops/ms) | Gain %
> -- | -- | -- | -- | -- | -- | -- | -- | --
> ? | ? | ? | ? | ? | ? | ? | ? | ?
> RotateBenchmark.testRotateLeftB | 128.00 | 7.00 | 17223.35 | 17094.69 | -0.75 | 17008.32 | 17488.06 | 2.82
> RotateBenchmark.testRotateLeftB | 128.00 | 7.00 | 8944.98 | 8811.34 | -1.49 | 8878.17 | 9218.68 | 3.84
> RotateBenchmark.testRotateLeftB | 128.00 | 15.00 | 17195.75 | 17137.32 | -0.34 | 16789.01 | 17780.34 | 5.90
> RotateBenchmark.testRotateLeftB | 128.00 | 15.00 | 9052.67 | 8838.60 | -2.36 | 8814.62 | 9206.01 | 4.44
> RotateBenchmark.testRotateLeftB | 128.00 | 31.00 | 17100.19 | 16950.64 | -0.87 | 16827.73 | 17720.37 | 5.30
> RotateBenchmark.testRotateLeftB | 128.00 | 31.00 | 9079.95 | 8471.26 | -6.70 | 8888.44 | 9167.68 | 3.14
> RotateBenchmark.testRotateLeftB | 256.00 | 7.00 | 21231.33 | 21513.08 | 1.33 | 21824.51 | 21479.48 | -1.58
> RotateBenchmark.testRotateLeftB | 256.00 | 7.00 | 11103.62 | 11180.16 | 0.69 | 11173.67 | 11529.22 | 3.18
> RotateBenchmark.testRotateLeftB | 256.00 | 15.00 | 21119.14 | 21552.04 | 2.05 | 21693.05 | 21915.37 | 1.02
> RotateBenchmark.testRotateLeftB | 256.00 | 15.00 | 11048.68 | 11094.20 | 0.41 | 11049.90 | 11439.07 | 3.52
> RotateBenchmark.testRotateLeftB | 256.00 | 31.00 | 21506.31 | 21391.41 | -0.53 | 21263.18 | 21986.29 | 3.40
> RotateBenchmark.testRotateLeftB | 256.00 | 31.00 | 11056.12 | 11232.78 | 1.60 | 10941.59 | 11397.09 | 4.16
> RotateBenchmark.testRotateLeftB | 512.00 | 7.00 | 17976.56 | 18180.85 | 1.14 | 1212.26 | 2533.34 | 108.98
> RotateBenchmark.testRotateLeftB | 512.00 | 15.00 | 17553.70 | 18219.07 | 3.79 | 1256.73 | 2537.41 | 101.91
> RotateBenchmark.testRotateLeftB | 512.00 | 31.00 | 17618.03 | 17738.15 | 0.68 | 1214.69 | 2533.83 | 108.60
> RotateBenchmark.testRotateLeftI | 128.00 | 7.00 | 7258.87 | 7468.88 | 2.89 | 7115.12 | 7117.26 | 0.03
> RotateBenchmark.testRotateLeftI | 128.00 | 7.00 | 3586.65 | 3950.85 | 10.15 | 3532.17 | 3595.80 | 1.80
> RotateBenchmark.testRotateLeftI | 128.00 | 7.00 | 1835.07 | 1999.68 | 8.97 | 1789.90 | 1819.93 | 1.68
> RotateBenchmark.testRotateLeftI | 128.00 | 15.00 | 7273.36 | 7410.91 | 1.89 | 7198.60 | 6994.79 | -2.83
> RotateBenchmark.testRotateLeftI | 128.00 | 15.00 | 3674.98 | 3926.27 | 6.84 | 3549.90 | 3755.09 | 5.78
> RotateBenchmark.testRotateLeftI | 128.00 | 15.00 | 1840.94 | 1882.25 | 2.24 | 1801.56 | 1872.89 | 3.96
> RotateBenchmark.testRotateLeftI | 128.00 | 31.00 | 7457.11 | 7361.48 | -1.28 | 6975.33 | 7385.94 | 5.89
> RotateBenchmark.testRotateLeftI | 128.00 | 31.00 | 3570.74 | 3929.30 | 10.04 | 3635.37 | 3736.67 | 2.79
> RotateBenchmark.testRotateLeftI | 128.00 | 31.00 | 1902.32 | 1960.46 | 3.06 | 1812.32 | 1813.88 | 0.09
> RotateBenchmark.testRotateLeftI | 256.00 | 7.00 | 11174.24 | 12044.52 | 7.79 | 11509.87 | 11273.44 | -2.05
> RotateBenchmark.testRotateLeftI | 256.00 | 7.00 | 5981.47 | 6073.70 | 1.54 | 5593.66 | 5661.93 | 1.22
> RotateBenchmark.testRotateLeftI | 256.00 | 7.00 | 2932.49 | 3069.54 | 4.67 | 2950.86 | 2892.42 | -1.98
> RotateBenchmark.testRotateLeftI | 256.00 | 15.00 | 11764.11 | 12098.63 | 2.84 | 11069.52 | 11476.93 | 3.68
> RotateBenchmark.testRotateLeftI | 256.00 | 15.00 | 5855.20 | 6080.40 | 3.85 | 5919.11 | 5607.04 | -5.27
> RotateBenchmark.testRotateLeftI | 256.00 | 15.00 | 2989.05 | 3048.56 | 1.99 | 2902.63 | 2821.83 | -2.78
> RotateBenchmark.testRotateLeftI | 256.00 | 31.00 | 11652.84 | 11965.40 | 2.68 | 11525.62 | 11459.83 | -0.57
> RotateBenchmark.testRotateLeftI | 256.00 | 31.00 | 5851.82 | 6164.94 | 5.35 | 5882.60 | 5842.30 | -0.69
> RotateBenchmark.testRotateLeftI | 256.00 | 31.00 | 3015.99 | 3043.79 | 0.92 | 2963.71 | 2947.97 | -0.53
> RotateBenchmark.testRotateLeftI | 512.00 | 7.00 | 16029.15 | 16189.79 | 1.00 | 860.43 | 2339.32 | 171.88
> RotateBenchmark.testRotateLeftI | 512.00 | 7.00 | 8078.25 | 8081.84 | 0.04 | 427.39 | 1147.92 | 168.59
> RotateBenchmark.testRotateLeftI | 512.00 | 7.00 | 4021.49 | 4294.03 | 6.78 | 209.25 | 582.28 | 178.27
> RotateBenchmark.testRotateLeftI | 512.00 | 15.00 | 15912.98 | 16329.03 | 2.61 | 848.23 | 2296.78 | 170.77
> RotateBenchmark.testRotateLeftI | 512.00 | 15.00 | 8054.10 | 8306.37 | 3.13 | 429.93 | 1146.90 | 166.77
> RotateBenchmark.testRotateLeftI | 512.00 | 15.00 | 4102.58 | 4071.08 | -0.77 | 217.86 | 582.20 | 167.24
> RotateBenchmark.testRotateLeftI | 512.00 | 31.00 | 16177.79 | 16287.85 | 0.68 | 857.84 | 2243.15 | 161.49
> RotateBenchmark.testRotateLeftI | 512.00 | 31.00 | 8187.47 | 8410.48 | 2.72 | 434.60 | 1128.20 | 159.60
> RotateBenchmark.testRotateLeftI | 512.00 | 31.00 | 4109.15 | 4233.80 | 3.03 | 208.71 | 572.43 | 174.27
> RotateBenchmark.testRotateLeftL | 128.00 | 7.00 | 3755.09 | 3930.29 | 4.67 | 3604.19 | 3598.47 | -0.16
> RotateBenchmark.testRotateLeftL | 128.00 | 7.00 | 1829.03 | 1957.39 | 7.02 | 1833.95 | 1808.38 | -1.39
> RotateBenchmark.testRotateLeftL | 128.00 | 7.00 | 915.35 | 970.55 | 6.03 | 916.25 | 899.08 | -1.87
> RotateBenchmark.testRotateLeftL | 128.00 | 15.00 | 3664.85 | 3812.26 | 4.02 | 3629.37 | 3579.23 | -1.38
> RotateBenchmark.testRotateLeftL | 128.00 | 15.00 | 1829.51 | 1877.76 | 2.64 | 1781.05 | 1807.57 | 1.49
> RotateBenchmark.testRotateLeftL | 128.00 | 15.00 | 913.37 | 953.42 | 4.38 | 912.26 | 908.73 | -0.39
> RotateBenchmark.testRotateLeftL | 128.00 | 31.00 | 3648.45 | 3899.20 | 6.87 | 3552.67 | 3581.04 | 0.80
> RotateBenchmark.testRotateLeftL | 128.00 | 31.00 | 1816.50 | 1959.68 | 7.88 | 1820.88 | 1819.71 | -0.06
> RotateBenchmark.testRotateLeftL | 128.00 | 31.00 | 901.05 | 955.13 | 6.00 | 913.74 | 907.90 | -0.64
> RotateBenchmark.testRotateLeftL | 256.00 | 7.00 | 5850.99 | 6108.64 | 4.40 | 5882.65 | 5755.21 | -2.17
> RotateBenchmark.testRotateLeftL | 256.00 | 7.00 | 2962.21 | 3060.47 | 3.32 | 2955.20 | 2909.18 | -1.56
> RotateBenchmark.testRotateLeftL | 256.00 | 7.00 | 1480.46 | 1534.72 | 3.66 | 1467.78 | 1430.60 | -2.53
> RotateBenchmark.testRotateLeftL | 256.00 | 15.00 | 5858.23 | 6047.51 | 3.23 | 5770.02 | 5773.19 | 0.05
> RotateBenchmark.testRotateLeftL | 256.00 | 15.00 | 2951.49 | 3096.53 | 4.91 | 2885.21 | 2899.31 | 0.49
> RotateBenchmark.testRotateLeftL | 256.00 | 15.00 | 1486.26 | 1527.94 | 2.80 | 1441.93 | 1454.25 | 0.85
> RotateBenchmark.testRotateLeftL | 256.00 | 31.00 | 5873.21 | 6089.75 | 3.69 | 5767.58 | 5664.11 | -1.79
> RotateBenchmark.testRotateLeftL | 256.00 | 31.00 | 2969.67 | 3081.39 | 3.76 | 2878.50 | 2905.86 | 0.95
> RotateBenchmark.testRotateLeftL | 256.00 | 31.00 | 1452.21 | 1520.03 | 4.67 | 1430.30 | 1485.63 | 3.87
> RotateBenchmark.testRotateLeftL | 512.00 | 7.00 | 8088.65 | 8443.63 | 4.39 | 455.67 | 1226.33 | 169.13
> RotateBenchmark.testRotateLeftL | 512.00 | 7.00 | 4011.95 | 4120.25 | 2.70 | 229.77 | 619.87 | 169.77
> RotateBenchmark.testRotateLeftL | 512.00 | 7.00 | 2090.57 | 2109.53 | 0.91 | 115.21 | 310.36 | 169.37
> RotateBenchmark.testRotateLeftL | 512.00 | 15.00 | 8166.84 | 8557.28 | 4.78 | 457.67 | 1242.86 | 171.56
> RotateBenchmark.testRotateLeftL | 512.00 | 15.00 | 4137.02 | 4287.95 | 3.65 | 227.26 | 624.80 | 174.93
> RotateBenchmark.testRotateLeftL | 512.00 | 15.00 | 2095.01 | 2102.86 | 0.37 | 114.26 | 310.83 | 172.03
> RotateBenchmark.testRotateLeftL | 512.00 | 31.00 | 8082.68 | 8400.56 | 3.93 | 459.59 | 1230.07 | 167.64
> RotateBenchmark.testRotateLeftL | 512.00 | 31.00 | 4047.67 | 4147.58 | 2.47 | 229.01 | 606.38 | 164.78
> RotateBenchmark.testRotateLeftL | 512.00 | 31.00 | 2086.83 | 2126.72 | 1.91 | 111.93 | 305.66 | 173.08
> RotateBenchmark.testRotateLeftS | 128.00 | 7.00 | 13597.19 | 13255.09 | -2.52 | 13818.39 | 13242.40 | -4.17
> RotateBenchmark.testRotateLeftS | 128.00 | 7.00 | 7028.26 | 6826.59 | -2.87 | 6765.15 | 6907.87 | 2.11
> RotateBenchmark.testRotateLeftS | 128.00 | 7.00 | 3570.40 | 3468.01 | -2.87 | 3449.66 | 3533.50 | 2.43
> RotateBenchmark.testRotateLeftS | 128.00 | 15.00 | 13615.99 | 13464.40 | -1.11 | 13330.02 | 13870.57 | 4.06
> RotateBenchmark.testRotateLeftS | 128.00 | 15.00 | 7043.31 | 6763.34 | -3.97 | 6928.88 | 7063.57 | 1.94
> RotateBenchmark.testRotateLeftS | 128.00 | 15.00 | 3495.12 | 3537.62 | 1.22 | 3503.41 | 3457.67 | -1.31
> RotateBenchmark.testRotateLeftS | 128.00 | 31.00 | 13591.66 | 13665.84 | 0.55 | 13773.27 | 13126.08 | -4.70
> RotateBenchmark.testRotateLeftS | 128.00 | 31.00 | 7027.08 | 7011.24 | -0.23 | 6974.98 | 6815.50 | -2.29
> RotateBenchmark.testRotateLeftS | 128.00 | 31.00 | 3568.28 | 3569.62 | 0.04 | 3580.67 | 3463.58 | -3.27
> RotateBenchmark.testRotateLeftS | 256.00 | 7.00 | 21154.03 | 21416.32 | 1.24 | 21187.01 | 21401.61 | 1.01
> RotateBenchmark.testRotateLeftS | 256.00 | 7.00 | 11194.24 | 10865.47 | -2.94 | 11063.19 | 10977.60 | -0.77
> RotateBenchmark.testRotateLeftS | 256.00 | 7.00 | 5797.80 | 5523.94 | -4.72 | 5654.63 | 5468.78 | -3.29
> RotateBenchmark.testRotateLeftS | 256.00 | 15.00 | 21333.89 | 21412.74 | 0.37 | 21610.94 | 20908.96 | -3.25
> RotateBenchmark.testRotateLeftS | 256.00 | 15.00 | 11327.07 | 11113.48 | -1.89 | 11148.25 | 10678.14 | -4.22
> RotateBenchmark.testRotateLeftS | 256.00 | 15.00 | 5810.69 | 5569.72 | -4.15 | 5663.26 | 5618.87 | -0.78
> RotateBenchmark.testRotateLeftS | 256.00 | 31.00 | 21753.20 | 21198.43 | -2.55 | 21567.90 | 21929.81 | 1.68
> RotateBenchmark.testRotateLeftS | 256.00 | 31.00 | 11517.08 | 11039.64 | -4.15 | 11103.08 | 10871.59 | -2.08
> RotateBenchmark.testRotateLeftS | 256.00 | 31.00 | 5897.16 | 5606.75 | -4.92 | 5459.87 | 5604.12 | 2.64
> RotateBenchmark.testRotateLeftS | 512.00 | 7.00 | 29748.53 | 28883.73 | -2.91 | 1549.02 | 3928.53 | 153.61
> RotateBenchmark.testRotateLeftS | 512.00 | 7.00 | 15197.09 | 15878.19 | 4.48 | 772.59 | 1924.35 | 149.08
> RotateBenchmark.testRotateLeftS | 512.00 | 7.00 | 8046.30 | 8081.19 | 0.43 | 388.11 | 990.28 | 155.16
> RotateBenchmark.testRotateLeftS | 512.00 | 15.00 | 30618.04 | 29419.19 | -3.92 | 1524.22 | 3915.97 | 156.92
> RotateBenchmark.testRotateLeftS | 512.00 | 15.00 | 15854.43 | 15846.37 | -0.05 | 766.09 | 1953.60 | 155.01
> RotateBenchmark.testRotateLeftS | 512.00 | 15.00 | 7814.77 | 7899.30 | 1.08 | 390.82 | 970.37 | 148.29
> RotateBenchmark.testRotateLeftS | 512.00 | 31.00 | 29596.82 | 28538.69 | -3.58 | 1530.45 | 3906.91 | 155.28
> RotateBenchmark.testRotateLeftS | 512.00 | 31.00 | 15662.48 | 15849.25 | 1.19 | 778.08 | 1934.31 | 148.60
> RotateBenchmark.testRotateLeftS | 512.00 | 31.00 | 8121.14 | 7758.59 | -4.46 | 392.78 | 959.73 | 144.34
> RotateBenchmark.testRotateRightB | 128.00 | 7.00 | 17465.84 | 17069.34 | -2.27 | 16849.73 | 17842.08 | 5.89
> RotateBenchmark.testRotateRightB | 128.00 | 7.00 | 9049.19 | 8864.15 | -2.04 | 8786.67 | 9105.34 | 3.63
> RotateBenchmark.testRotateRightB | 128.00 | 15.00 | 17703.38 | 17070.98 | -3.57 | 16595.85 | 17784.68 | 7.16
> RotateBenchmark.testRotateRightB | 128.00 | 15.00 | 9007.68 | 8817.41 | -2.11 | 8704.49 | 9185.87 | 5.53
> RotateBenchmark.testRotateRightB | 128.00 | 31.00 | 17531.05 | 16983.40 | -3.12 | 16947.69 | 17655.40 | 4.18
> RotateBenchmark.testRotateRightB | 128.00 | 31.00 | 8986.30 | 8794.15 | -2.14 | 8816.62 | 9225.95 | 4.64
> RotateBenchmark.testRotateRightB | 256.00 | 7.00 | 21293.95 | 21506.74 | 1.00 | 21163.29 | 21854.03 | 3.26
> RotateBenchmark.testRotateRightB | 256.00 | 7.00 | 11258.47 | 11072.92 | -1.65 | 11118.12 | 11338.96 | 1.99
> RotateBenchmark.testRotateRightB | 256.00 | 15.00 | 21253.36 | 21292.37 | 0.18 | 21224.39 | 21763.88 | 2.54
> RotateBenchmark.testRotateRightB | 256.00 | 15.00 | 11064.80 | 11198.35 | 1.21 | 10960.98 | 11294.14 | 3.04
> RotateBenchmark.testRotateRightB | 256.00 | 31.00 | 21358.14 | 21346.21 | -0.06 | 21487.25 | 21854.42 | 1.71
> RotateBenchmark.testRotateRightB | 256.00 | 31.00 | 11045.61 | 11208.26 | 1.47 | 10907.03 | 11415.18 | 4.66
> RotateBenchmark.testRotateRightB | 512.00 | 7.00 | 17898.61 | 18307.54 | 2.28 | 1214.65 | 2546.64 | 109.66
> RotateBenchmark.testRotateRightB | 512.00 | 15.00 | 17909.25 | 18242.51 | 1.86 | 1215.05 | 2563.98 | 111.02
> RotateBenchmark.testRotateRightB | 512.00 | 31.00 | 17883.35 | 17928.44 | 0.25 | 1220.77 | 2543.30 | 108.34
> RotateBenchmark.testRotateRightI | 128.00 | 7.00 | 7139.97 | 7626.72 | 6.82 | 6994.86 | 7075.65 | 1.15
> RotateBenchmark.testRotateRightI | 128.00 | 7.00 | 3657.37 | 3898.34 | 6.59 | 3617.06 | 3576.12 | -1.13
> RotateBenchmark.testRotateRightI | 128.00 | 7.00 | 1804.26 | 1969.19 | 9.14 | 1796.62 | 1858.84 | 3.46
> RotateBenchmark.testRotateRightI | 128.00 | 15.00 | 7404.31 | 7760.09 | 4.80 | 7036.77 | 7401.52 | 5.18
> RotateBenchmark.testRotateRightI | 128.00 | 15.00 | 3600.52 | 3956.35 | 9.88 | 3595.28 | 3560.36 | -0.97
> RotateBenchmark.testRotateRightI | 128.00 | 15.00 | 1813.32 | 1966.41 | 8.44 | 1839.95 | 1852.53 | 0.68
> RotateBenchmark.testRotateRightI | 128.00 | 31.00 | 7118.48 | 7724.81 | 8.52 | 7151.56 | 7021.09 | -1.82
> RotateBenchmark.testRotateRightI | 128.00 | 31.00 | 3529.70 | 3881.63 | 9.97 | 3623.08 | 3601.01 | -0.61
> RotateBenchmark.testRotateRightI | 128.00 | 31.00 | 1823.61 | 1961.34 | 7.55 | 1786.86 | 1748.85 | -2.13
> RotateBenchmark.testRotateRightI | 256.00 | 7.00 | 11697.98 | 11835.25 | 1.17 | 11513.16 | 11184.87 | -2.85
> RotateBenchmark.testRotateRightI | 256.00 | 7.00 | 5890.11 | 6102.57 | 3.61 | 5658.79 | 5696.08 | 0.66
> RotateBenchmark.testRotateRightI | 256.00 | 7.00 | 2964.94 | 3070.26 | 3.55 | 2945.00 | 2962.08 | 0.58
> RotateBenchmark.testRotateRightI | 256.00 | 15.00 | 11562.51 | 12151.29 | 5.09 | 11404.17 | 11120.28 | -2.49
> RotateBenchmark.testRotateRightI | 256.00 | 15.00 | 5702.93 | 6130.57 | 7.50 | 5799.54 | 5779.08 | -0.35
> RotateBenchmark.testRotateRightI | 256.00 | 15.00 | 2861.96 | 3051.44 | 6.62 | 2943.99 | 2860.65 | -2.83
> RotateBenchmark.testRotateRightI | 256.00 | 31.00 | 11203.13 | 11710.59 | 4.53 | 11363.18 | 11112.16 | -2.21
> RotateBenchmark.testRotateRightI | 256.00 | 31.00 | 5893.97 | 6070.71 | 3.00 | 5776.67 | 5648.84 | -2.21
> RotateBenchmark.testRotateRightI | 256.00 | 31.00 | 2971.83 | 3046.76 | 2.52 | 2903.35 | 2833.88 | -2.39
> RotateBenchmark.testRotateRightI | 512.00 | 7.00 | 16064.71 | 15851.35 | -1.33 | 861.93 | 2256.88 | 161.84
> RotateBenchmark.testRotateRightI | 512.00 | 7.00 | 7916.80 | 8462.65 | 6.89 | 430.23 | 1147.30 | 166.67
> RotateBenchmark.testRotateRightI | 512.00 | 7.00 | 4104.64 | 4068.28 | -0.89 | 216.30 | 572.86 | 164.84
> RotateBenchmark.testRotateRightI | 512.00 | 15.00 | 16133.09 | 16281.59 | 0.92 | 856.36 | 2229.58 | 160.35
> RotateBenchmark.testRotateRightI | 512.00 | 15.00 | 8127.26 | 8117.59 | -0.12 | 419.16 | 1176.42 | 180.66
> RotateBenchmark.testRotateRightI | 512.00 | 15.00 | 4080.11 | 4063.26 | -0.41 | 218.32 | 571.93 | 161.97
> RotateBenchmark.testRotateRightI | 512.00 | 31.00 | 15834.26 | 16314.64 | 3.03 | 865.96 | 2297.74 | 165.34
> RotateBenchmark.testRotateRightI | 512.00 | 31.00 | 7965.62 | 8270.48 | 3.83 | 428.55 | 1148.87 | 168.08
> RotateBenchmark.testRotateRightI | 512.00 | 31.00 | 4161.69 | 4034.76 | -3.05 | 215.63 | 570.19 | 164.43
> RotateBenchmark.testRotateRightL | 128.00 | 7.00 | 3556.70 | 3877.08 | 9.01 | 3596.46 | 3558.32 | -1.06
> RotateBenchmark.testRotateRightL | 128.00 | 7.00 | 1772.93 | 1993.86 | 12.46 | 1856.79 | 1783.22 | -3.96
> RotateBenchmark.testRotateRightL | 128.00 | 7.00 | 908.66 | 1000.37 | 10.09 | 944.79 | 922.91 | -2.32
> RotateBenchmark.testRotateRightL | 128.00 | 15.00 | 3742.44 | 3748.41 | 0.16 | 3788.07 | 3570.67 | -5.74
> RotateBenchmark.testRotateRightL | 128.00 | 15.00 | 1817.53 | 1985.69 | 9.25 | 1892.38 | 1833.16 | -3.13
> RotateBenchmark.testRotateRightL | 128.00 | 15.00 | 941.03 | 952.68 | 1.24 | 915.79 | 910.21 | -0.61
> RotateBenchmark.testRotateRightL | 128.00 | 31.00 | 3649.48 | 3896.56 | 6.77 | 3637.59 | 3557.53 | -2.20
> RotateBenchmark.testRotateRightL | 128.00 | 31.00 | 1840.12 | 1997.19 | 8.54 | 1821.47 | 1799.82 | -1.19
> RotateBenchmark.testRotateRightL | 128.00 | 31.00 | 901.33 | 995.67 | 10.47 | 909.20 | 902.73 | -0.71
> RotateBenchmark.testRotateRightL | 256.00 | 7.00 | 5789.93 | 5960.54 | 2.95 | 5758.14 | 5736.30 | -0.38
> RotateBenchmark.testRotateRightL | 256.00 | 7.00 | 2963.20 | 3063.30 | 3.38 | 2943.48 | 2833.84 | -3.72
> RotateBenchmark.testRotateRightL | 256.00 | 7.00 | 1501.81 | 1510.23 | 0.56 | 1463.85 | 1462.26 | -0.11
> RotateBenchmark.testRotateRightL | 256.00 | 15.00 | 5870.05 | 5951.43 | 1.39 | 5794.74 | 5604.58 | -3.28
> RotateBenchmark.testRotateRightL | 256.00 | 15.00 | 2971.36 | 3047.00 | 2.55 | 2931.19 | 2907.30 | -0.82
> RotateBenchmark.testRotateRightL | 256.00 | 15.00 | 1473.97 | 1530.54 | 3.84 | 1473.45 | 1442.40 | -2.11
> RotateBenchmark.testRotateRightL | 256.00 | 31.00 | 5858.08 | 6080.49 | 3.80 | 5863.69 | 5549.85 | -5.35
> RotateBenchmark.testRotateRightL | 256.00 | 31.00 | 2916.24 | 3045.77 | 4.44 | 2981.59 | 2815.07 | -5.58
> RotateBenchmark.testRotateRightL | 256.00 | 31.00 | 1441.20 | 1531.56 | 6.27 | 1492.47 | 1473.25 | -1.29
> RotateBenchmark.testRotateRightL | 512.00 | 7.00 | 8147.24 | 8310.05 | 2.00 | 469.45 | 1235.21 | 163.12
> RotateBenchmark.testRotateRightL | 512.00 | 7.00 | 4142.95 | 4258.86 | 2.80 | 234.14 | 615.52 | 162.88
> RotateBenchmark.testRotateRightL | 512.00 | 7.00 | 2095.48 | 2087.20 | -0.40 | 113.55 | 311.19 | 174.05
> RotateBenchmark.testRotateRightL | 512.00 | 15.00 | 8222.94 | 8246.58 | 0.29 | 458.91 | 1244.32 | 171.15
> RotateBenchmark.testRotateRightL | 512.00 | 15.00 | 4160.04 | 4226.46 | 1.60 | 227.78 | 625.38 | 174.56
> RotateBenchmark.testRotateRightL | 512.00 | 15.00 | 2064.63 | 2162.44 | 4.74 | 113.27 | 314.15 | 177.36
> RotateBenchmark.testRotateRightL | 512.00 | 31.00 | 8157.94 | 8466.90 | 3.79 | 450.26 | 1221.90 | 171.37
> RotateBenchmark.testRotateRightL | 512.00 | 31.00 | 4039.74 | 4283.33 | 6.03 | 224.82 | 612.68 | 172.53
> RotateBenchmark.testRotateRightL | 512.00 | 31.00 | 2066.88 | 2147.51 | 3.90 | 110.97 | 303.43 | 173.42
> RotateBenchmark.testRotateRightS | 128.00 | 7.00 | 13548.39 | 13245.87 | -2.23 | 13490.93 | 13084.76 | -3.01
> RotateBenchmark.testRotateRightS | 128.00 | 7.00 | 7020.16 | 6768.85 | -3.58 | 6991.39 | 7044.32 | 0.76
> RotateBenchmark.testRotateRightS | 128.00 | 7.00 | 3550.50 | 3505.19 | -1.28 | 3507.12 | 3612.86 | 3.01
> RotateBenchmark.testRotateRightS | 128.00 | 15.00 | 13743.43 | 13325.44 | -3.04 | 13696.15 | 13255.80 | -3.22
> RotateBenchmark.testRotateRightS | 128.00 | 15.00 | 6856.02 | 6969.18 | 1.65 | 6886.29 | 6834.12 | -0.76
> RotateBenchmark.testRotateRightS | 128.00 | 15.00 | 3569.53 | 3492.76 | -2.15 | 3539.02 | 3470.02 | -1.95
> RotateBenchmark.testRotateRightS | 128.00 | 31.00 | 13704.18 | 13495.07 | -1.53 | 13649.14 | 13583.87 | -0.48
> RotateBenchmark.testRotateRightS | 128.00 | 31.00 | 7011.77 | 6953.93 | -0.82 | 6978.28 | 6740.30 | -3.41
> RotateBenchmark.testRotateRightS | 128.00 | 31.00 | 3591.62 | 3620.12 | 0.79 | 3502.04 | 3510.05 | 0.23
> RotateBenchmark.testRotateRightS | 256.00 | 7.00 | 21950.71 | 22113.60 | 0.74 | 21484.27 | 21596.64 | 0.52
> RotateBenchmark.testRotateRightS | 256.00 | 7.00 | 11616.88 | 11099.73 | -4.45 | 11188.29 | 10737.68 | -4.03
> RotateBenchmark.testRotateRightS | 256.00 | 7.00 | 5872.72 | 5579.12 | -5.00 | 5784.05 | 5454.57 | -5.70
> RotateBenchmark.testRotateRightS | 256.00 | 15.00 | 22017.83 | 20817.97 | -5.45 | 21934.65 | 21356.90 | -2.63
> RotateBenchmark.testRotateRightS | 256.00 | 15.00 | 11414.27 | 11044.86 | -3.24 | 11454.35 | 11140.34 | -2.74
> RotateBenchmark.testRotateRightS | 256.00 | 15.00 | 5786.64 | 5634.05 | -2.64 | 5724.93 | 5639.99 | -1.48
> RotateBenchmark.testRotateRightS | 256.00 | 31.00 | 21754.77 | 21466.01 | -1.33 | 21140.67 | 21970.03 | 3.92
> RotateBenchmark.testRotateRightS | 256.00 | 31.00 | 11676.46 | 11358.64 | -2.72 | 11204.90 | 11213.48 | 0.08
> RotateBenchmark.testRotateRightS | 256.00 | 31.00 | 5728.20 | 5772.49 | 0.77 | 5594.33 | 5544.25 | -0.90
> RotateBenchmark.testRotateRightS | 512.00 | 7.00 | 30247.03 | 30179.41 | -0.22 | 1538.75 | 3975.82 | 158.38
> RotateBenchmark.testRotateRightS | 512.00 | 7.00 | 15988.73 | 15621.42 | -2.30 | 776.04 | 1910.91 | 146.24
> RotateBenchmark.testRotateRightS | 512.00 | 7.00 | 8115.84 | 8025.28 | -1.12 | 389.12 | 984.46 | 152.99
> RotateBenchmark.testRotateRightS | 512.00 | 15.00 | 30110.91 | 30200.69 | 0.30 | 1532.49 | 3983.77 | 159.95
> RotateBenchmark.testRotateRightS | 512.00 | 15.00 | 15957.90 | 15690.73 | -1.67 | 774.90 | 1931.00 | 149.19
> RotateBenchmark.testRotateRightS | 512.00 | 15.00 | 8113.26 | 8037.93 | -0.93 | 391.90 | 965.53 | 146.37
> RotateBenchmark.testRotateRightS | 512.00 | 31.00 | 29816.97 | 29891.54 | 0.25 | 1538.12 | 3881.93 | 152.38
> RotateBenchmark.testRotateRightS | 512.00 | 31.00 | 15405.95 | 15619.17 | 1.38 | 762.49 | 1871.00 | 145.38
> RotateBenchmark.testRotateRightS | 512.00 | 31.00 | 7919.80 | 7957.35 | 0.47 | 393.63 | 972.49 | 147.06

Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:

 - 8266054: Incorporating styling changes based on reviews.
 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8266054
 - Merge http://github.com/openjdk/jdk into JDK-8266054
 - Merge http://github.com/openjdk/jdk into JDK-8266054
 - Merge http://github.com/openjdk/jdk into JDK-8266054
 - Merge branch 'JDK-8266054' of http://github.com/jatin-bhateja/jdk into JDK-8266054
 - 8266054: Removing redundant teat templates.
 - 8266054: Code reorganization for efficient sharing of logic to check rotate operation support on a target platform.
 - 8266054: Removing redundant test templates.
 - 8266054: Review comments resolution.
 - ... and 5 more: https://git.openjdk.java.net/jdk/compare/07e90524...609c4143

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

Changes: https://git.openjdk.java.net/jdk/pull/3720/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3720&range=09
  Stats: 4393 lines in 52 files changed: 4172 ins; 60 del; 161 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3720.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3720/head:pull/3720

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

From jvernee at openjdk.java.net  Thu Jul 15 10:50:36 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Thu, 15 Jul 2021 10:50:36 GMT
Subject: [jdk17] RFR: 8269240:
 java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC
 [v2]
In-Reply-To: <e7gBayKnokRzWTDb2LQFrP8eikV-UrRN_Y0JGCzY55w=.962eb647-c232-47b5-95c2-4844d8a36204@github.com>
References: <PqFCdTWCSge_X14Rc5aNAo2pr5uliZ9jT0iYltvef3g=.7467c1a4-ad15-48a3-a495-75b655acf69c@github.com>
 <o-O6F0omoRjgCjD28Ir79_QYw2xdT_1SlIu2h0eLqH0=.a9e4053d-4464-40de-94df-39fc98e4eaaf@github.com>
 <e7gBayKnokRzWTDb2LQFrP8eikV-UrRN_Y0JGCzY55w=.962eb647-c232-47b5-95c2-4844d8a36204@github.com>
Message-ID: <66vtM23dULcHDhjAYzZipQHy0KQHxwNKleKJIUlFnDo=.fe454def-a1a6-4475-94c2-06e85eea53e9@github.com>

On Wed, 14 Jul 2021 00:24:38 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Assert frame is correct type in frame_data_for_frame
>
> src/hotspot/share/prims/universalUpcallHandler.cpp line 86:
> 
>> 84:   context->new_handles = JNIHandleBlock::allocate_block(thread);
>> 85: 
>> 86:   // After this, we are official in Java Code. This needs to be done before we change any of the thread local
> 
> typo: s/official/officially/
> (I see this was copied from Javacalls)

Thanks, I wasn't sure whether to leave the comments in or not.

> src/hotspot/share/prims/universalUpcallHandler.cpp line 114:
> 
>> 112:   thread->set_active_handles(context->new_handles);     // install new handle block and reset Java frame linkage
>> 113: 
>> 114:   assert (thread->thread_state() != _thread_in_native, "cannot set native pc to NULL");
> 
> You transitioned to _thread_in_Java above so how can you possibly have changed state again ?? (okay again copied from javaCalls ...)

Yeah, it seemed paranoid to me as well. I'll remove this

> src/hotspot/share/prims/universalUpcallHandler.cpp line 121:
> 
>> 119:   }
>> 120: 
>> 121:   MACOS_AARCH64_ONLY(thread->enable_wx(WXExec));
> 
> Not clear why this is needed? JavaCallWrapper doesn't use it.

I took this from JavaCallWrapper. Seems to have been added in 17 for the mach aarch64 port: https://github.com/openjdk/jdk17/blame/a32d2eefea12771522b942b32985df0fe50119e8/src/hotspot/share/runtime/javaCalls.cpp#L112

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

PR: https://git.openjdk.java.net/jdk17/pull/149

From jvernee at openjdk.java.net  Thu Jul 15 11:06:13 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Thu, 15 Jul 2021 11:06:13 GMT
Subject: [jdk17] RFR: 8269240:
 java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC
 [v2]
In-Reply-To: <VW5GuwT6ccFopn__J_mIvIBaso53uR8i81DtuEh2AuM=.a5adb7ea-7a24-41d5-a1d0-cd972792dad6@github.com>
References: <PqFCdTWCSge_X14Rc5aNAo2pr5uliZ9jT0iYltvef3g=.7467c1a4-ad15-48a3-a495-75b655acf69c@github.com>
 <ebTR3Fg3FnrWIJX847RkbgTBN0Ma9rWbdyVR8WR0dhs=.349b6255-e6c7-46d8-b2df-8cd4d4dd13e8@github.com>
 <VW5GuwT6ccFopn__J_mIvIBaso53uR8i81DtuEh2AuM=.a5adb7ea-7a24-41d5-a1d0-cd972792dad6@github.com>
Message-ID: <hBpL8Lz9hRJ3_Ee8ZhpfyxI3qLSya9yMTRo2fRI6Zdo=.c50761ec-0fb8-45c1-a6f7-99ba2c408512@github.com>

On Wed, 14 Jul 2021 00:50:44 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/hotspot/share/runtime/safepoint.cpp line 931:
>> 
>>> 929:     // See if return type is an oop.
>>> 930:     bool return_oop = nm->method()->is_returning_oop();
>>> 931:     HandleMark hm(self);
>> 
>> I was seeing an `assert(_handle_mark_nesting > 1) failed: memory leak: allocating handle outside HandleMark` when the existing code allocates the Handle for `return_value` in the code down below. It seems to be a simple case of a missing handle mark, so I've added it here. (looking at the stack trace in the error log, the caller frame is native code, so I don't think we can expect the caller to have a HandleMark).
>
> How does native code reach a safepoint polling point?

The stack trace looks like this:


Current thread (0x000002a2489f0b50):  JavaThread "Thread-4551" [_thread_in_Java, id=24920, stack(0x000000d9e0500000,0x000000d9e0600000)]

Stack: [0x000000d9e0500000,0x000000d9e0600000]
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [jvm.dll+0xae6651]  os::platform_print_native_stack+0xf1  (os_windows_x86.cpp:235)
V  [jvm.dll+0xda3f25]  VMError::report+0x1005  (vmError.cpp:739)
V  [jvm.dll+0xda58ae]  VMError::report_and_die+0x7fe  (vmError.cpp:1549)
V  [jvm.dll+0xda5fe4]  VMError::report_and_die+0x64  (vmError.cpp:1330)
V  [jvm.dll+0x4ceca7]  report_vm_error+0xb7  (debug.cpp:282)
V  [jvm.dll+0x6511be]  HandleArea::allocate_handle+0x3e  (handles.cpp:35)
V  [jvm.dll+0xb8e334]  ThreadSafepointState::handle_polling_page_exception+0x314  (safepoint.cpp:939)
C  0x000002a035d8caa7

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
v  ~SafepointBlob
J 639 c1 java.lang.invoke.LambdaForm$MH+0x000000080101b800.invoke(Ljava/lang/Object;)V java.base at 18-internal (87 bytes) @ 0x000002a03635f7b4 [0x000002a03635f4a0+0x0000000000000314]
J 620 c1 java.lang.invoke.LambdaForm$MH+0x0000000801018c00.invoke(Ljava/lang/Object;)V java.base at 18-internal (37 bytes) @ 0x000002a036353e0c [0x000002a036353720+0x00000000000006ec]
v  ~BufferBlob::m?Y?????G?


So I think the 'native code' is something being called by the safepoint blob, but I'm not sure why it's marked with a `C` instead of `V` in the stack trace (maybe just a stack unwind failure?).

FWIW, this part has already been fixed as part of: https://github.com/openjdk/jdk17/pull/173 (not sure why it still shows up in the diff)

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

PR: https://git.openjdk.java.net/jdk17/pull/149

From github.com+10835776+stsypanov at openjdk.java.net  Thu Jul 15 11:26:31 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Thu, 15 Jul 2021 11:26:31 GMT
Subject: RFR: 8270160: Remove redundant bounds check from
 AbstractStringBuilder.charAt() [v2]
In-Reply-To: <Rs2IOOVA4Rt-72REaifI9rMAtle9N-CLgkGSH7Q7xH0=.bfadc544-a1ad-41dd-9222-b0dec3dbed65@github.com>
References: <Rs2IOOVA4Rt-72REaifI9rMAtle9N-CLgkGSH7Q7xH0=.bfadc544-a1ad-41dd-9222-b0dec3dbed65@github.com>
Message-ID: <B-WO8KcYaEkRgCtVYVSYKKw9tFbMeQ1uuRlqxpIXHBI=.64835509-f417-44b2-9e3c-0df51f530118@github.com>

> `AbstractStringBuilder.charAt(int)` does bounds check before calling `charAt()` (for non-latin Strings):
> 
> @Override
> public char charAt(int index) {
>     checkIndex(index, count);
>     if (isLatin1()) {
>         return (char)(value[index] & 0xff);
>     }
>     return StringUTF16.charAt(value, index);
> }
> 
> This can be improved by removing bounds check from ASB.charAt() in favour of one in String*.charAt(). This gives slight improvement:
> 
> before
> Benchmark                           Mode  Cnt  Score   Error  Units
> StringBuilderCharAtBenchmark.latin  avgt   50  2,827 ? 0,024  ns/op
> StringBuilderCharAtBenchmark.utf    avgt   50  2,985 ? 0,020  ns/op
> 
> after
> Benchmark                           Mode  Cnt  Score   Error  Units
> StringBuilderCharAtBenchmark.latin  avgt   50  2,434 ? 0,004  ns/op
> StringBuilderCharAtBenchmark.utf    avgt   50  2,631 ? 0,004  ns/op

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

 - Merge branch 'master' into 8270160
   
   # Conflicts:
   #	src/java.base/share/classes/java/lang/StringLatin1.java
 - 8270160 Remove redundant bounds check from AbstractStringBuilder.charAt()

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

Changes: https://git.openjdk.java.net/jdk/pull/4738/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4738&range=01
  Stats: 7 lines in 2 files changed: 1 ins; 3 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4738.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4738/head:pull/4738

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

From github.com+10835776+stsypanov at openjdk.java.net  Thu Jul 15 11:56:31 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Thu, 15 Jul 2021 11:56:31 GMT
Subject: RFR: 8270160: Remove redundant bounds check from
 AbstractStringBuilder.charAt() [v3]
In-Reply-To: <Rs2IOOVA4Rt-72REaifI9rMAtle9N-CLgkGSH7Q7xH0=.bfadc544-a1ad-41dd-9222-b0dec3dbed65@github.com>
References: <Rs2IOOVA4Rt-72REaifI9rMAtle9N-CLgkGSH7Q7xH0=.bfadc544-a1ad-41dd-9222-b0dec3dbed65@github.com>
Message-ID: <Kt6Ff5XsQsJ58xWUIhe5nh0ymKD3DIzyCrWkBYiioL0=.5c497696-7e9f-4c15-a4d8-b34e05d84cee@github.com>

> `AbstractStringBuilder.charAt(int)` does bounds check before calling `charAt()` (for non-latin Strings):
> 
> @Override
> public char charAt(int index) {
>     checkIndex(index, count);
>     if (isLatin1()) {
>         return (char)(value[index] & 0xff);
>     }
>     return StringUTF16.charAt(value, index);
> }
> 
> This can be improved by removing bounds check from ASB.charAt() in favour of one in String*.charAt(). This gives slight improvement:
> 
> before
> Benchmark                           Mode  Cnt  Score   Error  Units
> StringBuilderCharAtBenchmark.latin  avgt   50  2,827 ? 0,024  ns/op
> StringBuilderCharAtBenchmark.utf    avgt   50  2,985 ? 0,020  ns/op
> 
> after
> Benchmark                           Mode  Cnt  Score   Error  Units
> StringBuilderCharAtBenchmark.latin  avgt   50  2,434 ? 0,004  ns/op
> StringBuilderCharAtBenchmark.utf    avgt   50  2,631 ? 0,004  ns/op

?????? ??????? 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 two new commits since the last revision:

 - Merge branch 'master' into 8270160
   
   # Conflicts:
   #	src/java.base/share/classes/java/lang/StringLatin1.java
 - 8270160: Remove redundant bounds check from AbstractStringBuilder.charAt()

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4738/files
  - new: https://git.openjdk.java.net/jdk/pull/4738/files/9f30e621..b7b01ff4

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

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

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

From jlahoda at openjdk.java.net  Thu Jul 15 12:28:35 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Thu, 15 Jul 2021 12:28:35 GMT
Subject: RFR: 8270547: java.util.Random contains unnecessary
 @SuppressWarnings("exports")
Message-ID: <1zvok0pcWa55YUY01VmZLadbT0haBz8RXjTg2V5R3sI=.a6dd9b54-cb7a-4d79-a64f-707da3dd7a0f@github.com>

Removing unnecessary `@SuppressWarnings("exports")`. The reason for the suppress warnings was, as far as I can tell, removed by https://bugs.openjdk.java.net/browse/JDK-8265137.

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

Commit messages:
 - 8270547: java.util.Random contains unnecessary @SuppressWarnings("exports")

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

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

From jvernee at openjdk.java.net  Thu Jul 15 12:29:26 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Thu, 15 Jul 2021 12:29:26 GMT
Subject: [jdk17] RFR: 8269240:
 java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC
 [v2]
In-Reply-To: <e7gBayKnokRzWTDb2LQFrP8eikV-UrRN_Y0JGCzY55w=.962eb647-c232-47b5-95c2-4844d8a36204@github.com>
References: <PqFCdTWCSge_X14Rc5aNAo2pr5uliZ9jT0iYltvef3g=.7467c1a4-ad15-48a3-a495-75b655acf69c@github.com>
 <o-O6F0omoRjgCjD28Ir79_QYw2xdT_1SlIu2h0eLqH0=.a9e4053d-4464-40de-94df-39fc98e4eaaf@github.com>
 <e7gBayKnokRzWTDb2LQFrP8eikV-UrRN_Y0JGCzY55w=.962eb647-c232-47b5-95c2-4844d8a36204@github.com>
Message-ID: <fyyuRO2J0ekD3Y5aSd96rGzJDImawCygjqtMXRB1EA0=.0105932c-1d93-4287-8df7-30b1fd6b3090@github.com>

On Wed, 14 Jul 2021 00:47:47 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Assert frame is correct type in frame_data_for_frame
>
> src/hotspot/share/prims/universalUpcallHandler.cpp line 76:
> 
>> 74: 
>> 75: // modelled after JavaCallWrapper::JavaCallWrapper
>> 76: Thread* ProgrammableUpcallHandler::on_entry(OptimizedEntryBlob::FrameData* context) {
> 
> This should return JavaThread not Thread.

Thanks.

I've been careful here to return a `Thread*` since the result is stored in `r15_thread` and I thought converting between sub and super types could potentially result in different pointers due to the way super types are laid out within a subtype. I thought it worked like this:


Subclass
+---
| {Subclass vtable pointer}
| +--- (base class Super)
| | {Super vtable pointer}
| +---
+---


So, I thought plainly using a `JavaThread*` in generated machine code where a `Thread*` was expected could cause trouble, since the pointer needs to be offset for the type conversion.

But now that I'm looking at some cases with compiler explorer, the pointer offset only seems to be needed when using multiple inheritance, for instance:


class SuperA {
public:
    virtual void foo();
};

class SuperB {
public:
    virtual void bar();
};

class Sub : public SuperA, public SuperB {
public:
    virtual void baz();
};


Results in:


class Sub	size(16):
	+---
 0	| +--- (base class SuperA)
 0	| | {vfptr}
	| +---
 8	| +--- (base class SuperB)
 8	| | {vfptr}
	| +---
	+---

Sub::$vftable at SuperA@:
	| &Sub_meta
	|  0
 0	| &SuperA::foo 
 1	| &Sub::baz 

Sub::$vftable at SuperB@:
	| -8
 0	| &SuperB::bar 

Sub::baz this adjustor: 0


(https://godbolt.org/z/rq9bT8d9d)

It seems that the sub type just reuses the vtable pointer of the first super type (probably to avoid having to do this pointer offsetting). Though, converting between `SuperB*` and `Sub*` would require offsetting the pointer. I'm still not sure this is guaranteed to work like this with all compilers though (the example is with MSVC, which has options to dump class layouts).

The result of `on_entry` is stored in `r15_thread`, so I guess I'm wondering if it's safe to store a `JavaThread*` instead of a `Thread*` in `r15`, and other code, which may expect `r15` to hold a `Thread*`, is guaranteed to keep working? (FWIW, after changing the return type to `JavaThread*` the tests that exercise this code still pass on Windows with MSVC, and on WSL Linux with GCC).

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

PR: https://git.openjdk.java.net/jdk17/pull/149

From jvernee at openjdk.java.net  Thu Jul 15 12:41:33 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Thu, 15 Jul 2021 12:41:33 GMT
Subject: [jdk17] RFR: 8269240:
 java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC
 [v2]
In-Reply-To: <e7gBayKnokRzWTDb2LQFrP8eikV-UrRN_Y0JGCzY55w=.962eb647-c232-47b5-95c2-4844d8a36204@github.com>
References: <PqFCdTWCSge_X14Rc5aNAo2pr5uliZ9jT0iYltvef3g=.7467c1a4-ad15-48a3-a495-75b655acf69c@github.com>
 <o-O6F0omoRjgCjD28Ir79_QYw2xdT_1SlIu2h0eLqH0=.a9e4053d-4464-40de-94df-39fc98e4eaaf@github.com>
 <e7gBayKnokRzWTDb2LQFrP8eikV-UrRN_Y0JGCzY55w=.962eb647-c232-47b5-95c2-4844d8a36204@github.com>
Message-ID: <GOiAjpKpXbCkdLtC_GBmF_SEp4DeVDGP3xj_utAXX8Y=.62bc8742-4b72-4474-97b0-b42dab69854e@github.com>

On Wed, 14 Jul 2021 00:58:38 GMT, David Holmes <dholmes at openjdk.org> wrote:

> The mapping to JavaCallWrapper seems reasonable but there are a few differences that I'm now assuming stem from the fact upcalls start _thread_in_native while JCW starts from _thread_in_vm?

The main difference stems from the fact that, since these upcalls can come from non-JNI native code, we can not assume that the thread is already attached to the VM, so we do that on the fly instead, and we detach the thread again after the upcall (if needed). Those are what the call to `maybe_attach_and_get_thread` at the start of `on_entry`, and `detach_thread` call at the end of `on_exit` are for.

The other thing is that there is no stack watermark check at the end of `on_exit`. This check is guarded by a check if the thread has any pending exceptions in `JavaCallWrapper`, but since a panama upcall is not allowed to throw any exceptions, I've changed that to an `assert` that checks that there are no pending exceptions at that point instead.

The last thing is that we transition directly from `_thread_in_native` to `_thread_in_Java`, which changes some of the thread transition code.

Other than that, I've tried to mimic what `JavaCallWrapper` does as closely as possible.

Is there anything else that looks different?

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

PR: https://git.openjdk.java.net/jdk17/pull/149

From jvernee at openjdk.java.net  Thu Jul 15 12:47:22 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Thu, 15 Jul 2021 12:47:22 GMT
Subject: [jdk17] RFR: 8269240:
 java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC
 [v2]
In-Reply-To: <fyyuRO2J0ekD3Y5aSd96rGzJDImawCygjqtMXRB1EA0=.0105932c-1d93-4287-8df7-30b1fd6b3090@github.com>
References: <PqFCdTWCSge_X14Rc5aNAo2pr5uliZ9jT0iYltvef3g=.7467c1a4-ad15-48a3-a495-75b655acf69c@github.com>
 <o-O6F0omoRjgCjD28Ir79_QYw2xdT_1SlIu2h0eLqH0=.a9e4053d-4464-40de-94df-39fc98e4eaaf@github.com>
 <e7gBayKnokRzWTDb2LQFrP8eikV-UrRN_Y0JGCzY55w=.962eb647-c232-47b5-95c2-4844d8a36204@github.com>
 <fyyuRO2J0ekD3Y5aSd96rGzJDImawCygjqtMXRB1EA0=.0105932c-1d93-4287-8df7-30b1fd6b3090@github.com>
Message-ID: <iFQizlIjNo63-wowvyQkjsPBmY--Rgy1pWhEN94GuUw=.b0d3f899-b665-427a-ae1c-65bd3b7c7721@github.com>

On Thu, 15 Jul 2021 12:25:54 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> src/hotspot/share/prims/universalUpcallHandler.cpp line 76:
>> 
>>> 74: 
>>> 75: // modelled after JavaCallWrapper::JavaCallWrapper
>>> 76: Thread* ProgrammableUpcallHandler::on_entry(OptimizedEntryBlob::FrameData* context) {
>> 
>> This should return JavaThread not Thread.
>
> Thanks.
> 
> I've been careful here to return a `Thread*` since the result is stored in `r15_thread` and I thought converting between sub and super types could potentially result in different pointers due to the way super types are laid out within a subtype. I thought it worked like this:
> 
> 
> Subclass
> +---
> | {Subclass vtable pointer}
> | +--- (base class Super)
> | | {Super vtable pointer}
> | +---
> +---
> 
> 
> So, I thought plainly using a `JavaThread*` in generated machine code where a `Thread*` was expected could cause trouble, since the pointer needs to be offset for the type conversion.
> 
> But now that I'm looking at some cases with compiler explorer, the pointer offset only seems to be needed when using multiple inheritance, for instance:
> 
> 
> class SuperA {
> public:
>     virtual void foo();
> };
> 
> class SuperB {
> public:
>     virtual void bar();
> };
> 
> class Sub : public SuperA, public SuperB {
> public:
>     virtual void baz();
> };
> 
> 
> Results in:
> 
> 
> class Sub	size(16):
> 	+---
>  0	| +--- (base class SuperA)
>  0	| | {vfptr}
> 	| +---
>  8	| +--- (base class SuperB)
>  8	| | {vfptr}
> 	| +---
> 	+---
> 
> Sub::$vftable at SuperA@:
> 	| &Sub_meta
> 	|  0
>  0	| &SuperA::foo 
>  1	| &Sub::baz 
> 
> Sub::$vftable at SuperB@:
> 	| -8
>  0	| &SuperB::bar 
> 
> Sub::baz this adjustor: 0
> 
> 
> (https://godbolt.org/z/1665fWzff)
> 
> It seems that the sub type just reuses the vtable pointer of the first super type (probably to avoid having to do this pointer offsetting). Though, converting between `SuperB*` and `Sub*` would require offsetting the pointer. I'm still not sure this is guaranteed to work like this with all compilers though (the example is with MSVC, which has options to dump class layouts).
> 
> The result of `on_entry` is stored in `r15_thread`, so I guess I'm wondering if it's safe to store a `JavaThread*` instead of a `Thread*` in `r15`, and other code, which may expect `r15` to hold a `Thread*`, is guaranteed to keep working? (FWIW, after changing the return type to `JavaThread*` the tests that exercise this code still pass on Windows with MSVC, and on WSL Linux with GCC).

Sorry, I sent the wrong godbolt link: https://godbolt.org/z/1665fWzff

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

PR: https://git.openjdk.java.net/jdk17/pull/149

From david.holmes at oracle.com  Thu Jul 15 12:54:39 2021
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 15 Jul 2021 22:54:39 +1000
Subject: [jdk17] RFR: 8269240:
 java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC
 [v2]
In-Reply-To: <fyyuRO2J0ekD3Y5aSd96rGzJDImawCygjqtMXRB1EA0=.0105932c-1d93-4287-8df7-30b1fd6b3090@github.com>
References: <PqFCdTWCSge_X14Rc5aNAo2pr5uliZ9jT0iYltvef3g=.7467c1a4-ad15-48a3-a495-75b655acf69c@github.com>
 <o-O6F0omoRjgCjD28Ir79_QYw2xdT_1SlIu2h0eLqH0=.a9e4053d-4464-40de-94df-39fc98e4eaaf@github.com>
 <e7gBayKnokRzWTDb2LQFrP8eikV-UrRN_Y0JGCzY55w=.962eb647-c232-47b5-95c2-4844d8a36204@github.com>
 <fyyuRO2J0ekD3Y5aSd96rGzJDImawCygjqtMXRB1EA0=.0105932c-1d93-4287-8df7-30b1fd6b3090@github.com>
Message-ID: <ec1abc84-4aff-e8c4-9574-ab788a66c8e9@oracle.com>

On 15/07/2021 10:29 pm, Jorn Vernee wrote:
> On Wed, 14 Jul 2021 00:47:47 GMT, David Holmes <dholmes at openjdk.org> wrote:
> 
>>> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
>>>
>>>    Assert frame is correct type in frame_data_for_frame
>>
>> src/hotspot/share/prims/universalUpcallHandler.cpp line 76:
>>
>>> 74:
>>> 75: // modelled after JavaCallWrapper::JavaCallWrapper
>>> 76: Thread* ProgrammableUpcallHandler::on_entry(OptimizedEntryBlob::FrameData* context) {
>>
>> This should return JavaThread not Thread.
> 
> Thanks.
> 
> I've been careful here to return a `Thread*` since the result is stored in `r15_thread` and I thought converting between sub and super types could potentially result in different pointers due to the way super types are laid out within a subtype. I thought it worked like this:

Wow! Okay I've never seen anyone query this before. AFAIK whatever we 
store in r15_thread is required to be a correct pointer to the current 
thread object whatever its exact subtype may be. The returned pointer 
has to work correctly for virtual functions and can't be a "sliced" 
Thread instead of the real type. So as far as I know this "just works" 
and I think we'd be in big trouble if it didn't work.

But I don't deal with the under-the-covers parts of the C++ compiler.

David
-----

> 
> Subclass
> +---
> | {Subclass vtable pointer}
> | +--- (base class Super)
> | | {Super vtable pointer}
> | +---
> +---
> 
> 
> So, I thought plainly using a `JavaThread*` in generated machine code where a `Thread*` was expected could cause trouble, since the pointer needs to be offset for the type conversion.
> 
> But now that I'm looking at some cases with compiler explorer, the pointer offset only seems to be needed when using multiple inheritance, for instance:
> 
> 
> class SuperA {
> public:
>      virtual void foo();
> };
> 
> class SuperB {
> public:
>      virtual void bar();
> };
> 
> class Sub : public SuperA, public SuperB {
> public:
>      virtual void baz();
> };
> 
> 
> Results in:
> 
> 
> class Sub	size(16):
> 	+---
>   0	| +--- (base class SuperA)
>   0	| | {vfptr}
> 	| +---
>   8	| +--- (base class SuperB)
>   8	| | {vfptr}
> 	| +---
> 	+---
> 
> Sub::$vftable at SuperA@:
> 	| &Sub_meta
> 	|  0
>   0	| &SuperA::foo
>   1	| &Sub::baz
> 
> Sub::$vftable at SuperB@:
> 	| -8
>   0	| &SuperB::bar
> 
> Sub::baz this adjustor: 0
> 
> 
> (https://godbolt.org/z/rq9bT8d9d)
> 
> It seems that the sub type just reuses the vtable pointer of the first super type (probably to avoid having to do this pointer offsetting). Though, converting between `SuperB*` and `Sub*` would require offsetting the pointer. I'm still not sure this is guaranteed to work like this with all compilers though (the example is with MSVC, which has options to dump class layouts).
> 
> The result of `on_entry` is stored in `r15_thread`, so I guess I'm wondering if it's safe to store a `JavaThread*` instead of a `Thread*` in `r15`, and other code, which may expect `r15` to hold a `Thread*`, is guaranteed to keep working? (FWIW, after changing the return type to `JavaThread*` the tests that exercise this code still pass on Windows with MSVC, and on WSL Linux with GCC).
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk17/pull/149
> 

From mbaesken at openjdk.java.net  Thu Jul 15 13:09:54 2021
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Thu, 15 Jul 2021 13:09:54 GMT
Subject: RFR: JDK-8266490: Extend the OSContainer API to support the pids
 controller of cgroups [v4]
In-Reply-To: <MWenVRe4ptn5aua0DUHvxb-sdbu-Ykl9x0GlhmxKHhY=.1fb8901e-36c3-4c07-a6ed-b653120807de@github.com>
References: <MWenVRe4ptn5aua0DUHvxb-sdbu-Ykl9x0GlhmxKHhY=.1fb8901e-36c3-4c07-a6ed-b653120807de@github.com>
Message-ID: <RWs56CmhmIHEUesFH6SXGRdo07sstXw3jSU4y37dddg=.fa6fa265-0637-4695-bb54-040b94833492@github.com>

> Hello, please review this PR; it extend the OSContainer API in order to also support the pids controller of cgroups.
> 
> I noticed that unlike the other controllers "cpu", "cpuset", "cpuacct", "memory"  on some older Linux distros (SLES 12.1, RHEL 7.1) the pids controller might not be there (or not fully supported) so it was added as optional  , see the coding
> 
> 
>   if (!cg_infos[PIDS_IDX]._data_complete) {
>     log_debug(os, container)("Optional cgroup v1 pids subsystem not found");
>     // keep the other controller info, pids is optional
>   }

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

  Add hotspot tests

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4518/files
  - new: https://git.openjdk.java.net/jdk/pull/4518/files/f5527143..3fe73c3c

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

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

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

From mbaesken at openjdk.java.net  Thu Jul 15 13:24:19 2021
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Thu, 15 Jul 2021 13:24:19 GMT
Subject: RFR: JDK-8266490: Extend the OSContainer API to support the pids
 controller of cgroups [v2]
In-Reply-To: <ga__j-XfZjoFwlZi_Q69nCEYziyadbRwe7LId7RRxdA=.9a8f37e2-e77b-4857-ad14-273eded6caf2@github.com>
References: <MWenVRe4ptn5aua0DUHvxb-sdbu-Ykl9x0GlhmxKHhY=.1fb8901e-36c3-4c07-a6ed-b653120807de@github.com>
 <OO_Lxoony0VmDrg-VdikAu0xjQSceEUO-7wlPKIEZjc=.7a15039a-15d3-4b7c-aa7e-f44e3736f68d@github.com>
 <4TD_2jJOnOQ6-D2eCFdJzF3tQg_H-Vm6IrFcyX_xSIw=.028fbe3f-bc04-4b9c-8b35-a6a450a80f7f@github.com>
 <PRpXuavlV1Kl2wQcs81cA-ZxJg9feDzoSMHBjDSlfM0=.e5492d2f-c99d-4ec9-8586-1b80b96ea8f5@github.com>
 <DXWQW5zdXAT9GAqWnWxbN7sYEpLA5i2szlBz4IsNKRM=.0698e1aa-d4ba-49a7-8a20-299302436fa7@github.com>
 <ga__j-XfZjoFwlZi_Q69nCEYziyadbRwe7LId7RRxdA=.9a8f37e2-e77b-4857-ad14-273eded6caf2@github.com>
Message-ID: <lyyepyjam1r88i7Q03rzwWFmRj5iC1y4mkInTmsUb4s=.350974c3-da45-438e-82a5-bd6ec39d597f@github.com>

On Fri, 9 Jul 2021 13:53:27 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> > OK. Please also add a test on the hotspot side. You may want to add relevant parts to `TestMisc.java`.
> 
> Thanks for the suggestion, I will look into TestMisc.java .

I added some HS testing code in the latest commit.

Best regards, Matthias

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

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

From sgehwolf at openjdk.java.net  Thu Jul 15 13:42:17 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Thu, 15 Jul 2021 13:42:17 GMT
Subject: RFR: JDK-8266490: Extend the OSContainer API to support the pids
 controller of cgroups [v4]
In-Reply-To: <RWs56CmhmIHEUesFH6SXGRdo07sstXw3jSU4y37dddg=.fa6fa265-0637-4695-bb54-040b94833492@github.com>
References: <MWenVRe4ptn5aua0DUHvxb-sdbu-Ykl9x0GlhmxKHhY=.1fb8901e-36c3-4c07-a6ed-b653120807de@github.com>
 <RWs56CmhmIHEUesFH6SXGRdo07sstXw3jSU4y37dddg=.fa6fa265-0637-4695-bb54-040b94833492@github.com>
Message-ID: <3VJ1EMr_QoFConUexuO8Z1pUGuLoIKiNAlJyFT0HKHw=.e2904647-69c9-418e-b0be-db252d439e30@github.com>

On Thu, 15 Jul 2021 13:09:54 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Hello, please review this PR; it extend the OSContainer API in order to also support the pids controller of cgroups.
>> 
>> I noticed that unlike the other controllers "cpu", "cpuset", "cpuacct", "memory"  on some older Linux distros (SLES 12.1, RHEL 7.1) the pids controller might not be there (or not fully supported) so it was added as optional  , see the coding
>> 
>> 
>>   if (!cg_infos[PIDS_IDX]._data_complete) {
>>     log_debug(os, container)("Optional cgroup v1 pids subsystem not found");
>>     // keep the other controller info, pids is optional
>>   }
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add hotspot tests

Thanks, I'll test it and review once again. Meanwhile, please merge the master branch into your `JDK-8266490` branch and push so that we get a better ruling of pre-integration tests.

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

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

From darcy at openjdk.java.net  Thu Jul 15 13:57:15 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 15 Jul 2021 13:57:15 GMT
Subject: RFR: 8270547: java.util.Random contains unnecessary
 @SuppressWarnings("exports")
In-Reply-To: <1zvok0pcWa55YUY01VmZLadbT0haBz8RXjTg2V5R3sI=.a6dd9b54-cb7a-4d79-a64f-707da3dd7a0f@github.com>
References: <1zvok0pcWa55YUY01VmZLadbT0haBz8RXjTg2V5R3sI=.a6dd9b54-cb7a-4d79-a64f-707da3dd7a0f@github.com>
Message-ID: <Ddqmv_HGOXsQ5BSgPM5YfIDsC0O454XdnKBLOnWrOw8=.2be4aabf-2e18-480b-b2e8-3328ed1eaf41@github.com>

On Thu, 15 Jul 2021 12:07:42 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Removing unnecessary `@SuppressWarnings("exports")`. The reason for the suppress warnings was, as far as I can tell, removed by https://bugs.openjdk.java.net/browse/JDK-8265137.

Looks fine.

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

Marked as reviewed by darcy (Reviewer).

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

From bpb at openjdk.java.net  Thu Jul 15 15:42:16 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 15 Jul 2021 15:42:16 GMT
Subject: RFR: 8270547: java.util.Random contains unnecessary
 @SuppressWarnings("exports")
In-Reply-To: <1zvok0pcWa55YUY01VmZLadbT0haBz8RXjTg2V5R3sI=.a6dd9b54-cb7a-4d79-a64f-707da3dd7a0f@github.com>
References: <1zvok0pcWa55YUY01VmZLadbT0haBz8RXjTg2V5R3sI=.a6dd9b54-cb7a-4d79-a64f-707da3dd7a0f@github.com>
Message-ID: <ZXqpCXIvkanC5J76EvV5Lu_o2ozJBfFxs4ot90bY8J4=.8fbe566b-06ce-4c2b-a08c-e6befc649d0a@github.com>

On Thu, 15 Jul 2021 12:07:42 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Removing unnecessary `@SuppressWarnings("exports")`. The reason for the suppress warnings was, as far as I can tell, removed by https://bugs.openjdk.java.net/browse/JDK-8265137.

+1

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

Marked as reviewed by bpb (Reviewer).

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

From bpb at openjdk.java.net  Thu Jul 15 15:45:46 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 15 Jul 2021 15:45:46 GMT
Subject: RFR: 8075806: divideExact is missing in java.lang.Math [v3]
In-Reply-To: <8nZ1xpS-Ir7KIEuaryZ0bQ2upeqcMy9TBm7-afE5lek=.22ec71c9-49d7-4994-aa1e-638c9d522510@github.com>
References: <8nZ1xpS-Ir7KIEuaryZ0bQ2upeqcMy9TBm7-afE5lek=.22ec71c9-49d7-4994-aa1e-638c9d522510@github.com>
Message-ID: <M0UVuieADb3yxDlUV1JhSRXfj3Mcs_ReF5hws56WpVg=.3836bc64-3253-4e63-81eb-dc241d7aad0d@github.com>

> Please consider this proposal to add `divideExact()` methods for integral data types to `java.lang.Math` thereby rounding out "exact" support to all four basic arithmetic operations.

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

  8075806: Add StrictMath analogs

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4770/files
  - new: https://git.openjdk.java.net/jdk/pull/4770/files/6843e666..60adb9e5

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

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

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

From jvernee at openjdk.java.net  Thu Jul 15 15:54:50 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Thu, 15 Jul 2021 15:54:50 GMT
Subject: [jdk17] RFR: 8269240:
 java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC
 [v3]
In-Reply-To: <PqFCdTWCSge_X14Rc5aNAo2pr5uliZ9jT0iYltvef3g=.7467c1a4-ad15-48a3-a495-75b655acf69c@github.com>
References: <PqFCdTWCSge_X14Rc5aNAo2pr5uliZ9jT0iYltvef3g=.7467c1a4-ad15-48a3-a495-75b655acf69c@github.com>
Message-ID: <cavIUnm5LQtMXdPpG2WUo3pYBB2rs7MVe-l_T5tHnWo=.2215f2d8-f8ef-4f59-b0a0-61aed83af110@github.com>

> This patch rewrites the prologue and epilogue of panama upcalls, in order to fix the test failure from the title.
> 
> Previously, we did a call to potentially attach the current thread to the VM, and then afterwards did the same suspend and stack reguard checks that we do on the back-edge of a native downcall. Then, on the back edge of the upcall we did another conditional call to detach the thread.
> 
> The suspend and reguard checks on the front-edge are incorrect, so I've changed the 2 calls to mimic what is done by JavaCallWrapper instead (with attach and detach included), and removed the old suspend and stack reguard checks.
> 
> FWIW, this removes the JavaFrameAnchor save/restore MacroAssembler code. This is now written in C++. Also, MacroAssembler code was added to save/restore the result of the upcall around the call on the back-edge, which was previously missing. Since the new code allocates a handle block as well, I've added handling for those oops to frame & OptimizedUpcallBlob.
> 
> Testing: local running of `jdk_foreign` on Windows and Linux (WSL). Tier 1-3

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

  Address David's review comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/149/files
  - new: https://git.openjdk.java.net/jdk17/pull/149/files/211bf316..128f48db

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

  Stats: 20 lines in 3 files changed: 0 ins; 8 del; 12 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/149.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/149/head:pull/149

PR: https://git.openjdk.java.net/jdk17/pull/149

From jvernee at openjdk.java.net  Thu Jul 15 15:58:16 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Thu, 15 Jul 2021 15:58:16 GMT
Subject: [jdk17] RFR: 8269240:
 java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC
 [v3]
In-Reply-To: <cavIUnm5LQtMXdPpG2WUo3pYBB2rs7MVe-l_T5tHnWo=.2215f2d8-f8ef-4f59-b0a0-61aed83af110@github.com>
References: <PqFCdTWCSge_X14Rc5aNAo2pr5uliZ9jT0iYltvef3g=.7467c1a4-ad15-48a3-a495-75b655acf69c@github.com>
 <cavIUnm5LQtMXdPpG2WUo3pYBB2rs7MVe-l_T5tHnWo=.2215f2d8-f8ef-4f59-b0a0-61aed83af110@github.com>
Message-ID: <gS2RQY1pwpR8BoC-CjliHSmmsB4UjYNTgXyFEbnKyqs=.64a2c2bc-cf70-4137-baf1-b044dab087a6@github.com>

On Thu, 15 Jul 2021 15:54:50 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> This patch rewrites the prologue and epilogue of panama upcalls, in order to fix the test failure from the title.
>> 
>> Previously, we did a call to potentially attach the current thread to the VM, and then afterwards did the same suspend and stack reguard checks that we do on the back-edge of a native downcall. Then, on the back edge of the upcall we did another conditional call to detach the thread.
>> 
>> The suspend and reguard checks on the front-edge are incorrect, so I've changed the 2 calls to mimic what is done by JavaCallWrapper instead (with attach and detach included), and removed the old suspend and stack reguard checks.
>> 
>> FWIW, this removes the JavaFrameAnchor save/restore MacroAssembler code. This is now written in C++. Also, MacroAssembler code was added to save/restore the result of the upcall around the call on the back-edge, which was previously missing. Since the new code allocates a handle block as well, I've added handling for those oops to frame & OptimizedUpcallBlob.
>> 
>> Testing: local running of `jdk_foreign` on Windows and Linux (WSL). Tier 1-3
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address David's review comments

David, I've addressed your review comments.

For now I went with changing the return type of `on_entry` to `JavaThread*`, assuming the potential pointer conversion is not an issue. 

I tried for a while to implement a static assert to check that `Thread*` is trivial convertible to `JavaThread*` as well, but couldn't find a way to do that at compile time, so left it for now. It looks like C++ 20 has a type trait to check this: https://en.cppreference.com/w/cpp/types/is_pointer_interconvertible_base_of (I think this does what we want). I thought maybe we could just mimic the reference implementation, but looking at for instance the MSVC STL implementation, this type trait is implemented as a compiler intrinsic, so I think we'll have to wait until we are on C++ 20 before adding such a static assert.

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

PR: https://git.openjdk.java.net/jdk17/pull/149

From bpb at openjdk.java.net  Thu Jul 15 16:52:31 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 15 Jul 2021 16:52:31 GMT
Subject: RFR: 8075806: divideExact is missing in java.lang.Math [v4]
In-Reply-To: <8nZ1xpS-Ir7KIEuaryZ0bQ2upeqcMy9TBm7-afE5lek=.22ec71c9-49d7-4994-aa1e-638c9d522510@github.com>
References: <8nZ1xpS-Ir7KIEuaryZ0bQ2upeqcMy9TBm7-afE5lek=.22ec71c9-49d7-4994-aa1e-638c9d522510@github.com>
Message-ID: <CPmIQb48D7vPdgl_FFwW04dLuJY31PbskXFI4WyJn4Y=.32be6b20-6b32-4895-bda0-3730c6eaf2a0@github.com>

> Please consider this proposal to add `divideExact()` methods for integral data types to `java.lang.Math` thereby rounding out "exact" support to all four basic arithmetic operations.

Brian Burkhalter 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:

  8075806: Add StrictMath analogs

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4770/files
  - new: https://git.openjdk.java.net/jdk/pull/4770/files/60adb9e5..328e4188

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

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

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

From herrick at openjdk.java.net  Thu Jul 15 17:09:13 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Thu, 15 Jul 2021 17:09:13 GMT
Subject: Integrated: JDK-8269387: jpackage --add-launcher should have option
 to not create shortcuts for additional launchers
In-Reply-To: <gO8--JRs2F9hyLuR5gnanY-KYiH-wYSexmUbDGeaP0Q=.e8fa9a64-1018-427f-b1f9-72fc48671b21@github.com>
References: <gO8--JRs2F9hyLuR5gnanY-KYiH-wYSexmUbDGeaP0Q=.e8fa9a64-1018-427f-b1f9-72fc48671b21@github.com>
Message-ID: <L-Uzi1ViRCMD1PB8p4bwAveg8ufHyftgDHSJbNHO9lU=.16eb7599-870c-4dfb-b6a4-97b1e3f26892@github.com>

On Thu, 8 Jul 2021 19:25:33 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> JDK-8269387: jpackage --add-launcher should have option to not create shortcuts for additional launchers

This pull request has now been integrated.

Changeset: 057992f2
Author:    Andy Herrick <herrick at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/057992f206d48d0f6152f6fdece229e2ff56e375
Stats:     341 lines in 11 files changed: 258 ins; 13 del; 70 mod

8269387: jpackage --add-launcher should have option to not create shortcuts for additional launchers

Reviewed-by: asemenyuk, almatvee

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

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

From naoto at openjdk.java.net  Thu Jul 15 17:32:50 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 15 Jul 2021 17:32:50 GMT
Subject: RFR: 8260265: UTF-8 by Default [v4]
In-Reply-To: <-F4rYMOBcR8vg_mtYrJ--Ovx9d5bDLTF2p40uV5QqMM=.9cfd49ad-be84-4455-9695-138203395b21@github.com>
References: <-F4rYMOBcR8vg_mtYrJ--Ovx9d5bDLTF2p40uV5QqMM=.9cfd49ad-be84-4455-9695-138203395b21@github.com>
Message-ID: <0XnBkxB71TxtmuPYVNnWxoC609KRRHfhoa9dgi-X9So=.0e097cb9-0230-479d-9450-a91e1334dc20@github.com>

> This is an implementation for the `JEP 400: UTF-8 by Default`. The gist of the changes is `Charset.defaultCharset()` returning `UTF-8` and `file.encoding` system property being added in the spec, but another notable modification is in `java.io.PrintStream` where it continues to use the `Console` encoding as the default charset instead of `UTF-8`. Other changes are mostly clarification of the term "default charset" and their links. Corresponding CSR has also been drafted.
> 
> JEP 400: https://bugs.openjdk.java.net/browse/JDK-8187041
> CSR: https://bugs.openjdk.java.net/browse/JDK-8260266

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

  Removed leftover `console` references in `PrintStream`

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4733/files
  - new: https://git.openjdk.java.net/jdk/pull/4733/files/182dcb6d..38b8d988

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

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

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

From dholmes at openjdk.java.net  Thu Jul 15 23:00:29 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 15 Jul 2021 23:00:29 GMT
Subject: [jdk17] RFR: 8269240:
 java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC
 [v3]
In-Reply-To: <hBpL8Lz9hRJ3_Ee8ZhpfyxI3qLSya9yMTRo2fRI6Zdo=.c50761ec-0fb8-45c1-a6f7-99ba2c408512@github.com>
References: <PqFCdTWCSge_X14Rc5aNAo2pr5uliZ9jT0iYltvef3g=.7467c1a4-ad15-48a3-a495-75b655acf69c@github.com>
 <ebTR3Fg3FnrWIJX847RkbgTBN0Ma9rWbdyVR8WR0dhs=.349b6255-e6c7-46d8-b2df-8cd4d4dd13e8@github.com>
 <VW5GuwT6ccFopn__J_mIvIBaso53uR8i81DtuEh2AuM=.a5adb7ea-7a24-41d5-a1d0-cd972792dad6@github.com>
 <hBpL8Lz9hRJ3_Ee8ZhpfyxI3qLSya9yMTRo2fRI6Zdo=.c50761ec-0fb8-45c1-a6f7-99ba2c408512@github.com>
Message-ID: <r8EZ6JV8KgMt8OkTXblKPfHum4Dp4rjohVIDKYety08=.4d8ff226-ee1d-4a68-b296-3f033a316466@github.com>

On Thu, 15 Jul 2021 11:02:21 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> How does native code reach a safepoint polling point?
>
> The stack trace looks like this:
> 
> 
> Current thread (0x000002a2489f0b50):  JavaThread "Thread-4551" [_thread_in_Java, id=24920, stack(0x000000d9e0500000,0x000000d9e0600000)]
> 
> Stack: [0x000000d9e0500000,0x000000d9e0600000]
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [jvm.dll+0xae6651]  os::platform_print_native_stack+0xf1  (os_windows_x86.cpp:235)
> V  [jvm.dll+0xda3f25]  VMError::report+0x1005  (vmError.cpp:739)
> V  [jvm.dll+0xda58ae]  VMError::report_and_die+0x7fe  (vmError.cpp:1549)
> V  [jvm.dll+0xda5fe4]  VMError::report_and_die+0x64  (vmError.cpp:1330)
> V  [jvm.dll+0x4ceca7]  report_vm_error+0xb7  (debug.cpp:282)
> V  [jvm.dll+0x6511be]  HandleArea::allocate_handle+0x3e  (handles.cpp:35)
> V  [jvm.dll+0xb8e334]  ThreadSafepointState::handle_polling_page_exception+0x314  (safepoint.cpp:939)
> C  0x000002a035d8caa7
> 
> Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
> v  ~SafepointBlob
> J 639 c1 java.lang.invoke.LambdaForm$MH+0x000000080101b800.invoke(Ljava/lang/Object;)V java.base at 18-internal (87 bytes) @ 0x000002a03635f7b4 [0x000002a03635f4a0+0x0000000000000314]
> J 620 c1 java.lang.invoke.LambdaForm$MH+0x0000000801018c00.invoke(Ljava/lang/Object;)V java.base at 18-internal (37 bytes) @ 0x000002a036353e0c [0x000002a036353720+0x00000000000006ec]
> v  ~BufferBlob::m?Y?????G?
> 
> 
> So I think the 'native code' is something being called by the safepoint blob, but I'm not sure why it's marked with a `C` instead of `V` in the stack trace (maybe just a stack unwind failure?).
> 
> FWIW, this part has already been fixed as part of: https://github.com/openjdk/jdk17/pull/173 (not sure why it still shows up in the diff)

Okay so we're not actually _thread_in_native it is just a chunk of VM generated code. Something still seems off to me about the need for the HandleMark but that isn't your problem.

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

PR: https://git.openjdk.java.net/jdk17/pull/149

From kvn at openjdk.java.net  Thu Jul 15 23:47:17 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Thu, 15 Jul 2021 23:47:17 GMT
Subject: [jdk17] RFR: 8269240:
 java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC
 [v2]
In-Reply-To: <iFQizlIjNo63-wowvyQkjsPBmY--Rgy1pWhEN94GuUw=.b0d3f899-b665-427a-ae1c-65bd3b7c7721@github.com>
References: <PqFCdTWCSge_X14Rc5aNAo2pr5uliZ9jT0iYltvef3g=.7467c1a4-ad15-48a3-a495-75b655acf69c@github.com>
 <o-O6F0omoRjgCjD28Ir79_QYw2xdT_1SlIu2h0eLqH0=.a9e4053d-4464-40de-94df-39fc98e4eaaf@github.com>
 <e7gBayKnokRzWTDb2LQFrP8eikV-UrRN_Y0JGCzY55w=.962eb647-c232-47b5-95c2-4844d8a36204@github.com>
 <fyyuRO2J0ekD3Y5aSd96rGzJDImawCygjqtMXRB1EA0=.0105932c-1d93-4287-8df7-30b1fd6b3090@github.com>
 <iFQizlIjNo63-wowvyQkjsPBmY--Rgy1pWhEN94GuUw=.b0d3f899-b665-427a-ae1c-65bd3b7c7721@github.com>
Message-ID: <4q2WY6-y3tV9zRqLlR6mWPhwd-nQ-Ai0JCxqA16taXE=.05ff5f90-2ace-470a-b237-30c6b97055f9@github.com>

On Thu, 15 Jul 2021 12:44:23 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Thanks.
>> 
>> I've been careful here to return a `Thread*` since the result is stored in `r15_thread` and I thought converting between sub and super types could potentially result in different pointers due to the way super types are laid out within a subtype. I thought it worked like this:
>> 
>> 
>> Subclass
>> +---
>> | {Subclass vtable pointer}
>> | +--- (base class Super)
>> | | {Super vtable pointer}
>> | +---
>> +---
>> 
>> 
>> So, I thought plainly using a `JavaThread*` in generated machine code where a `Thread*` was expected could cause trouble, since the pointer needs to be offset for the type conversion.
>> 
>> But now that I'm looking at some cases with compiler explorer, the pointer offset only seems to be needed when using multiple inheritance, for instance:
>> 
>> 
>> class SuperA {
>> public:
>>     virtual void foo();
>> };
>> 
>> class SuperB {
>> public:
>>     virtual void bar();
>> };
>> 
>> class Sub : public SuperA, public SuperB {
>> public:
>>     virtual void baz();
>> };
>> 
>> 
>> Results in:
>> 
>> 
>> class Sub	size(16):
>> 	+---
>>  0	| +--- (base class SuperA)
>>  0	| | {vfptr}
>> 	| +---
>>  8	| +--- (base class SuperB)
>>  8	| | {vfptr}
>> 	| +---
>> 	+---
>> 
>> Sub::$vftable at SuperA@:
>> 	| &Sub_meta
>> 	|  0
>>  0	| &SuperA::foo 
>>  1	| &Sub::baz 
>> 
>> Sub::$vftable at SuperB@:
>> 	| -8
>>  0	| &SuperB::bar 
>> 
>> Sub::baz this adjustor: 0
>> 
>> 
>> (https://godbolt.org/z/1665fWzff)
>> 
>> It seems that the sub type just reuses the vtable pointer of the first super type (probably to avoid having to do this pointer offsetting). Though, converting between `SuperB*` and `Sub*` would require offsetting the pointer. I'm still not sure this is guaranteed to work like this with all compilers though (the example is with MSVC, which has options to dump class layouts).
>> 
>> The result of `on_entry` is stored in `r15_thread`, so I guess I'm wondering if it's safe to store a `JavaThread*` instead of a `Thread*` in `r15`, and other code, which may expect `r15` to hold a `Thread*`, is guaranteed to keep working? (FWIW, after changing the return type to `JavaThread*` the tests that exercise this code still pass on Windows with MSVC, and on WSL Linux with GCC).
>
> Sorry, I sent the wrong godbolt link: https://godbolt.org/z/1665fWzff

@JornVernee I have small correct to your comment. We use simple inheritance for Thread subclasses. Their instances have **one** vtbl pointer at the same offset as in base class. But this pointer will point to separate vtable for each subclass (and base class). The layout (sequence) of methods pointers in vtable is the same in base class and subclasses. But subclass specific methods pointers will be different.

The only issue is that you have to make sure to cast passed object pointer to correct subclass (or base class). Otherwise you will get incorrect vtable and incorrect virtual methods pointers.

R15 is used by our JIT compiled code and Interpreter code which are executed only in JavaThread so the pinter it contains is JavaThread*

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

PR: https://git.openjdk.java.net/jdk17/pull/149

From sviswanathan at openjdk.java.net  Fri Jul 16 01:41:17 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Fri, 16 Jul 2021 01:41:17 GMT
Subject: RFR: 8266054: VectorAPI rotate operation optimization [v10]
In-Reply-To: <j-MimQL3RfOga-_XaS0UWHPsmDp99CyUer8f_bFptmo=.231d4cc0-e9ee-47d8-ad6c-41adcf114367@github.com>
References: <OZ2u4DDNaYF3WiR5uU6NWvzPMKV3j8QAO_mZyLP3Isg=.594e3514-8a5a-442c-ac1a-ca6c6d14e963@github.com>
 <j-MimQL3RfOga-_XaS0UWHPsmDp99CyUer8f_bFptmo=.231d4cc0-e9ee-47d8-ad6c-41adcf114367@github.com>
Message-ID: <mF_TPuiSWMhsH4OoVgvPDJ2VcSP8MGhj1mL7ACIyoQg=.e9e159d5-90ec-470a-84b9-167c36ce6c7f@github.com>

On Thu, 15 Jul 2021 08:34:42 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Current VectorAPI Java side implementation expresses rotateLeft and rotateRight operation using following operations:-
>> 
>>     vec1 = lanewise(VectorOperators.LSHL, n)
>>     vec2 = lanewise(VectorOperators.LSHR, n)
>>     res = lanewise(VectorOperations.OR, vec1 , vec2)
>> 
>> This patch moves above handling from Java side to C2 compiler which facilitates dismantling the rotate operation if target ISA does not support a direct rotate instruction.
>> 
>> AVX512 added vector rotate instructions vpro[rl][v][dq] which operate over long and integer type vectors. For other cases (i.e. sub-word type vectors or for targets which do not support direct rotate operations )   instruction sequence comprising of vector SHIFT (LEFT/RIGHT) and vector OR is emitted.
>> 
>> Please find below the performance data for included JMH benchmark.
>> Machine:  Cascade Lake Server (Intel(R) Xeon(R) Platinum 8280 CPU @ 2.70GHz)
>> 
>> 
>> Benchmark | (TESTSIZE) | Shift | Baseline AVX3 (ops/ms) | Withopt? AVX3 (ops/ms) | Gain % | Baseline AVX2 (ops/ms) | Withopt AVX2 (ops/ms) | Gain %
>> -- | -- | -- | -- | -- | -- | -- | -- | --
>> ? | ? | ? | ? | ? | ? | ? | ? | ?
>> RotateBenchmark.testRotateLeftB | 128.00 | 7.00 | 17223.35 | 17094.69 | -0.75 | 17008.32 | 17488.06 | 2.82
>> RotateBenchmark.testRotateLeftB | 128.00 | 7.00 | 8944.98 | 8811.34 | -1.49 | 8878.17 | 9218.68 | 3.84
>> RotateBenchmark.testRotateLeftB | 128.00 | 15.00 | 17195.75 | 17137.32 | -0.34 | 16789.01 | 17780.34 | 5.90
>> RotateBenchmark.testRotateLeftB | 128.00 | 15.00 | 9052.67 | 8838.60 | -2.36 | 8814.62 | 9206.01 | 4.44
>> RotateBenchmark.testRotateLeftB | 128.00 | 31.00 | 17100.19 | 16950.64 | -0.87 | 16827.73 | 17720.37 | 5.30
>> RotateBenchmark.testRotateLeftB | 128.00 | 31.00 | 9079.95 | 8471.26 | -6.70 | 8888.44 | 9167.68 | 3.14
>> RotateBenchmark.testRotateLeftB | 256.00 | 7.00 | 21231.33 | 21513.08 | 1.33 | 21824.51 | 21479.48 | -1.58
>> RotateBenchmark.testRotateLeftB | 256.00 | 7.00 | 11103.62 | 11180.16 | 0.69 | 11173.67 | 11529.22 | 3.18
>> RotateBenchmark.testRotateLeftB | 256.00 | 15.00 | 21119.14 | 21552.04 | 2.05 | 21693.05 | 21915.37 | 1.02
>> RotateBenchmark.testRotateLeftB | 256.00 | 15.00 | 11048.68 | 11094.20 | 0.41 | 11049.90 | 11439.07 | 3.52
>> RotateBenchmark.testRotateLeftB | 256.00 | 31.00 | 21506.31 | 21391.41 | -0.53 | 21263.18 | 21986.29 | 3.40
>> RotateBenchmark.testRotateLeftB | 256.00 | 31.00 | 11056.12 | 11232.78 | 1.60 | 10941.59 | 11397.09 | 4.16
>> RotateBenchmark.testRotateLeftB | 512.00 | 7.00 | 17976.56 | 18180.85 | 1.14 | 1212.26 | 2533.34 | 108.98
>> RotateBenchmark.testRotateLeftB | 512.00 | 15.00 | 17553.70 | 18219.07 | 3.79 | 1256.73 | 2537.41 | 101.91
>> RotateBenchmark.testRotateLeftB | 512.00 | 31.00 | 17618.03 | 17738.15 | 0.68 | 1214.69 | 2533.83 | 108.60
>> RotateBenchmark.testRotateLeftI | 128.00 | 7.00 | 7258.87 | 7468.88 | 2.89 | 7115.12 | 7117.26 | 0.03
>> RotateBenchmark.testRotateLeftI | 128.00 | 7.00 | 3586.65 | 3950.85 | 10.15 | 3532.17 | 3595.80 | 1.80
>> RotateBenchmark.testRotateLeftI | 128.00 | 7.00 | 1835.07 | 1999.68 | 8.97 | 1789.90 | 1819.93 | 1.68
>> RotateBenchmark.testRotateLeftI | 128.00 | 15.00 | 7273.36 | 7410.91 | 1.89 | 7198.60 | 6994.79 | -2.83
>> RotateBenchmark.testRotateLeftI | 128.00 | 15.00 | 3674.98 | 3926.27 | 6.84 | 3549.90 | 3755.09 | 5.78
>> RotateBenchmark.testRotateLeftI | 128.00 | 15.00 | 1840.94 | 1882.25 | 2.24 | 1801.56 | 1872.89 | 3.96
>> RotateBenchmark.testRotateLeftI | 128.00 | 31.00 | 7457.11 | 7361.48 | -1.28 | 6975.33 | 7385.94 | 5.89
>> RotateBenchmark.testRotateLeftI | 128.00 | 31.00 | 3570.74 | 3929.30 | 10.04 | 3635.37 | 3736.67 | 2.79
>> RotateBenchmark.testRotateLeftI | 128.00 | 31.00 | 1902.32 | 1960.46 | 3.06 | 1812.32 | 1813.88 | 0.09
>> RotateBenchmark.testRotateLeftI | 256.00 | 7.00 | 11174.24 | 12044.52 | 7.79 | 11509.87 | 11273.44 | -2.05
>> RotateBenchmark.testRotateLeftI | 256.00 | 7.00 | 5981.47 | 6073.70 | 1.54 | 5593.66 | 5661.93 | 1.22
>> RotateBenchmark.testRotateLeftI | 256.00 | 7.00 | 2932.49 | 3069.54 | 4.67 | 2950.86 | 2892.42 | -1.98
>> RotateBenchmark.testRotateLeftI | 256.00 | 15.00 | 11764.11 | 12098.63 | 2.84 | 11069.52 | 11476.93 | 3.68
>> RotateBenchmark.testRotateLeftI | 256.00 | 15.00 | 5855.20 | 6080.40 | 3.85 | 5919.11 | 5607.04 | -5.27
>> RotateBenchmark.testRotateLeftI | 256.00 | 15.00 | 2989.05 | 3048.56 | 1.99 | 2902.63 | 2821.83 | -2.78
>> RotateBenchmark.testRotateLeftI | 256.00 | 31.00 | 11652.84 | 11965.40 | 2.68 | 11525.62 | 11459.83 | -0.57
>> RotateBenchmark.testRotateLeftI | 256.00 | 31.00 | 5851.82 | 6164.94 | 5.35 | 5882.60 | 5842.30 | -0.69
>> RotateBenchmark.testRotateLeftI | 256.00 | 31.00 | 3015.99 | 3043.79 | 0.92 | 2963.71 | 2947.97 | -0.53
>> RotateBenchmark.testRotateLeftI | 512.00 | 7.00 | 16029.15 | 16189.79 | 1.00 | 860.43 | 2339.32 | 171.88
>> RotateBenchmark.testRotateLeftI | 512.00 | 7.00 | 8078.25 | 8081.84 | 0.04 | 427.39 | 1147.92 | 168.59
>> RotateBenchmark.testRotateLeftI | 512.00 | 7.00 | 4021.49 | 4294.03 | 6.78 | 209.25 | 582.28 | 178.27
>> RotateBenchmark.testRotateLeftI | 512.00 | 15.00 | 15912.98 | 16329.03 | 2.61 | 848.23 | 2296.78 | 170.77
>> RotateBenchmark.testRotateLeftI | 512.00 | 15.00 | 8054.10 | 8306.37 | 3.13 | 429.93 | 1146.90 | 166.77
>> RotateBenchmark.testRotateLeftI | 512.00 | 15.00 | 4102.58 | 4071.08 | -0.77 | 217.86 | 582.20 | 167.24
>> RotateBenchmark.testRotateLeftI | 512.00 | 31.00 | 16177.79 | 16287.85 | 0.68 | 857.84 | 2243.15 | 161.49
>> RotateBenchmark.testRotateLeftI | 512.00 | 31.00 | 8187.47 | 8410.48 | 2.72 | 434.60 | 1128.20 | 159.60
>> RotateBenchmark.testRotateLeftI | 512.00 | 31.00 | 4109.15 | 4233.80 | 3.03 | 208.71 | 572.43 | 174.27
>> RotateBenchmark.testRotateLeftL | 128.00 | 7.00 | 3755.09 | 3930.29 | 4.67 | 3604.19 | 3598.47 | -0.16
>> RotateBenchmark.testRotateLeftL | 128.00 | 7.00 | 1829.03 | 1957.39 | 7.02 | 1833.95 | 1808.38 | -1.39
>> RotateBenchmark.testRotateLeftL | 128.00 | 7.00 | 915.35 | 970.55 | 6.03 | 916.25 | 899.08 | -1.87
>> RotateBenchmark.testRotateLeftL | 128.00 | 15.00 | 3664.85 | 3812.26 | 4.02 | 3629.37 | 3579.23 | -1.38
>> RotateBenchmark.testRotateLeftL | 128.00 | 15.00 | 1829.51 | 1877.76 | 2.64 | 1781.05 | 1807.57 | 1.49
>> RotateBenchmark.testRotateLeftL | 128.00 | 15.00 | 913.37 | 953.42 | 4.38 | 912.26 | 908.73 | -0.39
>> RotateBenchmark.testRotateLeftL | 128.00 | 31.00 | 3648.45 | 3899.20 | 6.87 | 3552.67 | 3581.04 | 0.80
>> RotateBenchmark.testRotateLeftL | 128.00 | 31.00 | 1816.50 | 1959.68 | 7.88 | 1820.88 | 1819.71 | -0.06
>> RotateBenchmark.testRotateLeftL | 128.00 | 31.00 | 901.05 | 955.13 | 6.00 | 913.74 | 907.90 | -0.64
>> RotateBenchmark.testRotateLeftL | 256.00 | 7.00 | 5850.99 | 6108.64 | 4.40 | 5882.65 | 5755.21 | -2.17
>> RotateBenchmark.testRotateLeftL | 256.00 | 7.00 | 2962.21 | 3060.47 | 3.32 | 2955.20 | 2909.18 | -1.56
>> RotateBenchmark.testRotateLeftL | 256.00 | 7.00 | 1480.46 | 1534.72 | 3.66 | 1467.78 | 1430.60 | -2.53
>> RotateBenchmark.testRotateLeftL | 256.00 | 15.00 | 5858.23 | 6047.51 | 3.23 | 5770.02 | 5773.19 | 0.05
>> RotateBenchmark.testRotateLeftL | 256.00 | 15.00 | 2951.49 | 3096.53 | 4.91 | 2885.21 | 2899.31 | 0.49
>> RotateBenchmark.testRotateLeftL | 256.00 | 15.00 | 1486.26 | 1527.94 | 2.80 | 1441.93 | 1454.25 | 0.85
>> RotateBenchmark.testRotateLeftL | 256.00 | 31.00 | 5873.21 | 6089.75 | 3.69 | 5767.58 | 5664.11 | -1.79
>> RotateBenchmark.testRotateLeftL | 256.00 | 31.00 | 2969.67 | 3081.39 | 3.76 | 2878.50 | 2905.86 | 0.95
>> RotateBenchmark.testRotateLeftL | 256.00 | 31.00 | 1452.21 | 1520.03 | 4.67 | 1430.30 | 1485.63 | 3.87
>> RotateBenchmark.testRotateLeftL | 512.00 | 7.00 | 8088.65 | 8443.63 | 4.39 | 455.67 | 1226.33 | 169.13
>> RotateBenchmark.testRotateLeftL | 512.00 | 7.00 | 4011.95 | 4120.25 | 2.70 | 229.77 | 619.87 | 169.77
>> RotateBenchmark.testRotateLeftL | 512.00 | 7.00 | 2090.57 | 2109.53 | 0.91 | 115.21 | 310.36 | 169.37
>> RotateBenchmark.testRotateLeftL | 512.00 | 15.00 | 8166.84 | 8557.28 | 4.78 | 457.67 | 1242.86 | 171.56
>> RotateBenchmark.testRotateLeftL | 512.00 | 15.00 | 4137.02 | 4287.95 | 3.65 | 227.26 | 624.80 | 174.93
>> RotateBenchmark.testRotateLeftL | 512.00 | 15.00 | 2095.01 | 2102.86 | 0.37 | 114.26 | 310.83 | 172.03
>> RotateBenchmark.testRotateLeftL | 512.00 | 31.00 | 8082.68 | 8400.56 | 3.93 | 459.59 | 1230.07 | 167.64
>> RotateBenchmark.testRotateLeftL | 512.00 | 31.00 | 4047.67 | 4147.58 | 2.47 | 229.01 | 606.38 | 164.78
>> RotateBenchmark.testRotateLeftL | 512.00 | 31.00 | 2086.83 | 2126.72 | 1.91 | 111.93 | 305.66 | 173.08
>> RotateBenchmark.testRotateLeftS | 128.00 | 7.00 | 13597.19 | 13255.09 | -2.52 | 13818.39 | 13242.40 | -4.17
>> RotateBenchmark.testRotateLeftS | 128.00 | 7.00 | 7028.26 | 6826.59 | -2.87 | 6765.15 | 6907.87 | 2.11
>> RotateBenchmark.testRotateLeftS | 128.00 | 7.00 | 3570.40 | 3468.01 | -2.87 | 3449.66 | 3533.50 | 2.43
>> RotateBenchmark.testRotateLeftS | 128.00 | 15.00 | 13615.99 | 13464.40 | -1.11 | 13330.02 | 13870.57 | 4.06
>> RotateBenchmark.testRotateLeftS | 128.00 | 15.00 | 7043.31 | 6763.34 | -3.97 | 6928.88 | 7063.57 | 1.94
>> RotateBenchmark.testRotateLeftS | 128.00 | 15.00 | 3495.12 | 3537.62 | 1.22 | 3503.41 | 3457.67 | -1.31
>> RotateBenchmark.testRotateLeftS | 128.00 | 31.00 | 13591.66 | 13665.84 | 0.55 | 13773.27 | 13126.08 | -4.70
>> RotateBenchmark.testRotateLeftS | 128.00 | 31.00 | 7027.08 | 7011.24 | -0.23 | 6974.98 | 6815.50 | -2.29
>> RotateBenchmark.testRotateLeftS | 128.00 | 31.00 | 3568.28 | 3569.62 | 0.04 | 3580.67 | 3463.58 | -3.27
>> RotateBenchmark.testRotateLeftS | 256.00 | 7.00 | 21154.03 | 21416.32 | 1.24 | 21187.01 | 21401.61 | 1.01
>> RotateBenchmark.testRotateLeftS | 256.00 | 7.00 | 11194.24 | 10865.47 | -2.94 | 11063.19 | 10977.60 | -0.77
>> RotateBenchmark.testRotateLeftS | 256.00 | 7.00 | 5797.80 | 5523.94 | -4.72 | 5654.63 | 5468.78 | -3.29
>> RotateBenchmark.testRotateLeftS | 256.00 | 15.00 | 21333.89 | 21412.74 | 0.37 | 21610.94 | 20908.96 | -3.25
>> RotateBenchmark.testRotateLeftS | 256.00 | 15.00 | 11327.07 | 11113.48 | -1.89 | 11148.25 | 10678.14 | -4.22
>> RotateBenchmark.testRotateLeftS | 256.00 | 15.00 | 5810.69 | 5569.72 | -4.15 | 5663.26 | 5618.87 | -0.78
>> RotateBenchmark.testRotateLeftS | 256.00 | 31.00 | 21753.20 | 21198.43 | -2.55 | 21567.90 | 21929.81 | 1.68
>> RotateBenchmark.testRotateLeftS | 256.00 | 31.00 | 11517.08 | 11039.64 | -4.15 | 11103.08 | 10871.59 | -2.08
>> RotateBenchmark.testRotateLeftS | 256.00 | 31.00 | 5897.16 | 5606.75 | -4.92 | 5459.87 | 5604.12 | 2.64
>> RotateBenchmark.testRotateLeftS | 512.00 | 7.00 | 29748.53 | 28883.73 | -2.91 | 1549.02 | 3928.53 | 153.61
>> RotateBenchmark.testRotateLeftS | 512.00 | 7.00 | 15197.09 | 15878.19 | 4.48 | 772.59 | 1924.35 | 149.08
>> RotateBenchmark.testRotateLeftS | 512.00 | 7.00 | 8046.30 | 8081.19 | 0.43 | 388.11 | 990.28 | 155.16
>> RotateBenchmark.testRotateLeftS | 512.00 | 15.00 | 30618.04 | 29419.19 | -3.92 | 1524.22 | 3915.97 | 156.92
>> RotateBenchmark.testRotateLeftS | 512.00 | 15.00 | 15854.43 | 15846.37 | -0.05 | 766.09 | 1953.60 | 155.01
>> RotateBenchmark.testRotateLeftS | 512.00 | 15.00 | 7814.77 | 7899.30 | 1.08 | 390.82 | 970.37 | 148.29
>> RotateBenchmark.testRotateLeftS | 512.00 | 31.00 | 29596.82 | 28538.69 | -3.58 | 1530.45 | 3906.91 | 155.28
>> RotateBenchmark.testRotateLeftS | 512.00 | 31.00 | 15662.48 | 15849.25 | 1.19 | 778.08 | 1934.31 | 148.60
>> RotateBenchmark.testRotateLeftS | 512.00 | 31.00 | 8121.14 | 7758.59 | -4.46 | 392.78 | 959.73 | 144.34
>> RotateBenchmark.testRotateRightB | 128.00 | 7.00 | 17465.84 | 17069.34 | -2.27 | 16849.73 | 17842.08 | 5.89
>> RotateBenchmark.testRotateRightB | 128.00 | 7.00 | 9049.19 | 8864.15 | -2.04 | 8786.67 | 9105.34 | 3.63
>> RotateBenchmark.testRotateRightB | 128.00 | 15.00 | 17703.38 | 17070.98 | -3.57 | 16595.85 | 17784.68 | 7.16
>> RotateBenchmark.testRotateRightB | 128.00 | 15.00 | 9007.68 | 8817.41 | -2.11 | 8704.49 | 9185.87 | 5.53
>> RotateBenchmark.testRotateRightB | 128.00 | 31.00 | 17531.05 | 16983.40 | -3.12 | 16947.69 | 17655.40 | 4.18
>> RotateBenchmark.testRotateRightB | 128.00 | 31.00 | 8986.30 | 8794.15 | -2.14 | 8816.62 | 9225.95 | 4.64
>> RotateBenchmark.testRotateRightB | 256.00 | 7.00 | 21293.95 | 21506.74 | 1.00 | 21163.29 | 21854.03 | 3.26
>> RotateBenchmark.testRotateRightB | 256.00 | 7.00 | 11258.47 | 11072.92 | -1.65 | 11118.12 | 11338.96 | 1.99
>> RotateBenchmark.testRotateRightB | 256.00 | 15.00 | 21253.36 | 21292.37 | 0.18 | 21224.39 | 21763.88 | 2.54
>> RotateBenchmark.testRotateRightB | 256.00 | 15.00 | 11064.80 | 11198.35 | 1.21 | 10960.98 | 11294.14 | 3.04
>> RotateBenchmark.testRotateRightB | 256.00 | 31.00 | 21358.14 | 21346.21 | -0.06 | 21487.25 | 21854.42 | 1.71
>> RotateBenchmark.testRotateRightB | 256.00 | 31.00 | 11045.61 | 11208.26 | 1.47 | 10907.03 | 11415.18 | 4.66
>> RotateBenchmark.testRotateRightB | 512.00 | 7.00 | 17898.61 | 18307.54 | 2.28 | 1214.65 | 2546.64 | 109.66
>> RotateBenchmark.testRotateRightB | 512.00 | 15.00 | 17909.25 | 18242.51 | 1.86 | 1215.05 | 2563.98 | 111.02
>> RotateBenchmark.testRotateRightB | 512.00 | 31.00 | 17883.35 | 17928.44 | 0.25 | 1220.77 | 2543.30 | 108.34
>> RotateBenchmark.testRotateRightI | 128.00 | 7.00 | 7139.97 | 7626.72 | 6.82 | 6994.86 | 7075.65 | 1.15
>> RotateBenchmark.testRotateRightI | 128.00 | 7.00 | 3657.37 | 3898.34 | 6.59 | 3617.06 | 3576.12 | -1.13
>> RotateBenchmark.testRotateRightI | 128.00 | 7.00 | 1804.26 | 1969.19 | 9.14 | 1796.62 | 1858.84 | 3.46
>> RotateBenchmark.testRotateRightI | 128.00 | 15.00 | 7404.31 | 7760.09 | 4.80 | 7036.77 | 7401.52 | 5.18
>> RotateBenchmark.testRotateRightI | 128.00 | 15.00 | 3600.52 | 3956.35 | 9.88 | 3595.28 | 3560.36 | -0.97
>> RotateBenchmark.testRotateRightI | 128.00 | 15.00 | 1813.32 | 1966.41 | 8.44 | 1839.95 | 1852.53 | 0.68
>> RotateBenchmark.testRotateRightI | 128.00 | 31.00 | 7118.48 | 7724.81 | 8.52 | 7151.56 | 7021.09 | -1.82
>> RotateBenchmark.testRotateRightI | 128.00 | 31.00 | 3529.70 | 3881.63 | 9.97 | 3623.08 | 3601.01 | -0.61
>> RotateBenchmark.testRotateRightI | 128.00 | 31.00 | 1823.61 | 1961.34 | 7.55 | 1786.86 | 1748.85 | -2.13
>> RotateBenchmark.testRotateRightI | 256.00 | 7.00 | 11697.98 | 11835.25 | 1.17 | 11513.16 | 11184.87 | -2.85
>> RotateBenchmark.testRotateRightI | 256.00 | 7.00 | 5890.11 | 6102.57 | 3.61 | 5658.79 | 5696.08 | 0.66
>> RotateBenchmark.testRotateRightI | 256.00 | 7.00 | 2964.94 | 3070.26 | 3.55 | 2945.00 | 2962.08 | 0.58
>> RotateBenchmark.testRotateRightI | 256.00 | 15.00 | 11562.51 | 12151.29 | 5.09 | 11404.17 | 11120.28 | -2.49
>> RotateBenchmark.testRotateRightI | 256.00 | 15.00 | 5702.93 | 6130.57 | 7.50 | 5799.54 | 5779.08 | -0.35
>> RotateBenchmark.testRotateRightI | 256.00 | 15.00 | 2861.96 | 3051.44 | 6.62 | 2943.99 | 2860.65 | -2.83
>> RotateBenchmark.testRotateRightI | 256.00 | 31.00 | 11203.13 | 11710.59 | 4.53 | 11363.18 | 11112.16 | -2.21
>> RotateBenchmark.testRotateRightI | 256.00 | 31.00 | 5893.97 | 6070.71 | 3.00 | 5776.67 | 5648.84 | -2.21
>> RotateBenchmark.testRotateRightI | 256.00 | 31.00 | 2971.83 | 3046.76 | 2.52 | 2903.35 | 2833.88 | -2.39
>> RotateBenchmark.testRotateRightI | 512.00 | 7.00 | 16064.71 | 15851.35 | -1.33 | 861.93 | 2256.88 | 161.84
>> RotateBenchmark.testRotateRightI | 512.00 | 7.00 | 7916.80 | 8462.65 | 6.89 | 430.23 | 1147.30 | 166.67
>> RotateBenchmark.testRotateRightI | 512.00 | 7.00 | 4104.64 | 4068.28 | -0.89 | 216.30 | 572.86 | 164.84
>> RotateBenchmark.testRotateRightI | 512.00 | 15.00 | 16133.09 | 16281.59 | 0.92 | 856.36 | 2229.58 | 160.35
>> RotateBenchmark.testRotateRightI | 512.00 | 15.00 | 8127.26 | 8117.59 | -0.12 | 419.16 | 1176.42 | 180.66
>> RotateBenchmark.testRotateRightI | 512.00 | 15.00 | 4080.11 | 4063.26 | -0.41 | 218.32 | 571.93 | 161.97
>> RotateBenchmark.testRotateRightI | 512.00 | 31.00 | 15834.26 | 16314.64 | 3.03 | 865.96 | 2297.74 | 165.34
>> RotateBenchmark.testRotateRightI | 512.00 | 31.00 | 7965.62 | 8270.48 | 3.83 | 428.55 | 1148.87 | 168.08
>> RotateBenchmark.testRotateRightI | 512.00 | 31.00 | 4161.69 | 4034.76 | -3.05 | 215.63 | 570.19 | 164.43
>> RotateBenchmark.testRotateRightL | 128.00 | 7.00 | 3556.70 | 3877.08 | 9.01 | 3596.46 | 3558.32 | -1.06
>> RotateBenchmark.testRotateRightL | 128.00 | 7.00 | 1772.93 | 1993.86 | 12.46 | 1856.79 | 1783.22 | -3.96
>> RotateBenchmark.testRotateRightL | 128.00 | 7.00 | 908.66 | 1000.37 | 10.09 | 944.79 | 922.91 | -2.32
>> RotateBenchmark.testRotateRightL | 128.00 | 15.00 | 3742.44 | 3748.41 | 0.16 | 3788.07 | 3570.67 | -5.74
>> RotateBenchmark.testRotateRightL | 128.00 | 15.00 | 1817.53 | 1985.69 | 9.25 | 1892.38 | 1833.16 | -3.13
>> RotateBenchmark.testRotateRightL | 128.00 | 15.00 | 941.03 | 952.68 | 1.24 | 915.79 | 910.21 | -0.61
>> RotateBenchmark.testRotateRightL | 128.00 | 31.00 | 3649.48 | 3896.56 | 6.77 | 3637.59 | 3557.53 | -2.20
>> RotateBenchmark.testRotateRightL | 128.00 | 31.00 | 1840.12 | 1997.19 | 8.54 | 1821.47 | 1799.82 | -1.19
>> RotateBenchmark.testRotateRightL | 128.00 | 31.00 | 901.33 | 995.67 | 10.47 | 909.20 | 902.73 | -0.71
>> RotateBenchmark.testRotateRightL | 256.00 | 7.00 | 5789.93 | 5960.54 | 2.95 | 5758.14 | 5736.30 | -0.38
>> RotateBenchmark.testRotateRightL | 256.00 | 7.00 | 2963.20 | 3063.30 | 3.38 | 2943.48 | 2833.84 | -3.72
>> RotateBenchmark.testRotateRightL | 256.00 | 7.00 | 1501.81 | 1510.23 | 0.56 | 1463.85 | 1462.26 | -0.11
>> RotateBenchmark.testRotateRightL | 256.00 | 15.00 | 5870.05 | 5951.43 | 1.39 | 5794.74 | 5604.58 | -3.28
>> RotateBenchmark.testRotateRightL | 256.00 | 15.00 | 2971.36 | 3047.00 | 2.55 | 2931.19 | 2907.30 | -0.82
>> RotateBenchmark.testRotateRightL | 256.00 | 15.00 | 1473.97 | 1530.54 | 3.84 | 1473.45 | 1442.40 | -2.11
>> RotateBenchmark.testRotateRightL | 256.00 | 31.00 | 5858.08 | 6080.49 | 3.80 | 5863.69 | 5549.85 | -5.35
>> RotateBenchmark.testRotateRightL | 256.00 | 31.00 | 2916.24 | 3045.77 | 4.44 | 2981.59 | 2815.07 | -5.58
>> RotateBenchmark.testRotateRightL | 256.00 | 31.00 | 1441.20 | 1531.56 | 6.27 | 1492.47 | 1473.25 | -1.29
>> RotateBenchmark.testRotateRightL | 512.00 | 7.00 | 8147.24 | 8310.05 | 2.00 | 469.45 | 1235.21 | 163.12
>> RotateBenchmark.testRotateRightL | 512.00 | 7.00 | 4142.95 | 4258.86 | 2.80 | 234.14 | 615.52 | 162.88
>> RotateBenchmark.testRotateRightL | 512.00 | 7.00 | 2095.48 | 2087.20 | -0.40 | 113.55 | 311.19 | 174.05
>> RotateBenchmark.testRotateRightL | 512.00 | 15.00 | 8222.94 | 8246.58 | 0.29 | 458.91 | 1244.32 | 171.15
>> RotateBenchmark.testRotateRightL | 512.00 | 15.00 | 4160.04 | 4226.46 | 1.60 | 227.78 | 625.38 | 174.56
>> RotateBenchmark.testRotateRightL | 512.00 | 15.00 | 2064.63 | 2162.44 | 4.74 | 113.27 | 314.15 | 177.36
>> RotateBenchmark.testRotateRightL | 512.00 | 31.00 | 8157.94 | 8466.90 | 3.79 | 450.26 | 1221.90 | 171.37
>> RotateBenchmark.testRotateRightL | 512.00 | 31.00 | 4039.74 | 4283.33 | 6.03 | 224.82 | 612.68 | 172.53
>> RotateBenchmark.testRotateRightL | 512.00 | 31.00 | 2066.88 | 2147.51 | 3.90 | 110.97 | 303.43 | 173.42
>> RotateBenchmark.testRotateRightS | 128.00 | 7.00 | 13548.39 | 13245.87 | -2.23 | 13490.93 | 13084.76 | -3.01
>> RotateBenchmark.testRotateRightS | 128.00 | 7.00 | 7020.16 | 6768.85 | -3.58 | 6991.39 | 7044.32 | 0.76
>> RotateBenchmark.testRotateRightS | 128.00 | 7.00 | 3550.50 | 3505.19 | -1.28 | 3507.12 | 3612.86 | 3.01
>> RotateBenchmark.testRotateRightS | 128.00 | 15.00 | 13743.43 | 13325.44 | -3.04 | 13696.15 | 13255.80 | -3.22
>> RotateBenchmark.testRotateRightS | 128.00 | 15.00 | 6856.02 | 6969.18 | 1.65 | 6886.29 | 6834.12 | -0.76
>> RotateBenchmark.testRotateRightS | 128.00 | 15.00 | 3569.53 | 3492.76 | -2.15 | 3539.02 | 3470.02 | -1.95
>> RotateBenchmark.testRotateRightS | 128.00 | 31.00 | 13704.18 | 13495.07 | -1.53 | 13649.14 | 13583.87 | -0.48
>> RotateBenchmark.testRotateRightS | 128.00 | 31.00 | 7011.77 | 6953.93 | -0.82 | 6978.28 | 6740.30 | -3.41
>> RotateBenchmark.testRotateRightS | 128.00 | 31.00 | 3591.62 | 3620.12 | 0.79 | 3502.04 | 3510.05 | 0.23
>> RotateBenchmark.testRotateRightS | 256.00 | 7.00 | 21950.71 | 22113.60 | 0.74 | 21484.27 | 21596.64 | 0.52
>> RotateBenchmark.testRotateRightS | 256.00 | 7.00 | 11616.88 | 11099.73 | -4.45 | 11188.29 | 10737.68 | -4.03
>> RotateBenchmark.testRotateRightS | 256.00 | 7.00 | 5872.72 | 5579.12 | -5.00 | 5784.05 | 5454.57 | -5.70
>> RotateBenchmark.testRotateRightS | 256.00 | 15.00 | 22017.83 | 20817.97 | -5.45 | 21934.65 | 21356.90 | -2.63
>> RotateBenchmark.testRotateRightS | 256.00 | 15.00 | 11414.27 | 11044.86 | -3.24 | 11454.35 | 11140.34 | -2.74
>> RotateBenchmark.testRotateRightS | 256.00 | 15.00 | 5786.64 | 5634.05 | -2.64 | 5724.93 | 5639.99 | -1.48
>> RotateBenchmark.testRotateRightS | 256.00 | 31.00 | 21754.77 | 21466.01 | -1.33 | 21140.67 | 21970.03 | 3.92
>> RotateBenchmark.testRotateRightS | 256.00 | 31.00 | 11676.46 | 11358.64 | -2.72 | 11204.90 | 11213.48 | 0.08
>> RotateBenchmark.testRotateRightS | 256.00 | 31.00 | 5728.20 | 5772.49 | 0.77 | 5594.33 | 5544.25 | -0.90
>> RotateBenchmark.testRotateRightS | 512.00 | 7.00 | 30247.03 | 30179.41 | -0.22 | 1538.75 | 3975.82 | 158.38
>> RotateBenchmark.testRotateRightS | 512.00 | 7.00 | 15988.73 | 15621.42 | -2.30 | 776.04 | 1910.91 | 146.24
>> RotateBenchmark.testRotateRightS | 512.00 | 7.00 | 8115.84 | 8025.28 | -1.12 | 389.12 | 984.46 | 152.99
>> RotateBenchmark.testRotateRightS | 512.00 | 15.00 | 30110.91 | 30200.69 | 0.30 | 1532.49 | 3983.77 | 159.95
>> RotateBenchmark.testRotateRightS | 512.00 | 15.00 | 15957.90 | 15690.73 | -1.67 | 774.90 | 1931.00 | 149.19
>> RotateBenchmark.testRotateRightS | 512.00 | 15.00 | 8113.26 | 8037.93 | -0.93 | 391.90 | 965.53 | 146.37
>> RotateBenchmark.testRotateRightS | 512.00 | 31.00 | 29816.97 | 29891.54 | 0.25 | 1538.12 | 3881.93 | 152.38
>> RotateBenchmark.testRotateRightS | 512.00 | 31.00 | 15405.95 | 15619.17 | 1.38 | 762.49 | 1871.00 | 145.38
>> RotateBenchmark.testRotateRightS | 512.00 | 31.00 | 7919.80 | 7957.35 | 0.47 | 393.63 | 972.49 | 147.06
>
> Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
> 
>  - 8266054: Incorporating styling changes based on reviews.
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8266054
>  - Merge http://github.com/openjdk/jdk into JDK-8266054
>  - Merge http://github.com/openjdk/jdk into JDK-8266054
>  - Merge http://github.com/openjdk/jdk into JDK-8266054
>  - Merge branch 'JDK-8266054' of http://github.com/jatin-bhateja/jdk into JDK-8266054
>  - 8266054: Removing redundant teat templates.
>  - 8266054: Code reorganization for efficient sharing of logic to check rotate operation support on a target platform.
>  - 8266054: Removing redundant test templates.
>  - 8266054: Review comments resolution.
>  - ... and 5 more: https://git.openjdk.java.net/jdk/compare/07e90524...609c4143

src/hotspot/share/opto/vectorIntrinsics.cpp line 84:

> 82:         arch_supports_vector(Op_OrV, num_elem, elem_bt, VecMaskNotUsed)) {
> 83:       is_supported = true;
> 84:     }

When check_bcast is set, is_supported could be false when replicate is not supported. Is replicate not needed for shift+or sequence?

src/hotspot/share/opto/vectorIntrinsics.cpp line 86:

> 84:     }
> 85:     return is_supported;
> 86: }

Please add comments here why the Left/Right shift and Or opcodes are being checked here. Also add comments why for left shift we are only checking for int and long left shift opcodes whereas for right shift sub word opcodes are being checked.

src/hotspot/share/opto/vectorIntrinsics.cpp line 338:

> 336:     // TODO When mask usage is supported, VecMaskNotUsed needs to be VecMaskUseLoad.
> 337:     if ((sopc != 0) &&
> 338:         !arch_supports_vector(sopc, num_elem, elem_bt, is_vector_mask(vbox_klass) ? VecMaskUseAll : VecMaskNotUsed)) {

Could we not call arch_supports_vector_rotate from arch_supports_vector?

src/hotspot/share/opto/vectorIntrinsics.cpp line 1563:

> 1561:                          -0x80 <= cnt_type->get_con() && cnt_type->get_con() < 0x80;
> 1562:   if (is_rotate) {
> 1563:     if (!arch_supports_vector_rotate(sopc, num_elem, elem_bt, !is_const_rotate)) {

What is the relationship between check_bcast and !is_const_rotate? Some comments here on this would help.

src/hotspot/share/opto/vectorIntrinsics.cpp line 1590:

> 1588:       opd2 = gvn().transform(VectorNode::scalar2vector(cnt, num_elem, type_bt));
> 1589:     } else {
> 1590:       // constant shift.

Did you mean constant rotate here?

src/hotspot/share/opto/vectornode.cpp line 1180:

> 1178:       cnt = cnt->in(1);
> 1179:     }
> 1180:     shiftRCnt = cnt;

Why do we remove the And with mask here?

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

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

From dholmes at openjdk.java.net  Fri Jul 16 02:10:23 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 16 Jul 2021 02:10:23 GMT
Subject: [jdk17] RFR: 8269240:
 java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC
 [v2]
In-Reply-To: <66vtM23dULcHDhjAYzZipQHy0KQHxwNKleKJIUlFnDo=.fe454def-a1a6-4475-94c2-06e85eea53e9@github.com>
References: <PqFCdTWCSge_X14Rc5aNAo2pr5uliZ9jT0iYltvef3g=.7467c1a4-ad15-48a3-a495-75b655acf69c@github.com>
 <o-O6F0omoRjgCjD28Ir79_QYw2xdT_1SlIu2h0eLqH0=.a9e4053d-4464-40de-94df-39fc98e4eaaf@github.com>
 <e7gBayKnokRzWTDb2LQFrP8eikV-UrRN_Y0JGCzY55w=.962eb647-c232-47b5-95c2-4844d8a36204@github.com>
 <66vtM23dULcHDhjAYzZipQHy0KQHxwNKleKJIUlFnDo=.fe454def-a1a6-4475-94c2-06e85eea53e9@github.com>
Message-ID: <5BzyK6iLhqUQVIm9F6SH-Y3s5ykFtys605qqLvVbJs0=.62fdab67-7716-4f9a-9a25-19052f55da52@github.com>

On Thu, 15 Jul 2021 10:47:17 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> src/hotspot/share/prims/universalUpcallHandler.cpp line 121:
>> 
>>> 119:   }
>>> 120: 
>>> 121:   MACOS_AARCH64_ONLY(thread->enable_wx(WXExec));
>> 
>> Not clear why this is needed? JavaCallWrapper doesn't use it.
>
> I took this from JavaCallWrapper. Seems to have been added in 17 for the mach aarch64 port: https://github.com/openjdk/jdk17/blame/a32d2eefea12771522b942b32985df0fe50119e8/src/hotspot/share/runtime/javaCalls.cpp#L112

Sorry not sure what I was looking at when I didn't see this.

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

PR: https://git.openjdk.java.net/jdk17/pull/149

From dholmes at openjdk.java.net  Fri Jul 16 02:20:16 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 16 Jul 2021 02:20:16 GMT
Subject: [jdk17] RFR: 8269240:
 java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC
 [v3]
In-Reply-To: <cavIUnm5LQtMXdPpG2WUo3pYBB2rs7MVe-l_T5tHnWo=.2215f2d8-f8ef-4f59-b0a0-61aed83af110@github.com>
References: <PqFCdTWCSge_X14Rc5aNAo2pr5uliZ9jT0iYltvef3g=.7467c1a4-ad15-48a3-a495-75b655acf69c@github.com>
 <cavIUnm5LQtMXdPpG2WUo3pYBB2rs7MVe-l_T5tHnWo=.2215f2d8-f8ef-4f59-b0a0-61aed83af110@github.com>
Message-ID: <wqxaxlrKcv8j9N9q2ncHtucCsYGRV4aO6hII4fJHPRU=.23d6e58f-dfd8-4336-b427-7d085f742199@github.com>

On Thu, 15 Jul 2021 15:54:50 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> This patch rewrites the prologue and epilogue of panama upcalls, in order to fix the test failure from the title.
>> 
>> Previously, we did a call to potentially attach the current thread to the VM, and then afterwards did the same suspend and stack reguard checks that we do on the back-edge of a native downcall. Then, on the back edge of the upcall we did another conditional call to detach the thread.
>> 
>> The suspend and reguard checks on the front-edge are incorrect, so I've changed the 2 calls to mimic what is done by JavaCallWrapper instead (with attach and detach included), and removed the old suspend and stack reguard checks.
>> 
>> FWIW, this removes the JavaFrameAnchor save/restore MacroAssembler code. This is now written in C++. Also, MacroAssembler code was added to save/restore the result of the upcall around the call on the back-edge, which was previously missing. Since the new code allocates a handle block as well, I've added handling for those oops to frame & OptimizedUpcallBlob.
>> 
>> Testing: local running of `jdk_foreign` on Windows and Linux (WSL). Tier 1-3
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address David's review comments

Thanks for the updates.

Minor comments below.

David

src/hotspot/share/prims/universalUpcallHandler.cpp line 62:

> 60:     guarantee(result == JNI_OK, "Could not attach thread for upcall. JNI error code: %d", result);
> 61:     *should_detach = true;
> 62:     thread = Thread::current();

You could use JavaThread::current() here and avoid the later conversions.

src/hotspot/share/prims/universalUpcallHandler.cpp line 138:

> 136:   debug_only(thread->dec_java_call_counter());
> 137: 
> 138:   // Old thread-local info. has been restored. We are not back in native code.

Pre-existing: I think "not" should be "now".

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/149

From mbaesken at openjdk.java.net  Fri Jul 16 06:14:07 2021
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Fri, 16 Jul 2021 06:14:07 GMT
Subject: RFR: JDK-8266490: Extend the OSContainer API to support the pids
 controller of cgroups [v5]
In-Reply-To: <MWenVRe4ptn5aua0DUHvxb-sdbu-Ykl9x0GlhmxKHhY=.1fb8901e-36c3-4c07-a6ed-b653120807de@github.com>
References: <MWenVRe4ptn5aua0DUHvxb-sdbu-Ykl9x0GlhmxKHhY=.1fb8901e-36c3-4c07-a6ed-b653120807de@github.com>
Message-ID: <WIJ8PVBUx3qqQx0DJIzdaXdsj_iaPVM7PBINpO5F-O4=.7a5df000-3728-46d6-b344-2f9a4ce53bc2@github.com>

> Hello, please review this PR; it extend the OSContainer API in order to also support the pids controller of cgroups.
> 
> I noticed that unlike the other controllers "cpu", "cpuset", "cpuacct", "memory"  on some older Linux distros (SLES 12.1, RHEL 7.1) the pids controller might not be there (or not fully supported) so it was added as optional  , see the coding
> 
> 
>   if (!cg_infos[PIDS_IDX]._data_complete) {
>     log_debug(os, container)("Optional cgroup v1 pids subsystem not found");
>     // keep the other controller info, pids is optional
>   }

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

 - Merge remote-tracking branch 'origin/master' into JDK-8266490
 - Add hotspot tests
 - test and small adjustments suggested by Severin
 - Adjustments following Severins comments
 - JDK-8266490

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4518/files
  - new: https://git.openjdk.java.net/jdk/pull/4518/files/3fe73c3c..5fc52fb1

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

  Stats: 675520 lines in 5968 files changed: 547978 ins; 105328 del; 22214 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4518.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4518/head:pull/4518

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

From jlahoda at openjdk.java.net  Fri Jul 16 08:57:53 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Fri, 16 Jul 2021 08:57:53 GMT
Subject: Integrated: 8270547: java.util.Random contains unnecessary
 @SuppressWarnings("exports")
In-Reply-To: <1zvok0pcWa55YUY01VmZLadbT0haBz8RXjTg2V5R3sI=.a6dd9b54-cb7a-4d79-a64f-707da3dd7a0f@github.com>
References: <1zvok0pcWa55YUY01VmZLadbT0haBz8RXjTg2V5R3sI=.a6dd9b54-cb7a-4d79-a64f-707da3dd7a0f@github.com>
Message-ID: <BauAuj_3-zvtfPgyiUIf-VBcQAdiK7yV4Jict2_RZW4=.aa73374a-202b-4b6e-a1ff-574d21f9378c@github.com>

On Thu, 15 Jul 2021 12:07:42 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Removing unnecessary `@SuppressWarnings("exports")`. The reason for the suppress warnings was, as far as I can tell, removed by https://bugs.openjdk.java.net/browse/JDK-8265137.

This pull request has now been integrated.

Changeset: 90c219f3
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/90c219f37bc7da2a556d1733a148a7d445e900e3
Stats:     1 line in 1 file changed: 0 ins; 1 del; 0 mod

8270547: java.util.Random contains unnecessary @SuppressWarnings("exports")

Reviewed-by: darcy, bpb

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

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

From jvernee at openjdk.java.net  Fri Jul 16 11:55:57 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Fri, 16 Jul 2021 11:55:57 GMT
Subject: [jdk17] RFR: 8269240:
 java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC
 [v3]
In-Reply-To: <wqxaxlrKcv8j9N9q2ncHtucCsYGRV4aO6hII4fJHPRU=.23d6e58f-dfd8-4336-b427-7d085f742199@github.com>
References: <PqFCdTWCSge_X14Rc5aNAo2pr5uliZ9jT0iYltvef3g=.7467c1a4-ad15-48a3-a495-75b655acf69c@github.com>
 <cavIUnm5LQtMXdPpG2WUo3pYBB2rs7MVe-l_T5tHnWo=.2215f2d8-f8ef-4f59-b0a0-61aed83af110@github.com>
 <wqxaxlrKcv8j9N9q2ncHtucCsYGRV4aO6hII4fJHPRU=.23d6e58f-dfd8-4336-b427-7d085f742199@github.com>
Message-ID: <KTrEVoMDKBIJdbmWMZyraQef5u-VVg0BTwZn-E_gAi8=.bda8a353-92be-400d-84c0-31beb8415cf6@github.com>

On Fri, 16 Jul 2021 02:12: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:
>> 
>>   Address David's review comments
>
> src/hotspot/share/prims/universalUpcallHandler.cpp line 62:
> 
>> 60:     guarantee(result == JNI_OK, "Could not attach thread for upcall. JNI error code: %d", result);
>> 61:     *should_detach = true;
>> 62:     thread = Thread::current();
> 
> You could use JavaThread::current() here and avoid the later conversions.

Ok. The variable is initially initialized (hah) using `Thread::current_or_null()` and there was no equivalent that does that for `JavaThread`. I can add something like that though.

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

PR: https://git.openjdk.java.net/jdk17/pull/149

From jvernee at openjdk.java.net  Fri Jul 16 11:55:58 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Fri, 16 Jul 2021 11:55:58 GMT
Subject: [jdk17] RFR: 8269240:
 java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC
 [v2]
In-Reply-To: <4q2WY6-y3tV9zRqLlR6mWPhwd-nQ-Ai0JCxqA16taXE=.05ff5f90-2ace-470a-b237-30c6b97055f9@github.com>
References: <PqFCdTWCSge_X14Rc5aNAo2pr5uliZ9jT0iYltvef3g=.7467c1a4-ad15-48a3-a495-75b655acf69c@github.com>
 <o-O6F0omoRjgCjD28Ir79_QYw2xdT_1SlIu2h0eLqH0=.a9e4053d-4464-40de-94df-39fc98e4eaaf@github.com>
 <e7gBayKnokRzWTDb2LQFrP8eikV-UrRN_Y0JGCzY55w=.962eb647-c232-47b5-95c2-4844d8a36204@github.com>
 <fyyuRO2J0ekD3Y5aSd96rGzJDImawCygjqtMXRB1EA0=.0105932c-1d93-4287-8df7-30b1fd6b3090@github.com>
 <iFQizlIjNo63-wowvyQkjsPBmY--Rgy1pWhEN94GuUw=.b0d3f899-b665-427a-ae1c-65bd3b7c7721@github.com>
 <4q2WY6-y3tV9zRqLlR6mWPhwd-nQ-Ai0JCxqA16taXE=.05ff5f90-2ace-470a-b237-30c6b97055f9@github.com>
Message-ID: <EtP70HnhABN0Q6AGxupeyWh0NOzoPawVxO6lDLAVajU=.2f8ba88a-033d-404c-ac82-94835d8aaf2b@github.com>

On Thu, 15 Jul 2021 23:43:38 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Sorry, I sent the wrong godbolt link: https://godbolt.org/z/1665fWzff
>
> @JornVernee I have small correct to your comment. We use simple inheritance for Thread subclasses. Their instances have **one** vtbl pointer at the same offset as in base class. But this pointer will point to separate vtable for each subclass (and base class). The layout (sequence) of methods pointers in vtable is the same in base class and subclasses. But subclass specific methods pointers will be different.
> 
> The only issue is that you have to make sure to cast passed object pointer to correct subclass (or base class). Otherwise you will get incorrect vtable and incorrect virtual methods pointers.
> 
> R15 is used by our JIT compiled code and Interpreter code which are executed only in JavaThread so the pinter it contains is JavaThread*

Thanks Vladimir. This also matches what I was seeing in compiler explorer, but I wasn't sure if we could assume it always worked like that with every C++ compiler.

It sound like R15 is expected to hold a `JavaThread*` though, so making the return type of `on_entry` be `JavaThread*` as David suggested seems correct.

Thanks

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

PR: https://git.openjdk.java.net/jdk17/pull/149

From jvernee at openjdk.java.net  Fri Jul 16 14:38:35 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Fri, 16 Jul 2021 14:38:35 GMT
Subject: [jdk17] RFR: 8269240:
 java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC
 [v4]
In-Reply-To: <PqFCdTWCSge_X14Rc5aNAo2pr5uliZ9jT0iYltvef3g=.7467c1a4-ad15-48a3-a495-75b655acf69c@github.com>
References: <PqFCdTWCSge_X14Rc5aNAo2pr5uliZ9jT0iYltvef3g=.7467c1a4-ad15-48a3-a495-75b655acf69c@github.com>
Message-ID: <sZ-6K79A6wl2BweSBsqsFjfoYQmNNRJf2fzV63rOpmE=.95db31cd-ae7c-40d4-a199-90ea2dc61eaf@github.com>

> This patch rewrites the prologue and epilogue of panama upcalls, in order to fix the test failure from the title.
> 
> Previously, we did a call to potentially attach the current thread to the VM, and then afterwards did the same suspend and stack reguard checks that we do on the back-edge of a native downcall. Then, on the back edge of the upcall we did another conditional call to detach the thread.
> 
> The suspend and reguard checks on the front-edge are incorrect, so I've changed the 2 calls to mimic what is done by JavaCallWrapper instead (with attach and detach included), and removed the old suspend and stack reguard checks.
> 
> FWIW, this removes the JavaFrameAnchor save/restore MacroAssembler code. This is now written in C++. Also, MacroAssembler code was added to save/restore the result of the upcall around the call on the back-edge, which was previously missing. Since the new code allocates a handle block as well, I've added handling for those oops to frame & OptimizedUpcallBlob.
> 
> Testing: local running of `jdk_foreign` on Windows and Linux (WSL). Tier 1-3

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

  Address more review comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/149/files
  - new: https://git.openjdk.java.net/jdk17/pull/149/files/128f48db..60bc5564

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

  Stats: 17 lines in 3 files changed: 7 ins; 0 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/149.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/149/head:pull/149

PR: https://git.openjdk.java.net/jdk17/pull/149

From jvernee at openjdk.java.net  Fri Jul 16 14:38:37 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Fri, 16 Jul 2021 14:38:37 GMT
Subject: [jdk17] RFR: 8269240:
 java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC
 [v3]
In-Reply-To: <cavIUnm5LQtMXdPpG2WUo3pYBB2rs7MVe-l_T5tHnWo=.2215f2d8-f8ef-4f59-b0a0-61aed83af110@github.com>
References: <PqFCdTWCSge_X14Rc5aNAo2pr5uliZ9jT0iYltvef3g=.7467c1a4-ad15-48a3-a495-75b655acf69c@github.com>
 <cavIUnm5LQtMXdPpG2WUo3pYBB2rs7MVe-l_T5tHnWo=.2215f2d8-f8ef-4f59-b0a0-61aed83af110@github.com>
Message-ID: <lNrc6ixlZvbTZR30xVAURpwAzV-ewfjOlFKy69ps2cQ=.51965554-d3db-42be-bba1-72cd256ca616@github.com>

On Thu, 15 Jul 2021 15:54:50 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> This patch rewrites the prologue and epilogue of panama upcalls, in order to fix the test failure from the title.
>> 
>> Previously, we did a call to potentially attach the current thread to the VM, and then afterwards did the same suspend and stack reguard checks that we do on the back-edge of a native downcall. Then, on the back edge of the upcall we did another conditional call to detach the thread.
>> 
>> The suspend and reguard checks on the front-edge are incorrect, so I've changed the 2 calls to mimic what is done by JavaCallWrapper instead (with attach and detach included), and removed the old suspend and stack reguard checks.
>> 
>> FWIW, this removes the JavaFrameAnchor save/restore MacroAssembler code. This is now written in C++. Also, MacroAssembler code was added to save/restore the result of the upcall around the call on the back-edge, which was previously missing. Since the new code allocates a handle block as well, I've added handling for those oops to frame & OptimizedUpcallBlob.
>> 
>> Testing: local running of `jdk_foreign` on Windows and Linux (WSL). Tier 1-3
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address David's review comments

I've addressed the new review comments, changing some `Thread*` to `JavaThread*`, removing now redundant casts, and finally noticed that the `Thread*` being passed to `ProgrammableUpcallHandle::detach_thread` was not being used, and it was always detaching the current thread instead. This in itself is fine, but then there's no need for the parameter, so I've dropped that.

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

PR: https://git.openjdk.java.net/jdk17/pull/149

From github.com+70726043+rgiulietti at openjdk.java.net  Fri Jul 16 15:15:00 2021
From: github.com+70726043+rgiulietti at openjdk.java.net (Raffaello Giulietti)
Date: Fri, 16 Jul 2021 15:15:00 GMT
Subject: RFR: 4511638: Double.toString(double) sometimes produces
 incorrect results [v2]
In-Reply-To: <Nd6utSzkKOGc1ynbZ30UxckmgacySChXLBRT7DGlkA4=.5d00bb70-1150-42bf-8c64-145404c3aa89@github.com>
References: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com>
 <Nd6utSzkKOGc1ynbZ30UxckmgacySChXLBRT7DGlkA4=.5d00bb70-1150-42bf-8c64-145404c3aa89@github.com>
Message-ID: <6hXBSzZI5a7uNYiriq90g69BQ8jAyYZbmSrq1PFiod4=.d7be4948-1c3c-47da-84e5-1d80a4810768@github.com>

On Fri, 16 Apr 2021 11:30:32 GMT, Raffaello Giulietti <github.com+70726043+rgiulietti at openjdk.org> wrote:

>> Hello,
>> 
>> here's a PR for a patch submitted on March 2020 [1](https://cr.openjdk.java.net/~bpb/4511638/webrev.04/) when Mercurial was a thing.
>> 
>> The patch has been edited to adhere to OpenJDK code conventions about multi-line (block) comments. Nothing in the code proper has changed, except for the addition of redundant but clarifying parentheses in some expressions.
>> 
>> 
>> Greetings
>> Raffaello
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   4511638: Double.toString(double) sometimes produces incorrect results

This is just to keep [1] alive. No news.

[1] https://github.com/openjdk/jdk/pull/3402

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

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

From dholmes at openjdk.java.net  Sat Jul 17 00:37:59 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Sat, 17 Jul 2021 00:37:59 GMT
Subject: [jdk17] RFR: 8269240:
 java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC
 [v4]
In-Reply-To: <sZ-6K79A6wl2BweSBsqsFjfoYQmNNRJf2fzV63rOpmE=.95db31cd-ae7c-40d4-a199-90ea2dc61eaf@github.com>
References: <PqFCdTWCSge_X14Rc5aNAo2pr5uliZ9jT0iYltvef3g=.7467c1a4-ad15-48a3-a495-75b655acf69c@github.com>
 <sZ-6K79A6wl2BweSBsqsFjfoYQmNNRJf2fzV63rOpmE=.95db31cd-ae7c-40d4-a199-90ea2dc61eaf@github.com>
Message-ID: <u4O0lg5nYU9K0BfwcintajLEBtCZvujBSXvtCNNd4io=.197fa775-1174-4921-a8cb-d64f66f71bea@github.com>

On Fri, 16 Jul 2021 14:38:35 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> This patch rewrites the prologue and epilogue of panama upcalls, in order to fix the test failure from the title.
>> 
>> Previously, we did a call to potentially attach the current thread to the VM, and then afterwards did the same suspend and stack reguard checks that we do on the back-edge of a native downcall. Then, on the back edge of the upcall we did another conditional call to detach the thread.
>> 
>> The suspend and reguard checks on the front-edge are incorrect, so I've changed the 2 calls to mimic what is done by JavaCallWrapper instead (with attach and detach included), and removed the old suspend and stack reguard checks.
>> 
>> FWIW, this removes the JavaFrameAnchor save/restore MacroAssembler code. This is now written in C++. Also, MacroAssembler code was added to save/restore the result of the upcall around the call on the back-edge, which was previously missing. Since the new code allocates a handle block as well, I've added handling for those oops to frame & OptimizedUpcallBlob.
>> 
>> Testing: local running of `jdk_foreign` on Windows and Linux (WSL). Tier 1-3
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address more review comments

Updates look good.

Thanks,
David

src/hotspot/share/runtime/thread.hpp line 1427:

> 1425:   static inline JavaThread* current();
> 1426:   // Returns the current thread as a JavaThread, or NULL if not attached
> 1427:   static inline JavaThread* current_or_null();

I hadn't intended to suggest the introduction of this method, but I see now how my comment led to it. It is fine.

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/149

From github.com+1701815+mkarg at openjdk.java.net  Sat Jul 17 08:37:52 2021
From: github.com+1701815+mkarg at openjdk.java.net (Markus KARG)
Date: Sat, 17 Jul 2021 08:37:52 GMT
Subject: RFR: 8265891: (ch) InputStream returned by
 Channels.newInputStream should override transferTo [v3]
In-Reply-To: <xBg2xYkt8KnJCohvSQW13aIyNAEhQIG9PVzLUAV1lQM=.771005fb-080f-4828-acc4-1ebf63a42a21@github.com>
References: <XlU5gCBUEa4qTTz8yhMeElh95FuiPcFYQ_nj_WYvbLE=.6e9fc6a4-f3b1-4faf-91f0-d8b06f875780@github.com>
 <aS5i72i7KLnTndIFIA_94OUjEgyuwXiHDHu1H898QtE=.0fcdd01c-2219-4318-86d7-8826941b6f41@github.com>
 <xBg2xYkt8KnJCohvSQW13aIyNAEhQIG9PVzLUAV1lQM=.771005fb-080f-4828-acc4-1ebf63a42a21@github.com>
Message-ID: <p2EzAoH2D4K_NLO3V5PssMeZ1ZjPQ7LR7e20Iz6sdnQ=.24a97456-2286-4629-a90b-13ae4e956d71@github.com>

On Wed, 14 Jul 2021 18:35:15 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Have you looked into other tests which have implemented Providers?

I have not found any test code containing the word `new FileChannel() {...}` or `extends FileChannel`, so I apparently there exists no mock of `FileChannel`. Unfortunately, as long as it is mandatory to copy *all* the tests of `InputStream/TransferTo` this means that I *must* implement *all* methods of `FileChannel` (even if they are empty) just for the sake of throwing an exception after one, two, or three transferred bytes (which, BTW, is not part of the API but looks like just a personal decision of the original test author). It is not really helpful that OpenJDK *neither* uses mocking *nor* lets me reduce the number of tests to the *essential* minimum, as this means, I wrote approx. 100 LoC for the optimized implementations and now I have to write approx. 1000 LoC just to perform *exactly the same tests* (to be clear: I have no problem with testing `content()` which certainly *has* to be tested, but which does *not* imply writing a `FileChannel` mock).

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

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

From jbhateja at openjdk.java.net  Sun Jul 18 20:28:34 2021
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Sun, 18 Jul 2021 20:28:34 GMT
Subject: RFR: 8266054: VectorAPI rotate operation optimization [v11]
In-Reply-To: <OZ2u4DDNaYF3WiR5uU6NWvzPMKV3j8QAO_mZyLP3Isg=.594e3514-8a5a-442c-ac1a-ca6c6d14e963@github.com>
References: <OZ2u4DDNaYF3WiR5uU6NWvzPMKV3j8QAO_mZyLP3Isg=.594e3514-8a5a-442c-ac1a-ca6c6d14e963@github.com>
Message-ID: <yzn9HnY80ghFCpAds8gr4uJKHRPXBrDkvtDlBAO8Tc4=.247e9fc2-05af-4f50-9811-6cde35da472a@github.com>

> Current VectorAPI Java side implementation expresses rotateLeft and rotateRight operation using following operations:-
> 
>     vec1 = lanewise(VectorOperators.LSHL, n)
>     vec2 = lanewise(VectorOperators.LSHR, n)
>     res = lanewise(VectorOperations.OR, vec1 , vec2)
> 
> This patch moves above handling from Java side to C2 compiler which facilitates dismantling the rotate operation if target ISA does not support a direct rotate instruction.
> 
> AVX512 added vector rotate instructions vpro[rl][v][dq] which operate over long and integer type vectors. For other cases (i.e. sub-word type vectors or for targets which do not support direct rotate operations )   instruction sequence comprising of vector SHIFT (LEFT/RIGHT) and vector OR is emitted.
> 
> Please find below the performance data for included JMH benchmark.
> Machine:  Cascade Lake Server (Intel(R) Xeon(R) Platinum 8280 CPU @ 2.70GHz)
> 
> 
> Benchmark | (TESTSIZE) | Shift | Baseline AVX3 (ops/ms) | Withopt? AVX3 (ops/ms) | Gain % | Baseline AVX2 (ops/ms) | Withopt AVX2 (ops/ms) | Gain %
> -- | -- | -- | -- | -- | -- | -- | -- | --
> ? | ? | ? | ? | ? | ? | ? | ? | ?
> RotateBenchmark.testRotateLeftB | 128.00 | 7.00 | 17223.35 | 17094.69 | -0.75 | 17008.32 | 17488.06 | 2.82
> RotateBenchmark.testRotateLeftB | 128.00 | 7.00 | 8944.98 | 8811.34 | -1.49 | 8878.17 | 9218.68 | 3.84
> RotateBenchmark.testRotateLeftB | 128.00 | 15.00 | 17195.75 | 17137.32 | -0.34 | 16789.01 | 17780.34 | 5.90
> RotateBenchmark.testRotateLeftB | 128.00 | 15.00 | 9052.67 | 8838.60 | -2.36 | 8814.62 | 9206.01 | 4.44
> RotateBenchmark.testRotateLeftB | 128.00 | 31.00 | 17100.19 | 16950.64 | -0.87 | 16827.73 | 17720.37 | 5.30
> RotateBenchmark.testRotateLeftB | 128.00 | 31.00 | 9079.95 | 8471.26 | -6.70 | 8888.44 | 9167.68 | 3.14
> RotateBenchmark.testRotateLeftB | 256.00 | 7.00 | 21231.33 | 21513.08 | 1.33 | 21824.51 | 21479.48 | -1.58
> RotateBenchmark.testRotateLeftB | 256.00 | 7.00 | 11103.62 | 11180.16 | 0.69 | 11173.67 | 11529.22 | 3.18
> RotateBenchmark.testRotateLeftB | 256.00 | 15.00 | 21119.14 | 21552.04 | 2.05 | 21693.05 | 21915.37 | 1.02
> RotateBenchmark.testRotateLeftB | 256.00 | 15.00 | 11048.68 | 11094.20 | 0.41 | 11049.90 | 11439.07 | 3.52
> RotateBenchmark.testRotateLeftB | 256.00 | 31.00 | 21506.31 | 21391.41 | -0.53 | 21263.18 | 21986.29 | 3.40
> RotateBenchmark.testRotateLeftB | 256.00 | 31.00 | 11056.12 | 11232.78 | 1.60 | 10941.59 | 11397.09 | 4.16
> RotateBenchmark.testRotateLeftB | 512.00 | 7.00 | 17976.56 | 18180.85 | 1.14 | 1212.26 | 2533.34 | 108.98
> RotateBenchmark.testRotateLeftB | 512.00 | 15.00 | 17553.70 | 18219.07 | 3.79 | 1256.73 | 2537.41 | 101.91
> RotateBenchmark.testRotateLeftB | 512.00 | 31.00 | 17618.03 | 17738.15 | 0.68 | 1214.69 | 2533.83 | 108.60
> RotateBenchmark.testRotateLeftI | 128.00 | 7.00 | 7258.87 | 7468.88 | 2.89 | 7115.12 | 7117.26 | 0.03
> RotateBenchmark.testRotateLeftI | 128.00 | 7.00 | 3586.65 | 3950.85 | 10.15 | 3532.17 | 3595.80 | 1.80
> RotateBenchmark.testRotateLeftI | 128.00 | 7.00 | 1835.07 | 1999.68 | 8.97 | 1789.90 | 1819.93 | 1.68
> RotateBenchmark.testRotateLeftI | 128.00 | 15.00 | 7273.36 | 7410.91 | 1.89 | 7198.60 | 6994.79 | -2.83
> RotateBenchmark.testRotateLeftI | 128.00 | 15.00 | 3674.98 | 3926.27 | 6.84 | 3549.90 | 3755.09 | 5.78
> RotateBenchmark.testRotateLeftI | 128.00 | 15.00 | 1840.94 | 1882.25 | 2.24 | 1801.56 | 1872.89 | 3.96
> RotateBenchmark.testRotateLeftI | 128.00 | 31.00 | 7457.11 | 7361.48 | -1.28 | 6975.33 | 7385.94 | 5.89
> RotateBenchmark.testRotateLeftI | 128.00 | 31.00 | 3570.74 | 3929.30 | 10.04 | 3635.37 | 3736.67 | 2.79
> RotateBenchmark.testRotateLeftI | 128.00 | 31.00 | 1902.32 | 1960.46 | 3.06 | 1812.32 | 1813.88 | 0.09
> RotateBenchmark.testRotateLeftI | 256.00 | 7.00 | 11174.24 | 12044.52 | 7.79 | 11509.87 | 11273.44 | -2.05
> RotateBenchmark.testRotateLeftI | 256.00 | 7.00 | 5981.47 | 6073.70 | 1.54 | 5593.66 | 5661.93 | 1.22
> RotateBenchmark.testRotateLeftI | 256.00 | 7.00 | 2932.49 | 3069.54 | 4.67 | 2950.86 | 2892.42 | -1.98
> RotateBenchmark.testRotateLeftI | 256.00 | 15.00 | 11764.11 | 12098.63 | 2.84 | 11069.52 | 11476.93 | 3.68
> RotateBenchmark.testRotateLeftI | 256.00 | 15.00 | 5855.20 | 6080.40 | 3.85 | 5919.11 | 5607.04 | -5.27
> RotateBenchmark.testRotateLeftI | 256.00 | 15.00 | 2989.05 | 3048.56 | 1.99 | 2902.63 | 2821.83 | -2.78
> RotateBenchmark.testRotateLeftI | 256.00 | 31.00 | 11652.84 | 11965.40 | 2.68 | 11525.62 | 11459.83 | -0.57
> RotateBenchmark.testRotateLeftI | 256.00 | 31.00 | 5851.82 | 6164.94 | 5.35 | 5882.60 | 5842.30 | -0.69
> RotateBenchmark.testRotateLeftI | 256.00 | 31.00 | 3015.99 | 3043.79 | 0.92 | 2963.71 | 2947.97 | -0.53
> RotateBenchmark.testRotateLeftI | 512.00 | 7.00 | 16029.15 | 16189.79 | 1.00 | 860.43 | 2339.32 | 171.88
> RotateBenchmark.testRotateLeftI | 512.00 | 7.00 | 8078.25 | 8081.84 | 0.04 | 427.39 | 1147.92 | 168.59
> RotateBenchmark.testRotateLeftI | 512.00 | 7.00 | 4021.49 | 4294.03 | 6.78 | 209.25 | 582.28 | 178.27
> RotateBenchmark.testRotateLeftI | 512.00 | 15.00 | 15912.98 | 16329.03 | 2.61 | 848.23 | 2296.78 | 170.77
> RotateBenchmark.testRotateLeftI | 512.00 | 15.00 | 8054.10 | 8306.37 | 3.13 | 429.93 | 1146.90 | 166.77
> RotateBenchmark.testRotateLeftI | 512.00 | 15.00 | 4102.58 | 4071.08 | -0.77 | 217.86 | 582.20 | 167.24
> RotateBenchmark.testRotateLeftI | 512.00 | 31.00 | 16177.79 | 16287.85 | 0.68 | 857.84 | 2243.15 | 161.49
> RotateBenchmark.testRotateLeftI | 512.00 | 31.00 | 8187.47 | 8410.48 | 2.72 | 434.60 | 1128.20 | 159.60
> RotateBenchmark.testRotateLeftI | 512.00 | 31.00 | 4109.15 | 4233.80 | 3.03 | 208.71 | 572.43 | 174.27
> RotateBenchmark.testRotateLeftL | 128.00 | 7.00 | 3755.09 | 3930.29 | 4.67 | 3604.19 | 3598.47 | -0.16
> RotateBenchmark.testRotateLeftL | 128.00 | 7.00 | 1829.03 | 1957.39 | 7.02 | 1833.95 | 1808.38 | -1.39
> RotateBenchmark.testRotateLeftL | 128.00 | 7.00 | 915.35 | 970.55 | 6.03 | 916.25 | 899.08 | -1.87
> RotateBenchmark.testRotateLeftL | 128.00 | 15.00 | 3664.85 | 3812.26 | 4.02 | 3629.37 | 3579.23 | -1.38
> RotateBenchmark.testRotateLeftL | 128.00 | 15.00 | 1829.51 | 1877.76 | 2.64 | 1781.05 | 1807.57 | 1.49
> RotateBenchmark.testRotateLeftL | 128.00 | 15.00 | 913.37 | 953.42 | 4.38 | 912.26 | 908.73 | -0.39
> RotateBenchmark.testRotateLeftL | 128.00 | 31.00 | 3648.45 | 3899.20 | 6.87 | 3552.67 | 3581.04 | 0.80
> RotateBenchmark.testRotateLeftL | 128.00 | 31.00 | 1816.50 | 1959.68 | 7.88 | 1820.88 | 1819.71 | -0.06
> RotateBenchmark.testRotateLeftL | 128.00 | 31.00 | 901.05 | 955.13 | 6.00 | 913.74 | 907.90 | -0.64
> RotateBenchmark.testRotateLeftL | 256.00 | 7.00 | 5850.99 | 6108.64 | 4.40 | 5882.65 | 5755.21 | -2.17
> RotateBenchmark.testRotateLeftL | 256.00 | 7.00 | 2962.21 | 3060.47 | 3.32 | 2955.20 | 2909.18 | -1.56
> RotateBenchmark.testRotateLeftL | 256.00 | 7.00 | 1480.46 | 1534.72 | 3.66 | 1467.78 | 1430.60 | -2.53
> RotateBenchmark.testRotateLeftL | 256.00 | 15.00 | 5858.23 | 6047.51 | 3.23 | 5770.02 | 5773.19 | 0.05
> RotateBenchmark.testRotateLeftL | 256.00 | 15.00 | 2951.49 | 3096.53 | 4.91 | 2885.21 | 2899.31 | 0.49
> RotateBenchmark.testRotateLeftL | 256.00 | 15.00 | 1486.26 | 1527.94 | 2.80 | 1441.93 | 1454.25 | 0.85
> RotateBenchmark.testRotateLeftL | 256.00 | 31.00 | 5873.21 | 6089.75 | 3.69 | 5767.58 | 5664.11 | -1.79
> RotateBenchmark.testRotateLeftL | 256.00 | 31.00 | 2969.67 | 3081.39 | 3.76 | 2878.50 | 2905.86 | 0.95
> RotateBenchmark.testRotateLeftL | 256.00 | 31.00 | 1452.21 | 1520.03 | 4.67 | 1430.30 | 1485.63 | 3.87
> RotateBenchmark.testRotateLeftL | 512.00 | 7.00 | 8088.65 | 8443.63 | 4.39 | 455.67 | 1226.33 | 169.13
> RotateBenchmark.testRotateLeftL | 512.00 | 7.00 | 4011.95 | 4120.25 | 2.70 | 229.77 | 619.87 | 169.77
> RotateBenchmark.testRotateLeftL | 512.00 | 7.00 | 2090.57 | 2109.53 | 0.91 | 115.21 | 310.36 | 169.37
> RotateBenchmark.testRotateLeftL | 512.00 | 15.00 | 8166.84 | 8557.28 | 4.78 | 457.67 | 1242.86 | 171.56
> RotateBenchmark.testRotateLeftL | 512.00 | 15.00 | 4137.02 | 4287.95 | 3.65 | 227.26 | 624.80 | 174.93
> RotateBenchmark.testRotateLeftL | 512.00 | 15.00 | 2095.01 | 2102.86 | 0.37 | 114.26 | 310.83 | 172.03
> RotateBenchmark.testRotateLeftL | 512.00 | 31.00 | 8082.68 | 8400.56 | 3.93 | 459.59 | 1230.07 | 167.64
> RotateBenchmark.testRotateLeftL | 512.00 | 31.00 | 4047.67 | 4147.58 | 2.47 | 229.01 | 606.38 | 164.78
> RotateBenchmark.testRotateLeftL | 512.00 | 31.00 | 2086.83 | 2126.72 | 1.91 | 111.93 | 305.66 | 173.08
> RotateBenchmark.testRotateLeftS | 128.00 | 7.00 | 13597.19 | 13255.09 | -2.52 | 13818.39 | 13242.40 | -4.17
> RotateBenchmark.testRotateLeftS | 128.00 | 7.00 | 7028.26 | 6826.59 | -2.87 | 6765.15 | 6907.87 | 2.11
> RotateBenchmark.testRotateLeftS | 128.00 | 7.00 | 3570.40 | 3468.01 | -2.87 | 3449.66 | 3533.50 | 2.43
> RotateBenchmark.testRotateLeftS | 128.00 | 15.00 | 13615.99 | 13464.40 | -1.11 | 13330.02 | 13870.57 | 4.06
> RotateBenchmark.testRotateLeftS | 128.00 | 15.00 | 7043.31 | 6763.34 | -3.97 | 6928.88 | 7063.57 | 1.94
> RotateBenchmark.testRotateLeftS | 128.00 | 15.00 | 3495.12 | 3537.62 | 1.22 | 3503.41 | 3457.67 | -1.31
> RotateBenchmark.testRotateLeftS | 128.00 | 31.00 | 13591.66 | 13665.84 | 0.55 | 13773.27 | 13126.08 | -4.70
> RotateBenchmark.testRotateLeftS | 128.00 | 31.00 | 7027.08 | 7011.24 | -0.23 | 6974.98 | 6815.50 | -2.29
> RotateBenchmark.testRotateLeftS | 128.00 | 31.00 | 3568.28 | 3569.62 | 0.04 | 3580.67 | 3463.58 | -3.27
> RotateBenchmark.testRotateLeftS | 256.00 | 7.00 | 21154.03 | 21416.32 | 1.24 | 21187.01 | 21401.61 | 1.01
> RotateBenchmark.testRotateLeftS | 256.00 | 7.00 | 11194.24 | 10865.47 | -2.94 | 11063.19 | 10977.60 | -0.77
> RotateBenchmark.testRotateLeftS | 256.00 | 7.00 | 5797.80 | 5523.94 | -4.72 | 5654.63 | 5468.78 | -3.29
> RotateBenchmark.testRotateLeftS | 256.00 | 15.00 | 21333.89 | 21412.74 | 0.37 | 21610.94 | 20908.96 | -3.25
> RotateBenchmark.testRotateLeftS | 256.00 | 15.00 | 11327.07 | 11113.48 | -1.89 | 11148.25 | 10678.14 | -4.22
> RotateBenchmark.testRotateLeftS | 256.00 | 15.00 | 5810.69 | 5569.72 | -4.15 | 5663.26 | 5618.87 | -0.78
> RotateBenchmark.testRotateLeftS | 256.00 | 31.00 | 21753.20 | 21198.43 | -2.55 | 21567.90 | 21929.81 | 1.68
> RotateBenchmark.testRotateLeftS | 256.00 | 31.00 | 11517.08 | 11039.64 | -4.15 | 11103.08 | 10871.59 | -2.08
> RotateBenchmark.testRotateLeftS | 256.00 | 31.00 | 5897.16 | 5606.75 | -4.92 | 5459.87 | 5604.12 | 2.64
> RotateBenchmark.testRotateLeftS | 512.00 | 7.00 | 29748.53 | 28883.73 | -2.91 | 1549.02 | 3928.53 | 153.61
> RotateBenchmark.testRotateLeftS | 512.00 | 7.00 | 15197.09 | 15878.19 | 4.48 | 772.59 | 1924.35 | 149.08
> RotateBenchmark.testRotateLeftS | 512.00 | 7.00 | 8046.30 | 8081.19 | 0.43 | 388.11 | 990.28 | 155.16
> RotateBenchmark.testRotateLeftS | 512.00 | 15.00 | 30618.04 | 29419.19 | -3.92 | 1524.22 | 3915.97 | 156.92
> RotateBenchmark.testRotateLeftS | 512.00 | 15.00 | 15854.43 | 15846.37 | -0.05 | 766.09 | 1953.60 | 155.01
> RotateBenchmark.testRotateLeftS | 512.00 | 15.00 | 7814.77 | 7899.30 | 1.08 | 390.82 | 970.37 | 148.29
> RotateBenchmark.testRotateLeftS | 512.00 | 31.00 | 29596.82 | 28538.69 | -3.58 | 1530.45 | 3906.91 | 155.28
> RotateBenchmark.testRotateLeftS | 512.00 | 31.00 | 15662.48 | 15849.25 | 1.19 | 778.08 | 1934.31 | 148.60
> RotateBenchmark.testRotateLeftS | 512.00 | 31.00 | 8121.14 | 7758.59 | -4.46 | 392.78 | 959.73 | 144.34
> RotateBenchmark.testRotateRightB | 128.00 | 7.00 | 17465.84 | 17069.34 | -2.27 | 16849.73 | 17842.08 | 5.89
> RotateBenchmark.testRotateRightB | 128.00 | 7.00 | 9049.19 | 8864.15 | -2.04 | 8786.67 | 9105.34 | 3.63
> RotateBenchmark.testRotateRightB | 128.00 | 15.00 | 17703.38 | 17070.98 | -3.57 | 16595.85 | 17784.68 | 7.16
> RotateBenchmark.testRotateRightB | 128.00 | 15.00 | 9007.68 | 8817.41 | -2.11 | 8704.49 | 9185.87 | 5.53
> RotateBenchmark.testRotateRightB | 128.00 | 31.00 | 17531.05 | 16983.40 | -3.12 | 16947.69 | 17655.40 | 4.18
> RotateBenchmark.testRotateRightB | 128.00 | 31.00 | 8986.30 | 8794.15 | -2.14 | 8816.62 | 9225.95 | 4.64
> RotateBenchmark.testRotateRightB | 256.00 | 7.00 | 21293.95 | 21506.74 | 1.00 | 21163.29 | 21854.03 | 3.26
> RotateBenchmark.testRotateRightB | 256.00 | 7.00 | 11258.47 | 11072.92 | -1.65 | 11118.12 | 11338.96 | 1.99
> RotateBenchmark.testRotateRightB | 256.00 | 15.00 | 21253.36 | 21292.37 | 0.18 | 21224.39 | 21763.88 | 2.54
> RotateBenchmark.testRotateRightB | 256.00 | 15.00 | 11064.80 | 11198.35 | 1.21 | 10960.98 | 11294.14 | 3.04
> RotateBenchmark.testRotateRightB | 256.00 | 31.00 | 21358.14 | 21346.21 | -0.06 | 21487.25 | 21854.42 | 1.71
> RotateBenchmark.testRotateRightB | 256.00 | 31.00 | 11045.61 | 11208.26 | 1.47 | 10907.03 | 11415.18 | 4.66
> RotateBenchmark.testRotateRightB | 512.00 | 7.00 | 17898.61 | 18307.54 | 2.28 | 1214.65 | 2546.64 | 109.66
> RotateBenchmark.testRotateRightB | 512.00 | 15.00 | 17909.25 | 18242.51 | 1.86 | 1215.05 | 2563.98 | 111.02
> RotateBenchmark.testRotateRightB | 512.00 | 31.00 | 17883.35 | 17928.44 | 0.25 | 1220.77 | 2543.30 | 108.34
> RotateBenchmark.testRotateRightI | 128.00 | 7.00 | 7139.97 | 7626.72 | 6.82 | 6994.86 | 7075.65 | 1.15
> RotateBenchmark.testRotateRightI | 128.00 | 7.00 | 3657.37 | 3898.34 | 6.59 | 3617.06 | 3576.12 | -1.13
> RotateBenchmark.testRotateRightI | 128.00 | 7.00 | 1804.26 | 1969.19 | 9.14 | 1796.62 | 1858.84 | 3.46
> RotateBenchmark.testRotateRightI | 128.00 | 15.00 | 7404.31 | 7760.09 | 4.80 | 7036.77 | 7401.52 | 5.18
> RotateBenchmark.testRotateRightI | 128.00 | 15.00 | 3600.52 | 3956.35 | 9.88 | 3595.28 | 3560.36 | -0.97
> RotateBenchmark.testRotateRightI | 128.00 | 15.00 | 1813.32 | 1966.41 | 8.44 | 1839.95 | 1852.53 | 0.68
> RotateBenchmark.testRotateRightI | 128.00 | 31.00 | 7118.48 | 7724.81 | 8.52 | 7151.56 | 7021.09 | -1.82
> RotateBenchmark.testRotateRightI | 128.00 | 31.00 | 3529.70 | 3881.63 | 9.97 | 3623.08 | 3601.01 | -0.61
> RotateBenchmark.testRotateRightI | 128.00 | 31.00 | 1823.61 | 1961.34 | 7.55 | 1786.86 | 1748.85 | -2.13
> RotateBenchmark.testRotateRightI | 256.00 | 7.00 | 11697.98 | 11835.25 | 1.17 | 11513.16 | 11184.87 | -2.85
> RotateBenchmark.testRotateRightI | 256.00 | 7.00 | 5890.11 | 6102.57 | 3.61 | 5658.79 | 5696.08 | 0.66
> RotateBenchmark.testRotateRightI | 256.00 | 7.00 | 2964.94 | 3070.26 | 3.55 | 2945.00 | 2962.08 | 0.58
> RotateBenchmark.testRotateRightI | 256.00 | 15.00 | 11562.51 | 12151.29 | 5.09 | 11404.17 | 11120.28 | -2.49
> RotateBenchmark.testRotateRightI | 256.00 | 15.00 | 5702.93 | 6130.57 | 7.50 | 5799.54 | 5779.08 | -0.35
> RotateBenchmark.testRotateRightI | 256.00 | 15.00 | 2861.96 | 3051.44 | 6.62 | 2943.99 | 2860.65 | -2.83
> RotateBenchmark.testRotateRightI | 256.00 | 31.00 | 11203.13 | 11710.59 | 4.53 | 11363.18 | 11112.16 | -2.21
> RotateBenchmark.testRotateRightI | 256.00 | 31.00 | 5893.97 | 6070.71 | 3.00 | 5776.67 | 5648.84 | -2.21
> RotateBenchmark.testRotateRightI | 256.00 | 31.00 | 2971.83 | 3046.76 | 2.52 | 2903.35 | 2833.88 | -2.39
> RotateBenchmark.testRotateRightI | 512.00 | 7.00 | 16064.71 | 15851.35 | -1.33 | 861.93 | 2256.88 | 161.84
> RotateBenchmark.testRotateRightI | 512.00 | 7.00 | 7916.80 | 8462.65 | 6.89 | 430.23 | 1147.30 | 166.67
> RotateBenchmark.testRotateRightI | 512.00 | 7.00 | 4104.64 | 4068.28 | -0.89 | 216.30 | 572.86 | 164.84
> RotateBenchmark.testRotateRightI | 512.00 | 15.00 | 16133.09 | 16281.59 | 0.92 | 856.36 | 2229.58 | 160.35
> RotateBenchmark.testRotateRightI | 512.00 | 15.00 | 8127.26 | 8117.59 | -0.12 | 419.16 | 1176.42 | 180.66
> RotateBenchmark.testRotateRightI | 512.00 | 15.00 | 4080.11 | 4063.26 | -0.41 | 218.32 | 571.93 | 161.97
> RotateBenchmark.testRotateRightI | 512.00 | 31.00 | 15834.26 | 16314.64 | 3.03 | 865.96 | 2297.74 | 165.34
> RotateBenchmark.testRotateRightI | 512.00 | 31.00 | 7965.62 | 8270.48 | 3.83 | 428.55 | 1148.87 | 168.08
> RotateBenchmark.testRotateRightI | 512.00 | 31.00 | 4161.69 | 4034.76 | -3.05 | 215.63 | 570.19 | 164.43
> RotateBenchmark.testRotateRightL | 128.00 | 7.00 | 3556.70 | 3877.08 | 9.01 | 3596.46 | 3558.32 | -1.06
> RotateBenchmark.testRotateRightL | 128.00 | 7.00 | 1772.93 | 1993.86 | 12.46 | 1856.79 | 1783.22 | -3.96
> RotateBenchmark.testRotateRightL | 128.00 | 7.00 | 908.66 | 1000.37 | 10.09 | 944.79 | 922.91 | -2.32
> RotateBenchmark.testRotateRightL | 128.00 | 15.00 | 3742.44 | 3748.41 | 0.16 | 3788.07 | 3570.67 | -5.74
> RotateBenchmark.testRotateRightL | 128.00 | 15.00 | 1817.53 | 1985.69 | 9.25 | 1892.38 | 1833.16 | -3.13
> RotateBenchmark.testRotateRightL | 128.00 | 15.00 | 941.03 | 952.68 | 1.24 | 915.79 | 910.21 | -0.61
> RotateBenchmark.testRotateRightL | 128.00 | 31.00 | 3649.48 | 3896.56 | 6.77 | 3637.59 | 3557.53 | -2.20
> RotateBenchmark.testRotateRightL | 128.00 | 31.00 | 1840.12 | 1997.19 | 8.54 | 1821.47 | 1799.82 | -1.19
> RotateBenchmark.testRotateRightL | 128.00 | 31.00 | 901.33 | 995.67 | 10.47 | 909.20 | 902.73 | -0.71
> RotateBenchmark.testRotateRightL | 256.00 | 7.00 | 5789.93 | 5960.54 | 2.95 | 5758.14 | 5736.30 | -0.38
> RotateBenchmark.testRotateRightL | 256.00 | 7.00 | 2963.20 | 3063.30 | 3.38 | 2943.48 | 2833.84 | -3.72
> RotateBenchmark.testRotateRightL | 256.00 | 7.00 | 1501.81 | 1510.23 | 0.56 | 1463.85 | 1462.26 | -0.11
> RotateBenchmark.testRotateRightL | 256.00 | 15.00 | 5870.05 | 5951.43 | 1.39 | 5794.74 | 5604.58 | -3.28
> RotateBenchmark.testRotateRightL | 256.00 | 15.00 | 2971.36 | 3047.00 | 2.55 | 2931.19 | 2907.30 | -0.82
> RotateBenchmark.testRotateRightL | 256.00 | 15.00 | 1473.97 | 1530.54 | 3.84 | 1473.45 | 1442.40 | -2.11
> RotateBenchmark.testRotateRightL | 256.00 | 31.00 | 5858.08 | 6080.49 | 3.80 | 5863.69 | 5549.85 | -5.35
> RotateBenchmark.testRotateRightL | 256.00 | 31.00 | 2916.24 | 3045.77 | 4.44 | 2981.59 | 2815.07 | -5.58
> RotateBenchmark.testRotateRightL | 256.00 | 31.00 | 1441.20 | 1531.56 | 6.27 | 1492.47 | 1473.25 | -1.29
> RotateBenchmark.testRotateRightL | 512.00 | 7.00 | 8147.24 | 8310.05 | 2.00 | 469.45 | 1235.21 | 163.12
> RotateBenchmark.testRotateRightL | 512.00 | 7.00 | 4142.95 | 4258.86 | 2.80 | 234.14 | 615.52 | 162.88
> RotateBenchmark.testRotateRightL | 512.00 | 7.00 | 2095.48 | 2087.20 | -0.40 | 113.55 | 311.19 | 174.05
> RotateBenchmark.testRotateRightL | 512.00 | 15.00 | 8222.94 | 8246.58 | 0.29 | 458.91 | 1244.32 | 171.15
> RotateBenchmark.testRotateRightL | 512.00 | 15.00 | 4160.04 | 4226.46 | 1.60 | 227.78 | 625.38 | 174.56
> RotateBenchmark.testRotateRightL | 512.00 | 15.00 | 2064.63 | 2162.44 | 4.74 | 113.27 | 314.15 | 177.36
> RotateBenchmark.testRotateRightL | 512.00 | 31.00 | 8157.94 | 8466.90 | 3.79 | 450.26 | 1221.90 | 171.37
> RotateBenchmark.testRotateRightL | 512.00 | 31.00 | 4039.74 | 4283.33 | 6.03 | 224.82 | 612.68 | 172.53
> RotateBenchmark.testRotateRightL | 512.00 | 31.00 | 2066.88 | 2147.51 | 3.90 | 110.97 | 303.43 | 173.42
> RotateBenchmark.testRotateRightS | 128.00 | 7.00 | 13548.39 | 13245.87 | -2.23 | 13490.93 | 13084.76 | -3.01
> RotateBenchmark.testRotateRightS | 128.00 | 7.00 | 7020.16 | 6768.85 | -3.58 | 6991.39 | 7044.32 | 0.76
> RotateBenchmark.testRotateRightS | 128.00 | 7.00 | 3550.50 | 3505.19 | -1.28 | 3507.12 | 3612.86 | 3.01
> RotateBenchmark.testRotateRightS | 128.00 | 15.00 | 13743.43 | 13325.44 | -3.04 | 13696.15 | 13255.80 | -3.22
> RotateBenchmark.testRotateRightS | 128.00 | 15.00 | 6856.02 | 6969.18 | 1.65 | 6886.29 | 6834.12 | -0.76
> RotateBenchmark.testRotateRightS | 128.00 | 15.00 | 3569.53 | 3492.76 | -2.15 | 3539.02 | 3470.02 | -1.95
> RotateBenchmark.testRotateRightS | 128.00 | 31.00 | 13704.18 | 13495.07 | -1.53 | 13649.14 | 13583.87 | -0.48
> RotateBenchmark.testRotateRightS | 128.00 | 31.00 | 7011.77 | 6953.93 | -0.82 | 6978.28 | 6740.30 | -3.41
> RotateBenchmark.testRotateRightS | 128.00 | 31.00 | 3591.62 | 3620.12 | 0.79 | 3502.04 | 3510.05 | 0.23
> RotateBenchmark.testRotateRightS | 256.00 | 7.00 | 21950.71 | 22113.60 | 0.74 | 21484.27 | 21596.64 | 0.52
> RotateBenchmark.testRotateRightS | 256.00 | 7.00 | 11616.88 | 11099.73 | -4.45 | 11188.29 | 10737.68 | -4.03
> RotateBenchmark.testRotateRightS | 256.00 | 7.00 | 5872.72 | 5579.12 | -5.00 | 5784.05 | 5454.57 | -5.70
> RotateBenchmark.testRotateRightS | 256.00 | 15.00 | 22017.83 | 20817.97 | -5.45 | 21934.65 | 21356.90 | -2.63
> RotateBenchmark.testRotateRightS | 256.00 | 15.00 | 11414.27 | 11044.86 | -3.24 | 11454.35 | 11140.34 | -2.74
> RotateBenchmark.testRotateRightS | 256.00 | 15.00 | 5786.64 | 5634.05 | -2.64 | 5724.93 | 5639.99 | -1.48
> RotateBenchmark.testRotateRightS | 256.00 | 31.00 | 21754.77 | 21466.01 | -1.33 | 21140.67 | 21970.03 | 3.92
> RotateBenchmark.testRotateRightS | 256.00 | 31.00 | 11676.46 | 11358.64 | -2.72 | 11204.90 | 11213.48 | 0.08
> RotateBenchmark.testRotateRightS | 256.00 | 31.00 | 5728.20 | 5772.49 | 0.77 | 5594.33 | 5544.25 | -0.90
> RotateBenchmark.testRotateRightS | 512.00 | 7.00 | 30247.03 | 30179.41 | -0.22 | 1538.75 | 3975.82 | 158.38
> RotateBenchmark.testRotateRightS | 512.00 | 7.00 | 15988.73 | 15621.42 | -2.30 | 776.04 | 1910.91 | 146.24
> RotateBenchmark.testRotateRightS | 512.00 | 7.00 | 8115.84 | 8025.28 | -1.12 | 389.12 | 984.46 | 152.99
> RotateBenchmark.testRotateRightS | 512.00 | 15.00 | 30110.91 | 30200.69 | 0.30 | 1532.49 | 3983.77 | 159.95
> RotateBenchmark.testRotateRightS | 512.00 | 15.00 | 15957.90 | 15690.73 | -1.67 | 774.90 | 1931.00 | 149.19
> RotateBenchmark.testRotateRightS | 512.00 | 15.00 | 8113.26 | 8037.93 | -0.93 | 391.90 | 965.53 | 146.37
> RotateBenchmark.testRotateRightS | 512.00 | 31.00 | 29816.97 | 29891.54 | 0.25 | 1538.12 | 3881.93 | 152.38
> RotateBenchmark.testRotateRightS | 512.00 | 31.00 | 15405.95 | 15619.17 | 1.38 | 762.49 | 1871.00 | 145.38
> RotateBenchmark.testRotateRightS | 512.00 | 31.00 | 7919.80 | 7957.35 | 0.47 | 393.63 | 972.49 | 147.06

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

  8266054: Review comments resolution.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3720/files
  - new: https://git.openjdk.java.net/jdk/pull/3720/files/609c4143..d26caa6a

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

  Stats: 165 lines in 10 files changed: 68 ins; 23 del; 74 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3720.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3720/head:pull/3720

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

From jbhateja at openjdk.java.net  Sun Jul 18 20:28:47 2021
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Sun, 18 Jul 2021 20:28:47 GMT
Subject: RFR: 8266054: VectorAPI rotate operation optimization [v10]
In-Reply-To: <mF_TPuiSWMhsH4OoVgvPDJ2VcSP8MGhj1mL7ACIyoQg=.e9e159d5-90ec-470a-84b9-167c36ce6c7f@github.com>
References: <OZ2u4DDNaYF3WiR5uU6NWvzPMKV3j8QAO_mZyLP3Isg=.594e3514-8a5a-442c-ac1a-ca6c6d14e963@github.com>
 <j-MimQL3RfOga-_XaS0UWHPsmDp99CyUer8f_bFptmo=.231d4cc0-e9ee-47d8-ad6c-41adcf114367@github.com>
 <mF_TPuiSWMhsH4OoVgvPDJ2VcSP8MGhj1mL7ACIyoQg=.e9e159d5-90ec-470a-84b9-167c36ce6c7f@github.com>
Message-ID: <57RjIAXAeh_OL4TKIusvf_Zzcdy8sojU874yc1lH2yY=.3acc983b-9152-404c-a67a-d484fe41c15b@github.com>

On Fri, 16 Jul 2021 00:52:21 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
>> 
>>  - 8266054: Incorporating styling changes based on reviews.
>>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8266054
>>  - Merge http://github.com/openjdk/jdk into JDK-8266054
>>  - Merge http://github.com/openjdk/jdk into JDK-8266054
>>  - Merge http://github.com/openjdk/jdk into JDK-8266054
>>  - Merge branch 'JDK-8266054' of http://github.com/jatin-bhateja/jdk into JDK-8266054
>>  - 8266054: Removing redundant teat templates.
>>  - 8266054: Code reorganization for efficient sharing of logic to check rotate operation support on a target platform.
>>  - 8266054: Removing redundant test templates.
>>  - 8266054: Review comments resolution.
>>  - ... and 5 more: https://git.openjdk.java.net/jdk/compare/07e90524...609c4143
>
> src/hotspot/share/opto/vectorIntrinsics.cpp line 84:
> 
>> 82:         arch_supports_vector(Op_OrV, num_elem, elem_bt, VecMaskNotUsed)) {
>> 83:       is_supported = true;
>> 84:     }
> 
> When check_bcast is set, is_supported could be false when replicate is not supported. Is replicate not needed for shift+or sequence?

check_bcast is true only when shift value is a non-constant scalar value, in that case we need to check for broadcasting operation for shift, in all other cases broadcast is not needed.  Constant shift value is an optimizing case since AVX512 offers instructions which directly accept 8bit immediate shift value.

> src/hotspot/share/opto/vectorIntrinsics.cpp line 86:
> 
>> 84:     }
>> 85:     return is_supported;
>> 86: }
> 
> Please add comments here why the Left/Right shift and Or opcodes are being checked here. Also add comments why for left shift we are only checking for int and long left shift opcodes whereas for right shift sub word opcodes are being checked.

Both left and right shifts opcodes are selected for all integral types (byte/short/int/long). VectorNode::opcode returns the granular left shift type based on the sub-type i.e. elem_bt in case of  LeftShiftI.  Re-organizing the code for better readability.

> src/hotspot/share/opto/vectorIntrinsics.cpp line 338:
> 
>> 336:     // TODO When mask usage is supported, VecMaskNotUsed needs to be VecMaskUseLoad.
>> 337:     if ((sopc != 0) &&
>> 338:         !arch_supports_vector(sopc, num_elem, elem_bt, is_vector_mask(vbox_klass) ? VecMaskUseAll : VecMaskNotUsed)) {
> 
> Could we not call arch_supports_vector_rotate from arch_supports_vector?

DONE

> src/hotspot/share/opto/vectorIntrinsics.cpp line 1563:
> 
>> 1561:                          -0x80 <= cnt_type->get_con() && cnt_type->get_con() < 0x80;
>> 1562:   if (is_rotate) {
>> 1563:     if (!arch_supports_vector_rotate(sopc, num_elem, elem_bt, !is_const_rotate)) {
> 
> What is the relationship between check_bcast and !is_const_rotate? Some comments here on this would help.

Constant shift value is an optimizing case since AVX512 offers instructions which directly accept constant shifts in the range (-256, 255). Similar handling is done in SLP.
https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/superword.cpp#L2493

But I feel this is very X86 specific check in generic code, so moving decision to a new target specific matcher routine.

> src/hotspot/share/opto/vectorIntrinsics.cpp line 1590:
> 
>> 1588:       opd2 = gvn().transform(VectorNode::scalar2vector(cnt, num_elem, type_bt));
>> 1589:     } else {
>> 1590:       // constant shift.
> 
> Did you mean constant rotate here?

Yes.

> src/hotspot/share/opto/vectornode.cpp line 1180:
> 
>> 1178:       cnt = cnt->in(1);
>> 1179:     }
>> 1180:     shiftRCnt = cnt;
> 
> Why do we remove the And with mask here?

And'ing with shift_mask is already done on Java API side implementation before making a call to intrinsic rountine.

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

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

From jbhateja at openjdk.java.net  Sun Jul 18 20:36:46 2021
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Sun, 18 Jul 2021 20:36:46 GMT
Subject: RFR: 8266054: VectorAPI rotate operation optimization [v11]
In-Reply-To: <yzn9HnY80ghFCpAds8gr4uJKHRPXBrDkvtDlBAO8Tc4=.247e9fc2-05af-4f50-9811-6cde35da472a@github.com>
References: <OZ2u4DDNaYF3WiR5uU6NWvzPMKV3j8QAO_mZyLP3Isg=.594e3514-8a5a-442c-ac1a-ca6c6d14e963@github.com>
 <yzn9HnY80ghFCpAds8gr4uJKHRPXBrDkvtDlBAO8Tc4=.247e9fc2-05af-4f50-9811-6cde35da472a@github.com>
Message-ID: <snmvVvebV3YJWRJJfDh4RhFwfoZlnQ9AMWZsJfJ_IFE=.3ffdbc12-9fa4-4a62-91c7-ef4a3527b049@github.com>

On Sun, 18 Jul 2021 20:28:34 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Current VectorAPI Java side implementation expresses rotateLeft and rotateRight operation using following operations:-
>> 
>>     vec1 = lanewise(VectorOperators.LSHL, n)
>>     vec2 = lanewise(VectorOperators.LSHR, n)
>>     res = lanewise(VectorOperations.OR, vec1 , vec2)
>> 
>> This patch moves above handling from Java side to C2 compiler which facilitates dismantling the rotate operation if target ISA does not support a direct rotate instruction.
>> 
>> AVX512 added vector rotate instructions vpro[rl][v][dq] which operate over long and integer type vectors. For other cases (i.e. sub-word type vectors or for targets which do not support direct rotate operations )   instruction sequence comprising of vector SHIFT (LEFT/RIGHT) and vector OR is emitted.
>> 
>> Please find below the performance data for included JMH benchmark.
>> Machine:  Cascade Lake Server (Intel(R) Xeon(R) Platinum 8280 CPU @ 2.70GHz)
>> 
>> 
>> Benchmark | (TESTSIZE) | Shift | Baseline AVX3 (ops/ms) | Withopt? AVX3 (ops/ms) | Gain % | Baseline AVX2 (ops/ms) | Withopt AVX2 (ops/ms) | Gain %
>> -- | -- | -- | -- | -- | -- | -- | -- | --
>> ? | ? | ? | ? | ? | ? | ? | ? | ?
>> RotateBenchmark.testRotateLeftB | 128.00 | 7.00 | 17223.35 | 17094.69 | -0.75 | 17008.32 | 17488.06 | 2.82
>> RotateBenchmark.testRotateLeftB | 128.00 | 7.00 | 8944.98 | 8811.34 | -1.49 | 8878.17 | 9218.68 | 3.84
>> RotateBenchmark.testRotateLeftB | 128.00 | 15.00 | 17195.75 | 17137.32 | -0.34 | 16789.01 | 17780.34 | 5.90
>> RotateBenchmark.testRotateLeftB | 128.00 | 15.00 | 9052.67 | 8838.60 | -2.36 | 8814.62 | 9206.01 | 4.44
>> RotateBenchmark.testRotateLeftB | 128.00 | 31.00 | 17100.19 | 16950.64 | -0.87 | 16827.73 | 17720.37 | 5.30
>> RotateBenchmark.testRotateLeftB | 128.00 | 31.00 | 9079.95 | 8471.26 | -6.70 | 8888.44 | 9167.68 | 3.14
>> RotateBenchmark.testRotateLeftB | 256.00 | 7.00 | 21231.33 | 21513.08 | 1.33 | 21824.51 | 21479.48 | -1.58
>> RotateBenchmark.testRotateLeftB | 256.00 | 7.00 | 11103.62 | 11180.16 | 0.69 | 11173.67 | 11529.22 | 3.18
>> RotateBenchmark.testRotateLeftB | 256.00 | 15.00 | 21119.14 | 21552.04 | 2.05 | 21693.05 | 21915.37 | 1.02
>> RotateBenchmark.testRotateLeftB | 256.00 | 15.00 | 11048.68 | 11094.20 | 0.41 | 11049.90 | 11439.07 | 3.52
>> RotateBenchmark.testRotateLeftB | 256.00 | 31.00 | 21506.31 | 21391.41 | -0.53 | 21263.18 | 21986.29 | 3.40
>> RotateBenchmark.testRotateLeftB | 256.00 | 31.00 | 11056.12 | 11232.78 | 1.60 | 10941.59 | 11397.09 | 4.16
>> RotateBenchmark.testRotateLeftB | 512.00 | 7.00 | 17976.56 | 18180.85 | 1.14 | 1212.26 | 2533.34 | 108.98
>> RotateBenchmark.testRotateLeftB | 512.00 | 15.00 | 17553.70 | 18219.07 | 3.79 | 1256.73 | 2537.41 | 101.91
>> RotateBenchmark.testRotateLeftB | 512.00 | 31.00 | 17618.03 | 17738.15 | 0.68 | 1214.69 | 2533.83 | 108.60
>> RotateBenchmark.testRotateLeftI | 128.00 | 7.00 | 7258.87 | 7468.88 | 2.89 | 7115.12 | 7117.26 | 0.03
>> RotateBenchmark.testRotateLeftI | 128.00 | 7.00 | 3586.65 | 3950.85 | 10.15 | 3532.17 | 3595.80 | 1.80
>> RotateBenchmark.testRotateLeftI | 128.00 | 7.00 | 1835.07 | 1999.68 | 8.97 | 1789.90 | 1819.93 | 1.68
>> RotateBenchmark.testRotateLeftI | 128.00 | 15.00 | 7273.36 | 7410.91 | 1.89 | 7198.60 | 6994.79 | -2.83
>> RotateBenchmark.testRotateLeftI | 128.00 | 15.00 | 3674.98 | 3926.27 | 6.84 | 3549.90 | 3755.09 | 5.78
>> RotateBenchmark.testRotateLeftI | 128.00 | 15.00 | 1840.94 | 1882.25 | 2.24 | 1801.56 | 1872.89 | 3.96
>> RotateBenchmark.testRotateLeftI | 128.00 | 31.00 | 7457.11 | 7361.48 | -1.28 | 6975.33 | 7385.94 | 5.89
>> RotateBenchmark.testRotateLeftI | 128.00 | 31.00 | 3570.74 | 3929.30 | 10.04 | 3635.37 | 3736.67 | 2.79
>> RotateBenchmark.testRotateLeftI | 128.00 | 31.00 | 1902.32 | 1960.46 | 3.06 | 1812.32 | 1813.88 | 0.09
>> RotateBenchmark.testRotateLeftI | 256.00 | 7.00 | 11174.24 | 12044.52 | 7.79 | 11509.87 | 11273.44 | -2.05
>> RotateBenchmark.testRotateLeftI | 256.00 | 7.00 | 5981.47 | 6073.70 | 1.54 | 5593.66 | 5661.93 | 1.22
>> RotateBenchmark.testRotateLeftI | 256.00 | 7.00 | 2932.49 | 3069.54 | 4.67 | 2950.86 | 2892.42 | -1.98
>> RotateBenchmark.testRotateLeftI | 256.00 | 15.00 | 11764.11 | 12098.63 | 2.84 | 11069.52 | 11476.93 | 3.68
>> RotateBenchmark.testRotateLeftI | 256.00 | 15.00 | 5855.20 | 6080.40 | 3.85 | 5919.11 | 5607.04 | -5.27
>> RotateBenchmark.testRotateLeftI | 256.00 | 15.00 | 2989.05 | 3048.56 | 1.99 | 2902.63 | 2821.83 | -2.78
>> RotateBenchmark.testRotateLeftI | 256.00 | 31.00 | 11652.84 | 11965.40 | 2.68 | 11525.62 | 11459.83 | -0.57
>> RotateBenchmark.testRotateLeftI | 256.00 | 31.00 | 5851.82 | 6164.94 | 5.35 | 5882.60 | 5842.30 | -0.69
>> RotateBenchmark.testRotateLeftI | 256.00 | 31.00 | 3015.99 | 3043.79 | 0.92 | 2963.71 | 2947.97 | -0.53
>> RotateBenchmark.testRotateLeftI | 512.00 | 7.00 | 16029.15 | 16189.79 | 1.00 | 860.43 | 2339.32 | 171.88
>> RotateBenchmark.testRotateLeftI | 512.00 | 7.00 | 8078.25 | 8081.84 | 0.04 | 427.39 | 1147.92 | 168.59
>> RotateBenchmark.testRotateLeftI | 512.00 | 7.00 | 4021.49 | 4294.03 | 6.78 | 209.25 | 582.28 | 178.27
>> RotateBenchmark.testRotateLeftI | 512.00 | 15.00 | 15912.98 | 16329.03 | 2.61 | 848.23 | 2296.78 | 170.77
>> RotateBenchmark.testRotateLeftI | 512.00 | 15.00 | 8054.10 | 8306.37 | 3.13 | 429.93 | 1146.90 | 166.77
>> RotateBenchmark.testRotateLeftI | 512.00 | 15.00 | 4102.58 | 4071.08 | -0.77 | 217.86 | 582.20 | 167.24
>> RotateBenchmark.testRotateLeftI | 512.00 | 31.00 | 16177.79 | 16287.85 | 0.68 | 857.84 | 2243.15 | 161.49
>> RotateBenchmark.testRotateLeftI | 512.00 | 31.00 | 8187.47 | 8410.48 | 2.72 | 434.60 | 1128.20 | 159.60
>> RotateBenchmark.testRotateLeftI | 512.00 | 31.00 | 4109.15 | 4233.80 | 3.03 | 208.71 | 572.43 | 174.27
>> RotateBenchmark.testRotateLeftL | 128.00 | 7.00 | 3755.09 | 3930.29 | 4.67 | 3604.19 | 3598.47 | -0.16
>> RotateBenchmark.testRotateLeftL | 128.00 | 7.00 | 1829.03 | 1957.39 | 7.02 | 1833.95 | 1808.38 | -1.39
>> RotateBenchmark.testRotateLeftL | 128.00 | 7.00 | 915.35 | 970.55 | 6.03 | 916.25 | 899.08 | -1.87
>> RotateBenchmark.testRotateLeftL | 128.00 | 15.00 | 3664.85 | 3812.26 | 4.02 | 3629.37 | 3579.23 | -1.38
>> RotateBenchmark.testRotateLeftL | 128.00 | 15.00 | 1829.51 | 1877.76 | 2.64 | 1781.05 | 1807.57 | 1.49
>> RotateBenchmark.testRotateLeftL | 128.00 | 15.00 | 913.37 | 953.42 | 4.38 | 912.26 | 908.73 | -0.39
>> RotateBenchmark.testRotateLeftL | 128.00 | 31.00 | 3648.45 | 3899.20 | 6.87 | 3552.67 | 3581.04 | 0.80
>> RotateBenchmark.testRotateLeftL | 128.00 | 31.00 | 1816.50 | 1959.68 | 7.88 | 1820.88 | 1819.71 | -0.06
>> RotateBenchmark.testRotateLeftL | 128.00 | 31.00 | 901.05 | 955.13 | 6.00 | 913.74 | 907.90 | -0.64
>> RotateBenchmark.testRotateLeftL | 256.00 | 7.00 | 5850.99 | 6108.64 | 4.40 | 5882.65 | 5755.21 | -2.17
>> RotateBenchmark.testRotateLeftL | 256.00 | 7.00 | 2962.21 | 3060.47 | 3.32 | 2955.20 | 2909.18 | -1.56
>> RotateBenchmark.testRotateLeftL | 256.00 | 7.00 | 1480.46 | 1534.72 | 3.66 | 1467.78 | 1430.60 | -2.53
>> RotateBenchmark.testRotateLeftL | 256.00 | 15.00 | 5858.23 | 6047.51 | 3.23 | 5770.02 | 5773.19 | 0.05
>> RotateBenchmark.testRotateLeftL | 256.00 | 15.00 | 2951.49 | 3096.53 | 4.91 | 2885.21 | 2899.31 | 0.49
>> RotateBenchmark.testRotateLeftL | 256.00 | 15.00 | 1486.26 | 1527.94 | 2.80 | 1441.93 | 1454.25 | 0.85
>> RotateBenchmark.testRotateLeftL | 256.00 | 31.00 | 5873.21 | 6089.75 | 3.69 | 5767.58 | 5664.11 | -1.79
>> RotateBenchmark.testRotateLeftL | 256.00 | 31.00 | 2969.67 | 3081.39 | 3.76 | 2878.50 | 2905.86 | 0.95
>> RotateBenchmark.testRotateLeftL | 256.00 | 31.00 | 1452.21 | 1520.03 | 4.67 | 1430.30 | 1485.63 | 3.87
>> RotateBenchmark.testRotateLeftL | 512.00 | 7.00 | 8088.65 | 8443.63 | 4.39 | 455.67 | 1226.33 | 169.13
>> RotateBenchmark.testRotateLeftL | 512.00 | 7.00 | 4011.95 | 4120.25 | 2.70 | 229.77 | 619.87 | 169.77
>> RotateBenchmark.testRotateLeftL | 512.00 | 7.00 | 2090.57 | 2109.53 | 0.91 | 115.21 | 310.36 | 169.37
>> RotateBenchmark.testRotateLeftL | 512.00 | 15.00 | 8166.84 | 8557.28 | 4.78 | 457.67 | 1242.86 | 171.56
>> RotateBenchmark.testRotateLeftL | 512.00 | 15.00 | 4137.02 | 4287.95 | 3.65 | 227.26 | 624.80 | 174.93
>> RotateBenchmark.testRotateLeftL | 512.00 | 15.00 | 2095.01 | 2102.86 | 0.37 | 114.26 | 310.83 | 172.03
>> RotateBenchmark.testRotateLeftL | 512.00 | 31.00 | 8082.68 | 8400.56 | 3.93 | 459.59 | 1230.07 | 167.64
>> RotateBenchmark.testRotateLeftL | 512.00 | 31.00 | 4047.67 | 4147.58 | 2.47 | 229.01 | 606.38 | 164.78
>> RotateBenchmark.testRotateLeftL | 512.00 | 31.00 | 2086.83 | 2126.72 | 1.91 | 111.93 | 305.66 | 173.08
>> RotateBenchmark.testRotateLeftS | 128.00 | 7.00 | 13597.19 | 13255.09 | -2.52 | 13818.39 | 13242.40 | -4.17
>> RotateBenchmark.testRotateLeftS | 128.00 | 7.00 | 7028.26 | 6826.59 | -2.87 | 6765.15 | 6907.87 | 2.11
>> RotateBenchmark.testRotateLeftS | 128.00 | 7.00 | 3570.40 | 3468.01 | -2.87 | 3449.66 | 3533.50 | 2.43
>> RotateBenchmark.testRotateLeftS | 128.00 | 15.00 | 13615.99 | 13464.40 | -1.11 | 13330.02 | 13870.57 | 4.06
>> RotateBenchmark.testRotateLeftS | 128.00 | 15.00 | 7043.31 | 6763.34 | -3.97 | 6928.88 | 7063.57 | 1.94
>> RotateBenchmark.testRotateLeftS | 128.00 | 15.00 | 3495.12 | 3537.62 | 1.22 | 3503.41 | 3457.67 | -1.31
>> RotateBenchmark.testRotateLeftS | 128.00 | 31.00 | 13591.66 | 13665.84 | 0.55 | 13773.27 | 13126.08 | -4.70
>> RotateBenchmark.testRotateLeftS | 128.00 | 31.00 | 7027.08 | 7011.24 | -0.23 | 6974.98 | 6815.50 | -2.29
>> RotateBenchmark.testRotateLeftS | 128.00 | 31.00 | 3568.28 | 3569.62 | 0.04 | 3580.67 | 3463.58 | -3.27
>> RotateBenchmark.testRotateLeftS | 256.00 | 7.00 | 21154.03 | 21416.32 | 1.24 | 21187.01 | 21401.61 | 1.01
>> RotateBenchmark.testRotateLeftS | 256.00 | 7.00 | 11194.24 | 10865.47 | -2.94 | 11063.19 | 10977.60 | -0.77
>> RotateBenchmark.testRotateLeftS | 256.00 | 7.00 | 5797.80 | 5523.94 | -4.72 | 5654.63 | 5468.78 | -3.29
>> RotateBenchmark.testRotateLeftS | 256.00 | 15.00 | 21333.89 | 21412.74 | 0.37 | 21610.94 | 20908.96 | -3.25
>> RotateBenchmark.testRotateLeftS | 256.00 | 15.00 | 11327.07 | 11113.48 | -1.89 | 11148.25 | 10678.14 | -4.22
>> RotateBenchmark.testRotateLeftS | 256.00 | 15.00 | 5810.69 | 5569.72 | -4.15 | 5663.26 | 5618.87 | -0.78
>> RotateBenchmark.testRotateLeftS | 256.00 | 31.00 | 21753.20 | 21198.43 | -2.55 | 21567.90 | 21929.81 | 1.68
>> RotateBenchmark.testRotateLeftS | 256.00 | 31.00 | 11517.08 | 11039.64 | -4.15 | 11103.08 | 10871.59 | -2.08
>> RotateBenchmark.testRotateLeftS | 256.00 | 31.00 | 5897.16 | 5606.75 | -4.92 | 5459.87 | 5604.12 | 2.64
>> RotateBenchmark.testRotateLeftS | 512.00 | 7.00 | 29748.53 | 28883.73 | -2.91 | 1549.02 | 3928.53 | 153.61
>> RotateBenchmark.testRotateLeftS | 512.00 | 7.00 | 15197.09 | 15878.19 | 4.48 | 772.59 | 1924.35 | 149.08
>> RotateBenchmark.testRotateLeftS | 512.00 | 7.00 | 8046.30 | 8081.19 | 0.43 | 388.11 | 990.28 | 155.16
>> RotateBenchmark.testRotateLeftS | 512.00 | 15.00 | 30618.04 | 29419.19 | -3.92 | 1524.22 | 3915.97 | 156.92
>> RotateBenchmark.testRotateLeftS | 512.00 | 15.00 | 15854.43 | 15846.37 | -0.05 | 766.09 | 1953.60 | 155.01
>> RotateBenchmark.testRotateLeftS | 512.00 | 15.00 | 7814.77 | 7899.30 | 1.08 | 390.82 | 970.37 | 148.29
>> RotateBenchmark.testRotateLeftS | 512.00 | 31.00 | 29596.82 | 28538.69 | -3.58 | 1530.45 | 3906.91 | 155.28
>> RotateBenchmark.testRotateLeftS | 512.00 | 31.00 | 15662.48 | 15849.25 | 1.19 | 778.08 | 1934.31 | 148.60
>> RotateBenchmark.testRotateLeftS | 512.00 | 31.00 | 8121.14 | 7758.59 | -4.46 | 392.78 | 959.73 | 144.34
>> RotateBenchmark.testRotateRightB | 128.00 | 7.00 | 17465.84 | 17069.34 | -2.27 | 16849.73 | 17842.08 | 5.89
>> RotateBenchmark.testRotateRightB | 128.00 | 7.00 | 9049.19 | 8864.15 | -2.04 | 8786.67 | 9105.34 | 3.63
>> RotateBenchmark.testRotateRightB | 128.00 | 15.00 | 17703.38 | 17070.98 | -3.57 | 16595.85 | 17784.68 | 7.16
>> RotateBenchmark.testRotateRightB | 128.00 | 15.00 | 9007.68 | 8817.41 | -2.11 | 8704.49 | 9185.87 | 5.53
>> RotateBenchmark.testRotateRightB | 128.00 | 31.00 | 17531.05 | 16983.40 | -3.12 | 16947.69 | 17655.40 | 4.18
>> RotateBenchmark.testRotateRightB | 128.00 | 31.00 | 8986.30 | 8794.15 | -2.14 | 8816.62 | 9225.95 | 4.64
>> RotateBenchmark.testRotateRightB | 256.00 | 7.00 | 21293.95 | 21506.74 | 1.00 | 21163.29 | 21854.03 | 3.26
>> RotateBenchmark.testRotateRightB | 256.00 | 7.00 | 11258.47 | 11072.92 | -1.65 | 11118.12 | 11338.96 | 1.99
>> RotateBenchmark.testRotateRightB | 256.00 | 15.00 | 21253.36 | 21292.37 | 0.18 | 21224.39 | 21763.88 | 2.54
>> RotateBenchmark.testRotateRightB | 256.00 | 15.00 | 11064.80 | 11198.35 | 1.21 | 10960.98 | 11294.14 | 3.04
>> RotateBenchmark.testRotateRightB | 256.00 | 31.00 | 21358.14 | 21346.21 | -0.06 | 21487.25 | 21854.42 | 1.71
>> RotateBenchmark.testRotateRightB | 256.00 | 31.00 | 11045.61 | 11208.26 | 1.47 | 10907.03 | 11415.18 | 4.66
>> RotateBenchmark.testRotateRightB | 512.00 | 7.00 | 17898.61 | 18307.54 | 2.28 | 1214.65 | 2546.64 | 109.66
>> RotateBenchmark.testRotateRightB | 512.00 | 15.00 | 17909.25 | 18242.51 | 1.86 | 1215.05 | 2563.98 | 111.02
>> RotateBenchmark.testRotateRightB | 512.00 | 31.00 | 17883.35 | 17928.44 | 0.25 | 1220.77 | 2543.30 | 108.34
>> RotateBenchmark.testRotateRightI | 128.00 | 7.00 | 7139.97 | 7626.72 | 6.82 | 6994.86 | 7075.65 | 1.15
>> RotateBenchmark.testRotateRightI | 128.00 | 7.00 | 3657.37 | 3898.34 | 6.59 | 3617.06 | 3576.12 | -1.13
>> RotateBenchmark.testRotateRightI | 128.00 | 7.00 | 1804.26 | 1969.19 | 9.14 | 1796.62 | 1858.84 | 3.46
>> RotateBenchmark.testRotateRightI | 128.00 | 15.00 | 7404.31 | 7760.09 | 4.80 | 7036.77 | 7401.52 | 5.18
>> RotateBenchmark.testRotateRightI | 128.00 | 15.00 | 3600.52 | 3956.35 | 9.88 | 3595.28 | 3560.36 | -0.97
>> RotateBenchmark.testRotateRightI | 128.00 | 15.00 | 1813.32 | 1966.41 | 8.44 | 1839.95 | 1852.53 | 0.68
>> RotateBenchmark.testRotateRightI | 128.00 | 31.00 | 7118.48 | 7724.81 | 8.52 | 7151.56 | 7021.09 | -1.82
>> RotateBenchmark.testRotateRightI | 128.00 | 31.00 | 3529.70 | 3881.63 | 9.97 | 3623.08 | 3601.01 | -0.61
>> RotateBenchmark.testRotateRightI | 128.00 | 31.00 | 1823.61 | 1961.34 | 7.55 | 1786.86 | 1748.85 | -2.13
>> RotateBenchmark.testRotateRightI | 256.00 | 7.00 | 11697.98 | 11835.25 | 1.17 | 11513.16 | 11184.87 | -2.85
>> RotateBenchmark.testRotateRightI | 256.00 | 7.00 | 5890.11 | 6102.57 | 3.61 | 5658.79 | 5696.08 | 0.66
>> RotateBenchmark.testRotateRightI | 256.00 | 7.00 | 2964.94 | 3070.26 | 3.55 | 2945.00 | 2962.08 | 0.58
>> RotateBenchmark.testRotateRightI | 256.00 | 15.00 | 11562.51 | 12151.29 | 5.09 | 11404.17 | 11120.28 | -2.49
>> RotateBenchmark.testRotateRightI | 256.00 | 15.00 | 5702.93 | 6130.57 | 7.50 | 5799.54 | 5779.08 | -0.35
>> RotateBenchmark.testRotateRightI | 256.00 | 15.00 | 2861.96 | 3051.44 | 6.62 | 2943.99 | 2860.65 | -2.83
>> RotateBenchmark.testRotateRightI | 256.00 | 31.00 | 11203.13 | 11710.59 | 4.53 | 11363.18 | 11112.16 | -2.21
>> RotateBenchmark.testRotateRightI | 256.00 | 31.00 | 5893.97 | 6070.71 | 3.00 | 5776.67 | 5648.84 | -2.21
>> RotateBenchmark.testRotateRightI | 256.00 | 31.00 | 2971.83 | 3046.76 | 2.52 | 2903.35 | 2833.88 | -2.39
>> RotateBenchmark.testRotateRightI | 512.00 | 7.00 | 16064.71 | 15851.35 | -1.33 | 861.93 | 2256.88 | 161.84
>> RotateBenchmark.testRotateRightI | 512.00 | 7.00 | 7916.80 | 8462.65 | 6.89 | 430.23 | 1147.30 | 166.67
>> RotateBenchmark.testRotateRightI | 512.00 | 7.00 | 4104.64 | 4068.28 | -0.89 | 216.30 | 572.86 | 164.84
>> RotateBenchmark.testRotateRightI | 512.00 | 15.00 | 16133.09 | 16281.59 | 0.92 | 856.36 | 2229.58 | 160.35
>> RotateBenchmark.testRotateRightI | 512.00 | 15.00 | 8127.26 | 8117.59 | -0.12 | 419.16 | 1176.42 | 180.66
>> RotateBenchmark.testRotateRightI | 512.00 | 15.00 | 4080.11 | 4063.26 | -0.41 | 218.32 | 571.93 | 161.97
>> RotateBenchmark.testRotateRightI | 512.00 | 31.00 | 15834.26 | 16314.64 | 3.03 | 865.96 | 2297.74 | 165.34
>> RotateBenchmark.testRotateRightI | 512.00 | 31.00 | 7965.62 | 8270.48 | 3.83 | 428.55 | 1148.87 | 168.08
>> RotateBenchmark.testRotateRightI | 512.00 | 31.00 | 4161.69 | 4034.76 | -3.05 | 215.63 | 570.19 | 164.43
>> RotateBenchmark.testRotateRightL | 128.00 | 7.00 | 3556.70 | 3877.08 | 9.01 | 3596.46 | 3558.32 | -1.06
>> RotateBenchmark.testRotateRightL | 128.00 | 7.00 | 1772.93 | 1993.86 | 12.46 | 1856.79 | 1783.22 | -3.96
>> RotateBenchmark.testRotateRightL | 128.00 | 7.00 | 908.66 | 1000.37 | 10.09 | 944.79 | 922.91 | -2.32
>> RotateBenchmark.testRotateRightL | 128.00 | 15.00 | 3742.44 | 3748.41 | 0.16 | 3788.07 | 3570.67 | -5.74
>> RotateBenchmark.testRotateRightL | 128.00 | 15.00 | 1817.53 | 1985.69 | 9.25 | 1892.38 | 1833.16 | -3.13
>> RotateBenchmark.testRotateRightL | 128.00 | 15.00 | 941.03 | 952.68 | 1.24 | 915.79 | 910.21 | -0.61
>> RotateBenchmark.testRotateRightL | 128.00 | 31.00 | 3649.48 | 3896.56 | 6.77 | 3637.59 | 3557.53 | -2.20
>> RotateBenchmark.testRotateRightL | 128.00 | 31.00 | 1840.12 | 1997.19 | 8.54 | 1821.47 | 1799.82 | -1.19
>> RotateBenchmark.testRotateRightL | 128.00 | 31.00 | 901.33 | 995.67 | 10.47 | 909.20 | 902.73 | -0.71
>> RotateBenchmark.testRotateRightL | 256.00 | 7.00 | 5789.93 | 5960.54 | 2.95 | 5758.14 | 5736.30 | -0.38
>> RotateBenchmark.testRotateRightL | 256.00 | 7.00 | 2963.20 | 3063.30 | 3.38 | 2943.48 | 2833.84 | -3.72
>> RotateBenchmark.testRotateRightL | 256.00 | 7.00 | 1501.81 | 1510.23 | 0.56 | 1463.85 | 1462.26 | -0.11
>> RotateBenchmark.testRotateRightL | 256.00 | 15.00 | 5870.05 | 5951.43 | 1.39 | 5794.74 | 5604.58 | -3.28
>> RotateBenchmark.testRotateRightL | 256.00 | 15.00 | 2971.36 | 3047.00 | 2.55 | 2931.19 | 2907.30 | -0.82
>> RotateBenchmark.testRotateRightL | 256.00 | 15.00 | 1473.97 | 1530.54 | 3.84 | 1473.45 | 1442.40 | -2.11
>> RotateBenchmark.testRotateRightL | 256.00 | 31.00 | 5858.08 | 6080.49 | 3.80 | 5863.69 | 5549.85 | -5.35
>> RotateBenchmark.testRotateRightL | 256.00 | 31.00 | 2916.24 | 3045.77 | 4.44 | 2981.59 | 2815.07 | -5.58
>> RotateBenchmark.testRotateRightL | 256.00 | 31.00 | 1441.20 | 1531.56 | 6.27 | 1492.47 | 1473.25 | -1.29
>> RotateBenchmark.testRotateRightL | 512.00 | 7.00 | 8147.24 | 8310.05 | 2.00 | 469.45 | 1235.21 | 163.12
>> RotateBenchmark.testRotateRightL | 512.00 | 7.00 | 4142.95 | 4258.86 | 2.80 | 234.14 | 615.52 | 162.88
>> RotateBenchmark.testRotateRightL | 512.00 | 7.00 | 2095.48 | 2087.20 | -0.40 | 113.55 | 311.19 | 174.05
>> RotateBenchmark.testRotateRightL | 512.00 | 15.00 | 8222.94 | 8246.58 | 0.29 | 458.91 | 1244.32 | 171.15
>> RotateBenchmark.testRotateRightL | 512.00 | 15.00 | 4160.04 | 4226.46 | 1.60 | 227.78 | 625.38 | 174.56
>> RotateBenchmark.testRotateRightL | 512.00 | 15.00 | 2064.63 | 2162.44 | 4.74 | 113.27 | 314.15 | 177.36
>> RotateBenchmark.testRotateRightL | 512.00 | 31.00 | 8157.94 | 8466.90 | 3.79 | 450.26 | 1221.90 | 171.37
>> RotateBenchmark.testRotateRightL | 512.00 | 31.00 | 4039.74 | 4283.33 | 6.03 | 224.82 | 612.68 | 172.53
>> RotateBenchmark.testRotateRightL | 512.00 | 31.00 | 2066.88 | 2147.51 | 3.90 | 110.97 | 303.43 | 173.42
>> RotateBenchmark.testRotateRightS | 128.00 | 7.00 | 13548.39 | 13245.87 | -2.23 | 13490.93 | 13084.76 | -3.01
>> RotateBenchmark.testRotateRightS | 128.00 | 7.00 | 7020.16 | 6768.85 | -3.58 | 6991.39 | 7044.32 | 0.76
>> RotateBenchmark.testRotateRightS | 128.00 | 7.00 | 3550.50 | 3505.19 | -1.28 | 3507.12 | 3612.86 | 3.01
>> RotateBenchmark.testRotateRightS | 128.00 | 15.00 | 13743.43 | 13325.44 | -3.04 | 13696.15 | 13255.80 | -3.22
>> RotateBenchmark.testRotateRightS | 128.00 | 15.00 | 6856.02 | 6969.18 | 1.65 | 6886.29 | 6834.12 | -0.76
>> RotateBenchmark.testRotateRightS | 128.00 | 15.00 | 3569.53 | 3492.76 | -2.15 | 3539.02 | 3470.02 | -1.95
>> RotateBenchmark.testRotateRightS | 128.00 | 31.00 | 13704.18 | 13495.07 | -1.53 | 13649.14 | 13583.87 | -0.48
>> RotateBenchmark.testRotateRightS | 128.00 | 31.00 | 7011.77 | 6953.93 | -0.82 | 6978.28 | 6740.30 | -3.41
>> RotateBenchmark.testRotateRightS | 128.00 | 31.00 | 3591.62 | 3620.12 | 0.79 | 3502.04 | 3510.05 | 0.23
>> RotateBenchmark.testRotateRightS | 256.00 | 7.00 | 21950.71 | 22113.60 | 0.74 | 21484.27 | 21596.64 | 0.52
>> RotateBenchmark.testRotateRightS | 256.00 | 7.00 | 11616.88 | 11099.73 | -4.45 | 11188.29 | 10737.68 | -4.03
>> RotateBenchmark.testRotateRightS | 256.00 | 7.00 | 5872.72 | 5579.12 | -5.00 | 5784.05 | 5454.57 | -5.70
>> RotateBenchmark.testRotateRightS | 256.00 | 15.00 | 22017.83 | 20817.97 | -5.45 | 21934.65 | 21356.90 | -2.63
>> RotateBenchmark.testRotateRightS | 256.00 | 15.00 | 11414.27 | 11044.86 | -3.24 | 11454.35 | 11140.34 | -2.74
>> RotateBenchmark.testRotateRightS | 256.00 | 15.00 | 5786.64 | 5634.05 | -2.64 | 5724.93 | 5639.99 | -1.48
>> RotateBenchmark.testRotateRightS | 256.00 | 31.00 | 21754.77 | 21466.01 | -1.33 | 21140.67 | 21970.03 | 3.92
>> RotateBenchmark.testRotateRightS | 256.00 | 31.00 | 11676.46 | 11358.64 | -2.72 | 11204.90 | 11213.48 | 0.08
>> RotateBenchmark.testRotateRightS | 256.00 | 31.00 | 5728.20 | 5772.49 | 0.77 | 5594.33 | 5544.25 | -0.90
>> RotateBenchmark.testRotateRightS | 512.00 | 7.00 | 30247.03 | 30179.41 | -0.22 | 1538.75 | 3975.82 | 158.38
>> RotateBenchmark.testRotateRightS | 512.00 | 7.00 | 15988.73 | 15621.42 | -2.30 | 776.04 | 1910.91 | 146.24
>> RotateBenchmark.testRotateRightS | 512.00 | 7.00 | 8115.84 | 8025.28 | -1.12 | 389.12 | 984.46 | 152.99
>> RotateBenchmark.testRotateRightS | 512.00 | 15.00 | 30110.91 | 30200.69 | 0.30 | 1532.49 | 3983.77 | 159.95
>> RotateBenchmark.testRotateRightS | 512.00 | 15.00 | 15957.90 | 15690.73 | -1.67 | 774.90 | 1931.00 | 149.19
>> RotateBenchmark.testRotateRightS | 512.00 | 15.00 | 8113.26 | 8037.93 | -0.93 | 391.90 | 965.53 | 146.37
>> RotateBenchmark.testRotateRightS | 512.00 | 31.00 | 29816.97 | 29891.54 | 0.25 | 1538.12 | 3881.93 | 152.38
>> RotateBenchmark.testRotateRightS | 512.00 | 31.00 | 15405.95 | 15619.17 | 1.38 | 762.49 | 1871.00 | 145.38
>> RotateBenchmark.testRotateRightS | 512.00 | 31.00 | 7919.80 | 7957.35 | 0.47 | 393.63 | 972.49 | 147.06
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8266054: Review comments resolution.

Hi @sviswa7 your comments have been addressed.

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

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

From jbhateja at openjdk.java.net  Sun Jul 18 20:36:45 2021
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Sun, 18 Jul 2021 20:36:45 GMT
Subject: RFR: 8266054: VectorAPI rotate operation optimization [v12]
In-Reply-To: <OZ2u4DDNaYF3WiR5uU6NWvzPMKV3j8QAO_mZyLP3Isg=.594e3514-8a5a-442c-ac1a-ca6c6d14e963@github.com>
References: <OZ2u4DDNaYF3WiR5uU6NWvzPMKV3j8QAO_mZyLP3Isg=.594e3514-8a5a-442c-ac1a-ca6c6d14e963@github.com>
Message-ID: <x8QRmoxTAQnAro5Hngz1PiWfMkXrLJIs_qBu4w3yh94=.7295db66-b9f5-4602-8790-8a161832c479@github.com>

> Current VectorAPI Java side implementation expresses rotateLeft and rotateRight operation using following operations:-
> 
>     vec1 = lanewise(VectorOperators.LSHL, n)
>     vec2 = lanewise(VectorOperators.LSHR, n)
>     res = lanewise(VectorOperations.OR, vec1 , vec2)
> 
> This patch moves above handling from Java side to C2 compiler which facilitates dismantling the rotate operation if target ISA does not support a direct rotate instruction.
> 
> AVX512 added vector rotate instructions vpro[rl][v][dq] which operate over long and integer type vectors. For other cases (i.e. sub-word type vectors or for targets which do not support direct rotate operations )   instruction sequence comprising of vector SHIFT (LEFT/RIGHT) and vector OR is emitted.
> 
> Please find below the performance data for included JMH benchmark.
> Machine:  Cascade Lake Server (Intel(R) Xeon(R) Platinum 8280 CPU @ 2.70GHz)
> 
> 
> Benchmark | (TESTSIZE) | Shift | Baseline AVX3 (ops/ms) | Withopt? AVX3 (ops/ms) | Gain % | Baseline AVX2 (ops/ms) | Withopt AVX2 (ops/ms) | Gain %
> -- | -- | -- | -- | -- | -- | -- | -- | --
> ? | ? | ? | ? | ? | ? | ? | ? | ?
> RotateBenchmark.testRotateLeftB | 128.00 | 7.00 | 17223.35 | 17094.69 | -0.75 | 17008.32 | 17488.06 | 2.82
> RotateBenchmark.testRotateLeftB | 128.00 | 7.00 | 8944.98 | 8811.34 | -1.49 | 8878.17 | 9218.68 | 3.84
> RotateBenchmark.testRotateLeftB | 128.00 | 15.00 | 17195.75 | 17137.32 | -0.34 | 16789.01 | 17780.34 | 5.90
> RotateBenchmark.testRotateLeftB | 128.00 | 15.00 | 9052.67 | 8838.60 | -2.36 | 8814.62 | 9206.01 | 4.44
> RotateBenchmark.testRotateLeftB | 128.00 | 31.00 | 17100.19 | 16950.64 | -0.87 | 16827.73 | 17720.37 | 5.30
> RotateBenchmark.testRotateLeftB | 128.00 | 31.00 | 9079.95 | 8471.26 | -6.70 | 8888.44 | 9167.68 | 3.14
> RotateBenchmark.testRotateLeftB | 256.00 | 7.00 | 21231.33 | 21513.08 | 1.33 | 21824.51 | 21479.48 | -1.58
> RotateBenchmark.testRotateLeftB | 256.00 | 7.00 | 11103.62 | 11180.16 | 0.69 | 11173.67 | 11529.22 | 3.18
> RotateBenchmark.testRotateLeftB | 256.00 | 15.00 | 21119.14 | 21552.04 | 2.05 | 21693.05 | 21915.37 | 1.02
> RotateBenchmark.testRotateLeftB | 256.00 | 15.00 | 11048.68 | 11094.20 | 0.41 | 11049.90 | 11439.07 | 3.52
> RotateBenchmark.testRotateLeftB | 256.00 | 31.00 | 21506.31 | 21391.41 | -0.53 | 21263.18 | 21986.29 | 3.40
> RotateBenchmark.testRotateLeftB | 256.00 | 31.00 | 11056.12 | 11232.78 | 1.60 | 10941.59 | 11397.09 | 4.16
> RotateBenchmark.testRotateLeftB | 512.00 | 7.00 | 17976.56 | 18180.85 | 1.14 | 1212.26 | 2533.34 | 108.98
> RotateBenchmark.testRotateLeftB | 512.00 | 15.00 | 17553.70 | 18219.07 | 3.79 | 1256.73 | 2537.41 | 101.91
> RotateBenchmark.testRotateLeftB | 512.00 | 31.00 | 17618.03 | 17738.15 | 0.68 | 1214.69 | 2533.83 | 108.60
> RotateBenchmark.testRotateLeftI | 128.00 | 7.00 | 7258.87 | 7468.88 | 2.89 | 7115.12 | 7117.26 | 0.03
> RotateBenchmark.testRotateLeftI | 128.00 | 7.00 | 3586.65 | 3950.85 | 10.15 | 3532.17 | 3595.80 | 1.80
> RotateBenchmark.testRotateLeftI | 128.00 | 7.00 | 1835.07 | 1999.68 | 8.97 | 1789.90 | 1819.93 | 1.68
> RotateBenchmark.testRotateLeftI | 128.00 | 15.00 | 7273.36 | 7410.91 | 1.89 | 7198.60 | 6994.79 | -2.83
> RotateBenchmark.testRotateLeftI | 128.00 | 15.00 | 3674.98 | 3926.27 | 6.84 | 3549.90 | 3755.09 | 5.78
> RotateBenchmark.testRotateLeftI | 128.00 | 15.00 | 1840.94 | 1882.25 | 2.24 | 1801.56 | 1872.89 | 3.96
> RotateBenchmark.testRotateLeftI | 128.00 | 31.00 | 7457.11 | 7361.48 | -1.28 | 6975.33 | 7385.94 | 5.89
> RotateBenchmark.testRotateLeftI | 128.00 | 31.00 | 3570.74 | 3929.30 | 10.04 | 3635.37 | 3736.67 | 2.79
> RotateBenchmark.testRotateLeftI | 128.00 | 31.00 | 1902.32 | 1960.46 | 3.06 | 1812.32 | 1813.88 | 0.09
> RotateBenchmark.testRotateLeftI | 256.00 | 7.00 | 11174.24 | 12044.52 | 7.79 | 11509.87 | 11273.44 | -2.05
> RotateBenchmark.testRotateLeftI | 256.00 | 7.00 | 5981.47 | 6073.70 | 1.54 | 5593.66 | 5661.93 | 1.22
> RotateBenchmark.testRotateLeftI | 256.00 | 7.00 | 2932.49 | 3069.54 | 4.67 | 2950.86 | 2892.42 | -1.98
> RotateBenchmark.testRotateLeftI | 256.00 | 15.00 | 11764.11 | 12098.63 | 2.84 | 11069.52 | 11476.93 | 3.68
> RotateBenchmark.testRotateLeftI | 256.00 | 15.00 | 5855.20 | 6080.40 | 3.85 | 5919.11 | 5607.04 | -5.27
> RotateBenchmark.testRotateLeftI | 256.00 | 15.00 | 2989.05 | 3048.56 | 1.99 | 2902.63 | 2821.83 | -2.78
> RotateBenchmark.testRotateLeftI | 256.00 | 31.00 | 11652.84 | 11965.40 | 2.68 | 11525.62 | 11459.83 | -0.57
> RotateBenchmark.testRotateLeftI | 256.00 | 31.00 | 5851.82 | 6164.94 | 5.35 | 5882.60 | 5842.30 | -0.69
> RotateBenchmark.testRotateLeftI | 256.00 | 31.00 | 3015.99 | 3043.79 | 0.92 | 2963.71 | 2947.97 | -0.53
> RotateBenchmark.testRotateLeftI | 512.00 | 7.00 | 16029.15 | 16189.79 | 1.00 | 860.43 | 2339.32 | 171.88
> RotateBenchmark.testRotateLeftI | 512.00 | 7.00 | 8078.25 | 8081.84 | 0.04 | 427.39 | 1147.92 | 168.59
> RotateBenchmark.testRotateLeftI | 512.00 | 7.00 | 4021.49 | 4294.03 | 6.78 | 209.25 | 582.28 | 178.27
> RotateBenchmark.testRotateLeftI | 512.00 | 15.00 | 15912.98 | 16329.03 | 2.61 | 848.23 | 2296.78 | 170.77
> RotateBenchmark.testRotateLeftI | 512.00 | 15.00 | 8054.10 | 8306.37 | 3.13 | 429.93 | 1146.90 | 166.77
> RotateBenchmark.testRotateLeftI | 512.00 | 15.00 | 4102.58 | 4071.08 | -0.77 | 217.86 | 582.20 | 167.24
> RotateBenchmark.testRotateLeftI | 512.00 | 31.00 | 16177.79 | 16287.85 | 0.68 | 857.84 | 2243.15 | 161.49
> RotateBenchmark.testRotateLeftI | 512.00 | 31.00 | 8187.47 | 8410.48 | 2.72 | 434.60 | 1128.20 | 159.60
> RotateBenchmark.testRotateLeftI | 512.00 | 31.00 | 4109.15 | 4233.80 | 3.03 | 208.71 | 572.43 | 174.27
> RotateBenchmark.testRotateLeftL | 128.00 | 7.00 | 3755.09 | 3930.29 | 4.67 | 3604.19 | 3598.47 | -0.16
> RotateBenchmark.testRotateLeftL | 128.00 | 7.00 | 1829.03 | 1957.39 | 7.02 | 1833.95 | 1808.38 | -1.39
> RotateBenchmark.testRotateLeftL | 128.00 | 7.00 | 915.35 | 970.55 | 6.03 | 916.25 | 899.08 | -1.87
> RotateBenchmark.testRotateLeftL | 128.00 | 15.00 | 3664.85 | 3812.26 | 4.02 | 3629.37 | 3579.23 | -1.38
> RotateBenchmark.testRotateLeftL | 128.00 | 15.00 | 1829.51 | 1877.76 | 2.64 | 1781.05 | 1807.57 | 1.49
> RotateBenchmark.testRotateLeftL | 128.00 | 15.00 | 913.37 | 953.42 | 4.38 | 912.26 | 908.73 | -0.39
> RotateBenchmark.testRotateLeftL | 128.00 | 31.00 | 3648.45 | 3899.20 | 6.87 | 3552.67 | 3581.04 | 0.80
> RotateBenchmark.testRotateLeftL | 128.00 | 31.00 | 1816.50 | 1959.68 | 7.88 | 1820.88 | 1819.71 | -0.06
> RotateBenchmark.testRotateLeftL | 128.00 | 31.00 | 901.05 | 955.13 | 6.00 | 913.74 | 907.90 | -0.64
> RotateBenchmark.testRotateLeftL | 256.00 | 7.00 | 5850.99 | 6108.64 | 4.40 | 5882.65 | 5755.21 | -2.17
> RotateBenchmark.testRotateLeftL | 256.00 | 7.00 | 2962.21 | 3060.47 | 3.32 | 2955.20 | 2909.18 | -1.56
> RotateBenchmark.testRotateLeftL | 256.00 | 7.00 | 1480.46 | 1534.72 | 3.66 | 1467.78 | 1430.60 | -2.53
> RotateBenchmark.testRotateLeftL | 256.00 | 15.00 | 5858.23 | 6047.51 | 3.23 | 5770.02 | 5773.19 | 0.05
> RotateBenchmark.testRotateLeftL | 256.00 | 15.00 | 2951.49 | 3096.53 | 4.91 | 2885.21 | 2899.31 | 0.49
> RotateBenchmark.testRotateLeftL | 256.00 | 15.00 | 1486.26 | 1527.94 | 2.80 | 1441.93 | 1454.25 | 0.85
> RotateBenchmark.testRotateLeftL | 256.00 | 31.00 | 5873.21 | 6089.75 | 3.69 | 5767.58 | 5664.11 | -1.79
> RotateBenchmark.testRotateLeftL | 256.00 | 31.00 | 2969.67 | 3081.39 | 3.76 | 2878.50 | 2905.86 | 0.95
> RotateBenchmark.testRotateLeftL | 256.00 | 31.00 | 1452.21 | 1520.03 | 4.67 | 1430.30 | 1485.63 | 3.87
> RotateBenchmark.testRotateLeftL | 512.00 | 7.00 | 8088.65 | 8443.63 | 4.39 | 455.67 | 1226.33 | 169.13
> RotateBenchmark.testRotateLeftL | 512.00 | 7.00 | 4011.95 | 4120.25 | 2.70 | 229.77 | 619.87 | 169.77
> RotateBenchmark.testRotateLeftL | 512.00 | 7.00 | 2090.57 | 2109.53 | 0.91 | 115.21 | 310.36 | 169.37
> RotateBenchmark.testRotateLeftL | 512.00 | 15.00 | 8166.84 | 8557.28 | 4.78 | 457.67 | 1242.86 | 171.56
> RotateBenchmark.testRotateLeftL | 512.00 | 15.00 | 4137.02 | 4287.95 | 3.65 | 227.26 | 624.80 | 174.93
> RotateBenchmark.testRotateLeftL | 512.00 | 15.00 | 2095.01 | 2102.86 | 0.37 | 114.26 | 310.83 | 172.03
> RotateBenchmark.testRotateLeftL | 512.00 | 31.00 | 8082.68 | 8400.56 | 3.93 | 459.59 | 1230.07 | 167.64
> RotateBenchmark.testRotateLeftL | 512.00 | 31.00 | 4047.67 | 4147.58 | 2.47 | 229.01 | 606.38 | 164.78
> RotateBenchmark.testRotateLeftL | 512.00 | 31.00 | 2086.83 | 2126.72 | 1.91 | 111.93 | 305.66 | 173.08
> RotateBenchmark.testRotateLeftS | 128.00 | 7.00 | 13597.19 | 13255.09 | -2.52 | 13818.39 | 13242.40 | -4.17
> RotateBenchmark.testRotateLeftS | 128.00 | 7.00 | 7028.26 | 6826.59 | -2.87 | 6765.15 | 6907.87 | 2.11
> RotateBenchmark.testRotateLeftS | 128.00 | 7.00 | 3570.40 | 3468.01 | -2.87 | 3449.66 | 3533.50 | 2.43
> RotateBenchmark.testRotateLeftS | 128.00 | 15.00 | 13615.99 | 13464.40 | -1.11 | 13330.02 | 13870.57 | 4.06
> RotateBenchmark.testRotateLeftS | 128.00 | 15.00 | 7043.31 | 6763.34 | -3.97 | 6928.88 | 7063.57 | 1.94
> RotateBenchmark.testRotateLeftS | 128.00 | 15.00 | 3495.12 | 3537.62 | 1.22 | 3503.41 | 3457.67 | -1.31
> RotateBenchmark.testRotateLeftS | 128.00 | 31.00 | 13591.66 | 13665.84 | 0.55 | 13773.27 | 13126.08 | -4.70
> RotateBenchmark.testRotateLeftS | 128.00 | 31.00 | 7027.08 | 7011.24 | -0.23 | 6974.98 | 6815.50 | -2.29
> RotateBenchmark.testRotateLeftS | 128.00 | 31.00 | 3568.28 | 3569.62 | 0.04 | 3580.67 | 3463.58 | -3.27
> RotateBenchmark.testRotateLeftS | 256.00 | 7.00 | 21154.03 | 21416.32 | 1.24 | 21187.01 | 21401.61 | 1.01
> RotateBenchmark.testRotateLeftS | 256.00 | 7.00 | 11194.24 | 10865.47 | -2.94 | 11063.19 | 10977.60 | -0.77
> RotateBenchmark.testRotateLeftS | 256.00 | 7.00 | 5797.80 | 5523.94 | -4.72 | 5654.63 | 5468.78 | -3.29
> RotateBenchmark.testRotateLeftS | 256.00 | 15.00 | 21333.89 | 21412.74 | 0.37 | 21610.94 | 20908.96 | -3.25
> RotateBenchmark.testRotateLeftS | 256.00 | 15.00 | 11327.07 | 11113.48 | -1.89 | 11148.25 | 10678.14 | -4.22
> RotateBenchmark.testRotateLeftS | 256.00 | 15.00 | 5810.69 | 5569.72 | -4.15 | 5663.26 | 5618.87 | -0.78
> RotateBenchmark.testRotateLeftS | 256.00 | 31.00 | 21753.20 | 21198.43 | -2.55 | 21567.90 | 21929.81 | 1.68
> RotateBenchmark.testRotateLeftS | 256.00 | 31.00 | 11517.08 | 11039.64 | -4.15 | 11103.08 | 10871.59 | -2.08
> RotateBenchmark.testRotateLeftS | 256.00 | 31.00 | 5897.16 | 5606.75 | -4.92 | 5459.87 | 5604.12 | 2.64
> RotateBenchmark.testRotateLeftS | 512.00 | 7.00 | 29748.53 | 28883.73 | -2.91 | 1549.02 | 3928.53 | 153.61
> RotateBenchmark.testRotateLeftS | 512.00 | 7.00 | 15197.09 | 15878.19 | 4.48 | 772.59 | 1924.35 | 149.08
> RotateBenchmark.testRotateLeftS | 512.00 | 7.00 | 8046.30 | 8081.19 | 0.43 | 388.11 | 990.28 | 155.16
> RotateBenchmark.testRotateLeftS | 512.00 | 15.00 | 30618.04 | 29419.19 | -3.92 | 1524.22 | 3915.97 | 156.92
> RotateBenchmark.testRotateLeftS | 512.00 | 15.00 | 15854.43 | 15846.37 | -0.05 | 766.09 | 1953.60 | 155.01
> RotateBenchmark.testRotateLeftS | 512.00 | 15.00 | 7814.77 | 7899.30 | 1.08 | 390.82 | 970.37 | 148.29
> RotateBenchmark.testRotateLeftS | 512.00 | 31.00 | 29596.82 | 28538.69 | -3.58 | 1530.45 | 3906.91 | 155.28
> RotateBenchmark.testRotateLeftS | 512.00 | 31.00 | 15662.48 | 15849.25 | 1.19 | 778.08 | 1934.31 | 148.60
> RotateBenchmark.testRotateLeftS | 512.00 | 31.00 | 8121.14 | 7758.59 | -4.46 | 392.78 | 959.73 | 144.34
> RotateBenchmark.testRotateRightB | 128.00 | 7.00 | 17465.84 | 17069.34 | -2.27 | 16849.73 | 17842.08 | 5.89
> RotateBenchmark.testRotateRightB | 128.00 | 7.00 | 9049.19 | 8864.15 | -2.04 | 8786.67 | 9105.34 | 3.63
> RotateBenchmark.testRotateRightB | 128.00 | 15.00 | 17703.38 | 17070.98 | -3.57 | 16595.85 | 17784.68 | 7.16
> RotateBenchmark.testRotateRightB | 128.00 | 15.00 | 9007.68 | 8817.41 | -2.11 | 8704.49 | 9185.87 | 5.53
> RotateBenchmark.testRotateRightB | 128.00 | 31.00 | 17531.05 | 16983.40 | -3.12 | 16947.69 | 17655.40 | 4.18
> RotateBenchmark.testRotateRightB | 128.00 | 31.00 | 8986.30 | 8794.15 | -2.14 | 8816.62 | 9225.95 | 4.64
> RotateBenchmark.testRotateRightB | 256.00 | 7.00 | 21293.95 | 21506.74 | 1.00 | 21163.29 | 21854.03 | 3.26
> RotateBenchmark.testRotateRightB | 256.00 | 7.00 | 11258.47 | 11072.92 | -1.65 | 11118.12 | 11338.96 | 1.99
> RotateBenchmark.testRotateRightB | 256.00 | 15.00 | 21253.36 | 21292.37 | 0.18 | 21224.39 | 21763.88 | 2.54
> RotateBenchmark.testRotateRightB | 256.00 | 15.00 | 11064.80 | 11198.35 | 1.21 | 10960.98 | 11294.14 | 3.04
> RotateBenchmark.testRotateRightB | 256.00 | 31.00 | 21358.14 | 21346.21 | -0.06 | 21487.25 | 21854.42 | 1.71
> RotateBenchmark.testRotateRightB | 256.00 | 31.00 | 11045.61 | 11208.26 | 1.47 | 10907.03 | 11415.18 | 4.66
> RotateBenchmark.testRotateRightB | 512.00 | 7.00 | 17898.61 | 18307.54 | 2.28 | 1214.65 | 2546.64 | 109.66
> RotateBenchmark.testRotateRightB | 512.00 | 15.00 | 17909.25 | 18242.51 | 1.86 | 1215.05 | 2563.98 | 111.02
> RotateBenchmark.testRotateRightB | 512.00 | 31.00 | 17883.35 | 17928.44 | 0.25 | 1220.77 | 2543.30 | 108.34
> RotateBenchmark.testRotateRightI | 128.00 | 7.00 | 7139.97 | 7626.72 | 6.82 | 6994.86 | 7075.65 | 1.15
> RotateBenchmark.testRotateRightI | 128.00 | 7.00 | 3657.37 | 3898.34 | 6.59 | 3617.06 | 3576.12 | -1.13
> RotateBenchmark.testRotateRightI | 128.00 | 7.00 | 1804.26 | 1969.19 | 9.14 | 1796.62 | 1858.84 | 3.46
> RotateBenchmark.testRotateRightI | 128.00 | 15.00 | 7404.31 | 7760.09 | 4.80 | 7036.77 | 7401.52 | 5.18
> RotateBenchmark.testRotateRightI | 128.00 | 15.00 | 3600.52 | 3956.35 | 9.88 | 3595.28 | 3560.36 | -0.97
> RotateBenchmark.testRotateRightI | 128.00 | 15.00 | 1813.32 | 1966.41 | 8.44 | 1839.95 | 1852.53 | 0.68
> RotateBenchmark.testRotateRightI | 128.00 | 31.00 | 7118.48 | 7724.81 | 8.52 | 7151.56 | 7021.09 | -1.82
> RotateBenchmark.testRotateRightI | 128.00 | 31.00 | 3529.70 | 3881.63 | 9.97 | 3623.08 | 3601.01 | -0.61
> RotateBenchmark.testRotateRightI | 128.00 | 31.00 | 1823.61 | 1961.34 | 7.55 | 1786.86 | 1748.85 | -2.13
> RotateBenchmark.testRotateRightI | 256.00 | 7.00 | 11697.98 | 11835.25 | 1.17 | 11513.16 | 11184.87 | -2.85
> RotateBenchmark.testRotateRightI | 256.00 | 7.00 | 5890.11 | 6102.57 | 3.61 | 5658.79 | 5696.08 | 0.66
> RotateBenchmark.testRotateRightI | 256.00 | 7.00 | 2964.94 | 3070.26 | 3.55 | 2945.00 | 2962.08 | 0.58
> RotateBenchmark.testRotateRightI | 256.00 | 15.00 | 11562.51 | 12151.29 | 5.09 | 11404.17 | 11120.28 | -2.49
> RotateBenchmark.testRotateRightI | 256.00 | 15.00 | 5702.93 | 6130.57 | 7.50 | 5799.54 | 5779.08 | -0.35
> RotateBenchmark.testRotateRightI | 256.00 | 15.00 | 2861.96 | 3051.44 | 6.62 | 2943.99 | 2860.65 | -2.83
> RotateBenchmark.testRotateRightI | 256.00 | 31.00 | 11203.13 | 11710.59 | 4.53 | 11363.18 | 11112.16 | -2.21
> RotateBenchmark.testRotateRightI | 256.00 | 31.00 | 5893.97 | 6070.71 | 3.00 | 5776.67 | 5648.84 | -2.21
> RotateBenchmark.testRotateRightI | 256.00 | 31.00 | 2971.83 | 3046.76 | 2.52 | 2903.35 | 2833.88 | -2.39
> RotateBenchmark.testRotateRightI | 512.00 | 7.00 | 16064.71 | 15851.35 | -1.33 | 861.93 | 2256.88 | 161.84
> RotateBenchmark.testRotateRightI | 512.00 | 7.00 | 7916.80 | 8462.65 | 6.89 | 430.23 | 1147.30 | 166.67
> RotateBenchmark.testRotateRightI | 512.00 | 7.00 | 4104.64 | 4068.28 | -0.89 | 216.30 | 572.86 | 164.84
> RotateBenchmark.testRotateRightI | 512.00 | 15.00 | 16133.09 | 16281.59 | 0.92 | 856.36 | 2229.58 | 160.35
> RotateBenchmark.testRotateRightI | 512.00 | 15.00 | 8127.26 | 8117.59 | -0.12 | 419.16 | 1176.42 | 180.66
> RotateBenchmark.testRotateRightI | 512.00 | 15.00 | 4080.11 | 4063.26 | -0.41 | 218.32 | 571.93 | 161.97
> RotateBenchmark.testRotateRightI | 512.00 | 31.00 | 15834.26 | 16314.64 | 3.03 | 865.96 | 2297.74 | 165.34
> RotateBenchmark.testRotateRightI | 512.00 | 31.00 | 7965.62 | 8270.48 | 3.83 | 428.55 | 1148.87 | 168.08
> RotateBenchmark.testRotateRightI | 512.00 | 31.00 | 4161.69 | 4034.76 | -3.05 | 215.63 | 570.19 | 164.43
> RotateBenchmark.testRotateRightL | 128.00 | 7.00 | 3556.70 | 3877.08 | 9.01 | 3596.46 | 3558.32 | -1.06
> RotateBenchmark.testRotateRightL | 128.00 | 7.00 | 1772.93 | 1993.86 | 12.46 | 1856.79 | 1783.22 | -3.96
> RotateBenchmark.testRotateRightL | 128.00 | 7.00 | 908.66 | 1000.37 | 10.09 | 944.79 | 922.91 | -2.32
> RotateBenchmark.testRotateRightL | 128.00 | 15.00 | 3742.44 | 3748.41 | 0.16 | 3788.07 | 3570.67 | -5.74
> RotateBenchmark.testRotateRightL | 128.00 | 15.00 | 1817.53 | 1985.69 | 9.25 | 1892.38 | 1833.16 | -3.13
> RotateBenchmark.testRotateRightL | 128.00 | 15.00 | 941.03 | 952.68 | 1.24 | 915.79 | 910.21 | -0.61
> RotateBenchmark.testRotateRightL | 128.00 | 31.00 | 3649.48 | 3896.56 | 6.77 | 3637.59 | 3557.53 | -2.20
> RotateBenchmark.testRotateRightL | 128.00 | 31.00 | 1840.12 | 1997.19 | 8.54 | 1821.47 | 1799.82 | -1.19
> RotateBenchmark.testRotateRightL | 128.00 | 31.00 | 901.33 | 995.67 | 10.47 | 909.20 | 902.73 | -0.71
> RotateBenchmark.testRotateRightL | 256.00 | 7.00 | 5789.93 | 5960.54 | 2.95 | 5758.14 | 5736.30 | -0.38
> RotateBenchmark.testRotateRightL | 256.00 | 7.00 | 2963.20 | 3063.30 | 3.38 | 2943.48 | 2833.84 | -3.72
> RotateBenchmark.testRotateRightL | 256.00 | 7.00 | 1501.81 | 1510.23 | 0.56 | 1463.85 | 1462.26 | -0.11
> RotateBenchmark.testRotateRightL | 256.00 | 15.00 | 5870.05 | 5951.43 | 1.39 | 5794.74 | 5604.58 | -3.28
> RotateBenchmark.testRotateRightL | 256.00 | 15.00 | 2971.36 | 3047.00 | 2.55 | 2931.19 | 2907.30 | -0.82
> RotateBenchmark.testRotateRightL | 256.00 | 15.00 | 1473.97 | 1530.54 | 3.84 | 1473.45 | 1442.40 | -2.11
> RotateBenchmark.testRotateRightL | 256.00 | 31.00 | 5858.08 | 6080.49 | 3.80 | 5863.69 | 5549.85 | -5.35
> RotateBenchmark.testRotateRightL | 256.00 | 31.00 | 2916.24 | 3045.77 | 4.44 | 2981.59 | 2815.07 | -5.58
> RotateBenchmark.testRotateRightL | 256.00 | 31.00 | 1441.20 | 1531.56 | 6.27 | 1492.47 | 1473.25 | -1.29
> RotateBenchmark.testRotateRightL | 512.00 | 7.00 | 8147.24 | 8310.05 | 2.00 | 469.45 | 1235.21 | 163.12
> RotateBenchmark.testRotateRightL | 512.00 | 7.00 | 4142.95 | 4258.86 | 2.80 | 234.14 | 615.52 | 162.88
> RotateBenchmark.testRotateRightL | 512.00 | 7.00 | 2095.48 | 2087.20 | -0.40 | 113.55 | 311.19 | 174.05
> RotateBenchmark.testRotateRightL | 512.00 | 15.00 | 8222.94 | 8246.58 | 0.29 | 458.91 | 1244.32 | 171.15
> RotateBenchmark.testRotateRightL | 512.00 | 15.00 | 4160.04 | 4226.46 | 1.60 | 227.78 | 625.38 | 174.56
> RotateBenchmark.testRotateRightL | 512.00 | 15.00 | 2064.63 | 2162.44 | 4.74 | 113.27 | 314.15 | 177.36
> RotateBenchmark.testRotateRightL | 512.00 | 31.00 | 8157.94 | 8466.90 | 3.79 | 450.26 | 1221.90 | 171.37
> RotateBenchmark.testRotateRightL | 512.00 | 31.00 | 4039.74 | 4283.33 | 6.03 | 224.82 | 612.68 | 172.53
> RotateBenchmark.testRotateRightL | 512.00 | 31.00 | 2066.88 | 2147.51 | 3.90 | 110.97 | 303.43 | 173.42
> RotateBenchmark.testRotateRightS | 128.00 | 7.00 | 13548.39 | 13245.87 | -2.23 | 13490.93 | 13084.76 | -3.01
> RotateBenchmark.testRotateRightS | 128.00 | 7.00 | 7020.16 | 6768.85 | -3.58 | 6991.39 | 7044.32 | 0.76
> RotateBenchmark.testRotateRightS | 128.00 | 7.00 | 3550.50 | 3505.19 | -1.28 | 3507.12 | 3612.86 | 3.01
> RotateBenchmark.testRotateRightS | 128.00 | 15.00 | 13743.43 | 13325.44 | -3.04 | 13696.15 | 13255.80 | -3.22
> RotateBenchmark.testRotateRightS | 128.00 | 15.00 | 6856.02 | 6969.18 | 1.65 | 6886.29 | 6834.12 | -0.76
> RotateBenchmark.testRotateRightS | 128.00 | 15.00 | 3569.53 | 3492.76 | -2.15 | 3539.02 | 3470.02 | -1.95
> RotateBenchmark.testRotateRightS | 128.00 | 31.00 | 13704.18 | 13495.07 | -1.53 | 13649.14 | 13583.87 | -0.48
> RotateBenchmark.testRotateRightS | 128.00 | 31.00 | 7011.77 | 6953.93 | -0.82 | 6978.28 | 6740.30 | -3.41
> RotateBenchmark.testRotateRightS | 128.00 | 31.00 | 3591.62 | 3620.12 | 0.79 | 3502.04 | 3510.05 | 0.23
> RotateBenchmark.testRotateRightS | 256.00 | 7.00 | 21950.71 | 22113.60 | 0.74 | 21484.27 | 21596.64 | 0.52
> RotateBenchmark.testRotateRightS | 256.00 | 7.00 | 11616.88 | 11099.73 | -4.45 | 11188.29 | 10737.68 | -4.03
> RotateBenchmark.testRotateRightS | 256.00 | 7.00 | 5872.72 | 5579.12 | -5.00 | 5784.05 | 5454.57 | -5.70
> RotateBenchmark.testRotateRightS | 256.00 | 15.00 | 22017.83 | 20817.97 | -5.45 | 21934.65 | 21356.90 | -2.63
> RotateBenchmark.testRotateRightS | 256.00 | 15.00 | 11414.27 | 11044.86 | -3.24 | 11454.35 | 11140.34 | -2.74
> RotateBenchmark.testRotateRightS | 256.00 | 15.00 | 5786.64 | 5634.05 | -2.64 | 5724.93 | 5639.99 | -1.48
> RotateBenchmark.testRotateRightS | 256.00 | 31.00 | 21754.77 | 21466.01 | -1.33 | 21140.67 | 21970.03 | 3.92
> RotateBenchmark.testRotateRightS | 256.00 | 31.00 | 11676.46 | 11358.64 | -2.72 | 11204.90 | 11213.48 | 0.08
> RotateBenchmark.testRotateRightS | 256.00 | 31.00 | 5728.20 | 5772.49 | 0.77 | 5594.33 | 5544.25 | -0.90
> RotateBenchmark.testRotateRightS | 512.00 | 7.00 | 30247.03 | 30179.41 | -0.22 | 1538.75 | 3975.82 | 158.38
> RotateBenchmark.testRotateRightS | 512.00 | 7.00 | 15988.73 | 15621.42 | -2.30 | 776.04 | 1910.91 | 146.24
> RotateBenchmark.testRotateRightS | 512.00 | 7.00 | 8115.84 | 8025.28 | -1.12 | 389.12 | 984.46 | 152.99
> RotateBenchmark.testRotateRightS | 512.00 | 15.00 | 30110.91 | 30200.69 | 0.30 | 1532.49 | 3983.77 | 159.95
> RotateBenchmark.testRotateRightS | 512.00 | 15.00 | 15957.90 | 15690.73 | -1.67 | 774.90 | 1931.00 | 149.19
> RotateBenchmark.testRotateRightS | 512.00 | 15.00 | 8113.26 | 8037.93 | -0.93 | 391.90 | 965.53 | 146.37
> RotateBenchmark.testRotateRightS | 512.00 | 31.00 | 29816.97 | 29891.54 | 0.25 | 1538.12 | 3881.93 | 152.38
> RotateBenchmark.testRotateRightS | 512.00 | 31.00 | 15405.95 | 15619.17 | 1.38 | 762.49 | 1871.00 | 145.38
> RotateBenchmark.testRotateRightS | 512.00 | 31.00 | 7919.80 | 7957.35 | 0.47 | 393.63 | 972.49 | 147.06

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

  8266054: Formal argument name change to be more appropriate.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3720/files
  - new: https://git.openjdk.java.net/jdk/pull/3720/files/d26caa6a..51c930d7

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

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

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

From igraves at openjdk.java.net  Wed Jul 21 20:19:31 2021
From: igraves at openjdk.java.net (Ian Graves)
Date: Wed, 21 Jul 2021 20:19:31 GMT
Subject: RFR: 8214761: Bug in parallel Kahan summation implementation [v2]
In-Reply-To: <inWiS2IlqFmGWsJuVSn1NP2Rn7YoYlADJ-3JeI8pfEs=.d208e206-5d71-4a8f-99e0-800d159d0905@github.com>
References: <inWiS2IlqFmGWsJuVSn1NP2Rn7YoYlADJ-3JeI8pfEs=.d208e206-5d71-4a8f-99e0-800d159d0905@github.com>
Message-ID: <Bks_wWFKs6jddBmCuaCNnO3X1j9pQVuaK9G4vmDj__Y=.393742fc-4f38-4c64-8617-dd64d87cbcfa@github.com>

> 8214761: Bug in parallel Kahan summation implementation

Ian Graves has updated the pull request incrementally with three additional commits since the last revision:

 - Updates with more test coverage
 - stashing
 - Stashing

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4674/files
  - new: https://git.openjdk.java.net/jdk/pull/4674/files/d7fc3948..10b8dcda

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

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

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

From darcy at openjdk.java.net  Wed Jul 21 20:24:46 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 21 Jul 2021 20:24:46 GMT
Subject: RFR: 8199594: Add doc describing how (?x) ignores spaces in
 character classes
In-Reply-To: <nZMkehSmeX8-0XBaLVpBCUc8Kabl1RimMvWLrX6JOYc=.9d5f58a0-639a-489d-bf85-33cf9af615f2@github.com>
References: <nZMkehSmeX8-0XBaLVpBCUc8Kabl1RimMvWLrX6JOYc=.9d5f58a0-639a-489d-bf85-33cf9af615f2@github.com>
Message-ID: <6qPe_jAi4_5sqr3b7KdeE8lA3hUIXAot4kFEudddEG8=.45843cd7-e10d-4d35-a596-c7f526604666@github.com>

On Mon, 28 Jun 2021 20:50:42 GMT, Ian Graves <igraves at openjdk.org> wrote:

> 8199594: Add doc describing how (?x) ignores spaces in character classes

Marked as reviewed by darcy (Reviewer).

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

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

From prappo at openjdk.java.net  Wed Jul 21 20:24:46 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Wed, 21 Jul 2021 20:24:46 GMT
Subject: RFR: 8199594: Add doc describing how (?x) ignores spaces in
 character classes
In-Reply-To: <nZMkehSmeX8-0XBaLVpBCUc8Kabl1RimMvWLrX6JOYc=.9d5f58a0-639a-489d-bf85-33cf9af615f2@github.com>
References: <nZMkehSmeX8-0XBaLVpBCUc8Kabl1RimMvWLrX6JOYc=.9d5f58a0-639a-489d-bf85-33cf9af615f2@github.com>
Message-ID: <rp7KzUZaxUeJpwkRREu0liZtsYAGzynnMCwrKhY25t0=.1956d29a-83ae-466b-8afe-ea77456dfc25@github.com>

On Mon, 28 Jun 2021 20:50:42 GMT, Ian Graves <igraves at openjdk.org> wrote:

> 8199594: Add doc describing how (?x) ignores spaces in character classes

src/java.base/share/classes/java/util/regex/Pattern.java line 833:

> 831:      * <p> Comments mode can also be enabled via the embedded flag
> 832:      * expression&nbsp;{@code (?x)}.
> 833:      *

Nit: is this extra line necessary?

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

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

From naoto at openjdk.java.net  Wed Jul 21 20:33:45 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 21 Jul 2021 20:33:45 GMT
Subject: RFR: 8199594: Add doc describing how (?x) ignores spaces in
 character classes
In-Reply-To: <nZMkehSmeX8-0XBaLVpBCUc8Kabl1RimMvWLrX6JOYc=.9d5f58a0-639a-489d-bf85-33cf9af615f2@github.com>
References: <nZMkehSmeX8-0XBaLVpBCUc8Kabl1RimMvWLrX6JOYc=.9d5f58a0-639a-489d-bf85-33cf9af615f2@github.com>
Message-ID: <Lfv8ZMqyu-LMKj2Mo3wtDfffLsmvcfuhqesHEPuLVMg=.dc4616f7-10b8-45ca-bcde-c332892c515d@github.com>

On Mon, 28 Jun 2021 20:50:42 GMT, Ian Graves <igraves at openjdk.org> wrote:

> 8199594: Add doc describing how (?x) ignores spaces in character classes

Marked as reviewed by naoto (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4618

From iris at openjdk.java.net  Wed Jul 21 20:41:45 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Wed, 21 Jul 2021 20:41:45 GMT
Subject: RFR: 8199594: Add doc describing how (?x) ignores spaces in
 character classes
In-Reply-To: <nZMkehSmeX8-0XBaLVpBCUc8Kabl1RimMvWLrX6JOYc=.9d5f58a0-639a-489d-bf85-33cf9af615f2@github.com>
References: <nZMkehSmeX8-0XBaLVpBCUc8Kabl1RimMvWLrX6JOYc=.9d5f58a0-639a-489d-bf85-33cf9af615f2@github.com>
Message-ID: <oTguH9mF44WzVaJJIHBOvrhz4uzatH7IDg6EZY8XPzk=.0c3b6629-a9bb-455a-b4f4-a1d2a518628f@github.com>

On Mon, 28 Jun 2021 20:50:42 GMT, Ian Graves <igraves at openjdk.org> wrote:

> 8199594: Add doc describing how (?x) ignores spaces in character classes

Changes match corresponding, approved CSR.

-------------

Marked as reviewed by iris (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4618

From Bruno.Borges at microsoft.com  Wed Jul 21 20:46:31 2021
From: Bruno.Borges at microsoft.com (Bruno Borges)
Date: Wed, 21 Jul 2021 20:46:31 +0000
Subject: jpackage on MacOS - ./Contents/Contents/app/myapp.cfg file not found 
Message-ID: <MWHPR2101MB0873AF20AB2DA35EF9C8F9B585E39@MWHPR2101MB0873.namprd21.prod.outlook.com>

Hi all,

Been trying to use Java 16.0.1 to produce a PKG for the fx2048 [1] game, and the generated app-image comes with a binary launcher that tries to load the .cfg file from the wrong directory.

Anyone seen this problem?

fx2048.app/Contents/MacOS  master -> origin/master ?                                                                                                                                      1h59m  java:16.0.1
$ tree ../../../ -L 4
../../../
??? fx2048.app
    ??? Contents
        ??? Info.plist
        ??? MacOS
        ?   ??? fx2048
        ??? PkgInfo
        ??? Resources
        ?   ??? fx2048.icns
        ??? app
        ?   ??? fx2048.cfg
        ??? runtime
            ??? Contents

7 directories, 5 files

$ ./fx2048
Error opening "/Users/bruno/myprojects/fx2048/build/installers/fx2048.app/Contents/Contents/app/fx2048.cfg" file: No such file or directory

[1] http://github.com/brunoborges/fx2048

From andy.herrick at oracle.com  Wed Jul 21 20:57:02 2021
From: andy.herrick at oracle.com (Andy Herrick)
Date: Wed, 21 Jul 2021 16:57:02 -0400
Subject: jpackage on MacOS - ./Contents/Contents/app/myapp.cfg file not
 found
In-Reply-To: <MWHPR2101MB0873AF20AB2DA35EF9C8F9B585E39@MWHPR2101MB0873.namprd21.prod.outlook.com>
References: <MWHPR2101MB0873AF20AB2DA35EF9C8F9B585E39@MWHPR2101MB0873.namprd21.prod.outlook.com>
Message-ID: <e74aa584-12b9-32da-9269-cb6b13b76ee2@oracle.com>

Looks like an instance of: JDK-8260335 
<https://bugs.openjdk.java.net/browse/JDK-8260335> : [macos] Running app 
using relative path causes problems (fixed in jdk17 build b09)

you can try builds from https://jdk.java.net/17/ to confirm fix.

/Andy

On 7/21/2021 4:46 PM, Bruno Borges wrote:
> Hi all,
>
> Been trying to use Java 16.0.1 to produce a PKG for the fx2048 [1] game, and the generated app-image comes with a binary launcher that tries to load the .cfg file from the wrong directory.
>
> Anyone seen this problem?
>
> fx2048.app/Contents/MacOS  master -> origin/master ?                                                                                                                                      1h59m  java:16.0.1
> $ tree ../../../ -L 4
> ../../../
> ??? fx2048.app
>      ??? Contents
>          ??? Info.plist
>          ??? MacOS
>          ?   ??? fx2048
>          ??? PkgInfo
>          ??? Resources
>          ?   ??? fx2048.icns
>          ??? app
>          ?   ??? fx2048.cfg
>          ??? runtime
>              ??? Contents
>
> 7 directories, 5 files
>
> $ ./fx2048
> Error opening "/Users/bruno/myprojects/fx2048/build/installers/fx2048.app/Contents/Contents/app/fx2048.cfg" file: No such file or directory
>
> [1] http://github.com/brunoborges/fx2048

From igraves at openjdk.java.net  Wed Jul 21 21:25:18 2021
From: igraves at openjdk.java.net (Ian Graves)
Date: Wed, 21 Jul 2021 21:25:18 GMT
Subject: RFR: 8199594: Add doc describing how (?x) ignores spaces in
 character classes [v2]
In-Reply-To: <nZMkehSmeX8-0XBaLVpBCUc8Kabl1RimMvWLrX6JOYc=.9d5f58a0-639a-489d-bf85-33cf9af615f2@github.com>
References: <nZMkehSmeX8-0XBaLVpBCUc8Kabl1RimMvWLrX6JOYc=.9d5f58a0-639a-489d-bf85-33cf9af615f2@github.com>
Message-ID: <Tti-MHDQPN__VC3i2lXZmx9RHLxAeiXKHn445901ufo=.e8e88e2d-2271-4eab-a904-5bc647f6d405@github.com>

> 8199594: Add doc describing how (?x) ignores spaces in character classes

Ian Graves has updated the pull request incrementally with one additional commit since the last revision:

  delete errant line

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4618/files
  - new: https://git.openjdk.java.net/jdk/pull/4618/files/07ea6f0f..11bafe80

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4618&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4618&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4618.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4618/head:pull/4618

PR: https://git.openjdk.java.net/jdk/pull/4618

From lancea at openjdk.java.net  Wed Jul 21 21:32:54 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Wed, 21 Jul 2021 21:32:54 GMT
Subject: RFR: 8199594: Add doc describing how (?x) ignores spaces in
 character classes [v2]
In-Reply-To: <Tti-MHDQPN__VC3i2lXZmx9RHLxAeiXKHn445901ufo=.e8e88e2d-2271-4eab-a904-5bc647f6d405@github.com>
References: <nZMkehSmeX8-0XBaLVpBCUc8Kabl1RimMvWLrX6JOYc=.9d5f58a0-639a-489d-bf85-33cf9af615f2@github.com>
 <Tti-MHDQPN__VC3i2lXZmx9RHLxAeiXKHn445901ufo=.e8e88e2d-2271-4eab-a904-5bc647f6d405@github.com>
Message-ID: <6LoGHpdE90nLgq3dLOCD82FbNIEBBWaBbgqIIP6XRfs=.8f7a6a63-b08f-40da-b9cb-ff7dbcf89b00@github.com>

On Wed, 21 Jul 2021 21:25:18 GMT, Ian Graves <igraves at openjdk.org> wrote:

>> 8199594: Add doc describing how (?x) ignores spaces in character classes
>
> Ian Graves has updated the pull request incrementally with one additional commit since the last revision:
> 
>   delete errant line

src/java.base/share/classes/java/util/regex/Pattern.java line 758:

> 756:  *    group just as in Perl.  </p></li>
> 757:  *
> 758:  *    <li><p> In Perl, <i>free-spacing mode</i> (which is called <i>comments

Looks good overall, one suggestion is to perhaps re-phrase the opening of the paragraph as the preceding  paragraph also starts with "In-Perl".

-------------

PR: https://git.openjdk.java.net/jdk/pull/4618

From igraves at openjdk.java.net  Wed Jul 21 21:32:55 2021
From: igraves at openjdk.java.net (Ian Graves)
Date: Wed, 21 Jul 2021 21:32:55 GMT
Subject: RFR: 8199594: Add doc describing how (?x) ignores spaces in
 character classes [v2]
In-Reply-To: <rp7KzUZaxUeJpwkRREu0liZtsYAGzynnMCwrKhY25t0=.1956d29a-83ae-466b-8afe-ea77456dfc25@github.com>
References: <nZMkehSmeX8-0XBaLVpBCUc8Kabl1RimMvWLrX6JOYc=.9d5f58a0-639a-489d-bf85-33cf9af615f2@github.com>
 <rp7KzUZaxUeJpwkRREu0liZtsYAGzynnMCwrKhY25t0=.1956d29a-83ae-466b-8afe-ea77456dfc25@github.com>
Message-ID: <YFNmXRMWDF1-nQpkoTsGPkwBMb4bBwaN0N1xABppDkk=.0f8b7a2f-a063-4672-8cc3-a412a7479f03@github.com>

On Wed, 21 Jul 2021 20:22:04 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Ian Graves has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   delete errant line
>
> src/java.base/share/classes/java/util/regex/Pattern.java line 833:
> 
>> 831:      * <p> Comments mode can also be enabled via the embedded flag
>> 832:      * expression&nbsp;{@code (?x)}.
>> 833:      *
> 
> Nit: is this extra line necessary?

Nope! Deleted.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4618

From hboehm at google.com  Wed Jul 21 21:54:58 2021
From: hboehm at google.com (Hans Boehm)
Date: Wed, 21 Jul 2021 14:54:58 -0700
Subject: JNI WeakGlobalRefs
Message-ID: <CAMOCf+isqt=NAEHfQBgW-ZgEyfYxZWDvAcnpdiO+oDx3zVCUbA@mail.gmail.com>

Is this an appropriate list to discuss JNI?

I'm concerned that the current semantics of JNI WeakGlobalRefs are still
dangerous in a very subtle way that is hidden in the spec. The current
(14+) spec says:

?Weak global references are related to Java phantom references
(java.lang.ref.PhantomReference). A weak global reference to a specific
object is treated as a phantom reference referring to that object when
determining whether the object is phantom reachable (see java.lang.ref).
---> Such a weak global reference will become functionally equivalent to
NULL at the same time as a PhantomReference referring to that same object
would be cleared by the garbage collector. <---?

(This was the result of JDK-8220617, and is IMO a large improvement over
the prior version, but ...)

Consider what happens if I have a WeakGlobalRef W that refers to a Java
object A which, possibly indirectly, relies on an object F, where F is
finalizable, i.e.

W - - -> A -----> ... -----> F

Assume that F becomes invalid once it is finalized, e.g. because the
finalizer deallocates a native object that F relies on. This seems to be a
very common case. We are then exposed to the following scenario:

0) At some point, there are no longer any other references to A or F.
1) F is enqueued for finalization.
2) W is dereferenced by Thread 1, yielding a strong reference to A and
transitively to F.
3) F is finalized.
4) Thread 1 uses A and F, accessing F, which is no longer valid.
5) Crash, or possibly memory corruption followed by a later crash elsewhere.

(3) and (4) actually race, so there is some synchronization effort and cost
required to prevent F from corrupting memory. Commonly the implementer of W
will have no idea that F even exists.

I believe that typically there is no way to prevent this scenario, unless
the developer adding W actually knows how every class that A could possibly
rely on, including those in the Java standard library, are implemented.

This is reminiscent of finalizer ordering issues. But it seems to be worse,
in that there isn't even a semi-plausible workaround.

I believe all of this is exactly the reason PhantomReference.get() always
returns null, while WeakReference provides significantly different
semantics, and WeakReferences are enqueued when an object is enqueued for
finalization.

The situation improves, but the problem doesn't fully disappear, in a
hypothetical world without finalizers. It's still possible to use
WeakGlobalRef to get a strong reference to A after a WeakReference to A has
been cleared and enqueued. I think the problem does go away if all cleanup
code were to use PhantomReference-based Cleaners.

AFAICT, backward-compatibility aside, the obvious solution here is to have
WeakGlobalRefs behave like WeakReferences. My impression is that this would
fix significantly more broken clients than it would break correct ones, so
it is arguably still a viable option.

There is a case in which the current semantics are actually the desired
ones, namely when implementing, say, a String intern table. In this case
it's important the reference not be cleared even if the referent is, at
some point, only reachable via a finalizer. But this use case again relies
on the programmer knowing that no part of the referent is invalidated by a
finalizer. That's a reasonable assumption for the
Java-implementation-provided String intern table. But I'm not sure it's
reasonable for any user-written code.

There seem to be two ways forward here:

1) Make WeakGlobalRefs behave like WeakReferences instead of
PhantomReferences, or
2) Add strong warnings to the spec that basically suggest using a strong
GlobalRef to a WeakReference instead.

Has there been prior discussion of this? Are there reasonable use cases for
the current semantics? Is there something else that I'm overlooking? If
not, what's the best way forward here?

(I found some discussion from JDK-8220617, including a message I posted.
Unfortunately, it seems to me that all of us overlooked this issue?)

Hans

From mik3hall at gmail.com  Wed Jul 21 21:57:04 2021
From: mik3hall at gmail.com (Michael Hall)
Date: Wed, 21 Jul 2021 16:57:04 -0500
Subject: jpackage on MacOS - ./Contents/Contents/app/myapp.cfg file not
 found
In-Reply-To: <e74aa584-12b9-32da-9269-cb6b13b76ee2@oracle.com>
References: <MWHPR2101MB0873AF20AB2DA35EF9C8F9B585E39@MWHPR2101MB0873.namprd21.prod.outlook.com>
 <e74aa584-12b9-32da-9269-cb6b13b76ee2@oracle.com>
Message-ID: <A05A8BC7-3597-4FE2-A649-34947F3F38B5@gmail.com>



> On Jul 21, 2021, at 3:57 PM, Andy Herrick <andy.herrick at oracle.com> wrote:
> 
> Looks like an instance of: JDK-8260335 <https://bugs.openjdk.java.net/browse/JDK-8260335> : [macos] Running app using relative path causes problems (fixed in jdk17 build b09)
> 
> you can try builds from https://jdk.java.net/17/ to confirm fix.
> 
> /Andy
> 
> On 7/21/2021 4:46 PM, Bruno Borges wrote:
>> Hi all,
>> 
>> Been trying to use Java 16.0.1 to produce a PKG for the fx2048 [1] game, and the generated app-image comes with a binary launcher that tries to load the .cfg file from the wrong directory.
>> 
>> 
>>         ??? PkgInfo

Somewhat off-topic. I hadn't noticed that PkgInfo was included on my applications? It used to have creator/type OSType?s needed for AppleEvent?s to work properly but since creator/type are pretty much out of use I thought PkgInfo was too?


From david.holmes at oracle.com  Wed Jul 21 22:25:06 2021
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 22 Jul 2021 08:25:06 +1000
Subject: JNI WeakGlobalRefs
In-Reply-To: <CAMOCf+isqt=NAEHfQBgW-ZgEyfYxZWDvAcnpdiO+oDx3zVCUbA@mail.gmail.com>
References: <CAMOCf+isqt=NAEHfQBgW-ZgEyfYxZWDvAcnpdiO+oDx3zVCUbA@mail.gmail.com>
Message-ID: <ed8070fe-c877-3445-595b-76f635d53e49@oracle.com>

Hi Hans,

On 22/07/2021 7:54 am, Hans Boehm wrote:
> Is this an appropriate list to discuss JNI?

No - hotspot-dev (to get runtime and GC folk) is the place to discuss JNI.

Thanks,
David

> I'm concerned that the current semantics of JNI WeakGlobalRefs are still
> dangerous in a very subtle way that is hidden in the spec. The current
> (14+) spec says:
> 
> ?Weak global references are related to Java phantom references
> (java.lang.ref.PhantomReference). A weak global reference to a specific
> object is treated as a phantom reference referring to that object when
> determining whether the object is phantom reachable (see java.lang.ref).
> ---> Such a weak global reference will become functionally equivalent to
> NULL at the same time as a PhantomReference referring to that same object
> would be cleared by the garbage collector. <---?
> 
> (This was the result of JDK-8220617, and is IMO a large improvement over
> the prior version, but ...)
> 
> Consider what happens if I have a WeakGlobalRef W that refers to a Java
> object A which, possibly indirectly, relies on an object F, where F is
> finalizable, i.e.
> 
> W - - -> A -----> ... -----> F
> 
> Assume that F becomes invalid once it is finalized, e.g. because the
> finalizer deallocates a native object that F relies on. This seems to be a
> very common case. We are then exposed to the following scenario:
> 
> 0) At some point, there are no longer any other references to A or F.
> 1) F is enqueued for finalization.
> 2) W is dereferenced by Thread 1, yielding a strong reference to A and
> transitively to F.
> 3) F is finalized.
> 4) Thread 1 uses A and F, accessing F, which is no longer valid.
> 5) Crash, or possibly memory corruption followed by a later crash elsewhere.
> 
> (3) and (4) actually race, so there is some synchronization effort and cost
> required to prevent F from corrupting memory. Commonly the implementer of W
> will have no idea that F even exists.
> 
> I believe that typically there is no way to prevent this scenario, unless
> the developer adding W actually knows how every class that A could possibly
> rely on, including those in the Java standard library, are implemented.
> 
> This is reminiscent of finalizer ordering issues. But it seems to be worse,
> in that there isn't even a semi-plausible workaround.
> 
> I believe all of this is exactly the reason PhantomReference.get() always
> returns null, while WeakReference provides significantly different
> semantics, and WeakReferences are enqueued when an object is enqueued for
> finalization.
> 
> The situation improves, but the problem doesn't fully disappear, in a
> hypothetical world without finalizers. It's still possible to use
> WeakGlobalRef to get a strong reference to A after a WeakReference to A has
> been cleared and enqueued. I think the problem does go away if all cleanup
> code were to use PhantomReference-based Cleaners.
> 
> AFAICT, backward-compatibility aside, the obvious solution here is to have
> WeakGlobalRefs behave like WeakReferences. My impression is that this would
> fix significantly more broken clients than it would break correct ones, so
> it is arguably still a viable option.
> 
> There is a case in which the current semantics are actually the desired
> ones, namely when implementing, say, a String intern table. In this case
> it's important the reference not be cleared even if the referent is, at
> some point, only reachable via a finalizer. But this use case again relies
> on the programmer knowing that no part of the referent is invalidated by a
> finalizer. That's a reasonable assumption for the
> Java-implementation-provided String intern table. But I'm not sure it's
> reasonable for any user-written code.
> 
> There seem to be two ways forward here:
> 
> 1) Make WeakGlobalRefs behave like WeakReferences instead of
> PhantomReferences, or
> 2) Add strong warnings to the spec that basically suggest using a strong
> GlobalRef to a WeakReference instead.
> 
> Has there been prior discussion of this? Are there reasonable use cases for
> the current semantics? Is there something else that I'm overlooking? If
> not, what's the best way forward here?
> 
> (I found some discussion from JDK-8220617, including a message I posted.
> Unfortunately, it seems to me that all of us overlooked this issue?)
> 
> Hans
> 

From Bruno.Borges at microsoft.com  Wed Jul 21 23:01:45 2021
From: Bruno.Borges at microsoft.com (Bruno Borges)
Date: Wed, 21 Jul 2021 23:01:45 +0000
Subject: [EXTERNAL] Re: jpackage on MacOS -
 ./Contents/Contents/app/myapp.cfg file not found
In-Reply-To: <e74aa584-12b9-32da-9269-cb6b13b76ee2@oracle.com>
References: <MWHPR2101MB0873AF20AB2DA35EF9C8F9B585E39@MWHPR2101MB0873.namprd21.prod.outlook.com>,
 <e74aa584-12b9-32da-9269-cb6b13b76ee2@oracle.com>
Message-ID: <MWHPR2101MB087349B898509D27022FF74C85E39@MWHPR2101MB0873.namprd21.prod.outlook.com>

Thanks Andy.

The issue regarding .cfg file not being found is indeed fixed in 17, and solves this particular problem I found.

From: core-libs-dev <core-libs-dev-retn at openjdk.java.net> on behalf of Andy Herrick <andy.herrick at oracle.com>
Date: Wednesday, July 21, 2021 at 1:57 PM
To: core-libs-dev at openjdk.java.net <core-libs-dev at openjdk.java.net>
Subject: [EXTERNAL] Re: jpackage on MacOS - ./Contents/Contents/app/myapp.cfg file not found
Looks like an instance of: JDK-8260335
<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8260335&amp;data=04%7C01%7Cbruno.borges%40microsoft.com%7C9b29c0dfcd6d45f58cc908d94c8a3229%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637624978703359720%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=Ifc5MP7qZj58mnEm5QjRarJqVWPKC%2B3%2BBhOuJLuYV7I%3D&amp;reserved=0> : [macos] Running app
using relative path causes problems (fixed in jdk17 build b09)

you can try builds from https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjdk.java.net%2F17%2F&amp;data=04%7C01%7Cbruno.borges%40microsoft.com%7C9b29c0dfcd6d45f58cc908d94c8a3229%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637624978703359720%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=pGwCWe9IBiVKhZCVMpFo1OZJLSyFVfQJODpKQ%2B6fby8%3D&amp;reserved=0 to confirm fix.

/Andy

On 7/21/2021 4:46 PM, Bruno Borges wrote:
> Hi all,
>
> Been trying to use Java 16.0.1 to produce a PKG for the fx2048 [1] game, and the generated app-image comes with a binary launcher that tries to load the .cfg file from the wrong directory.
>
> Anyone seen this problem?
>
> fx2048.app/Contents/MacOS  master -> origin/master ?                                                                                                                                      1h59m  java:16.0.1
> $ tree ../../../ -L 4
> ../../../
> ??? fx2048.app
>      ??? Contents
>          ??? Info.plist
>          ??? MacOS
>          ?   ??? fx2048
>          ??? PkgInfo
>          ??? Resources
>          ?   ??? fx2048.icns
>          ??? app
>          ?   ??? fx2048.cfg
>          ??? runtime
>              ??? Contents
>
> 7 directories, 5 files
>
> $ ./fx2048
> Error opening "/Users/bruno/myprojects/fx2048/build/installers/fx2048.app/Contents/Contents/app/fx2048.cfg" file: No such file or directory
>
> [1] https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgithub.com%2Fbrunoborges%2Ffx2048&amp;data=04%7C01%7Cbruno.borges%40microsoft.com%7C9b29c0dfcd6d45f58cc908d94c8a3229%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637624978703359720%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=t8txGpyO7cA9TuIY%2FcsPt4zXN2WmRrsTwJD7rQaC4%2F4%3D&amp;reserved=0

From jwilhelm at openjdk.java.net  Thu Jul 22 00:02:23 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Thu, 22 Jul 2021 00:02:23 GMT
Subject: RFR: Merge jdk17
Message-ID: <EyjzhDedbKuTrHsbgwBAv7Q3cDRnmZ9pv_zR_rRzdZg=.779ee90b-0a77-413a-95b2-6f85d77296c4@github.com>

Forwardport JDK 17 -> JDK 18

-------------

Commit messages:
 - Merge
 - 8266347: assert(Dependencies::is_concrete_root_method(fm, ctxk) == Dependencies::is_concrete_method(m, ctxk)) failed: mismatch
 - 8264066: Enhance compiler validation
 - 8265201: JarFile.getInputStream not validating invalid signed jars
 - 8258432: Improve File Transfers
 - 8264079: Improve abstractions
 - 8262380: Enhance XML processing passes
 - 8262967: Improve Zip file support
 - 8264460: Improve NTLM support
 - 8256491: Better HTTP transport
 - ... and 10 more: https://git.openjdk.java.net/jdk/compare/0790f04d...025eaefb

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=4863&range=00.0
 - jdk17: https://webrevs.openjdk.java.net/?repo=jdk&pr=4863&range=00.1

Changes: https://git.openjdk.java.net/jdk/pull/4863/files
  Stats: 517 lines in 33 files changed: 403 ins; 34 del; 80 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4863.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4863/head:pull/4863

PR: https://git.openjdk.java.net/jdk/pull/4863

From jwilhelm at openjdk.java.net  Thu Jul 22 00:51:37 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Thu, 22 Jul 2021 00:51:37 GMT
Subject: RFR: Merge jdk17 [v2]
In-Reply-To: <EyjzhDedbKuTrHsbgwBAv7Q3cDRnmZ9pv_zR_rRzdZg=.779ee90b-0a77-413a-95b2-6f85d77296c4@github.com>
References: <EyjzhDedbKuTrHsbgwBAv7Q3cDRnmZ9pv_zR_rRzdZg=.779ee90b-0a77-413a-95b2-6f85d77296c4@github.com>
Message-ID: <pAbckiZhttmfKUoxQWEPkJpNvzyNGo9c0VKlKeN929A=.b6e0fb04-aa73-4174-aa51-0b7eecf86564@github.com>

> Forwardport JDK 17 -> JDK 18

Jesper Wilhelmsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 282 commits:

 - Merge
 - 8271015: Split cds/SharedBaseAddress.java test into smaller parts
   
   Reviewed-by: ccheung, minqi
 - 8271014: Refactor HeapShared::is_archived_object()
   
   Reviewed-by: ccheung, minqi
 - 8270949: Make dynamically generated classes with the class file version of the current release
   
   Reviewed-by: alanb
 - 8269849: vmTestbase/gc/gctests/PhantomReference/phantom002/TestDescription.java failed with "OutOfMemoryError: Java heap space: failed reallocation of scalar replaced objects"
   
   Reviewed-by: kbarrett
 - 8270991: G1 Full GC always performs heap verification after JDK-8269295
   
   Reviewed-by: iwalulya, kbarrett
 - 8270820: remove unused stiFileTableIndex from SDE.c
   
   Reviewed-by: cjplummer, sspitsyn
 - 8270147: Increase stride size allowing unrolling more loops
   
   Reviewed-by: kvn, iveresov
 - 8270803: Reduce CDS API verbosity
   
   Reviewed-by: minqi, ccheung
 - 8269933: test/jdk/javax/net/ssl/compatibility/JdkInfo incorrect verification of protocol and cipher support
   
   Reviewed-by: xuelei, rhalade
 - ... and 272 more: https://git.openjdk.java.net/jdk/compare/89f7998a...025eaefb

-------------

Changes: https://git.openjdk.java.net/jdk/pull/4863/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4863&range=01
  Stats: 55988 lines in 1158 files changed: 26162 ins; 25130 del; 4696 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4863.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4863/head:pull/4863

PR: https://git.openjdk.java.net/jdk/pull/4863

From jwilhelm at openjdk.java.net  Thu Jul 22 00:51:38 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Thu, 22 Jul 2021 00:51:38 GMT
Subject: Integrated: Merge jdk17
In-Reply-To: <EyjzhDedbKuTrHsbgwBAv7Q3cDRnmZ9pv_zR_rRzdZg=.779ee90b-0a77-413a-95b2-6f85d77296c4@github.com>
References: <EyjzhDedbKuTrHsbgwBAv7Q3cDRnmZ9pv_zR_rRzdZg=.779ee90b-0a77-413a-95b2-6f85d77296c4@github.com>
Message-ID: <uLKilEHqK1ophFqLcb19742sf7ShTcYaXP-yo8A0U-M=.04e4edb1-ff3b-406e-8a45-9bc01771a05b@github.com>

On Wed, 21 Jul 2021 23:52:53 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 17 -> JDK 18

This pull request has now been integrated.

Changeset: c36755de
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c36755dedf1a0d7ce0aeadd401e0c70ff84185e7
Stats:     517 lines in 33 files changed: 403 ins; 34 del; 80 mod

Merge

-------------

PR: https://git.openjdk.java.net/jdk/pull/4863

From igraves at openjdk.java.net  Thu Jul 22 01:46:09 2021
From: igraves at openjdk.java.net (Ian Graves)
Date: Thu, 22 Jul 2021 01:46:09 GMT
Subject: RFR: 8199594: Add doc describing how (?x) ignores spaces in
 character classes [v3]
In-Reply-To: <nZMkehSmeX8-0XBaLVpBCUc8Kabl1RimMvWLrX6JOYc=.9d5f58a0-639a-489d-bf85-33cf9af615f2@github.com>
References: <nZMkehSmeX8-0XBaLVpBCUc8Kabl1RimMvWLrX6JOYc=.9d5f58a0-639a-489d-bf85-33cf9af615f2@github.com>
Message-ID: <MxS-oZAbpbzC7VQWxsYuSAgIm7jn_l1dB3_VlTR-Gd8=.417331e1-9304-4d1d-8934-5179b11d84ed@github.com>

> 8199594: Add doc describing how (?x) ignores spaces in character classes

Ian Graves has updated the pull request incrementally with one additional commit since the last revision:

  Rewording repetitive phrase

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4618/files
  - new: https://git.openjdk.java.net/jdk/pull/4618/files/11bafe80..521cddca

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4618&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4618&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4618.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4618/head:pull/4618

PR: https://git.openjdk.java.net/jdk/pull/4618

From igraves at openjdk.java.net  Thu Jul 22 01:46:10 2021
From: igraves at openjdk.java.net (Ian Graves)
Date: Thu, 22 Jul 2021 01:46:10 GMT
Subject: RFR: 8199594: Add doc describing how (?x) ignores spaces in
 character classes [v2]
In-Reply-To: <6LoGHpdE90nLgq3dLOCD82FbNIEBBWaBbgqIIP6XRfs=.8f7a6a63-b08f-40da-b9cb-ff7dbcf89b00@github.com>
References: <nZMkehSmeX8-0XBaLVpBCUc8Kabl1RimMvWLrX6JOYc=.9d5f58a0-639a-489d-bf85-33cf9af615f2@github.com>
 <Tti-MHDQPN__VC3i2lXZmx9RHLxAeiXKHn445901ufo=.e8e88e2d-2271-4eab-a904-5bc647f6d405@github.com>
 <6LoGHpdE90nLgq3dLOCD82FbNIEBBWaBbgqIIP6XRfs=.8f7a6a63-b08f-40da-b9cb-ff7dbcf89b00@github.com>
Message-ID: <l-sW5_VkYhui9QjXtW-tp2L4s4ki84GRJWQPAlI4pkc=.1fcdcefb-ecb5-4d30-ac12-68161e6c8da5@github.com>

On Wed, 21 Jul 2021 21:30:01 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Ian Graves has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   delete errant line
>
> src/java.base/share/classes/java/util/regex/Pattern.java line 758:
> 
>> 756:  *    group just as in Perl.  </p></li>
>> 757:  *
>> 758:  *    <li><p> In Perl, <i>free-spacing mode</i> (which is called <i>comments
> 
> Looks good overall, one suggestion is to perhaps re-phrase the opening of the paragraph as the preceding  paragraph also starts with "In-Perl".

Good idea. Re-worded to "Free-spacing mode in Perl (called comments..."

-------------

PR: https://git.openjdk.java.net/jdk/pull/4618

From github.com+1701815+mkarg at openjdk.java.net  Thu Jul 22 05:54:51 2021
From: github.com+1701815+mkarg at openjdk.java.net (Markus KARG)
Date: Thu, 22 Jul 2021 05:54:51 GMT
Subject: RFR: 8265891: (ch) InputStream returned by
 Channels.newInputStream should override transferTo [v3]
In-Reply-To: <aS5i72i7KLnTndIFIA_94OUjEgyuwXiHDHu1H898QtE=.0fcdd01c-2219-4318-86d7-8826941b6f41@github.com>
References: <XlU5gCBUEa4qTTz8yhMeElh95FuiPcFYQ_nj_WYvbLE=.6e9fc6a4-f3b1-4faf-91f0-d8b06f875780@github.com>
 <aS5i72i7KLnTndIFIA_94OUjEgyuwXiHDHu1H898QtE=.0fcdd01c-2219-4318-86d7-8826941b6f41@github.com>
Message-ID: <5JT_y4R4xZAA8CgrqeCsxrlbDkn2Q8817kyRymvn4F8=.e200a0b0-67e4-4742-97df-2c71000bc0c2@github.com>

On Fri, 2 Jul 2021 06:20:29 GMT, Markus KARG <github.com+1701815+mkarg at openjdk.org> wrote:

>> This PR-*draft* is **work in progress** and an invitation to discuss a possible solution for issue [JDK-8265891](https://bugs.openjdk.java.net/browse/JDK-8265891). It is *not yet* intended for a final review.
>> 
>> As proposed in JDK-8265891, this PR provides an implementation for `Channels.newInputStream().transferTo()` which provide superior performance compared to the current implementation. The changes are:
>> * Prevents transfers through the JVM heap as much as possibly by offloading to deeper levels via NIO, hence allowing the operating system to optimize the transfer.
>> * Using more JRE heap in the fallback case when no NIO is possible (still only KiBs, hence mostl ynegligible even on SBCs) to better perform on modern hardware / fast I/O devides.
>> 
>> Using JMH I have benchmarked both, the original implementation and this implementation, and (depending on the used hardware and use case) performance change was approx. doubled performance. So this PoC proofs that it makes sense to finalize this work and turn it into an actual OpenJDK contribution. 
>> 
>> I encourage everybody to discuss this draft:
>> * Are there valid arguments for *not* doing this change?
>> * Is there a *better* way to improve performance of `Channels.newInputStream().transferTo()`?
>> * How to go on from here: What is missing to get this ready for an actual review?
>
> Markus KARG 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:
> 
>   Draft: Renaming i and separating code into several methods
>   
>   Signed-off-by: Markus Karg <markus at headcrashing.eu>

Understood. Work is in progress. Stay tuned.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4263

From alanb at openjdk.java.net  Thu Jul 22 08:30:52 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 22 Jul 2021 08:30:52 GMT
Subject: RFR: 8260265: UTF-8 by Default [v6]
In-Reply-To: <YKdP2Z56gvAlrdfZWOVlcbIC5Poc4ObXlijbsUhBsmw=.704f808f-2f0a-4876-b4c1-c5b9a74bcae6@github.com>
References: <-F4rYMOBcR8vg_mtYrJ--Ovx9d5bDLTF2p40uV5QqMM=.9cfd49ad-be84-4455-9695-138203395b21@github.com>
 <YKdP2Z56gvAlrdfZWOVlcbIC5Poc4ObXlijbsUhBsmw=.704f808f-2f0a-4876-b4c1-c5b9a74bcae6@github.com>
Message-ID: <BAmtZs5zg3x8mJ-mygrHT8puNVZjSeW9jLwp7mYN3QI=.41a22a56-b512-4d27-95b3-30bdd3bb1141@github.com>

On Wed, 21 Jul 2021 17:34:15 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is an implementation for the `JEP 400: UTF-8 by Default`. The gist of the changes is `Charset.defaultCharset()` returning `UTF-8` and `file.encoding` system property being added in the spec, but another notable modification is in `java.io.PrintStream` where it continues to use the `Console` encoding as the default charset instead of `UTF-8`. Other changes are mostly clarification of the term "default charset" and their links. Corresponding CSR has also been drafted.
>> 
>> JEP 400: https://bugs.openjdk.java.net/browse/JDK-8187041
>> CSR: https://bugs.openjdk.java.net/browse/JDK-8260266
>
> 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 JDK-8260265
>  - Refined `file.encoding` description
>  - Merge branch 'master' into JDK-8260265
>  - Reflects comments
>  - Removed leftover `console` references in `PrintStream`
>  - Reflects comments
>  - Reflects review comments
>  - Merge branch 'master' into JDK-8260265
>  - 8260265: UTF-8 by Default

Thanks for incorporating the suggestion for the getProperties text. I think it looks good now.

-------------

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4733

From mbaesken at openjdk.java.net  Thu Jul 22 12:18:36 2021
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Thu, 22 Jul 2021 12:18:36 GMT
Subject: RFR: JDK-8266490: Extend the OSContainer API to support the pids
 controller of cgroups [v5]
In-Reply-To: <WIJ8PVBUx3qqQx0DJIzdaXdsj_iaPVM7PBINpO5F-O4=.7a5df000-3728-46d6-b344-2f9a4ce53bc2@github.com>
References: <MWenVRe4ptn5aua0DUHvxb-sdbu-Ykl9x0GlhmxKHhY=.1fb8901e-36c3-4c07-a6ed-b653120807de@github.com>
 <WIJ8PVBUx3qqQx0DJIzdaXdsj_iaPVM7PBINpO5F-O4=.7a5df000-3728-46d6-b344-2f9a4ce53bc2@github.com>
Message-ID: <5U29-7MNu_hZ-zKgsFUKj656igVcq-0h3kq-EASNU_M=.2881b609-4712-49b7-8f4f-fb447b94c2eb@github.com>

On Fri, 16 Jul 2021 06:14:07 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Hello, please review this PR; it extend the OSContainer API in order to also support the pids controller of cgroups.
>> 
>> I noticed that unlike the other controllers "cpu", "cpuset", "cpuacct", "memory"  on some older Linux distros (SLES 12.1, RHEL 7.1) the pids controller might not be there (or not fully supported) so it was added as optional  , see the coding
>> 
>> 
>>   if (!cg_infos[PIDS_IDX]._data_complete) {
>>     log_debug(os, container)("Optional cgroup v1 pids subsystem not found");
>>     // keep the other controller info, pids is optional
>>   }
>
> Matthias Baesken has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/master' into JDK-8266490
>  - Add hotspot tests
>  - test and small adjustments suggested by Severin
>  - Adjustments following Severins comments
>  - JDK-8266490

Hi Severin, thanks for the comments. I added a commit with a number of adjustments 

src/hotspot/os/linux/cgroupSubsystem_linux.cpp
adjusted log_info to log_debug

src/java.base/share/classes/sun/launcher/LauncherHelper.java
adjusted the output to "Maximum Processes Limit:"

test/hotspot/jtreg/containers/docker/CheckOperatingSystemMXBean.java
removed the getPidsMax related line (I think I inserted it while running some tests and forgot previously to remove it)

test/hotspot/jtreg/containers/docker/TestPids.java
added testing of "Unlimited"; added  --pids-limit=-1  for  Unlimited procs like you suggested

test/jdk/jdk/internal/platform/docker/TestPidsLimit.java
adjusted output; added  --pids-limit=-1  for  Unlimited procs like you suggested

-------------

PR: https://git.openjdk.java.net/jdk/pull/4518

From mbaesken at openjdk.java.net  Thu Jul 22 12:18:20 2021
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Thu, 22 Jul 2021 12:18:20 GMT
Subject: RFR: JDK-8266490: Extend the OSContainer API to support the pids
 controller of cgroups [v6]
In-Reply-To: <MWenVRe4ptn5aua0DUHvxb-sdbu-Ykl9x0GlhmxKHhY=.1fb8901e-36c3-4c07-a6ed-b653120807de@github.com>
References: <MWenVRe4ptn5aua0DUHvxb-sdbu-Ykl9x0GlhmxKHhY=.1fb8901e-36c3-4c07-a6ed-b653120807de@github.com>
Message-ID: <g4NiARIHx5BTgvq6uoi9LqqcJRkJT2NiK_-qMrrv-H0=.bbbf85f5-8da9-467a-b5e0-b47bc8b73172@github.com>

> Hello, please review this PR; it extend the OSContainer API in order to also support the pids controller of cgroups.
> 
> I noticed that unlike the other controllers "cpu", "cpuset", "cpuacct", "memory"  on some older Linux distros (SLES 12.1, RHEL 7.1) the pids controller might not be there (or not fully supported) so it was added as optional  , see the coding
> 
> 
>   if (!cg_infos[PIDS_IDX]._data_complete) {
>     log_debug(os, container)("Optional cgroup v1 pids subsystem not found");
>     // keep the other controller info, pids is optional
>   }

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  Minor adjustments, handling of Unlimited

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4518/files
  - new: https://git.openjdk.java.net/jdk/pull/4518/files/5fc52fb1..857ab1db

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4518&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4518&range=04-05

  Stats: 19 lines in 5 files changed: 11 ins; 1 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4518.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4518/head:pull/4518

PR: https://git.openjdk.java.net/jdk/pull/4518

From jpai at openjdk.java.net  Thu Jul 22 12:55:46 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Thu, 22 Jul 2021 12:55:46 GMT
Subject: RFR: 8190753: (zipfs): Accessing a large entry (> 2^31 bytes)
 leads to a negative initial size for ByteArrayOutputStream [v8]
In-Reply-To: <qvx7-anm29qNq_xfUfYTP0_8Me5pKoFnXSceloKS-9c=.d12bf1e3-5ead-45b9-bd6a-908a9b798e2f@github.com>
References: <0GJVLeCPoDI4FePU-Z-NMwJHaS2XyH9S28LgqI1LNB8=.e32743dc-a6dd-475d-88ab-16ed3f46beab@github.com>
 <ehuksZQILsWLXcuvxgtRGIq7Lqwl146QQpIVHanMoIs=.9cad7f15-24b8-4bf6-99db-cbf3ef3cccbf@github.com>
 <ConvQJ7XdR_kfz0T9BDkYlZ4l05w65o8i_bulHcdAxM=.ccd7e23a-dea4-44c0-a183-aa98ec31f955@github.com>
 <tYUfVXrSQR82OGRtYohP_1ieRkMgLrcniUksThnWFc0=.f709ca9d-9918-4de0-a5c4-1b011fd07f89@github.com>
 <qvx7-anm29qNq_xfUfYTP0_8Me5pKoFnXSceloKS-9c=.d12bf1e3-5ead-45b9-bd6a-908a9b798e2f@github.com>
Message-ID: <uG2wyFCNIlm-GSa3kAEEEj_MamETPOwZS9oSilafOw8=.09d1b5d4-17c2-468a-bec3-2d1853c717c1@github.com>

On Wed, 21 Jul 2021 04:09:23 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> > > For some context - the new `FileRolloverOutputStream` extends `ByteArrayOutputStream` and hence cannot have a `throws IOException` in its overridden `write` methods.
> > 
> > 
> > Have you tried wrapping a BAOS rather than extending, that might allow the exception wrapping/unwapping to go away.
> 
> Hello Alan,
> 
> I did experiment with it earlier, before going with the current approach in this PR. The disadvantage, as I see it, with wrapping a `ByteArrayOutputStream` instead of extending it is that when trying to rollover the contents to a file, you don't have access to the (inner protected) byte array of the ByteArrayOutputStream.
> 
> The rollover code would then look something like:
> 
> ```
> private void transferToFile() throws IOException {
>     // create a tempfile
>     entry.file = getTempPathForEntry(null);
>     // transfer the already written data from the byte array buffer into this tempfile
>     try (OutputStream os = new BufferedOutputStream(Files.newOutputStream(entry.file))) {
>         new ByteArrayInputStream(baos.toByteArray(), 0, baos.size()).transferTo(os);
>     }
>     // release the underlying byte array
>     baos = null;
>     // append any further data to the file with buffering enabled
>     tmpFileOS = new BufferedOutputStream(Files.newOutputStream(entry.file, APPEND));
> }
> ```
> 
> So although you can transfer the contents to the file without requiring the access to the byte array, you end up creating a new copy of that array (through the use of `baos.toByteArray()`), which can be at most 10MB in size. I thought avoiding a new copy of that (potentially 10MB) array during this transfer would be a good save and hence decided to settle on extending `ByteArrayOutputStream` instead of wrapping it.
> 
> The use of `extends` of course now means dealing with the `UncheckedIOException` as done in this PR. But if you think that the array copy isn't a concern and wrapping the `ByteArrayOutputStream` is a better way, then I'll go ahead and update this PR accordingly.

Now that the mailing lists integration seems to be back to normal, just adding this dummy comment to bring to attention the latest comments in this PR.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4607

From mik3hall at gmail.com  Thu Jul 22 14:01:03 2021
From: mik3hall at gmail.com (Michael Hall)
Date: Thu, 22 Jul 2021 09:01:03 -0500
Subject: jpackage OS/X JDK-8263157 fix regressed out
Message-ID: <9112F1A4-FFFB-4DD2-BC47-AC2F6E098F99@gmail.com>

JDK-8263157 <https://bugs.openjdk.java.net/browse/JDK-8263157> [macos]: java.library.path is being set incorrectly

The fix for this seems to be gone in both current jdk17 and jdk18 releases. There is no ?app? directory included in java.library.path.

outputdir/HalfPipe.app/Contents/runtime/Contents/Home/bin/java -version
openjdk version "18-ea" 2022-03-15
OpenJDK Runtime Environment (build 18-ea+6-237)
OpenJDK 64-Bit Server VM (build 18-ea+6-237, mixed mode)

outputdir/HalfPipe.app/Contents/MacOS/HalfPipe
Exception in thread "main" java.lang.UnsatisfiedLinkError: no hp in java.library.path: /opt/ooRexx/lib/ooRexx;/Users/mjh/HalfPipe/HalfPipe_jpkg/outputdir/HalfPipe.app/Contents/app:/Users/mjh/Library/Java/Extensions:/Library/Java/Extensions:/Network/Library/Java/Extensions:/System/Library/Java/Extensions:/usr/lib/java:.
	at java.base/java.lang.ClassLoader.loadLibrary(Unknown Source)
	at java.base/java.lang.Runtime.loadLibrary0(Unknown Source)
	at java.base/java.lang.System.loadLibrary(Unknown Source)
	at us.hall.hp.common.LoaderLaunchStub.<clinit>(LoaderLaunchStub.java:35)
Failed to launch JVM


From ecki at zusammenkunft.net  Thu Jul 22 15:24:39 2021
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Thu, 22 Jul 2021 15:24:39 +0000
Subject: RFR: 8190753: (zipfs): Accessing a large entry (> 2^31 bytes)
 leads to a negative initial size for ByteArrayOutputStream [v8]
In-Reply-To: <uG2wyFCNIlm-GSa3kAEEEj_MamETPOwZS9oSilafOw8=.09d1b5d4-17c2-468a-bec3-2d1853c717c1@github.com>
References: <0GJVLeCPoDI4FePU-Z-NMwJHaS2XyH9S28LgqI1LNB8=.e32743dc-a6dd-475d-88ab-16ed3f46beab@github.com>
 <ehuksZQILsWLXcuvxgtRGIq7Lqwl146QQpIVHanMoIs=.9cad7f15-24b8-4bf6-99db-cbf3ef3cccbf@github.com>
 <ConvQJ7XdR_kfz0T9BDkYlZ4l05w65o8i_bulHcdAxM=.ccd7e23a-dea4-44c0-a183-aa98ec31f955@github.com>
 <tYUfVXrSQR82OGRtYohP_1ieRkMgLrcniUksThnWFc0=.f709ca9d-9918-4de0-a5c4-1b011fd07f89@github.com>
 <qvx7-anm29qNq_xfUfYTP0_8Me5pKoFnXSceloKS-9c=.d12bf1e3-5ead-45b9-bd6a-908a9b798e2f@github.com>,
 <uG2wyFCNIlm-GSa3kAEEEj_MamETPOwZS9oSilafOw8=.09d1b5d4-17c2-468a-bec3-2d1853c717c1@github.com>
Message-ID: <AM0PR03MB4145C179362F192CF419E8E8FFE49@AM0PR03MB4145.eurprd03.prod.outlook.com>

Hello,

> So although you can transfer the contents to the file without requiring the access
> to the byte array, you end up creating a new copy of that array (through the use
> of `baos.toByteArray()`)

You can avoid the copy and the additional buffer with baos.writeTo() I think.

try (OutputStream os = Files.newOutputStream(entry.file)) { // maybe append?
    baos.writeTo(os);
}
// release the underlying byte array
baos = null;
// append any further data to the file with buffering enabled
tmpFileOS = new BufferedOutputStream(Files.newOutputStream(entry.file, APPEND));


--
http://bernd.eckenfels.net
________________________________
Von: nio-dev <nio-dev-retn at openjdk.java.net> im Auftrag von Jaikiran Pai <jpai at openjdk.java.net>
Gesendet: Thursday, July 22, 2021 2:55:46 PM
An: core-libs-dev at openjdk.java.net <core-libs-dev at openjdk.java.net>; nio-dev at openjdk.java.net <nio-dev at openjdk.java.net>
Betreff: Re: RFR: 8190753: (zipfs): Accessing a large entry (> 2^31 bytes) leads to a negative initial size for ByteArrayOutputStream [v8]

On Wed, 21 Jul 2021 04:09:23 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> > > For some context - the new `FileRolloverOutputStream` extends `ByteArrayOutputStream` and hence cannot have a `throws IOException` in its overridden `write` methods.
> >
> >
> > Have you tried wrapping a BAOS rather than extending, that might allow the exception wrapping/unwapping to go away.
>
> Hello Alan,
>
> I did experiment with it earlier, before going with the current approach in this PR. The disadvantage, as I see it, with wrapping a `ByteArrayOutputStream` instead of extending it is that when trying to rollover the contents to a file, you don't have access to the (inner protected) byte array of the ByteArrayOutputStream.
>
> The rollover code would then look something like:
>
> ```
> private void transferToFile() throws IOException {
>     // create a tempfile
>     entry.file = getTempPathForEntry(null);
>     // transfer the already written data from the byte array buffer into this tempfile
>     try (OutputStream os = new BufferedOutputStream(Files.newOutputStream(entry.file))) {
>         new ByteArrayInputStream(baos.toByteArray(), 0, baos.size()).transferTo(os);
>     }
>     // release the underlying byte array
>     baos = null;
>     // append any further data to the file with buffering enabled
>     tmpFileOS = new BufferedOutputStream(Files.newOutputStream(entry.file, APPEND));
> }
> ```
>
> So although you can transfer the contents to the file without requiring the access to the byte array, you end up creating a new copy of that array (through the use of `baos.toByteArray()`), which can be at most 10MB in size. I thought avoiding a new copy of that (potentially 10MB) array during this transfer would be a good save and hence decided to settle on extending `ByteArrayOutputStream` instead of wrapping it.
>
> The use of `extends` of course now means dealing with the `UncheckedIOException` as done in this PR. But if you think that the array copy isn't a concern and wrapping the `ByteArrayOutputStream` is a better way, then I'll go ahead and update this PR accordingly.

Now that the mailing lists integration seems to be back to normal, just adding this dummy comment to bring to attention the latest comments in this PR.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4607

From sgehwolf at openjdk.java.net  Thu Jul 22 15:42:01 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Thu, 22 Jul 2021 15:42:01 GMT
Subject: RFR: JDK-8266490: Extend the OSContainer API to support the pids
 controller of cgroups [v5]
In-Reply-To: <5U29-7MNu_hZ-zKgsFUKj656igVcq-0h3kq-EASNU_M=.2881b609-4712-49b7-8f4f-fb447b94c2eb@github.com>
References: <MWenVRe4ptn5aua0DUHvxb-sdbu-Ykl9x0GlhmxKHhY=.1fb8901e-36c3-4c07-a6ed-b653120807de@github.com>
 <WIJ8PVBUx3qqQx0DJIzdaXdsj_iaPVM7PBINpO5F-O4=.7a5df000-3728-46d6-b344-2f9a4ce53bc2@github.com>
 <5U29-7MNu_hZ-zKgsFUKj656igVcq-0h3kq-EASNU_M=.2881b609-4712-49b7-8f4f-fb447b94c2eb@github.com>
Message-ID: <VhXkWw747iLACzr_FbdqJaMi4FOl9hr2Mj0nkCQWDSE=.8e5e0632-0e17-4105-a4c4-e26b4fc22d8c@github.com>

On Thu, 22 Jul 2021 12:15:03 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Matthias Baesken has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'origin/master' into JDK-8266490
>>  - Add hotspot tests
>>  - test and small adjustments suggested by Severin
>>  - Adjustments following Severins comments
>>  - JDK-8266490
>
> Hi Severin, thanks for the comments. I added a commit with a number of adjustments 
> 
> src/hotspot/os/linux/cgroupSubsystem_linux.cpp
> adjusted log_info to log_debug
> 
> src/java.base/share/classes/sun/launcher/LauncherHelper.java
> adjusted the output to "Maximum Processes Limit:"
> 
> test/hotspot/jtreg/containers/docker/CheckOperatingSystemMXBean.java
> removed the getPidsMax related line (I think I inserted it while running some tests and forgot previously to remove it)
> 
> test/hotspot/jtreg/containers/docker/TestPids.java
> added testing of "Unlimited"; added  --pids-limit=-1  for  Unlimited procs like you suggested
> 
> test/jdk/jdk/internal/platform/docker/TestPidsLimit.java
> adjusted output; added  --pids-limit=-1  for  Unlimited procs like you suggested

@MBaesken Thanks. We need a solution for https://github.com/openjdk/jdk/pull/4518#issuecomment-882637594 though. `--pids-limit=-1` doesn't seem to make it unlimited on all container runtimes. For example it fails for me here with:


$ docker --version
Docker version 20.10.6, build 370c289

-------------

PR: https://git.openjdk.java.net/jdk/pull/4518

From jai.forums2013 at gmail.com  Thu Jul 22 16:01:46 2021
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Thu, 22 Jul 2021 21:31:46 +0530
Subject: RFR: 8190753: (zipfs): Accessing a large entry (> 2^31 bytes)
 leads to a negative initial size for ByteArrayOutputStream [v8]
In-Reply-To: <AM0PR03MB4145C179362F192CF419E8E8FFE49@AM0PR03MB4145.eurprd03.prod.outlook.com>
References: <0GJVLeCPoDI4FePU-Z-NMwJHaS2XyH9S28LgqI1LNB8=.e32743dc-a6dd-475d-88ab-16ed3f46beab@github.com>
 <ehuksZQILsWLXcuvxgtRGIq7Lqwl146QQpIVHanMoIs=.9cad7f15-24b8-4bf6-99db-cbf3ef3cccbf@github.com>
 <ConvQJ7XdR_kfz0T9BDkYlZ4l05w65o8i_bulHcdAxM=.ccd7e23a-dea4-44c0-a183-aa98ec31f955@github.com>
 <tYUfVXrSQR82OGRtYohP_1ieRkMgLrcniUksThnWFc0=.f709ca9d-9918-4de0-a5c4-1b011fd07f89@github.com>
 <qvx7-anm29qNq_xfUfYTP0_8Me5pKoFnXSceloKS-9c=.d12bf1e3-5ead-45b9-bd6a-908a9b798e2f@github.com>
 <uG2wyFCNIlm-GSa3kAEEEj_MamETPOwZS9oSilafOw8=.09d1b5d4-17c2-468a-bec3-2d1853c717c1@github.com>
 <AM0PR03MB4145C179362F192CF419E8E8FFE49@AM0PR03MB4145.eurprd03.prod.outlook.com>
Message-ID: <a6d0412b-5e62-6f49-aefc-1d21f13c8155@gmail.com>

Hello Bernd,

On 22/07/21 8:54 pm, Bernd Eckenfels wrote:
> Hello,
>
>> So although you can transfer the contents to the file without requiring the access
>> to the byte array, you end up creating a new copy of that array (through the use
>> of `baos.toByteArray()`)
> You can avoid the copy and the additional buffer with baos.writeTo() I think.
>
> try (OutputStream os = Files.newOutputStream(entry.file)) { // maybe append?
>      baos.writeTo(os);
> }

You are absolutely right. I hadn't noticed ByteArrayOutputStream had 
this writeTo() method. Thank you for this input.

This was the only concern I had when it came to wrapping the 
ByteArrayOutputStream and now with your input it no longer is a concern. 
I have updated this PR to go ahead with the wrapping approach which also 
does away with the necessity of UncheckedIOException. Existing and the 
new tests continue to pass with this change.

-Jaikiran



From jpai at openjdk.java.net  Thu Jul 22 16:01:30 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Thu, 22 Jul 2021 16:01:30 GMT
Subject: RFR: 8190753: (zipfs): Accessing a large entry (> 2^31 bytes)
 leads to a negative initial size for ByteArrayOutputStream [v9]
In-Reply-To: <0GJVLeCPoDI4FePU-Z-NMwJHaS2XyH9S28LgqI1LNB8=.e32743dc-a6dd-475d-88ab-16ed3f46beab@github.com>
References: <0GJVLeCPoDI4FePU-Z-NMwJHaS2XyH9S28LgqI1LNB8=.e32743dc-a6dd-475d-88ab-16ed3f46beab@github.com>
Message-ID: <xzX9pwzVnXSp-9Dp5BOlDRQNWZRL4mWFGeWSHTufRME=.a568319a-5c6d-451c-a023-8ea0519deae2@github.com>

> Can I please get a review for this proposed fix for the issue reported in https://bugs.openjdk.java.net/browse/JDK-8190753?
> 
> The commit here checks for the size of the zip entry before trying to create a `ByteArrayOutputStream` for that entry's content. A new jtreg test has been included in this commit to reproduce the issue and verify the fix.
> 
> P.S: It's still a bit arguable whether it's a good idea to create the `ByteArrayOutputStream` with an initial size potentially as large as the `MAX_ARRAY_SIZE` or whether it's better to just use some smaller default value. However, I think that can be addressed separately while dealing with https://bugs.openjdk.java.net/browse/JDK-8011146

Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:

 - remove no longer necessary javadoc comment on test
 - review suggestion - wrap ByteArrayOutputStream instead of extending it

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4607/files
  - new: https://git.openjdk.java.net/jdk/pull/4607/files/c1ec9e12..90101d45

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4607&range=08
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4607&range=07-08

  Stats: 72 lines in 2 files changed: 19 ins; 35 del; 18 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4607.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4607/head:pull/4607

PR: https://git.openjdk.java.net/jdk/pull/4607

From brian.goetz at oracle.com  Thu Jul 22 16:15:57 2021
From: brian.goetz at oracle.com (Brian Goetz)
Date: Thu, 22 Jul 2021 12:15:57 -0400
Subject: JNI WeakGlobalRefs
In-Reply-To: <ed8070fe-c877-3445-595b-76f635d53e49@oracle.com>
References: <CAMOCf+isqt=NAEHfQBgW-ZgEyfYxZWDvAcnpdiO+oDx3zVCUbA@mail.gmail.com>
 <ed8070fe-c877-3445-595b-76f635d53e49@oracle.com>
Message-ID: <f1794bfa-f975-969c-97fd-47e89b859984@oracle.com>

You might also consider bringing this to panama-dev, since that will 
eventually be the recommended replacement for most uses of JNI.

On 7/21/2021 6:25 PM, David Holmes wrote:
> Hi Hans,
>
> On 22/07/2021 7:54 am, Hans Boehm wrote:
>> Is this an appropriate list to discuss JNI?
>
> No - hotspot-dev (to get runtime and GC folk) is the place to discuss 
> JNI.
>
> Thanks,
> David
>
>> I'm concerned that the current semantics of JNI WeakGlobalRefs are still
>> dangerous in a very subtle way that is hidden in the spec. The current
>> (14+) spec says:
>>
>> ?Weak global references are related to Java phantom references
>> (java.lang.ref.PhantomReference). A weak global reference to a specific
>> object is treated as a phantom reference referring to that object when
>> determining whether the object is phantom reachable (see java.lang.ref).
>> ---> Such a weak global reference will become functionally equivalent to
>> NULL at the same time as a PhantomReference referring to that same 
>> object
>> would be cleared by the garbage collector. <---?
>>
>> (This was the result of JDK-8220617, and is IMO a large improvement over
>> the prior version, but ...)
>>
>> Consider what happens if I have a WeakGlobalRef W that refers to a Java
>> object A which, possibly indirectly, relies on an object F, where F is
>> finalizable, i.e.
>>
>> W - - -> A -----> ... -----> F
>>
>> Assume that F becomes invalid once it is finalized, e.g. because the
>> finalizer deallocates a native object that F relies on. This seems to 
>> be a
>> very common case. We are then exposed to the following scenario:
>>
>> 0) At some point, there are no longer any other references to A or F.
>> 1) F is enqueued for finalization.
>> 2) W is dereferenced by Thread 1, yielding a strong reference to A and
>> transitively to F.
>> 3) F is finalized.
>> 4) Thread 1 uses A and F, accessing F, which is no longer valid.
>> 5) Crash, or possibly memory corruption followed by a later crash 
>> elsewhere.
>>
>> (3) and (4) actually race, so there is some synchronization effort 
>> and cost
>> required to prevent F from corrupting memory. Commonly the 
>> implementer of W
>> will have no idea that F even exists.
>>
>> I believe that typically there is no way to prevent this scenario, 
>> unless
>> the developer adding W actually knows how every class that A could 
>> possibly
>> rely on, including those in the Java standard library, are implemented.
>>
>> This is reminiscent of finalizer ordering issues. But it seems to be 
>> worse,
>> in that there isn't even a semi-plausible workaround.
>>
>> I believe all of this is exactly the reason PhantomReference.get() 
>> always
>> returns null, while WeakReference provides significantly different
>> semantics, and WeakReferences are enqueued when an object is enqueued 
>> for
>> finalization.
>>
>> The situation improves, but the problem doesn't fully disappear, in a
>> hypothetical world without finalizers. It's still possible to use
>> WeakGlobalRef to get a strong reference to A after a WeakReference to 
>> A has
>> been cleared and enqueued. I think the problem does go away if all 
>> cleanup
>> code were to use PhantomReference-based Cleaners.
>>
>> AFAICT, backward-compatibility aside, the obvious solution here is to 
>> have
>> WeakGlobalRefs behave like WeakReferences. My impression is that this 
>> would
>> fix significantly more broken clients than it would break correct 
>> ones, so
>> it is arguably still a viable option.
>>
>> There is a case in which the current semantics are actually the desired
>> ones, namely when implementing, say, a String intern table. In this case
>> it's important the reference not be cleared even if the referent is, at
>> some point, only reachable via a finalizer. But this use case again 
>> relies
>> on the programmer knowing that no part of the referent is invalidated 
>> by a
>> finalizer. That's a reasonable assumption for the
>> Java-implementation-provided String intern table. But I'm not sure it's
>> reasonable for any user-written code.
>>
>> There seem to be two ways forward here:
>>
>> 1) Make WeakGlobalRefs behave like WeakReferences instead of
>> PhantomReferences, or
>> 2) Add strong warnings to the spec that basically suggest using a strong
>> GlobalRef to a WeakReference instead.
>>
>> Has there been prior discussion of this? Are there reasonable use 
>> cases for
>> the current semantics? Is there something else that I'm overlooking? If
>> not, what's the best way forward here?
>>
>> (I found some discussion from JDK-8220617, including a message I posted.
>> Unfortunately, it seems to me that all of us overlooked this issue?)
>>
>> Hans
>>


From alexey.semenyuk at oracle.com  Thu Jul 22 17:29:19 2021
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Thu, 22 Jul 2021 13:29:19 -0400
Subject: jpackage OS/X JDK-8263157 fix regressed out
In-Reply-To: <9112F1A4-FFFB-4DD2-BC47-AC2F6E098F99@gmail.com>
References: <9112F1A4-FFFB-4DD2-BC47-AC2F6E098F99@gmail.com>
Message-ID: <5d2d5237-7d51-9ffd-c966-7110f82149d4@oracle.com>

The fix for JDK-8263157 cleared the default value of `java.library.path` 
system property and resulted in JDK-8267598 regression. So the fix for 
JDK-8263157 was reworked: jpackage doesn't set `java.library.path` 
system property, but it adds `app` directory to `DYLD_LIBRARY_PATH` env 
variable on OSX. OSX JVM startup code builds the value of 
`java.library.path` system property from the value of 
`DYLD_LIBRARY_PATH` env variable. This way jpackage doesn't interfere 
with the default JVM initialization code and also adds `app`? directory 
to `java.library.path` system property.
As far as I can see it from the log, the value of `java.library.path` 
contains `app` dir - 
`/Users/mjh/HalfPipe/HalfPipe_jpkg/outputdir/HalfPipe.app/Contents/app`. 
So it works as expected.
Are you sure the native library is in place?

- Alexey

On 7/22/2021 10:01 AM, Michael Hall wrote:
> JDK-8263157 <https://bugs.openjdk.java.net/browse/JDK-8263157> [macos]: java.library.path is being set incorrectly
>
> The fix for this seems to be gone in both current jdk17 and jdk18 releases. There is no ?app? directory included in java.library.path.
>
> outputdir/HalfPipe.app/Contents/runtime/Contents/Home/bin/java -version
> openjdk version "18-ea" 2022-03-15
> OpenJDK Runtime Environment (build 18-ea+6-237)
> OpenJDK 64-Bit Server VM (build 18-ea+6-237, mixed mode)
>
> outputdir/HalfPipe.app/Contents/MacOS/HalfPipe
> Exception in thread "main" java.lang.UnsatisfiedLinkError: no hp in java.library.path: /opt/ooRexx/lib/ooRexx;/Users/mjh/HalfPipe/HalfPipe_jpkg/outputdir/HalfPipe.app/Contents/app:/Users/mjh/Library/Java/Extensions:/Library/Java/Extensions:/Network/Library/Java/Extensions:/System/Library/Java/Extensions:/usr/lib/java:.
> 	at java.base/java.lang.ClassLoader.loadLibrary(Unknown Source)
> 	at java.base/java.lang.Runtime.loadLibrary0(Unknown Source)
> 	at java.base/java.lang.System.loadLibrary(Unknown Source)
> 	at us.hall.hp.common.LoaderLaunchStub.<clinit>(LoaderLaunchStub.java:35)
> Failed to launch JVM
>


From mik3hall at gmail.com  Thu Jul 22 18:04:22 2021
From: mik3hall at gmail.com (Michael Hall)
Date: Thu, 22 Jul 2021 13:04:22 -0500
Subject: jpackage OS/X JDK-8263157 fix regressed out
In-Reply-To: <5d2d5237-7d51-9ffd-c966-7110f82149d4@oracle.com>
References: <9112F1A4-FFFB-4DD2-BC47-AC2F6E098F99@gmail.com>
 <5d2d5237-7d51-9ffd-c966-7110f82149d4@oracle.com>
Message-ID: <D417A6F0-2642-4FD2-A74B-5BC9ED15576B@gmail.com>



> On Jul 22, 2021, at 12:29 PM, Alexey Semenyuk <alexey.semenyuk at oracle.com> wrote:
> 
> The fix for JDK-8263157 cleared the default value of `java.library.path` system property and resulted in JDK-8267598 regression. So the fix for JDK-8263157 was reworked: jpackage doesn't set `java.library.path` system property, but it adds `app` directory to `DYLD_LIBRARY_PATH` env variable on OSX. OSX JVM startup code builds the value of `java.library.path` system property from the value of `DYLD_LIBRARY_PATH` env variable. This way jpackage doesn't interfere with the default JVM initialization code and also adds `app`  directory to `java.library.path` system property.
> As far as I can see it from the log, the value of `java.library.path` contains `app` dir - `/Users/mjh/HalfPipe/HalfPipe_jpkg/outputdir/HalfPipe.app/Contents/app`. So it works as expected.
> Are you sure the native library is in place?
> 
> - Alexey
> 

I missed that it was there somehow, but?

ls outputdir/HalfPipe.app/Contents/app | grep dylib
libAppleScriptEngine.dylib
libBSF4ooRexx.dylib
libfscript.dylib
libhp.dylib
libmacattrs.dylib

Also overriding 
-Djava.library.path=$APPDIR
worked. So I didn?t look too closely. 
So what am I still missing?
;/Users/mjh/HalfPipe/HalfPipe_jpkg/outputdir/HalfPipe.app/Contents/app:/Users/mjh/Library/Java/Extensions:
Inconsistent path separators?

From javalists at cbfiddle.com  Thu Jul 22 18:42:53 2021
From: javalists at cbfiddle.com (Alan Snyder)
Date: Thu, 22 Jul 2021 11:42:53 -0700
Subject: jpackage OS/X JDK-8263157 fix regressed out
In-Reply-To: <D417A6F0-2642-4FD2-A74B-5BC9ED15576B@gmail.com>
References: <9112F1A4-FFFB-4DD2-BC47-AC2F6E098F99@gmail.com>
 <5d2d5237-7d51-9ffd-c966-7110f82149d4@oracle.com>
 <D417A6F0-2642-4FD2-A74B-5BC9ED15576B@gmail.com>
Message-ID: <2B5A68DF-0E9E-4276-A854-3ADF0AE6C500@cbfiddle.com>

Why is a directory named ?app? used for dynamic libraries instead of the conventional directory ?Frameworks??

  Alan



> On Jul 22, 2021, at 11:04 AM, Michael Hall <mik3hall at gmail.com> wrote:
> 
> 
> 
>> On Jul 22, 2021, at 12:29 PM, Alexey Semenyuk <alexey.semenyuk at oracle.com> wrote:
>> 
>> The fix for JDK-8263157 cleared the default value of `java.library.path` system property and resulted in JDK-8267598 regression. So the fix for JDK-8263157 was reworked: jpackage doesn't set `java.library.path` system property, but it adds `app` directory to `DYLD_LIBRARY_PATH` env variable on OSX. OSX JVM startup code builds the value of `java.library.path` system property from the value of `DYLD_LIBRARY_PATH` env variable. This way jpackage doesn't interfere with the default JVM initialization code and also adds `app`  directory to `java.library.path` system property.
>> As far as I can see it from the log, the value of `java.library.path` contains `app` dir - `/Users/mjh/HalfPipe/HalfPipe_jpkg/outputdir/HalfPipe.app/Contents/app`. So it works as expected.
>> Are you sure the native library is in place?
>> 
>> - Alexey
>> 
> 
> I missed that it was there somehow, but?
> 
> ls outputdir/HalfPipe.app/Contents/app | grep dylib
> libAppleScriptEngine.dylib
> libBSF4ooRexx.dylib
> libfscript.dylib
> libhp.dylib
> libmacattrs.dylib
> 
> Also overriding 
> -Djava.library.path=$APPDIR
> worked. So I didn?t look too closely. 
> So what am I still missing?
> ;/Users/mjh/HalfPipe/HalfPipe_jpkg/outputdir/HalfPipe.app/Contents/app:/Users/mjh/Library/Java/Extensions:
> Inconsistent path separators?


From alexey.semenyuk at oracle.com  Thu Jul 22 18:46:59 2021
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Thu, 22 Jul 2021 14:46:59 -0400
Subject: [External] : Re: jpackage OS/X JDK-8263157 fix regressed out
In-Reply-To: <D417A6F0-2642-4FD2-A74B-5BC9ED15576B@gmail.com>
References: <9112F1A4-FFFB-4DD2-BC47-AC2F6E098F99@gmail.com>
 <5d2d5237-7d51-9ffd-c966-7110f82149d4@oracle.com>
 <D417A6F0-2642-4FD2-A74B-5BC9ED15576B@gmail.com>
Message-ID: <e379329f-3bc4-b131-6aba-23a1b12dfc0d@oracle.com>

Oh, inconsistent path separators indeed. Good catch! This is the reason 
it doesn't work as it should.
Filed https://bugs.openjdk.java.net/browse/JDK-8271155 to track it.

- Alexey


On 7/22/2021 2:04 PM, Michael Hall wrote:
>
>> On Jul 22, 2021, at 12:29 PM, Alexey Semenyuk <alexey.semenyuk at oracle.com> wrote:
>>
>> The fix for JDK-8263157 cleared the default value of `java.library.path` system property and resulted in JDK-8267598 regression. So the fix for JDK-8263157 was reworked: jpackage doesn't set `java.library.path` system property, but it adds `app` directory to `DYLD_LIBRARY_PATH` env variable on OSX. OSX JVM startup code builds the value of `java.library.path` system property from the value of `DYLD_LIBRARY_PATH` env variable. This way jpackage doesn't interfere with the default JVM initialization code and also adds `app`  directory to `java.library.path` system property.
>> As far as I can see it from the log, the value of `java.library.path` contains `app` dir - `/Users/mjh/HalfPipe/HalfPipe_jpkg/outputdir/HalfPipe.app/Contents/app`. So it works as expected.
>> Are you sure the native library is in place?
>>
>> - Alexey
>>
> I missed that it was there somehow, but?
>
> ls outputdir/HalfPipe.app/Contents/app | grep dylib
> libAppleScriptEngine.dylib
> libBSF4ooRexx.dylib
> libfscript.dylib
> libhp.dylib
> libmacattrs.dylib
>
> Also overriding
> -Djava.library.path=$APPDIR
> worked. So I didn?t look too closely.
> So what am I still missing?
> ;/Users/mjh/HalfPipe/HalfPipe_jpkg/outputdir/HalfPipe.app/Contents/app:/Users/mjh/Library/Java/Extensions:
> Inconsistent path separators?


From mik3hall at gmail.com  Thu Jul 22 18:47:51 2021
From: mik3hall at gmail.com (Michael Hall)
Date: Thu, 22 Jul 2021 13:47:51 -0500
Subject: [External] : Re: jpackage OS/X JDK-8263157 fix regressed out
In-Reply-To: <e379329f-3bc4-b131-6aba-23a1b12dfc0d@oracle.com>
References: <9112F1A4-FFFB-4DD2-BC47-AC2F6E098F99@gmail.com>
 <5d2d5237-7d51-9ffd-c966-7110f82149d4@oracle.com>
 <D417A6F0-2642-4FD2-A74B-5BC9ED15576B@gmail.com>
 <e379329f-3bc4-b131-6aba-23a1b12dfc0d@oracle.com>
Message-ID: <D10F3E48-2D73-4F47-9B7A-11BDAD042F7C@gmail.com>



> On Jul 22, 2021, at 1:46 PM, Alexey Semenyuk <alexey.semenyuk at oracle.com> wrote:
> 
> Oh, inconsistent path separators indeed. Good catch! This is the reason it doesn't work as it should.
> Filed https://bugs.openjdk.java.net/browse/JDK-8271155 to track it.
> 
> - Alexey
> 
> 

Thank you.


From alexey.semenyuk at oracle.com  Thu Jul 22 18:51:47 2021
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Thu, 22 Jul 2021 14:51:47 -0400
Subject: [External] : Re: jpackage OS/X JDK-8263157 fix regressed out
In-Reply-To: <2B5A68DF-0E9E-4276-A854-3ADF0AE6C500@cbfiddle.com>
References: <9112F1A4-FFFB-4DD2-BC47-AC2F6E098F99@gmail.com>
 <5d2d5237-7d51-9ffd-c966-7110f82149d4@oracle.com>
 <D417A6F0-2642-4FD2-A74B-5BC9ED15576B@gmail.com>
 <2B5A68DF-0E9E-4276-A854-3ADF0AE6C500@cbfiddle.com>
Message-ID: <e9f391c8-0f87-26ae-4a0e-f3d63b153d0a@oracle.com>

There is no corresponding folder on other platforms, so to simplify 
packaging "app" directory is used on all platforms.

- Alexey

On 7/22/2021 2:42 PM, Alan Snyder wrote:
> Why is a directory named ?app? used for dynamic libraries instead of the conventional directory ?Frameworks??
>
>    Alan
>
>
>
>> On Jul 22, 2021, at 11:04 AM, Michael Hall <mik3hall at gmail.com> wrote:
>>
>>
>>
>>> On Jul 22, 2021, at 12:29 PM, Alexey Semenyuk <alexey.semenyuk at oracle.com> wrote:
>>>
>>> The fix for JDK-8263157 cleared the default value of `java.library.path` system property and resulted in JDK-8267598 regression. So the fix for JDK-8263157 was reworked: jpackage doesn't set `java.library.path` system property, but it adds `app` directory to `DYLD_LIBRARY_PATH` env variable on OSX. OSX JVM startup code builds the value of `java.library.path` system property from the value of `DYLD_LIBRARY_PATH` env variable. This way jpackage doesn't interfere with the default JVM initialization code and also adds `app`  directory to `java.library.path` system property.
>>> As far as I can see it from the log, the value of `java.library.path` contains `app` dir - `/Users/mjh/HalfPipe/HalfPipe_jpkg/outputdir/HalfPipe.app/Contents/app`. So it works as expected.
>>> Are you sure the native library is in place?
>>>
>>> - Alexey
>>>
>> I missed that it was there somehow, but?
>>
>> ls outputdir/HalfPipe.app/Contents/app | grep dylib
>> libAppleScriptEngine.dylib
>> libBSF4ooRexx.dylib
>> libfscript.dylib
>> libhp.dylib
>> libmacattrs.dylib
>>
>> Also overriding
>> -Djava.library.path=$APPDIR
>> worked. So I didn?t look too closely.
>> So what am I still missing?
>> ;/Users/mjh/HalfPipe/HalfPipe_jpkg/outputdir/HalfPipe.app/Contents/app:/Users/mjh/Library/Java/Extensions:
>> Inconsistent path separators?


From asemenyuk at openjdk.java.net  Thu Jul 22 18:57:15 2021
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Thu, 22 Jul 2021 18:57:15 GMT
Subject: Integrated: 8268974: GetJREPath() JLI function fails to locate
 libjava.so if not standard Java launcher is used
In-Reply-To: <FwgeDLBYWTNtFkAm4wFZWWTmRvR7gOrMgLWWA54S-aw=.c4c8e357-ae73-4096-8d0a-5dd5f717fb08@github.com>
References: <FwgeDLBYWTNtFkAm4wFZWWTmRvR7gOrMgLWWA54S-aw=.c4c8e357-ae73-4096-8d0a-5dd5f717fb08@github.com>
Message-ID: <Dd4c5NEY9nf9FNd3jCNHyzmvIqV1kHV0waspJv46ps4=.3846209c-41e1-4be5-a238-ddc8912ba2d3@github.com>

On Fri, 18 Jun 2021 22:46:24 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> GetApplicationHomeFromDll() fails if the path to libjli.so contains "bin" component (/tmp/bin/HelloWorld/lib/runtime/lib/libjli.so). TruncatePath() looks for "/bin/" first in "/tmp/bin/HelloWorld/lib/runtime/lib/libjli.so" string and then it looks for "/lib/". But this is wrong order as it should look for "/lib/" first. I.e. TruncatePath() should look for "/bin/" and then for "/lib/" if called from GetApplicationHome() and for "/lib/" first and then for "/bin/" if called from GetApplicationHomeFromDll().

This pull request has now been integrated.

Changeset: 984003d5
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/984003d5c969443abae2d889e92cba30da26e55f
Stats:     65 lines in 2 files changed: 58 ins; 1 del; 6 mod

8268974: GetJREPath() JLI function fails to locate libjava.so if not standard Java launcher is used

Reviewed-by: almatvee, herrick, alanb

-------------

PR: https://git.openjdk.java.net/jdk/pull/4534

From bpb at openjdk.java.net  Thu Jul 22 19:40:46 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 22 Jul 2021 19:40:46 GMT
Subject: RFR: 8075806: divideExact is missing in java.lang.Math [v5]
In-Reply-To: <8nZ1xpS-Ir7KIEuaryZ0bQ2upeqcMy9TBm7-afE5lek=.22ec71c9-49d7-4994-aa1e-638c9d522510@github.com>
References: <8nZ1xpS-Ir7KIEuaryZ0bQ2upeqcMy9TBm7-afE5lek=.22ec71c9-49d7-4994-aa1e-638c9d522510@github.com>
Message-ID: <mS6mAEfpbieNp8YNCtxZz6aZXRH0zsNXLQOpDTR4LTY=.3c403d96-7d19-4e30-a77e-8956caaae51f@github.com>

> Please consider this proposal to add `divideExact()` methods for integral data types to `java.lang.Math` thereby rounding out "exact" support to all four basic arithmetic operations.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8075806: Clean up division by zero verbiage

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4770/files
  - new: https://git.openjdk.java.net/jdk/pull/4770/files/328e4188..5093a2e8

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4770&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4770&range=03-04

  Stats: 16 lines in 2 files changed: 4 ins; 0 del; 12 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4770.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4770/head:pull/4770

PR: https://git.openjdk.java.net/jdk/pull/4770

From bpb at openjdk.java.net  Thu Jul 22 19:41:05 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 22 Jul 2021 19:41:05 GMT
Subject: RFR: 8211002: test/jdk/java/lang/Math/PowTests.java skips testing
 for non-corner-case values [v2]
In-Reply-To: <lmK9ADp0JZWq70DBBupJhygkCGlXsSHWqo1RBdMwTyY=.be1aed71-1ea2-4d82-bef7-713262d437b0@github.com>
References: <CTD8-ciAhD-kPjiC0ic6qbOOE3XObK7JoFCTOVpLflM=.7970b30d-a3b0-4a7f-81c0-860894d56b94@github.com>
 <lmK9ADp0JZWq70DBBupJhygkCGlXsSHWqo1RBdMwTyY=.be1aed71-1ea2-4d82-bef7-713262d437b0@github.com>
Message-ID: <U_2ZnpFsCkife4JE4GEd5-LHhpbu3lA2lyYNKUts1xg=.559b71b6-0aa2-4736-9a46-647f19e26940@github.com>

On Wed, 14 Jul 2021 16:43:48 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Please consider this proposal to add some test coverage comparing `Math` and `StrictMath` results of `pow()`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8211002: Change so that Tests.testUlpDiff() handles the NaNs and accepts a ulp tolerance of 2

Ping.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4758

From darcy at openjdk.java.net  Thu Jul 22 19:41:22 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 22 Jul 2021 19:41:22 GMT
Subject: [jdk17] RFR: 8270916: Update java.lang.annotation.Target for
 changes in JLS 9.6.4.1
In-Reply-To: <Ec7nlMbURyFtJMF_nJIoCLvTyhtySjfutQQqaMQqA-Y=.c5055864-298b-45f9-bd4b-de7582acdb8e@github.com>
References: <Ec7nlMbURyFtJMF_nJIoCLvTyhtySjfutQQqaMQqA-Y=.c5055864-298b-45f9-bd4b-de7582acdb8e@github.com>
Message-ID: <vkq8a0nWym2y6KV2BSyVjnovKFgNfrOVp3QxM_lcXEc=.19b7e334-4d19-4200-a3c7-6b36a979401a@github.com>

On Mon, 19 Jul 2021 21:18:42 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Given changes in JLS 9.6.4.1, JDK-8261610 in Java SE 17, the statements about annotation applicability made in java.lang.annotation.Target need to be updated to match.
> 
> Please also review the corresponding CSR: https://bugs.openjdk.java.net/browse/JDK-8270917

CSR now approved.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/256

From asemenyuk at openjdk.java.net  Thu Jul 22 19:43:23 2021
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Thu, 22 Jul 2021 19:43:23 GMT
Subject: [jdk17] RFR: 8271155: Wrong path separator in env variable
Message-ID: <cG6R3D_aazzIwvandjuyQXdP2cFGidW1W1wkWycO498=.0273daae-5bac-4b9f-8155-6585e1e6ea52@github.com>

Replace `";"` with `FileUtils::pathSeparator` in the expression adding 'app' dir to env variable in jpackage app launcher.

-------------

Commit messages:
 - 8271155: Wrong path separator in env variable

Changes: https://git.openjdk.java.net/jdk17/pull/271/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=271&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8271155
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/271.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/271/head:pull/271

PR: https://git.openjdk.java.net/jdk17/pull/271

From bpb at openjdk.java.net  Thu Jul 22 19:47:20 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 22 Jul 2021 19:47:20 GMT
Subject: [jdk17] RFR: 8270916: Update java.lang.annotation.Target for
 changes in JLS 9.6.4.1
In-Reply-To: <Ec7nlMbURyFtJMF_nJIoCLvTyhtySjfutQQqaMQqA-Y=.c5055864-298b-45f9-bd4b-de7582acdb8e@github.com>
References: <Ec7nlMbURyFtJMF_nJIoCLvTyhtySjfutQQqaMQqA-Y=.c5055864-298b-45f9-bd4b-de7582acdb8e@github.com>
Message-ID: <kCkHRnaqAPfT2vWyDtJLA-zisc-bwBRjp0cW8hqXhV0=.c8f5b329-f345-41a9-9963-95872267b5e5@github.com>

On Mon, 19 Jul 2021 21:18:42 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Given changes in JLS 9.6.4.1, JDK-8261610 in Java SE 17, the statements about annotation applicability made in java.lang.annotation.Target need to be updated to match.
> 
> Please also review the corresponding CSR: https://bugs.openjdk.java.net/browse/JDK-8270917

Marked as reviewed by bpb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk17/pull/256

From naoto at openjdk.java.net  Thu Jul 22 19:47:20 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 22 Jul 2021 19:47:20 GMT
Subject: [jdk17] RFR: 8270916: Update java.lang.annotation.Target for
 changes in JLS 9.6.4.1
In-Reply-To: <Ec7nlMbURyFtJMF_nJIoCLvTyhtySjfutQQqaMQqA-Y=.c5055864-298b-45f9-bd4b-de7582acdb8e@github.com>
References: <Ec7nlMbURyFtJMF_nJIoCLvTyhtySjfutQQqaMQqA-Y=.c5055864-298b-45f9-bd4b-de7582acdb8e@github.com>
Message-ID: <7374tW-dc_23WZBK4MPvQvCLgxedIuIeOUXgdl9exBA=.cd660bd1-3293-41c2-9971-2310568bcb56@github.com>

On Mon, 19 Jul 2021 21:18:42 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Given changes in JLS 9.6.4.1, JDK-8261610 in Java SE 17, the statements about annotation applicability made in java.lang.annotation.Target need to be updated to match.
> 
> Please also review the corresponding CSR: https://bugs.openjdk.java.net/browse/JDK-8270917

Marked as reviewed by naoto (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk17/pull/256

From darcy at openjdk.java.net  Thu Jul 22 19:54:07 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 22 Jul 2021 19:54:07 GMT
Subject: [jdk17] Integrated: 8270916: Update java.lang.annotation.Target for
 changes in JLS 9.6.4.1
In-Reply-To: <Ec7nlMbURyFtJMF_nJIoCLvTyhtySjfutQQqaMQqA-Y=.c5055864-298b-45f9-bd4b-de7582acdb8e@github.com>
References: <Ec7nlMbURyFtJMF_nJIoCLvTyhtySjfutQQqaMQqA-Y=.c5055864-298b-45f9-bd4b-de7582acdb8e@github.com>
Message-ID: <NfMOsKz2APAru-jx67QtGzeb86k2ulp7-1mWINovmis=.38e30688-aae1-4bdb-923d-afc706912eae@github.com>

On Mon, 19 Jul 2021 21:18:42 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Given changes in JLS 9.6.4.1, JDK-8261610 in Java SE 17, the statements about annotation applicability made in java.lang.annotation.Target need to be updated to match.
> 
> Please also review the corresponding CSR: https://bugs.openjdk.java.net/browse/JDK-8270917

This pull request has now been integrated.

Changeset: ecc37b06
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.java.net/jdk17/commit/ecc37b06f283c18ab4aa2b23562843bca14da85d
Stats:     3 lines in 1 file changed: 0 ins; 0 del; 3 mod

8270916: Update java.lang.annotation.Target for changes in JLS 9.6.4.1

Reviewed-by: bpb, naoto

-------------

PR: https://git.openjdk.java.net/jdk17/pull/256

From herrick at openjdk.java.net  Thu Jul 22 20:20:20 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Thu, 22 Jul 2021 20:20:20 GMT
Subject: [jdk17] RFR: 8271155: Wrong path separator in env variable
In-Reply-To: <cG6R3D_aazzIwvandjuyQXdP2cFGidW1W1wkWycO498=.0273daae-5bac-4b9f-8155-6585e1e6ea52@github.com>
References: <cG6R3D_aazzIwvandjuyQXdP2cFGidW1W1wkWycO498=.0273daae-5bac-4b9f-8155-6585e1e6ea52@github.com>
Message-ID: <mMtAOV6PlbRvRDMYjKhZywmol3n6iJvMIwkspgpoRkA=.e9136ad2-05c3-48d4-ae05-155151eafcfc@github.com>

On Thu, 22 Jul 2021 19:35:59 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Replace `";"` with `FileUtils::pathSeparator` in the expression adding 'app' dir to env variable in jpackage app launcher.

Marked as reviewed by herrick (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk17/pull/271

From darcy at openjdk.java.net  Thu Jul 22 20:31:05 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 22 Jul 2021 20:31:05 GMT
Subject: RFR: 8211002: test/jdk/java/lang/Math/PowTests.java skips testing
 for non-corner-case values [v2]
In-Reply-To: <lmK9ADp0JZWq70DBBupJhygkCGlXsSHWqo1RBdMwTyY=.be1aed71-1ea2-4d82-bef7-713262d437b0@github.com>
References: <CTD8-ciAhD-kPjiC0ic6qbOOE3XObK7JoFCTOVpLflM=.7970b30d-a3b0-4a7f-81c0-860894d56b94@github.com>
 <lmK9ADp0JZWq70DBBupJhygkCGlXsSHWqo1RBdMwTyY=.be1aed71-1ea2-4d82-bef7-713262d437b0@github.com>
Message-ID: <bH8-lgK9yOJS7XvfdDnc7sebHeaPGckPTzjZdLFAiYI=.10de21b2-0294-43c5-a8e5-84a1ea47b2b5@github.com>

On Wed, 14 Jul 2021 16:43:48 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Please consider this proposal to add some test coverage comparing `Math` and `StrictMath` results of `pow()`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8211002: Change so that Tests.testUlpDiff() handles the NaNs and accepts a ulp tolerance of 2

Marked as reviewed by darcy (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4758

From kcr at openjdk.java.net  Thu Jul 22 20:34:05 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 22 Jul 2021 20:34:05 GMT
Subject: [jdk17] RFR: 8271155: Wrong path separator in env variable
In-Reply-To: <cG6R3D_aazzIwvandjuyQXdP2cFGidW1W1wkWycO498=.0273daae-5bac-4b9f-8155-6585e1e6ea52@github.com>
References: <cG6R3D_aazzIwvandjuyQXdP2cFGidW1W1wkWycO498=.0273daae-5bac-4b9f-8155-6585e1e6ea52@github.com>
Message-ID: <xIybUiLreGagIHp9xDzwJCQ5jEewySlljxCFMnZkXz0=.d6665ed8-8bf6-4dcb-9e71-7fdc7cd4be96@github.com>

On Thu, 22 Jul 2021 19:35:59 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Replace `";"` with `FileUtils::pathSeparator` in the expression adding 'app' dir to env variable in jpackage app launcher.

Looks good. Is there a unit test associated with this? If not, do you think one would be useful?

-------------

Marked as reviewed by kcr (Author).

PR: https://git.openjdk.java.net/jdk17/pull/271

From bpb at openjdk.java.net  Thu Jul 22 20:38:08 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 22 Jul 2021 20:38:08 GMT
Subject: Integrated: 8211002: test/jdk/java/lang/Math/PowTests.java skips
 testing for non-corner-case values
In-Reply-To: <CTD8-ciAhD-kPjiC0ic6qbOOE3XObK7JoFCTOVpLflM=.7970b30d-a3b0-4a7f-81c0-860894d56b94@github.com>
References: <CTD8-ciAhD-kPjiC0ic6qbOOE3XObK7JoFCTOVpLflM=.7970b30d-a3b0-4a7f-81c0-860894d56b94@github.com>
Message-ID: <cbNttOtWQMw32Oe4Zy-1mEs2UHMWEeUURJAHy1mTttc=.78054b25-69bf-423f-b9d4-e13356656293@github.com>

On Mon, 12 Jul 2021 19:39:13 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Please consider this proposal to add some test coverage comparing `Math` and `StrictMath` results of `pow()`.

This pull request has now been integrated.

Changeset: 1362e094
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/1362e094798d8f1d86a30c96cf93b13c664a0438
Stats:     12 lines in 1 file changed: 11 ins; 0 del; 1 mod

8211002: test/jdk/java/lang/Math/PowTests.java skips testing for non-corner-case values

Reviewed-by: darcy

-------------

PR: https://git.openjdk.java.net/jdk/pull/4758

From darcy at openjdk.java.net  Thu Jul 22 20:39:08 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 22 Jul 2021 20:39:08 GMT
Subject: RFR: 8075806: divideExact is missing in java.lang.Math [v5]
In-Reply-To: <mS6mAEfpbieNp8YNCtxZz6aZXRH0zsNXLQOpDTR4LTY=.3c403d96-7d19-4e30-a77e-8956caaae51f@github.com>
References: <8nZ1xpS-Ir7KIEuaryZ0bQ2upeqcMy9TBm7-afE5lek=.22ec71c9-49d7-4994-aa1e-638c9d522510@github.com>
 <mS6mAEfpbieNp8YNCtxZz6aZXRH0zsNXLQOpDTR4LTY=.3c403d96-7d19-4e30-a77e-8956caaae51f@github.com>
Message-ID: <Ow0TRG1nvE0fobqVV-UY66N8ZnEahty2kqFgQYu0fJM=.59373523-241b-4e8c-ada0-07d74156f3b1@github.com>

On Thu, 22 Jul 2021 19:40:46 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Please consider this proposal to add `divideExact()` methods for integral data types to `java.lang.Math` thereby rounding out "exact" support to all four basic arithmetic operations.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8075806: Clean up division by zero verbiage

Marked as reviewed by darcy (Reviewer).

test/jdk/java/lang/Math/ExactArithTests.java line 135:

> 133:         }
> 134: 
> 135:         boolean exceptionExpected = false;

Please add "divideExact" to the list of methods tested by 
static void testIntegerExact(int x, int y) 
and similar change for long.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4770

From iris at openjdk.java.net  Thu Jul 22 20:39:06 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Thu, 22 Jul 2021 20:39:06 GMT
Subject: [jdk17] RFR: 8271155: Wrong path separator in env variable
In-Reply-To: <cG6R3D_aazzIwvandjuyQXdP2cFGidW1W1wkWycO498=.0273daae-5bac-4b9f-8155-6585e1e6ea52@github.com>
References: <cG6R3D_aazzIwvandjuyQXdP2cFGidW1W1wkWycO498=.0273daae-5bac-4b9f-8155-6585e1e6ea52@github.com>
Message-ID: <j4JB0AWLYpF39-ks37t-V2hMkoI22aB8jlT4nNuskfs=.09866647-ba70-426c-acb5-f6a8968f13e6@github.com>

On Thu, 22 Jul 2021 19:35:59 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Replace `";"` with `FileUtils::pathSeparator` in the expression adding 'app' dir to env variable in jpackage app launcher.

Marked as reviewed by iris (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk17/pull/271

From bpb at openjdk.java.net  Thu Jul 22 20:52:40 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 22 Jul 2021 20:52:40 GMT
Subject: RFR: 8075806: divideExact is missing in java.lang.Math [v6]
In-Reply-To: <8nZ1xpS-Ir7KIEuaryZ0bQ2upeqcMy9TBm7-afE5lek=.22ec71c9-49d7-4994-aa1e-638c9d522510@github.com>
References: <8nZ1xpS-Ir7KIEuaryZ0bQ2upeqcMy9TBm7-afE5lek=.22ec71c9-49d7-4994-aa1e-638c9d522510@github.com>
Message-ID: <WiN671_iADZa9gsBbgtU4tS8llm5P-RtR1bAlO7XoN0=.9aeb5612-8c36-4a31-ac88-641748749aa7@github.com>

> Please consider this proposal to add `divideExact()` methods for integral data types to `java.lang.Math` thereby rounding out "exact" support to all four basic arithmetic operations.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8075806: Add divideExact() to list of tested methods

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4770/files
  - new: https://git.openjdk.java.net/jdk/pull/4770/files/5093a2e8..1dabf117

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4770&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4770&range=04-05

  Stats: 6 lines in 1 file changed: 2 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4770.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4770/head:pull/4770

PR: https://git.openjdk.java.net/jdk/pull/4770

From igraves at openjdk.java.net  Thu Jul 22 21:01:08 2021
From: igraves at openjdk.java.net (Ian Graves)
Date: Thu, 22 Jul 2021 21:01:08 GMT
Subject: RFR: 8214761: Bug in parallel Kahan summation implementation [v2]
In-Reply-To: <Bks_wWFKs6jddBmCuaCNnO3X1j9pQVuaK9G4vmDj__Y=.393742fc-4f38-4c64-8617-dd64d87cbcfa@github.com>
References: <inWiS2IlqFmGWsJuVSn1NP2Rn7YoYlADJ-3JeI8pfEs=.d208e206-5d71-4a8f-99e0-800d159d0905@github.com>
 <Bks_wWFKs6jddBmCuaCNnO3X1j9pQVuaK9G4vmDj__Y=.393742fc-4f38-4c64-8617-dd64d87cbcfa@github.com>
Message-ID: <2galZK_GfmxfXd40GkwBxmhhOpbUtIRvlMZAwKl4few=.fb0b746f-dd44-4fbd-9bdb-450edcebae62@github.com>

On Wed, 21 Jul 2021 20:19:31 GMT, Ian Graves <igraves at openjdk.org> wrote:

>> 8214761: Bug in parallel Kahan summation implementation
>
> Ian Graves has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Updates with more test coverage
>  - stashing
>  - Stashing

Circling back on this. I've worked in the test from Ivan Gerasimov's email back when. It includes some additional comparisons to prior approaches to assert improvements in error.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4674

From almatvee at openjdk.java.net  Thu Jul 22 22:11:05 2021
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Thu, 22 Jul 2021 22:11:05 GMT
Subject: [jdk17] RFR: 8271155: Wrong path separator in env variable
In-Reply-To: <cG6R3D_aazzIwvandjuyQXdP2cFGidW1W1wkWycO498=.0273daae-5bac-4b9f-8155-6585e1e6ea52@github.com>
References: <cG6R3D_aazzIwvandjuyQXdP2cFGidW1W1wkWycO498=.0273daae-5bac-4b9f-8155-6585e1e6ea52@github.com>
Message-ID: <pbfUBk9Nqu4lANt7yy8FI814y8M9W9_ej7tdiJq2ELM=.52a05325-f50b-4584-a247-15396eb96b7f@github.com>

On Thu, 22 Jul 2021 19:35:59 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Replace `";"` with `FileUtils::pathSeparator` in the expression adding 'app' dir to env variable in jpackage app launcher.

Marked as reviewed by almatvee (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk17/pull/271

From asemenyuk at openjdk.java.net  Thu Jul 22 22:18:11 2021
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Thu, 22 Jul 2021 22:18:11 GMT
Subject: [jdk17] Integrated: 8271155: Wrong path separator in env variable
In-Reply-To: <cG6R3D_aazzIwvandjuyQXdP2cFGidW1W1wkWycO498=.0273daae-5bac-4b9f-8155-6585e1e6ea52@github.com>
References: <cG6R3D_aazzIwvandjuyQXdP2cFGidW1W1wkWycO498=.0273daae-5bac-4b9f-8155-6585e1e6ea52@github.com>
Message-ID: <miFEK6bMT-gkIPZdQL5HxakQ7wWYjAWOptKbeWzGvfc=.fae08ac3-5578-44cc-8778-820502191f8b@github.com>

On Thu, 22 Jul 2021 19:35:59 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Replace `";"` with `FileUtils::pathSeparator` in the expression adding 'app' dir to env variable in jpackage app launcher.

This pull request has now been integrated.

Changeset: 7165b3f1
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.java.net/jdk17/commit/7165b3f105621398d7673253b6324e97ba0d2eee
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8271155: Wrong path separator in env variable

Reviewed-by: herrick, kcr, iris, almatvee

-------------

PR: https://git.openjdk.java.net/jdk17/pull/271

From asemenyuk at openjdk.java.net  Thu Jul 22 22:21:06 2021
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Thu, 22 Jul 2021 22:21:06 GMT
Subject: [jdk17] RFR: 8271155: Wrong path separator in env variable
In-Reply-To: <cG6R3D_aazzIwvandjuyQXdP2cFGidW1W1wkWycO498=.0273daae-5bac-4b9f-8155-6585e1e6ea52@github.com>
References: <cG6R3D_aazzIwvandjuyQXdP2cFGidW1W1wkWycO498=.0273daae-5bac-4b9f-8155-6585e1e6ea52@github.com>
Message-ID: <XdhmA19dgGB3dkpeB2X-Ke1HS4wyBPGK80JHPWGXuWk=.57078dfe-d74b-49eb-8e02-8c8b9cb94e33@github.com>

On Thu, 22 Jul 2021 19:35:59 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Replace `";"` with `FileUtils::pathSeparator` in the expression adding 'app' dir to env variable in jpackage app launcher.

There is no unit test covering this area. I'll file follow up CR to add one in JDK18.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/271

From jwilhelm at openjdk.java.net  Fri Jul 23 00:38:36 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Fri, 23 Jul 2021 00:38:36 GMT
Subject: RFR: Merge jdk17
Message-ID: <v1NRBk6d4bNWp_iftzKAJ5abkPOxvZ-hfm2v6gMOb_E=.d9099b53-7255-4da7-a990-131b19b2ecb0@github.com>

Forwardport JDK 17 -> JDK 18

-------------

Commit messages:
 - Merge
 - 8271162: runtime/StackTrace/LargeClassTest.java can be run in driver mode
 - 8271158: runtime/handshake/HandshakeTimeoutTest.java test doesn't check exit code
 - 8271169: runtime/Safepoint/TestAbortVMOnSafepointTimeout.java can be run in driver mode
 - 8271160: runtime/jni/checked/TestCheckedJniExceptionCheck.java doesn't set -Djava.library.path
 - 8271155: Wrong path separator in env variable
 - 8270916: Update java.lang.annotation.Target for changes in JLS 9.6.4.1
 - 8271094: runtime/duplAttributes/DuplAttributesTest.java doesn't check exit code
 - 8271093: remove deadcode from runtime/Thread/TestThreadDumpSMRInfo.java test
 - 8270085: Suspend during block transition may deadlock if lock held
 - ... and 2 more: https://git.openjdk.java.net/jdk/compare/a7d30123...b6b24fa0

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=4883&range=00.0
 - jdk17: https://webrevs.openjdk.java.net/?repo=jdk&pr=4883&range=00.1

Changes: https://git.openjdk.java.net/jdk/pull/4883/files
  Stats: 268 lines in 20 files changed: 178 ins; 43 del; 47 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4883.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4883/head:pull/4883

PR: https://git.openjdk.java.net/jdk/pull/4883

From Bruno.Borges at microsoft.com  Fri Jul 23 01:31:03 2021
From: Bruno.Borges at microsoft.com (Bruno Borges)
Date: Fri, 23 Jul 2021 01:31:03 +0000
Subject: jpackage - override postinstall script (Mac OS PKG) 
Message-ID: <MWHPR2101MB087350C61FABC8A6062DB78685E59@MWHPR2101MB0873.namprd21.prod.outlook.com>

Is it possible to replace the postinstall (pre too, if needed) script created by jpackage for the PKG installer on Mac OS ?



From jwilhelm at openjdk.java.net  Fri Jul 23 01:44:14 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Fri, 23 Jul 2021 01:44:14 GMT
Subject: Integrated: Merge jdk17
In-Reply-To: <v1NRBk6d4bNWp_iftzKAJ5abkPOxvZ-hfm2v6gMOb_E=.d9099b53-7255-4da7-a990-131b19b2ecb0@github.com>
References: <v1NRBk6d4bNWp_iftzKAJ5abkPOxvZ-hfm2v6gMOb_E=.d9099b53-7255-4da7-a990-131b19b2ecb0@github.com>
Message-ID: <Dd9JeDiUhvxqk32sMdsqrT5JwX_c8orhgbdnS1ofgBY=.a86c8568-3664-4040-92d3-e79fa6385ae4@github.com>

On Fri, 23 Jul 2021 00:28:53 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 17 -> JDK 18

This pull request has now been integrated.

Changeset: 9935440e
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/9935440eded25b041ea3e73cfa8ac0d95bbd66c6
Stats:     268 lines in 20 files changed: 178 ins; 43 del; 47 mod

Merge

-------------

PR: https://git.openjdk.java.net/jdk/pull/4883

From jpai at openjdk.java.net  Fri Jul 23 03:54:13 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Fri, 23 Jul 2021 03:54:13 GMT
Subject: RFR: 8271147: java/nio/file/Path.java javadoc typo
Message-ID: <IzS3dg2GJ-tX_WHTAifilNFdJyjQsx7xN7FMUS8c6ok=.8db84393-43cd-4eda-b572-720fb0e34c55@github.com>

Can I please get a review for this change which fixes the typo noted in https://bugs.openjdk.java.net/browse/JDK-8271147? `make docs-image` worked fine and the generated javadoc looks fine.

-------------

Commit messages:
 - 8271147: java/nio/file/Path.java javadoc typo

Changes: https://git.openjdk.java.net/jdk/pull/4884/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4884&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8271147
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4884.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4884/head:pull/4884

PR: https://git.openjdk.java.net/jdk/pull/4884

From iris at openjdk.java.net  Fri Jul 23 04:01:06 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Fri, 23 Jul 2021 04:01:06 GMT
Subject: RFR: 8271147: java/nio/file/Path.java javadoc typo
In-Reply-To: <IzS3dg2GJ-tX_WHTAifilNFdJyjQsx7xN7FMUS8c6ok=.8db84393-43cd-4eda-b572-720fb0e34c55@github.com>
References: <IzS3dg2GJ-tX_WHTAifilNFdJyjQsx7xN7FMUS8c6ok=.8db84393-43cd-4eda-b572-720fb0e34c55@github.com>
Message-ID: <qZXvMfFXBwYPYN2Vqie1g7Sd6pw0gsi6FUirmoesde0=.49aa6981-92c6-47be-a81c-30d3a54a87cd@github.com>

On Fri, 23 Jul 2021 03:37:44 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review for this change which fixes the typo noted in https://bugs.openjdk.java.net/browse/JDK-8271147? `make docs-image` worked fine and the generated javadoc looks fine.

Marked as reviewed by iris (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4884

From jpai at openjdk.java.net  Fri Jul 23 04:10:09 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Fri, 23 Jul 2021 04:10:09 GMT
Subject: Integrated: 8271147: java/nio/file/Path.java javadoc typo
In-Reply-To: <IzS3dg2GJ-tX_WHTAifilNFdJyjQsx7xN7FMUS8c6ok=.8db84393-43cd-4eda-b572-720fb0e34c55@github.com>
References: <IzS3dg2GJ-tX_WHTAifilNFdJyjQsx7xN7FMUS8c6ok=.8db84393-43cd-4eda-b572-720fb0e34c55@github.com>
Message-ID: <GaOK3kVWdRyJojbZWqEGmXVk6WtrnIJuqS3TCsomwuc=.b9706fdf-e8fc-4dff-b464-8f16ee287a8a@github.com>

On Fri, 23 Jul 2021 03:37:44 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review for this change which fixes the typo noted in https://bugs.openjdk.java.net/browse/JDK-8271147? `make docs-image` worked fine and the generated javadoc looks fine.

This pull request has now been integrated.

Changeset: 8156ff60
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/8156ff609b27316f31ba89d9eb8ca752f4027c2b
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8271147: java/nio/file/Path.java javadoc typo

Reviewed-by: iris

-------------

PR: https://git.openjdk.java.net/jdk/pull/4884

From jpai at openjdk.java.net  Fri Jul 23 04:10:08 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Fri, 23 Jul 2021 04:10:08 GMT
Subject: RFR: 8271147: java/nio/file/Path.java javadoc typo
In-Reply-To: <IzS3dg2GJ-tX_WHTAifilNFdJyjQsx7xN7FMUS8c6ok=.8db84393-43cd-4eda-b572-720fb0e34c55@github.com>
References: <IzS3dg2GJ-tX_WHTAifilNFdJyjQsx7xN7FMUS8c6ok=.8db84393-43cd-4eda-b572-720fb0e34c55@github.com>
Message-ID: <TSRVQCf-7JlAueOj6bucPtXXBueZDLcdr2PoL8jfj1k=.3f3d4622-baa7-4a36-b665-bc39f98a71a6@github.com>

On Fri, 23 Jul 2021 03:37:44 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review for this change which fixes the typo noted in https://bugs.openjdk.java.net/browse/JDK-8271147? `make docs-image` worked fine and the generated javadoc looks fine.

Thank you for the review, Iris.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4884

From mbaesken at openjdk.java.net  Fri Jul 23 06:52:06 2021
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Fri, 23 Jul 2021 06:52:06 GMT
Subject: RFR: JDK-8266490: Extend the OSContainer API to support the pids
 controller of cgroups [v6]
In-Reply-To: <g4NiARIHx5BTgvq6uoi9LqqcJRkJT2NiK_-qMrrv-H0=.bbbf85f5-8da9-467a-b5e0-b47bc8b73172@github.com>
References: <MWenVRe4ptn5aua0DUHvxb-sdbu-Ykl9x0GlhmxKHhY=.1fb8901e-36c3-4c07-a6ed-b653120807de@github.com>
 <g4NiARIHx5BTgvq6uoi9LqqcJRkJT2NiK_-qMrrv-H0=.bbbf85f5-8da9-467a-b5e0-b47bc8b73172@github.com>
Message-ID: <80NDhQE20WOO7LMCDS9C9zYQIRy-YKqNiGgrPQAPI64=.ef6e55d9-8995-4669-9c6f-e10a61bd427f@github.com>

On Thu, 22 Jul 2021 12:18:20 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Hello, please review this PR; it extend the OSContainer API in order to also support the pids controller of cgroups.
>> 
>> I noticed that unlike the other controllers "cpu", "cpuset", "cpuacct", "memory"  on some older Linux distros (SLES 12.1, RHEL 7.1) the pids controller might not be there (or not fully supported) so it was added as optional  , see the coding
>> 
>> 
>>   if (!cg_infos[PIDS_IDX]._data_complete) {
>>     log_debug(os, container)("Optional cgroup v1 pids subsystem not found");
>>     // keep the other controller info, pids is optional
>>   }
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minor adjustments, handling of Unlimited

> @MBaesken Thanks. We need a solution for [#4518 (comment)](https://github.com/openjdk/jdk/pull/4518#issuecomment-882637594) though. `--pids-limit=-1` doesn't seem to make it unlimited on all container runtimes. For example it fails for me here with:
> 
> ```
> $ docker --version
> Docker version 20.10.6, build 370c289
> ```

Hi Severin, that's a pity and looks like a bug, because the docker documentation says 
https://docs.docker.com/engine/reference/commandline/run/

<html>
<body>


--pids-limit | ? | Tune container pids limit (set -1 for unlimited)
-- | -- | --



</body>
</html>

Do you have an idea what to set with docker 20 on your setup?  I did not find much about this in the docker 20 release notes https://docs.docker.com/engine/release-notes/ .

-------------

PR: https://git.openjdk.java.net/jdk/pull/4518

From alanb at openjdk.java.net  Fri Jul 23 07:55:05 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 23 Jul 2021 07:55:05 GMT
Subject: [jdk17] RFR: 8271155: Wrong path separator in env variable
In-Reply-To: <cG6R3D_aazzIwvandjuyQXdP2cFGidW1W1wkWycO498=.0273daae-5bac-4b9f-8155-6585e1e6ea52@github.com>
References: <cG6R3D_aazzIwvandjuyQXdP2cFGidW1W1wkWycO498=.0273daae-5bac-4b9f-8155-6585e1e6ea52@github.com>
Message-ID: <A6ToGCwc3T_nTMCyyE6IGI-cuHKOm4a2dUMunsuJofc=.7f3c54d2-2af1-4484-9cb7-295c15fa9a7e@github.com>

On Thu, 22 Jul 2021 19:35:59 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Replace `";"` with `FileUtils::pathSeparator` in the expression adding 'app' dir to env variable in jpackage app launcher.

Is there a test planned for this change or is it covered by an existing test? Just asking as this has been committed to openjdk/jdk17 and wondering what the test coverage is.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/271

From alanb at openjdk.java.net  Fri Jul 23 08:37:06 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 23 Jul 2021 08:37:06 GMT
Subject: RFR: 8251329: (zipfs) Files.walkFileTree walks infinitely if zip
 has dir named "." inside [v4]
In-Reply-To: <FS4dG8muHl9vXW_eryRBZkDsRiquNnNOCLBlwsNVXeU=.1cecfec8-6a90-4cd4-a796-249c9b8c3110@github.com>
References: <H5Dy39I78mG6FE2N9U5vZnEhGI2zcIaxGvJ8uZBCGM0=.f3ba4976-f985-4002-87f3-da234b3c402d@github.com>
 <FWKKv49jcPmyN0fr_GVK0Sz3DceDPXRF724C45esjF8=.c86aa8c4-8fbd-4b76-90fa-a906323aae8a@github.com>
 <FS4dG8muHl9vXW_eryRBZkDsRiquNnNOCLBlwsNVXeU=.1cecfec8-6a90-4cd4-a796-249c9b8c3110@github.com>
Message-ID: <RbqToCLJL51Pe1uYIwCEpfTby8QSOwhgqsF6knjTT84=.de3b6c66-3367-4b4f-a7b8-4e30bd7a0dca@github.com>

On Fri, 2 Jul 2021 11:08:43 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
>> 
>>  - Merge latest from upstream master branch to bring in fixes that might help fix the unrelated tier1 failures in Github Actions job runs
>>  - implement review suggestions:
>>     - reduce the toString() calls by creating a helper
>>     - fs.getPath("/") instead of fs.getRootDirectories().iterator().next()
>>  - implement review suggestion - move isSelfOrParent to ZipPath class
>>  - 8251329: (zipfs) Files.walkFileTree walks infinitely if zip has dir named "." inside
>
> Hi Jaikiran,
> 
> Consider:
> 
> 
>         try (var os = Files.newOutputStream(ZIPFILE);
>              ZipOutputStream zos = new ZipOutputStream(os)) {
>             zos.putNextEntry(new ZipEntry("../Hello.txt"));
>             zos.write("Hello World".getBytes(StandardCharsets.UTF_8));
>         }
> 
> 
> With your proposed fix, you will only return "/" when you walk the the Zip file and we should also return "/Hello.txt"
> 
> If. you resolve the path when the Inode entry is created:
> 
>            ` name(new ZipPath(null, normalize(name), true).getResolvedPath());`
> 
> That should address the issue and also allow you to access the entry.

I discussed this issue with @LanceAndersen and I think we are in agreement that a zip file system needs to use "." and ".." as links to the current and parent directories and cannot reliably support entries that have "." and ".." as name elements.  The other options on the table (including Lance's origin prototype fix and the proposal in this PR) lead to anomalies. So I think we should close this PR and restart JDK-8251329.  @jaikiran Are you okay this this? JDK-8251329 is still assigned to JDK-8251329 and has a patch with the changes that we think are the right way for newFileSystem to reject ZIP files that have entries in the CEN that can't be used for files in a file system.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4604

From sgehwolf at openjdk.java.net  Fri Jul 23 08:43:04 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Fri, 23 Jul 2021 08:43:04 GMT
Subject: RFR: JDK-8266490: Extend the OSContainer API to support the pids
 controller of cgroups [v6]
In-Reply-To: <80NDhQE20WOO7LMCDS9C9zYQIRy-YKqNiGgrPQAPI64=.ef6e55d9-8995-4669-9c6f-e10a61bd427f@github.com>
References: <MWenVRe4ptn5aua0DUHvxb-sdbu-Ykl9x0GlhmxKHhY=.1fb8901e-36c3-4c07-a6ed-b653120807de@github.com>
 <g4NiARIHx5BTgvq6uoi9LqqcJRkJT2NiK_-qMrrv-H0=.bbbf85f5-8da9-467a-b5e0-b47bc8b73172@github.com>
 <80NDhQE20WOO7LMCDS9C9zYQIRy-YKqNiGgrPQAPI64=.ef6e55d9-8995-4669-9c6f-e10a61bd427f@github.com>
Message-ID: <wGe0vflu7uZ8O0WsAz2OdkpjtiyXLkafQF-w5x3n1gU=.57343745-db2f-42b9-b1cb-2694a741c7f6@github.com>

On Fri, 23 Jul 2021 06:49:15 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Minor adjustments, handling of Unlimited
>
>> @MBaesken Thanks. We need a solution for [#4518 (comment)](https://github.com/openjdk/jdk/pull/4518#issuecomment-882637594) though. `--pids-limit=-1` doesn't seem to make it unlimited on all container runtimes. For example it fails for me here with:
>> 
>> ```
>> $ docker --version
>> Docker version 20.10.6, build 370c289
>> ```
> 
> Hi Severin, that's a pity and looks like a bug, because the docker documentation says 
> https://docs.docker.com/engine/reference/commandline/run/
> 
> <html>
> <body>
> 
> 
> --pids-limit | ? | Tune container pids limit (set -1 for unlimited)
> -- | -- | --
> 
> 
> 
> </body>
> </html>
> 
> Do you have an idea what to set with docker 20 on your setup?  I did not find much about this in the docker 20 release notes https://docs.docker.com/engine/release-notes/ .

> > @MBaesken Thanks. We need a solution for [#4518 (comment)](https://github.com/openjdk/jdk/pull/4518#issuecomment-882637594) though. `--pids-limit=-1` doesn't seem to make it unlimited on all container runtimes. For example it fails for me here with:
> > ```
> > $ docker --version
> > Docker version 20.10.6, build 370c289
> > ```
> 
> Hi Severin, that's a pity and looks like a bug, because the docker documentation says
> https://docs.docker.com/engine/reference/commandline/run/
> --pids-limit 	  	Tune container pids limit (set -1 for unlimited)
> 
> Do you have an idea what to set with docker 20 on your setup? I did not find much about this in the docker 20 release notes https://docs.docker.com/engine/release-notes/ .

No, I don't know what to do about it. All I can see it comes back with a pids limit of `38019` when set to `-1`. It does seem like a bug or an intentional setting so as to avoid fork bombs.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4518

From jpai at openjdk.java.net  Fri Jul 23 08:51:09 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Fri, 23 Jul 2021 08:51:09 GMT
Subject: RFR: 8251329: (zipfs) Files.walkFileTree walks infinitely if zip
 has dir named "." inside [v4]
In-Reply-To: <FWKKv49jcPmyN0fr_GVK0Sz3DceDPXRF724C45esjF8=.c86aa8c4-8fbd-4b76-90fa-a906323aae8a@github.com>
References: <H5Dy39I78mG6FE2N9U5vZnEhGI2zcIaxGvJ8uZBCGM0=.f3ba4976-f985-4002-87f3-da234b3c402d@github.com>
 <FWKKv49jcPmyN0fr_GVK0Sz3DceDPXRF724C45esjF8=.c86aa8c4-8fbd-4b76-90fa-a906323aae8a@github.com>
Message-ID: <JpH4SJfNWNzVHuX8rsxpiZa6z996faubJkUexd7Mwwk=.fdef89e0-8e7e-491e-9957-53a0d4b03852@github.com>

On Fri, 2 Jul 2021 11:06:40 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this proposed fix for https://bugs.openjdk.java.net/browse/JDK-8251329?
>> 
>> As noted in that issue, if a zip filesystem created on top of a jar containing a "./" entry is "walked" using the `Files.walkFileTree`, it leads to a infinite never ending iteration (which ultimately fails with Java heap space OOM).
>> 
>> Alan notes in that issue that:
>> 
>>> This is more likely an issue with the zipfs DirectoryStream implementation. A DirectoryStream is specified to not include elements that for the special links to the current or parent directory. It should be rare. 
>> 
>> This indeed turned out to be an issue in the `jdk.nio.zipfs.ZipDirectoryStream#iterator()` implementation where it calls the `jdk.nio.zipfs.ZipFileSystem#iteratorOf(...)` implementation.  The implementation, unlike what the javadoc of `java.nio.file.DirectoryStream` states, was including the "." and ".." paths in its returned iterator:
>> 
>>> The elements returned by the iterator are in no specific order. Some file
>>  systems maintain special links to the directory itself and the directory's
>>   parent directory. Entries representing these links are not returned by the
>>   iterator.
>> 
>> 
>> The proposed fix in this patch checks the paths for "." and "..", similar to what the `sun.nio.fs.UnixDirectoryStream` does in its `isSelfOrParent` and skips those paths from being added into the returned iterator. The `jdk.nio.zipfs.ZipFileSystem#iteratorOf(...)` (where this change has been done) is currently only used by `jdk.nio.zipfs.ZipDirectoryStream#iterator()` and has package-private visibility, so this change shouldn't impact any other usage/expectations.
>> 
>> A new jtreg test has been added to reproduce this issue and verify the fix. Local testing of the `test/jdk/jdk/nio/` (including this new test) went fine without any issues after this change. I will be triggering a `tier1` test locally in a while.
>
> Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge latest from upstream master branch to bring in fixes that might help fix the unrelated tier1 failures in Github Actions job runs
>  - implement review suggestions:
>     - reduce the toString() calls by creating a helper
>     - fs.getPath("/") instead of fs.getRootDirectories().iterator().next()
>  - implement review suggestion - move isSelfOrParent to ZipPath class
>  - 8251329: (zipfs) Files.walkFileTree walks infinitely if zip has dir named "." inside

Hello Alan,

> So I think we should close this PR and restart JDK-8251329. @jaikiran Are you okay this this?

Yes, this sounds fine to me. I don't have any objection in closing this PR and I'll do it shortly.

> JDK-8251329 is still assigned to JDK-8251329 and has a patch with the changes that we think are the right way for newFileSystem to reject ZIP files 

This part I didn't understand. Did you mean to refer some other JBS issue? Because from what I see in https://bugs.openjdk.java.net/browse/JDK-8251329 there's no patch attached to it (unless of course it's restricted to specific JBS user roles?).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4604

From jpai at openjdk.java.net  Fri Jul 23 09:03:13 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Fri, 23 Jul 2021 09:03:13 GMT
Subject: RFR: 8251329: (zipfs) Files.walkFileTree walks infinitely if zip
 has dir named "." inside [v4]
In-Reply-To: <FWKKv49jcPmyN0fr_GVK0Sz3DceDPXRF724C45esjF8=.c86aa8c4-8fbd-4b76-90fa-a906323aae8a@github.com>
References: <H5Dy39I78mG6FE2N9U5vZnEhGI2zcIaxGvJ8uZBCGM0=.f3ba4976-f985-4002-87f3-da234b3c402d@github.com>
 <FWKKv49jcPmyN0fr_GVK0Sz3DceDPXRF724C45esjF8=.c86aa8c4-8fbd-4b76-90fa-a906323aae8a@github.com>
Message-ID: <7-Xlx5esvz244se9IG2KZDmLwscSh2SKk2dwSU1-l_0=.1a5b3fcb-a586-4c02-93fd-d45ef54fd78e@github.com>

On Fri, 2 Jul 2021 11:06:40 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this proposed fix for https://bugs.openjdk.java.net/browse/JDK-8251329?
>> 
>> As noted in that issue, if a zip filesystem created on top of a jar containing a "./" entry is "walked" using the `Files.walkFileTree`, it leads to a infinite never ending iteration (which ultimately fails with Java heap space OOM).
>> 
>> Alan notes in that issue that:
>> 
>>> This is more likely an issue with the zipfs DirectoryStream implementation. A DirectoryStream is specified to not include elements that for the special links to the current or parent directory. It should be rare. 
>> 
>> This indeed turned out to be an issue in the `jdk.nio.zipfs.ZipDirectoryStream#iterator()` implementation where it calls the `jdk.nio.zipfs.ZipFileSystem#iteratorOf(...)` implementation.  The implementation, unlike what the javadoc of `java.nio.file.DirectoryStream` states, was including the "." and ".." paths in its returned iterator:
>> 
>>> The elements returned by the iterator are in no specific order. Some file
>>  systems maintain special links to the directory itself and the directory's
>>   parent directory. Entries representing these links are not returned by the
>>   iterator.
>> 
>> 
>> The proposed fix in this patch checks the paths for "." and "..", similar to what the `sun.nio.fs.UnixDirectoryStream` does in its `isSelfOrParent` and skips those paths from being added into the returned iterator. The `jdk.nio.zipfs.ZipFileSystem#iteratorOf(...)` (where this change has been done) is currently only used by `jdk.nio.zipfs.ZipDirectoryStream#iterator()` and has package-private visibility, so this change shouldn't impact any other usage/expectations.
>> 
>> A new jtreg test has been added to reproduce this issue and verify the fix. Local testing of the `test/jdk/jdk/nio/` (including this new test) went fine without any issues after this change. I will be triggering a `tier1` test locally in a while.
>
> Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge latest from upstream master branch to bring in fixes that might help fix the unrelated tier1 failures in Github Actions job runs
>  - implement review suggestions:
>     - reduce the toString() calls by creating a helper
>     - fs.getPath("/") instead of fs.getRootDirectories().iterator().next()
>  - implement review suggestion - move isSelfOrParent to ZipPath class
>  - 8251329: (zipfs) Files.walkFileTree walks infinitely if zip has dir named "." inside

Closing this PR based on the above discussion.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4604

From jpai at openjdk.java.net  Fri Jul 23 09:03:13 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Fri, 23 Jul 2021 09:03:13 GMT
Subject: Withdrawn: 8251329: (zipfs) Files.walkFileTree walks infinitely if
 zip has dir named "." inside
In-Reply-To: <H5Dy39I78mG6FE2N9U5vZnEhGI2zcIaxGvJ8uZBCGM0=.f3ba4976-f985-4002-87f3-da234b3c402d@github.com>
References: <H5Dy39I78mG6FE2N9U5vZnEhGI2zcIaxGvJ8uZBCGM0=.f3ba4976-f985-4002-87f3-da234b3c402d@github.com>
Message-ID: <p2jXteophrfv2BG0aUQOEmyfaZ3YCfMpcDsk05Hez7Y=.1525f10b-dde2-419b-b407-970093e55122@github.com>

On Sun, 27 Jun 2021 13:13:42 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this proposed fix for https://bugs.openjdk.java.net/browse/JDK-8251329?
> 
> As noted in that issue, if a zip filesystem created on top of a jar containing a "./" entry is "walked" using the `Files.walkFileTree`, it leads to a infinite never ending iteration (which ultimately fails with Java heap space OOM).
> 
> Alan notes in that issue that:
> 
>> This is more likely an issue with the zipfs DirectoryStream implementation. A DirectoryStream is specified to not include elements that for the special links to the current or parent directory. It should be rare. 
> 
> This indeed turned out to be an issue in the `jdk.nio.zipfs.ZipDirectoryStream#iterator()` implementation where it calls the `jdk.nio.zipfs.ZipFileSystem#iteratorOf(...)` implementation.  The implementation, unlike what the javadoc of `java.nio.file.DirectoryStream` states, was including the "." and ".." paths in its returned iterator:
> 
>> The elements returned by the iterator are in no specific order. Some file
>  systems maintain special links to the directory itself and the directory's
>   parent directory. Entries representing these links are not returned by the
>   iterator.
> 
> 
> The proposed fix in this patch checks the paths for "." and "..", similar to what the `sun.nio.fs.UnixDirectoryStream` does in its `isSelfOrParent` and skips those paths from being added into the returned iterator. The `jdk.nio.zipfs.ZipFileSystem#iteratorOf(...)` (where this change has been done) is currently only used by `jdk.nio.zipfs.ZipDirectoryStream#iterator()` and has package-private visibility, so this change shouldn't impact any other usage/expectations.
> 
> A new jtreg test has been added to reproduce this issue and verify the fix. Local testing of the `test/jdk/jdk/nio/` (including this new test) went fine without any issues after this change. I will be triggering a `tier1` test locally in a while.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4604

From alanb at openjdk.java.net  Fri Jul 23 10:31:04 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 23 Jul 2021 10:31:04 GMT
Subject: RFR: 8190753: (zipfs): Accessing a large entry (> 2^31 bytes)
 leads to a negative initial size for ByteArrayOutputStream [v9]
In-Reply-To: <xzX9pwzVnXSp-9Dp5BOlDRQNWZRL4mWFGeWSHTufRME=.a568319a-5c6d-451c-a023-8ea0519deae2@github.com>
References: <0GJVLeCPoDI4FePU-Z-NMwJHaS2XyH9S28LgqI1LNB8=.e32743dc-a6dd-475d-88ab-16ed3f46beab@github.com>
 <xzX9pwzVnXSp-9Dp5BOlDRQNWZRL4mWFGeWSHTufRME=.a568319a-5c6d-451c-a023-8ea0519deae2@github.com>
Message-ID: <woyZSONLQ0DEtRRSVD6kjlyXqlYYUROeN9k-DgWmeMg=.6205b3e1-c2e2-4861-a00d-4aec82e7d154@github.com>

On Thu, 22 Jul 2021 16:01:30 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this proposed fix for the issue reported in https://bugs.openjdk.java.net/browse/JDK-8190753?
>> 
>> The commit here checks for the size of the zip entry before trying to create a `ByteArrayOutputStream` for that entry's content. A new jtreg test has been included in this commit to reproduce the issue and verify the fix.
>> 
>> P.S: It's still a bit arguable whether it's a good idea to create the `ByteArrayOutputStream` with an initial size potentially as large as the `MAX_ARRAY_SIZE` or whether it's better to just use some smaller default value. However, I think that can be addressed separately while dealing with https://bugs.openjdk.java.net/browse/JDK-8011146
>
> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - remove no longer necessary javadoc comment on test
>  - review suggestion - wrap ByteArrayOutputStream instead of extending it

Thanks for changing it to wrap the BOAS rather than existing it, that avoids the annoying wrapping/unwrapping of exceptions.

So I think the approach looks good but I think the synchronization needs to be re-checked it is not obvious that is correct or needed. Are there any cases where FileRolloverOutputStream is returned to user code? I don't think so, instead users of the zip file system will get an EntryOutputStream that wraps the FileRolloverOutputStream. The EntryOutputStream methods are synchronized so I assume that FileRolloverOutputStream does not need to it and that would avoid the inconsistency between the write methods and the flush/close methods.

One other thing to point out is that transferToFile shouldn't need to open the file twice, instead it should be able to open the tmp file for writing once.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4607

From alanb at openjdk.java.net  Fri Jul 23 10:40:09 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 23 Jul 2021 10:40:09 GMT
Subject: RFR: 8251329: (zipfs) Files.walkFileTree walks infinitely if zip
 has dir named "." inside [v4]
In-Reply-To: <JpH4SJfNWNzVHuX8rsxpiZa6z996faubJkUexd7Mwwk=.fdef89e0-8e7e-491e-9957-53a0d4b03852@github.com>
References: <H5Dy39I78mG6FE2N9U5vZnEhGI2zcIaxGvJ8uZBCGM0=.f3ba4976-f985-4002-87f3-da234b3c402d@github.com>
 <FWKKv49jcPmyN0fr_GVK0Sz3DceDPXRF724C45esjF8=.c86aa8c4-8fbd-4b76-90fa-a906323aae8a@github.com>
 <JpH4SJfNWNzVHuX8rsxpiZa6z996faubJkUexd7Mwwk=.fdef89e0-8e7e-491e-9957-53a0d4b03852@github.com>
Message-ID: <C-LUWPR74y0Tpi2CDCyyoWkt8m2uH_IhYomlyO0IoAc=.6ff84ced-ca68-42a3-b839-9fe4af2d492a@github.com>

On Fri, 23 Jul 2021 08:47:46 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> This part I didn't understand. Did you mean to refer some other JBS issue? Because from what I see in https://bugs.openjdk.java.net/browse/JDK-8251329 there's no patch attached to it (unless of course it's restricted to specific JBS user roles?).

I wasn't suggesting there is a patch attached to that issue. Rather I was just pointing out that JDK-8251329 was being worked on already before this PR was created. Lance's initial patch for JDK-8251329 changed ZipPath::getResolvedPath when creating the inode entry but that approach leads to anomalies. Overall I think the discussion has been useful but I don't think it's feasible to have a file system view over entries that look like links to the current or parent directory.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4604

From mbaesken at openjdk.java.net  Fri Jul 23 11:05:03 2021
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Fri, 23 Jul 2021 11:05:03 GMT
Subject: RFR: JDK-8266490: Extend the OSContainer API to support the pids
 controller of cgroups [v6]
In-Reply-To: <wGe0vflu7uZ8O0WsAz2OdkpjtiyXLkafQF-w5x3n1gU=.57343745-db2f-42b9-b1cb-2694a741c7f6@github.com>
References: <MWenVRe4ptn5aua0DUHvxb-sdbu-Ykl9x0GlhmxKHhY=.1fb8901e-36c3-4c07-a6ed-b653120807de@github.com>
 <g4NiARIHx5BTgvq6uoi9LqqcJRkJT2NiK_-qMrrv-H0=.bbbf85f5-8da9-467a-b5e0-b47bc8b73172@github.com>
 <80NDhQE20WOO7LMCDS9C9zYQIRy-YKqNiGgrPQAPI64=.ef6e55d9-8995-4669-9c6f-e10a61bd427f@github.com>
 <wGe0vflu7uZ8O0WsAz2OdkpjtiyXLkafQF-w5x3n1gU=.57343745-db2f-42b9-b1cb-2694a741c7f6@github.com>
Message-ID: <b3tc72GBp_aSCngNXWbJFncPyTJT3mF-NoSYPqAGGlw=.bf5d98c7-62e9-46f0-bbc4-6aeb86b77a3d@github.com>

On Fri, 23 Jul 2021 08:39:37 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> 
> No, I don't know what to do about it. All I can see it comes back with a pids limit of `38019` when set to `-1`. It does seem like a bug or an intentional setting so as to avoid fork bombs.

Very strange indeed, I have docker 20.10.2 on my Ubuntu test server and there the tests work and no "38019" is coming back for -1/unlimited . What distro are you using?  I did a quick search but did not find much about the mysterious  `38019`  .  Could this be some setting configured on your box that is picked up as an additional limit ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4518

From prappo at openjdk.java.net  Fri Jul 23 11:27:22 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Fri, 23 Jul 2021 11:27:22 GMT
Subject: RFR: 8247373: ArraysSupport.newLength doc, test,
 and exception message [v5]
In-Reply-To: <3FceBcNCgvvX-OtjUilCudtV6bhkxc5MNfSUmcwIpeE=.b9849110-ed3d-4824-931c-f14bb7b4741a@github.com>
References: <D9oU9mGK5su1atHT64_Hf8f3ZRF2rN1E8pueDRYlOHA=.067ec1c2-4fb9-4b06-82e5-e3243d2e065f@github.com>
 <XtFTqL8gIc5KE9PlJAg8ebG4C9pFah8VqYNAJ6z58Ig=.701d54b4-10d2-4b05-9caa-bad73c637c23@github.com>
 <95Ftj5VP86TBOjqROCftNhumk8KoF1AzjZ5mTNgOEEY=.74ae6a40-31a7-4e23-8412-ef1487d15109@github.com>
 <3FceBcNCgvvX-OtjUilCudtV6bhkxc5MNfSUmcwIpeE=.b9849110-ed3d-4824-931c-f14bb7b4741a@github.com>
Message-ID: <I8YwzqPyE-NbKjqlFs8SE0AHGvTQTdNPbP8x45PMW9g=.18d89910-8335-4d5f-9cb5-37149a4864c2@github.com>

On Tue, 2 Mar 2021 18:07:24 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> test/jdk/jdk/internal/util/ArraysSupport/NewLength.java line 100:
>> 
>>> 98:             int r = ArraysSupport.newLength(old, min, pref);
>>> 99:             fail("expected OutOfMemoryError, got normal return value of " + r);
>>> 100:         } catch (OutOfMemoryError success) { }
>> 
>> Consider using `expectThrows` or `assertThrows` from `org.testng.Assert`.
>
> Good point. However, I actually tried to use assertThrows, but there doesn't seem to be a way to get the unexpected return value into the error message. I think having this value in the test output is important for diagnosing failures.

That tradeoff you made, makes sense.

Indeed, neither `assertThrows` nor `expectThrows` in `org.testng.Assert` logs an unexpectedly returned value. This is because the code being tested is expressed as the `Assert.ThrowingRunnable` interface which has a single `void` method. So the code being tested cannot return a value to the testing framework.

Now, if `org.testng.Assert` were to provide the respective methods accepting, say, `Assert.ThrowingCallable` that had a value-returning method, TestNG would run into the same issues that JUnit ran into when they attempted to do that: https://github.com/junit-team/junit5/issues/1576

-------------

PR: https://git.openjdk.java.net/jdk/pull/1617

From jpai at openjdk.java.net  Fri Jul 23 11:52:47 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Fri, 23 Jul 2021 11:52:47 GMT
Subject: RFR: 8190753: (zipfs): Accessing a large entry (> 2^31 bytes)
 leads to a negative initial size for ByteArrayOutputStream [v10]
In-Reply-To: <0GJVLeCPoDI4FePU-Z-NMwJHaS2XyH9S28LgqI1LNB8=.e32743dc-a6dd-475d-88ab-16ed3f46beab@github.com>
References: <0GJVLeCPoDI4FePU-Z-NMwJHaS2XyH9S28LgqI1LNB8=.e32743dc-a6dd-475d-88ab-16ed3f46beab@github.com>
Message-ID: <gK-f_jNlcnG0wS8IYmCs_Dz0fzesq0y_28ax8w79Ffg=.1da279b7-2a9d-4d3e-b347-81f3632da0f2@github.com>

> Can I please get a review for this proposed fix for the issue reported in https://bugs.openjdk.java.net/browse/JDK-8190753?
> 
> The commit here checks for the size of the zip entry before trying to create a `ByteArrayOutputStream` for that entry's content. A new jtreg test has been included in this commit to reproduce the issue and verify the fix.
> 
> P.S: It's still a bit arguable whether it's a good idea to create the `ByteArrayOutputStream` with an initial size potentially as large as the `MAX_ARRAY_SIZE` or whether it's better to just use some smaller default value. However, I think that can be addressed separately while dealing with https://bugs.openjdk.java.net/browse/JDK-8011146

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  Implement review suggestions:
   - remove unnecessary "synchronized"
   - no need to open the temp file twice

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4607/files
  - new: https://git.openjdk.java.net/jdk/pull/4607/files/90101d45..9e78ba06

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4607&range=09
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4607&range=08-09

  Stats: 12 lines in 1 file changed: 5 ins; 4 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4607.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4607/head:pull/4607

PR: https://git.openjdk.java.net/jdk/pull/4607

From kcr at openjdk.java.net  Fri Jul 23 11:59:06 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 23 Jul 2021 11:59:06 GMT
Subject: [jdk17] RFR: 8271155: Wrong path separator in env variable
In-Reply-To: <cG6R3D_aazzIwvandjuyQXdP2cFGidW1W1wkWycO498=.0273daae-5bac-4b9f-8155-6585e1e6ea52@github.com>
References: <cG6R3D_aazzIwvandjuyQXdP2cFGidW1W1wkWycO498=.0273daae-5bac-4b9f-8155-6585e1e6ea52@github.com>
Message-ID: <i2ISJI8LEOrJwqRhlMdc4MRv81XQCRiCTsvm3KWFSR8=.74bbaa3b-a797-4e5d-817a-9cf5b2931cf9@github.com>

On Thu, 22 Jul 2021 19:35:59 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Replace `";"` with `FileUtils::pathSeparator` in the expression adding 'app' dir to env variable in jpackage app launcher.

Alexey filed [JDK-8271170](https://bugs.openjdk.java.net/browse/JDK-8271170) to cover this.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/271

From jpai at openjdk.java.net  Fri Jul 23 12:00:08 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Fri, 23 Jul 2021 12:00:08 GMT
Subject: RFR: 8190753: (zipfs): Accessing a large entry (> 2^31 bytes)
 leads to a negative initial size for ByteArrayOutputStream [v9]
In-Reply-To: <woyZSONLQ0DEtRRSVD6kjlyXqlYYUROeN9k-DgWmeMg=.6205b3e1-c2e2-4861-a00d-4aec82e7d154@github.com>
References: <0GJVLeCPoDI4FePU-Z-NMwJHaS2XyH9S28LgqI1LNB8=.e32743dc-a6dd-475d-88ab-16ed3f46beab@github.com>
 <xzX9pwzVnXSp-9Dp5BOlDRQNWZRL4mWFGeWSHTufRME=.a568319a-5c6d-451c-a023-8ea0519deae2@github.com>
 <woyZSONLQ0DEtRRSVD6kjlyXqlYYUROeN9k-DgWmeMg=.6205b3e1-c2e2-4861-a00d-4aec82e7d154@github.com>
Message-ID: <czBvY_lC-NcKS07rwYvYxv2SZAkznRoNSqf2uIzMm0M=.8a12ec0a-6e10-4ba6-a0b4-fc4a049149ac@github.com>

On Fri, 23 Jul 2021 10:28:02 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> So I think the approach looks good but I think the synchronization needs to be re-checked it is not obvious that is correct or needed. Are there any cases where FileRolloverOutputStream is returned to user code? I don't think so, instead users of the zip file system will get an EntryOutputStream that wraps the FileRolloverOutputStream. The EntryOutputStream methods are synchronized so I assume that FileRolloverOutputStream does not need to it and that would avoid the inconsistency between the write methods and the flush/close methods.

I hadn't paid any thoughts on the "synchronized" part. You are right - the new `FileRolloverOutputStream` doesn't get sent back to the callers directly and instead either the `EntryOutputStream` or the `DeflatingEntryOutputStream` get returned. Both of them have the necessary syncrhonizations in place for `write` and `close` operations. The `flush` of the `FileRolloverOutputStream` calls the `flush` on the `BufferedOutputStream` which already has the necessary synchronization. I've updated the PR to remove the use of `synchronized` from this new class and added a brief note about this for future maintainers, just like the existing `EntryOutputStreamDef` has.

> One other thing to point out is that transferToFile shouldn't need to open the file twice, instead it should be able to open the tmp file for writing once.

The updated version of this PR now fixes this part to open it just once. I had reviewed this `transferTo` multiple times before, but clearly I overlooked this part of the implementation. 

Thank you for these inputs. The updated PR continues to pass the new tests and the existing ones in `test/jdk/jdk/nio/zipfs/`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4607

From jpai at openjdk.java.net  Fri Jul 23 12:09:10 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Fri, 23 Jul 2021 12:09:10 GMT
Subject: RFR: 8251329: (zipfs) Files.walkFileTree walks infinitely if zip
 has dir named "." inside [v4]
In-Reply-To: <C-LUWPR74y0Tpi2CDCyyoWkt8m2uH_IhYomlyO0IoAc=.6ff84ced-ca68-42a3-b839-9fe4af2d492a@github.com>
References: <H5Dy39I78mG6FE2N9U5vZnEhGI2zcIaxGvJ8uZBCGM0=.f3ba4976-f985-4002-87f3-da234b3c402d@github.com>
 <FWKKv49jcPmyN0fr_GVK0Sz3DceDPXRF724C45esjF8=.c86aa8c4-8fbd-4b76-90fa-a906323aae8a@github.com>
 <JpH4SJfNWNzVHuX8rsxpiZa6z996faubJkUexd7Mwwk=.fdef89e0-8e7e-491e-9957-53a0d4b03852@github.com>
 <C-LUWPR74y0Tpi2CDCyyoWkt8m2uH_IhYomlyO0IoAc=.6ff84ced-ca68-42a3-b839-9fe4af2d492a@github.com>
Message-ID: <qtX6PYmeMyrE1wEEfQPql8noL121rWThxuj6Wu7FWvs=.4bacb27a-4072-44c8-ae74-dae1af30b210@github.com>

On Fri, 23 Jul 2021 10:36:51 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I wasn't suggesting there is a patch attached to that issue. Rather I was just pointing out that JDK-8251329 was being worked on already before this PR was created.

Ok, that makes sense. Thank you for the details.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4604

From sgehwolf at openjdk.java.net  Fri Jul 23 12:32:03 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Fri, 23 Jul 2021 12:32:03 GMT
Subject: RFR: JDK-8266490: Extend the OSContainer API to support the pids
 controller of cgroups [v6]
In-Reply-To: <b3tc72GBp_aSCngNXWbJFncPyTJT3mF-NoSYPqAGGlw=.bf5d98c7-62e9-46f0-bbc4-6aeb86b77a3d@github.com>
References: <MWenVRe4ptn5aua0DUHvxb-sdbu-Ykl9x0GlhmxKHhY=.1fb8901e-36c3-4c07-a6ed-b653120807de@github.com>
 <g4NiARIHx5BTgvq6uoi9LqqcJRkJT2NiK_-qMrrv-H0=.bbbf85f5-8da9-467a-b5e0-b47bc8b73172@github.com>
 <80NDhQE20WOO7LMCDS9C9zYQIRy-YKqNiGgrPQAPI64=.ef6e55d9-8995-4669-9c6f-e10a61bd427f@github.com>
 <wGe0vflu7uZ8O0WsAz2OdkpjtiyXLkafQF-w5x3n1gU=.57343745-db2f-42b9-b1cb-2694a741c7f6@github.com>
 <b3tc72GBp_aSCngNXWbJFncPyTJT3mF-NoSYPqAGGlw=.bf5d98c7-62e9-46f0-bbc4-6aeb86b77a3d@github.com>
Message-ID: <v5HmhFytrDnyrexCubsJSA0AxT5_FfrWD2yoN_2uRlQ=.a13c4127-46d4-4a94-aeca-31a99549a2bf@github.com>

On Fri, 23 Jul 2021 11:02:13 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> > No, I don't know what to do about it. All I can see it comes back with a pids limit of `38019` when set to `-1`. It does seem like a bug or an intentional setting so as to avoid fork bombs.
> 
> Very strange indeed, I have docker 20.10.2 on my Ubuntu test server and there the tests work and no "38019" is coming back for -1/unlimited . What distro are you using? I did a quick search but did not find much about the mysterious `38019` . Could this be some setting configured on your box that is picked up as an additional limit ?

I'm on Fedora 34 and have the moby distro build of docker:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1781164

-------------

PR: https://git.openjdk.java.net/jdk/pull/4518

From sgehwolf at openjdk.java.net  Fri Jul 23 12:35:11 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Fri, 23 Jul 2021 12:35:11 GMT
Subject: RFR: JDK-8266490: Extend the OSContainer API to support the pids
 controller of cgroups [v6]
In-Reply-To: <v5HmhFytrDnyrexCubsJSA0AxT5_FfrWD2yoN_2uRlQ=.a13c4127-46d4-4a94-aeca-31a99549a2bf@github.com>
References: <MWenVRe4ptn5aua0DUHvxb-sdbu-Ykl9x0GlhmxKHhY=.1fb8901e-36c3-4c07-a6ed-b653120807de@github.com>
 <g4NiARIHx5BTgvq6uoi9LqqcJRkJT2NiK_-qMrrv-H0=.bbbf85f5-8da9-467a-b5e0-b47bc8b73172@github.com>
 <80NDhQE20WOO7LMCDS9C9zYQIRy-YKqNiGgrPQAPI64=.ef6e55d9-8995-4669-9c6f-e10a61bd427f@github.com>
 <wGe0vflu7uZ8O0WsAz2OdkpjtiyXLkafQF-w5x3n1gU=.57343745-db2f-42b9-b1cb-2694a741c7f6@github.com>
 <b3tc72GBp_aSCngNXWbJFncPyTJT3mF-NoSYPqAGGlw=.bf5d98c7-62e9-46f0-bbc4-6aeb86b77a3d@github.com>
 <v5HmhFytrDnyrexCubsJSA0AxT5_FfrWD2yoN_2uRlQ=.a13c4127-46d4-4a94-aeca-31a99549a2bf@github.com>
Message-ID: <_CXJ5Lcpd7-PqzRzGAtEE4NyZzAGirYGSgVT7KbPyFw=.f2ce7164-7d28-4b6e-9a79-9417054e0113@github.com>

On Fri, 23 Jul 2021 12:28:47 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Could this be some setting configured on your box that is picked up as an additional limit ?

Possibly. Not sure where to look, though.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4518

From jpai at openjdk.java.net  Fri Jul 23 14:58:01 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Fri, 23 Jul 2021 14:58:01 GMT
Subject: RFR: 8190753: (zipfs): Accessing a large entry (> 2^31 bytes)
 leads to a negative initial size for ByteArrayOutputStream [v11]
In-Reply-To: <0GJVLeCPoDI4FePU-Z-NMwJHaS2XyH9S28LgqI1LNB8=.e32743dc-a6dd-475d-88ab-16ed3f46beab@github.com>
References: <0GJVLeCPoDI4FePU-Z-NMwJHaS2XyH9S28LgqI1LNB8=.e32743dc-a6dd-475d-88ab-16ed3f46beab@github.com>
Message-ID: <eglX2CJeKvHWYuASSDER6ClGtBUbYk3YVD9cpensiDY=.2450e7d6-9c0e-4de6-a907-d878f21a0e6e@github.com>

> Can I please get a review for this proposed fix for the issue reported in https://bugs.openjdk.java.net/browse/JDK-8190753?
> 
> The commit here checks for the size of the zip entry before trying to create a `ByteArrayOutputStream` for that entry's content. A new jtreg test has been included in this commit to reproduce the issue and verify the fix.
> 
> P.S: It's still a bit arguable whether it's a good idea to create the `ByteArrayOutputStream` with an initial size potentially as large as the `MAX_ARRAY_SIZE` or whether it's better to just use some smaller default value. However, I think that can be addressed separately while dealing with https://bugs.openjdk.java.net/browse/JDK-8011146

Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 15 additional commits since the last revision:

 - Merge latest from master branch
 - Implement review suggestions:
    - remove unnecessary "synchronized"
    - no need to open the temp file twice
 - remove no longer necessary javadoc comment on test
 - review suggestion - wrap ByteArrayOutputStream instead of extending it
 - reorganize the tests now that the temp file creation threshold isn't exposed as a user configurable value
 - minor update to comment on FileRolloverOutputStream class
 - remove no longer used constant
 - use jtreg's construct of manual test
 - Implement Alan's review suggestion - don't expose the threshold as a configuration property, instead set it internally to a specific value
 - propagate back the original checked IOException to the callers
 - ... and 5 more: https://git.openjdk.java.net/jdk/compare/d783ad9d...991de6b9

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4607/files
  - new: https://git.openjdk.java.net/jdk/pull/4607/files/9e78ba06..991de6b9

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4607&range=10
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4607&range=09-10

  Stats: 43946 lines in 1112 files changed: 20903 ins; 17871 del; 5172 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4607.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4607/head:pull/4607

PR: https://git.openjdk.java.net/jdk/pull/4607

From alanb at openjdk.java.net  Fri Jul 23 15:18:06 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 23 Jul 2021 15:18:06 GMT
Subject: RFR: 8190753: (zipfs): Accessing a large entry (> 2^31 bytes)
 leads to a negative initial size for ByteArrayOutputStream [v9]
In-Reply-To: <czBvY_lC-NcKS07rwYvYxv2SZAkznRoNSqf2uIzMm0M=.8a12ec0a-6e10-4ba6-a0b4-fc4a049149ac@github.com>
References: <0GJVLeCPoDI4FePU-Z-NMwJHaS2XyH9S28LgqI1LNB8=.e32743dc-a6dd-475d-88ab-16ed3f46beab@github.com>
 <xzX9pwzVnXSp-9Dp5BOlDRQNWZRL4mWFGeWSHTufRME=.a568319a-5c6d-451c-a023-8ea0519deae2@github.com>
 <woyZSONLQ0DEtRRSVD6kjlyXqlYYUROeN9k-DgWmeMg=.6205b3e1-c2e2-4861-a00d-4aec82e7d154@github.com>
 <czBvY_lC-NcKS07rwYvYxv2SZAkznRoNSqf2uIzMm0M=.8a12ec0a-6e10-4ba6-a0b4-fc4a049149ac@github.com>
Message-ID: <NE22Zjblp8nkZWJ3bQ-jfBpXhl-UGlbKNbgLkR49Kko=.81a6e830-d0ff-42c1-9b7c-9b91926d044b@github.com>

On Fri, 23 Jul 2021 11:57:34 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> The updated version of this PR now fixes this part to open it just once. I had reviewed this `transferTo` multiple times before, but clearly I overlooked this part of the implementation.
> 
> Thank you for these inputs. The updated PR continues to pass the new tests and the existing ones in `test/jdk/jdk/nio/zipfs/`.

The updated implementation looks okay, I don't think I have any more questions.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4607

From alanb at openjdk.java.net  Fri Jul 23 15:21:12 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 23 Jul 2021 15:21:12 GMT
Subject: RFR: 8265474: Dubious 'null' assignment in CompactByteArray.expand
In-Reply-To: <VgD5N1gsnxjI0L6HjaDWiX3Sc2FU3jBwoqw-xeSI_EI=.8b997c59-a7e9-47d7-9cfe-94c95a2b5502@github.com>
References: <VgD5N1gsnxjI0L6HjaDWiX3Sc2FU3jBwoqw-xeSI_EI=.8b997c59-a7e9-47d7-9cfe-94c95a2b5502@github.com>
Message-ID: <mxLCrIc6lzaf4T0LKyj-T6hYlBqetaEgmoeg_sK2wpo=.29cc254a-a2ea-4cc1-953b-bf56138b668e@github.com>

On Wed, 23 Dec 2020 16:06:30 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> I propose to remove 'null' assignment of field CompactByteArray.values in `expand` method. In the next statement this field is overridden with another value - `tempArray`.
> This code was there from initial load of OpenJDK sources. I believe it was just leftovers from development phase of this class. There is no practical reason to assign `null` to non-volatile field and then overwrite it with another value.
> Also I've removed unused method `getArray`. I hope it's ok to cleanup such unused stuff in the same PR.

This cleanup looks okay, @naotoj?

-------------

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1880

From alanb at openjdk.java.net  Fri Jul 23 15:24:08 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 23 Jul 2021 15:24:08 GMT
Subject: RFR: 8236569: -Xss not multiple of 4K does not work for the main
 thread on macOS [v6]
In-Reply-To: <ASrwaBWqkJnch7MykKuSxjyhFCAbr32m18Vyt62aMlE=.acf01756-1338-4c00-af9e-2f10037fb3fa@github.com>
References: <4MLFDLQaF5jyv5Nee-RfP6zREmqUk2tgSmveCDXUDWo=.b9381e50-213b-49bb-9894-933a537ef3ab@github.com>
 <ASrwaBWqkJnch7MykKuSxjyhFCAbr32m18Vyt62aMlE=.acf01756-1338-4c00-af9e-2f10037fb3fa@github.com>
Message-ID: <ZeQK11rYlMKqn3qMsXZMtN2V5I8ORdjUkjCrKvsJz5I=.2a0a7693-6c24-4008-b88f-b0ec097d58bf@github.com>

On Tue, 8 Jun 2021 16:53:38 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>> ?d on macOS
>> 
>> This patch simply round up the specified stack size to multiple of the system page size. 
>> 
>> Test is trivial, simply run java with -Xss option against following code. On MacOS, before the fix, running with `-Xss159k` and `-Xss160k` would get `7183` and `649` respectively. After fix, both would output `649`, while `-Xss161k` would be same as `-Xss164k` and see 691 as the output.
>> 
>> ```code:java
>> public class StackLeak {
>>     public int depth = 0;
>>     public void stackLeak() {
>>         depth++;
>>         stackLeak();
>>     }
>> 
>>     public static void main(String[] args) {
>>         var test = new StackLeak();
>>         try {
>>             test.stackLeak();
>>         } catch (Throwable e) {
>>             System.out.println(test.depth);
>>         }
>>     }
>> }
>
> Henry Jen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update help text

Marked as reviewed by alanb (Reviewer).

src/java.base/unix/native/libjli/java_md.c line 681:

> 679: 
> 680:     if (stack_size > 0) {
> 681:         if (EINVAL == pthread_attr_setstacksize(&attr, stack_size)) {

Style-wise it might be more consistent put EINVAL on the RHS of the ==.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4256

From jpai at openjdk.java.net  Fri Jul 23 15:26:19 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Fri, 23 Jul 2021 15:26:19 GMT
Subject: RFR: 8190753: (zipfs): Accessing a large entry (> 2^31 bytes)
 leads to a negative initial size for ByteArrayOutputStream [v11]
In-Reply-To: <eglX2CJeKvHWYuASSDER6ClGtBUbYk3YVD9cpensiDY=.2450e7d6-9c0e-4de6-a907-d878f21a0e6e@github.com>
References: <0GJVLeCPoDI4FePU-Z-NMwJHaS2XyH9S28LgqI1LNB8=.e32743dc-a6dd-475d-88ab-16ed3f46beab@github.com>
 <eglX2CJeKvHWYuASSDER6ClGtBUbYk3YVD9cpensiDY=.2450e7d6-9c0e-4de6-a907-d878f21a0e6e@github.com>
Message-ID: <2ttMZAIqSLz7XfsDi0CQjsaApF19Vk68hNNgh_WDIw0=.a4b275b9-3ce9-4101-9dfd-0db920386eb1@github.com>

On Fri, 23 Jul 2021 14:58:01 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this proposed fix for the issue reported in https://bugs.openjdk.java.net/browse/JDK-8190753?
>> 
>> The commit here checks for the size of the zip entry before trying to create a `ByteArrayOutputStream` for that entry's content. A new jtreg test has been included in this commit to reproduce the issue and verify the fix.
>> 
>> P.S: It's still a bit arguable whether it's a good idea to create the `ByteArrayOutputStream` with an initial size potentially as large as the `MAX_ARRAY_SIZE` or whether it's better to just use some smaller default value. However, I think that can be addressed separately while dealing with https://bugs.openjdk.java.net/browse/JDK-8011146
>
> Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 15 additional commits since the last revision:
> 
>  - Merge latest from master branch
>  - Implement review suggestions:
>     - remove unnecessary "synchronized"
>     - no need to open the temp file twice
>  - remove no longer necessary javadoc comment on test
>  - review suggestion - wrap ByteArrayOutputStream instead of extending it
>  - reorganize the tests now that the temp file creation threshold isn't exposed as a user configurable value
>  - minor update to comment on FileRolloverOutputStream class
>  - remove no longer used constant
>  - use jtreg's construct of manual test
>  - Implement Alan's review suggestion - don't expose the threshold as a configuration property, instead set it internally to a specific value
>  - propagate back the original checked IOException to the callers
>  - ... and 5 more: https://git.openjdk.java.net/jdk/compare/e1196067...991de6b9

Thank you for the review Alan.

@LanceAndersen, I've run the tier1 tests locally with the latest PR and they have passed without any regressions. Given that we changed the implementation to wrap ByteArrayOutputStream instead of extending it, would you want to rerun some of your other tests that you had previously run, before I integrate this?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4607

From alanb at openjdk.java.net  Fri Jul 23 15:30:07 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 23 Jul 2021 15:30:07 GMT
Subject: RFR: 8268873: Unnecessary Vector usage in java.base
In-Reply-To: <77cFcWG1ejeaZ87GNO3D1Jj5JKBAgSxgb-4Tvzi71ts=.666dfd29-4159-4ebd-ae00-5ac64816c771@github.com>
References: <RiYSRALAstA3O6-B_kVJ6HPAb7K47Ps-6LpSgsedK98=.5ab809ba-5870-4160-b6ec-f6625b417ddb@github.com>
 <77cFcWG1ejeaZ87GNO3D1Jj5JKBAgSxgb-4Tvzi71ts=.666dfd29-4159-4ebd-ae00-5ac64816c771@github.com>
Message-ID: <7ss8rAI-Yo8YnSkBEGOBYesUG72udl_Ie6zMvDCXQ4s=.acd0986b-b2c3-4caa-968b-b4f2068cf860@github.com>

On Fri, 18 Jun 2021 18:28:26 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Usage of thread-safe collection `Vector` is unnecessary. It's recommended to use `ArrayList` if a thread-safe implementation is not needed. In post-BiasedLocking times, this is gets worse, as every access is synchronized.
>> I checked only places where `Vector` was used as local variable.
>
> The change to `PKCS7::verify(byte[])` looks fine.

@seanjmullan Are you planning to sponsor this?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4482

From lancea at openjdk.java.net  Fri Jul 23 16:25:03 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Fri, 23 Jul 2021 16:25:03 GMT
Subject: RFR: 8190753: (zipfs): Accessing a large entry (> 2^31 bytes)
 leads to a negative initial size for ByteArrayOutputStream [v11]
In-Reply-To: <2ttMZAIqSLz7XfsDi0CQjsaApF19Vk68hNNgh_WDIw0=.a4b275b9-3ce9-4101-9dfd-0db920386eb1@github.com>
References: <0GJVLeCPoDI4FePU-Z-NMwJHaS2XyH9S28LgqI1LNB8=.e32743dc-a6dd-475d-88ab-16ed3f46beab@github.com>
 <eglX2CJeKvHWYuASSDER6ClGtBUbYk3YVD9cpensiDY=.2450e7d6-9c0e-4de6-a907-d878f21a0e6e@github.com>
 <2ttMZAIqSLz7XfsDi0CQjsaApF19Vk68hNNgh_WDIw0=.a4b275b9-3ce9-4101-9dfd-0db920386eb1@github.com>
Message-ID: <27fDIfBum2vSv7DmFs_PH8Z27NAYMVeMUmAa6OOJgfI=.b125d8c7-83a0-48d5-8342-d0da696fdbff@github.com>

On Fri, 23 Jul 2021 15:23:07 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Thank you for the review Alan.
> 
> @LanceAndersen, I've run the tier1 tests locally with the latest PR and they have passed without any regressions. Given that we changed the implementation to wrap ByteArrayOutputStream instead of extending it, would you want to rerun some of your other tests that you had previously run, before I integrate this?

Yes, I will run additional tests and report back after they complete

-------------

PR: https://git.openjdk.java.net/jdk/pull/4607

From naoto at openjdk.java.net  Fri Jul 23 17:03:09 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 23 Jul 2021 17:03:09 GMT
Subject: RFR: 8265474: Dubious 'null' assignment in CompactByteArray.expand
In-Reply-To: <VgD5N1gsnxjI0L6HjaDWiX3Sc2FU3jBwoqw-xeSI_EI=.8b997c59-a7e9-47d7-9cfe-94c95a2b5502@github.com>
References: <VgD5N1gsnxjI0L6HjaDWiX3Sc2FU3jBwoqw-xeSI_EI=.8b997c59-a7e9-47d7-9cfe-94c95a2b5502@github.com>
Message-ID: <67RqXewcQPMo14W02JuOSDpi3eRVWaeHfdtrPYBjc2k=.226bbc6c-1593-42b3-ac24-ba11ccee0f38@github.com>

On Wed, 23 Dec 2020 16:06:30 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> I propose to remove 'null' assignment of field CompactByteArray.values in `expand` method. In the next statement this field is overridden with another value - `tempArray`.
> This code was there from initial load of OpenJDK sources. I believe it was just leftovers from development phase of this class. There is no practical reason to assign `null` to non-volatile field and then overwrite it with another value.
> Also I've removed unused method `getArray`. I hope it's ok to cleanup such unused stuff in the same PR.

Yes, it does.

-------------

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1880

From mullan at openjdk.java.net  Fri Jul 23 17:06:06 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Fri, 23 Jul 2021 17:06:06 GMT
Subject: RFR: 8268873: Unnecessary Vector usage in java.base
In-Reply-To: <77cFcWG1ejeaZ87GNO3D1Jj5JKBAgSxgb-4Tvzi71ts=.666dfd29-4159-4ebd-ae00-5ac64816c771@github.com>
References: <RiYSRALAstA3O6-B_kVJ6HPAb7K47Ps-6LpSgsedK98=.5ab809ba-5870-4160-b6ec-f6625b417ddb@github.com>
 <77cFcWG1ejeaZ87GNO3D1Jj5JKBAgSxgb-4Tvzi71ts=.666dfd29-4159-4ebd-ae00-5ac64816c771@github.com>
Message-ID: <2Snt76xMeYT8vZi0EmdlB-KaaopCmWV-zSU8qy-_Tzk=.deccb518-b7e2-49d3-a489-7db9c230f0a6@github.com>

On Fri, 18 Jun 2021 18:28:26 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Usage of thread-safe collection `Vector` is unnecessary. It's recommended to use `ArrayList` if a thread-safe implementation is not needed. In post-BiasedLocking times, this is gets worse, as every access is synchronized.
>> I checked only places where `Vector` was used as local variable.
>
> The change to `PKCS7::verify(byte[])` looks fine.

> @seanjmullan Are you planning to sponsor this?

Yes, I can do that, but I will wait until Monday in case there are any post-integration issues that I need to follow up on.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4482

From naoto at openjdk.java.net  Fri Jul 23 17:35:25 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 23 Jul 2021 17:35:25 GMT
Subject: RFR: 8171382: java.time.Duration missing isPositive method
Message-ID: <ogy5GwKye8RhHJDyZwTzW4IFamPpEOzpK7BRuqpL1FE=.f2f3ecec-7388-42d5-aee9-3754dcb649db@github.com>

Please review this PR to introduce `java.time.Duration.isPositive()` method. A CSR is also drafted.

-------------

Commit messages:
 - 8171382: java.time.Duration missing isPositive method

Changes: https://git.openjdk.java.net/jdk/pull/4892/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4892&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8171382
  Stats: 31 lines in 2 files changed: 30 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4892.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4892/head:pull/4892

PR: https://git.openjdk.java.net/jdk/pull/4892

From rriggs at openjdk.java.net  Fri Jul 23 18:06:07 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 23 Jul 2021 18:06:07 GMT
Subject: RFR: 8171382: java.time.Duration missing isPositive method
In-Reply-To: <ogy5GwKye8RhHJDyZwTzW4IFamPpEOzpK7BRuqpL1FE=.f2f3ecec-7388-42d5-aee9-3754dcb649db@github.com>
References: <ogy5GwKye8RhHJDyZwTzW4IFamPpEOzpK7BRuqpL1FE=.f2f3ecec-7388-42d5-aee9-3754dcb649db@github.com>
Message-ID: <lexxmCX4Yp4f-9rNe3wOF9cY1fMO_Ne8CwJJsQjLZRQ=.13701aa6-4827-46e3-9a2c-5a021f44038d@github.com>

On Fri, 23 Jul 2021 17:27:27 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Please review this PR to introduce `java.time.Duration.isPositive()` method. A CSR is also drafted.

In the CSR, I would omit the "which is odd" from the "Problem".
and in the Solution, replace "integrity" with "completeness".

-------------

Marked as reviewed by rriggs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4892

From naoto at openjdk.java.net  Fri Jul 23 18:09:03 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 23 Jul 2021 18:09:03 GMT
Subject: RFR: 8171382: java.time.Duration missing isPositive method
In-Reply-To: <ogy5GwKye8RhHJDyZwTzW4IFamPpEOzpK7BRuqpL1FE=.f2f3ecec-7388-42d5-aee9-3754dcb649db@github.com>
References: <ogy5GwKye8RhHJDyZwTzW4IFamPpEOzpK7BRuqpL1FE=.f2f3ecec-7388-42d5-aee9-3754dcb649db@github.com>
Message-ID: <S7CDes17pdmXRVIqyLtF0rlbb-feG0SYBO1PP5Fz1Ms=.3861f588-00c8-458e-bc9e-513302081684@github.com>

On Fri, 23 Jul 2021 17:27:27 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Please review this PR to introduce `java.time.Duration.isPositive()` method. A CSR is also drafted.

Thanks, Roger. Modified the CSR as suggested.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4892

From github.com+6394632+sercher at openjdk.java.net  Fri Jul 23 18:10:16 2021
From: github.com+6394632+sercher at openjdk.java.net (Sergey Chernyshev)
Date: Fri, 23 Jul 2021 18:10:16 GMT
Subject: RFR: 8270321: Startup regressions in 18-b5 caused by JDK-8266310
Message-ID: <W0x401I1NqmAUe7fn05M-YVVBaP1yD98xoXz0kNw5UM=.a60b4e7d-c7e9-406e-bde4-1341519a439a@github.com>

Dear colleagues,

Please review the patch that replaces the lambdas with anonymous classes which solves the startup time regression as shown below.

I attached the Bytestacks flamegraphs for both original (regression) and fixed versions. The flamegraphs clearly show the lambdas were causing the performance issue.

[bytestacks_flamegraphs.zip](https://github.com/openjdk/jdk/files/6870446/bytestacks_flamegraphs.zip)

Although the proposed JDK-8270321 patch fixes the startup time (it might appear even better than it was before the regression was introduced, i.e. before JDK-8266310), it increases MaxRSS slightly compared to the version before JDK-8266310, which is shown in the below graphs.

![StartupTime](https://user-images.githubusercontent.com/6394632/126822380-5b01ce90-b249-4294-9a62-8269440f942d.png)

![MaxRSS](https://user-images.githubusercontent.com/6394632/126822404-899ab904-efc1-4377-9e0d-d8cdb5c0e5d0.png)

I additionally include the heap objects histograms to show the change does not increase the total live objects size significantly with only 1000 bytes the total difference, namely 1116128 bytes in 25002 live objects after the proposed fix JDK-8270321 compared to 1115128 bytes in 24990 objects in the version with the original patch reverted (i.e. before JDK-8266310).

[histograms.zip](https://github.com/openjdk/jdk/files/6870457/histograms.zip)

-------------

Commit messages:
 - 8270321: Startup regressions in 18-b5 caused by JDK-8266310

Changes: https://git.openjdk.java.net/jdk/pull/4893/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4893&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8270321
  Stats: 35 lines in 1 file changed: 17 ins; 3 del; 15 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4893.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4893/head:pull/4893

PR: https://git.openjdk.java.net/jdk/pull/4893

From joehw at openjdk.java.net  Fri Jul 23 18:47:00 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Fri, 23 Jul 2021 18:47:00 GMT
Subject: RFR: 8171382: java.time.Duration missing isPositive method
In-Reply-To: <ogy5GwKye8RhHJDyZwTzW4IFamPpEOzpK7BRuqpL1FE=.f2f3ecec-7388-42d5-aee9-3754dcb649db@github.com>
References: <ogy5GwKye8RhHJDyZwTzW4IFamPpEOzpK7BRuqpL1FE=.f2f3ecec-7388-42d5-aee9-3754dcb649db@github.com>
Message-ID: <Mwd5uKxqbRmzldLTVJIvxHbacfFXLL0z9h6nY-SPw5E=.0861900e-f62d-4825-97d2-8be4b448d359@github.com>

On Fri, 23 Jul 2021 17:27:27 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Please review this PR to introduce `java.time.Duration.isPositive()` method. A CSR is also drafted.

Marked as reviewed by joehw (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4892

From iris at openjdk.java.net  Fri Jul 23 18:56:09 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Fri, 23 Jul 2021 18:56:09 GMT
Subject: RFR: 8199594: Add doc describing how (?x) ignores spaces in
 character classes [v3]
In-Reply-To: <MxS-oZAbpbzC7VQWxsYuSAgIm7jn_l1dB3_VlTR-Gd8=.417331e1-9304-4d1d-8934-5179b11d84ed@github.com>
References: <nZMkehSmeX8-0XBaLVpBCUc8Kabl1RimMvWLrX6JOYc=.9d5f58a0-639a-489d-bf85-33cf9af615f2@github.com>
 <MxS-oZAbpbzC7VQWxsYuSAgIm7jn_l1dB3_VlTR-Gd8=.417331e1-9304-4d1d-8934-5179b11d84ed@github.com>
Message-ID: <C0amrLGPjMopq3bL8dK-xe72oN1E1LckGtoXaDihTgI=.661b3f74-b7da-4f06-97d7-270767f154bc@github.com>

On Thu, 22 Jul 2021 01:46:09 GMT, Ian Graves <igraves at openjdk.org> wrote:

>> 8199594: Add doc describing how (?x) ignores spaces in character classes
>
> Ian Graves has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rewording repetitive phrase

Marked as reviewed by iris (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4618

From forax at openjdk.java.net  Fri Jul 23 18:57:05 2021
From: forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Fri, 23 Jul 2021 18:57:05 GMT
Subject: RFR: 8270321: Startup regressions in 18-b5 caused by JDK-8266310
In-Reply-To: <W0x401I1NqmAUe7fn05M-YVVBaP1yD98xoXz0kNw5UM=.a60b4e7d-c7e9-406e-bde4-1341519a439a@github.com>
References: <W0x401I1NqmAUe7fn05M-YVVBaP1yD98xoXz0kNw5UM=.a60b4e7d-c7e9-406e-bde4-1341519a439a@github.com>
Message-ID: <CbnVwENJCdEXt-ATQy4JHsoEkSt0W9Q24x8sqE20n9Q=.0b0c5b3d-663b-4d4b-8f1e-d50576722c9e@github.com>

On Fri, 23 Jul 2021 18:03:31 GMT, Sergey Chernyshev <github.com+6394632+sercher at openjdk.org> wrote:

> Dear colleagues,
> 
> Please review the patch that replaces the lambdas with anonymous classes which solves the startup time regression as shown below.
> 
> I attached the Bytestacks flamegraphs for both original (regression) and fixed versions. The flamegraphs clearly show the lambdas were causing the performance issue.
> 
> [bytestacks_flamegraphs.zip](https://github.com/openjdk/jdk/files/6870446/bytestacks_flamegraphs.zip)
> 
> Although the proposed JDK-8270321 patch fixes the startup time (it might appear even better than it was before the regression was introduced, i.e. before JDK-8266310), it increases MaxRSS slightly compared to the version before JDK-8266310, which is shown in the below graphs.
> 
> ![StartupTime](https://user-images.githubusercontent.com/6394632/126822380-5b01ce90-b249-4294-9a62-8269440f942d.png)
> 
> ![MaxRSS](https://user-images.githubusercontent.com/6394632/126822404-899ab904-efc1-4377-9e0d-d8cdb5c0e5d0.png)
> 
> I additionally include the heap objects histograms to show the change does not increase the total live objects size significantly with only 1000 bytes the total difference, namely 1116128 bytes in 25002 live objects after the proposed fix JDK-8270321 compared to 1115128 bytes in 24990 objects in the version with the original patch reverted (i.e. before JDK-8266310).
> 
> [histograms.zip](https://github.com/openjdk/jdk/files/6870457/histograms.zip)
> 
> The patch was tested w/hotspot/tier1/tier2 test groups.

I don't understand your analysis, you are testing the startup time with -Xint which disable JITs, but there is no mention of -Xint in the bug report.
It's obvious to me that there is a regression with -Xint given that the lambda creation is using invokedynamic which is only optimizable by JITs. 

I think you should first try to reproduce the issue with the correct flags and then follow the advice from Mandy on how to implement the fix. Using an anonymous class may introduce more allocation than using a lambda once the code is JITed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4893

From lancea at openjdk.java.net  Fri Jul 23 19:02:03 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Fri, 23 Jul 2021 19:02:03 GMT
Subject: RFR: 8199594: Add doc describing how (?x) ignores spaces in
 character classes [v3]
In-Reply-To: <MxS-oZAbpbzC7VQWxsYuSAgIm7jn_l1dB3_VlTR-Gd8=.417331e1-9304-4d1d-8934-5179b11d84ed@github.com>
References: <nZMkehSmeX8-0XBaLVpBCUc8Kabl1RimMvWLrX6JOYc=.9d5f58a0-639a-489d-bf85-33cf9af615f2@github.com>
 <MxS-oZAbpbzC7VQWxsYuSAgIm7jn_l1dB3_VlTR-Gd8=.417331e1-9304-4d1d-8934-5179b11d84ed@github.com>
Message-ID: <1-y6-HfnqhYj_B44exLw_RXKvKD0uG7G6sJMee17zh0=.8f8fa37c-65a8-4df9-b529-3518826d78d8@github.com>

On Thu, 22 Jul 2021 01:46:09 GMT, Ian Graves <igraves at openjdk.org> wrote:

>> 8199594: Add doc describing how (?x) ignores spaces in character classes
>
> Ian Graves has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rewording repetitive phrase

Marked as reviewed by lancea (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4618

From iris at openjdk.java.net  Fri Jul 23 19:06:05 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Fri, 23 Jul 2021 19:06:05 GMT
Subject: RFR: 8171382: java.time.Duration missing isPositive method
In-Reply-To: <ogy5GwKye8RhHJDyZwTzW4IFamPpEOzpK7BRuqpL1FE=.f2f3ecec-7388-42d5-aee9-3754dcb649db@github.com>
References: <ogy5GwKye8RhHJDyZwTzW4IFamPpEOzpK7BRuqpL1FE=.f2f3ecec-7388-42d5-aee9-3754dcb649db@github.com>
Message-ID: <dqR4mv37iagpmfP-6rK2rjHTdMFaVMYG1JgBAiTSA40=.16f7f7a7-2858-484b-8e87-6dbbe80f988a@github.com>

On Fri, 23 Jul 2021 17:27:27 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Please review this PR to introduce `java.time.Duration.isPositive()` method. A CSR is also drafted.

Looks good!  I've also Reviewed the associated CSR.

-------------

Marked as reviewed by iris (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4892

From bpb at openjdk.java.net  Fri Jul 23 19:12:06 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Fri, 23 Jul 2021 19:12:06 GMT
Subject: RFR: 8199594: Add doc describing how (?x) ignores spaces in
 character classes [v3]
In-Reply-To: <MxS-oZAbpbzC7VQWxsYuSAgIm7jn_l1dB3_VlTR-Gd8=.417331e1-9304-4d1d-8934-5179b11d84ed@github.com>
References: <nZMkehSmeX8-0XBaLVpBCUc8Kabl1RimMvWLrX6JOYc=.9d5f58a0-639a-489d-bf85-33cf9af615f2@github.com>
 <MxS-oZAbpbzC7VQWxsYuSAgIm7jn_l1dB3_VlTR-Gd8=.417331e1-9304-4d1d-8934-5179b11d84ed@github.com>
Message-ID: <kEGW2IfdCwMqLqYmduVhYMhN4fqFjQ1A7BxZG0Fznv8=.5845341a-bcd8-41f2-9015-e5b471b5485d@github.com>

On Thu, 22 Jul 2021 01:46:09 GMT, Ian Graves <igraves at openjdk.org> wrote:

>> 8199594: Add doc describing how (?x) ignores spaces in character classes
>
> Ian Graves has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rewording repetitive phrase

Marked as reviewed by bpb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4618

From bpb at openjdk.java.net  Fri Jul 23 19:13:02 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Fri, 23 Jul 2021 19:13:02 GMT
Subject: RFR: 8171382: java.time.Duration missing isPositive method
In-Reply-To: <ogy5GwKye8RhHJDyZwTzW4IFamPpEOzpK7BRuqpL1FE=.f2f3ecec-7388-42d5-aee9-3754dcb649db@github.com>
References: <ogy5GwKye8RhHJDyZwTzW4IFamPpEOzpK7BRuqpL1FE=.f2f3ecec-7388-42d5-aee9-3754dcb649db@github.com>
Message-ID: <DFgvBRhEQxbgkISe0WOM8CgDPLoSffgkNJm4eVOk338=.96199948-f29b-4dd9-a90a-68ac9d5fab24@github.com>

On Fri, 23 Jul 2021 17:27:27 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Please review this PR to introduce `java.time.Duration.isPositive()` method. A CSR is also drafted.

Marked as reviewed by bpb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4892

From igraves at openjdk.java.net  Fri Jul 23 19:21:11 2021
From: igraves at openjdk.java.net (Ian Graves)
Date: Fri, 23 Jul 2021 19:21:11 GMT
Subject: Integrated: 8199594: Add doc describing how (?x) ignores spaces in
 character classes
In-Reply-To: <nZMkehSmeX8-0XBaLVpBCUc8Kabl1RimMvWLrX6JOYc=.9d5f58a0-639a-489d-bf85-33cf9af615f2@github.com>
References: <nZMkehSmeX8-0XBaLVpBCUc8Kabl1RimMvWLrX6JOYc=.9d5f58a0-639a-489d-bf85-33cf9af615f2@github.com>
Message-ID: <MOR-3d5kO79JuHRkPyNDEq3tjDgfycC29rU6PIWqEto=.b847b4fb-9f30-4260-92da-1aa515090665@github.com>

On Mon, 28 Jun 2021 20:50:42 GMT, Ian Graves <igraves at openjdk.org> wrote:

> 8199594: Add doc describing how (?x) ignores spaces in character classes

This pull request has now been integrated.

Changeset: a1c0a6aa
Author:    Ian Graves <igraves at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a1c0a6aafb575e3d5c76dd3a279e4fe03ca07223
Stats:     11 lines in 1 file changed: 10 ins; 0 del; 1 mod

8199594: Add doc describing how (?x) ignores spaces in character classes

Reviewed-by: darcy, naoto, iris, lancea, bpb

-------------

PR: https://git.openjdk.java.net/jdk/pull/4618

From scolebourne at openjdk.java.net  Fri Jul 23 19:41:02 2021
From: scolebourne at openjdk.java.net (Stephen Colebourne)
Date: Fri, 23 Jul 2021 19:41:02 GMT
Subject: RFR: 8171382: java.time.Duration missing isPositive method
In-Reply-To: <ogy5GwKye8RhHJDyZwTzW4IFamPpEOzpK7BRuqpL1FE=.f2f3ecec-7388-42d5-aee9-3754dcb649db@github.com>
References: <ogy5GwKye8RhHJDyZwTzW4IFamPpEOzpK7BRuqpL1FE=.f2f3ecec-7388-42d5-aee9-3754dcb649db@github.com>
Message-ID: <DpPTpeGg3REJ5xhUuQdN2oykFtshwqKpG78CL4blVU8=.ea591300-43b2-45e0-ad72-d6dc073d2189@github.com>

On Fri, 23 Jul 2021 17:27:27 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Please review this PR to introduce `java.time.Duration.isPositive()` method. A CSR is also drafted.

Marked as reviewed by scolebourne (Author).

src/java.base/share/classes/java/time/Duration.java line 596:

> 594:      */
> 595:     public boolean isPositive() {
> 596:         return (seconds | nanos) > 0;

I had to think whether this logic is correct, but I believe it is because `nanos` is 32 bits and positive so won't impact the negative bit of `seconds`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4892

From naoto at openjdk.java.net  Fri Jul 23 20:03:06 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 23 Jul 2021 20:03:06 GMT
Subject: RFR: 8171382: java.time.Duration missing isPositive method
In-Reply-To: <DpPTpeGg3REJ5xhUuQdN2oykFtshwqKpG78CL4blVU8=.ea591300-43b2-45e0-ad72-d6dc073d2189@github.com>
References: <ogy5GwKye8RhHJDyZwTzW4IFamPpEOzpK7BRuqpL1FE=.f2f3ecec-7388-42d5-aee9-3754dcb649db@github.com>
 <DpPTpeGg3REJ5xhUuQdN2oykFtshwqKpG78CL4blVU8=.ea591300-43b2-45e0-ad72-d6dc073d2189@github.com>
Message-ID: <wo96y_YrRzJBOHGLtpWdfMQ1UFRp-FQY_PHi1iQIeWQ=.9dd7a75f-1c0f-4749-bc8b-dd3c35ad70ad@github.com>

On Fri, 23 Jul 2021 19:37:44 GMT, Stephen Colebourne <scolebourne at openjdk.org> wrote:

>> Please review this PR to introduce `java.time.Duration.isPositive()` method. A CSR is also drafted.
>
> src/java.base/share/classes/java/time/Duration.java line 596:
> 
>> 594:      */
>> 595:     public boolean isPositive() {
>> 596:         return (seconds | nanos) > 0;
> 
> I had to think whether this logic is correct, but I believe it is because `nanos` is 32 bits and positive so won't impact the negative bit of `seconds`.

Thanks, Stephen. Yes, `nanos` is even smaller, less than `1,000,000,000`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4892

From github.com+6394632+sercher at openjdk.java.net  Sun Jul 25 12:10:07 2021
From: github.com+6394632+sercher at openjdk.java.net (Sergey Chernyshev)
Date: Sun, 25 Jul 2021 12:10:07 GMT
Subject: RFR: 8270321: Startup regressions in 18-b5 caused by JDK-8266310
In-Reply-To: <W0x401I1NqmAUe7fn05M-YVVBaP1yD98xoXz0kNw5UM=.a60b4e7d-c7e9-406e-bde4-1341519a439a@github.com>
References: <W0x401I1NqmAUe7fn05M-YVVBaP1yD98xoXz0kNw5UM=.a60b4e7d-c7e9-406e-bde4-1341519a439a@github.com>
Message-ID: <jGPSdHro6gV_SfIS_cvtL4HF0uhoBJjTDoCRceNHWyg=.d7250b16-ab78-427d-a998-4d3b09128e28@github.com>

On Fri, 23 Jul 2021 18:03:31 GMT, Sergey Chernyshev <github.com+6394632+sercher at openjdk.org> wrote:

> Dear colleagues,
> 
> Please review the patch that replaces the lambdas with anonymous classes which solves the startup time regression as shown below.
> 
> I attached the Bytestacks flamegraphs for both original (regression) and fixed versions. The flamegraphs clearly show the lambdas were causing the performance issue.
> 
> [bytestacks_flamegraphs.zip](https://github.com/openjdk/jdk/files/6870446/bytestacks_flamegraphs.zip)
> 
> Although the proposed JDK-8270321 patch fixes the startup time (it might appear even better than it was before the regression was introduced, i.e. before JDK-8266310) and generally fixed the footprint regression, it may increase MaxRSS slightly compared to the version before JDK-8266310, which is shown in the below graphs. (updated)
> 
> ![StartupTime2](https://user-images.githubusercontent.com/6394632/126898224-a05fda62-f723-4f2c-9af9-e02cbfe1c9c8.png)
> 
> ![MaxRSS](https://user-images.githubusercontent.com/6394632/126822404-899ab904-efc1-4377-9e0d-d8cdb5c0e5d0.png)
> 
> (update: added ZGC graphs)
> 
> ![StartupTime_ZGC](https://user-images.githubusercontent.com/6394632/126898242-52c09582-c2a4-4623-aad2-f47055277193.png)
> 
> ![MaxRSS_ZGC](https://user-images.githubusercontent.com/6394632/126898244-31c3eeb5-a768-4a52-8960-960cc4a72d7b.png)
> 
> I additionally include the heap objects histograms to show the change does not increase the total live objects size significantly with only 1000 bytes the total difference, namely 1116128 bytes in 25002 live objects after the proposed fix JDK-8270321 compared to 1115128 bytes in 24990 objects in the version with the original patch reverted (i.e. before JDK-8266310).
> 
> [histograms.zip](https://github.com/openjdk/jdk/files/6870457/histograms.zip)
> 
> The patch was tested w/hotspot/tier1/tier2 test groups.

Hi R?mi,
> 
> I don't understand your analysis, you are testing the startup time with -Xint which disable JITs, but there is no mention of -Xint in the bug report.
> It's obvious to me that there is a regression with -Xint given that the lambda creation is using invokedynamic which is only optimizable by JITs.

I apologize, perhaps I wasn't quite clear describing the analysis. Also, there was a faulty picture, -Xint was only used to grab the opcode traces to build the flamegraphs. I replaced the faulty image and posted additional graphs with -XX:+UseZGC.
Performance (startup) testing, as well as the live objects dumps were obtained with JIT enabled and with G1GC and ZGC. Would you think more data is needed with -Xint? (in addition to the flamegraphs which are obtained with -Xint)

> 
> I think you should first try to reproduce the issue with the correct flags and then follow the advice from Mandy on how to implement the fix.

In my opinion removing computeXXX methods defeats the purpose of the entire deadlock fix. It is sufficient to avoid using lambdas in order not to trigger the method handles initialization, which is what Mandy Chung is really suggesting in the first note in [JBS](https://bugs.openjdk.java.net/browse/JDK-8270321).

> 
> Using an anonymous class may introduce more allocation than using a lambda once the code is JITed.

I provided live objects dumps after noop.jar has been loaded with JIT enabled. Please see the attached histograms. The difference is always the same after full GC (1000 bytes in 12 objects compared to pre JDK-8266310 version tested w/G1) and it doesn't change with subsequent executions. The patch resolves the memory regression as you may observe in RSS graphs and heap dumps. Please see 'fixed.histogram' in comparison with the object dump before the fix (post JDK-8266310) in 'original.histogram'.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4893

From alanb at openjdk.java.net  Sun Jul 25 14:11:12 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sun, 25 Jul 2021 14:11:12 GMT
Subject: RFR: 8270321: Startup regressions in 18-b5 caused by JDK-8266310
In-Reply-To: <jGPSdHro6gV_SfIS_cvtL4HF0uhoBJjTDoCRceNHWyg=.d7250b16-ab78-427d-a998-4d3b09128e28@github.com>
References: <W0x401I1NqmAUe7fn05M-YVVBaP1yD98xoXz0kNw5UM=.a60b4e7d-c7e9-406e-bde4-1341519a439a@github.com>
 <jGPSdHro6gV_SfIS_cvtL4HF0uhoBJjTDoCRceNHWyg=.d7250b16-ab78-427d-a998-4d3b09128e28@github.com>
Message-ID: <wDDaZRhrd_u-qdTRPqjvIpNno8lWAW37Oc6Dza4EU9U=.0a4dae7b-c880-4a4c-ad14-3809a2f47309@github.com>

On Sun, 25 Jul 2021 12:06:49 GMT, Sergey Chernyshev <github.com+6394632+sercher at openjdk.org> wrote:

> I don't understand your analysis, you are testing the startup time with -Xint which disable JITs, but there is no mention of -Xint in the bug report.
> It's obvious to me that there is a regression with -Xint given that the lambda creation is using invokedynamic which is only optimizable by JITs.

Eric Caspole (the submitter) may be able to share more data but the startup regression looks plausible given that this code executes early in the startup.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4893

From lancea at openjdk.java.net  Sun Jul 25 22:04:40 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Sun, 25 Jul 2021 22:04:40 GMT
Subject: RFR: 8251329: (zipfs) Files.walkFileTree walks infinitely if zip has
 dir named "." inside
Message-ID: <BnwVE1xrk_yNwA-SSQWdU-s3Q6aWxeoNn2udHvQi9QE=.40ebc385-34fd-4be1-98ea-1514c46c89fb@github.com>

Hi,

As discussed in the https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-July/079621.html thread, this is the revised patch to address the use of '.' and '..' within Zip FS

Zip FS needs to use "." and ".." as links to the current and parent directories and cannot reliably support entries that have "." and ".." as name elements.  This patch updates Zip Fs  to reject ZIP files that have entries in the CEN that can't be used for files in a file system.


Mach5 tiers 1 through 3 have been run without any errors encountered .

Best,
Lance

-------------

Commit messages:
 - Address missing linefeed  after package name
 - Address overzelous intellij import update
 - Patch to address JDK-8251329

Changes: https://git.openjdk.java.net/jdk/pull/4900/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4900&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8251329
  Stats: 174 lines in 2 files changed: 174 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4900.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4900/head:pull/4900

PR: https://git.openjdk.java.net/jdk/pull/4900

From lzang at openjdk.java.net  Mon Jul 26 03:28:44 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Mon, 26 Jul 2021 03:28:44 GMT
Subject: RFR: 4890732: GZIPOutputStream doesn't support optional GZIP
 fields [v9]
In-Reply-To: <DKXYUELjj1BRxIwULHr8Ocm0DY4I6ngRFJ7eog1Miew=.c080fccf-a2b0-46cc-9e4a-306c226cce3c@github.com>
References: <DKXYUELjj1BRxIwULHr8Ocm0DY4I6ngRFJ7eog1Miew=.c080fccf-a2b0-46cc-9e4a-306c226cce3c@github.com>
Message-ID: <j7YPtBR8ylz-kuKwNVPgR8v2Tj2bAU7DE7UNr7G7mO4=.ef19d436-f320-460e-9c0d-6610ec7db5f6@github.com>

> 4890732: GZIPOutputStream doesn't support optional GZIP fields

Lin Zang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:

 - change since version to 18
 - Merge branch 'master' into gzip-field
 - Merge branch 'master' into gzip-field
 - Add api in GZIPInputStream to get header data
 - Merge remote-tracking branch 'upstream/master' into gzip-field
 - remove trailing spaces
 - Use record and Builder pattern
 - add class GZIPHeaderData, refine testcases
 - update copyright
 - reuse arguments constructor for non-argument one.
 - ... and 3 more: https://git.openjdk.java.net/jdk/compare/e627caec...b1868e8f

-------------

Changes: https://git.openjdk.java.net/jdk/pull/3072/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3072&range=08
  Stats: 635 lines in 4 files changed: 585 ins; 26 del; 24 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3072.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3072/head:pull/3072

PR: https://git.openjdk.java.net/jdk/pull/3072

From lzang at openjdk.java.net  Mon Jul 26 03:35:23 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Mon, 26 Jul 2021 03:35:23 GMT
Subject: RFR: 4890732: GZIPOutputStream doesn't support optional GZIP
 fields [v9]
In-Reply-To: <j7YPtBR8ylz-kuKwNVPgR8v2Tj2bAU7DE7UNr7G7mO4=.ef19d436-f320-460e-9c0d-6610ec7db5f6@github.com>
References: <DKXYUELjj1BRxIwULHr8Ocm0DY4I6ngRFJ7eog1Miew=.c080fccf-a2b0-46cc-9e4a-306c226cce3c@github.com>
 <j7YPtBR8ylz-kuKwNVPgR8v2Tj2bAU7DE7UNr7G7mO4=.ef19d436-f320-460e-9c0d-6610ec7db5f6@github.com>
Message-ID: <bHwR9QtfgFGCwYtRQd3Pm1C6zkY91zFNhwJz0haESwQ=.e6042907-cbd2-4c6f-9fcc-95e2ca1231d6@github.com>

On Mon, 26 Jul 2021 03:28:44 GMT, Lin Zang <lzang at openjdk.org> wrote:

>> 4890732: GZIPOutputStream doesn't support optional GZIP fields
>
> Lin Zang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:
> 
>  - change since version to 18
>  - Merge branch 'master' into gzip-field
>  - Merge branch 'master' into gzip-field
>  - Add api in GZIPInputStream to get header data
>  - Merge remote-tracking branch 'upstream/master' into gzip-field
>  - remove trailing spaces
>  - Use record and Builder pattern
>  - add class GZIPHeaderData, refine testcases
>  - update copyright
>  - reuse arguments constructor for non-argument one.
>  - ... and 3 more: https://git.openjdk.java.net/jdk/compare/e627caec...b1868e8f

Dear All, 
   I have updated the CSR with the latest change. https://bugs.openjdk.java.net/browse/JDK-8263793 , may I ask your help to review and give comments?  
Thanks!

-------------

PR: https://git.openjdk.java.net/jdk/pull/3072

From alanb at openjdk.java.net  Mon Jul 26 07:54:06 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 26 Jul 2021 07:54:06 GMT
Subject: RFR: 8251329: (zipfs) Files.walkFileTree walks infinitely if zip
 has dir named "." inside
In-Reply-To: <BnwVE1xrk_yNwA-SSQWdU-s3Q6aWxeoNn2udHvQi9QE=.40ebc385-34fd-4be1-98ea-1514c46c89fb@github.com>
References: <BnwVE1xrk_yNwA-SSQWdU-s3Q6aWxeoNn2udHvQi9QE=.40ebc385-34fd-4be1-98ea-1514c46c89fb@github.com>
Message-ID: <EenpuGghvFrTL7WCedsVxo-6BCzSxMQJOr9fKotMELw=.54217ed0-e351-4797-9df7-567296768585@github.com>

On Sun, 25 Jul 2021 21:56:10 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Hi,
> 
> As discussed in the https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-July/079621.html thread, this is the revised patch to address the use of '.' and '..' within Zip FS
> 
> Zip FS needs to use "." and ".." as links to the current and parent directories and cannot reliably support entries that have "." and ".." as name elements.  This patch updates Zip Fs  to reject ZIP files that have entries in the CEN that can't be used for files in a file system.
> 
> 
> Mach5 tiers 1 through 3 have been run without any errors encountered .
> 
> Best,
> Lance

This is behavior change (to reject zip/JAR files) so a CSR will be required. I've also added a label to the JBS issue to remind us to add a release note.

I think it would be good for @jaikiran to review too.

src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 1573:

> 1571:             }
> 1572:             IndexNode inode = new IndexNode(cen, pos, nlen);
> 1573:             if(hasDotOrDotDot(inode.name)) {

Minor nit, missing space in "if(".

src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 1602:

> 1600:         // Inode.name always includes "/" in path[0]
> 1601:         if (path.length == 1) {
> 1602:             return false;

It may be useful to add "assert path[0] == '/';" at the start of this method.

test/jdk/jdk/nio/zipfs/HasDotDotTest.java line 1:

> 1: import org.testng.annotations.DataProvider;

Missing copyright header.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4900

From github.com+10835776+stsypanov at openjdk.java.net  Mon Jul 26 08:22:28 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 26 Jul 2021 08:22:28 GMT
Subject: RFR: 8270160: Remove redundant bounds check from
 AbstractStringBuilder.charAt() [v4]
In-Reply-To: <Rs2IOOVA4Rt-72REaifI9rMAtle9N-CLgkGSH7Q7xH0=.bfadc544-a1ad-41dd-9222-b0dec3dbed65@github.com>
References: <Rs2IOOVA4Rt-72REaifI9rMAtle9N-CLgkGSH7Q7xH0=.bfadc544-a1ad-41dd-9222-b0dec3dbed65@github.com>
Message-ID: <nEng6LszhWobvxqUgmOTYfDC43ngC7VbXsBc4wxcyMs=.a36851c5-84ff-4075-8759-63f361b692be@github.com>

> `AbstractStringBuilder.charAt(int)` does bounds check before calling `charAt()` (for non-latin Strings):
> 
> @Override
> public char charAt(int index) {
>     checkIndex(index, count);
>     if (isLatin1()) {
>         return (char)(value[index] & 0xff);
>     }
>     return StringUTF16.charAt(value, index);
> }
> 
> This can be improved by removing bounds check from ASB.charAt() in favour of one in String*.charAt(). This gives slight improvement:
> 
> before
> Benchmark                           Mode  Cnt  Score   Error  Units
> StringBuilderCharAtBenchmark.latin  avgt   50  2,827 ? 0,024  ns/op
> StringBuilderCharAtBenchmark.utf    avgt   50  2,985 ? 0,020  ns/op
> 
> after
> Benchmark                           Mode  Cnt  Score   Error  Units
> StringBuilderCharAtBenchmark.latin  avgt   50  2,434 ? 0,004  ns/op
> StringBuilderCharAtBenchmark.utf    avgt   50  2,631 ? 0,004  ns/op

?????? ??????? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:

 - Merge branch 'master' into 8270160
 - Merge branch 'master' into 8270160
   
   # Conflicts:
   #	src/java.base/share/classes/java/lang/StringLatin1.java
 - 8270160: Remove redundant bounds check from AbstractStringBuilder.charAt()

-------------

Changes: https://git.openjdk.java.net/jdk/pull/4738/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4738&range=03
  Stats: 6 lines in 2 files changed: 0 ins; 3 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4738.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4738/head:pull/4738

PR: https://git.openjdk.java.net/jdk/pull/4738

From github.com+10835776+stsypanov at openjdk.java.net  Mon Jul 26 08:27:14 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 26 Jul 2021 08:27:14 GMT
Subject: RFR: 8268113: Re-use Long.hashCode() where possible [v11]
In-Reply-To: <7TGw6Vzvw38bqmNOQsuVuGXMe98OqH25nmexLUghcMU=.5e7b347c-0d83-4e54-acc3-9847c08cdc29@github.com>
References: <7TGw6Vzvw38bqmNOQsuVuGXMe98OqH25nmexLUghcMU=.5e7b347c-0d83-4e54-acc3-9847c08cdc29@github.com>
Message-ID: <bxpkAvClK09ExpSL7KeZj9nZqCKHj-b7thCYa75EfuE=.2ad4ad96-2529-47d8-96ea-d90db7fc0e12@github.com>

> There is a few JDK classes duplicating the contents of Long.hashCode() for hash code calculation. They should explicitly delegate to Long.hashCode().

?????? ??????? has updated the pull request with a new target base 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 8268113
 - 8270160 Revert changes in BitSet.hashCode
 - Merge branch 'master' into 8268113
 - 8270160 Revert changes in BitSet.hashCode
 - Merge branch 'master' into 8268113
 - Merge branch 'master' into 8268113
 - Merge branch 'master' into 8268113
 - Merge branch 'master' into 8268113
 - Merge branch 'master' into 8268113
 - Merge branch 'master' into 8268113
 - ... and 3 more: https://git.openjdk.java.net/jdk/compare/441e382b...bd762b7d

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4309/files
  - new: https://git.openjdk.java.net/jdk/pull/4309/files/1d619c73..bd762b7d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4309&range=10
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4309&range=09-10

  Stats: 7986 lines in 302 files changed: 5011 ins; 1046 del; 1929 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4309.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4309/head:pull/4309

PR: https://git.openjdk.java.net/jdk/pull/4309

From github.com+10835776+stsypanov at openjdk.java.net  Mon Jul 26 08:27:20 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 26 Jul 2021 08:27:20 GMT
Subject: RFR: 8263561: Re-examine uses of LinkedList [v5]
In-Reply-To: <eCQ8oFDjAJgFR3SG0K7GlaM1lxivFOkQGkIi-i7I7Xw=.bd379708-2bb4-4d52-81e3-175fb7a9c46b@github.com>
References: <eCQ8oFDjAJgFR3SG0K7GlaM1lxivFOkQGkIi-i7I7Xw=.bd379708-2bb4-4d52-81e3-175fb7a9c46b@github.com>
Message-ID: <oj-2SM4qef-9bKhmErlifgLmp3bNeyNi7P-cqkQutxA=.e8891bb3-d00c-4a27-bbe6-a179a475343d@github.com>

> After I've renamed remove branch GitHub for some reason has closed original https://github.com/openjdk/jdk/pull/2744, so I've decided to recreate it.

?????? ??????? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:

 - Merge branch 'master' into 8263561
 - Merge branch 'master' into 8263561
 - Merge branch 'master' into 8263561
 - Merge branch 'master' into 8263561
 - Merge branch 'master' into 8263561
   
   # Conflicts:
   #	src/java.base/unix/classes/sun/net/dns/ResolverConfigurationImpl.java
 - Merge branch 'master' into purge-linked-list
 - 8263561: Use sized constructor where reasonable
 - 8263561: Use interface List instead of particular type where possible
 - 8263561: Rename requestList -> requests
 - 8263561: Re-examine uses of LinkedList

-------------

Changes: https://git.openjdk.java.net/jdk/pull/4304/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4304&range=04
  Stats: 48 lines in 9 files changed: 0 ins; 2 del; 46 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4304.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4304/head:pull/4304

PR: https://git.openjdk.java.net/jdk/pull/4304

From github.com+10835776+stsypanov at openjdk.java.net  Mon Jul 26 08:31:23 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 26 Jul 2021 08:31:23 GMT
Subject: RFR: 8266972: Use String.concat() in j.l.Class where
 invokedynamic-based String concatenation is not available [v7]
In-Reply-To: <mmH_gQ8uVQa6VMhBzCMHjdgL7wpmwll5DKxnfuS0U9A=.82977d2b-d934-471e-94b6-dd5ef90c037c@github.com>
References: <mmH_gQ8uVQa6VMhBzCMHjdgL7wpmwll5DKxnfuS0U9A=.82977d2b-d934-471e-94b6-dd5ef90c037c@github.com>
Message-ID: <89-oUHcxXQG6OI8aEC84Y1LXclStOtfNi_UmZxs_ubc=.48ace564-95fc-452e-8438-6d655f61a0b5@github.com>

> Hello, from discussion in https://github.com/openjdk/jdk/pull/3464 I've found out, that in a few of JDK core classes, e.g. in `j.l.Class` expressions like `baseName.replace('.', '/') + '/' + name` are not compiled into `invokedynamic`-based code, but into one using `StringBuilder`. This happens due to some bootstraping issues.
> 
> However the code like
> 
> private String getSimpleName0() {
>     if (isArray()) {
>         return getComponentType().getSimpleName() + "[]";
>     }
>     //...
> }
> 
> can be improved via replacement of `+` with `String.concat()` call.
> 
> I've used this benchmark to measure impact:
> 
> @State(Scope.Thread)
> @BenchmarkMode(Mode.AverageTime)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"})
> public class ClassMethodsBenchmark {
>   private final Class<? extends Object[]> arrayClass = Object[].class;
>   private Method descriptorString;
> 
>   @Setup
>   public void setUp() throws NoSuchMethodException {
>     //fore some reason compiler doesn't allow me to call Class.descriptorString() directly
>     descriptorString = Class.class.getDeclaredMethod("descriptorString");
>   }
> 
>   @Benchmark
>   public Object descriptorString() throws Exception {
>     return descriptorString.invoke(arrayClass);
>   }
> 
>   @Benchmark
>   public Object typeName() {
>     return arrayClass.getTypeName();
>   }
> }
> 
> and got those results
> 
>                                                    Mode  Cnt     Score     Error   Units
> descriptorString                                   avgt   60    91.480 ?   1.839   ns/op
> descriptorString:?gc.alloc.rate.norm               avgt   60   404.008 ?   4.033    B/op
> descriptorString:?gc.churn.G1_Eden_Space           avgt   60  2791.866 ? 181.589  MB/sec
> descriptorString:?gc.churn.G1_Eden_Space.norm      avgt   60   401.702 ?  26.047    B/op
> descriptorString:?gc.churn.G1_Survivor_Space       avgt   60     0.003 ?   0.001  MB/sec
> descriptorString:?gc.churn.G1_Survivor_Space.norm  avgt   60    ? 10??              B/op
> descriptorString:?gc.count                         avgt   60   205.000            counts
> descriptorString:?gc.time                          avgt   60   216.000                ms
> 
> patched
>                                                    Mode  Cnt     Score     Error   Units
> descriptorString                                   avgt   60    65.016 ?   3.446   ns/op
> descriptorString:?gc.alloc.rate                    avgt   60  2844.240 ? 115.719  MB/sec
> descriptorString:?gc.alloc.rate.norm               avgt   60   288.006 ?   0.001    B/op
> descriptorString:?gc.churn.G1_Eden_Space           avgt   60  2832.996 ? 206.939  MB/sec
> descriptorString:?gc.churn.G1_Eden_Space.norm      avgt   60   286.955 ?  17.853    B/op
> descriptorString:?gc.churn.G1_Survivor_Space       avgt   60     0.003 ?   0.001  MB/sec
> descriptorString:?gc.churn.G1_Survivor_Space.norm  avgt   60    ? 10??              B/op
> descriptorString:?gc.count                         avgt   60   208.000            counts
> descriptorString:?gc.time                          avgt   60   228.000                ms
> -----------------
> typeName                                           avgt   60    34.273 ?   0.480   ns/op
> typeName:?gc.alloc.rate                            avgt   60  3265.356 ?  45.113  MB/sec
> typeName:?gc.alloc.rate.norm                       avgt   60   176.004 ?   0.001    B/op
> typeName:?gc.churn.G1_Eden_Space                   avgt   60  3268.454 ? 134.458  MB/sec
> typeName:?gc.churn.G1_Eden_Space.norm              avgt   60   176.109 ?   6.595    B/op
> typeName:?gc.churn.G1_Survivor_Space               avgt   60     0.003 ?   0.001  MB/sec
> typeName:?gc.churn.G1_Survivor_Space.norm          avgt   60    ? 10??              B/op
> typeName:?gc.count                                 avgt   60   240.000            counts
> typeName:?gc.time                                  avgt   60   255.000                ms
> 
> patched
> 
> typeName                                           avgt   60    15.787 ?   0.214   ns/op
> typeName:?gc.alloc.rate                            avgt   60  2577.554 ?  32.339  MB/sec
> typeName:?gc.alloc.rate.norm                       avgt   60    64.001 ?   0.001    B/op
> typeName:?gc.churn.G1_Eden_Space                   avgt   60  2574.039 ? 147.774  MB/sec
> typeName:?gc.churn.G1_Eden_Space.norm              avgt   60    63.895 ?   3.511    B/op
> typeName:?gc.churn.G1_Survivor_Space               avgt   60     0.003 ?   0.001  MB/sec
> typeName:?gc.churn.G1_Survivor_Space.norm          avgt   60    ? 10??              B/op
> typeName:?gc.count                                 avgt   60   189.000            counts
> typeName:?gc.time                                  avgt   60   199.000                ms
> 
> I think this patch is likely to improve reflection operations related to arrays.
> 
> If one finds this patch useful, then I'll create a ticket to track this. Also it'd be nice to have a list of classes, that are compiled in the same way as `j.l.Class` (i.e. have no access to `invokedynamic`) so I could look into them for other snippets where two String are joined so `concat`-based optimization is possible.
> 
> Pre-sizing of `StringBuilder` for `Class.gdescriptorString()` and `Class.getCanonicalName0()` is one more improvement opportunity here.

?????? ??????? has updated the pull request with a new target base 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 class-concat
 - Merge remote-tracking branch 'origin/class-concat' into class-concat
 - Merge branch 'master' into class-concat
 - Merge branch 'master' into class-concat
 - 8266972: Revert change in Class.descriptorString()
 - Merge branch 'master' into class-concat
 - Merge branch 'master' into class-concat
 - 8266972: Use String.concat() in j.l.Class.toSting()
 - Use String.concat() where invokedynamic-based String concatenation is not available

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3627/files
  - new: https://git.openjdk.java.net/jdk/pull/3627/files/aba59d3d..7e846a25

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3627&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3627&range=05-06

  Stats: 14906 lines in 590 files changed: 8743 ins; 3140 del; 3023 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3627.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3627/head:pull/3627

PR: https://git.openjdk.java.net/jdk/pull/3627

From jpai at openjdk.java.net  Mon Jul 26 09:55:07 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Mon, 26 Jul 2021 09:55:07 GMT
Subject: RFR: 8251329: (zipfs) Files.walkFileTree walks infinitely if zip
 has dir named "." inside
In-Reply-To: <BnwVE1xrk_yNwA-SSQWdU-s3Q6aWxeoNn2udHvQi9QE=.40ebc385-34fd-4be1-98ea-1514c46c89fb@github.com>
References: <BnwVE1xrk_yNwA-SSQWdU-s3Q6aWxeoNn2udHvQi9QE=.40ebc385-34fd-4be1-98ea-1514c46c89fb@github.com>
Message-ID: <KsKUat1TucLU0aKYTiQ3LnH0B40G70ZWEs4ycbeDleQ=.8f12288c-1089-4226-bbda-af212119644e@github.com>

On Sun, 25 Jul 2021 21:56:10 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Hi,
> 
> As discussed in the https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-July/079621.html thread, this is the revised patch to address the use of '.' and '..' within Zip FS
> 
> Zip FS needs to use "." and ".." as links to the current and parent directories and cannot reliably support entries that have "." and ".." as name elements.  This patch updates Zip Fs  to reject ZIP files that have entries in the CEN that can't be used for files in a file system.
> 
> 
> Mach5 tiers 1 through 3 have been run without any errors encountered .
> 
> Best,
> Lance

This change looks fine to me. I was unsure how the writing/creating entries with `.` or `..` with `ZipFileSystem` would behave in context of this change, so I gave this a try locally with the changes from this PR:


try (FileSystem zipfs = FileSystems.newFileSystem(ZIPFILE)) {
            final Path[] paths = new Path[]{
                    zipfs.getPath("./Hello.txt"),
                    zipfs.getPath("../../../Hello.txt"),
                    zipfs.getPath("../Hello.txt")};
            for (int i = 0; i < paths.length; i++) {
                try (OutputStream os = Files.newOutputStream(paths[i])) {
                    os.write(("Hello " + i).getBytes(StandardCharsets.UTF_8));
                }
            }
        }

This code runs fine and it ends up creating (just one) CEN entry for `Hello.txt`:

JTwork/scratch/zipfsDotDotTest.zip
  Length      Date    Time    Name
---------  ---------- -----   ----
        7  07-26-2021 15:07   Hello.txt

In other words, the `ZipFileSystem` doesn't end up creating a zip file which is then rejected by `ZipFileSystem` when creating a new filesystem using `Files.newFileSystem`. That's a good thing.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4900

From lancea at openjdk.java.net  Mon Jul 26 10:16:47 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Mon, 26 Jul 2021 10:16:47 GMT
Subject: RFR: 8251329: (zipfs) Files.walkFileTree walks infinitely if zip
 has dir named "." inside [v2]
In-Reply-To: <BnwVE1xrk_yNwA-SSQWdU-s3Q6aWxeoNn2udHvQi9QE=.40ebc385-34fd-4be1-98ea-1514c46c89fb@github.com>
References: <BnwVE1xrk_yNwA-SSQWdU-s3Q6aWxeoNn2udHvQi9QE=.40ebc385-34fd-4be1-98ea-1514c46c89fb@github.com>
Message-ID: <MEu03waUkJEgptOFz8noYr3hKH7eaTSRSpXWUhOB-2I=.97f556fb-5543-45da-beb8-b671ae209f45@github.com>

> Hi,
> 
> As discussed in the https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-July/079621.html thread, this is the revised patch to address the use of '.' and '..' within Zip FS
> 
> Zip FS needs to use "." and ".." as links to the current and parent directories and cannot reliably support entries that have "." and ".." as name elements.  This patch updates Zip Fs  to reject ZIP files that have entries in the CEN that can't be used for files in a file system.
> 
> 
> Mach5 tiers 1 through 3 have been run without any errors encountered .
> 
> Best,
> Lance

Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:

  Add missing Copyright header and address minor comments

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4900/files
  - new: https://git.openjdk.java.net/jdk/pull/4900/files/68af64c4..2265ffe1

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4900&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4900&range=00-01

  Stats: 25 lines in 2 files changed: 24 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4900.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4900/head:pull/4900

PR: https://git.openjdk.java.net/jdk/pull/4900

From lancea at openjdk.java.net  Mon Jul 26 10:16:53 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Mon, 26 Jul 2021 10:16:53 GMT
Subject: RFR: 8251329: (zipfs) Files.walkFileTree walks infinitely if zip
 has dir named "." inside [v2]
In-Reply-To: <EenpuGghvFrTL7WCedsVxo-6BCzSxMQJOr9fKotMELw=.54217ed0-e351-4797-9df7-567296768585@github.com>
References: <BnwVE1xrk_yNwA-SSQWdU-s3Q6aWxeoNn2udHvQi9QE=.40ebc385-34fd-4be1-98ea-1514c46c89fb@github.com>
 <EenpuGghvFrTL7WCedsVxo-6BCzSxMQJOr9fKotMELw=.54217ed0-e351-4797-9df7-567296768585@github.com>
Message-ID: <yOfKwQZp7mqnKcPKBJEnrWZmx-tAB1BqzdlKLZ8q034=.d50e6fff-59fb-47c6-be10-7d0cce9f6aef@github.com>

On Mon, 26 Jul 2021 07:30:12 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add missing Copyright header and address minor comments
>
> src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 1573:
> 
>> 1571:             }
>> 1572:             IndexNode inode = new IndexNode(cen, pos, nlen);
>> 1573:             if(hasDotOrDotDot(inode.name)) {
> 
> Minor nit, missing space in "if(".

fixed

> src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 1602:
> 
>> 1600:         // Inode.name always includes "/" in path[0]
>> 1601:         if (path.length == 1) {
>> 1602:             return false;
> 
> It may be useful to add "assert path[0] == '/';" at the start of this method.

I added it per your suggestion, though IndexNode(byte[] cen, int pos, int nlen) which is only used by initCen() will already guarantee the leading "/" is there

> test/jdk/jdk/nio/zipfs/HasDotDotTest.java line 1:
> 
>> 1: import org.testng.annotations.DataProvider;
> 
> Missing copyright header.

Geez, how did I miss that.  Added

-------------

PR: https://git.openjdk.java.net/jdk/pull/4900

From lancea at openjdk.java.net  Mon Jul 26 10:19:06 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Mon, 26 Jul 2021 10:19:06 GMT
Subject: RFR: 8251329: (zipfs) Files.walkFileTree walks infinitely if zip
 has dir named "." inside
In-Reply-To: <KsKUat1TucLU0aKYTiQ3LnH0B40G70ZWEs4ycbeDleQ=.8f12288c-1089-4226-bbda-af212119644e@github.com>
References: <BnwVE1xrk_yNwA-SSQWdU-s3Q6aWxeoNn2udHvQi9QE=.40ebc385-34fd-4be1-98ea-1514c46c89fb@github.com>
 <KsKUat1TucLU0aKYTiQ3LnH0B40G70ZWEs4ycbeDleQ=.8f12288c-1089-4226-bbda-af212119644e@github.com>
Message-ID: <hBMOJU-d8rc1scvBZOBLSe5oQJ56iBRcM8NMBLE01KM=.6f3bb1b8-74de-437e-8f82-5d9e622a22c9@github.com>

On Mon, 26 Jul 2021 09:52:09 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> This change looks fine to me. I was unsure how the writing/creating entries with `.` or `..` with `ZipFileSystem` would behave in context of this change, so I gave this a try locally with the changes from this PR:
> 
> ```
> try (FileSystem zipfs = FileSystems.newFileSystem(ZIPFILE)) {
>             final Path[] paths = new Path[]{
>                     zipfs.getPath("./Hello.txt"),
>                     zipfs.getPath("../../../Hello.txt"),
>                     zipfs.getPath("../Hello.txt")};
>             for (int i = 0; i < paths.length; i++) {
>                 try (OutputStream os = Files.newOutputStream(paths[i])) {
>                     os.write(("Hello " + i).getBytes(StandardCharsets.UTF_8));
>                 }
>             }
>         }
> ```
> 
> This code runs fine and it ends up creating (just one) CEN entry for `Hello.txt`:
> 
> ```
> JTwork/scratch/zipfsDotDotTest.zip
>   Length      Date    Time    Name
> ---------  ---------- -----   ----
>         7  07-26-2021 15:07   Hello.txt
> ```
> 
> In other words, the `ZipFileSystem` doesn't end up creating a zip file which is then rejected by `ZipFileSystem` when creating a new filesystem using `Files.newFileSystem`. That's a good thing.


With the exception of creating the Inodes table,  Zip FS always calls ZipPath::getResolvedPath for access to Zip entries.  So there is no issues with the creation and access of entries in the case above

-------------

PR: https://git.openjdk.java.net/jdk/pull/4900

From alanb at openjdk.java.net  Mon Jul 26 10:26:07 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 26 Jul 2021 10:26:07 GMT
Subject: RFR: 8251329: (zipfs) Files.walkFileTree walks infinitely if zip
 has dir named "." inside [v2]
In-Reply-To: <MEu03waUkJEgptOFz8noYr3hKH7eaTSRSpXWUhOB-2I=.97f556fb-5543-45da-beb8-b671ae209f45@github.com>
References: <BnwVE1xrk_yNwA-SSQWdU-s3Q6aWxeoNn2udHvQi9QE=.40ebc385-34fd-4be1-98ea-1514c46c89fb@github.com>
 <MEu03waUkJEgptOFz8noYr3hKH7eaTSRSpXWUhOB-2I=.97f556fb-5543-45da-beb8-b671ae209f45@github.com>
Message-ID: <ZQw1s2E8HzzpD-QuIWyEF_SRKkzFqJOVWabN9ofyN4Q=.3cf1d3e7-915b-4c60-a128-6241dba3a95c@github.com>

On Mon, 26 Jul 2021 10:16:47 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Hi,
>> 
>> As discussed in the https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-July/079621.html thread, this is the revised patch to address the use of '.' and '..' within Zip FS
>> 
>> Zip FS needs to use "." and ".." as links to the current and parent directories and cannot reliably support entries that have "." and ".." as name elements.  This patch updates Zip Fs  to reject ZIP files that have entries in the CEN that can't be used for files in a file system.
>> 
>> 
>> Mach5 tiers 1 through 3 have been run without any errors encountered .
>> 
>> Best,
>> Lance
>
> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add missing Copyright header and address minor comments

>                     zipfs.getPath("./Hello.txt"),
>                     zipfs.getPath("../../../Hello.txt"),
>                     zipfs.getPath("../Hello.txt")};
>
> 
> In other words, the `ZipFileSystem` doesn't end up creating a zip file which is then rejected by `ZipFileSystem` when creating a new filesystem using `Files.newFileSystem`. That's a good thing.

Right, it's always existing behavior and matches the behavior of the platform file system.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4900

From github.com+741251+turbanoff at openjdk.java.net  Mon Jul 26 11:30:21 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Mon, 26 Jul 2021 11:30:21 GMT
Subject: RFR: 8269130: Replace usages of Collection.toArray() with
 Collection.toArray(T[]) to avoid redundant array copying
Message-ID: <T7SCIIPHljpkI__o6KGtVXO1I9jMWWcXkQv-GaUE6pE=.b3de93a2-9057-4bf5-9680-2397a4d10e62@github.com>

I found few places, where code initially perform `Object[] Colleciton.toArray()` call and then manually copy array into another array with required type.
This PR cleanups such places to more shorter call `T[] Collection.toArray(T[])`.

-------------

Commit messages:
 - Replace usages of Collection.toArray() with Collection.toArray(T[]) to avoid redundant array copying
 - Replace usages of Collection.toArray() with Collection.toArray(T[]) to avoid redundant array copying
 - Replace usages of Collection.toArray() with Collection.toArray(T[]) to avoid redundant array copying

Changes: https://git.openjdk.java.net/jdk/pull/4487/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4487&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8269130
  Stats: 70 lines in 8 files changed: 0 ins; 54 del; 16 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4487.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4487/head:pull/4487

PR: https://git.openjdk.java.net/jdk/pull/4487

From github.com+10835776+stsypanov at openjdk.java.net  Mon Jul 26 11:30:21 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 26 Jul 2021 11:30:21 GMT
Subject: RFR: 8269130: Replace usages of Collection.toArray() with
 Collection.toArray(T[]) to avoid redundant array copying
In-Reply-To: <T7SCIIPHljpkI__o6KGtVXO1I9jMWWcXkQv-GaUE6pE=.b3de93a2-9057-4bf5-9680-2397a4d10e62@github.com>
References: <T7SCIIPHljpkI__o6KGtVXO1I9jMWWcXkQv-GaUE6pE=.b3de93a2-9057-4bf5-9680-2397a4d10e62@github.com>
Message-ID: <RGdfH15SqrmAJ_F_lJsXWPgDXASBawZa6STmTw79O0M=.9a0479b0-2555-4541-95ba-665960ab4fbe@github.com>

On Mon, 14 Jun 2021 17:00:29 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> I found few places, where code initially perform `Object[] Colleciton.toArray()` call and then manually copy array into another array with required type.
> This PR cleanups such places to more shorter call `T[] Collection.toArray(T[])`.

I think the same simlification can be done for some classes affected by your previous PR https://github.com/openjdk/jdk/pull/4482, e.g. `HttpsClient`, lines 154-157 and 177-180 and `PKCS7`, so I'd wait for https://github.com/openjdk/jdk/pull/4482 and then add one more commit here.

@turbanoff I've filed a ticket for this: https://bugs.openjdk.java.net/browse/JDK-8269130. Also I think you can integrate https://github.com/openjdk/jdk/pull/4482

-------------

PR: https://git.openjdk.java.net/jdk/pull/4487

From github.com+741251+turbanoff at openjdk.java.net  Mon Jul 26 11:30:22 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Mon, 26 Jul 2021 11:30:22 GMT
Subject: RFR: 8269130: Replace usages of Collection.toArray() with
 Collection.toArray(T[]) to avoid redundant array copying
In-Reply-To: <1z_ElyUFTtNdV6Wt5HV0lEdQZbTvf7F5MRdV6pB36zM=.d92f53e6-53dc-436e-acf3-619f784d7814@github.com>
References: <T7SCIIPHljpkI__o6KGtVXO1I9jMWWcXkQv-GaUE6pE=.b3de93a2-9057-4bf5-9680-2397a4d10e62@github.com>
 <1z_ElyUFTtNdV6Wt5HV0lEdQZbTvf7F5MRdV6pB36zM=.d92f53e6-53dc-436e-acf3-619f784d7814@github.com>
Message-ID: <HbAuDh-MFnpUrGAxHJTKJX9_0ybK5EbYuHoTI3s2MPE=.6104a076-442a-4c67-9805-5c4008905d10@github.com>

On Tue, 15 Jun 2021 12:06:43 GMT, Michael Bien <github.com+114367+mbien at openjdk.org> wrote:

>> I found few places, where code initially perform `Object[] Colleciton.toArray()` call and then manually copy array into another array with required type.
>> This PR cleanups such places to more shorter call `T[] Collection.toArray(T[])`.
>
> src/java.base/share/classes/java/security/Security.java line 656:
> 
>> 654:             return null;
>> 655: 
>> 656:         return candidates.toArray(new Provider[0]);
> 
> `candidates.toArray(new Provider[candidates.size()]);`
> 
> would use the fast path of the toArray() implementation. Performance probably doesn't matter much in a lot of this cases, but since its only a few characters more, its still worth considering IMO.
> 
> The only places I would leave this out are on the HashTable and on the Vector collections in this PR, since calling one synchronized method is not the same as calling two - concurrency wise.
> 
> (i am no reviewer)

Actually it's not _the fast path_ - see https://shipilev.net/blog/2016/arrays-wisdom-ancients/

-------------

PR: https://git.openjdk.java.net/jdk/pull/4487

From github.com+114367+mbien at openjdk.java.net  Mon Jul 26 11:30:21 2021
From: github.com+114367+mbien at openjdk.java.net (Michael Bien)
Date: Mon, 26 Jul 2021 11:30:21 GMT
Subject: RFR: 8269130: Replace usages of Collection.toArray() with
 Collection.toArray(T[]) to avoid redundant array copying
In-Reply-To: <T7SCIIPHljpkI__o6KGtVXO1I9jMWWcXkQv-GaUE6pE=.b3de93a2-9057-4bf5-9680-2397a4d10e62@github.com>
References: <T7SCIIPHljpkI__o6KGtVXO1I9jMWWcXkQv-GaUE6pE=.b3de93a2-9057-4bf5-9680-2397a4d10e62@github.com>
Message-ID: <1z_ElyUFTtNdV6Wt5HV0lEdQZbTvf7F5MRdV6pB36zM=.d92f53e6-53dc-436e-acf3-619f784d7814@github.com>

On Mon, 14 Jun 2021 17:00:29 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> I found few places, where code initially perform `Object[] Colleciton.toArray()` call and then manually copy array into another array with required type.
> This PR cleanups such places to more shorter call `T[] Collection.toArray(T[])`.

src/java.base/share/classes/java/security/Security.java line 656:

> 654:             return null;
> 655: 
> 656:         return candidates.toArray(new Provider[0]);

`candidates.toArray(new Provider[candidates.size()]);`

would use the fast path of the toArray() implementation. Performance probably doesn't matter much in a lot of this cases, but since its only a few characters more, its still worth considering IMO.

The only places I would leave this out are on the HashTable and on the Vector collections in this PR, since calling one synchronized method is not the same as calling two - concurrency wise.

(i am no reviewer)

-------------

PR: https://git.openjdk.java.net/jdk/pull/4487

From github.com+114367+mbien at openjdk.java.net  Mon Jul 26 11:30:22 2021
From: github.com+114367+mbien at openjdk.java.net (Michael Bien)
Date: Mon, 26 Jul 2021 11:30:22 GMT
Subject: RFR: 8269130: Replace usages of Collection.toArray() with
 Collection.toArray(T[]) to avoid redundant array copying
In-Reply-To: <HbAuDh-MFnpUrGAxHJTKJX9_0ybK5EbYuHoTI3s2MPE=.6104a076-442a-4c67-9805-5c4008905d10@github.com>
References: <T7SCIIPHljpkI__o6KGtVXO1I9jMWWcXkQv-GaUE6pE=.b3de93a2-9057-4bf5-9680-2397a4d10e62@github.com>
 <1z_ElyUFTtNdV6Wt5HV0lEdQZbTvf7F5MRdV6pB36zM=.d92f53e6-53dc-436e-acf3-619f784d7814@github.com>
 <HbAuDh-MFnpUrGAxHJTKJX9_0ybK5EbYuHoTI3s2MPE=.6104a076-442a-4c67-9805-5c4008905d10@github.com>
Message-ID: <XMK9iClcp3uF-aORRgwlw0r7X9TGNvP12JYZSFESnwc=.4ee3292e-f9f0-4fb2-b039-8f4f2b97df34@github.com>

On Tue, 15 Jun 2021 12:34:50 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> src/java.base/share/classes/java/security/Security.java line 656:
>> 
>>> 654:             return null;
>>> 655: 
>>> 656:         return candidates.toArray(new Provider[0]);
>> 
>> `candidates.toArray(new Provider[candidates.size()]);`
>> 
>> would use the fast path of the toArray() implementation. Performance probably doesn't matter much in a lot of this cases, but since its only a few characters more, its still worth considering IMO.
>> 
>> The only places I would leave this out are on the HashTable and on the Vector collections in this PR, since calling one synchronized method is not the same as calling two - concurrency wise.
>> 
>> (i am no reviewer)
>
> Actually it's not _the fast path_ - see https://shipilev.net/blog/2016/arrays-wisdom-ancients/

oh I am sorry my mistake - I actually now remember reading the article. (It would be interesting to rerun the benchmark on modern JDKs since I would expect the gap to be smaller now)
Please disregard my suggestion.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4487

From serb at openjdk.java.net  Mon Jul 26 11:30:23 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 26 Jul 2021 11:30:23 GMT
Subject: RFR: 8269130: Replace usages of Collection.toArray() with
 Collection.toArray(T[]) to avoid redundant array copying
In-Reply-To: <T7SCIIPHljpkI__o6KGtVXO1I9jMWWcXkQv-GaUE6pE=.b3de93a2-9057-4bf5-9680-2397a4d10e62@github.com>
References: <T7SCIIPHljpkI__o6KGtVXO1I9jMWWcXkQv-GaUE6pE=.b3de93a2-9057-4bf5-9680-2397a4d10e62@github.com>
Message-ID: <522sj45K-E26GUke0gp6dDoq_4dpwfLMytNVmg5V2k8=.2d5a1a6c-4191-4f63-a83e-af35c69cb6e4@github.com>

On Mon, 14 Jun 2021 17:00:29 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> I found few places, where code initially perform `Object[] Colleciton.toArray()` call and then manually copy array into another array with required type.
> This PR cleanups such places to more shorter call `T[] Collection.toArray(T[])`.

src/java.desktop/share/classes/sun/java2d/SunGraphicsEnvironment.java line 191:

> 189:                         installed[i]);
> 190:             }
> 191:             String[] retval = map.keySet().toArray(new String[0]);

Looks like previously the code returns values, and now it will return keys, please recheck.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4487

From stuefe at openjdk.java.net  Mon Jul 26 12:15:55 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Mon, 26 Jul 2021 12:15:55 GMT
Subject: RFR: JDK-8256844: Make NMT late-initializable
Message-ID: <Ze_dKp-5-dse_657jTXTD4kbHSBeOQcLvqeluE0DXjI=.9214cb10-f1f1-48cb-8d96-12621a51a904@github.com>

Short: this patch makes NMT available in custom-launcher scenarios and during gtests. It simplifies NMT initialization. It adds a lot of NMT-specific testing.

---------

NMT continues to be an extremely useful tool for SAP to tackle memory problems in the JVM.

However, NMT is of limited use due to the following restrictions:

- NMT cannot be used if the hotspot is embedded into a custom launcher unless the launcher actively cooperates. Just creating and invoking the JVM is not enough, it needs to do some steps prior to loading the hotspot. This limitation is not well known (nor, do I believe, documented). Many products don't do this, e.g., you cannot use NMT with IntelliJ. For us at SAP this problem limits NMT usefulness greatly since our VMs are often embedded into custom launchers and modifying every launcher is impossible.
- Worse, if that custom launcher links the libjvm *statically* there is just no way to activate NMT at all. This is the reason NMT cannot be used in the `gtestlauncher`.
- Related to that is that we cannot pass NMT options via `JAVA_TOOL_OPTIONS` and `-XX:Flags=<file>`.
- The fact that NMT cannot be used in gtests is really a pity since it would allow us to both test NMT itself more rigorously and check for memory leaks while testing other stuff.

The reason for all this is that NMT initialization happens very early, on the first call to `os::malloc()`. And those calls happen already during dynamic C++ initialization - a long time before the VM gets around parsing arguments. So, regular VM argument parsing is too late to parse NMT arguments.

The current solution is to pass NMT arguments via a specially prepared environment variable: `NMT_LEVEL_<PID>=<NMT arguments>`. That environment variable has to be set by the embedding launcher, before it loads the libjvm. Since its name contains the PID, we cannot even set that variable in the shell before starting the launcher.

All that means that every launcher needs to especially parse and process the NMT arguments given at the command line (or via whatever method) and prepare the environment variable. `java` itself does this. This only works before the libjvm.so is loaded, before its dynamic C++ initialization. For that reason, it does not work if the launcher links statically against the hotspot, since in that case C++ initialization of the launcher and hotspot are folded into one phase with no possibility of executing code beforehand.

And since it bypasses argument handling in the VM, it bypasses a number of argument processing ways, e.g., `JAVA_TOOL_OPTIONS`.

------

This patch fixes these shortcomings by making NMT late-initializable: it can now be initialized after normal VM argument parsing, like all other parts of the VM. This greatly simplifies NMT initialization and makes it work automagically for every third party launcher, as well as within our gtests.

The glaring problem with late-initializing NMT is the NMT malloc headers. If we rule out just always having them (unacceptable in terms of memory overhead), there is no safe way to determine, in os::free(), if an allocation came from before or after NMT initialization ran, and therefore what to do with its malloc headers. For a more extensive explanation, please see the comment block `nmtPreInit.hpp` and the discussion with @kimbarrett and @zhengyu123 in the JBS comment section.

The heart of this patch is a new way to track early, pre-NMT-init allocations. These are tracked via a lookup table. This was a suggestion by Kim and it worked out well.

Changes in detail:

- pre-NMT-init handling:
	- the new files `nmtPreInit.hpp/cpp` take case of NMT pre-init handling. They contain a small global lookup table managing C-heap blocks allocated in the pre-NMT-init phase.
	- `os::malloc()/os::realloc()/os::free()` defer to this code before doing anything else.
	- Please see the extensive comment block at the start of `nmtPreinit.hpp` explaining the details.

- Changes to NMT:
	- Before, NMT initialization was spread over two phases, `initialize()` and `late_initialize()`. Those were merged into one and simplified - there is only one initialization now which happens after argument parsing.
	- Minor changes were needed for the `NMT_TrackingLevel` enum - to simplify code, I changed NMT_unknown to be numerically 0. A new comment block in `nmtCommon.hpp` now clearly specifies what's what, including allowed level state transitions.
	- New utility functions to translate tracking level from/to strings added to `NMTUtil`
	- NMT has never been able to handle virtual memory allocations before initialization, which is fine since os::reserve_memory() is not called before VM parses arguments. We now assert that.
	- All code outside the VM handling NMT initialization (eg. libjli) has been removed, as has the code testing it.

- Gtests:
	- Some existing gtests had to be modified: before, they all changed global state (turning NMT on/off) before testing. This is not allowed anymore, to keep NMT simple. Also, this pattern disturbed other tests.
	- The new way to test is to passively check whether NMT has been switched on or off, and do tests accordingly: if on, full tests, if off, test just what makes sense in off-state. That does not disturb neighboring tests, gives us actually better coverage all around.
	- It is now possible to start the gtestlauncher with NMT on! Which additionally gives us good coverage.
	- To actually do gtests with NMT - since it's disabled by default - we now run NMT-enabled gtests as part of the hotspot jtreg NMT wrapper. This pattern we have done for a number of other facitilites, see all the tests in test/hotspot/jtreg/gtest.. . It works very well.
	- Finally, a new gtest has been written to test the NMT preinit lookup map in isolation, placed in `gtest/nmt/test_nmtpreinitmap.cpp`.
	
- jtreg:
	- A new test has been added, `runtime/NMT/NMTInitializationTest.java`, testing NMT initialization in the face of many many VM arguments.

-------------

Tests:
- ran manually all new tests on 64-bit and 32-bit Linux
- GHAs
- The patch has been active in SAPs test systems for a while now.

-------------

Commit messages:
 - NMT late init, hashmap variant

Changes: https://git.openjdk.java.net/jdk/pull/4874/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4874&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8256844
  Stats: 1616 lines in 22 files changed: 1227 ins; 346 del; 43 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4874.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4874/head:pull/4874

PR: https://git.openjdk.java.net/jdk/pull/4874

From github.com+741251+turbanoff at openjdk.java.net  Mon Jul 26 16:34:58 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Mon, 26 Jul 2021 16:34:58 GMT
Subject: Integrated: 8265474: Dubious 'null' assignment in
 CompactByteArray.expand
In-Reply-To: <VgD5N1gsnxjI0L6HjaDWiX3Sc2FU3jBwoqw-xeSI_EI=.8b997c59-a7e9-47d7-9cfe-94c95a2b5502@github.com>
References: <VgD5N1gsnxjI0L6HjaDWiX3Sc2FU3jBwoqw-xeSI_EI=.8b997c59-a7e9-47d7-9cfe-94c95a2b5502@github.com>
Message-ID: <sWtr0DbLc7uCCrd4gWXbWwQg4RpG6UwUs52Hh0Fh8XE=.be164528-6345-47d7-9882-03bf6e2bfb18@github.com>

On Wed, 23 Dec 2020 16:06:30 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> I propose to remove 'null' assignment of field CompactByteArray.values in `expand` method. In the next statement this field is overridden with another value - `tempArray`.
> This code was there from initial load of OpenJDK sources. I believe it was just leftovers from development phase of this class. There is no practical reason to assign `null` to non-volatile field and then overwrite it with another value.
> Also I've removed unused method `getArray`. I hope it's ok to cleanup such unused stuff in the same PR.

This pull request has now been integrated.

Changeset: ee553618
Author:    Andrey Turbanov <turbanoff at gmail.com>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ee5536183a9df90d1209d9effe5d2aa61d86abd3
Stats:     9 lines in 1 file changed: 0 ins; 6 del; 3 mod

8265474: Dubious 'null' assignment in CompactByteArray.expand

Reviewed-by: alanb, naoto

-------------

PR: https://git.openjdk.java.net/jdk/pull/1880

From naoto at openjdk.java.net  Mon Jul 26 16:39:05 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 26 Jul 2021 16:39:05 GMT
Subject: Integrated: 8171382: java.time.Duration missing isPositive method
In-Reply-To: <ogy5GwKye8RhHJDyZwTzW4IFamPpEOzpK7BRuqpL1FE=.f2f3ecec-7388-42d5-aee9-3754dcb649db@github.com>
References: <ogy5GwKye8RhHJDyZwTzW4IFamPpEOzpK7BRuqpL1FE=.f2f3ecec-7388-42d5-aee9-3754dcb649db@github.com>
Message-ID: <-76AkvMvUFGYePOo6M38_4uVnYD3rZedWmIzgWkVOxo=.1dc4d955-384e-457b-897d-d43040c1d274@github.com>

On Fri, 23 Jul 2021 17:27:27 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Please review this PR to introduce `java.time.Duration.isPositive()` method. A CSR is also drafted.

This pull request has now been integrated.

Changeset: efa63dc1
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/efa63dc1c64db357eeb497d2e1fefd170ca22d98
Stats:     31 lines in 2 files changed: 30 ins; 0 del; 1 mod

8171382: java.time.Duration missing isPositive method

Reviewed-by: rriggs, joehw, iris, bpb, scolebourne

-------------

PR: https://git.openjdk.java.net/jdk/pull/4892

From mchung at openjdk.java.net  Mon Jul 26 17:21:37 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Mon, 26 Jul 2021 17:21:37 GMT
Subject: RFR: 8270321: Startup regressions in 18-b5 caused by JDK-8266310
In-Reply-To: <W0x401I1NqmAUe7fn05M-YVVBaP1yD98xoXz0kNw5UM=.a60b4e7d-c7e9-406e-bde4-1341519a439a@github.com>
References: <W0x401I1NqmAUe7fn05M-YVVBaP1yD98xoXz0kNw5UM=.a60b4e7d-c7e9-406e-bde4-1341519a439a@github.com>
Message-ID: <-CNtomzHBavLEh_YZCjxSRVJDQ9I773s5lP13u2L-2Q=.ab2104ce-77ba-49ca-b8a0-7986cabd0294@github.com>

On Fri, 23 Jul 2021 18:03:31 GMT, Sergey Chernyshev <github.com+6394632+sercher at openjdk.org> wrote:

> Dear colleagues,
> 
> Please review the patch that replaces the lambdas with anonymous classes which solves the startup time regression as shown below.
> 
> I attached the Bytestacks flamegraphs for both original (regression) and fixed versions. The flamegraphs clearly show the lambdas were causing the performance issue.
> 
> [bytestacks_flamegraphs.zip](https://github.com/openjdk/jdk/files/6870446/bytestacks_flamegraphs.zip)
> 
> Although the proposed JDK-8270321 patch fixes the startup time (it might appear even better than it was before the regression was introduced, i.e. before JDK-8266310) and generally fixes the footprint regression, it may increase MaxRSS slightly compared to the version before JDK-8266310, which is shown in the below graphs. (updated)
> 
> ![StartupTime2](https://user-images.githubusercontent.com/6394632/126898224-a05fda62-f723-4f2c-9af9-e02cbfe1c9c8.png)
> 
> ![MaxRSS](https://user-images.githubusercontent.com/6394632/126822404-899ab904-efc1-4377-9e0d-d8cdb5c0e5d0.png)
> 
> (update: added ZGC graphs)
> 
> ![StartupTime_ZGC](https://user-images.githubusercontent.com/6394632/126898242-52c09582-c2a4-4623-aad2-f47055277193.png)
> 
> ![MaxRSS_ZGC](https://user-images.githubusercontent.com/6394632/126898244-31c3eeb5-a768-4a52-8960-960cc4a72d7b.png)
> 
> I additionally include the heap objects histograms to show the change does not increase the total live objects size significantly with only 1000 bytes the total difference, namely 1116128 bytes in 25002 live objects after the proposed fix JDK-8270321 compared to 1115128 bytes in 24990 objects in the version with the original patch reverted (i.e. before JDK-8266310).
> 
> [histograms.zip](https://github.com/openjdk/jdk/files/6870457/histograms.zip)
> 
> The patch was tested w/hotspot/tier1/tier2 test groups.

NativeLibraries was called early during VM startup and the startup benchmark is just a Noop.   So the lambda creation by NativeLibraries is likely still running in interpreted mode.

Looks like replacing it with an anonymous class may be an alternative.  I ran a few startup benchmarks on linux x64 with this patch.   It does show that the startup regression is fixed and also the footprint benchmark I included does not show any regression.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4893

From sviswanathan at openjdk.java.net  Mon Jul 26 17:22:34 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Mon, 26 Jul 2021 17:22:34 GMT
Subject: RFR: 8266054: VectorAPI rotate operation optimization [v10]
In-Reply-To: <57RjIAXAeh_OL4TKIusvf_Zzcdy8sojU874yc1lH2yY=.3acc983b-9152-404c-a67a-d484fe41c15b@github.com>
References: <OZ2u4DDNaYF3WiR5uU6NWvzPMKV3j8QAO_mZyLP3Isg=.594e3514-8a5a-442c-ac1a-ca6c6d14e963@github.com>
 <j-MimQL3RfOga-_XaS0UWHPsmDp99CyUer8f_bFptmo=.231d4cc0-e9ee-47d8-ad6c-41adcf114367@github.com>
 <mF_TPuiSWMhsH4OoVgvPDJ2VcSP8MGhj1mL7ACIyoQg=.e9e159d5-90ec-470a-84b9-167c36ce6c7f@github.com>
 <57RjIAXAeh_OL4TKIusvf_Zzcdy8sojU874yc1lH2yY=.3acc983b-9152-404c-a67a-d484fe41c15b@github.com>
Message-ID: <OwhhLDoNCALTI4sXL6P_4iVtX-M6psAL2IoyTP8RwS8=.98105420-c710-4aa1-8a45-bed07608776b@github.com>

On Sun, 18 Jul 2021 20:22:18 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> src/hotspot/share/opto/vectornode.cpp line 1180:
>> 
>>> 1178:       cnt = cnt->in(1);
>>> 1179:     }
>>> 1180:     shiftRCnt = cnt;
>> 
>> Why do we remove the And with mask here?
>
> And'ing with shift_mask is already done on Java API side implementation before making a call to intrinsic rountine.

@jatin-bhateja  This question is still pending.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3720

From bpb at openjdk.java.net  Mon Jul 26 17:23:36 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Mon, 26 Jul 2021 17:23:36 GMT
Subject: Integrated: 8075806: divideExact is missing in java.lang.Math
In-Reply-To: <8nZ1xpS-Ir7KIEuaryZ0bQ2upeqcMy9TBm7-afE5lek=.22ec71c9-49d7-4994-aa1e-638c9d522510@github.com>
References: <8nZ1xpS-Ir7KIEuaryZ0bQ2upeqcMy9TBm7-afE5lek=.22ec71c9-49d7-4994-aa1e-638c9d522510@github.com>
Message-ID: <efv_6eMQAz4tM1l8ryv6D2LSjvjdMJYLLTYSsF7wA3U=.6f89635b-7121-4488-ab3f-9d108074c23c@github.com>

On Tue, 13 Jul 2021 17:21:52 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Please consider this proposal to add `divideExact()` methods for integral data types to `java.lang.Math` thereby rounding out "exact" support to all four basic arithmetic operations.

This pull request has now been integrated.

Changeset: 0b12e7c8
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/0b12e7c82c559f64c8c202bf59ee71f9cbd5a5fa
Stats:     177 lines in 3 files changed: 157 ins; 10 del; 10 mod

8075806: divideExact is missing in java.lang.Math

Reviewed-by: darcy

-------------

PR: https://git.openjdk.java.net/jdk/pull/4770

From github.com+1701815+mkarg at openjdk.java.net  Mon Jul 26 18:02:27 2021
From: github.com+1701815+mkarg at openjdk.java.net (Markus KARG)
Date: Mon, 26 Jul 2021 18:02:27 GMT
Subject: RFR: 8265891: (ch) InputStream returned by
 Channels.newInputStream should override transferTo [v4]
In-Reply-To: <XlU5gCBUEa4qTTz8yhMeElh95FuiPcFYQ_nj_WYvbLE=.6e9fc6a4-f3b1-4faf-91f0-d8b06f875780@github.com>
References: <XlU5gCBUEa4qTTz8yhMeElh95FuiPcFYQ_nj_WYvbLE=.6e9fc6a4-f3b1-4faf-91f0-d8b06f875780@github.com>
Message-ID: <7PBopxz12bSrundwCfzqD7QBYqhVU39CYehUGIYGOwg=.632fc69f-2dfd-41df-aace-ad8965b2139b@github.com>

> This PR-*draft* is **work in progress** and an invitation to discuss a possible solution for issue [JDK-8265891](https://bugs.openjdk.java.net/browse/JDK-8265891). It is *not yet* intended for a final review.
> 
> As proposed in JDK-8265891, this PR provides an implementation for `Channels.newInputStream().transferTo()` which provide superior performance compared to the current implementation. The changes are:
> * Prevents transfers through the JVM heap as much as possibly by offloading to deeper levels via NIO, hence allowing the operating system to optimize the transfer.
> * Using more JRE heap in the fallback case when no NIO is possible (still only KiBs, hence mostl ynegligible even on SBCs) to better perform on modern hardware / fast I/O devides.
> 
> Using JMH I have benchmarked both, the original implementation and this implementation, and (depending on the used hardware and use case) performance change was approx. doubled performance. So this PoC proofs that it makes sense to finalize this work and turn it into an actual OpenJDK contribution. 
> 
> I encourage everybody to discuss this draft:
> * Are there valid arguments for *not* doing this change?
> * Is there a *better* way to improve performance of `Channels.newInputStream().transferTo()`?
> * How to go on from here: What is missing to get this ready for an actual review?

Markus KARG has updated the pull request incrementally with four additional commits since the last revision:

 - Draft: Test for ChannelInputStream::transferTo
 - Draft: Using Channels API to invoke sun.nio.ch classes
 - Draft: MUST check params before ANY other operation
 - Draft: ChannelInputStream::transferTo Test

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4263/files
  - new: https://git.openjdk.java.net/jdk/pull/4263/files/47ee00a2..b431fcd6

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4263&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4263&range=02-03

  Stats: 229 lines in 2 files changed: 229 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4263.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4263/head:pull/4263

PR: https://git.openjdk.java.net/jdk/pull/4263

From github.com+1701815+mkarg at openjdk.java.net  Mon Jul 26 18:02:29 2021
From: github.com+1701815+mkarg at openjdk.java.net (Markus KARG)
Date: Mon, 26 Jul 2021 18:02:29 GMT
Subject: RFR: 8265891: (ch) InputStream returned by
 Channels.newInputStream should override transferTo [v3]
In-Reply-To: <aS5i72i7KLnTndIFIA_94OUjEgyuwXiHDHu1H898QtE=.0fcdd01c-2219-4318-86d7-8826941b6f41@github.com>
References: <XlU5gCBUEa4qTTz8yhMeElh95FuiPcFYQ_nj_WYvbLE=.6e9fc6a4-f3b1-4faf-91f0-d8b06f875780@github.com>
 <aS5i72i7KLnTndIFIA_94OUjEgyuwXiHDHu1H898QtE=.0fcdd01c-2219-4318-86d7-8826941b6f41@github.com>
Message-ID: <MexwixZ1HWTbPlrkcrR4LaoNgjNiRKAICIb5trE5ewk=.98ec3da1-b6de-4cb8-a329-d93f6567ca3e@github.com>

On Fri, 2 Jul 2021 06:20:29 GMT, Markus KARG <github.com+1701815+mkarg at openjdk.org> wrote:

>> This PR-*draft* is **work in progress** and an invitation to discuss a possible solution for issue [JDK-8265891](https://bugs.openjdk.java.net/browse/JDK-8265891). It is *not yet* intended for a final review.
>> 
>> As proposed in JDK-8265891, this PR provides an implementation for `Channels.newInputStream().transferTo()` which provide superior performance compared to the current implementation. The changes are:
>> * Prevents transfers through the JVM heap as much as possibly by offloading to deeper levels via NIO, hence allowing the operating system to optimize the transfer.
>> * Using more JRE heap in the fallback case when no NIO is possible (still only KiBs, hence mostl ynegligible even on SBCs) to better perform on modern hardware / fast I/O devides.
>> 
>> Using JMH I have benchmarked both, the original implementation and this implementation, and (depending on the used hardware and use case) performance change was approx. doubled performance. So this PoC proofs that it makes sense to finalize this work and turn it into an actual OpenJDK contribution. 
>> 
>> I encourage everybody to discuss this draft:
>> * Are there valid arguments for *not* doing this change?
>> * Is there a *better* way to improve performance of `Channels.newInputStream().transferTo()`?
>> * How to go on from here: What is missing to get this ready for an actual review?
>
> Markus KARG 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.

Sorry for the delay. I now have pushed a first draft of the test. IIUC then five implementation have to be tested just for the actualy API, i. e. whether they throws NPE when `out` is `null`, and whether they transfer small, single turn, and multiple turn loads correctly. The tests are taken from `InputStream/TransferTo.java` as you proposed, and I am not using mocking but instead use `Channels.new*` as the existing tests you proposed as a blueprint. I hope I understood your requests and proposals correctly, if not please tell me. The tests pass well and proof that the new implementations work as expected and API-compliant.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4263

From jbhateja at openjdk.java.net  Mon Jul 26 18:04:32 2021
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Mon, 26 Jul 2021 18:04:32 GMT
Subject: RFR: 8266054: VectorAPI rotate operation optimization [v10]
In-Reply-To: <OwhhLDoNCALTI4sXL6P_4iVtX-M6psAL2IoyTP8RwS8=.98105420-c710-4aa1-8a45-bed07608776b@github.com>
References: <OZ2u4DDNaYF3WiR5uU6NWvzPMKV3j8QAO_mZyLP3Isg=.594e3514-8a5a-442c-ac1a-ca6c6d14e963@github.com>
 <j-MimQL3RfOga-_XaS0UWHPsmDp99CyUer8f_bFptmo=.231d4cc0-e9ee-47d8-ad6c-41adcf114367@github.com>
 <mF_TPuiSWMhsH4OoVgvPDJ2VcSP8MGhj1mL7ACIyoQg=.e9e159d5-90ec-470a-84b9-167c36ce6c7f@github.com>
 <57RjIAXAeh_OL4TKIusvf_Zzcdy8sojU874yc1lH2yY=.3acc983b-9152-404c-a67a-d484fe41c15b@github.com>
 <OwhhLDoNCALTI4sXL6P_4iVtX-M6psAL2IoyTP8RwS8=.98105420-c710-4aa1-8a45-bed07608776b@github.com>
Message-ID: <MNoVqtwGCmFq6Cb5hcjVR-i7agNJ03LFNmrXPO-_oug=.2ed90731-a5cb-4569-8185-34a4d284b835@github.com>

On Mon, 26 Jul 2021 17:19:07 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> And'ing with shift_mask is already done on Java API side implementation before making a call to intrinsic rountine.
>
> @jatin-bhateja  This question is still pending.

Other than VectorAPI , SLP also infers vector rotates where shift is either a 8bit constant or variable shift present in vector. So this case of scalar non-constant shift will not be hit for non-vectorAPI case.
Also it will be illegal to perform any wrap around for shifts.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3720

From igraves at openjdk.java.net  Mon Jul 26 18:19:45 2021
From: igraves at openjdk.java.net (Ian Graves)
Date: Mon, 26 Jul 2021 18:19:45 GMT
Subject: RFR: 8269753: Misplaced caret in PatternSyntaxException's detail
 message
Message-ID: <GXNX7r4c57Cyq9rRoXfcGp_Wb1M1PgTs1Axp-sMIRac=.7d6344f4-666e-4afc-88ae-88a835bed930@github.com>

Fixes a bug where carets aren't indented correctly in PatternSyntaxException messages because tab characters are converted to spaces in their indentation.

-------------

Commit messages:
 - 8269753: Misplaced caret in PatternSyntaxException's detail message

Changes: https://git.openjdk.java.net/jdk/pull/4906/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4906&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8269753
  Stats: 23 lines in 2 files changed: 21 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4906.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4906/head:pull/4906

PR: https://git.openjdk.java.net/jdk/pull/4906

From igraves at openjdk.java.net  Mon Jul 26 18:19:45 2021
From: igraves at openjdk.java.net (Ian Graves)
Date: Mon, 26 Jul 2021 18:19:45 GMT
Subject: RFR: 8269753: Misplaced caret in PatternSyntaxException's detail
 message
In-Reply-To: <GXNX7r4c57Cyq9rRoXfcGp_Wb1M1PgTs1Axp-sMIRac=.7d6344f4-666e-4afc-88ae-88a835bed930@github.com>
References: <GXNX7r4c57Cyq9rRoXfcGp_Wb1M1PgTs1Axp-sMIRac=.7d6344f4-666e-4afc-88ae-88a835bed930@github.com>
Message-ID: <3BEB5TZ9tVCO2HMYKCtwEevV0Qpf_2C-S4TBcnp8hEw=.929113ec-946d-4d07-b847-e9d4580d9caf@github.com>

On Mon, 26 Jul 2021 18:10:03 GMT, Ian Graves <igraves at openjdk.org> wrote:

> Fixes a bug where carets aren't indented correctly in PatternSyntaxException messages because tab characters are converted to spaces in their indentation.

@pavelrappo

-------------

PR: https://git.openjdk.java.net/jdk/pull/4906

From github.com+741251+turbanoff at openjdk.java.net  Mon Jul 26 18:22:39 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Mon, 26 Jul 2021 18:22:39 GMT
Subject: Integrated: 8268873: Unnecessary Vector usage in java.base
In-Reply-To: <RiYSRALAstA3O6-B_kVJ6HPAb7K47Ps-6LpSgsedK98=.5ab809ba-5870-4160-b6ec-f6625b417ddb@github.com>
References: <RiYSRALAstA3O6-B_kVJ6HPAb7K47Ps-6LpSgsedK98=.5ab809ba-5870-4160-b6ec-f6625b417ddb@github.com>
Message-ID: <8hxiUvDJy5Y4ewfuAit7Z2ya46d-1B0FTYPCt3oX7So=.7fa4203e-2378-4e5b-b5ef-8f07f6f7e3c9@github.com>

On Mon, 14 Jun 2021 11:34:50 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Usage of thread-safe collection `Vector` is unnecessary. It's recommended to use `ArrayList` if a thread-safe implementation is not needed. In post-BiasedLocking times, this is gets worse, as every access is synchronized.
> I checked only places where `Vector` was used as local variable.

This pull request has now been integrated.

Changeset: b8f79a7f
Author:    Andrey Turbanov <turbanoff at gmail.com>
Committer: Sean Mullan <mullan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b8f79a7ff798d3a0eee03a8153be942401781bbc
Stats:     18 lines in 3 files changed: 1 ins; 4 del; 13 mod

8268873: Unnecessary Vector usage in java.base

Reviewed-by: mullan

-------------

PR: https://git.openjdk.java.net/jdk/pull/4482

From forax at openjdk.java.net  Mon Jul 26 18:42:28 2021
From: forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Mon, 26 Jul 2021 18:42:28 GMT
Subject: RFR: 8270321: Startup regressions in 18-b5 caused by JDK-8266310
In-Reply-To: <W0x401I1NqmAUe7fn05M-YVVBaP1yD98xoXz0kNw5UM=.a60b4e7d-c7e9-406e-bde4-1341519a439a@github.com>
References: <W0x401I1NqmAUe7fn05M-YVVBaP1yD98xoXz0kNw5UM=.a60b4e7d-c7e9-406e-bde4-1341519a439a@github.com>
Message-ID: <KRe-0siWmbEzhL4npw0zbVceX0OfeI86j_fLFU1RVsI=.ce93ec4e-4789-4bb4-9c5a-1a066a8c67e9@github.com>

On Fri, 23 Jul 2021 18:03:31 GMT, Sergey Chernyshev <github.com+6394632+sercher at openjdk.org> wrote:

> Dear colleagues,
> 
> Please review the patch that replaces the lambdas with anonymous classes which solves the startup time regression as shown below.
> 
> I attached the Bytestacks flamegraphs for both original (regression) and fixed versions. The flamegraphs clearly show the lambdas were causing the performance issue.
> 
> [bytestacks_flamegraphs.zip](https://github.com/openjdk/jdk/files/6870446/bytestacks_flamegraphs.zip)
> 
> Although the proposed JDK-8270321 patch fixes the startup time (it might appear even better than it was before the regression was introduced, i.e. before JDK-8266310) and generally fixes the footprint regression, it may increase MaxRSS slightly compared to the version before JDK-8266310, which is shown in the below graphs. (updated)
> 
> ![StartupTime2](https://user-images.githubusercontent.com/6394632/126898224-a05fda62-f723-4f2c-9af9-e02cbfe1c9c8.png)
> 
> ![MaxRSS](https://user-images.githubusercontent.com/6394632/126822404-899ab904-efc1-4377-9e0d-d8cdb5c0e5d0.png)
> 
> (update: added ZGC graphs)
> 
> ![StartupTime_ZGC](https://user-images.githubusercontent.com/6394632/126898242-52c09582-c2a4-4623-aad2-f47055277193.png)
> 
> ![MaxRSS_ZGC](https://user-images.githubusercontent.com/6394632/126898244-31c3eeb5-a768-4a52-8960-960cc4a72d7b.png)
> 
> I additionally include the heap objects histograms to show the change does not increase the total live objects size significantly with only 1000 bytes the total difference, namely 1116128 bytes in 25002 live objects after the proposed fix JDK-8270321 compared to 1115128 bytes in 24990 objects in the version with the original patch reverted (i.e. before JDK-8266310).
> 
> [histograms.zip](https://github.com/openjdk/jdk/files/6870457/histograms.zip)
> 
> The patch was tested w/hotspot/tier1/tier2 test groups.

Hi Sergey,
thanks for the explanation, i don't think there is a need for more data with -Xint.

Using anonymous classes instead of lambdas is good for me.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4893

From jbhateja at openjdk.java.net  Mon Jul 26 18:58:28 2021
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Mon, 26 Jul 2021 18:58:28 GMT
Subject: RFR: 8266054: VectorAPI rotate operation optimization [v10]
In-Reply-To: <OwhhLDoNCALTI4sXL6P_4iVtX-M6psAL2IoyTP8RwS8=.98105420-c710-4aa1-8a45-bed07608776b@github.com>
References: <OZ2u4DDNaYF3WiR5uU6NWvzPMKV3j8QAO_mZyLP3Isg=.594e3514-8a5a-442c-ac1a-ca6c6d14e963@github.com>
 <j-MimQL3RfOga-_XaS0UWHPsmDp99CyUer8f_bFptmo=.231d4cc0-e9ee-47d8-ad6c-41adcf114367@github.com>
 <mF_TPuiSWMhsH4OoVgvPDJ2VcSP8MGhj1mL7ACIyoQg=.e9e159d5-90ec-470a-84b9-167c36ce6c7f@github.com>
 <57RjIAXAeh_OL4TKIusvf_Zzcdy8sojU874yc1lH2yY=.3acc983b-9152-404c-a67a-d484fe41c15b@github.com>
 <OwhhLDoNCALTI4sXL6P_4iVtX-M6psAL2IoyTP8RwS8=.98105420-c710-4aa1-8a45-bed07608776b@github.com>
Message-ID: <HvAMP5HzhzUGb1L_zSDdGL00POSydoS1zT29E4LeO_Q=.1649b2d4-308d-40ea-b43e-c0dcd56c11b5@github.com>

On Mon, 26 Jul 2021 17:19:07 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> And'ing with shift_mask is already done on Java API side implementation before making a call to intrinsic rountine.
>
> @jatin-bhateja  This question is still pending.

@sviswa7, SLP flow will either have a constant 8bit shift value or a variable shift present in vector. So non constant scalar case will not be hit through this route.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3720

From mullan at openjdk.java.net  Mon Jul 26 19:10:35 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Mon, 26 Jul 2021 19:10:35 GMT
Subject: RFR: 8269130: Replace usages of Collection.toArray() with
 Collection.toArray(T[]) to avoid redundant array copying
In-Reply-To: <T7SCIIPHljpkI__o6KGtVXO1I9jMWWcXkQv-GaUE6pE=.b3de93a2-9057-4bf5-9680-2397a4d10e62@github.com>
References: <T7SCIIPHljpkI__o6KGtVXO1I9jMWWcXkQv-GaUE6pE=.b3de93a2-9057-4bf5-9680-2397a4d10e62@github.com>
Message-ID: <w-b3bQRsyksOmZlapJ8a175cxPbajxOHPK5bP2mmfJ0=.dbc900f7-9a03-4233-90dd-8853e410adb2@github.com>

On Mon, 14 Jun 2021 17:00:29 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> I found few places, where code initially perform `Object[] Colleciton.toArray()` call and then manually copy array into another array with required type.
> This PR cleanups such places to more shorter call `T[] Collection.toArray(T[])`.

The changes to the security classes look good.

-------------

Marked as reviewed by mullan (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4487

From github.com+2996845+bokken at openjdk.java.net  Mon Jul 26 19:18:33 2021
From: github.com+2996845+bokken at openjdk.java.net (Brett Okken)
Date: Mon, 26 Jul 2021 19:18:33 GMT
Subject: RFR: 8269130: Replace usages of Collection.toArray() with
 Collection.toArray(T[]) to avoid redundant array copying
In-Reply-To: <T7SCIIPHljpkI__o6KGtVXO1I9jMWWcXkQv-GaUE6pE=.b3de93a2-9057-4bf5-9680-2397a4d10e62@github.com>
References: <T7SCIIPHljpkI__o6KGtVXO1I9jMWWcXkQv-GaUE6pE=.b3de93a2-9057-4bf5-9680-2397a4d10e62@github.com>
Message-ID: <amB5jIt1-LyF6A8_OxgTfO6tDKhujRwvnM1QYqPbzkU=.17cd1c88-0ff5-42f6-ad9b-53d5cbdd74e5@github.com>

On Mon, 14 Jun 2021 17:00:29 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> I found few places, where code initially perform `Object[] Colleciton.toArray()` call and then manually copy array into another array with required type.
> This PR cleanups such places to more shorter call `T[] Collection.toArray(T[])`.

src/java.base/share/classes/java/security/Security.java line 656:

> 654:             return null;
> 655: 
> 656:         return candidates.toArray(new Provider[0]);

Is this called often enough to warrant creating a constant of `new Provider[0]` (benefits of this covered in the _Wisdom of the Ancients_ blog linked)?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4487

From prappo at openjdk.java.net  Mon Jul 26 19:49:30 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Mon, 26 Jul 2021 19:49:30 GMT
Subject: RFR: 8269753: Misplaced caret in PatternSyntaxException's detail
 message
In-Reply-To: <GXNX7r4c57Cyq9rRoXfcGp_Wb1M1PgTs1Axp-sMIRac=.7d6344f4-666e-4afc-88ae-88a835bed930@github.com>
References: <GXNX7r4c57Cyq9rRoXfcGp_Wb1M1PgTs1Axp-sMIRac=.7d6344f4-666e-4afc-88ae-88a835bed930@github.com>
Message-ID: <VFzyvaCrNqalBP7LBIWXSeSTfUhmsMCaL5mSTOhMq3o=.663e98af-d83c-4575-b4d0-284e1944dc30@github.com>

On Mon, 26 Jul 2021 18:10:03 GMT, Ian Graves <igraves at openjdk.org> wrote:

> Fixes a bug where carets aren't indented correctly in PatternSyntaxException messages because tab characters are converted to spaces in their indentation.

Changes requested by prappo (Reviewer).

src/java.base/share/classes/java/util/regex/PatternSyntaxException.java line 111:

> 109:             sb.append(System.lineSeparator());
> 110:             for (int i = 0; i < index; i++) {
> 111:                 sb.append((pattern.charAt(i) == '\t') ? '\t' : ' ');

In contrast with https://github.com/igraves/jdk/blob/2609dd9618dd43ea0de9abe3e3100262d09c079c/src/jdk.compiler/share/classes/com/sun/tools/javac/util/AbstractDiagnosticFormatter.java#L324, this code uses `StringBuilder.append(char)`, which might be even cleaner; good.

test/jdk/java/util/regex/RegExTest.java line 5304:

> 5302:             var message = e.getMessage();
> 5303:             var sep = System.lineSeparator();
> 5304:             if(message.contains(sep + "\t ^")){

Suggestion:

            if (message.contains(sep + "\t ^")) {

test/jdk/java/util/regex/RegExTest.java line 5310:

> 5308:         failCount++;
> 5309: 
> 5310:         report("Correct caret indentation for patterns with tabs");

`report` will not be reached on success; this is different from how `report` is used in the rest of the file. Also: `report` seems to be stateful in that it resets the `failCount`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4906

From github.com+2996845+bokken at openjdk.java.net  Mon Jul 26 19:58:30 2021
From: github.com+2996845+bokken at openjdk.java.net (Brett Okken)
Date: Mon, 26 Jul 2021 19:58:30 GMT
Subject: RFR: 8269130: Replace usages of Collection.toArray() with
 Collection.toArray(T[]) to avoid redundant array copying
In-Reply-To: <T7SCIIPHljpkI__o6KGtVXO1I9jMWWcXkQv-GaUE6pE=.b3de93a2-9057-4bf5-9680-2397a4d10e62@github.com>
References: <T7SCIIPHljpkI__o6KGtVXO1I9jMWWcXkQv-GaUE6pE=.b3de93a2-9057-4bf5-9680-2397a4d10e62@github.com>
Message-ID: <FRn0jQHYWMJL5GTfhu4TWGlg8OaBHVpEoIQ_pCka3rs=.151177ce-ac88-4932-b8c9-c6e59a148b5c@github.com>

On Mon, 14 Jun 2021 17:00:29 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> I found few places, where code initially perform `Object[] Colleciton.toArray()` call and then manually copy array into another array with required type.
> This PR cleanups such places to more shorter call `T[] Collection.toArray(T[])`.

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/SystemDictionaryHelper.java line 92:

> 90:       }
> 91: 
> 92:       InstanceKlass[] searchResult = tmp.toArray(new InstanceKlass[0]);

Is it too far outside the scope of these changes to make `tmp` an `ArrayList` rather than a `Vector`?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4487

From igraves at openjdk.java.net  Mon Jul 26 20:01:54 2021
From: igraves at openjdk.java.net (Ian Graves)
Date: Mon, 26 Jul 2021 20:01:54 GMT
Subject: RFR: 8269753: Misplaced caret in PatternSyntaxException's detail
 message [v2]
In-Reply-To: <GXNX7r4c57Cyq9rRoXfcGp_Wb1M1PgTs1Axp-sMIRac=.7d6344f4-666e-4afc-88ae-88a835bed930@github.com>
References: <GXNX7r4c57Cyq9rRoXfcGp_Wb1M1PgTs1Axp-sMIRac=.7d6344f4-666e-4afc-88ae-88a835bed930@github.com>
Message-ID: <fld78-uI9pUfVOHpWyGvC2pxnBIGBaJIX9dquYPFoV8=.cb4b99ed-85d2-4c8b-929f-15b5295510de@github.com>

> Fixes a bug where carets aren't indented correctly in PatternSyntaxException messages because tab characters are converted to spaces in their indentation.

Ian Graves has updated the pull request incrementally with one additional commit since the last revision:

  Copyright years

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4906/files
  - new: https://git.openjdk.java.net/jdk/pull/4906/files/2609dd96..339b438a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4906&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4906&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4906.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4906/head:pull/4906

PR: https://git.openjdk.java.net/jdk/pull/4906

From mchung at openjdk.java.net  Mon Jul 26 20:13:30 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Mon, 26 Jul 2021 20:13:30 GMT
Subject: RFR: 8270321: Startup regressions in 18-b5 caused by JDK-8266310
In-Reply-To: <W0x401I1NqmAUe7fn05M-YVVBaP1yD98xoXz0kNw5UM=.a60b4e7d-c7e9-406e-bde4-1341519a439a@github.com>
References: <W0x401I1NqmAUe7fn05M-YVVBaP1yD98xoXz0kNw5UM=.a60b4e7d-c7e9-406e-bde4-1341519a439a@github.com>
Message-ID: <DsX0KHwfS6rz7hQL8HJv4o7IvZNAGjcjfE-D3mpQUY0=.6a4ba0b8-363f-468c-9f36-381ef686b036@github.com>

On Fri, 23 Jul 2021 18:03:31 GMT, Sergey Chernyshev <github.com+6394632+sercher at openjdk.org> wrote:

> Dear colleagues,
> 
> Please review the patch that replaces the lambdas with anonymous classes which solves the startup time regression as shown below.
> 
> I attached the Bytestacks flamegraphs for both original (regression) and fixed versions. The flamegraphs clearly show the lambdas were causing the performance issue.
> 
> [bytestacks_flamegraphs.zip](https://github.com/openjdk/jdk/files/6870446/bytestacks_flamegraphs.zip)
> 
> Although the proposed JDK-8270321 patch fixes the startup time (it might appear even better than it was before the regression was introduced, i.e. before JDK-8266310) and generally fixes the footprint regression, it may increase MaxRSS slightly compared to the version before JDK-8266310, which is shown in the below graphs. (updated)
> 
> ![StartupTime2](https://user-images.githubusercontent.com/6394632/126898224-a05fda62-f723-4f2c-9af9-e02cbfe1c9c8.png)
> 
> ![MaxRSS](https://user-images.githubusercontent.com/6394632/126822404-899ab904-efc1-4377-9e0d-d8cdb5c0e5d0.png)
> 
> (update: added ZGC graphs)
> 
> ![StartupTime_ZGC](https://user-images.githubusercontent.com/6394632/126898242-52c09582-c2a4-4623-aad2-f47055277193.png)
> 
> ![MaxRSS_ZGC](https://user-images.githubusercontent.com/6394632/126898244-31c3eeb5-a768-4a52-8960-960cc4a72d7b.png)
> 
> I additionally include the heap objects histograms to show the change does not increase the total live objects size significantly with only 1000 bytes the total difference, namely 1116128 bytes in 25002 live objects after the proposed fix JDK-8270321 compared to 1115128 bytes in 24990 objects in the version with the original patch reverted (i.e. before JDK-8266310).
> 
> [histograms.zip](https://github.com/openjdk/jdk/files/6870457/histograms.zip)
> 
> The patch was tested w/hotspot/tier1/tier2 test groups.

Marked as reviewed by mchung (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4893

From github.com+1701815+mkarg at openjdk.java.net  Mon Jul 26 20:24:51 2021
From: github.com+1701815+mkarg at openjdk.java.net (Markus KARG)
Date: Mon, 26 Jul 2021 20:24:51 GMT
Subject: RFR: 8265891: (ch) InputStream returned by
 Channels.newInputStream should override transferTo [v5]
In-Reply-To: <XlU5gCBUEa4qTTz8yhMeElh95FuiPcFYQ_nj_WYvbLE=.6e9fc6a4-f3b1-4faf-91f0-d8b06f875780@github.com>
References: <XlU5gCBUEa4qTTz8yhMeElh95FuiPcFYQ_nj_WYvbLE=.6e9fc6a4-f3b1-4faf-91f0-d8b06f875780@github.com>
Message-ID: <_ImTEjqgdig9vcnINDYEXqG2y0WYzY-fYJ8uOUlvnis=.6f8a51cc-12d9-4037-9078-0a3ebd71d4c3@github.com>

> This PR-*draft* is **work in progress** and an invitation to discuss a possible solution for issue [JDK-8265891](https://bugs.openjdk.java.net/browse/JDK-8265891). It is *not yet* intended for a final review.
> 
> As proposed in JDK-8265891, this PR provides an implementation for `Channels.newInputStream().transferTo()` which provide superior performance compared to the current implementation. The changes are:
> * Prevents transfers through the JVM heap as much as possibly by offloading to deeper levels via NIO, hence allowing the operating system to optimize the transfer.
> * Using more JRE heap in the fallback case when no NIO is possible (still only KiBs, hence mostl ynegligible even on SBCs) to better perform on modern hardware / fast I/O devides.
> 
> Using JMH I have benchmarked both, the original implementation and this implementation, and (depending on the used hardware and use case) performance change was approx. doubled performance. So this PoC proofs that it makes sense to finalize this work and turn it into an actual OpenJDK contribution. 
> 
> I encourage everybody to discuss this draft:
> * Are there valid arguments for *not* doing this change?
> * Is there a *better* way to improve performance of `Channels.newInputStream().transferTo()`?
> * How to go on from here: What is missing to get this ready for an actual review?

Markus KARG 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:

  Draft: Test for ChannelInputStream::transferTo

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4263/files
  - new: https://git.openjdk.java.net/jdk/pull/4263/files/b431fcd6..bfc699a0

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4263&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4263&range=03-04

  Stats: 227 lines in 1 file changed: 0 ins; 0 del; 227 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4263.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4263/head:pull/4263

PR: https://git.openjdk.java.net/jdk/pull/4263

From github.com+1701815+mkarg at openjdk.java.net  Mon Jul 26 20:45:14 2021
From: github.com+1701815+mkarg at openjdk.java.net (Markus KARG)
Date: Mon, 26 Jul 2021 20:45:14 GMT
Subject: RFR: 8265891: (ch) InputStream returned by
 Channels.newInputStream should override transferTo [v6]
In-Reply-To: <XlU5gCBUEa4qTTz8yhMeElh95FuiPcFYQ_nj_WYvbLE=.6e9fc6a4-f3b1-4faf-91f0-d8b06f875780@github.com>
References: <XlU5gCBUEa4qTTz8yhMeElh95FuiPcFYQ_nj_WYvbLE=.6e9fc6a4-f3b1-4faf-91f0-d8b06f875780@github.com>
Message-ID: <5PpEoJT1JZoo75hz4HAQFkipRfXCr_7MyTE8g4yhhgc=.5eeefcfe-205b-4b02-a59b-bead8b410139@github.com>

> This PR-*draft* is **work in progress** and an invitation to discuss a possible solution for issue [JDK-8265891](https://bugs.openjdk.java.net/browse/JDK-8265891). It is *not yet* intended for a final review.
> 
> As proposed in JDK-8265891, this PR provides an implementation for `Channels.newInputStream().transferTo()` which provide superior performance compared to the current implementation. The changes are:
> * Prevents transfers through the JVM heap as much as possibly by offloading to deeper levels via NIO, hence allowing the operating system to optimize the transfer.
> * Using more JRE heap in the fallback case when no NIO is possible (still only KiBs, hence mostl ynegligible even on SBCs) to better perform on modern hardware / fast I/O devides.
> 
> Using JMH I have benchmarked both, the original implementation and this implementation, and (depending on the used hardware and use case) performance change was approx. doubled performance. So this PoC proofs that it makes sense to finalize this work and turn it into an actual OpenJDK contribution. 
> 
> I encourage everybody to discuss this draft:
> * Are there valid arguments for *not* doing this change?
> * Is there a *better* way to improve performance of `Channels.newInputStream().transferTo()`?
> * How to go on from here: What is missing to get this ready for an actual review?

Markus KARG 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:

  Draft: Test for ChannelInputStream::transferTo

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4263/files
  - new: https://git.openjdk.java.net/jdk/pull/4263/files/bfc699a0..1f9dba3d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4263&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4263&range=04-05

  Stats: 173 lines in 1 file changed: 6 ins; 0 del; 167 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4263.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4263/head:pull/4263

PR: https://git.openjdk.java.net/jdk/pull/4263

From igraves at openjdk.java.net  Mon Jul 26 20:54:53 2021
From: igraves at openjdk.java.net (Ian Graves)
Date: Mon, 26 Jul 2021 20:54:53 GMT
Subject: RFR: 8269753: Misplaced caret in PatternSyntaxException's detail
 message [v3]
In-Reply-To: <GXNX7r4c57Cyq9rRoXfcGp_Wb1M1PgTs1Axp-sMIRac=.7d6344f4-666e-4afc-88ae-88a835bed930@github.com>
References: <GXNX7r4c57Cyq9rRoXfcGp_Wb1M1PgTs1Axp-sMIRac=.7d6344f4-666e-4afc-88ae-88a835bed930@github.com>
Message-ID: <EaSHhtp9HQMdwz8PvzOh88sjLr03yud2ZeFB_JOwOZE=.d5f04b26-1887-417a-bef7-61210e856838@github.com>

> Fixes a bug where carets aren't indented correctly in PatternSyntaxException messages because tab characters are converted to spaces in their indentation.

Ian Graves has updated the pull request incrementally with one additional commit since the last revision:

  Tweaking some spacing. Fixing some report placement.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4906/files
  - new: https://git.openjdk.java.net/jdk/pull/4906/files/339b438a..c47b0651

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4906&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4906&range=01-02

  Stats: 6 lines in 1 file changed: 2 ins; 2 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4906.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4906/head:pull/4906

PR: https://git.openjdk.java.net/jdk/pull/4906

From david.holmes at oracle.com  Mon Jul 26 21:06:13 2021
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 27 Jul 2021 07:06:13 +1000
Subject: RFR: JDK-8256844: Make NMT late-initializable
In-Reply-To: <Ze_dKp-5-dse_657jTXTD4kbHSBeOQcLvqeluE0DXjI=.9214cb10-f1f1-48cb-8d96-12621a51a904@github.com>
References: <Ze_dKp-5-dse_657jTXTD4kbHSBeOQcLvqeluE0DXjI=.9214cb10-f1f1-48cb-8d96-12621a51a904@github.com>
Message-ID: <c4d84f41-ffb9-d327-9ec9-e9f9c61b8367@oracle.com>

Hi Thomas,

On 26/07/2021 10:15 pm, Thomas Stuefe wrote:
> Short: this patch makes NMT available in custom-launcher scenarios and during gtests. It simplifies NMT initialization. It adds a lot of NMT-specific testing.

Before looking at this, have you checked the startup performance impact?

Thanks,
David
-----

> ---------
> 
> NMT continues to be an extremely useful tool for SAP to tackle memory problems in the JVM.
> 
> However, NMT is of limited use due to the following restrictions:
> 
> - NMT cannot be used if the hotspot is embedded into a custom launcher unless the launcher actively cooperates. Just creating and invoking the JVM is not enough, it needs to do some steps prior to loading the hotspot. This limitation is not well known (nor, do I believe, documented). Many products don't do this, e.g., you cannot use NMT with IntelliJ. For us at SAP this problem limits NMT usefulness greatly since our VMs are often embedded into custom launchers and modifying every launcher is impossible.
> - Worse, if that custom launcher links the libjvm *statically* there is just no way to activate NMT at all. This is the reason NMT cannot be used in the `gtestlauncher`.
> - Related to that is that we cannot pass NMT options via `JAVA_TOOL_OPTIONS` and `-XX:Flags=<file>`.
> - The fact that NMT cannot be used in gtests is really a pity since it would allow us to both test NMT itself more rigorously and check for memory leaks while testing other stuff.
> 
> The reason for all this is that NMT initialization happens very early, on the first call to `os::malloc()`. And those calls happen already during dynamic C++ initialization - a long time before the VM gets around parsing arguments. So, regular VM argument parsing is too late to parse NMT arguments.
> 
> The current solution is to pass NMT arguments via a specially prepared environment variable: `NMT_LEVEL_<PID>=<NMT arguments>`. That environment variable has to be set by the embedding launcher, before it loads the libjvm. Since its name contains the PID, we cannot even set that variable in the shell before starting the launcher.
> 
> All that means that every launcher needs to especially parse and process the NMT arguments given at the command line (or via whatever method) and prepare the environment variable. `java` itself does this. This only works before the libjvm.so is loaded, before its dynamic C++ initialization. For that reason, it does not work if the launcher links statically against the hotspot, since in that case C++ initialization of the launcher and hotspot are folded into one phase with no possibility of executing code beforehand.
> 
> And since it bypasses argument handling in the VM, it bypasses a number of argument processing ways, e.g., `JAVA_TOOL_OPTIONS`.
> 
> ------
> 
> This patch fixes these shortcomings by making NMT late-initializable: it can now be initialized after normal VM argument parsing, like all other parts of the VM. This greatly simplifies NMT initialization and makes it work automagically for every third party launcher, as well as within our gtests.
> 
> The glaring problem with late-initializing NMT is the NMT malloc headers. If we rule out just always having them (unacceptable in terms of memory overhead), there is no safe way to determine, in os::free(), if an allocation came from before or after NMT initialization ran, and therefore what to do with its malloc headers. For a more extensive explanation, please see the comment block `nmtPreInit.hpp` and the discussion with @kimbarrett and @zhengyu123 in the JBS comment section.
> 
> The heart of this patch is a new way to track early, pre-NMT-init allocations. These are tracked via a lookup table. This was a suggestion by Kim and it worked out well.
> 
> Changes in detail:
> 
> - pre-NMT-init handling:
> 	- the new files `nmtPreInit.hpp/cpp` take case of NMT pre-init handling. They contain a small global lookup table managing C-heap blocks allocated in the pre-NMT-init phase.
> 	- `os::malloc()/os::realloc()/os::free()` defer to this code before doing anything else.
> 	- Please see the extensive comment block at the start of `nmtPreinit.hpp` explaining the details.
> 
> - Changes to NMT:
> 	- Before, NMT initialization was spread over two phases, `initialize()` and `late_initialize()`. Those were merged into one and simplified - there is only one initialization now which happens after argument parsing.
> 	- Minor changes were needed for the `NMT_TrackingLevel` enum - to simplify code, I changed NMT_unknown to be numerically 0. A new comment block in `nmtCommon.hpp` now clearly specifies what's what, including allowed level state transitions.
> 	- New utility functions to translate tracking level from/to strings added to `NMTUtil`
> 	- NMT has never been able to handle virtual memory allocations before initialization, which is fine since os::reserve_memory() is not called before VM parses arguments. We now assert that.
> 	- All code outside the VM handling NMT initialization (eg. libjli) has been removed, as has the code testing it.
> 
> - Gtests:
> 	- Some existing gtests had to be modified: before, they all changed global state (turning NMT on/off) before testing. This is not allowed anymore, to keep NMT simple. Also, this pattern disturbed other tests.
> 	- The new way to test is to passively check whether NMT has been switched on or off, and do tests accordingly: if on, full tests, if off, test just what makes sense in off-state. That does not disturb neighboring tests, gives us actually better coverage all around.
> 	- It is now possible to start the gtestlauncher with NMT on! Which additionally gives us good coverage.
> 	- To actually do gtests with NMT - since it's disabled by default - we now run NMT-enabled gtests as part of the hotspot jtreg NMT wrapper. This pattern we have done for a number of other facitilites, see all the tests in test/hotspot/jtreg/gtest.. . It works very well.
> 	- Finally, a new gtest has been written to test the NMT preinit lookup map in isolation, placed in `gtest/nmt/test_nmtpreinitmap.cpp`.
> 	
> - jtreg:
> 	- A new test has been added, `runtime/NMT/NMTInitializationTest.java`, testing NMT initialization in the face of many many VM arguments.
> 
> -------------
> 
> Tests:
> - ran manually all new tests on 64-bit and 32-bit Linux
> - GHAs
> - The patch has been active in SAPs test systems for a while now.
> 
> -------------
> 
> Commit messages:
>   - NMT late init, hashmap variant
> 
> Changes: https://git.openjdk.java.net/jdk/pull/4874/files
>   Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4874&range=00
>    Issue: https://bugs.openjdk.java.net/browse/JDK-8256844
>    Stats: 1616 lines in 22 files changed: 1227 ins; 346 del; 43 mod
>    Patch: https://git.openjdk.java.net/jdk/pull/4874.diff
>    Fetch: git fetch https://git.openjdk.java.net/jdk pull/4874/head:pull/4874
> 
> PR: https://git.openjdk.java.net/jdk/pull/4874
> 

From lancea at openjdk.java.net  Mon Jul 26 21:10:44 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Mon, 26 Jul 2021 21:10:44 GMT
Subject: RFR: 4890732: GZIPOutputStream doesn't support optional GZIP
 fields [v9]
In-Reply-To: <j7YPtBR8ylz-kuKwNVPgR8v2Tj2bAU7DE7UNr7G7mO4=.ef19d436-f320-460e-9c0d-6610ec7db5f6@github.com>
References: <DKXYUELjj1BRxIwULHr8Ocm0DY4I6ngRFJ7eog1Miew=.c080fccf-a2b0-46cc-9e4a-306c226cce3c@github.com>
 <j7YPtBR8ylz-kuKwNVPgR8v2Tj2bAU7DE7UNr7G7mO4=.ef19d436-f320-460e-9c0d-6610ec7db5f6@github.com>
Message-ID: <V8-ktRi7BSd6chf4XnYiFDEHnhRGEtwQxKv5NN6Wd5I=.25c9045a-dce1-4fc7-906e-44e46022242c@github.com>

On Mon, 26 Jul 2021 03:28:44 GMT, Lin Zang <lzang at openjdk.org> wrote:

>> 4890732: GZIPOutputStream doesn't support optional GZIP fields
>
> Lin Zang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:
> 
>  - change since version to 18
>  - Merge branch 'master' into gzip-field
>  - Merge branch 'master' into gzip-field
>  - Add api in GZIPInputStream to get header data
>  - Merge remote-tracking branch 'upstream/master' into gzip-field
>  - remove trailing spaces
>  - Use record and Builder pattern
>  - add class GZIPHeaderData, refine testcases
>  - update copyright
>  - reuse arguments constructor for non-argument one.
>  - ... and 3 more: https://git.openjdk.java.net/jdk/compare/e627caec...b1868e8f

Thank you for reviving the discussion.

I have not gone through the latest update in detail but there are some changes that are needed. Before moving forward with the CSR, I would like to give time for additional feedback  on naming and design.

  I am not sure  the builder names withXXX are the preferred naming pattern.

src/java.base/share/classes/java/util/zip/GZIPHeaderBuilder.java line 33:

> 31:  * @author      Lin Zang
> 32:  * @since 18
> 33:  *

The overview section needs more detail and examples of the usage

Please remove the author tag as we have moved away from this tag (you can see who was involved via the file history

src/java.base/share/classes/java/util/zip/GZIPHeaderBuilder.java line 114:

> 112:      */
> 113:     public GZIPHeaderBuilder withFileComment(String fileComment) {
> 114:         if (fileComment == null || fileComment.length() == 0) {

What happens if the String contains characters outside of ISO_8859_1?

src/java.base/share/classes/java/util/zip/GZIPHeaderBuilder.java line 136:

> 134:         return this;
> 135:     }
> 136: 

Is this really needed as a public method ?

src/java.base/share/classes/java/util/zip/GZIPOutputStream.java line 74:

> 72:                             int size,
> 73:                             boolean syncFlush,
> 74:                             GZIPHeaderBuilder.GZIPHeaderData gzipHeaderData)

Given the Gzip header data is so infrequently modified,  one additional constructor is all that really need.

src/java.base/share/classes/java/util/zip/GZIPOutputStream.java line 91:

> 89:      * Creates a new output stream with the specified buffer size and
> 90:      * flush mode. And leave all other header fields set to default value.
> 91:      *

This needs rewording as we do not typically start a sentence with "And..."

src/java.base/share/classes/java/util/zip/GZIPOutputStream.java line 113:

> 111:     /**
> 112:      * Creates a new output stream with the specified buffer size.
> 113:      * And leave all other header fields set to default value.

Same comment regarding "And..."

src/java.base/share/classes/java/util/zip/GZIPOutputStream.java line 144:

> 142:     /**
> 143:      * Creates a new output stream with a default buffer size and
> 144:      * the specified flush mode. And leave all other header fields

Same comment regarding "And..."

-------------

Changes requested by lancea (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3072

From lancea at openjdk.java.net  Mon Jul 26 21:16:31 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Mon, 26 Jul 2021 21:16:31 GMT
Subject: RFR: 8190753: (zipfs): Accessing a large entry (> 2^31 bytes)
 leads to a negative initial size for ByteArrayOutputStream [v11]
In-Reply-To: <27fDIfBum2vSv7DmFs_PH8Z27NAYMVeMUmAa6OOJgfI=.b125d8c7-83a0-48d5-8342-d0da696fdbff@github.com>
References: <0GJVLeCPoDI4FePU-Z-NMwJHaS2XyH9S28LgqI1LNB8=.e32743dc-a6dd-475d-88ab-16ed3f46beab@github.com>
 <eglX2CJeKvHWYuASSDER6ClGtBUbYk3YVD9cpensiDY=.2450e7d6-9c0e-4de6-a907-d878f21a0e6e@github.com>
 <2ttMZAIqSLz7XfsDi0CQjsaApF19Vk68hNNgh_WDIw0=.a4b275b9-3ce9-4101-9dfd-0db920386eb1@github.com>
 <27fDIfBum2vSv7DmFs_PH8Z27NAYMVeMUmAa6OOJgfI=.b125d8c7-83a0-48d5-8342-d0da696fdbff@github.com>
Message-ID: <0hitV3isecJqQy6DhbOYBrBufoIj5I0xNINiPBzkbLA=.2fb39881-8a70-46b2-ad43-d0b090941667@github.com>

On Fri, 23 Jul 2021 16:22:01 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> > Thank you for the review Alan.
> > @LanceAndersen, I've run the tier1 tests locally with the latest PR and they have passed without any regressions. Given that we changed the implementation to wrap ByteArrayOutputStream instead of extending it, would you want to rerun some of your other tests that you had previously run, before I integrate this?
> 
> Yes, I will run additional tests and report back after they complete

I did not notice any new issues after running tier1 - tier3

-------------

PR: https://git.openjdk.java.net/jdk/pull/4607

From prappo at openjdk.java.net  Mon Jul 26 22:12:36 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Mon, 26 Jul 2021 22:12:36 GMT
Subject: RFR: 8269753: Misplaced caret in PatternSyntaxException's detail
 message [v3]
In-Reply-To: <EaSHhtp9HQMdwz8PvzOh88sjLr03yud2ZeFB_JOwOZE=.d5f04b26-1887-417a-bef7-61210e856838@github.com>
References: <GXNX7r4c57Cyq9rRoXfcGp_Wb1M1PgTs1Axp-sMIRac=.7d6344f4-666e-4afc-88ae-88a835bed930@github.com>
 <EaSHhtp9HQMdwz8PvzOh88sjLr03yud2ZeFB_JOwOZE=.d5f04b26-1887-417a-bef7-61210e856838@github.com>
Message-ID: <gPaSD_qxONR7nltN3Sevs7b3EANuR4KgkKT4UQLY2zc=.1600f006-9b95-40f1-8b5a-914e8c4a6d2d@github.com>

On Mon, 26 Jul 2021 20:54:53 GMT, Ian Graves <igraves at openjdk.org> wrote:

>> Fixes a bug where carets aren't indented correctly in PatternSyntaxException messages because tab characters are converted to spaces in their indentation.
>
> Ian Graves has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Tweaking some spacing. Fixing some report placement.

Marked as reviewed by prappo (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4906

From bpb at openjdk.java.net  Tue Jul 27 00:02:39 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Tue, 27 Jul 2021 00:02:39 GMT
Subject: RFR: 8265891: (ch) InputStream returned by
 Channels.newInputStream should override transferTo [v6]
In-Reply-To: <5PpEoJT1JZoo75hz4HAQFkipRfXCr_7MyTE8g4yhhgc=.5eeefcfe-205b-4b02-a59b-bead8b410139@github.com>
References: <XlU5gCBUEa4qTTz8yhMeElh95FuiPcFYQ_nj_WYvbLE=.6e9fc6a4-f3b1-4faf-91f0-d8b06f875780@github.com>
 <5PpEoJT1JZoo75hz4HAQFkipRfXCr_7MyTE8g4yhhgc=.5eeefcfe-205b-4b02-a59b-bead8b410139@github.com>
Message-ID: <IZKluRfiLnIovyrAw3TdXDSzB6e59nHmG3ee7PEtjSE=.a778bb70-9938-4599-a3d9-9ad8fa235b00@github.com>

On Mon, 26 Jul 2021 20:45:14 GMT, Markus KARG <github.com+1701815+mkarg at openjdk.org> wrote:

>> This PR-*draft* is **work in progress** and an invitation to discuss a possible solution for issue [JDK-8265891](https://bugs.openjdk.java.net/browse/JDK-8265891). It is *not yet* intended for a final review.
>> 
>> As proposed in JDK-8265891, this PR provides an implementation for `Channels.newInputStream().transferTo()` which provide superior performance compared to the current implementation. The changes are:
>> * Prevents transfers through the JVM heap as much as possibly by offloading to deeper levels via NIO, hence allowing the operating system to optimize the transfer.
>> * Using more JRE heap in the fallback case when no NIO is possible (still only KiBs, hence mostl ynegligible even on SBCs) to better perform on modern hardware / fast I/O devides.
>> 
>> Using JMH I have benchmarked both, the original implementation and this implementation, and (depending on the used hardware and use case) performance change was approx. doubled performance. So this PoC proofs that it makes sense to finalize this work and turn it into an actual OpenJDK contribution. 
>> 
>> I encourage everybody to discuss this draft:
>> * Are there valid arguments for *not* doing this change?
>> * Is there a *better* way to improve performance of `Channels.newInputStream().transferTo()`?
>> * How to go on from here: What is missing to get this ready for an actual review?
>
> Markus KARG 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/nio/ch/ChannelInputStream.java line 179:

> 177:             for (long n = srcSize - srcPos; bytesWritten < n;)
> 178:                 bytesWritten += src.transferTo(srcPos + bytesWritten, Long.MAX_VALUE, dest);
> 179:             return bytesWritten;

If `src` is extended at an inconvenient point in time, for example between the return from a call to `src.transferTo()` that makes `bytesWritten < n` false and the evaluation of that terminating condition, then it appears that not all the content of `src` will be transferred to `dest`. I am not however sure that this violates any contract but it could be a behavioral change from the existing implementation.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4263

From bpb at openjdk.java.net  Tue Jul 27 01:00:38 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Tue, 27 Jul 2021 01:00:38 GMT
Subject: RFR: 8265891: (ch) InputStream returned by
 Channels.newInputStream should override transferTo [v6]
In-Reply-To: <5PpEoJT1JZoo75hz4HAQFkipRfXCr_7MyTE8g4yhhgc=.5eeefcfe-205b-4b02-a59b-bead8b410139@github.com>
References: <XlU5gCBUEa4qTTz8yhMeElh95FuiPcFYQ_nj_WYvbLE=.6e9fc6a4-f3b1-4faf-91f0-d8b06f875780@github.com>
 <5PpEoJT1JZoo75hz4HAQFkipRfXCr_7MyTE8g4yhhgc=.5eeefcfe-205b-4b02-a59b-bead8b410139@github.com>
Message-ID: <eqqcs-9h_-p55lUyHJmmQgqbLCZ48MyBtDPi9eZH_bM=.17d7f6d4-6a37-4350-b774-e7040c85cab9@github.com>

On Mon, 26 Jul 2021 20:45:14 GMT, Markus KARG <github.com+1701815+mkarg at openjdk.org> wrote:

>> This PR-*draft* is **work in progress** and an invitation to discuss a possible solution for issue [JDK-8265891](https://bugs.openjdk.java.net/browse/JDK-8265891). It is *not yet* intended for a final review.
>> 
>> As proposed in JDK-8265891, this PR provides an implementation for `Channels.newInputStream().transferTo()` which provide superior performance compared to the current implementation. The changes are:
>> * Prevents transfers through the JVM heap as much as possibly by offloading to deeper levels via NIO, hence allowing the operating system to optimize the transfer.
>> * Using more JRE heap in the fallback case when no NIO is possible (still only KiBs, hence mostl ynegligible even on SBCs) to better perform on modern hardware / fast I/O devides.
>> 
>> Using JMH I have benchmarked both, the original implementation and this implementation, and (depending on the used hardware and use case) performance change was approx. doubled performance. So this PoC proofs that it makes sense to finalize this work and turn it into an actual OpenJDK contribution. 
>> 
>> I encourage everybody to discuss this draft:
>> * Are there valid arguments for *not* doing this change?
>> * Is there a *better* way to improve performance of `Channels.newInputStream().transferTo()`?
>> * How to go on from here: What is missing to get this ready for an actual review?
>
> Markus KARG 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/nio/ch/ChannelOutputStream.java line 85:

> 83:     private byte[] bs;       // Invoker's previous array
> 84:     private byte[] b1;
> 85: 

It might be better to put the field declarations at the beginning of the class before the static methods.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4263

From jpai at openjdk.java.net  Tue Jul 27 01:57:52 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Tue, 27 Jul 2021 01:57:52 GMT
Subject: RFR: 8190753: (zipfs): Accessing a large entry (> 2^31 bytes)
 leads to a negative initial size for ByteArrayOutputStream [v11]
In-Reply-To: <eglX2CJeKvHWYuASSDER6ClGtBUbYk3YVD9cpensiDY=.2450e7d6-9c0e-4de6-a907-d878f21a0e6e@github.com>
References: <0GJVLeCPoDI4FePU-Z-NMwJHaS2XyH9S28LgqI1LNB8=.e32743dc-a6dd-475d-88ab-16ed3f46beab@github.com>
 <eglX2CJeKvHWYuASSDER6ClGtBUbYk3YVD9cpensiDY=.2450e7d6-9c0e-4de6-a907-d878f21a0e6e@github.com>
Message-ID: <B1yo3mGV6Q_Pb46wGa3o8JB_-iWlVio7asluZHA-TOo=.fcd71ffb-338c-41bf-b197-b7f2f2f79859@github.com>

On Fri, 23 Jul 2021 14:58:01 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this proposed fix for the issue reported in https://bugs.openjdk.java.net/browse/JDK-8190753?
>> 
>> The commit here checks for the size of the zip entry before trying to create a `ByteArrayOutputStream` for that entry's content. A new jtreg test has been included in this commit to reproduce the issue and verify the fix.
>> 
>> P.S: It's still a bit arguable whether it's a good idea to create the `ByteArrayOutputStream` with an initial size potentially as large as the `MAX_ARRAY_SIZE` or whether it's better to just use some smaller default value. However, I think that can be addressed separately while dealing with https://bugs.openjdk.java.net/browse/JDK-8011146
>
> Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 15 additional commits since the last revision:
> 
>  - Merge latest from master branch
>  - Implement review suggestions:
>     - remove unnecessary "synchronized"
>     - no need to open the temp file twice
>  - remove no longer necessary javadoc comment on test
>  - review suggestion - wrap ByteArrayOutputStream instead of extending it
>  - reorganize the tests now that the temp file creation threshold isn't exposed as a user configurable value
>  - minor update to comment on FileRolloverOutputStream class
>  - remove no longer used constant
>  - use jtreg's construct of manual test
>  - Implement Alan's review suggestion - don't expose the threshold as a configuration property, instead set it internally to a specific value
>  - propagate back the original checked IOException to the callers
>  - ... and 5 more: https://git.openjdk.java.net/jdk/compare/f875aac8...991de6b9

Thank you for running the tests, Lance.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4607

From jpai at openjdk.java.net  Tue Jul 27 02:00:39 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Tue, 27 Jul 2021 02:00:39 GMT
Subject: Integrated: 8190753: (zipfs): Accessing a large entry (> 2^31 bytes)
 leads to a negative initial size for ByteArrayOutputStream
In-Reply-To: <0GJVLeCPoDI4FePU-Z-NMwJHaS2XyH9S28LgqI1LNB8=.e32743dc-a6dd-475d-88ab-16ed3f46beab@github.com>
References: <0GJVLeCPoDI4FePU-Z-NMwJHaS2XyH9S28LgqI1LNB8=.e32743dc-a6dd-475d-88ab-16ed3f46beab@github.com>
Message-ID: <waIETIaMapLWj63rHOjx2Vcf7JyKFaW4LwVICki2E9w=.9d4557aa-a4f3-47f4-ad21-4a3ea2a5243d@github.com>

On Mon, 28 Jun 2021 03:41:20 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review for this proposed fix for the issue reported in https://bugs.openjdk.java.net/browse/JDK-8190753?
> 
> The commit here checks for the size of the zip entry before trying to create a `ByteArrayOutputStream` for that entry's content. A new jtreg test has been included in this commit to reproduce the issue and verify the fix.
> 
> P.S: It's still a bit arguable whether it's a good idea to create the `ByteArrayOutputStream` with an initial size potentially as large as the `MAX_ARRAY_SIZE` or whether it's better to just use some smaller default value. However, I think that can be addressed separately while dealing with https://bugs.openjdk.java.net/browse/JDK-8011146

This pull request has now been integrated.

Changeset: c3d8e922
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c3d8e9228d0558a2ce3e093c105c61ea7af2e1d1
Stats:     356 lines in 3 files changed: 350 ins; 0 del; 6 mod

8190753: (zipfs): Accessing a large entry (> 2^31 bytes) leads to a negative initial size for ByteArrayOutputStream

Reviewed-by: lancea

-------------

PR: https://git.openjdk.java.net/jdk/pull/4607

From bpb at openjdk.java.net  Tue Jul 27 02:22:32 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Tue, 27 Jul 2021 02:22:32 GMT
Subject: RFR: 8265891: (ch) InputStream returned by
 Channels.newInputStream should override transferTo [v6]
In-Reply-To: <5PpEoJT1JZoo75hz4HAQFkipRfXCr_7MyTE8g4yhhgc=.5eeefcfe-205b-4b02-a59b-bead8b410139@github.com>
References: <XlU5gCBUEa4qTTz8yhMeElh95FuiPcFYQ_nj_WYvbLE=.6e9fc6a4-f3b1-4faf-91f0-d8b06f875780@github.com>
 <5PpEoJT1JZoo75hz4HAQFkipRfXCr_7MyTE8g4yhhgc=.5eeefcfe-205b-4b02-a59b-bead8b410139@github.com>
Message-ID: <g2LuISWVJcLFeSuUXfmfeqe7wl7kvcKsVgH2WXI90p4=.14176736-5173-41f3-b859-64cb9b986623@github.com>

On Mon, 26 Jul 2021 20:45:14 GMT, Markus KARG <github.com+1701815+mkarg at openjdk.org> wrote:

>> This PR-*draft* is **work in progress** and an invitation to discuss a possible solution for issue [JDK-8265891](https://bugs.openjdk.java.net/browse/JDK-8265891). It is *not yet* intended for a final review.
>> 
>> As proposed in JDK-8265891, this PR provides an implementation for `Channels.newInputStream().transferTo()` which provide superior performance compared to the current implementation. The changes are:
>> * Prevents transfers through the JVM heap as much as possibly by offloading to deeper levels via NIO, hence allowing the operating system to optimize the transfer.
>> * Using more JRE heap in the fallback case when no NIO is possible (still only KiBs, hence mostl ynegligible even on SBCs) to better perform on modern hardware / fast I/O devides.
>> 
>> Using JMH I have benchmarked both, the original implementation and this implementation, and (depending on the used hardware and use case) performance change was approx. doubled performance. So this PoC proofs that it makes sense to finalize this work and turn it into an actual OpenJDK contribution. 
>> 
>> I encourage everybody to discuss this draft:
>> * Are there valid arguments for *not* doing this change?
>> * Is there a *better* way to improve performance of `Channels.newInputStream().transferTo()`?
>> * How to go on from here: What is missing to get this ready for an actual review?
>
> Markus KARG 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/sun/nio/ch/ChannelInputStream/TransferTo.java line 67:

> 65:         test(readableByteChannelInput(), defaultOutput());
> 66:     }
> 67: 

This test looks like it's doing what it's supposed to do. I'm not asking to change it, but I think using TestNG might have given a simpler result with less work. For example, there could be one `DataProvider` supplying inputs which feed a `@Test` which expects an NPE, and another `DataProvider` supplying input-output pairs which feeds a `@Test` which validates the functionality.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4263

From igraves at openjdk.java.net  Tue Jul 27 02:28:32 2021
From: igraves at openjdk.java.net (Ian Graves)
Date: Tue, 27 Jul 2021 02:28:32 GMT
Subject: Integrated: 8269753: Misplaced caret in PatternSyntaxException's
 detail message
In-Reply-To: <GXNX7r4c57Cyq9rRoXfcGp_Wb1M1PgTs1Axp-sMIRac=.7d6344f4-666e-4afc-88ae-88a835bed930@github.com>
References: <GXNX7r4c57Cyq9rRoXfcGp_Wb1M1PgTs1Axp-sMIRac=.7d6344f4-666e-4afc-88ae-88a835bed930@github.com>
Message-ID: <Hf97fu-9dI4ch7-2vAMLpgEoxZNGN25prAkp23pFDWQ=.c511aa1d-6f1e-442c-bf90-c5c31eab09b7@github.com>

On Mon, 26 Jul 2021 18:10:03 GMT, Ian Graves <igraves at openjdk.org> wrote:

> Fixes a bug where carets aren't indented correctly in PatternSyntaxException messages because tab characters are converted to spaces in their indentation.

This pull request has now been integrated.

Changeset: bb508e13
Author:    Ian Graves <igraves at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/bb508e13032c3571c48275391dfeb04c03bbf3a3
Stats:     24 lines in 2 files changed: 21 ins; 0 del; 3 mod

8269753: Misplaced caret in PatternSyntaxException's detail message

Reviewed-by: prappo

-------------

PR: https://git.openjdk.java.net/jdk/pull/4906

From eliu at openjdk.java.net  Tue Jul 27 02:55:32 2021
From: eliu at openjdk.java.net (Eric Liu)
Date: Tue, 27 Jul 2021 02:55:32 GMT
Subject: RFR: 8266054: VectorAPI rotate operation optimization [v10]
In-Reply-To: <HvAMP5HzhzUGb1L_zSDdGL00POSydoS1zT29E4LeO_Q=.1649b2d4-308d-40ea-b43e-c0dcd56c11b5@github.com>
References: <OZ2u4DDNaYF3WiR5uU6NWvzPMKV3j8QAO_mZyLP3Isg=.594e3514-8a5a-442c-ac1a-ca6c6d14e963@github.com>
 <j-MimQL3RfOga-_XaS0UWHPsmDp99CyUer8f_bFptmo=.231d4cc0-e9ee-47d8-ad6c-41adcf114367@github.com>
 <mF_TPuiSWMhsH4OoVgvPDJ2VcSP8MGhj1mL7ACIyoQg=.e9e159d5-90ec-470a-84b9-167c36ce6c7f@github.com>
 <57RjIAXAeh_OL4TKIusvf_Zzcdy8sojU874yc1lH2yY=.3acc983b-9152-404c-a67a-d484fe41c15b@github.com>
 <OwhhLDoNCALTI4sXL6P_4iVtX-M6psAL2IoyTP8RwS8=.98105420-c710-4aa1-8a45-bed07608776b@github.com>
 <HvAMP5HzhzUGb1L_zSDdGL00POSydoS1zT29E4LeO_Q=.1649b2d4-308d-40ea-b43e-c0dcd56c11b5@github.com>
Message-ID: <T6m3nWtDYJuvtu63cTKRAAK0hqoDwJFlTSWDMl1xeM4=.1876e923-6f7b-425d-893f-c58c8b766343@github.com>

On Mon, 26 Jul 2021 18:56:01 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> @jatin-bhateja  This question is still pending.
>
> @sviswa7, SLP flow will either have a constant 8bit shift value or a variable shift present in vector. So non constant scalar case will not be hit through this route.

It would be better comment here, since the correctness relay on some others.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3720

From sviswanathan at openjdk.java.net  Tue Jul 27 04:07:37 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Tue, 27 Jul 2021 04:07:37 GMT
Subject: RFR: 8266054: VectorAPI rotate operation optimization [v13]
In-Reply-To: <HU2E5YuCI7Iz38CNycxu62RVNsyyT9unlr79-fSwFVg=.fde03b0d-6f8f-445f-88e4-84511f50226b@github.com>
References: <OZ2u4DDNaYF3WiR5uU6NWvzPMKV3j8QAO_mZyLP3Isg=.594e3514-8a5a-442c-ac1a-ca6c6d14e963@github.com>
 <HU2E5YuCI7Iz38CNycxu62RVNsyyT9unlr79-fSwFVg=.fde03b0d-6f8f-445f-88e4-84511f50226b@github.com>
Message-ID: <aqV8l0nNTwpat7s4IuOqdXpywz8gT_-QUrpUpBrv5lo=.7d07f269-2996-4e5f-9c6d-a04ae657330a@github.com>

On Tue, 20 Jul 2021 09:57:07 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Current VectorAPI Java side implementation expresses rotateLeft and rotateRight operation using following operations:-
>> 
>>     vec1 = lanewise(VectorOperators.LSHL, n)
>>     vec2 = lanewise(VectorOperators.LSHR, n)
>>     res = lanewise(VectorOperations.OR, vec1 , vec2)
>> 
>> This patch moves above handling from Java side to C2 compiler which facilitates dismantling the rotate operation if target ISA does not support a direct rotate instruction.
>> 
>> AVX512 added vector rotate instructions vpro[rl][v][dq] which operate over long and integer type vectors. For other cases (i.e. sub-word type vectors or for targets which do not support direct rotate operations )   instruction sequence comprising of vector SHIFT (LEFT/RIGHT) and vector OR is emitted.
>> 
>> Please find below the performance data for included JMH benchmark.
>> Machine:  Cascade Lake Server (Intel(R) Xeon(R) Platinum 8280 CPU @ 2.70GHz)
>> 
>> 
>> <html xmlns:v="urn:schemas-microsoft-com:vml"
>> xmlns:o="urn:schemas-microsoft-com:office:office"
>> xmlns:x="urn:schemas-microsoft-com:office:excel"
>> xmlns="http://www.w3.org/TR/REC-html40">
>> 
>> <head>
>> 
>> <meta name=ProgId content=Excel.Sheet>
>> <meta name=Generator content="Microsoft Excel 15">
>> <link id=Main-File rel=Main-File
>> href="file:///C:/Users/jatinbha/AppData/Local/Temp/msohtmlclip1/01/clip.htm">
>> <link rel=File-List
>> href="file:///C:/Users/jatinbha/AppData/Local/Temp/msohtmlclip1/01/clip_filelist.xml">
>> <style>
>> 
>> </style>
>> </head>
>> 
>> <body link="#0563C1" vlink="#954F72">
>> 
>> 
>> 
>> Benchmark | (bits) | (shift) | (size) | Baseline Score (ops/ms) | With Opts (ops/ms) | Gain
>> -- | -- | -- | -- | -- | -- | --
>> RotateBenchmark.testRotateLeftB | 128 | 7 | 256 | 3939.136 | 3836.133 | 0.973851372
>> RotateBenchmark.testRotateLeftB | 128 | 7 | 512 | 1984.231 | 1918.27 | 0.966757399
>> RotateBenchmark.testRotateLeftB | 128 | 15 | 256 | 3925.165 | 4043.842 | 1.030234907
>> RotateBenchmark.testRotateLeftB | 128 | 15 | 512 | 1962.723 | 1936.551 | 0.986665464
>> RotateBenchmark.testRotateLeftB | 128 | 31 | 256 | 3945.6 | 3817.883 | 0.967630525
>> RotateBenchmark.testRotateLeftB | 128 | 31 | 512 | 1944.458 | 1914.229 | 0.984453766
>> RotateBenchmark.testRotateLeftB | 256 | 7 | 256 | 4612.149 | 4514.874 | 0.978908964
>> RotateBenchmark.testRotateLeftB | 256 | 7 | 512 | 2296.252 | 2270.237 | 0.988670669
>> RotateBenchmark.testRotateLeftB | 256 | 15 | 256 | 4576.628 | 4515.53 | 0.986649996
>> RotateBenchmark.testRotateLeftB | 256 | 15 | 512 | 2288.278 | 2270.923 | 0.992415694
>> RotateBenchmark.testRotateLeftB | 256 | 31 | 256 | 4624.243 | 4511.46 | 0.975610495
>> RotateBenchmark.testRotateLeftB | 256 | 31 | 512 | 2305.459 | 2273.788 | 0.986262605
>> RotateBenchmark.testRotateLeftB | 512 | 7 | 256 | 7748.283 | 7777.105 | 1.003719792
>> RotateBenchmark.testRotateLeftB | 512 | 7 | 512 | 3906.214 | 3912.647 | 1.001646863
>> RotateBenchmark.testRotateLeftB | 512 | 15 | 256 | 7764.653 | 7763.482 | 0.999849188
>> RotateBenchmark.testRotateLeftB | 512 | 15 | 512 | 3916.061 | 3919.363 | 1.000843194
>> RotateBenchmark.testRotateLeftB | 512 | 31 | 256 | 7779.754 | 7770.239 | 0.998776954
>> RotateBenchmark.testRotateLeftB | 512 | 31 | 512 | 3916.471 | 3912.718 | 0.999041739
>> RotateBenchmark.testRotateLeftI | 128 | 7 | 256 | 4043.39 | 13461.814 | 3.329338501
>> RotateBenchmark.testRotateLeftI | 128 | 7 | 512 | 1996.217 | 6455.425 | 3.233829288
>> RotateBenchmark.testRotateLeftI | 128 | 15 | 256 | 4028.614 | 13077.277 | 3.246098286
>> RotateBenchmark.testRotateLeftI | 128 | 15 | 512 | 1997.612 | 6452.918 | 3.230315997
>> RotateBenchmark.testRotateLeftI | 128 | 31 | 256 | 4123.357 | 13079.045 | 3.171940969
>> RotateBenchmark.testRotateLeftI | 128 | 31 | 512 | 2003.356 | 6452.716 | 3.22095324
>> RotateBenchmark.testRotateLeftI | 256 | 7 | 256 | 7666.949 | 25658.625 | 3.34665393
>> RotateBenchmark.testRotateLeftI | 256 | 7 | 512 | 3855.826 | 12278.106 | 3.18429981
>> RotateBenchmark.testRotateLeftI | 256 | 15 | 256 | 7670.901 | 24625.466 | 3.210244272
>> RotateBenchmark.testRotateLeftI | 256 | 15 | 512 | 3765.786 | 12272.771 | 3.259019764
>> RotateBenchmark.testRotateLeftI | 256 | 31 | 256 | 7660.599 | 25678.864 | 3.352069988
>> RotateBenchmark.testRotateLeftI | 256 | 31 | 512 | 3773.401 | 12006.469 | 3.181869353
>> RotateBenchmark.testRotateLeftI | 512 | 7 | 256 | 11900.948 | 31242.989 | 2.625252123
>> RotateBenchmark.testRotateLeftI | 512 | 7 | 512 | 5830.878 | 15727.149 | 2.697217983
>> RotateBenchmark.testRotateLeftI | 512 | 15 | 256 | 12171.847 | 33180.067 | 2.72596813
>> RotateBenchmark.testRotateLeftI | 512 | 15 | 512 | 5830.544 | 16740.182 | 2.871118372
>> RotateBenchmark.testRotateLeftI | 512 | 31 | 256 | 11909.553 | 31250.882 | 2.624018047
>> RotateBenchmark.testRotateLeftI | 512 | 31 | 512 | 5846.747 | 15738.831 | 2.691895339
>> RotateBenchmark.testRotateLeftL | 128 | 7 | 256 | 2047.243 | 6888.484 | 3.364761291
>> RotateBenchmark.testRotateLeftL | 128 | 7 | 512 | 1005.029 | 3245.931 | 3.229688895
>> RotateBenchmark.testRotateLeftL | 128 | 15 | 256 | 1996.921 | 6985.256 | 3.498013191
>> RotateBenchmark.testRotateLeftL | 128 | 15 | 512 | 986.906 | 3217.778 | 3.260470602
>> RotateBenchmark.testRotateLeftL | 128 | 31 | 256 | 1999.06 | 6977.672 | 3.490476524
>> RotateBenchmark.testRotateLeftL | 128 | 31 | 512 | 987.258 | 3236.63 | 3.278403416
>> RotateBenchmark.testRotateLeftL | 256 | 7 | 256 | 3752.412 | 12995.954 | 3.4633601
>> RotateBenchmark.testRotateLeftL | 256 | 7 | 512 | 1824.093 | 5809.576 | 3.184912173
>> RotateBenchmark.testRotateLeftL | 256 | 15 | 256 | 3759.99 | 13262.631 | 3.52730486
>> RotateBenchmark.testRotateLeftL | 256 | 15 | 512 | 1823.393 | 5803.872 | 3.183006626
>> RotateBenchmark.testRotateLeftL | 256 | 31 | 256 | 3757.134 | 13284.633 | 3.535842214
>> RotateBenchmark.testRotateLeftL | 256 | 31 | 512 | 1822.192 | 5824.178 | 3.196248255
>> RotateBenchmark.testRotateLeftL | 512 | 7 | 256 | 5794.005 | 15567.753 | 2.686872552
>> RotateBenchmark.testRotateLeftL | 512 | 7 | 512 | 2969.393 | 7694.79 | 2.591368
>> RotateBenchmark.testRotateLeftL | 512 | 15 | 256 | 5817.292 | 15726.597 | 2.703422314
>> RotateBenchmark.testRotateLeftL | 512 | 15 | 512 | 2944.655 | 7664.954 | 2.603005785
>> RotateBenchmark.testRotateLeftL | 512 | 31 | 256 | 5822.131 | 16718.64 | 2.871567129
>> RotateBenchmark.testRotateLeftL | 512 | 31 | 512 | 2944.763 | 7657.814 | 2.600485676
>> RotateBenchmark.testRotateLeftS | 128 | 7 | 256 | 8006.155 | 7976.701 | 0.99632108
>> RotateBenchmark.testRotateLeftS | 128 | 7 | 512 | 4031.753 | 4003.43 | 0.992975016
>> RotateBenchmark.testRotateLeftS | 128 | 15 | 256 | 8003.879 | 7952.752 | 0.993612222
>> RotateBenchmark.testRotateLeftS | 128 | 15 | 512 | 4026.359 | 4014.757 | 0.997118488
>> RotateBenchmark.testRotateLeftS | 128 | 31 | 256 | 8000.842 | 7995.733 | 0.999361442
>> RotateBenchmark.testRotateLeftS | 128 | 31 | 512 | 4044.421 | 4007.426 | 0.990852832
>> RotateBenchmark.testRotateLeftS | 256 | 7 | 256 | 15078.471 | 15034.395 | 0.997076892
>> RotateBenchmark.testRotateLeftS | 256 | 7 | 512 | 7236.509 | 7620.334 | 1.053040078
>> RotateBenchmark.testRotateLeftS | 256 | 15 | 256 | 15093.661 | 15024.17 | 0.995396014
>> RotateBenchmark.testRotateLeftS | 256 | 15 | 512 | 7308.568 | 7724.381 | 1.056893909
>> RotateBenchmark.testRotateLeftS | 256 | 31 | 256 | 15332.233 | 15432.113 | 1.006514381
>> RotateBenchmark.testRotateLeftS | 256 | 31 | 512 | 7317.18 | 7626.679 | 1.042297579
>> RotateBenchmark.testRotateLeftS | 512 | 7 | 256 | 24079.012 | 23939.263 | 0.994196232
>> RotateBenchmark.testRotateLeftS | 512 | 7 | 512 | 11441.41 | 11921.21 | 1.041935391
>> RotateBenchmark.testRotateLeftS | 512 | 15 | 256 | 23563.675 | 23590.959 | 1.001157884
>> RotateBenchmark.testRotateLeftS | 512 | 15 | 512 | 11418.634 | 11949.391 | 1.046481654
>> RotateBenchmark.testRotateLeftS | 512 | 31 | 256 | 24035.69 | 23595.385 | 0.9816812
>> RotateBenchmark.testRotateLeftS | 512 | 31 | 512 | 11668.091 | 11899.536 | 1.019835721
>> RotateBenchmark.testRotateRightB | 128 | 7 | 256 | 3852.421 | 3816.521 | 0.990681185
>> RotateBenchmark.testRotateRightB | 128 | 7 | 512 | 1956.766 | 1923.638 | 0.983070025
>> RotateBenchmark.testRotateRightB | 128 | 15 | 256 | 3899.136 | 4038.945 | 1.035856405
>> RotateBenchmark.testRotateRightB | 128 | 15 | 512 | 1957.733 | 2030.973 | 1.037410617
>> RotateBenchmark.testRotateRightB | 128 | 31 | 256 | 3902.5 | 4043.736 | 1.03619116
>> RotateBenchmark.testRotateRightB | 128 | 31 | 512 | 1957.728 | 1920.434 | 0.980950367
>> RotateBenchmark.testRotateRightB | 256 | 7 | 256 | 4565.887 | 4515.083 | 0.988873137
>> RotateBenchmark.testRotateRightB | 256 | 7 | 512 | 2300.057 | 2278.065 | 0.990438498
>> RotateBenchmark.testRotateRightB | 256 | 15 | 256 | 4570.754 | 4527.692 | 0.990578797
>> RotateBenchmark.testRotateRightB | 256 | 15 | 512 | 2300.524 | 2268.659 | 0.986148808
>> RotateBenchmark.testRotateRightB | 256 | 31 | 256 | 4577.569 | 4513.29 | 0.98595783
>> RotateBenchmark.testRotateRightB | 256 | 31 | 512 | 2304.335 | 2273.178 | 0.986478962
>> RotateBenchmark.testRotateRightB | 512 | 7 | 256 | 7772.483 | 7842.671 | 1.009030319
>> RotateBenchmark.testRotateRightB | 512 | 7 | 512 | 3907.265 | 3917.325 | 1.002574691
>> RotateBenchmark.testRotateRightB | 512 | 15 | 256 | 7855.653 | 7865.25 | 1.001221668
>> RotateBenchmark.testRotateRightB | 512 | 15 | 512 | 3909.845 | 3976.813 | 1.017128045
>> RotateBenchmark.testRotateRightB | 512 | 31 | 256 | 7746.765 | 7870.159 | 1.015928455
>> RotateBenchmark.testRotateRightB | 512 | 31 | 512 | 3919.596 | 3981.934 | 1.01590419
>> RotateBenchmark.testRotateRightI | 128 | 7 | 256 | 4125.151 | 13056.878 | 3.165187893
>> RotateBenchmark.testRotateRightI | 128 | 7 | 512 | 2045.201 | 6501.447 | 3.17887924
>> RotateBenchmark.testRotateRightI | 128 | 15 | 256 | 4111.736 | 13318.124 | 3.23905134
>> RotateBenchmark.testRotateRightI | 128 | 15 | 512 | 2055.355 | 6497.289 | 3.161151723
>> RotateBenchmark.testRotateRightI | 128 | 31 | 256 | 4109.353 | 13073.3 | 3.181352393
>> RotateBenchmark.testRotateRightI | 128 | 31 | 512 | 2055.431 | 6463.902 | 3.14479153
>> RotateBenchmark.testRotateRightI | 256 | 7 | 256 | 7804.976 | 24585.962 | 3.150036848
>> RotateBenchmark.testRotateRightI | 256 | 7 | 512 | 3815.818 | 11985.145 | 3.140911071
>> RotateBenchmark.testRotateRightI | 256 | 15 | 256 | 7644.977 | 25863.841 | 3.383115606
>> RotateBenchmark.testRotateRightI | 256 | 15 | 512 | 3822.508 | 12280.58 | 3.212702236
>> RotateBenchmark.testRotateRightI | 256 | 31 | 256 | 7709.635 | 25655.108 | 3.327668301
>> RotateBenchmark.testRotateRightI | 256 | 31 | 512 | 3801.5 | 12271.65 | 3.228107326
>> RotateBenchmark.testRotateRightI | 512 | 7 | 256 | 12223.711 | 31239.788 | 2.555671351
>> RotateBenchmark.testRotateRightI | 512 | 7 | 512 | 5973.571 | 16740.852 | 2.802486486
>> RotateBenchmark.testRotateRightI | 512 | 15 | 256 | 12205.47 | 31248.025 | 2.560165647
>> RotateBenchmark.testRotateRightI | 512 | 15 | 512 | 5966.513 | 15728.168 | 2.6360737
>> RotateBenchmark.testRotateRightI | 512 | 31 | 256 | 12209.405 | 33181.105 | 2.71766765
>> RotateBenchmark.testRotateRightI | 512 | 31 | 512 | 5981.527 | 15727.496 | 2.629344647
>> RotateBenchmark.testRotateRightL | 128 | 7 | 256 | 2054.509 | 6980.849 | 3.397818652
>> RotateBenchmark.testRotateRightL | 128 | 7 | 512 | 997.375 | 3242.374 | 3.250907633
>> RotateBenchmark.testRotateRightL | 128 | 15 | 256 | 2051.459 | 6892.389 | 3.359749817
>> RotateBenchmark.testRotateRightL | 128 | 15 | 512 | 1002.906 | 3223.342 | 3.21400211
>> RotateBenchmark.testRotateRightL | 128 | 31 | 256 | 2044.749 | 6984.157 | 3.415654929
>> RotateBenchmark.testRotateRightL | 128 | 31 | 512 | 1004.273 | 3237.496 | 3.22372104
>> RotateBenchmark.testRotateRightL | 256 | 7 | 256 | 3811.551 | 13347.75 | 3.501920872
>> RotateBenchmark.testRotateRightL | 256 | 7 | 512 | 1892.883 | 5840.85 | 3.085689924
>> RotateBenchmark.testRotateRightL | 256 | 15 | 256 | 3821.705 | 14034.823 | 3.672398314
>> RotateBenchmark.testRotateRightL | 256 | 15 | 512 | 1799.193 | 5817.533 | 3.233412424
>> RotateBenchmark.testRotateRightL | 256 | 31 | 256 | 3816.666 | 14022.31 | 3.673968327
>> RotateBenchmark.testRotateRightL | 256 | 31 | 512 | 1796.649 | 5824.13 | 3.241662673
>> RotateBenchmark.testRotateRightL | 512 | 7 | 256 | 5943.986 | 15586.254 | 2.622188881
>> RotateBenchmark.testRotateRightL | 512 | 7 | 512 | 3022.686 | 7662.241 | 2.534911334
>> RotateBenchmark.testRotateRightL | 512 | 15 | 256 | 5958.008 | 15726.859 | 2.639616966
>> RotateBenchmark.testRotateRightL | 512 | 15 | 512 | 2998.469 | 7654.703 | 2.552870482
>> RotateBenchmark.testRotateRightL | 512 | 31 | 256 | 5937.491 | 15741.207 | 2.651154671
>> RotateBenchmark.testRotateRightL | 512 | 31 | 512 | 3014.699 | 7656.837 | 2.539834657
>> RotateBenchmark.testRotateRightS | 128 | 7 | 256 | 8172.896 | 8003.474 | 0.979270261
>> RotateBenchmark.testRotateRightS | 128 | 7 | 512 | 4111.074 | 4047.267 | 0.984479238
>> RotateBenchmark.testRotateRightS | 128 | 15 | 256 | 8225.79 | 8040.421 | 0.9774649
>> RotateBenchmark.testRotateRightS | 128 | 15 | 512 | 4129.801 | 4011.919 | 0.971455767
>> RotateBenchmark.testRotateRightS | 128 | 31 | 256 | 8176.102 | 8052.686 | 0.984905276
>> RotateBenchmark.testRotateRightS | 128 | 31 | 512 | 4117.735 | 4046.522 | 0.982705784
>> RotateBenchmark.testRotateRightS | 256 | 7 | 256 | 15213.617 | 15169.51 | 0.997100821
>> RotateBenchmark.testRotateRightS | 256 | 7 | 512 | 7530.289 | 7625.581 | 1.012654494
>> RotateBenchmark.testRotateRightS | 256 | 15 | 256 | 15238.384 | 15069.978 | 0.988948566
>> RotateBenchmark.testRotateRightS | 256 | 15 | 512 | 7275.098 | 7620.764 | 1.047513587
>> RotateBenchmark.testRotateRightS | 256 | 31 | 256 | 15299.821 | 15043.765 | 0.983264118
>> RotateBenchmark.testRotateRightS | 256 | 31 | 512 | 7273.028 | 7630.97 | 1.04921499
>> RotateBenchmark.testRotateRightS | 512 | 7 | 256 | 23998.152 | 23920.046 | 0.996745333
>> RotateBenchmark.testRotateRightS | 512 | 7 | 512 | 11582.679 | 11916.382 | 1.02881052
>> RotateBenchmark.testRotateRightS | 512 | 15 | 256 | 23982.797 | 23434.756 | 0.977148579
>> RotateBenchmark.testRotateRightS | 512 | 15 | 512 | 11629.806 | 11918.759 | 1.0248459
>> RotateBenchmark.testRotateRightS | 512 | 31 | 256 | 23988.549 | 23475.629 | 0.978618132
>> RotateBenchmark.testRotateRightS | 512 | 31 | 512 | 11650.146 | 11916.47 | 1.022860143
>> 
>> 
>> 
>> </body>
>> 
>> </html>
>
> Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits:
> 
>  - 8266054: Re-designing benchmark to remove noise.
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8266054
>  - 8266054: Formal argument name change to be more appropriate.
>  - 8266054: Review comments resolution.
>  - 8266054: Incorporating styling changes based on reviews.
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8266054
>  - Merge http://github.com/openjdk/jdk into JDK-8266054
>  - Merge http://github.com/openjdk/jdk into JDK-8266054
>  - Merge http://github.com/openjdk/jdk into JDK-8266054
>  - Merge branch 'JDK-8266054' of http://github.com/jatin-bhateja/jdk into JDK-8266054
>  - ... and 9 more: https://git.openjdk.java.net/jdk/compare/a8f15427...b20404e2

src/hotspot/share/opto/vectorIntrinsics.cpp line 1598:

> 1596:       cnt = elem_bt == T_LONG ? gvn().transform(new ConvI2LNode(cnt)) : cnt;
> 1597:       opd2 = gvn().transform(VectorNode::scalar2vector(cnt, num_elem, type_bt));
> 1598:     } else {

Why conversion for only T_LONG and not for T_BYTE and T_SHORT? Is there an assumption here that only T_INT and T_LONG elem_bt are supported?

src/hotspot/share/opto/vectornode.cpp line 1199:

> 1197:                                              (Node*)(phase->intcon(shift_mask + 1));
> 1198:     Node* vector_mask = phase->transform(VectorNode::scalar2vector(shift_mask_node,vlen, elem_ty));
> 1199:     int subVopc = VectorNode::opcode((bt == T_LONG) ? Op_SubL : Op_SubI, bt);

There seems to be an assumption here that the vector type is INT or LONG only and not subword type. From Vector API you can get the sub word types as well.
Also if this path is coming from auto-vectorizer, don't we need masking here?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3720

From jbhateja at openjdk.java.net  Tue Jul 27 06:48:34 2021
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Tue, 27 Jul 2021 06:48:34 GMT
Subject: RFR: 8266054: VectorAPI rotate operation optimization [v13]
In-Reply-To: <aqV8l0nNTwpat7s4IuOqdXpywz8gT_-QUrpUpBrv5lo=.7d07f269-2996-4e5f-9c6d-a04ae657330a@github.com>
References: <OZ2u4DDNaYF3WiR5uU6NWvzPMKV3j8QAO_mZyLP3Isg=.594e3514-8a5a-442c-ac1a-ca6c6d14e963@github.com>
 <HU2E5YuCI7Iz38CNycxu62RVNsyyT9unlr79-fSwFVg=.fde03b0d-6f8f-445f-88e4-84511f50226b@github.com>
 <aqV8l0nNTwpat7s4IuOqdXpywz8gT_-QUrpUpBrv5lo=.7d07f269-2996-4e5f-9c6d-a04ae657330a@github.com>
Message-ID: <eBO3UJTSXSQeUl0CJ8U7s_0r9eXlBdeoXi1OicYPwNc=.f1fc41a4-b457-4c83-acb1-3cbaa4de467e@github.com>

On Tue, 27 Jul 2021 01:54:01 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits:
>> 
>>  - 8266054: Re-designing benchmark to remove noise.
>>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8266054
>>  - 8266054: Formal argument name change to be more appropriate.
>>  - 8266054: Review comments resolution.
>>  - 8266054: Incorporating styling changes based on reviews.
>>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8266054
>>  - Merge http://github.com/openjdk/jdk into JDK-8266054
>>  - Merge http://github.com/openjdk/jdk into JDK-8266054
>>  - Merge http://github.com/openjdk/jdk into JDK-8266054
>>  - Merge branch 'JDK-8266054' of http://github.com/jatin-bhateja/jdk into JDK-8266054
>>  - ... and 9 more: https://git.openjdk.java.net/jdk/compare/a8f15427...b20404e2
>
> src/hotspot/share/opto/vectornode.cpp line 1199:
> 
>> 1197:                                              (Node*)(phase->intcon(shift_mask + 1));
>> 1198:     Node* vector_mask = phase->transform(VectorNode::scalar2vector(shift_mask_node,vlen, elem_ty));
>> 1199:     int subVopc = VectorNode::opcode((bt == T_LONG) ? Op_SubL : Op_SubI, bt);
> 
> There seems to be an assumption here that the vector type is INT or LONG only and not subword type. From Vector API you can get the sub word types as well.
> Also if this path is coming from auto-vectorizer, don't we need masking here?

Subtype is being passed to VectorNode::opcode for correct opcode selection. Also shift_mask_node is a constant value node, so there is no assumption on vector type. Wrap around (masking) for shift value may not be needed here since we are degenerating rotate into shifts (logical left and rights).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3720

From jbhateja at openjdk.java.net  Tue Jul 27 07:05:32 2021
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Tue, 27 Jul 2021 07:05:32 GMT
Subject: RFR: 8266054: VectorAPI rotate operation optimization [v10]
In-Reply-To: <T6m3nWtDYJuvtu63cTKRAAK0hqoDwJFlTSWDMl1xeM4=.1876e923-6f7b-425d-893f-c58c8b766343@github.com>
References: <OZ2u4DDNaYF3WiR5uU6NWvzPMKV3j8QAO_mZyLP3Isg=.594e3514-8a5a-442c-ac1a-ca6c6d14e963@github.com>
 <j-MimQL3RfOga-_XaS0UWHPsmDp99CyUer8f_bFptmo=.231d4cc0-e9ee-47d8-ad6c-41adcf114367@github.com>
 <mF_TPuiSWMhsH4OoVgvPDJ2VcSP8MGhj1mL7ACIyoQg=.e9e159d5-90ec-470a-84b9-167c36ce6c7f@github.com>
 <57RjIAXAeh_OL4TKIusvf_Zzcdy8sojU874yc1lH2yY=.3acc983b-9152-404c-a67a-d484fe41c15b@github.com>
 <OwhhLDoNCALTI4sXL6P_4iVtX-M6psAL2IoyTP8RwS8=.98105420-c710-4aa1-8a45-bed07608776b@github.com>
 <HvAMP5HzhzUGb1L_zSDdGL00POSydoS1zT29E4LeO_Q=.1649b2d4-308d-40ea-b43e-c0dcd56c11b5@github.com>
 <T6m3nWtDYJuvtu63cTKRAAK0hqoDwJFlTSWDMl1xeM4=.1876e923-6f7b-425d-893f-c58c8b766343@github.com>
Message-ID: <wEeiPrfokgN8fNJs9HwEfeRiiQNexWKis5JCJ0sfoyM=.066e54f1-b00c-47ef-aaf7-d2018eba48c8@github.com>

On Tue, 27 Jul 2021 02:52:13 GMT, Eric Liu <eliu at openjdk.org> wrote:

>> @sviswa7, SLP flow will either have a constant 8bit shift value or a variable shift present in vector, this also include broadcasted non-constant shift value or a shift value beyond 8 bit.
>
> It would be better comment here, since the correctness relay on some others.

@theRealELiu , @sviswa7 , comment already exist in code,  I guess I mentioned incorrectly earlier on this thread, rectified my comments.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3720

From jbhateja at openjdk.java.net  Tue Jul 27 08:20:35 2021
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Tue, 27 Jul 2021 08:20:35 GMT
Subject: RFR: 8266054: VectorAPI rotate operation optimization [v13]
In-Reply-To: <aqV8l0nNTwpat7s4IuOqdXpywz8gT_-QUrpUpBrv5lo=.7d07f269-2996-4e5f-9c6d-a04ae657330a@github.com>
References: <OZ2u4DDNaYF3WiR5uU6NWvzPMKV3j8QAO_mZyLP3Isg=.594e3514-8a5a-442c-ac1a-ca6c6d14e963@github.com>
 <HU2E5YuCI7Iz38CNycxu62RVNsyyT9unlr79-fSwFVg=.fde03b0d-6f8f-445f-88e4-84511f50226b@github.com>
 <aqV8l0nNTwpat7s4IuOqdXpywz8gT_-QUrpUpBrv5lo=.7d07f269-2996-4e5f-9c6d-a04ae657330a@github.com>
Message-ID: <QVp3oWII9zaC5NbrEqb65qNSqlRtx65_88a1NcX3s9Q=.003c3ed8-b0b5-49d3-9b55-8ab96c3c68cc@github.com>

On Tue, 27 Jul 2021 00:24:52 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits:
>> 
>>  - 8266054: Re-designing benchmark to remove noise.
>>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8266054
>>  - 8266054: Formal argument name change to be more appropriate.
>>  - 8266054: Review comments resolution.
>>  - 8266054: Incorporating styling changes based on reviews.
>>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8266054
>>  - Merge http://github.com/openjdk/jdk into JDK-8266054
>>  - Merge http://github.com/openjdk/jdk into JDK-8266054
>>  - Merge http://github.com/openjdk/jdk into JDK-8266054
>>  - Merge branch 'JDK-8266054' of http://github.com/jatin-bhateja/jdk into JDK-8266054
>>  - ... and 9 more: https://git.openjdk.java.net/jdk/compare/a8f15427...b20404e2
>
> src/hotspot/share/opto/vectorIntrinsics.cpp line 1598:
> 
>> 1596:       cnt = elem_bt == T_LONG ? gvn().transform(new ConvI2LNode(cnt)) : cnt;
>> 1597:       opd2 = gvn().transform(VectorNode::scalar2vector(cnt, num_elem, type_bt));
>> 1598:     } else {
> 
> Why conversion for only T_LONG and not for T_BYTE and T_SHORT? Is there an assumption here that only T_INT and T_LONG elem_bt are supported?

Correcting this,  I2L may be needed in auto-vectorization flow since Integer/Long.rotate[Right/Left] APIs accept only integral shift, so for Long.rotate* operations integral shift value must be converted to long using I2L before broadcasting it. VectorAPI lanewise operations between vector-scalar, scalar type already matches with vector type.  Since degeneration routine is common b/w both the flows so maintaining IR consistency here.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3720

From mbaesken at openjdk.java.net  Tue Jul 27 10:28:30 2021
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Tue, 27 Jul 2021 10:28:30 GMT
Subject: RFR: JDK-8266490: Extend the OSContainer API to support the pids
 controller of cgroups [v6]
In-Reply-To: <_CXJ5Lcpd7-PqzRzGAtEE4NyZzAGirYGSgVT7KbPyFw=.f2ce7164-7d28-4b6e-9a79-9417054e0113@github.com>
References: <MWenVRe4ptn5aua0DUHvxb-sdbu-Ykl9x0GlhmxKHhY=.1fb8901e-36c3-4c07-a6ed-b653120807de@github.com>
 <g4NiARIHx5BTgvq6uoi9LqqcJRkJT2NiK_-qMrrv-H0=.bbbf85f5-8da9-467a-b5e0-b47bc8b73172@github.com>
 <80NDhQE20WOO7LMCDS9C9zYQIRy-YKqNiGgrPQAPI64=.ef6e55d9-8995-4669-9c6f-e10a61bd427f@github.com>
 <wGe0vflu7uZ8O0WsAz2OdkpjtiyXLkafQF-w5x3n1gU=.57343745-db2f-42b9-b1cb-2694a741c7f6@github.com>
 <b3tc72GBp_aSCngNXWbJFncPyTJT3mF-NoSYPqAGGlw=.bf5d98c7-62e9-46f0-bbc4-6aeb86b77a3d@github.com>
 <v5HmhFytrDnyrexCubsJSA0AxT5_FfrWD2yoN_2uRlQ=.a13c4127-46d4-4a94-aeca-31a99549a2bf@github.com>
 <_CXJ5Lcpd7-PqzRzGAtEE4NyZzAGirYGSgVT7KbPyFw=.f2ce7164-7d28-4b6e-9a79-9417054e0113@github.com>
Message-ID: <Cuddlk-XPnwxcvd6Y0kZs9jKh6IocZih1gA9njsDFD4=.7c6f04f1-fe9a-42cb-acae-489b76b712b4@github.com>

On Fri, 23 Jul 2021 12:32:04 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> > Could this be some setting configured on your box that is picked up as an additional limit ?
> 
> Possibly. Not sure where to look, though.

I ask some local experts about that issue.
What do you think about accepting, when setting -1/unlimited,   a high  limit number like 20.000+  as well (and and a comment that on some setups unlimited means just "high number"  but not unlimited?
Another Idea I had was to start a little test java program that creates e.g.  50.000 (or another high number) of threads. If this fails with "unilimited"  pids-limit set, we might have a setup like yours and then skip the test (or accept a high number like I suggested).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4518

From stuefe at openjdk.java.net  Tue Jul 27 14:17:34 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Tue, 27 Jul 2021 14:17:34 GMT
Subject: RFR: JDK-8256844: Make NMT late-initializable
In-Reply-To: <c4d84f41-ffb9-d327-9ec9-e9f9c61b8367@oracle.com>
References: <Ze_dKp-5-dse_657jTXTD4kbHSBeOQcLvqeluE0DXjI=.9214cb10-f1f1-48cb-8d96-12621a51a904@github.com>
 <c4d84f41-ffb9-d327-9ec9-e9f9c61b8367@oracle.com>
Message-ID: <gg2GKwMJOe-o1ZEXDvZ-ozQIEXgkBG47B8tqRBbl2C8=.53cc7973-ecec-43f0-bc21-cf3e5236852e@github.com>

On Mon, 26 Jul 2021 21:08:04 GMT, David Holmes <david.holmes at oracle.com> wrote:

> Before looking at this, have you checked the startup performance impact?
> 
> Thanks,
> David
> -----

Hi David,

performance should not be a problem. The potentially costly thing is the underlying hashmap. But we keep it operating with a very small load factor.

More details:

Adding entries is O(1). Since during pre-init phase almost only adds happen, startup time is not affected. Still, to make sure this is true, I did a bunch of tests:

- tested WCT of a helloworld, no differences with and without patch
- tested startup time in various of ways, no differences
- repeated those tests with 25000 (!) VM arguments, the only way to influence the number of pre-init allocations. No differences (VM gets slower with and without patch).

----

The expensive thing is lookup since we potentially need to walk a very full hashmap. Lookup affects post-init more than pre-init.

To get an idea of the cost of a too-full preinit lookup table, I modified the VM to do a configurable number of pre-init test-allocations, with the intent of artificially inflating the lookup table. Then, after NMT initialization, I measured the cost of lookup. The short story, I was not able to measure anything, even with a million pre-init allocations. Of course, with more allocations lookup table got fuller and the VM got slower, but the time increase was caused by the cost of the malloc calls themselves, not the table lookup.

Finally, I did an isolated test for the lookup table, testing pure adding and retrieval cost with artificial values. There, I could see costs for add were static (as expected), and lookup cost increased with table population. On my machine:

| lu table entries            | time per lookup |
| ------ |:-------------:|
| 1000    | 3 ns         | 
| 1 mio   | 240 ns       | 

As you can see, if lookup table population goes beyond 1 mio entries, lookup time starts being noticeable over background noise. But with these numbers, I am not worried. Standard lookup population should be around *300-500*, with very long command lines resulting in table populations of *~1000*. We should never seen 10000 entries, let alone millions of them.

Still, I added a jtreg test to verify the expected hash table population. To catch errors like an unforeseen mass of pre-init allocations (lets say a leak or badly written code sneaked in), or if the hash algorithm suddenly is not good anymore.

Two more points

1) I kept this coding deliberately simple. If we are really worried about a degenerated lookup table, we can do things to fix that:
 - we could automatically resize and rehash
 - we could, if we sense something wrong, just stop filling it and disable NMT, stopping NMT init phase prematurely at the cost of not being able to use NMT. 
 
The latter I had implemented already but removed it again to keep complexity down, and because I saw no need.

2) In our propietary production VM we have a system similar to NMT, but predating it. In that system we don't use malloc headers but store all (millions of) malloc'ed pointers in a big hash map. It performs excellent on *all our libc variants*. It is so fast that we just leave it always switched on. This solution has been productive since >10 years, and therefore I am confident that this is viable. This proposed hashmap with a planned population of 300-1000 is really not much :)

-------------

PR: https://git.openjdk.java.net/jdk/pull/4874

From mgronlun at openjdk.java.net  Tue Jul 27 14:44:16 2021
From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 27 Jul 2021 14:44:16 GMT
Subject: RFR: 8266936: Add a finalization JFR event [v2]
In-Reply-To: <PpWS13N5Xk6jE-2GGuVjVbd9KgG11x85fFDHww7fMeA=.cbfa8c67-2ead-4db5-ade3-f2bc45565b11@github.com>
References: <PpWS13N5Xk6jE-2GGuVjVbd9KgG11x85fFDHww7fMeA=.cbfa8c67-2ead-4db5-ade3-f2bc45565b11@github.com>
Message-ID: <xBZV_ep7AWGWe11jxoPFI-6Fxaqhl49q6IDtWKYty40=.affde9da-ac61-4504-a0df-5fe2a537c588@github.com>

> Greetings,
> 
> Object.finalize() was deprecated in JDK9. There is an ongoing effort to replace and mitigate Object.finalize() uses in the JDK libraries; please see https://bugs.openjdk.java.net/browse/JDK-8253568 for more information. 
> 
> We also like to assist users in replacing and mitigating uses in non-JDK code.
> 
> Hence, this changeset adds a periodic JFR event to help identify which classes are overriding Object.finalize().
> 
> Thanks
> Markus

Markus Gr?nlund has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 16 additional commits since the last revision:

 - merge
 - whitespace
 - update
 - update
 - whitespace
 - 8266936-alt: Add a finalization JFR event
 - shortcut calling Jfr::is_recording()
 - 8266936: Add a finalization JFR event
 - Code Source attribute for Finalizer event
 - whitespace
 - ... and 6 more: https://git.openjdk.java.net/jdk/compare/021c6513...d4d154e8

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4731/files
  - new: https://git.openjdk.java.net/jdk/pull/4731/files/9a966f9f..d4d154e8

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4731&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4731&range=00-01

  Stats: 10639 lines in 412 files changed: 6366 ins; 2700 del; 1573 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4731.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4731/head:pull/4731

PR: https://git.openjdk.java.net/jdk/pull/4731

From mgronlun at openjdk.java.net  Tue Jul 27 15:04:21 2021
From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 27 Jul 2021 15:04:21 GMT
Subject: RFR: 8266936: Add a finalization JFR event [v3]
In-Reply-To: <PpWS13N5Xk6jE-2GGuVjVbd9KgG11x85fFDHww7fMeA=.cbfa8c67-2ead-4db5-ade3-f2bc45565b11@github.com>
References: <PpWS13N5Xk6jE-2GGuVjVbd9KgG11x85fFDHww7fMeA=.cbfa8c67-2ead-4db5-ade3-f2bc45565b11@github.com>
Message-ID: <xXtU_Giw_qT1kIDZ0G5RwtHzmti9q5vbic3FKFVc_e0=.88930dd2-f175-458b-b0cb-1ef8c00d2741@github.com>

> Greetings,
> 
> Object.finalize() was deprecated in JDK9. There is an ongoing effort to replace and mitigate Object.finalize() uses in the JDK libraries; please see https://bugs.openjdk.java.net/browse/JDK-8253568 for more information. 
> 
> We also like to assist users in replacing and mitigating uses in non-JDK code.
> 
> Hence, this changeset adds a periodic JFR event to help identify which classes are overriding Object.finalize().
> 
> Thanks
> Markus

Markus Gr?nlund 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.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4731/files
  - new: https://git.openjdk.java.net/jdk/pull/4731/files/d4d154e8..58fc3f0a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4731&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4731&range=01-02

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4731.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4731/head:pull/4731

PR: https://git.openjdk.java.net/jdk/pull/4731

From mgronlun at openjdk.java.net  Tue Jul 27 15:14:29 2021
From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 27 Jul 2021 15:14:29 GMT
Subject: RFR: 8266936: Add a finalization JFR event [v4]
In-Reply-To: <PpWS13N5Xk6jE-2GGuVjVbd9KgG11x85fFDHww7fMeA=.cbfa8c67-2ead-4db5-ade3-f2bc45565b11@github.com>
References: <PpWS13N5Xk6jE-2GGuVjVbd9KgG11x85fFDHww7fMeA=.cbfa8c67-2ead-4db5-ade3-f2bc45565b11@github.com>
Message-ID: <ZhRmSB07Rzd1fay76np0B3hc-V9gy2s2UxZiCfENIMY=.247c6641-6536-409f-bd13-2b662cacbafb@github.com>

> Greetings,
> 
> Object.finalize() was deprecated in JDK9. There is an ongoing effort to replace and mitigate Object.finalize() uses in the JDK libraries; please see https://bugs.openjdk.java.net/browse/JDK-8253568 for more information. 
> 
> We also like to assist users in replacing and mitigating uses in non-JDK code.
> 
> Hence, this changeset adds a periodic JFR event to help identify which classes are overriding Object.finalize().
> 
> Thanks
> Markus

Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:

  remove build directive

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4731/files
  - new: https://git.openjdk.java.net/jdk/pull/4731/files/58fc3f0a..44988036

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4731&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4731&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4731.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4731/head:pull/4731

PR: https://git.openjdk.java.net/jdk/pull/4731

From alanb at openjdk.java.net  Tue Jul 27 15:48:27 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 27 Jul 2021 15:48:27 GMT
Subject: RFR: 8270321: Startup regressions in 18-b5 caused by JDK-8266310
In-Reply-To: <W0x401I1NqmAUe7fn05M-YVVBaP1yD98xoXz0kNw5UM=.a60b4e7d-c7e9-406e-bde4-1341519a439a@github.com>
References: <W0x401I1NqmAUe7fn05M-YVVBaP1yD98xoXz0kNw5UM=.a60b4e7d-c7e9-406e-bde4-1341519a439a@github.com>
Message-ID: <UUio1sCZYY6PtEJOKJuJPEc4IKyqOa4pgelvNmn4L7E=.884393ee-d90f-4ce7-b239-ab31cedfa149@github.com>

On Fri, 23 Jul 2021 18:03:31 GMT, Sergey Chernyshev <github.com+6394632+sercher at openjdk.org> wrote:

> Dear colleagues,
> 
> Please review the patch that replaces the lambdas with anonymous classes which solves the startup time regression as shown below.
> 
> I attached the Bytestacks flamegraphs for both original (regression) and fixed versions. The flamegraphs clearly show the lambdas were causing the performance issue.
> 
> [bytestacks_flamegraphs.zip](https://github.com/openjdk/jdk/files/6870446/bytestacks_flamegraphs.zip)
> 
> Although the proposed JDK-8270321 patch fixes the startup time (it might appear even better than it was before the regression was introduced, i.e. before JDK-8266310) and generally fixes the footprint regression, it may increase MaxRSS slightly compared to the version before JDK-8266310, which is shown in the below graphs. (updated)
> 
> ![StartupTime2](https://user-images.githubusercontent.com/6394632/126898224-a05fda62-f723-4f2c-9af9-e02cbfe1c9c8.png)
> 
> ![MaxRSS](https://user-images.githubusercontent.com/6394632/126822404-899ab904-efc1-4377-9e0d-d8cdb5c0e5d0.png)
> 
> (update: added ZGC graphs)
> 
> ![StartupTime_ZGC](https://user-images.githubusercontent.com/6394632/126898242-52c09582-c2a4-4623-aad2-f47055277193.png)
> 
> ![MaxRSS_ZGC](https://user-images.githubusercontent.com/6394632/126898244-31c3eeb5-a768-4a52-8960-960cc4a72d7b.png)
> 
> I additionally include the heap objects histograms to show the change does not increase the total live objects size significantly with only 1000 bytes the total difference, namely 1116128 bytes in 25002 live objects after the proposed fix JDK-8270321 compared to 1115128 bytes in 24990 objects in the version with the original patch reverted (i.e. before JDK-8266310).
> 
> [histograms.zip](https://github.com/openjdk/jdk/files/6870457/histograms.zip)
> 
> The patch was tested w/hotspot/tier1/tier2 test groups.

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4893

From alanb at openjdk.java.net  Tue Jul 27 15:55:30 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 27 Jul 2021 15:55:30 GMT
Subject: RFR: 4890732: GZIPOutputStream doesn't support optional GZIP
 fields [v9]
In-Reply-To: <V8-ktRi7BSd6chf4XnYiFDEHnhRGEtwQxKv5NN6Wd5I=.25c9045a-dce1-4fc7-906e-44e46022242c@github.com>
References: <DKXYUELjj1BRxIwULHr8Ocm0DY4I6ngRFJ7eog1Miew=.c080fccf-a2b0-46cc-9e4a-306c226cce3c@github.com>
 <j7YPtBR8ylz-kuKwNVPgR8v2Tj2bAU7DE7UNr7G7mO4=.ef19d436-f320-460e-9c0d-6610ec7db5f6@github.com>
 <V8-ktRi7BSd6chf4XnYiFDEHnhRGEtwQxKv5NN6Wd5I=.25c9045a-dce1-4fc7-906e-44e46022242c@github.com>
Message-ID: <hhVaZD7vDwymaqOkrPZURF5wvHsTjxq-8n6eaYYTBxc=.5d4c8c03-e0ce-4e32-b059-2ca137598ca6@github.com>

On Mon, 26 Jul 2021 21:07:59 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> I have not gone through the latest update in detail but there are some changes that are needed. Before moving forward with the CSR, I would like to give time for additional feedback on naming and design.

This proposal will need a few iterations to get to the right API. There are several issues with the proposed GZIPHeaderBuilder, also GZIPHeaderData is mutable (having byte[] as elements in a record is a hazard). I will try to make time in the coming weeks to help.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3072

From sviswanathan at openjdk.java.net  Tue Jul 27 18:08:35 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Tue, 27 Jul 2021 18:08:35 GMT
Subject: RFR: 8266054: VectorAPI rotate operation optimization [v13]
In-Reply-To: <QVp3oWII9zaC5NbrEqb65qNSqlRtx65_88a1NcX3s9Q=.003c3ed8-b0b5-49d3-9b55-8ab96c3c68cc@github.com>
References: <OZ2u4DDNaYF3WiR5uU6NWvzPMKV3j8QAO_mZyLP3Isg=.594e3514-8a5a-442c-ac1a-ca6c6d14e963@github.com>
 <HU2E5YuCI7Iz38CNycxu62RVNsyyT9unlr79-fSwFVg=.fde03b0d-6f8f-445f-88e4-84511f50226b@github.com>
 <aqV8l0nNTwpat7s4IuOqdXpywz8gT_-QUrpUpBrv5lo=.7d07f269-2996-4e5f-9c6d-a04ae657330a@github.com>
 <QVp3oWII9zaC5NbrEqb65qNSqlRtx65_88a1NcX3s9Q=.003c3ed8-b0b5-49d3-9b55-8ab96c3c68cc@github.com>
Message-ID: <UKMmKGpV5PtfcpkWUrJDlkoWuRv6sfiYmBEMdubplE8=.f582f1ea-c2ef-49ee-930d-ba334e99d858@github.com>

On Tue, 27 Jul 2021 08:17:55 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> src/hotspot/share/opto/vectorIntrinsics.cpp line 1598:
>> 
>>> 1596:       cnt = elem_bt == T_LONG ? gvn().transform(new ConvI2LNode(cnt)) : cnt;
>>> 1597:       opd2 = gvn().transform(VectorNode::scalar2vector(cnt, num_elem, type_bt));
>>> 1598:     } else {
>> 
>> Why conversion for only T_LONG and not for T_BYTE and T_SHORT? Is there an assumption here that only T_INT and T_LONG elem_bt are supported?
>
> Correcting this,  I2L may be needed in auto-vectorization flow since Integer/Long.rotate[Right/Left] APIs accept only integral shift, so for Long.rotate* operations integral shift value must be converted to long using I2L before broadcasting it. VectorAPI lanewise operations between vector-scalar, scalar type already matches with vector basic type.  Since degeneration routine is common b/w both the flows so maintaining IR consistency here.

For Vector API the shift is always coming in as int type for rotate by scalar (lanewiseShiftTemplate). The down conversion to byte or short needs to be done before scalar2vector.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3720

From ecki at zusammenkunft.net  Tue Jul 27 18:18:21 2021
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Tue, 27 Jul 2021 18:18:21 +0000
Subject: RFR: 8266936: Add a finalization JFR event [v4]
In-Reply-To: <ZhRmSB07Rzd1fay76np0B3hc-V9gy2s2UxZiCfENIMY=.247c6641-6536-409f-bd13-2b662cacbafb@github.com>
References: <PpWS13N5Xk6jE-2GGuVjVbd9KgG11x85fFDHww7fMeA=.cbfa8c67-2ead-4db5-ade3-f2bc45565b11@github.com>,
 <ZhRmSB07Rzd1fay76np0B3hc-V9gy2s2UxZiCfENIMY=.247c6641-6536-409f-bd13-2b662cacbafb@github.com>
Message-ID: <AM0PR03MB4145FF483A491837E4F7A419FFE99@AM0PR03MB4145.eurprd03.prod.outlook.com>

Hello,

I know I am a bit late, but just wanted to mention, that since finding finalizers with Bytecode analysis is doable (and probably easier to deal with such scan reports), I don?t see much value in a JFR event, especially considering it even has native code executed. (Not so sure about dynamically loaded classes, would the event content help to identify sources?)

Having said that, this event would be more useful from a runtime perspective if It would actually record execution counts and time per class. Then one can concentrate on the worst offenders, first and even use it for runtime monitoring. Is there already a finalizer profiler?

Gruss
Bernd
--
http://bernd.eckenfels.net
________________________________
Von: core-libs-dev <core-libs-dev-retn at openjdk.java.net> im Auftrag von Markus Gr?nlund <mgronlun at openjdk.java.net>
Gesendet: Tuesday, July 27, 2021 5:14:29 PM
An: core-libs-dev at openjdk.java.net <core-libs-dev at openjdk.java.net>; hotspot-jfr-dev at openjdk.java.net <hotspot-jfr-dev at openjdk.java.net>
Betreff: Re: RFR: 8266936: Add a finalization JFR event [v4]

> Greetings,
>
> Object.finalize() was deprecated in JDK9. There is an ongoing effort to replace and mitigate Object.finalize() uses in the JDK libraries; please see https://bugs.openjdk.java.net/browse/JDK-8253568 for more information.
>
> We also like to assist users in replacing and mitigating uses in non-JDK code.
>
> Hence, this changeset adds a periodic JFR event to help identify which classes are overriding Object.finalize().
>
> Thanks
> Markus

Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:

  remove build directive

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4731/files
  - new: https://git.openjdk.java.net/jdk/pull/4731/files/58fc3f0a..44988036

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4731&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4731&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4731.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4731/head:pull/4731

PR: https://git.openjdk.java.net/jdk/pull/4731

From sviswanathan at openjdk.java.net  Tue Jul 27 18:34:43 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Tue, 27 Jul 2021 18:34:43 GMT
Subject: RFR: 8266054: VectorAPI rotate operation optimization [v13]
In-Reply-To: <UKMmKGpV5PtfcpkWUrJDlkoWuRv6sfiYmBEMdubplE8=.f582f1ea-c2ef-49ee-930d-ba334e99d858@github.com>
References: <OZ2u4DDNaYF3WiR5uU6NWvzPMKV3j8QAO_mZyLP3Isg=.594e3514-8a5a-442c-ac1a-ca6c6d14e963@github.com>
 <HU2E5YuCI7Iz38CNycxu62RVNsyyT9unlr79-fSwFVg=.fde03b0d-6f8f-445f-88e4-84511f50226b@github.com>
 <aqV8l0nNTwpat7s4IuOqdXpywz8gT_-QUrpUpBrv5lo=.7d07f269-2996-4e5f-9c6d-a04ae657330a@github.com>
 <QVp3oWII9zaC5NbrEqb65qNSqlRtx65_88a1NcX3s9Q=.003c3ed8-b0b5-49d3-9b55-8ab96c3c68cc@github.com>
 <UKMmKGpV5PtfcpkWUrJDlkoWuRv6sfiYmBEMdubplE8=.f582f1ea-c2ef-49ee-930d-ba334e99d858@github.com>
Message-ID: <kcpEtsrpwgD1JP4ZK3tQVsGYBTSoBxiTcbaf1lhRNYY=.20436acd-22e1-41da-80e3-207f3db15c8a@github.com>

On Tue, 27 Jul 2021 18:05:49 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Correcting this,  I2L may be needed in auto-vectorization flow since Integer/Long.rotate[Right/Left] APIs accept only integral shift, so for Long.rotate* operations integral shift value must be converted to long using I2L before broadcasting it. VectorAPI lanewise operations between vector-scalar, scalar type already matches with vector basic type.  Since degeneration routine is common b/w both the flows so maintaining IR consistency here.
>
> For Vector API the shift is always coming in as int type for rotate by scalar (lanewiseShiftTemplate). The down conversion to byte or short needs to be done before scalar2vector.

I see that similar thing is done before for shift, so down conversion to sub type is not required.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3720

From sviswanathan at openjdk.java.net  Tue Jul 27 18:34:43 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Tue, 27 Jul 2021 18:34:43 GMT
Subject: RFR: 8266054: VectorAPI rotate operation optimization [v13]
In-Reply-To: <HU2E5YuCI7Iz38CNycxu62RVNsyyT9unlr79-fSwFVg=.fde03b0d-6f8f-445f-88e4-84511f50226b@github.com>
References: <OZ2u4DDNaYF3WiR5uU6NWvzPMKV3j8QAO_mZyLP3Isg=.594e3514-8a5a-442c-ac1a-ca6c6d14e963@github.com>
 <HU2E5YuCI7Iz38CNycxu62RVNsyyT9unlr79-fSwFVg=.fde03b0d-6f8f-445f-88e4-84511f50226b@github.com>
Message-ID: <FQQA8lfkU4CkF4wZ1PczK-ZqtZn1v5BkKqTVIPveCf0=.ac405b11-ea1e-4b98-9b07-c626fc3ad2cf@github.com>

On Tue, 20 Jul 2021 09:57:07 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Current VectorAPI Java side implementation expresses rotateLeft and rotateRight operation using following operations:-
>> 
>>     vec1 = lanewise(VectorOperators.LSHL, n)
>>     vec2 = lanewise(VectorOperators.LSHR, n)
>>     res = lanewise(VectorOperations.OR, vec1 , vec2)
>> 
>> This patch moves above handling from Java side to C2 compiler which facilitates dismantling the rotate operation if target ISA does not support a direct rotate instruction.
>> 
>> AVX512 added vector rotate instructions vpro[rl][v][dq] which operate over long and integer type vectors. For other cases (i.e. sub-word type vectors or for targets which do not support direct rotate operations )   instruction sequence comprising of vector SHIFT (LEFT/RIGHT) and vector OR is emitted.
>> 
>> Please find below the performance data for included JMH benchmark.
>> Machine:  Cascade Lake Server (Intel(R) Xeon(R) Platinum 8280 CPU @ 2.70GHz)
>> 
>> 
>> <html xmlns:v="urn:schemas-microsoft-com:vml"
>> xmlns:o="urn:schemas-microsoft-com:office:office"
>> xmlns:x="urn:schemas-microsoft-com:office:excel"
>> xmlns="http://www.w3.org/TR/REC-html40">
>> 
>> <head>
>> 
>> <meta name=ProgId content=Excel.Sheet>
>> <meta name=Generator content="Microsoft Excel 15">
>> <link id=Main-File rel=Main-File
>> href="file:///C:/Users/jatinbha/AppData/Local/Temp/msohtmlclip1/01/clip.htm">
>> <link rel=File-List
>> href="file:///C:/Users/jatinbha/AppData/Local/Temp/msohtmlclip1/01/clip_filelist.xml">
>> <style>
>> 
>> </style>
>> </head>
>> 
>> <body link="#0563C1" vlink="#954F72">
>> 
>> 
>> 
>> Benchmark | (bits) | (shift) | (size) | Baseline Score (ops/ms) | With Opts (ops/ms) | Gain
>> -- | -- | -- | -- | -- | -- | --
>> RotateBenchmark.testRotateLeftB | 128 | 7 | 256 | 3939.136 | 3836.133 | 0.973851372
>> RotateBenchmark.testRotateLeftB | 128 | 7 | 512 | 1984.231 | 1918.27 | 0.966757399
>> RotateBenchmark.testRotateLeftB | 128 | 15 | 256 | 3925.165 | 4043.842 | 1.030234907
>> RotateBenchmark.testRotateLeftB | 128 | 15 | 512 | 1962.723 | 1936.551 | 0.986665464
>> RotateBenchmark.testRotateLeftB | 128 | 31 | 256 | 3945.6 | 3817.883 | 0.967630525
>> RotateBenchmark.testRotateLeftB | 128 | 31 | 512 | 1944.458 | 1914.229 | 0.984453766
>> RotateBenchmark.testRotateLeftB | 256 | 7 | 256 | 4612.149 | 4514.874 | 0.978908964
>> RotateBenchmark.testRotateLeftB | 256 | 7 | 512 | 2296.252 | 2270.237 | 0.988670669
>> RotateBenchmark.testRotateLeftB | 256 | 15 | 256 | 4576.628 | 4515.53 | 0.986649996
>> RotateBenchmark.testRotateLeftB | 256 | 15 | 512 | 2288.278 | 2270.923 | 0.992415694
>> RotateBenchmark.testRotateLeftB | 256 | 31 | 256 | 4624.243 | 4511.46 | 0.975610495
>> RotateBenchmark.testRotateLeftB | 256 | 31 | 512 | 2305.459 | 2273.788 | 0.986262605
>> RotateBenchmark.testRotateLeftB | 512 | 7 | 256 | 7748.283 | 7777.105 | 1.003719792
>> RotateBenchmark.testRotateLeftB | 512 | 7 | 512 | 3906.214 | 3912.647 | 1.001646863
>> RotateBenchmark.testRotateLeftB | 512 | 15 | 256 | 7764.653 | 7763.482 | 0.999849188
>> RotateBenchmark.testRotateLeftB | 512 | 15 | 512 | 3916.061 | 3919.363 | 1.000843194
>> RotateBenchmark.testRotateLeftB | 512 | 31 | 256 | 7779.754 | 7770.239 | 0.998776954
>> RotateBenchmark.testRotateLeftB | 512 | 31 | 512 | 3916.471 | 3912.718 | 0.999041739
>> RotateBenchmark.testRotateLeftI | 128 | 7 | 256 | 4043.39 | 13461.814 | 3.329338501
>> RotateBenchmark.testRotateLeftI | 128 | 7 | 512 | 1996.217 | 6455.425 | 3.233829288
>> RotateBenchmark.testRotateLeftI | 128 | 15 | 256 | 4028.614 | 13077.277 | 3.246098286
>> RotateBenchmark.testRotateLeftI | 128 | 15 | 512 | 1997.612 | 6452.918 | 3.230315997
>> RotateBenchmark.testRotateLeftI | 128 | 31 | 256 | 4123.357 | 13079.045 | 3.171940969
>> RotateBenchmark.testRotateLeftI | 128 | 31 | 512 | 2003.356 | 6452.716 | 3.22095324
>> RotateBenchmark.testRotateLeftI | 256 | 7 | 256 | 7666.949 | 25658.625 | 3.34665393
>> RotateBenchmark.testRotateLeftI | 256 | 7 | 512 | 3855.826 | 12278.106 | 3.18429981
>> RotateBenchmark.testRotateLeftI | 256 | 15 | 256 | 7670.901 | 24625.466 | 3.210244272
>> RotateBenchmark.testRotateLeftI | 256 | 15 | 512 | 3765.786 | 12272.771 | 3.259019764
>> RotateBenchmark.testRotateLeftI | 256 | 31 | 256 | 7660.599 | 25678.864 | 3.352069988
>> RotateBenchmark.testRotateLeftI | 256 | 31 | 512 | 3773.401 | 12006.469 | 3.181869353
>> RotateBenchmark.testRotateLeftI | 512 | 7 | 256 | 11900.948 | 31242.989 | 2.625252123
>> RotateBenchmark.testRotateLeftI | 512 | 7 | 512 | 5830.878 | 15727.149 | 2.697217983
>> RotateBenchmark.testRotateLeftI | 512 | 15 | 256 | 12171.847 | 33180.067 | 2.72596813
>> RotateBenchmark.testRotateLeftI | 512 | 15 | 512 | 5830.544 | 16740.182 | 2.871118372
>> RotateBenchmark.testRotateLeftI | 512 | 31 | 256 | 11909.553 | 31250.882 | 2.624018047
>> RotateBenchmark.testRotateLeftI | 512 | 31 | 512 | 5846.747 | 15738.831 | 2.691895339
>> RotateBenchmark.testRotateLeftL | 128 | 7 | 256 | 2047.243 | 6888.484 | 3.364761291
>> RotateBenchmark.testRotateLeftL | 128 | 7 | 512 | 1005.029 | 3245.931 | 3.229688895
>> RotateBenchmark.testRotateLeftL | 128 | 15 | 256 | 1996.921 | 6985.256 | 3.498013191
>> RotateBenchmark.testRotateLeftL | 128 | 15 | 512 | 986.906 | 3217.778 | 3.260470602
>> RotateBenchmark.testRotateLeftL | 128 | 31 | 256 | 1999.06 | 6977.672 | 3.490476524
>> RotateBenchmark.testRotateLeftL | 128 | 31 | 512 | 987.258 | 3236.63 | 3.278403416
>> RotateBenchmark.testRotateLeftL | 256 | 7 | 256 | 3752.412 | 12995.954 | 3.4633601
>> RotateBenchmark.testRotateLeftL | 256 | 7 | 512 | 1824.093 | 5809.576 | 3.184912173
>> RotateBenchmark.testRotateLeftL | 256 | 15 | 256 | 3759.99 | 13262.631 | 3.52730486
>> RotateBenchmark.testRotateLeftL | 256 | 15 | 512 | 1823.393 | 5803.872 | 3.183006626
>> RotateBenchmark.testRotateLeftL | 256 | 31 | 256 | 3757.134 | 13284.633 | 3.535842214
>> RotateBenchmark.testRotateLeftL | 256 | 31 | 512 | 1822.192 | 5824.178 | 3.196248255
>> RotateBenchmark.testRotateLeftL | 512 | 7 | 256 | 5794.005 | 15567.753 | 2.686872552
>> RotateBenchmark.testRotateLeftL | 512 | 7 | 512 | 2969.393 | 7694.79 | 2.591368
>> RotateBenchmark.testRotateLeftL | 512 | 15 | 256 | 5817.292 | 15726.597 | 2.703422314
>> RotateBenchmark.testRotateLeftL | 512 | 15 | 512 | 2944.655 | 7664.954 | 2.603005785
>> RotateBenchmark.testRotateLeftL | 512 | 31 | 256 | 5822.131 | 16718.64 | 2.871567129
>> RotateBenchmark.testRotateLeftL | 512 | 31 | 512 | 2944.763 | 7657.814 | 2.600485676
>> RotateBenchmark.testRotateLeftS | 128 | 7 | 256 | 8006.155 | 7976.701 | 0.99632108
>> RotateBenchmark.testRotateLeftS | 128 | 7 | 512 | 4031.753 | 4003.43 | 0.992975016
>> RotateBenchmark.testRotateLeftS | 128 | 15 | 256 | 8003.879 | 7952.752 | 0.993612222
>> RotateBenchmark.testRotateLeftS | 128 | 15 | 512 | 4026.359 | 4014.757 | 0.997118488
>> RotateBenchmark.testRotateLeftS | 128 | 31 | 256 | 8000.842 | 7995.733 | 0.999361442
>> RotateBenchmark.testRotateLeftS | 128 | 31 | 512 | 4044.421 | 4007.426 | 0.990852832
>> RotateBenchmark.testRotateLeftS | 256 | 7 | 256 | 15078.471 | 15034.395 | 0.997076892
>> RotateBenchmark.testRotateLeftS | 256 | 7 | 512 | 7236.509 | 7620.334 | 1.053040078
>> RotateBenchmark.testRotateLeftS | 256 | 15 | 256 | 15093.661 | 15024.17 | 0.995396014
>> RotateBenchmark.testRotateLeftS | 256 | 15 | 512 | 7308.568 | 7724.381 | 1.056893909
>> RotateBenchmark.testRotateLeftS | 256 | 31 | 256 | 15332.233 | 15432.113 | 1.006514381
>> RotateBenchmark.testRotateLeftS | 256 | 31 | 512 | 7317.18 | 7626.679 | 1.042297579
>> RotateBenchmark.testRotateLeftS | 512 | 7 | 256 | 24079.012 | 23939.263 | 0.994196232
>> RotateBenchmark.testRotateLeftS | 512 | 7 | 512 | 11441.41 | 11921.21 | 1.041935391
>> RotateBenchmark.testRotateLeftS | 512 | 15 | 256 | 23563.675 | 23590.959 | 1.001157884
>> RotateBenchmark.testRotateLeftS | 512 | 15 | 512 | 11418.634 | 11949.391 | 1.046481654
>> RotateBenchmark.testRotateLeftS | 512 | 31 | 256 | 24035.69 | 23595.385 | 0.9816812
>> RotateBenchmark.testRotateLeftS | 512 | 31 | 512 | 11668.091 | 11899.536 | 1.019835721
>> RotateBenchmark.testRotateRightB | 128 | 7 | 256 | 3852.421 | 3816.521 | 0.990681185
>> RotateBenchmark.testRotateRightB | 128 | 7 | 512 | 1956.766 | 1923.638 | 0.983070025
>> RotateBenchmark.testRotateRightB | 128 | 15 | 256 | 3899.136 | 4038.945 | 1.035856405
>> RotateBenchmark.testRotateRightB | 128 | 15 | 512 | 1957.733 | 2030.973 | 1.037410617
>> RotateBenchmark.testRotateRightB | 128 | 31 | 256 | 3902.5 | 4043.736 | 1.03619116
>> RotateBenchmark.testRotateRightB | 128 | 31 | 512 | 1957.728 | 1920.434 | 0.980950367
>> RotateBenchmark.testRotateRightB | 256 | 7 | 256 | 4565.887 | 4515.083 | 0.988873137
>> RotateBenchmark.testRotateRightB | 256 | 7 | 512 | 2300.057 | 2278.065 | 0.990438498
>> RotateBenchmark.testRotateRightB | 256 | 15 | 256 | 4570.754 | 4527.692 | 0.990578797
>> RotateBenchmark.testRotateRightB | 256 | 15 | 512 | 2300.524 | 2268.659 | 0.986148808
>> RotateBenchmark.testRotateRightB | 256 | 31 | 256 | 4577.569 | 4513.29 | 0.98595783
>> RotateBenchmark.testRotateRightB | 256 | 31 | 512 | 2304.335 | 2273.178 | 0.986478962
>> RotateBenchmark.testRotateRightB | 512 | 7 | 256 | 7772.483 | 7842.671 | 1.009030319
>> RotateBenchmark.testRotateRightB | 512 | 7 | 512 | 3907.265 | 3917.325 | 1.002574691
>> RotateBenchmark.testRotateRightB | 512 | 15 | 256 | 7855.653 | 7865.25 | 1.001221668
>> RotateBenchmark.testRotateRightB | 512 | 15 | 512 | 3909.845 | 3976.813 | 1.017128045
>> RotateBenchmark.testRotateRightB | 512 | 31 | 256 | 7746.765 | 7870.159 | 1.015928455
>> RotateBenchmark.testRotateRightB | 512 | 31 | 512 | 3919.596 | 3981.934 | 1.01590419
>> RotateBenchmark.testRotateRightI | 128 | 7 | 256 | 4125.151 | 13056.878 | 3.165187893
>> RotateBenchmark.testRotateRightI | 128 | 7 | 512 | 2045.201 | 6501.447 | 3.17887924
>> RotateBenchmark.testRotateRightI | 128 | 15 | 256 | 4111.736 | 13318.124 | 3.23905134
>> RotateBenchmark.testRotateRightI | 128 | 15 | 512 | 2055.355 | 6497.289 | 3.161151723
>> RotateBenchmark.testRotateRightI | 128 | 31 | 256 | 4109.353 | 13073.3 | 3.181352393
>> RotateBenchmark.testRotateRightI | 128 | 31 | 512 | 2055.431 | 6463.902 | 3.14479153
>> RotateBenchmark.testRotateRightI | 256 | 7 | 256 | 7804.976 | 24585.962 | 3.150036848
>> RotateBenchmark.testRotateRightI | 256 | 7 | 512 | 3815.818 | 11985.145 | 3.140911071
>> RotateBenchmark.testRotateRightI | 256 | 15 | 256 | 7644.977 | 25863.841 | 3.383115606
>> RotateBenchmark.testRotateRightI | 256 | 15 | 512 | 3822.508 | 12280.58 | 3.212702236
>> RotateBenchmark.testRotateRightI | 256 | 31 | 256 | 7709.635 | 25655.108 | 3.327668301
>> RotateBenchmark.testRotateRightI | 256 | 31 | 512 | 3801.5 | 12271.65 | 3.228107326
>> RotateBenchmark.testRotateRightI | 512 | 7 | 256 | 12223.711 | 31239.788 | 2.555671351
>> RotateBenchmark.testRotateRightI | 512 | 7 | 512 | 5973.571 | 16740.852 | 2.802486486
>> RotateBenchmark.testRotateRightI | 512 | 15 | 256 | 12205.47 | 31248.025 | 2.560165647
>> RotateBenchmark.testRotateRightI | 512 | 15 | 512 | 5966.513 | 15728.168 | 2.6360737
>> RotateBenchmark.testRotateRightI | 512 | 31 | 256 | 12209.405 | 33181.105 | 2.71766765
>> RotateBenchmark.testRotateRightI | 512 | 31 | 512 | 5981.527 | 15727.496 | 2.629344647
>> RotateBenchmark.testRotateRightL | 128 | 7 | 256 | 2054.509 | 6980.849 | 3.397818652
>> RotateBenchmark.testRotateRightL | 128 | 7 | 512 | 997.375 | 3242.374 | 3.250907633
>> RotateBenchmark.testRotateRightL | 128 | 15 | 256 | 2051.459 | 6892.389 | 3.359749817
>> RotateBenchmark.testRotateRightL | 128 | 15 | 512 | 1002.906 | 3223.342 | 3.21400211
>> RotateBenchmark.testRotateRightL | 128 | 31 | 256 | 2044.749 | 6984.157 | 3.415654929
>> RotateBenchmark.testRotateRightL | 128 | 31 | 512 | 1004.273 | 3237.496 | 3.22372104
>> RotateBenchmark.testRotateRightL | 256 | 7 | 256 | 3811.551 | 13347.75 | 3.501920872
>> RotateBenchmark.testRotateRightL | 256 | 7 | 512 | 1892.883 | 5840.85 | 3.085689924
>> RotateBenchmark.testRotateRightL | 256 | 15 | 256 | 3821.705 | 14034.823 | 3.672398314
>> RotateBenchmark.testRotateRightL | 256 | 15 | 512 | 1799.193 | 5817.533 | 3.233412424
>> RotateBenchmark.testRotateRightL | 256 | 31 | 256 | 3816.666 | 14022.31 | 3.673968327
>> RotateBenchmark.testRotateRightL | 256 | 31 | 512 | 1796.649 | 5824.13 | 3.241662673
>> RotateBenchmark.testRotateRightL | 512 | 7 | 256 | 5943.986 | 15586.254 | 2.622188881
>> RotateBenchmark.testRotateRightL | 512 | 7 | 512 | 3022.686 | 7662.241 | 2.534911334
>> RotateBenchmark.testRotateRightL | 512 | 15 | 256 | 5958.008 | 15726.859 | 2.639616966
>> RotateBenchmark.testRotateRightL | 512 | 15 | 512 | 2998.469 | 7654.703 | 2.552870482
>> RotateBenchmark.testRotateRightL | 512 | 31 | 256 | 5937.491 | 15741.207 | 2.651154671
>> RotateBenchmark.testRotateRightL | 512 | 31 | 512 | 3014.699 | 7656.837 | 2.539834657
>> RotateBenchmark.testRotateRightS | 128 | 7 | 256 | 8172.896 | 8003.474 | 0.979270261
>> RotateBenchmark.testRotateRightS | 128 | 7 | 512 | 4111.074 | 4047.267 | 0.984479238
>> RotateBenchmark.testRotateRightS | 128 | 15 | 256 | 8225.79 | 8040.421 | 0.9774649
>> RotateBenchmark.testRotateRightS | 128 | 15 | 512 | 4129.801 | 4011.919 | 0.971455767
>> RotateBenchmark.testRotateRightS | 128 | 31 | 256 | 8176.102 | 8052.686 | 0.984905276
>> RotateBenchmark.testRotateRightS | 128 | 31 | 512 | 4117.735 | 4046.522 | 0.982705784
>> RotateBenchmark.testRotateRightS | 256 | 7 | 256 | 15213.617 | 15169.51 | 0.997100821
>> RotateBenchmark.testRotateRightS | 256 | 7 | 512 | 7530.289 | 7625.581 | 1.012654494
>> RotateBenchmark.testRotateRightS | 256 | 15 | 256 | 15238.384 | 15069.978 | 0.988948566
>> RotateBenchmark.testRotateRightS | 256 | 15 | 512 | 7275.098 | 7620.764 | 1.047513587
>> RotateBenchmark.testRotateRightS | 256 | 31 | 256 | 15299.821 | 15043.765 | 0.983264118
>> RotateBenchmark.testRotateRightS | 256 | 31 | 512 | 7273.028 | 7630.97 | 1.04921499
>> RotateBenchmark.testRotateRightS | 512 | 7 | 256 | 23998.152 | 23920.046 | 0.996745333
>> RotateBenchmark.testRotateRightS | 512 | 7 | 512 | 11582.679 | 11916.382 | 1.02881052
>> RotateBenchmark.testRotateRightS | 512 | 15 | 256 | 23982.797 | 23434.756 | 0.977148579
>> RotateBenchmark.testRotateRightS | 512 | 15 | 512 | 11629.806 | 11918.759 | 1.0248459
>> RotateBenchmark.testRotateRightS | 512 | 31 | 256 | 23988.549 | 23475.629 | 0.978618132
>> RotateBenchmark.testRotateRightS | 512 | 31 | 512 | 11650.146 | 11916.47 | 1.022860143
>> 
>> 
>> 
>> </body>
>> 
>> </html>
>
> Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits:
> 
>  - 8266054: Re-designing benchmark to remove noise.
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8266054
>  - 8266054: Formal argument name change to be more appropriate.
>  - 8266054: Review comments resolution.
>  - 8266054: Incorporating styling changes based on reviews.
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8266054
>  - Merge http://github.com/openjdk/jdk into JDK-8266054
>  - Merge http://github.com/openjdk/jdk into JDK-8266054
>  - Merge http://github.com/openjdk/jdk into JDK-8266054
>  - Merge branch 'JDK-8266054' of http://github.com/jatin-bhateja/jdk into JDK-8266054
>  - ... and 9 more: https://git.openjdk.java.net/jdk/compare/a8f15427...b20404e2

Looks good to me.

-------------

Marked as reviewed by sviswanathan (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3720

From david.holmes at oracle.com  Tue Jul 27 23:02:55 2021
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 28 Jul 2021 09:02:55 +1000
Subject: RFR: JDK-8256844: Make NMT late-initializable
In-Reply-To: <gg2GKwMJOe-o1ZEXDvZ-ozQIEXgkBG47B8tqRBbl2C8=.53cc7973-ecec-43f0-bc21-cf3e5236852e@github.com>
References: <Ze_dKp-5-dse_657jTXTD4kbHSBeOQcLvqeluE0DXjI=.9214cb10-f1f1-48cb-8d96-12621a51a904@github.com>
 <c4d84f41-ffb9-d327-9ec9-e9f9c61b8367@oracle.com>
 <gg2GKwMJOe-o1ZEXDvZ-ozQIEXgkBG47B8tqRBbl2C8=.53cc7973-ecec-43f0-bc21-cf3e5236852e@github.com>
Message-ID: <57df56b8-2a33-9a8f-8d6a-132208ce1b5f@oracle.com>

On 28/07/2021 12:17 am, Thomas Stuefe wrote:
> On Mon, 26 Jul 2021 21:08:04 GMT, David Holmes <david.holmes at oracle.com> wrote:
> 
>> Before looking at this, have you checked the startup performance impact?
>>
>> Thanks,
>> David
>> -----
> 
> Hi David,
> 
> performance should not be a problem. The potentially costly thing is the underlying hashmap. But we keep it operating with a very small load factor.
> 
> More details:
> 
> Adding entries is O(1). Since during pre-init phase almost only adds happen, startup time is not affected. Still, to make sure this is true, I did a bunch of tests:
> 
> - tested WCT of a helloworld, no differences with and without patch
> - tested startup time in various of ways, no differences
> - repeated those tests with 25000 (!) VM arguments, the only way to influence the number of pre-init allocations. No differences (VM gets slower with and without patch).
> 
> ----
> 
> The expensive thing is lookup since we potentially need to walk a very full hashmap. Lookup affects post-init more than pre-init.
> 
> To get an idea of the cost of a too-full preinit lookup table, I modified the VM to do a configurable number of pre-init test-allocations, with the intent of artificially inflating the lookup table. Then, after NMT initialization, I measured the cost of lookup. The short story, I was not able to measure anything, even with a million pre-init allocations. Of course, with more allocations lookup table got fuller and the VM got slower, but the time increase was caused by the cost of the malloc calls themselves, not the table lookup.
> 
> Finally, I did an isolated test for the lookup table, testing pure adding and retrieval cost with artificial values. There, I could see costs for add were static (as expected), and lookup cost increased with table population. On my machine:
> 
> | lu table entries            | time per lookup |
> | ------ |:-------------:|
> | 1000    | 3 ns         |
> | 1 mio   | 240 ns       |
> 
> As you can see, if lookup table population goes beyond 1 mio entries, lookup time starts being noticeable over background noise. But with these numbers, I am not worried. Standard lookup population should be around *300-500*, with very long command lines resulting in table populations of *~1000*. We should never seen 10000 entries, let alone millions of them.
> 
> Still, I added a jtreg test to verify the expected hash table population. To catch errors like an unforeseen mass of pre-init allocations (lets say a leak or badly written code sneaked in), or if the hash algorithm suddenly is not good anymore.
> 
> Two more points
> 
> 1) I kept this coding deliberately simple. If we are really worried about a degenerated lookup table, we can do things to fix that:
>   - we could automatically resize and rehash
>   - we could, if we sense something wrong, just stop filling it and disable NMT, stopping NMT init phase prematurely at the cost of not being able to use NMT.
>   
> The latter I had implemented already but removed it again to keep complexity down, and because I saw no need.
> 
> 2) In our propietary production VM we have a system similar to NMT, but predating it. In that system we don't use malloc headers but store all (millions of) malloc'ed pointers in a big hash map. It performs excellent on *all our libc variants*. It is so fast that we just leave it always switched on. This solution has been productive since >10 years, and therefore I am confident that this is viable. This proposed hashmap with a planned population of 300-1000 is really not much :)

Thanks Thomas! I appreciate the detailed investigation.

Cheers,
David

> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/4874
> 

From jbhateja at openjdk.java.net  Wed Jul 28 02:22:41 2021
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Wed, 28 Jul 2021 02:22:41 GMT
Subject: Integrated: 8266054: VectorAPI rotate operation optimization
In-Reply-To: <OZ2u4DDNaYF3WiR5uU6NWvzPMKV3j8QAO_mZyLP3Isg=.594e3514-8a5a-442c-ac1a-ca6c6d14e963@github.com>
References: <OZ2u4DDNaYF3WiR5uU6NWvzPMKV3j8QAO_mZyLP3Isg=.594e3514-8a5a-442c-ac1a-ca6c6d14e963@github.com>
Message-ID: <BDbnRETp0PWKWTnIJghtiMPlewGp5tXpnJPzeBTExuY=.db1e5321-6bab-4a30-9c88-18f1f8f1df5f@github.com>

On Tue, 27 Apr 2021 17:56:04 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Current VectorAPI Java side implementation expresses rotateLeft and rotateRight operation using following operations:-
> 
>     vec1 = lanewise(VectorOperators.LSHL, n)
>     vec2 = lanewise(VectorOperators.LSHR, n)
>     res = lanewise(VectorOperations.OR, vec1 , vec2)
> 
> This patch moves above handling from Java side to C2 compiler which facilitates dismantling the rotate operation if target ISA does not support a direct rotate instruction.
> 
> AVX512 added vector rotate instructions vpro[rl][v][dq] which operate over long and integer type vectors. For other cases (i.e. sub-word type vectors or for targets which do not support direct rotate operations )   instruction sequence comprising of vector SHIFT (LEFT/RIGHT) and vector OR is emitted.
> 
> Please find below the performance data for included JMH benchmark.
> Machine:  Cascade Lake Server (Intel(R) Xeon(R) Platinum 8280 CPU @ 2.70GHz)
> 
> 
> <html xmlns:v="urn:schemas-microsoft-com:vml"
> xmlns:o="urn:schemas-microsoft-com:office:office"
> xmlns:x="urn:schemas-microsoft-com:office:excel"
> xmlns="http://www.w3.org/TR/REC-html40">
> 
> <head>
> 
> <meta name=ProgId content=Excel.Sheet>
> <meta name=Generator content="Microsoft Excel 15">
> <link id=Main-File rel=Main-File
> href="file:///C:/Users/jatinbha/AppData/Local/Temp/msohtmlclip1/01/clip.htm">
> <link rel=File-List
> href="file:///C:/Users/jatinbha/AppData/Local/Temp/msohtmlclip1/01/clip_filelist.xml">
> <style>
> 
> </style>
> </head>
> 
> <body link="#0563C1" vlink="#954F72">
> 
> 
> 
> Benchmark | (bits) | (shift) | (size) | Baseline Score (ops/ms) | With Opts (ops/ms) | Gain
> -- | -- | -- | -- | -- | -- | --
> RotateBenchmark.testRotateLeftB | 128 | 7 | 256 | 3939.136 | 3836.133 | 0.973851372
> RotateBenchmark.testRotateLeftB | 128 | 7 | 512 | 1984.231 | 1918.27 | 0.966757399
> RotateBenchmark.testRotateLeftB | 128 | 15 | 256 | 3925.165 | 4043.842 | 1.030234907
> RotateBenchmark.testRotateLeftB | 128 | 15 | 512 | 1962.723 | 1936.551 | 0.986665464
> RotateBenchmark.testRotateLeftB | 128 | 31 | 256 | 3945.6 | 3817.883 | 0.967630525
> RotateBenchmark.testRotateLeftB | 128 | 31 | 512 | 1944.458 | 1914.229 | 0.984453766
> RotateBenchmark.testRotateLeftB | 256 | 7 | 256 | 4612.149 | 4514.874 | 0.978908964
> RotateBenchmark.testRotateLeftB | 256 | 7 | 512 | 2296.252 | 2270.237 | 0.988670669
> RotateBenchmark.testRotateLeftB | 256 | 15 | 256 | 4576.628 | 4515.53 | 0.986649996
> RotateBenchmark.testRotateLeftB | 256 | 15 | 512 | 2288.278 | 2270.923 | 0.992415694
> RotateBenchmark.testRotateLeftB | 256 | 31 | 256 | 4624.243 | 4511.46 | 0.975610495
> RotateBenchmark.testRotateLeftB | 256 | 31 | 512 | 2305.459 | 2273.788 | 0.986262605
> RotateBenchmark.testRotateLeftB | 512 | 7 | 256 | 7748.283 | 7777.105 | 1.003719792
> RotateBenchmark.testRotateLeftB | 512 | 7 | 512 | 3906.214 | 3912.647 | 1.001646863
> RotateBenchmark.testRotateLeftB | 512 | 15 | 256 | 7764.653 | 7763.482 | 0.999849188
> RotateBenchmark.testRotateLeftB | 512 | 15 | 512 | 3916.061 | 3919.363 | 1.000843194
> RotateBenchmark.testRotateLeftB | 512 | 31 | 256 | 7779.754 | 7770.239 | 0.998776954
> RotateBenchmark.testRotateLeftB | 512 | 31 | 512 | 3916.471 | 3912.718 | 0.999041739
> RotateBenchmark.testRotateLeftI | 128 | 7 | 256 | 4043.39 | 13461.814 | 3.329338501
> RotateBenchmark.testRotateLeftI | 128 | 7 | 512 | 1996.217 | 6455.425 | 3.233829288
> RotateBenchmark.testRotateLeftI | 128 | 15 | 256 | 4028.614 | 13077.277 | 3.246098286
> RotateBenchmark.testRotateLeftI | 128 | 15 | 512 | 1997.612 | 6452.918 | 3.230315997
> RotateBenchmark.testRotateLeftI | 128 | 31 | 256 | 4123.357 | 13079.045 | 3.171940969
> RotateBenchmark.testRotateLeftI | 128 | 31 | 512 | 2003.356 | 6452.716 | 3.22095324
> RotateBenchmark.testRotateLeftI | 256 | 7 | 256 | 7666.949 | 25658.625 | 3.34665393
> RotateBenchmark.testRotateLeftI | 256 | 7 | 512 | 3855.826 | 12278.106 | 3.18429981
> RotateBenchmark.testRotateLeftI | 256 | 15 | 256 | 7670.901 | 24625.466 | 3.210244272
> RotateBenchmark.testRotateLeftI | 256 | 15 | 512 | 3765.786 | 12272.771 | 3.259019764
> RotateBenchmark.testRotateLeftI | 256 | 31 | 256 | 7660.599 | 25678.864 | 3.352069988
> RotateBenchmark.testRotateLeftI | 256 | 31 | 512 | 3773.401 | 12006.469 | 3.181869353
> RotateBenchmark.testRotateLeftI | 512 | 7 | 256 | 11900.948 | 31242.989 | 2.625252123
> RotateBenchmark.testRotateLeftI | 512 | 7 | 512 | 5830.878 | 15727.149 | 2.697217983
> RotateBenchmark.testRotateLeftI | 512 | 15 | 256 | 12171.847 | 33180.067 | 2.72596813
> RotateBenchmark.testRotateLeftI | 512 | 15 | 512 | 5830.544 | 16740.182 | 2.871118372
> RotateBenchmark.testRotateLeftI | 512 | 31 | 256 | 11909.553 | 31250.882 | 2.624018047
> RotateBenchmark.testRotateLeftI | 512 | 31 | 512 | 5846.747 | 15738.831 | 2.691895339
> RotateBenchmark.testRotateLeftL | 128 | 7 | 256 | 2047.243 | 6888.484 | 3.364761291
> RotateBenchmark.testRotateLeftL | 128 | 7 | 512 | 1005.029 | 3245.931 | 3.229688895
> RotateBenchmark.testRotateLeftL | 128 | 15 | 256 | 1996.921 | 6985.256 | 3.498013191
> RotateBenchmark.testRotateLeftL | 128 | 15 | 512 | 986.906 | 3217.778 | 3.260470602
> RotateBenchmark.testRotateLeftL | 128 | 31 | 256 | 1999.06 | 6977.672 | 3.490476524
> RotateBenchmark.testRotateLeftL | 128 | 31 | 512 | 987.258 | 3236.63 | 3.278403416
> RotateBenchmark.testRotateLeftL | 256 | 7 | 256 | 3752.412 | 12995.954 | 3.4633601
> RotateBenchmark.testRotateLeftL | 256 | 7 | 512 | 1824.093 | 5809.576 | 3.184912173
> RotateBenchmark.testRotateLeftL | 256 | 15 | 256 | 3759.99 | 13262.631 | 3.52730486
> RotateBenchmark.testRotateLeftL | 256 | 15 | 512 | 1823.393 | 5803.872 | 3.183006626
> RotateBenchmark.testRotateLeftL | 256 | 31 | 256 | 3757.134 | 13284.633 | 3.535842214
> RotateBenchmark.testRotateLeftL | 256 | 31 | 512 | 1822.192 | 5824.178 | 3.196248255
> RotateBenchmark.testRotateLeftL | 512 | 7 | 256 | 5794.005 | 15567.753 | 2.686872552
> RotateBenchmark.testRotateLeftL | 512 | 7 | 512 | 2969.393 | 7694.79 | 2.591368
> RotateBenchmark.testRotateLeftL | 512 | 15 | 256 | 5817.292 | 15726.597 | 2.703422314
> RotateBenchmark.testRotateLeftL | 512 | 15 | 512 | 2944.655 | 7664.954 | 2.603005785
> RotateBenchmark.testRotateLeftL | 512 | 31 | 256 | 5822.131 | 16718.64 | 2.871567129
> RotateBenchmark.testRotateLeftL | 512 | 31 | 512 | 2944.763 | 7657.814 | 2.600485676
> RotateBenchmark.testRotateLeftS | 128 | 7 | 256 | 8006.155 | 7976.701 | 0.99632108
> RotateBenchmark.testRotateLeftS | 128 | 7 | 512 | 4031.753 | 4003.43 | 0.992975016
> RotateBenchmark.testRotateLeftS | 128 | 15 | 256 | 8003.879 | 7952.752 | 0.993612222
> RotateBenchmark.testRotateLeftS | 128 | 15 | 512 | 4026.359 | 4014.757 | 0.997118488
> RotateBenchmark.testRotateLeftS | 128 | 31 | 256 | 8000.842 | 7995.733 | 0.999361442
> RotateBenchmark.testRotateLeftS | 128 | 31 | 512 | 4044.421 | 4007.426 | 0.990852832
> RotateBenchmark.testRotateLeftS | 256 | 7 | 256 | 15078.471 | 15034.395 | 0.997076892
> RotateBenchmark.testRotateLeftS | 256 | 7 | 512 | 7236.509 | 7620.334 | 1.053040078
> RotateBenchmark.testRotateLeftS | 256 | 15 | 256 | 15093.661 | 15024.17 | 0.995396014
> RotateBenchmark.testRotateLeftS | 256 | 15 | 512 | 7308.568 | 7724.381 | 1.056893909
> RotateBenchmark.testRotateLeftS | 256 | 31 | 256 | 15332.233 | 15432.113 | 1.006514381
> RotateBenchmark.testRotateLeftS | 256 | 31 | 512 | 7317.18 | 7626.679 | 1.042297579
> RotateBenchmark.testRotateLeftS | 512 | 7 | 256 | 24079.012 | 23939.263 | 0.994196232
> RotateBenchmark.testRotateLeftS | 512 | 7 | 512 | 11441.41 | 11921.21 | 1.041935391
> RotateBenchmark.testRotateLeftS | 512 | 15 | 256 | 23563.675 | 23590.959 | 1.001157884
> RotateBenchmark.testRotateLeftS | 512 | 15 | 512 | 11418.634 | 11949.391 | 1.046481654
> RotateBenchmark.testRotateLeftS | 512 | 31 | 256 | 24035.69 | 23595.385 | 0.9816812
> RotateBenchmark.testRotateLeftS | 512 | 31 | 512 | 11668.091 | 11899.536 | 1.019835721
> RotateBenchmark.testRotateRightB | 128 | 7 | 256 | 3852.421 | 3816.521 | 0.990681185
> RotateBenchmark.testRotateRightB | 128 | 7 | 512 | 1956.766 | 1923.638 | 0.983070025
> RotateBenchmark.testRotateRightB | 128 | 15 | 256 | 3899.136 | 4038.945 | 1.035856405
> RotateBenchmark.testRotateRightB | 128 | 15 | 512 | 1957.733 | 2030.973 | 1.037410617
> RotateBenchmark.testRotateRightB | 128 | 31 | 256 | 3902.5 | 4043.736 | 1.03619116
> RotateBenchmark.testRotateRightB | 128 | 31 | 512 | 1957.728 | 1920.434 | 0.980950367
> RotateBenchmark.testRotateRightB | 256 | 7 | 256 | 4565.887 | 4515.083 | 0.988873137
> RotateBenchmark.testRotateRightB | 256 | 7 | 512 | 2300.057 | 2278.065 | 0.990438498
> RotateBenchmark.testRotateRightB | 256 | 15 | 256 | 4570.754 | 4527.692 | 0.990578797
> RotateBenchmark.testRotateRightB | 256 | 15 | 512 | 2300.524 | 2268.659 | 0.986148808
> RotateBenchmark.testRotateRightB | 256 | 31 | 256 | 4577.569 | 4513.29 | 0.98595783
> RotateBenchmark.testRotateRightB | 256 | 31 | 512 | 2304.335 | 2273.178 | 0.986478962
> RotateBenchmark.testRotateRightB | 512 | 7 | 256 | 7772.483 | 7842.671 | 1.009030319
> RotateBenchmark.testRotateRightB | 512 | 7 | 512 | 3907.265 | 3917.325 | 1.002574691
> RotateBenchmark.testRotateRightB | 512 | 15 | 256 | 7855.653 | 7865.25 | 1.001221668
> RotateBenchmark.testRotateRightB | 512 | 15 | 512 | 3909.845 | 3976.813 | 1.017128045
> RotateBenchmark.testRotateRightB | 512 | 31 | 256 | 7746.765 | 7870.159 | 1.015928455
> RotateBenchmark.testRotateRightB | 512 | 31 | 512 | 3919.596 | 3981.934 | 1.01590419
> RotateBenchmark.testRotateRightI | 128 | 7 | 256 | 4125.151 | 13056.878 | 3.165187893
> RotateBenchmark.testRotateRightI | 128 | 7 | 512 | 2045.201 | 6501.447 | 3.17887924
> RotateBenchmark.testRotateRightI | 128 | 15 | 256 | 4111.736 | 13318.124 | 3.23905134
> RotateBenchmark.testRotateRightI | 128 | 15 | 512 | 2055.355 | 6497.289 | 3.161151723
> RotateBenchmark.testRotateRightI | 128 | 31 | 256 | 4109.353 | 13073.3 | 3.181352393
> RotateBenchmark.testRotateRightI | 128 | 31 | 512 | 2055.431 | 6463.902 | 3.14479153
> RotateBenchmark.testRotateRightI | 256 | 7 | 256 | 7804.976 | 24585.962 | 3.150036848
> RotateBenchmark.testRotateRightI | 256 | 7 | 512 | 3815.818 | 11985.145 | 3.140911071
> RotateBenchmark.testRotateRightI | 256 | 15 | 256 | 7644.977 | 25863.841 | 3.383115606
> RotateBenchmark.testRotateRightI | 256 | 15 | 512 | 3822.508 | 12280.58 | 3.212702236
> RotateBenchmark.testRotateRightI | 256 | 31 | 256 | 7709.635 | 25655.108 | 3.327668301
> RotateBenchmark.testRotateRightI | 256 | 31 | 512 | 3801.5 | 12271.65 | 3.228107326
> RotateBenchmark.testRotateRightI | 512 | 7 | 256 | 12223.711 | 31239.788 | 2.555671351
> RotateBenchmark.testRotateRightI | 512 | 7 | 512 | 5973.571 | 16740.852 | 2.802486486
> RotateBenchmark.testRotateRightI | 512 | 15 | 256 | 12205.47 | 31248.025 | 2.560165647
> RotateBenchmark.testRotateRightI | 512 | 15 | 512 | 5966.513 | 15728.168 | 2.6360737
> RotateBenchmark.testRotateRightI | 512 | 31 | 256 | 12209.405 | 33181.105 | 2.71766765
> RotateBenchmark.testRotateRightI | 512 | 31 | 512 | 5981.527 | 15727.496 | 2.629344647
> RotateBenchmark.testRotateRightL | 128 | 7 | 256 | 2054.509 | 6980.849 | 3.397818652
> RotateBenchmark.testRotateRightL | 128 | 7 | 512 | 997.375 | 3242.374 | 3.250907633
> RotateBenchmark.testRotateRightL | 128 | 15 | 256 | 2051.459 | 6892.389 | 3.359749817
> RotateBenchmark.testRotateRightL | 128 | 15 | 512 | 1002.906 | 3223.342 | 3.21400211
> RotateBenchmark.testRotateRightL | 128 | 31 | 256 | 2044.749 | 6984.157 | 3.415654929
> RotateBenchmark.testRotateRightL | 128 | 31 | 512 | 1004.273 | 3237.496 | 3.22372104
> RotateBenchmark.testRotateRightL | 256 | 7 | 256 | 3811.551 | 13347.75 | 3.501920872
> RotateBenchmark.testRotateRightL | 256 | 7 | 512 | 1892.883 | 5840.85 | 3.085689924
> RotateBenchmark.testRotateRightL | 256 | 15 | 256 | 3821.705 | 14034.823 | 3.672398314
> RotateBenchmark.testRotateRightL | 256 | 15 | 512 | 1799.193 | 5817.533 | 3.233412424
> RotateBenchmark.testRotateRightL | 256 | 31 | 256 | 3816.666 | 14022.31 | 3.673968327
> RotateBenchmark.testRotateRightL | 256 | 31 | 512 | 1796.649 | 5824.13 | 3.241662673
> RotateBenchmark.testRotateRightL | 512 | 7 | 256 | 5943.986 | 15586.254 | 2.622188881
> RotateBenchmark.testRotateRightL | 512 | 7 | 512 | 3022.686 | 7662.241 | 2.534911334
> RotateBenchmark.testRotateRightL | 512 | 15 | 256 | 5958.008 | 15726.859 | 2.639616966
> RotateBenchmark.testRotateRightL | 512 | 15 | 512 | 2998.469 | 7654.703 | 2.552870482
> RotateBenchmark.testRotateRightL | 512 | 31 | 256 | 5937.491 | 15741.207 | 2.651154671
> RotateBenchmark.testRotateRightL | 512 | 31 | 512 | 3014.699 | 7656.837 | 2.539834657
> RotateBenchmark.testRotateRightS | 128 | 7 | 256 | 8172.896 | 8003.474 | 0.979270261
> RotateBenchmark.testRotateRightS | 128 | 7 | 512 | 4111.074 | 4047.267 | 0.984479238
> RotateBenchmark.testRotateRightS | 128 | 15 | 256 | 8225.79 | 8040.421 | 0.9774649
> RotateBenchmark.testRotateRightS | 128 | 15 | 512 | 4129.801 | 4011.919 | 0.971455767
> RotateBenchmark.testRotateRightS | 128 | 31 | 256 | 8176.102 | 8052.686 | 0.984905276
> RotateBenchmark.testRotateRightS | 128 | 31 | 512 | 4117.735 | 4046.522 | 0.982705784
> RotateBenchmark.testRotateRightS | 256 | 7 | 256 | 15213.617 | 15169.51 | 0.997100821
> RotateBenchmark.testRotateRightS | 256 | 7 | 512 | 7530.289 | 7625.581 | 1.012654494
> RotateBenchmark.testRotateRightS | 256 | 15 | 256 | 15238.384 | 15069.978 | 0.988948566
> RotateBenchmark.testRotateRightS | 256 | 15 | 512 | 7275.098 | 7620.764 | 1.047513587
> RotateBenchmark.testRotateRightS | 256 | 31 | 256 | 15299.821 | 15043.765 | 0.983264118
> RotateBenchmark.testRotateRightS | 256 | 31 | 512 | 7273.028 | 7630.97 | 1.04921499
> RotateBenchmark.testRotateRightS | 512 | 7 | 256 | 23998.152 | 23920.046 | 0.996745333
> RotateBenchmark.testRotateRightS | 512 | 7 | 512 | 11582.679 | 11916.382 | 1.02881052
> RotateBenchmark.testRotateRightS | 512 | 15 | 256 | 23982.797 | 23434.756 | 0.977148579
> RotateBenchmark.testRotateRightS | 512 | 15 | 512 | 11629.806 | 11918.759 | 1.0248459
> RotateBenchmark.testRotateRightS | 512 | 31 | 256 | 23988.549 | 23475.629 | 0.978618132
> RotateBenchmark.testRotateRightS | 512 | 31 | 512 | 11650.146 | 11916.47 | 1.022860143
> 
> 
> 
> </body>
> 
> </html>

This pull request has now been integrated.

Changeset: d994b93e
Author:    Jatin Bhateja <jbhateja at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d994b93e211d49af79212d765633ba3457365a08
Stats:     4438 lines in 57 files changed: 4219 ins; 58 del; 161 mod

8266054: VectorAPI rotate operation optimization

Reviewed-by: psandoz, sviswanathan

-------------

PR: https://git.openjdk.java.net/jdk/pull/3720

From weijun at openjdk.java.net  Wed Jul 28 02:57:42 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 28 Jul 2021 02:57:42 GMT
Subject: RFR: 8266054: VectorAPI rotate operation optimization [v13]
In-Reply-To: <HU2E5YuCI7Iz38CNycxu62RVNsyyT9unlr79-fSwFVg=.fde03b0d-6f8f-445f-88e4-84511f50226b@github.com>
References: <OZ2u4DDNaYF3WiR5uU6NWvzPMKV3j8QAO_mZyLP3Isg=.594e3514-8a5a-442c-ac1a-ca6c6d14e963@github.com>
 <HU2E5YuCI7Iz38CNycxu62RVNsyyT9unlr79-fSwFVg=.fde03b0d-6f8f-445f-88e4-84511f50226b@github.com>
Message-ID: <yz1q_z2hzZ5b2oF6lCR6SehwxE6AW6T_QmV1Govom4c=.8a428bcf-eb50-4efd-b584-4a0f0b8d034c@github.com>

On Tue, 20 Jul 2021 09:57:07 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Current VectorAPI Java side implementation expresses rotateLeft and rotateRight operation using following operations:-
>> 
>>     vec1 = lanewise(VectorOperators.LSHL, n)
>>     vec2 = lanewise(VectorOperators.LSHR, n)
>>     res = lanewise(VectorOperations.OR, vec1 , vec2)
>> 
>> This patch moves above handling from Java side to C2 compiler which facilitates dismantling the rotate operation if target ISA does not support a direct rotate instruction.
>> 
>> AVX512 added vector rotate instructions vpro[rl][v][dq] which operate over long and integer type vectors. For other cases (i.e. sub-word type vectors or for targets which do not support direct rotate operations )   instruction sequence comprising of vector SHIFT (LEFT/RIGHT) and vector OR is emitted.
>> 
>> Please find below the performance data for included JMH benchmark.
>> Machine:  Cascade Lake Server (Intel(R) Xeon(R) Platinum 8280 CPU @ 2.70GHz)
>> 
>> 
>> <html xmlns:v="urn:schemas-microsoft-com:vml"
>> xmlns:o="urn:schemas-microsoft-com:office:office"
>> xmlns:x="urn:schemas-microsoft-com:office:excel"
>> xmlns="http://www.w3.org/TR/REC-html40">
>> 
>> <head>
>> 
>> <meta name=ProgId content=Excel.Sheet>
>> <meta name=Generator content="Microsoft Excel 15">
>> <link id=Main-File rel=Main-File
>> href="file:///C:/Users/jatinbha/AppData/Local/Temp/msohtmlclip1/01/clip.htm">
>> <link rel=File-List
>> href="file:///C:/Users/jatinbha/AppData/Local/Temp/msohtmlclip1/01/clip_filelist.xml">
>> <style>
>> 
>> </style>
>> </head>
>> 
>> <body link="#0563C1" vlink="#954F72">
>> 
>> 
>> 
>> Benchmark | (bits) | (shift) | (size) | Baseline Score (ops/ms) | With Opts (ops/ms) | Gain
>> -- | -- | -- | -- | -- | -- | --
>> RotateBenchmark.testRotateLeftB | 128 | 7 | 256 | 3939.136 | 3836.133 | 0.973851372
>> RotateBenchmark.testRotateLeftB | 128 | 7 | 512 | 1984.231 | 1918.27 | 0.966757399
>> RotateBenchmark.testRotateLeftB | 128 | 15 | 256 | 3925.165 | 4043.842 | 1.030234907
>> RotateBenchmark.testRotateLeftB | 128 | 15 | 512 | 1962.723 | 1936.551 | 0.986665464
>> RotateBenchmark.testRotateLeftB | 128 | 31 | 256 | 3945.6 | 3817.883 | 0.967630525
>> RotateBenchmark.testRotateLeftB | 128 | 31 | 512 | 1944.458 | 1914.229 | 0.984453766
>> RotateBenchmark.testRotateLeftB | 256 | 7 | 256 | 4612.149 | 4514.874 | 0.978908964
>> RotateBenchmark.testRotateLeftB | 256 | 7 | 512 | 2296.252 | 2270.237 | 0.988670669
>> RotateBenchmark.testRotateLeftB | 256 | 15 | 256 | 4576.628 | 4515.53 | 0.986649996
>> RotateBenchmark.testRotateLeftB | 256 | 15 | 512 | 2288.278 | 2270.923 | 0.992415694
>> RotateBenchmark.testRotateLeftB | 256 | 31 | 256 | 4624.243 | 4511.46 | 0.975610495
>> RotateBenchmark.testRotateLeftB | 256 | 31 | 512 | 2305.459 | 2273.788 | 0.986262605
>> RotateBenchmark.testRotateLeftB | 512 | 7 | 256 | 7748.283 | 7777.105 | 1.003719792
>> RotateBenchmark.testRotateLeftB | 512 | 7 | 512 | 3906.214 | 3912.647 | 1.001646863
>> RotateBenchmark.testRotateLeftB | 512 | 15 | 256 | 7764.653 | 7763.482 | 0.999849188
>> RotateBenchmark.testRotateLeftB | 512 | 15 | 512 | 3916.061 | 3919.363 | 1.000843194
>> RotateBenchmark.testRotateLeftB | 512 | 31 | 256 | 7779.754 | 7770.239 | 0.998776954
>> RotateBenchmark.testRotateLeftB | 512 | 31 | 512 | 3916.471 | 3912.718 | 0.999041739
>> RotateBenchmark.testRotateLeftI | 128 | 7 | 256 | 4043.39 | 13461.814 | 3.329338501
>> RotateBenchmark.testRotateLeftI | 128 | 7 | 512 | 1996.217 | 6455.425 | 3.233829288
>> RotateBenchmark.testRotateLeftI | 128 | 15 | 256 | 4028.614 | 13077.277 | 3.246098286
>> RotateBenchmark.testRotateLeftI | 128 | 15 | 512 | 1997.612 | 6452.918 | 3.230315997
>> RotateBenchmark.testRotateLeftI | 128 | 31 | 256 | 4123.357 | 13079.045 | 3.171940969
>> RotateBenchmark.testRotateLeftI | 128 | 31 | 512 | 2003.356 | 6452.716 | 3.22095324
>> RotateBenchmark.testRotateLeftI | 256 | 7 | 256 | 7666.949 | 25658.625 | 3.34665393
>> RotateBenchmark.testRotateLeftI | 256 | 7 | 512 | 3855.826 | 12278.106 | 3.18429981
>> RotateBenchmark.testRotateLeftI | 256 | 15 | 256 | 7670.901 | 24625.466 | 3.210244272
>> RotateBenchmark.testRotateLeftI | 256 | 15 | 512 | 3765.786 | 12272.771 | 3.259019764
>> RotateBenchmark.testRotateLeftI | 256 | 31 | 256 | 7660.599 | 25678.864 | 3.352069988
>> RotateBenchmark.testRotateLeftI | 256 | 31 | 512 | 3773.401 | 12006.469 | 3.181869353
>> RotateBenchmark.testRotateLeftI | 512 | 7 | 256 | 11900.948 | 31242.989 | 2.625252123
>> RotateBenchmark.testRotateLeftI | 512 | 7 | 512 | 5830.878 | 15727.149 | 2.697217983
>> RotateBenchmark.testRotateLeftI | 512 | 15 | 256 | 12171.847 | 33180.067 | 2.72596813
>> RotateBenchmark.testRotateLeftI | 512 | 15 | 512 | 5830.544 | 16740.182 | 2.871118372
>> RotateBenchmark.testRotateLeftI | 512 | 31 | 256 | 11909.553 | 31250.882 | 2.624018047
>> RotateBenchmark.testRotateLeftI | 512 | 31 | 512 | 5846.747 | 15738.831 | 2.691895339
>> RotateBenchmark.testRotateLeftL | 128 | 7 | 256 | 2047.243 | 6888.484 | 3.364761291
>> RotateBenchmark.testRotateLeftL | 128 | 7 | 512 | 1005.029 | 3245.931 | 3.229688895
>> RotateBenchmark.testRotateLeftL | 128 | 15 | 256 | 1996.921 | 6985.256 | 3.498013191
>> RotateBenchmark.testRotateLeftL | 128 | 15 | 512 | 986.906 | 3217.778 | 3.260470602
>> RotateBenchmark.testRotateLeftL | 128 | 31 | 256 | 1999.06 | 6977.672 | 3.490476524
>> RotateBenchmark.testRotateLeftL | 128 | 31 | 512 | 987.258 | 3236.63 | 3.278403416
>> RotateBenchmark.testRotateLeftL | 256 | 7 | 256 | 3752.412 | 12995.954 | 3.4633601
>> RotateBenchmark.testRotateLeftL | 256 | 7 | 512 | 1824.093 | 5809.576 | 3.184912173
>> RotateBenchmark.testRotateLeftL | 256 | 15 | 256 | 3759.99 | 13262.631 | 3.52730486
>> RotateBenchmark.testRotateLeftL | 256 | 15 | 512 | 1823.393 | 5803.872 | 3.183006626
>> RotateBenchmark.testRotateLeftL | 256 | 31 | 256 | 3757.134 | 13284.633 | 3.535842214
>> RotateBenchmark.testRotateLeftL | 256 | 31 | 512 | 1822.192 | 5824.178 | 3.196248255
>> RotateBenchmark.testRotateLeftL | 512 | 7 | 256 | 5794.005 | 15567.753 | 2.686872552
>> RotateBenchmark.testRotateLeftL | 512 | 7 | 512 | 2969.393 | 7694.79 | 2.591368
>> RotateBenchmark.testRotateLeftL | 512 | 15 | 256 | 5817.292 | 15726.597 | 2.703422314
>> RotateBenchmark.testRotateLeftL | 512 | 15 | 512 | 2944.655 | 7664.954 | 2.603005785
>> RotateBenchmark.testRotateLeftL | 512 | 31 | 256 | 5822.131 | 16718.64 | 2.871567129
>> RotateBenchmark.testRotateLeftL | 512 | 31 | 512 | 2944.763 | 7657.814 | 2.600485676
>> RotateBenchmark.testRotateLeftS | 128 | 7 | 256 | 8006.155 | 7976.701 | 0.99632108
>> RotateBenchmark.testRotateLeftS | 128 | 7 | 512 | 4031.753 | 4003.43 | 0.992975016
>> RotateBenchmark.testRotateLeftS | 128 | 15 | 256 | 8003.879 | 7952.752 | 0.993612222
>> RotateBenchmark.testRotateLeftS | 128 | 15 | 512 | 4026.359 | 4014.757 | 0.997118488
>> RotateBenchmark.testRotateLeftS | 128 | 31 | 256 | 8000.842 | 7995.733 | 0.999361442
>> RotateBenchmark.testRotateLeftS | 128 | 31 | 512 | 4044.421 | 4007.426 | 0.990852832
>> RotateBenchmark.testRotateLeftS | 256 | 7 | 256 | 15078.471 | 15034.395 | 0.997076892
>> RotateBenchmark.testRotateLeftS | 256 | 7 | 512 | 7236.509 | 7620.334 | 1.053040078
>> RotateBenchmark.testRotateLeftS | 256 | 15 | 256 | 15093.661 | 15024.17 | 0.995396014
>> RotateBenchmark.testRotateLeftS | 256 | 15 | 512 | 7308.568 | 7724.381 | 1.056893909
>> RotateBenchmark.testRotateLeftS | 256 | 31 | 256 | 15332.233 | 15432.113 | 1.006514381
>> RotateBenchmark.testRotateLeftS | 256 | 31 | 512 | 7317.18 | 7626.679 | 1.042297579
>> RotateBenchmark.testRotateLeftS | 512 | 7 | 256 | 24079.012 | 23939.263 | 0.994196232
>> RotateBenchmark.testRotateLeftS | 512 | 7 | 512 | 11441.41 | 11921.21 | 1.041935391
>> RotateBenchmark.testRotateLeftS | 512 | 15 | 256 | 23563.675 | 23590.959 | 1.001157884
>> RotateBenchmark.testRotateLeftS | 512 | 15 | 512 | 11418.634 | 11949.391 | 1.046481654
>> RotateBenchmark.testRotateLeftS | 512 | 31 | 256 | 24035.69 | 23595.385 | 0.9816812
>> RotateBenchmark.testRotateLeftS | 512 | 31 | 512 | 11668.091 | 11899.536 | 1.019835721
>> RotateBenchmark.testRotateRightB | 128 | 7 | 256 | 3852.421 | 3816.521 | 0.990681185
>> RotateBenchmark.testRotateRightB | 128 | 7 | 512 | 1956.766 | 1923.638 | 0.983070025
>> RotateBenchmark.testRotateRightB | 128 | 15 | 256 | 3899.136 | 4038.945 | 1.035856405
>> RotateBenchmark.testRotateRightB | 128 | 15 | 512 | 1957.733 | 2030.973 | 1.037410617
>> RotateBenchmark.testRotateRightB | 128 | 31 | 256 | 3902.5 | 4043.736 | 1.03619116
>> RotateBenchmark.testRotateRightB | 128 | 31 | 512 | 1957.728 | 1920.434 | 0.980950367
>> RotateBenchmark.testRotateRightB | 256 | 7 | 256 | 4565.887 | 4515.083 | 0.988873137
>> RotateBenchmark.testRotateRightB | 256 | 7 | 512 | 2300.057 | 2278.065 | 0.990438498
>> RotateBenchmark.testRotateRightB | 256 | 15 | 256 | 4570.754 | 4527.692 | 0.990578797
>> RotateBenchmark.testRotateRightB | 256 | 15 | 512 | 2300.524 | 2268.659 | 0.986148808
>> RotateBenchmark.testRotateRightB | 256 | 31 | 256 | 4577.569 | 4513.29 | 0.98595783
>> RotateBenchmark.testRotateRightB | 256 | 31 | 512 | 2304.335 | 2273.178 | 0.986478962
>> RotateBenchmark.testRotateRightB | 512 | 7 | 256 | 7772.483 | 7842.671 | 1.009030319
>> RotateBenchmark.testRotateRightB | 512 | 7 | 512 | 3907.265 | 3917.325 | 1.002574691
>> RotateBenchmark.testRotateRightB | 512 | 15 | 256 | 7855.653 | 7865.25 | 1.001221668
>> RotateBenchmark.testRotateRightB | 512 | 15 | 512 | 3909.845 | 3976.813 | 1.017128045
>> RotateBenchmark.testRotateRightB | 512 | 31 | 256 | 7746.765 | 7870.159 | 1.015928455
>> RotateBenchmark.testRotateRightB | 512 | 31 | 512 | 3919.596 | 3981.934 | 1.01590419
>> RotateBenchmark.testRotateRightI | 128 | 7 | 256 | 4125.151 | 13056.878 | 3.165187893
>> RotateBenchmark.testRotateRightI | 128 | 7 | 512 | 2045.201 | 6501.447 | 3.17887924
>> RotateBenchmark.testRotateRightI | 128 | 15 | 256 | 4111.736 | 13318.124 | 3.23905134
>> RotateBenchmark.testRotateRightI | 128 | 15 | 512 | 2055.355 | 6497.289 | 3.161151723
>> RotateBenchmark.testRotateRightI | 128 | 31 | 256 | 4109.353 | 13073.3 | 3.181352393
>> RotateBenchmark.testRotateRightI | 128 | 31 | 512 | 2055.431 | 6463.902 | 3.14479153
>> RotateBenchmark.testRotateRightI | 256 | 7 | 256 | 7804.976 | 24585.962 | 3.150036848
>> RotateBenchmark.testRotateRightI | 256 | 7 | 512 | 3815.818 | 11985.145 | 3.140911071
>> RotateBenchmark.testRotateRightI | 256 | 15 | 256 | 7644.977 | 25863.841 | 3.383115606
>> RotateBenchmark.testRotateRightI | 256 | 15 | 512 | 3822.508 | 12280.58 | 3.212702236
>> RotateBenchmark.testRotateRightI | 256 | 31 | 256 | 7709.635 | 25655.108 | 3.327668301
>> RotateBenchmark.testRotateRightI | 256 | 31 | 512 | 3801.5 | 12271.65 | 3.228107326
>> RotateBenchmark.testRotateRightI | 512 | 7 | 256 | 12223.711 | 31239.788 | 2.555671351
>> RotateBenchmark.testRotateRightI | 512 | 7 | 512 | 5973.571 | 16740.852 | 2.802486486
>> RotateBenchmark.testRotateRightI | 512 | 15 | 256 | 12205.47 | 31248.025 | 2.560165647
>> RotateBenchmark.testRotateRightI | 512 | 15 | 512 | 5966.513 | 15728.168 | 2.6360737
>> RotateBenchmark.testRotateRightI | 512 | 31 | 256 | 12209.405 | 33181.105 | 2.71766765
>> RotateBenchmark.testRotateRightI | 512 | 31 | 512 | 5981.527 | 15727.496 | 2.629344647
>> RotateBenchmark.testRotateRightL | 128 | 7 | 256 | 2054.509 | 6980.849 | 3.397818652
>> RotateBenchmark.testRotateRightL | 128 | 7 | 512 | 997.375 | 3242.374 | 3.250907633
>> RotateBenchmark.testRotateRightL | 128 | 15 | 256 | 2051.459 | 6892.389 | 3.359749817
>> RotateBenchmark.testRotateRightL | 128 | 15 | 512 | 1002.906 | 3223.342 | 3.21400211
>> RotateBenchmark.testRotateRightL | 128 | 31 | 256 | 2044.749 | 6984.157 | 3.415654929
>> RotateBenchmark.testRotateRightL | 128 | 31 | 512 | 1004.273 | 3237.496 | 3.22372104
>> RotateBenchmark.testRotateRightL | 256 | 7 | 256 | 3811.551 | 13347.75 | 3.501920872
>> RotateBenchmark.testRotateRightL | 256 | 7 | 512 | 1892.883 | 5840.85 | 3.085689924
>> RotateBenchmark.testRotateRightL | 256 | 15 | 256 | 3821.705 | 14034.823 | 3.672398314
>> RotateBenchmark.testRotateRightL | 256 | 15 | 512 | 1799.193 | 5817.533 | 3.233412424
>> RotateBenchmark.testRotateRightL | 256 | 31 | 256 | 3816.666 | 14022.31 | 3.673968327
>> RotateBenchmark.testRotateRightL | 256 | 31 | 512 | 1796.649 | 5824.13 | 3.241662673
>> RotateBenchmark.testRotateRightL | 512 | 7 | 256 | 5943.986 | 15586.254 | 2.622188881
>> RotateBenchmark.testRotateRightL | 512 | 7 | 512 | 3022.686 | 7662.241 | 2.534911334
>> RotateBenchmark.testRotateRightL | 512 | 15 | 256 | 5958.008 | 15726.859 | 2.639616966
>> RotateBenchmark.testRotateRightL | 512 | 15 | 512 | 2998.469 | 7654.703 | 2.552870482
>> RotateBenchmark.testRotateRightL | 512 | 31 | 256 | 5937.491 | 15741.207 | 2.651154671
>> RotateBenchmark.testRotateRightL | 512 | 31 | 512 | 3014.699 | 7656.837 | 2.539834657
>> RotateBenchmark.testRotateRightS | 128 | 7 | 256 | 8172.896 | 8003.474 | 0.979270261
>> RotateBenchmark.testRotateRightS | 128 | 7 | 512 | 4111.074 | 4047.267 | 0.984479238
>> RotateBenchmark.testRotateRightS | 128 | 15 | 256 | 8225.79 | 8040.421 | 0.9774649
>> RotateBenchmark.testRotateRightS | 128 | 15 | 512 | 4129.801 | 4011.919 | 0.971455767
>> RotateBenchmark.testRotateRightS | 128 | 31 | 256 | 8176.102 | 8052.686 | 0.984905276
>> RotateBenchmark.testRotateRightS | 128 | 31 | 512 | 4117.735 | 4046.522 | 0.982705784
>> RotateBenchmark.testRotateRightS | 256 | 7 | 256 | 15213.617 | 15169.51 | 0.997100821
>> RotateBenchmark.testRotateRightS | 256 | 7 | 512 | 7530.289 | 7625.581 | 1.012654494
>> RotateBenchmark.testRotateRightS | 256 | 15 | 256 | 15238.384 | 15069.978 | 0.988948566
>> RotateBenchmark.testRotateRightS | 256 | 15 | 512 | 7275.098 | 7620.764 | 1.047513587
>> RotateBenchmark.testRotateRightS | 256 | 31 | 256 | 15299.821 | 15043.765 | 0.983264118
>> RotateBenchmark.testRotateRightS | 256 | 31 | 512 | 7273.028 | 7630.97 | 1.04921499
>> RotateBenchmark.testRotateRightS | 512 | 7 | 256 | 23998.152 | 23920.046 | 0.996745333
>> RotateBenchmark.testRotateRightS | 512 | 7 | 512 | 11582.679 | 11916.382 | 1.02881052
>> RotateBenchmark.testRotateRightS | 512 | 15 | 256 | 23982.797 | 23434.756 | 0.977148579
>> RotateBenchmark.testRotateRightS | 512 | 15 | 512 | 11629.806 | 11918.759 | 1.0248459
>> RotateBenchmark.testRotateRightS | 512 | 31 | 256 | 23988.549 | 23475.629 | 0.978618132
>> RotateBenchmark.testRotateRightS | 512 | 31 | 512 | 11650.146 | 11916.47 | 1.022860143
>> 
>> 
>> 
>> </body>
>> 
>> </html>
>
> Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits:
> 
>  - 8266054: Re-designing benchmark to remove noise.
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8266054
>  - 8266054: Formal argument name change to be more appropriate.
>  - 8266054: Review comments resolution.
>  - 8266054: Incorporating styling changes based on reviews.
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8266054
>  - Merge http://github.com/openjdk/jdk into JDK-8266054
>  - Merge http://github.com/openjdk/jdk into JDK-8266054
>  - Merge http://github.com/openjdk/jdk into JDK-8266054
>  - Merge branch 'JDK-8266054' of http://github.com/jatin-bhateja/jdk into JDK-8266054
>  - ... and 9 more: https://git.openjdk.java.net/jdk/compare/a8f15427...b20404e2

No comma after "2021" in `test/micro/org/openjdk/bench/jdk/incubator/vector/RotateBenchmark.java`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3720

From kvn at openjdk.java.net  Wed Jul 28 04:51:38 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 28 Jul 2021 04:51:38 GMT
Subject: RFR: 8266054: VectorAPI rotate operation optimization [v13]
In-Reply-To: <FQQA8lfkU4CkF4wZ1PczK-ZqtZn1v5BkKqTVIPveCf0=.ac405b11-ea1e-4b98-9b07-c626fc3ad2cf@github.com>
References: <OZ2u4DDNaYF3WiR5uU6NWvzPMKV3j8QAO_mZyLP3Isg=.594e3514-8a5a-442c-ac1a-ca6c6d14e963@github.com>
 <HU2E5YuCI7Iz38CNycxu62RVNsyyT9unlr79-fSwFVg=.fde03b0d-6f8f-445f-88e4-84511f50226b@github.com>
 <FQQA8lfkU4CkF4wZ1PczK-ZqtZn1v5BkKqTVIPveCf0=.ac405b11-ea1e-4b98-9b07-c626fc3ad2cf@github.com>
Message-ID: <yAIhiSCrVlfq0uznc-Hcb6IsMbnTnbGnL0k3RnULnAo=.38bb6473-27fd-4508-aaa6-37f066f25bdb@github.com>

On Tue, 27 Jul 2021 18:31:20 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits:
>> 
>>  - 8266054: Re-designing benchmark to remove noise.
>>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8266054
>>  - 8266054: Formal argument name change to be more appropriate.
>>  - 8266054: Review comments resolution.
>>  - 8266054: Incorporating styling changes based on reviews.
>>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8266054
>>  - Merge http://github.com/openjdk/jdk into JDK-8266054
>>  - Merge http://github.com/openjdk/jdk into JDK-8266054
>>  - Merge http://github.com/openjdk/jdk into JDK-8266054
>>  - Merge branch 'JDK-8266054' of http://github.com/jatin-bhateja/jdk into JDK-8266054
>>  - ... and 9 more: https://git.openjdk.java.net/jdk/compare/a8f15427...b20404e2
>
> Looks good to me.

@sviswa7 and @jatin-bhateja jatin-bhateja
The push caused https://bugs.openjdk.java.net/browse/JDK-8271366
I am strongly suggest in a future to ask an Oracle's engineer to test Intel's changes before pushing.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3720

From dholmes at openjdk.java.net  Wed Jul 28 05:48:45 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 28 Jul 2021 05:48:45 GMT
Subject: RFR: 8271368: [BACKOUT] JDK-8266054 VectorAPI rotate operation
 optimization
In-Reply-To: <3CmpsfEtgNRMlwhC0L2QmMFmKL_umQ95A_cT65DGVBs=.21a0fea3-9a65-41d9-86e1-ef0827c105ee@github.com>
References: <3CmpsfEtgNRMlwhC0L2QmMFmKL_umQ95A_cT65DGVBs=.21a0fea3-9a65-41d9-86e1-ef0827c105ee@github.com>
Message-ID: <qQsi9YOzP2eEFgHnQOQaWgSe9tY3zHXGG9V4jD4jgIQ=.b6136183-4907-48f6-835c-b4366556cb81@github.com>

On Wed, 28 Jul 2021 05:35:59 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Backout the following changes due to vector tests failures in tier 2 and later: 
> [JDK-8266054](https://bugs.openjdk.java.net/browse/JDK-8266054) VectorAPI rotate operation optimization 
> 
> Changes also caused copyright header validation failure in Tier1 due to missing `,` after copyright year in new test.
> 
> Currently running testing.

Backout looks good.

Thanks,
David

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4915

From kvn at openjdk.java.net  Wed Jul 28 05:48:45 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 28 Jul 2021 05:48:45 GMT
Subject: RFR: 8271368: [BACKOUT] JDK-8266054 VectorAPI rotate operation
 optimization
Message-ID: <3CmpsfEtgNRMlwhC0L2QmMFmKL_umQ95A_cT65DGVBs=.21a0fea3-9a65-41d9-86e1-ef0827c105ee@github.com>

Backout the following changes due to vector tests failures in tier 2 and later: 
[JDK-8266054](https://bugs.openjdk.java.net/browse/JDK-8266054) VectorAPI rotate operation optimization 

Changes also caused copyright header validation failure in Tier1 due to missing `,` after copyright year in new test.

Currently running testing.

-------------

Commit messages:
 - 8271368: [BACKOUT] JDK-8266054 VectorAPI rotate operation optimization

Changes: https://git.openjdk.java.net/jdk/pull/4915/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4915&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8271368
  Stats: 4438 lines in 57 files changed: 58 ins; 4219 del; 161 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4915.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4915/head:pull/4915

PR: https://git.openjdk.java.net/jdk/pull/4915

From iklam at openjdk.java.net  Wed Jul 28 06:08:33 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Wed, 28 Jul 2021 06:08:33 GMT
Subject: RFR: 8271368: [BACKOUT] JDK-8266054 VectorAPI rotate operation
 optimization
In-Reply-To: <3CmpsfEtgNRMlwhC0L2QmMFmKL_umQ95A_cT65DGVBs=.21a0fea3-9a65-41d9-86e1-ef0827c105ee@github.com>
References: <3CmpsfEtgNRMlwhC0L2QmMFmKL_umQ95A_cT65DGVBs=.21a0fea3-9a65-41d9-86e1-ef0827c105ee@github.com>
Message-ID: <S69HzInP3P2qQb6LXJnYgbnsCsvm-AVUsCGbJkNLicM=.43d04c00-3819-41ef-82d7-fa084ecab6cd@github.com>

On Wed, 28 Jul 2021 05:35:59 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Backout the following changes due to vector tests failures in tier 2 and later: 
> [JDK-8266054](https://bugs.openjdk.java.net/browse/JDK-8266054) VectorAPI rotate operation optimization 
> 
> Changes also caused copyright header validation failure in Tier1 due to missing `,` after copyright year in new test.
> 
> Currently running testing.

LGTM

-------------

Marked as reviewed by iklam (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4915

From jbhateja at openjdk.java.net  Wed Jul 28 06:27:27 2021
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Wed, 28 Jul 2021 06:27:27 GMT
Subject: RFR: 8271368: [BACKOUT] JDK-8266054 VectorAPI rotate operation
 optimization
In-Reply-To: <3CmpsfEtgNRMlwhC0L2QmMFmKL_umQ95A_cT65DGVBs=.21a0fea3-9a65-41d9-86e1-ef0827c105ee@github.com>
References: <3CmpsfEtgNRMlwhC0L2QmMFmKL_umQ95A_cT65DGVBs=.21a0fea3-9a65-41d9-86e1-ef0827c105ee@github.com>
Message-ID: <fR_RkB3sikFRoxeRsqF1HzV-k20Qyd6HpYW-PHUOxjw=.5411b35c-0047-4892-9e01-14d989d523e0@github.com>

On Wed, 28 Jul 2021 05:35:59 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Backout the following changes due to vector tests failures in tier 2 and later: 
> [JDK-8266054](https://bugs.openjdk.java.net/browse/JDK-8266054) VectorAPI rotate operation optimization 
> 
> Changes also caused copyright header validation failure in Tier1 due to missing `,` after copyright year in new test.
> 
> Currently running testing.

- Thanks for reporting it, should it be ok to move those tests to ProblemList.txt and let me fix this as a follow up issue instead of a revert ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4915

From kvn at openjdk.java.net  Wed Jul 28 07:01:34 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 28 Jul 2021 07:01:34 GMT
Subject: Integrated: 8271368: [BACKOUT] JDK-8266054 VectorAPI rotate operation
 optimization
In-Reply-To: <3CmpsfEtgNRMlwhC0L2QmMFmKL_umQ95A_cT65DGVBs=.21a0fea3-9a65-41d9-86e1-ef0827c105ee@github.com>
References: <3CmpsfEtgNRMlwhC0L2QmMFmKL_umQ95A_cT65DGVBs=.21a0fea3-9a65-41d9-86e1-ef0827c105ee@github.com>
Message-ID: <ANZnQnLDnjY4D-O30qYUK4hu_YZMyFtxST5qv5s3zw4=.78cbf5a2-1160-40df-aeb6-7c6e99804e55@github.com>

On Wed, 28 Jul 2021 05:35:59 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Backout the following changes due to vector tests failures in tier 2 and later: 
> [JDK-8266054](https://bugs.openjdk.java.net/browse/JDK-8266054) VectorAPI rotate operation optimization 
> 
> Changes also caused copyright header validation failure in Tier1 due to missing `,` after copyright year in new test.
> 
> Currently running testing.

This pull request has now been integrated.

Changeset: d7b5cb68
Author:    Vladimir Kozlov <kvn at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d7b5cb688956ce79443ef3cd080c36028fcfb19d
Stats:     4438 lines in 57 files changed: 58 ins; 4219 del; 161 mod

8271368: [BACKOUT] JDK-8266054 VectorAPI rotate operation optimization

Reviewed-by: dholmes, iklam

-------------

PR: https://git.openjdk.java.net/jdk/pull/4915

From kvn at openjdk.java.net  Wed Jul 28 07:07:31 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 28 Jul 2021 07:07:31 GMT
Subject: RFR: 8271368: [BACKOUT] JDK-8266054 VectorAPI rotate operation
 optimization
In-Reply-To: <fR_RkB3sikFRoxeRsqF1HzV-k20Qyd6HpYW-PHUOxjw=.5411b35c-0047-4892-9e01-14d989d523e0@github.com>
References: <3CmpsfEtgNRMlwhC0L2QmMFmKL_umQ95A_cT65DGVBs=.21a0fea3-9a65-41d9-86e1-ef0827c105ee@github.com>
 <fR_RkB3sikFRoxeRsqF1HzV-k20Qyd6HpYW-PHUOxjw=.5411b35c-0047-4892-9e01-14d989d523e0@github.com>
Message-ID: <Ng1UhU14PwD8x51wXeFSKq2OQaNCPNKCJiiG41LJffo=.6c2e1ad8-7407-44dd-9ff6-25eaf332515f@github.com>

On Wed, 28 Jul 2021 06:24:20 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> * Thanks for reporting it, should it be ok to move those tests to ProblemList.txt and let me fix this as a follow up issue instead of a revert ?

@jatin-bhateja We did not test original changes in our testing infra. There could be other issues in high tiers which we don't know.
I prefer that you use 8271366 to prepare changes with fixed reported failure, file PR and let me run testing.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4915

From wuyan at openjdk.java.net  Wed Jul 28 07:53:27 2021
From: wuyan at openjdk.java.net (Wu Yan)
Date: Wed, 28 Jul 2021 07:53:27 GMT
Subject: RFR: 8268231: Aarch64: Use ldp in intrinsics for String.compareTo
 [v2]
In-Reply-To: <Lek9D7969HKQkO_NK5FQsog9Nz2WxJVyDe3hkKwJBAs=.e473bc04-7633-4047-af95-675aa452a69d@github.com>
References: <XwW4MjGSYmSHa2ZbzrOfvoZi1pe8LJAK7YIKtmNhaDM=.d39df32e-8698-4608-9184-3b19cd175d1a@github.com>
 <4E6St8xE9eEeKfntwFWka1oBRy7IuAjXW8iA1h8GuqA=.5be4869c-a286-4dfd-a0fb-fcb10e75f921@github.com>
 <Lek9D7969HKQkO_NK5FQsog9Nz2WxJVyDe3hkKwJBAs=.e473bc04-7633-4047-af95-675aa452a69d@github.com>
Message-ID: <hbFn6rMkOU0p9x4mJAuFskTu8RwfIDfQaVmOAcu_w8w=.346c3b01-0433-41c0-a587-6df1b1bb7613@github.com>

On Mon, 12 Jul 2021 15:36:29 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Wang Huang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   draft of refactor
>
> And with longer strings, M1 and ThunderX2:
> 
> 
> Benchmark                                       (diff_pos)  (size)  Mode  Cnt   Score   Error  Units
> StringCompare.compareLLDiffStrings                    1023    1024  avgt    3  50.849 ? 0.087  us/op
> StringCompare.compareLLDiffStringsWithLdp             1023    1024  avgt    3  23.676 ? 0.015  us/op
> StringCompare.compareLLDiffStringsWithRefactor        1023    1024  avgt    3  28.967 ? 0.168  us/op
> 
> 
> StringCompare.compareLLDiffStrings                    1023    1024  avgt    3  98.681 ? 0.026  us/op
> StringCompare.compareLLDiffStringsWithLdp             1023    1024  avgt    3  82.576 ? 0.656  us/op
> StringCompare.compareLLDiffStringsWithRefactor        1023    1024  avgt    3  98.801 ? 0.321  us/op
> 
> LDP wins on M1 here, but on ThunderX2 it makes almost no difference at all. And how often are we comparing such long strings?
> I don't know what to think, really. It seems that we're near to a place where we're optimizing for micro-architecture, and I don't want to see that here. On the other hand, using LDP is not worse anywhere, so we should allow it.

Could you do me a favor to review the patch? @theRealAph @nick-arm Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4722

From ngasson at openjdk.java.net  Wed Jul 28 08:28:34 2021
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Wed, 28 Jul 2021 08:28:34 GMT
Subject: RFR: 8268231: Aarch64: Use ldp in intrinsics for String.compareTo
 [v4]
In-Reply-To: <F6md9mVnN7YiAwVrRTrLGaRVOGJp2PRCBUpaDRm__j4=.9a428b99-30d9-4c76-823a-19412c282ceb@github.com>
References: <XwW4MjGSYmSHa2ZbzrOfvoZi1pe8LJAK7YIKtmNhaDM=.d39df32e-8698-4608-9184-3b19cd175d1a@github.com>
 <F6md9mVnN7YiAwVrRTrLGaRVOGJp2PRCBUpaDRm__j4=.9a428b99-30d9-4c76-823a-19412c282ceb@github.com>
Message-ID: <CrjCx-SVcCpKtpnITLE1oinQGJky0PtbwoRx7I6qK1E=.a30e021b-5f1a-462e-a074-ab956d2ab991@github.com>

On Thu, 15 Jul 2021 03:30:46 GMT, Wang Huang <whuang at openjdk.org> wrote:

>> Dear all, 
>>     Can you do me a favor to review this patch. This patch use `ldp` to implement String.compareTo.
>>    
>> * We add a JMH test case 
>> * Here is the result of this test case
>>  
>> Benchmark	                       |(size)| Mode| Cnt|Score | Error	 |Units	
>> ---------------------------------|------|-----|----|------|--------|-----
>> StringCompare.compareLL       |  64  | avgt| 5  |7.992 | ?	0.005|us/op
>> StringCompare.compareLL       |  72  | avgt| 5  |15.029| ?	0.006|us/op
>> StringCompare.compareLL       |  80  | avgt| 5  |14.655| ?	0.011|us/op
>> StringCompare.compareLL       |  91  | avgt| 5  |16.363| ?	0.12 |us/op
>> StringCompare.compareLL       |  101 | avgt| 5  |16.966| ?	0.007|us/op
>> StringCompare.compareLL       |  121 | avgt| 5  |19.276| ?	0.006|us/op
>> StringCompare.compareLL       |  181 | avgt| 5  |19.002| ?	0.417|us/op
>> StringCompare.compareLL       |  256 | avgt| 5  |24.707| ?	0.041|us/op
>> StringCompare.compareLLWithLdp|  64  | avgt| 5  |8.001	| ?	0.121|us/op
>> StringCompare.compareLLWithLdp|  72  | avgt| 5  |11.573| ?	0.003|us/op
>> StringCompare.compareLLWithLdp|  80  | avgt| 5  |6.861 | ?	0.004|us/op
>> StringCompare.compareLLWithLdp|  91  | avgt| 5  |12.774| ?	0.201|us/op
>> StringCompare.compareLLWithLdp|  101 | avgt| 5  |8.691 | ?	0.004|us/op
>> StringCompare.compareLLWithLdp|  121 | avgt| 5  |11.091| ?	1.342|us/op
>> StringCompare.compareLLWithLdp|  181 | avgt| 5  |14.64 | ?	0.581|us/op
>> StringCompare.compareLLWithLdp|  256 | avgt| 5  |25.879| ?	1.775|us/op
>> StringCompare.compareUU       |  64  | avgt| 5  |13.476| ?	0.01 |us/op
>> StringCompare.compareUU       |  72  | avgt| 5  |15.078| ?	0.006|us/op
>> StringCompare.compareUU       |  80  | avgt| 5  |23.512| ?	0.011|us/op
>> StringCompare.compareUU       |  91  | avgt| 5  |24.284| ?	0.008|us/op
>> StringCompare.compareUU       |  101 | avgt| 5  |20.707| ?	0.017|us/op
>> StringCompare.compareUU       |  121 | avgt| 5  |29.302| ?	0.011|us/op
>> StringCompare.compareUU       |  181 | avgt| 5  |39.31	| ?	0.016|us/op
>> StringCompare.compareUU       |  256 | avgt| 5  |54.592| ?	0.392|us/op
>> StringCompare.compareUUWithLdp|  64  | avgt| 5  |16.389| ?	0.008|us/op
>> StringCompare.compareUUWithLdp|  72  | avgt| 5  |10.71 | ?	0.158|us/op
>> StringCompare.compareUUWithLdp|  80  | avgt| 5  |11.488| ?	0.024|us/op
>> StringCompare.compareUUWithLdp|  91  | avgt| 5  |13.412| ?	0.006|us/op
>> StringCompare.compareUUWithLdp|  101 | avgt| 5  |16.245| ?	0.434|us/op
>> StringCompare.compareUUWithLdp|  121 | avgt| 5  |16.597| ?	0.016|us/op
>> StringCompare.compareUUWithLdp|  181 | avgt| 5  |27.373| ?	0.017|us/op
>> StringCompare.compareUUWithLdp|  256 | avgt| 5  |41.74 | ?	3.5	 |us/op
>> 
>> From this table, we can see that in most cases, our patch is better than old one.
>> 
>> Thank you for your review. Any suggestions are welcome.
>
> Wang Huang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix style and add unalign test case

I don't think we want to keep two copies of the compareTo intrinsic. If there are no cases where the LDP version is worse than the original version then we should just delete the old one and replace it with this.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4722

From aph at openjdk.java.net  Wed Jul 28 08:54:30 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Wed, 28 Jul 2021 08:54:30 GMT
Subject: RFR: 8268231: Aarch64: Use ldp in intrinsics for String.compareTo
 [v4]
In-Reply-To: <CrjCx-SVcCpKtpnITLE1oinQGJky0PtbwoRx7I6qK1E=.a30e021b-5f1a-462e-a074-ab956d2ab991@github.com>
References: <XwW4MjGSYmSHa2ZbzrOfvoZi1pe8LJAK7YIKtmNhaDM=.d39df32e-8698-4608-9184-3b19cd175d1a@github.com>
 <F6md9mVnN7YiAwVrRTrLGaRVOGJp2PRCBUpaDRm__j4=.9a428b99-30d9-4c76-823a-19412c282ceb@github.com>
 <CrjCx-SVcCpKtpnITLE1oinQGJky0PtbwoRx7I6qK1E=.a30e021b-5f1a-462e-a074-ab956d2ab991@github.com>
Message-ID: <JIBFjcKsGGCiaHpLZ1lJkZI8059Ku1I3MJL8pvxUNEE=.35526bb2-c835-48b4-8388-56e390dee166@github.com>

On Wed, 28 Jul 2021 08:25:08 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

> I don't think we want to keep two copies of the compareTo intrinsic. If there are no cases where the LDP version is worse than the original version then we should just delete the old one and replace it with this.

I agree. The trouble is, what does "worse" mean? I'm looking at SDEN-1982442, Neoverse N2 errata, 2001293, and I see that LDP has to be slowed down on streaming workloads, which will affect this.

The trouble with this patch is that it (probably) makes things better for long strings, which are very rare. What we actually need to care about is performance for a large number of typical-sized strings, which are names, identifiers, passwords, and so on: about 10-30 characters.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4722

From wuyan at openjdk.java.net  Wed Jul 28 09:32:31 2021
From: wuyan at openjdk.java.net (Wu Yan)
Date: Wed, 28 Jul 2021 09:32:31 GMT
Subject: RFR: 8268231: Aarch64: Use ldp in intrinsics for String.compareTo
 [v4]
In-Reply-To: <JIBFjcKsGGCiaHpLZ1lJkZI8059Ku1I3MJL8pvxUNEE=.35526bb2-c835-48b4-8388-56e390dee166@github.com>
References: <XwW4MjGSYmSHa2ZbzrOfvoZi1pe8LJAK7YIKtmNhaDM=.d39df32e-8698-4608-9184-3b19cd175d1a@github.com>
 <F6md9mVnN7YiAwVrRTrLGaRVOGJp2PRCBUpaDRm__j4=.9a428b99-30d9-4c76-823a-19412c282ceb@github.com>
 <CrjCx-SVcCpKtpnITLE1oinQGJky0PtbwoRx7I6qK1E=.a30e021b-5f1a-462e-a074-ab956d2ab991@github.com>
 <JIBFjcKsGGCiaHpLZ1lJkZI8059Ku1I3MJL8pvxUNEE=.35526bb2-c835-48b4-8388-56e390dee166@github.com>
Message-ID: <KAZ0GJbUUPYV7jkRjD5vNxF5jTLnwZeYNRZyykE8qZc=.70df7d47-f4d9-494a-9d09-6509d8af72ea@github.com>

On Wed, 28 Jul 2021 08:51:38 GMT, Andrew Haley <aph at openjdk.org> wrote:

> The trouble is, what does "worse" mean? I'm looking at SDEN-1982442, Neoverse N2 errata, 2001293, and I see that LDP has to be slowed down on streaming workloads, which will affect this. (That's just an example: I'm making the point that implementations differ.)

We are testing on HiSilicon TSV110, maybe we can enable this optimization by default on the verified platforms.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4722

From ngasson at openjdk.java.net  Wed Jul 28 09:58:32 2021
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Wed, 28 Jul 2021 09:58:32 GMT
Subject: RFR: 8268231: Aarch64: Use ldp in intrinsics for String.compareTo
 [v4]
In-Reply-To: <KAZ0GJbUUPYV7jkRjD5vNxF5jTLnwZeYNRZyykE8qZc=.70df7d47-f4d9-494a-9d09-6509d8af72ea@github.com>
References: <XwW4MjGSYmSHa2ZbzrOfvoZi1pe8LJAK7YIKtmNhaDM=.d39df32e-8698-4608-9184-3b19cd175d1a@github.com>
 <F6md9mVnN7YiAwVrRTrLGaRVOGJp2PRCBUpaDRm__j4=.9a428b99-30d9-4c76-823a-19412c282ceb@github.com>
 <CrjCx-SVcCpKtpnITLE1oinQGJky0PtbwoRx7I6qK1E=.a30e021b-5f1a-462e-a074-ab956d2ab991@github.com>
 <JIBFjcKsGGCiaHpLZ1lJkZI8059Ku1I3MJL8pvxUNEE=.35526bb2-c835-48b4-8388-56e390dee166@github.com>
 <KAZ0GJbUUPYV7jkRjD5vNxF5jTLnwZeYNRZyykE8qZc=.70df7d47-f4d9-494a-9d09-6509d8af72ea@github.com>
Message-ID: <nkmR6oTY7W1zdp5DA6diMPtcZwC0tRiLYvIcttPsbA8=.32292edb-96a8-44e1-b00f-881ad796440e@github.com>

On Wed, 28 Jul 2021 09:29:25 GMT, Wu Yan <wuyan at openjdk.org> wrote:

> 
> We are testing on HiSilicon TSV110, maybe we can enable this optimization by default on the verified platforms.

We don't really want to have different implementations for each microarchitecture, that would be a testing nightmare. 

The existing stub uses prefetch instructions if `SoftwarePrefetchHintDistance >= 0` but the new LDP version doesn't. Did you find there's no benefit to that? Adding prefetches was one of the reasons to introduce the separate stub for long strings, see the mail below:

https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2018-April/028888.html

It seems the existing code was tuned for Thunder X/X2 so perhaps that's why Andrew sees little improvement there with the new version.

What testing have you done besides benchmarking? The patch linked above had at least two subtle bugs in corner cases.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4722

From psandoz at openjdk.java.net  Wed Jul 28 15:14:43 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Wed, 28 Jul 2021 15:14:43 GMT
Subject: RFR: 8266054: VectorAPI rotate operation optimization [v13]
In-Reply-To: <FQQA8lfkU4CkF4wZ1PczK-ZqtZn1v5BkKqTVIPveCf0=.ac405b11-ea1e-4b98-9b07-c626fc3ad2cf@github.com>
References: <OZ2u4DDNaYF3WiR5uU6NWvzPMKV3j8QAO_mZyLP3Isg=.594e3514-8a5a-442c-ac1a-ca6c6d14e963@github.com>
 <HU2E5YuCI7Iz38CNycxu62RVNsyyT9unlr79-fSwFVg=.fde03b0d-6f8f-445f-88e4-84511f50226b@github.com>
 <FQQA8lfkU4CkF4wZ1PczK-ZqtZn1v5BkKqTVIPveCf0=.ac405b11-ea1e-4b98-9b07-c626fc3ad2cf@github.com>
Message-ID: <Mx-cBpu6TgCE8xB8rGcdFHVQh6C2wjaFWyY06i8-BFI=.febe5016-0df7-4d8f-b96b-2e1543da10a9@github.com>

On Tue, 27 Jul 2021 18:31:20 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits:
>> 
>>  - 8266054: Re-designing benchmark to remove noise.
>>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8266054
>>  - 8266054: Formal argument name change to be more appropriate.
>>  - 8266054: Review comments resolution.
>>  - 8266054: Incorporating styling changes based on reviews.
>>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8266054
>>  - Merge http://github.com/openjdk/jdk into JDK-8266054
>>  - Merge http://github.com/openjdk/jdk into JDK-8266054
>>  - Merge http://github.com/openjdk/jdk into JDK-8266054
>>  - Merge branch 'JDK-8266054' of http://github.com/jatin-bhateja/jdk into JDK-8266054
>>  - ... and 9 more: https://git.openjdk.java.net/jdk/compare/a8f15427...b20404e2
>
> Looks good to me.

> @sviswa7 and @jatin-bhateja jatin-bhateja
> The push caused https://bugs.openjdk.java.net/browse/JDK-8271366
> I am strongly suggest in a future to ask an Oracle's engineer to test Intel's changes before pushing.

Yes, as discussed before please request that we perform internal tests before integrating e.g. CC me. Unfortunately the pre-commit PR tests don't cover all the tests cases and we don't yet have a way to expand that set.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3720

From daniel.peintner at gmail.com  Wed Jul 28 15:27:20 2021
From: daniel.peintner at gmail.com (Daniel Peintner)
Date: Wed, 28 Jul 2021 17:27:20 +0200
Subject: jpackage MacOS Notarization
Message-ID: <CAAoP7T5tO86Lt+WbwGv5iLuFcNRNgxsyCLaynQpUcAEkeqW-Zg@mail.gmail.com>

All,

I am trying to notarize an app (built with jpackage) for MacOS.

jpackage at first *seems* to properly sign all resources with the available
--mac-sign options et cetera.

Having said that, there are still remaining issues
1. The app cannot be properly installed
   (without hacks like xattr -d com.apple.quarantine /Applications/myAPP.app
).
2. I am also not able to properly notarize the app.

According to online resources there seem to exist issues in *past* about
notarization but according to [1, 2] the issues are fixed.

As mentioned, I still have issues :-(
Am I really the only one still having problems?

Java Version: AdoptOpenJDK-16.0.1+9 (tried Oracle JDK also without success)

The issue seems to boil down to 2 errors (attached the error log from Apple
notarization process).
* app Folder
* libjli.dylib

I thought I better ask first on the mailing list before creating an actual
bug report.

Note1: I used to use the *old* javapackager that worked with the same
signature/credentials.
Note2: running jpackage without --mac-sign options causes many more errors
in notarization (Hence, jpackage signs most resources but fails with some)

Any help / hint appreciated.

Thanks,

-- Daniel

[1] https://bugs.openjdk.java.net/browse/JDK-8257488
[2] https://bugs.openjdk.java.net/browse/JDK-8251892



## APPLE LOG ##

{
  "logFormatVersion": 1,
  "jobId": "...",
  "status": "Invalid",
  "statusSummary": "Archive contains critical validation errors",
  "statusCode": 4000,
  "archiveFilename": "myAPP-21.07.28.dmg",
  "uploadDate": "2021-07-28T14:31:24Z",
  "sha256": "...",
  "ticketContents": null,
  "issues": [
    {
      "severity": "error",
      "code": null,
      "path": "myAPP-21.07.28.dmg/myAPP.app/Contents/MacOS/myAPP",
      "message": "The signature of the binary is invalid.",
      "docUrl": null,
      "architecture": "x86_64"
    },
    {
      "severity": "error",
      "code": null,
      "path": "myAPP-21.07.28.dmg/myAPP.app/Contents/runtime/Contents/MacOS/libjli.dylib",
      "message": "The signature of the binary is invalid.",
      "docUrl": null,
      "architecture": "x86_64"
    }
  ]
}

From github.com+54304+ebourg at openjdk.java.net  Wed Jul 28 15:39:47 2021
From: github.com+54304+ebourg at openjdk.java.net (Emmanuel Bourg)
Date: Wed, 28 Jul 2021 15:39:47 GMT
Subject: RFR: 8271396: Spelling errors
Message-ID: <U-l1fZ9G8ctKEjq6IdJJBGXJzJJeI4JUjaemwOzhdHo=.1e30f73c-cf88-4394-b59f-98aa5664c9db@github.com>

This PR fixes the following spelling errors:

 choosen  -> chosen
 commad   -> command
 hiearchy -> hierarchy
 leagacy  -> legacy
 minium   -> minimum
 subsytem -> subsystem
 unamed   -> unnamed

-------------

Commit messages:
 - 8271396: Fix spelling errors

Changes: https://git.openjdk.java.net/jdk/pull/2385/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2385&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8271396
  Stats: 78 lines in 34 files changed: 0 ins; 0 del; 78 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2385.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2385/head:pull/2385

PR: https://git.openjdk.java.net/jdk/pull/2385

From tschatzl at openjdk.java.net  Wed Jul 28 15:39:47 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 28 Jul 2021 15:39:47 GMT
Subject: RFR: 8271396: Spelling errors
In-Reply-To: <U-l1fZ9G8ctKEjq6IdJJBGXJzJJeI4JUjaemwOzhdHo=.1e30f73c-cf88-4394-b59f-98aa5664c9db@github.com>
References: <U-l1fZ9G8ctKEjq6IdJJBGXJzJJeI4JUjaemwOzhdHo=.1e30f73c-cf88-4394-b59f-98aa5664c9db@github.com>
Message-ID: <qaXW0F5RvHQkbBOCClYDaM8g9-AwsGvhfPZT1ALfL8I=.eefdf486-3f44-42bf-a004-c379b6b3c666@github.com>

On Wed, 3 Feb 2021 19:12:25 GMT, Emmanuel Bourg <github.com+54304+ebourg at openjdk.org> wrote:

> This PR fixes the following spelling errors:
> 
>  choosen  -> chosen
>  commad   -> command
>  hiearchy -> hierarchy
>  leagacy  -> legacy
>  minium   -> minimum
>  subsytem -> subsystem
>  unamed   -> unnamed

Lgtm.

-------------

Marked as reviewed by tschatzl (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2385

From chegar at openjdk.java.net  Wed Jul 28 15:39:48 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Wed, 28 Jul 2021 15:39:48 GMT
Subject: RFR: 8271396: Spelling errors
In-Reply-To: <U-l1fZ9G8ctKEjq6IdJJBGXJzJJeI4JUjaemwOzhdHo=.1e30f73c-cf88-4394-b59f-98aa5664c9db@github.com>
References: <U-l1fZ9G8ctKEjq6IdJJBGXJzJJeI4JUjaemwOzhdHo=.1e30f73c-cf88-4394-b59f-98aa5664c9db@github.com>
Message-ID: <XjTat5FN7Pxw0RoEY4EmHVk_ItIxt5MZllXtrHVCQvc=.e4dcfdb0-4c77-4723-a216-4e4eb87d5340@github.com>

On Wed, 3 Feb 2021 19:12:25 GMT, Emmanuel Bourg <github.com+54304+ebourg at openjdk.org> wrote:

> This PR fixes the following spelling errors:
> 
>  choosen  -> chosen
>  commad   -> command
>  hiearchy -> hierarchy
>  leagacy  -> legacy
>  minium   -> minimum
>  subsytem -> subsystem
>  unamed   -> unnamed

Trivially, looks ok to me.

-------------

Marked as reviewed by chegar (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2385

From yyang at openjdk.java.net  Wed Jul 28 15:39:48 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Wed, 28 Jul 2021 15:39:48 GMT
Subject: RFR: 8271396: Spelling errors
In-Reply-To: <U-l1fZ9G8ctKEjq6IdJJBGXJzJJeI4JUjaemwOzhdHo=.1e30f73c-cf88-4394-b59f-98aa5664c9db@github.com>
References: <U-l1fZ9G8ctKEjq6IdJJBGXJzJJeI4JUjaemwOzhdHo=.1e30f73c-cf88-4394-b59f-98aa5664c9db@github.com>
Message-ID: <QVfb9Ia0KIhLqsqLTdMA1CU7UWY_o9DK_5BZaQt5oxs=.2f3b25f4-3f0d-42ca-b56a-109c2a1c2349@github.com>

On Wed, 3 Feb 2021 19:12:25 GMT, Emmanuel Bourg <github.com+54304+ebourg at openjdk.org> wrote:

> This PR fixes the following spelling errors:
> 
>  choosen  -> chosen
>  commad   -> command
>  hiearchy -> hierarchy
>  leagacy  -> legacy
>  minium   -> minimum
>  subsytem -> subsystem
>  unamed   -> unnamed

Hi, I've filed https://bugs.openjdk.java.net/browse/JDK-8271396 for this PR, you can change the title to "8271396: Spelling errors", openjdk bot will link this PR to the corresponding issue. Also you should resolve conflicts and pass jcheck before integrating it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2385

From github.com+54304+ebourg at openjdk.java.net  Wed Jul 28 15:39:48 2021
From: github.com+54304+ebourg at openjdk.java.net (Emmanuel Bourg)
Date: Wed, 28 Jul 2021 15:39:48 GMT
Subject: RFR: 8271396: Spelling errors
In-Reply-To: <U-l1fZ9G8ctKEjq6IdJJBGXJzJJeI4JUjaemwOzhdHo=.1e30f73c-cf88-4394-b59f-98aa5664c9db@github.com>
References: <U-l1fZ9G8ctKEjq6IdJJBGXJzJJeI4JUjaemwOzhdHo=.1e30f73c-cf88-4394-b59f-98aa5664c9db@github.com>
Message-ID: <10SItkPG_iJXTz8Ya0h8wBgoiXRl-aki9ADR8U_jaj8=.f3b7b05e-2b91-4522-9f7f-4b2ea97c8a50@github.com>

On Wed, 3 Feb 2021 19:12:25 GMT, Emmanuel Bourg <github.com+54304+ebourg at openjdk.org> wrote:

> This PR fixes the following spelling errors:
> 
>  choosen  -> chosen
>  commad   -> command
>  hiearchy -> hierarchy
>  leagacy  -> legacy
>  minium   -> minimum
>  subsytem -> subsystem
>  unamed   -> unnamed

.

.

Thank you!

The PR has been updated

-------------

PR: https://git.openjdk.java.net/jdk/pull/2385

From kevin.rushforth at oracle.com  Wed Jul 28 15:42:09 2021
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Wed, 28 Jul 2021 08:42:09 -0700
Subject: jpackage MacOS Notarization
In-Reply-To: <CAAoP7T5tO86Lt+WbwGv5iLuFcNRNgxsyCLaynQpUcAEkeqW-Zg@mail.gmail.com>
References: <CAAoP7T5tO86Lt+WbwGv5iLuFcNRNgxsyCLaynQpUcAEkeqW-Zg@mail.gmail.com>
Message-ID: <9d2ab55d-7ab7-b4a9-d49d-3f8e92e8da6a@oracle.com>

Full support for notarization in jpackage was added in JDK 17. Can you 
try an early access build of JDK 17 [1] and see if that works for you?

-- Kevin

[1] https://jdk.java.net/17

On 7/28/2021 8:27 AM, Daniel Peintner wrote:
> All,
>
> I am trying to notarize an app (built with jpackage) for MacOS.
>
> jpackage at first *seems* to properly sign all resources with the available
> --mac-sign options et cetera.
>
> Having said that, there are still remaining issues
> 1. The app cannot be properly installed
>     (without hacks like xattr -d com.apple.quarantine /Applications/myAPP.app
> ).
> 2. I am also not able to properly notarize the app.
>
> According to online resources there seem to exist issues in *past* about
> notarization but according to [1, 2] the issues are fixed.
>
> As mentioned, I still have issues :-(
> Am I really the only one still having problems?
>
> Java Version: AdoptOpenJDK-16.0.1+9 (tried Oracle JDK also without success)
>
> The issue seems to boil down to 2 errors (attached the error log from Apple
> notarization process).
> * app Folder
> * libjli.dylib
>
> I thought I better ask first on the mailing list before creating an actual
> bug report.
>
> Note1: I used to use the *old* javapackager that worked with the same
> signature/credentials.
> Note2: running jpackage without --mac-sign options causes many more errors
> in notarization (Hence, jpackage signs most resources but fails with some)
>
> Any help / hint appreciated.
>
> Thanks,
>
> -- Daniel
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8257488
> [2] https://bugs.openjdk.java.net/browse/JDK-8251892
>
>
>
> ## APPLE LOG ##
>
> {
>    "logFormatVersion": 1,
>    "jobId": "...",
>    "status": "Invalid",
>    "statusSummary": "Archive contains critical validation errors",
>    "statusCode": 4000,
>    "archiveFilename": "myAPP-21.07.28.dmg",
>    "uploadDate": "2021-07-28T14:31:24Z",
>    "sha256": "...",
>    "ticketContents": null,
>    "issues": [
>      {
>        "severity": "error",
>        "code": null,
>        "path": "myAPP-21.07.28.dmg/myAPP.app/Contents/MacOS/myAPP",
>        "message": "The signature of the binary is invalid.",
>        "docUrl": null,
>        "architecture": "x86_64"
>      },
>      {
>        "severity": "error",
>        "code": null,
>        "path": "myAPP-21.07.28.dmg/myAPP.app/Contents/runtime/Contents/MacOS/libjli.dylib",
>        "message": "The signature of the binary is invalid.",
>        "docUrl": null,
>        "architecture": "x86_64"
>      }
>    ]
> }


From iris at openjdk.java.net  Wed Jul 28 16:17:31 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Wed, 28 Jul 2021 16:17:31 GMT
Subject: RFR: 8271396: Spelling errors
In-Reply-To: <U-l1fZ9G8ctKEjq6IdJJBGXJzJJeI4JUjaemwOzhdHo=.1e30f73c-cf88-4394-b59f-98aa5664c9db@github.com>
References: <U-l1fZ9G8ctKEjq6IdJJBGXJzJJeI4JUjaemwOzhdHo=.1e30f73c-cf88-4394-b59f-98aa5664c9db@github.com>
Message-ID: <IzhHnS2Nir_azY-2MIv9m9UHxi2pQHE1mNxQw2f9nW4=.6a615f55-a7b1-4a81-9c91-57bd6e3fa7fa@github.com>

On Wed, 3 Feb 2021 19:12:25 GMT, Emmanuel Bourg <github.com+54304+ebourg at openjdk.org> wrote:

> This PR fixes the following spelling errors:
> 
>  choosen  -> chosen
>  commad   -> command
>  hiearchy -> hierarchy
>  leagacy  -> legacy
>  minium   -> minimum
>  subsytem -> subsystem
>  unamed   -> unnamed

Marked as reviewed by iris (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/2385

From psadhukhan at openjdk.java.net  Wed Jul 28 16:17:31 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 28 Jul 2021 16:17:31 GMT
Subject: RFR: 8271396: Spelling errors
In-Reply-To: <U-l1fZ9G8ctKEjq6IdJJBGXJzJJeI4JUjaemwOzhdHo=.1e30f73c-cf88-4394-b59f-98aa5664c9db@github.com>
References: <U-l1fZ9G8ctKEjq6IdJJBGXJzJJeI4JUjaemwOzhdHo=.1e30f73c-cf88-4394-b59f-98aa5664c9db@github.com>
Message-ID: <Bq3Nm1ILzw1TRD2bA2FpFLsnzuNxAffRspEOokAcBrs=.3c5c2746-d279-4db6-9c7a-47c551e8a1c1@github.com>

On Wed, 3 Feb 2021 19:12:25 GMT, Emmanuel Bourg <github.com+54304+ebourg at openjdk.org> wrote:

> This PR fixes the following spelling errors:
> 
>  choosen  -> chosen
>  commad   -> command
>  hiearchy -> hierarchy
>  leagacy  -> legacy
>  minium   -> minimum
>  subsytem -> subsystem
>  unamed   -> unnamed

Thanks for awt/swing correction.

-------------

Marked as reviewed by psadhukhan (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2385

From cjplummer at openjdk.java.net  Wed Jul 28 16:25:32 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Wed, 28 Jul 2021 16:25:32 GMT
Subject: RFR: 8271396: Spelling errors
In-Reply-To: <U-l1fZ9G8ctKEjq6IdJJBGXJzJJeI4JUjaemwOzhdHo=.1e30f73c-cf88-4394-b59f-98aa5664c9db@github.com>
References: <U-l1fZ9G8ctKEjq6IdJJBGXJzJJeI4JUjaemwOzhdHo=.1e30f73c-cf88-4394-b59f-98aa5664c9db@github.com>
Message-ID: <mF8f_Z4TdIttsMV7_J2yms_a3_eM2qHCbjnHs3XYpwI=.caae749d-6dfa-4be0-b459-2e69cd4d1662@github.com>

On Wed, 3 Feb 2021 19:12:25 GMT, Emmanuel Bourg <github.com+54304+ebourg at openjdk.org> wrote:

> This PR fixes the following spelling errors:
> 
>  choosen  -> chosen
>  commad   -> command
>  hiearchy -> hierarchy
>  leagacy  -> legacy
>  minium   -> minimum
>  subsytem -> subsystem
>  unamed   -> unnamed

jdi, jvmti, and dcmd related changes look good.

-------------

Marked as reviewed by cjplummer (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2385

From jboes at openjdk.java.net  Wed Jul 28 16:29:29 2021
From: jboes at openjdk.java.net (Julia Boes)
Date: Wed, 28 Jul 2021 16:29:29 GMT
Subject: RFR: 8271396: Spelling errors
In-Reply-To: <U-l1fZ9G8ctKEjq6IdJJBGXJzJJeI4JUjaemwOzhdHo=.1e30f73c-cf88-4394-b59f-98aa5664c9db@github.com>
References: <U-l1fZ9G8ctKEjq6IdJJBGXJzJJeI4JUjaemwOzhdHo=.1e30f73c-cf88-4394-b59f-98aa5664c9db@github.com>
Message-ID: <qsybKx5QEt_0qEvwE9hXSUZrCdY6FSAfBAINYLqbtvM=.2d27e252-6d6e-4070-9127-f9d257e4ea54@github.com>

On Wed, 3 Feb 2021 19:12:25 GMT, Emmanuel Bourg <github.com+54304+ebourg at openjdk.org> wrote:

> This PR fixes the following spelling errors:
> 
>  choosen  -> chosen
>  commad   -> command
>  hiearchy -> hierarchy
>  leagacy  -> legacy
>  minium   -> minimum
>  subsytem -> subsystem
>  unamed   -> unnamed

I'm happy to sponsor this change, but could you please update the copyright year where necessary, e.g. in 
src/java.desktop/unix/classes/sun/awt/X11/XMSelection.java: 
`Copyright (c) 2003, 2018, Oracle...` -> `Copyright (c) 2003, 2021, Oracle...`

-------------

PR: https://git.openjdk.java.net/jdk/pull/2385

From sviswanathan at openjdk.java.net  Wed Jul 28 16:41:37 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Wed, 28 Jul 2021 16:41:37 GMT
Subject: RFR: 8266054: VectorAPI rotate operation optimization [v13]
In-Reply-To: <yAIhiSCrVlfq0uznc-Hcb6IsMbnTnbGnL0k3RnULnAo=.38bb6473-27fd-4508-aaa6-37f066f25bdb@github.com>
References: <OZ2u4DDNaYF3WiR5uU6NWvzPMKV3j8QAO_mZyLP3Isg=.594e3514-8a5a-442c-ac1a-ca6c6d14e963@github.com>
 <HU2E5YuCI7Iz38CNycxu62RVNsyyT9unlr79-fSwFVg=.fde03b0d-6f8f-445f-88e4-84511f50226b@github.com>
 <FQQA8lfkU4CkF4wZ1PczK-ZqtZn1v5BkKqTVIPveCf0=.ac405b11-ea1e-4b98-9b07-c626fc3ad2cf@github.com>
 <yAIhiSCrVlfq0uznc-Hcb6IsMbnTnbGnL0k3RnULnAo=.38bb6473-27fd-4508-aaa6-37f066f25bdb@github.com>
Message-ID: <OGr0PFNR2pOxpHdi9ZZxgNA0izGzwspemZuMxbffLd0=.81cf927f-4845-40a8-846e-c0e82d6b0918@github.com>

On Wed, 28 Jul 2021 04:48:35 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Looks good to me.
>
> @sviswa7 and @jatin-bhateja jatin-bhateja
> The push caused https://bugs.openjdk.java.net/browse/JDK-8271366
> I am strongly suggest in a future to ask an Oracle's engineer to test Intel's changes before pushing.

@vnkozlov  @PaulSandoz Sorry for the inconvenience. @jatin-bhateja Please don't be in a hurry to push and reach out to Oracle engineers for testing before pushing.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3720

From github.com+54304+ebourg at openjdk.java.net  Wed Jul 28 17:12:04 2021
From: github.com+54304+ebourg at openjdk.java.net (Emmanuel Bourg)
Date: Wed, 28 Jul 2021 17:12:04 GMT
Subject: RFR: 8271396: Spelling errors [v2]
In-Reply-To: <U-l1fZ9G8ctKEjq6IdJJBGXJzJJeI4JUjaemwOzhdHo=.1e30f73c-cf88-4394-b59f-98aa5664c9db@github.com>
References: <U-l1fZ9G8ctKEjq6IdJJBGXJzJJeI4JUjaemwOzhdHo=.1e30f73c-cf88-4394-b59f-98aa5664c9db@github.com>
Message-ID: <axOY0lG3CInpykz-_Ur_wY8dRvr4QsfktJ9gD0vvirA=.c8302d67-79c3-4e99-853c-65701d049c4a@github.com>

> This PR fixes the following spelling errors:
> 
>  choosen  -> chosen
>  commad   -> command
>  hiearchy -> hierarchy
>  leagacy  -> legacy
>  minium   -> minimum
>  subsytem -> subsystem
>  unamed   -> unnamed

Emmanuel Bourg has updated the pull request with a new target base 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:

  8271396: Fix spelling errors
  
   choosen  -> chosen
   commad   -> command
   hiearchy -> hierarchy
   leagacy  -> legacy
   minium   -> minimum
   subsytem -> subsystem
   unamed   -> unnamed

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2385/files
  - new: https://git.openjdk.java.net/jdk/pull/2385/files/31cfcba7..6e1be4f6

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2385&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2385&range=00-01

  Stats: 61642 lines in 1361 files changed: 29147 ins; 26026 del; 6469 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2385.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2385/head:pull/2385

PR: https://git.openjdk.java.net/jdk/pull/2385

From github.com+54304+ebourg at openjdk.java.net  Wed Jul 28 17:12:05 2021
From: github.com+54304+ebourg at openjdk.java.net (Emmanuel Bourg)
Date: Wed, 28 Jul 2021 17:12:05 GMT
Subject: RFR: 8271396: Spelling errors
In-Reply-To: <qsybKx5QEt_0qEvwE9hXSUZrCdY6FSAfBAINYLqbtvM=.2d27e252-6d6e-4070-9127-f9d257e4ea54@github.com>
References: <U-l1fZ9G8ctKEjq6IdJJBGXJzJJeI4JUjaemwOzhdHo=.1e30f73c-cf88-4394-b59f-98aa5664c9db@github.com>
 <qsybKx5QEt_0qEvwE9hXSUZrCdY6FSAfBAINYLqbtvM=.2d27e252-6d6e-4070-9127-f9d257e4ea54@github.com>
Message-ID: <ECY56wmiBbQOh06b4r_yI7IykEom57iFFgIQNnhQMGY=.a16517dc-67bc-43a6-b0ef-d1eab0d6970a@github.com>

On Wed, 28 Jul 2021 16:26:49 GMT, Julia Boes <jboes at openjdk.org> wrote:

>> This PR fixes the following spelling errors:
>> 
>>  choosen  -> chosen
>>  commad   -> command
>>  hiearchy -> hierarchy
>>  leagacy  -> legacy
>>  minium   -> minimum
>>  subsytem -> subsystem
>>  unamed   -> unnamed
>
> I'm happy to sponsor this change, but could you please update the copyright year where necessary, e.g. in 
> src/java.desktop/unix/classes/sun/awt/X11/XMSelection.java: 
> `Copyright (c) 2003, 2018, Oracle...` -> `Copyright (c) 2003, 2021, Oracle...`

@FrauBoes thank you, the PR has been updated to modify the copyright year

-------------

PR: https://git.openjdk.java.net/jdk/pull/2385

From andy.herrick at oracle.com  Wed Jul 28 17:17:56 2021
From: andy.herrick at oracle.com (Andy Herrick)
Date: Wed, 28 Jul 2021 13:17:56 -0400
Subject: jpackage MacOS Notarization
In-Reply-To: <CAAoP7T5tO86Lt+WbwGv5iLuFcNRNgxsyCLaynQpUcAEkeqW-Zg@mail.gmail.com>
References: <CAAoP7T5tO86Lt+WbwGv5iLuFcNRNgxsyCLaynQpUcAEkeqW-Zg@mail.gmail.com>
Message-ID: <d9c211d0-8853-ab46-82a7-6c500e56b1fc@oracle.com>

Not really enough info given here to act on.? Exactly what java 
version/build are you using??? As Kevin suggested it best to try JDK17 
EA first, but I can notarize simple test app with JDK16 , staple the 
notarization, and then download it and run it on other machines without 
the quarantine hacks.

While implementing support for the Mac App Store in JDK17, we had to 
change the way signing works (we now unsign the java runtime and then 
re-sign it's components together with the app's components, where we 
previously used the signing already present in the released jdk.)? For 
this reason I think? it is better to look only at problem that persist 
in JDK17 at this time.

/Andy

On 7/28/2021 11:27 AM, Daniel Peintner wrote:
> All,
>
> I am trying to notarize an app (built with jpackage) for MacOS.
>
> jpackage at first *seems* to properly sign all resources with the available
> --mac-sign options et cetera.
>
> Having said that, there are still remaining issues
> 1. The app cannot be properly installed
>     (without hacks like xattr -d com.apple.quarantine /Applications/myAPP.app
> ).
This indicates the app is not notarized or the notarization is not 
properly stapled.
> 2. I am also not able to properly notarize the app.
>
> According to online resources there seem to exist issues in *past* about
> notarization but according to [1, 2] the issues are fixed.
>
> As mentioned, I still have issues :-(
> Am I really the only one still having problems?
>
> Java Version: AdoptOpenJDK-16.0.1+9 (tried Oracle JDK also without success)
>
> The issue seems to boil down to 2 errors (attached the error log from Apple
> notarization process).
> * app Folder
> * libjli.dylib

 From below it looks like you are trying to sign a dmg.

Notarization or a jpackage artifact requires either a signed pkg or a 
zipped signed app image.

It looks like notarizing a signed dmg is now supported by Apple, but 
this is not something that was available when we initially implemented 
this in jpackage.

Can you try the same thing with a "pkg" instead of a "dmg".

We will have to look into what is needed to sign "dmg" artifacts now.

/Andy


From iris at openjdk.java.net  Wed Jul 28 17:26:34 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Wed, 28 Jul 2021 17:26:34 GMT
Subject: RFR: 8271396: Spelling errors [v2]
In-Reply-To: <axOY0lG3CInpykz-_Ur_wY8dRvr4QsfktJ9gD0vvirA=.c8302d67-79c3-4e99-853c-65701d049c4a@github.com>
References: <U-l1fZ9G8ctKEjq6IdJJBGXJzJJeI4JUjaemwOzhdHo=.1e30f73c-cf88-4394-b59f-98aa5664c9db@github.com>
 <axOY0lG3CInpykz-_Ur_wY8dRvr4QsfktJ9gD0vvirA=.c8302d67-79c3-4e99-853c-65701d049c4a@github.com>
Message-ID: <creDetfFbVTSBqmvtf65RTiUEBDK2hFEh5ESw38QR-4=.3c2ecc4a-82a8-4aa7-ae79-efe2363e68d6@github.com>

On Wed, 28 Jul 2021 17:12:04 GMT, Emmanuel Bourg <github.com+54304+ebourg at openjdk.org> wrote:

>> This PR fixes the following spelling errors:
>> 
>>  choosen  -> chosen
>>  commad   -> command
>>  hiearchy -> hierarchy
>>  leagacy  -> legacy
>>  minium   -> minimum
>>  subsytem -> subsystem
>>  unamed   -> unnamed
>
> Emmanuel Bourg has updated the pull request with a new target base 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:
> 
>   8271396: Fix spelling errors
>   
>    choosen  -> chosen
>    commad   -> command
>    hiearchy -> hierarchy
>    leagacy  -> legacy
>    minium   -> minimum
>    subsytem -> subsystem
>    unamed   -> unnamed

Marked as reviewed by iris (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/2385

From github.com+54304+ebourg at openjdk.java.net  Wed Jul 28 17:26:35 2021
From: github.com+54304+ebourg at openjdk.java.net (Emmanuel Bourg)
Date: Wed, 28 Jul 2021 17:26:35 GMT
Subject: RFR: 8271396: Spelling errors
In-Reply-To: <c8D3av6T1vVqUc0YgytVzPMZoVwmk3pAQwgCU9OaTGY=.88b57352-b1a0-4563-b651-6f624560dbe7@github.com>
References: <U-l1fZ9G8ctKEjq6IdJJBGXJzJJeI4JUjaemwOzhdHo=.1e30f73c-cf88-4394-b59f-98aa5664c9db@github.com>
 <qsybKx5QEt_0qEvwE9hXSUZrCdY6FSAfBAINYLqbtvM=.2d27e252-6d6e-4070-9127-f9d257e4ea54@github.com>
 <ECY56wmiBbQOh06b4r_yI7IykEom57iFFgIQNnhQMGY=.a16517dc-67bc-43a6-b0ef-d1eab0d6970a@github.com>
 <c8D3av6T1vVqUc0YgytVzPMZoVwmk3pAQwgCU9OaTGY=.88b57352-b1a0-4563-b651-6f624560dbe7@github.com>
Message-ID: <al0SRVpmZ3Jta5hZkVrGWCBNM9X330njP-87Gtj2Xrk=.d7a1bea3-1b54-4084-be08-831b4eff898b@github.com>

On Wed, 28 Jul 2021 17:20:37 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> @FrauBoes thank you, the PR has been updated to modify the copyright year
>
> @ebourg for future PRs please do not force push after the PR is out for review. Just push incremental commits normally. The Skara tooling will squash them all into a single commit.

@kevinrushforth I'll do that, thank you for the hint

-------------

PR: https://git.openjdk.java.net/jdk/pull/2385

From kcr at openjdk.java.net  Wed Jul 28 17:26:35 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Wed, 28 Jul 2021 17:26:35 GMT
Subject: RFR: 8271396: Spelling errors
In-Reply-To: <ECY56wmiBbQOh06b4r_yI7IykEom57iFFgIQNnhQMGY=.a16517dc-67bc-43a6-b0ef-d1eab0d6970a@github.com>
References: <U-l1fZ9G8ctKEjq6IdJJBGXJzJJeI4JUjaemwOzhdHo=.1e30f73c-cf88-4394-b59f-98aa5664c9db@github.com>
 <qsybKx5QEt_0qEvwE9hXSUZrCdY6FSAfBAINYLqbtvM=.2d27e252-6d6e-4070-9127-f9d257e4ea54@github.com>
 <ECY56wmiBbQOh06b4r_yI7IykEom57iFFgIQNnhQMGY=.a16517dc-67bc-43a6-b0ef-d1eab0d6970a@github.com>
Message-ID: <c8D3av6T1vVqUc0YgytVzPMZoVwmk3pAQwgCU9OaTGY=.88b57352-b1a0-4563-b651-6f624560dbe7@github.com>

On Wed, 28 Jul 2021 17:08:01 GMT, Emmanuel Bourg <github.com+54304+ebourg at openjdk.org> wrote:

>> I'm happy to sponsor this change, but could you please update the copyright year where necessary, e.g. in 
>> src/java.desktop/unix/classes/sun/awt/X11/XMSelection.java: 
>> `Copyright (c) 2003, 2018, Oracle...` -> `Copyright (c) 2003, 2021, Oracle...`
>
> @FrauBoes thank you, the PR has been updated to modify the copyright year

@ebourg for future PRs please do not force push after the PR is out for review. Just push incremental commits normally. The Skara tooling will squash them all into a single commit.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2385

From dcubed at openjdk.java.net  Wed Jul 28 18:45:48 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 28 Jul 2021 18:45:48 GMT
Subject: [jdk17] RFR: 8271412: ProblemList
 javax/sound/midi/Sequencer/Looping.java
Message-ID: <qKt5-EvpbRH4gmE8jMO_vGiA7-kdpIkV6l-FTTuScik=.c638529f-d9a7-4cb7-9f89-7962370fc798@github.com>

8271412: ProblemList javax/sound/midi/Sequencer/Looping.java

-------------

Commit messages:
 - 8271413: ProblemList 2 locale tests on macOS-x64
 - 8271412: ProblemList javax/sound/midi/Sequencer/Looping.java

Changes: https://git.openjdk.java.net/jdk17/pull/291/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=291&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8271412
  Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/291.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/291/head:pull/291

PR: https://git.openjdk.java.net/jdk17/pull/291

From naoto at openjdk.java.net  Wed Jul 28 18:45:48 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 28 Jul 2021 18:45:48 GMT
Subject: [jdk17] RFR: 8271412: ProblemList
 javax/sound/midi/Sequencer/Looping.java
In-Reply-To: <qKt5-EvpbRH4gmE8jMO_vGiA7-kdpIkV6l-FTTuScik=.c638529f-d9a7-4cb7-9f89-7962370fc798@github.com>
References: <qKt5-EvpbRH4gmE8jMO_vGiA7-kdpIkV6l-FTTuScik=.c638529f-d9a7-4cb7-9f89-7962370fc798@github.com>
Message-ID: <4OxJyIjYmL7VipsbhwjpJi-1NdoZpud5c2HmLLJvqp0=.60816a97-a8fc-49f5-a0f7-74599ce623d9@github.com>

On Wed, 28 Jul 2021 17:51:31 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> 8271412: ProblemList javax/sound/midi/Sequencer/Looping.java

Marked as reviewed by naoto (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk17/pull/291

From dcubed at openjdk.java.net  Wed Jul 28 18:48:28 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 28 Jul 2021 18:48:28 GMT
Subject: [jdk17] RFR: 8271412: ProblemList
 javax/sound/midi/Sequencer/Looping.java
In-Reply-To: <4OxJyIjYmL7VipsbhwjpJi-1NdoZpud5c2HmLLJvqp0=.60816a97-a8fc-49f5-a0f7-74599ce623d9@github.com>
References: <qKt5-EvpbRH4gmE8jMO_vGiA7-kdpIkV6l-FTTuScik=.c638529f-d9a7-4cb7-9f89-7962370fc798@github.com>
 <4OxJyIjYmL7VipsbhwjpJi-1NdoZpud5c2HmLLJvqp0=.60816a97-a8fc-49f5-a0f7-74599ce623d9@github.com>
Message-ID: <x5Gxp05Xanfkg62YqIvcu3CR4tPd8IyRv6jp6UnjPcc=.e293bea8-9c18-4005-8606-5eaf877bf8f3@github.com>

On Wed, 28 Jul 2021 18:42:11 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> 8271412: ProblemList javax/sound/midi/Sequencer/Looping.java
>
> Marked as reviewed by naoto (Reviewer).

@naotoj - Thanks for the fast review!

-------------

PR: https://git.openjdk.java.net/jdk17/pull/291

From dcubed at openjdk.java.net  Wed Jul 28 18:56:33 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 28 Jul 2021 18:56:33 GMT
Subject: [jdk17] Integrated: 8271412: ProblemList
 javax/sound/midi/Sequencer/Looping.java
In-Reply-To: <qKt5-EvpbRH4gmE8jMO_vGiA7-kdpIkV6l-FTTuScik=.c638529f-d9a7-4cb7-9f89-7962370fc798@github.com>
References: <qKt5-EvpbRH4gmE8jMO_vGiA7-kdpIkV6l-FTTuScik=.c638529f-d9a7-4cb7-9f89-7962370fc798@github.com>
Message-ID: <6fzkDKaeX5rdBgxWZOF1kYGBK0pa6vxYSk15smZpdC8=.818f1405-3955-4746-a784-d4b68858f564@github.com>

On Wed, 28 Jul 2021 17:51:31 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> 8271412: ProblemList javax/sound/midi/Sequencer/Looping.java

This pull request has now been integrated.

Changeset: 7bf72ce3
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.java.net/jdk17/commit/7bf72ce301de80f4126607c2ef51d6df8c5849cf
Stats:     4 lines in 1 file changed: 4 ins; 0 del; 0 mod

8271412: ProblemList javax/sound/midi/Sequencer/Looping.java
8271413: ProblemList 2 locale tests on macOS-x64

Reviewed-by: naoto

-------------

PR: https://git.openjdk.java.net/jdk17/pull/291

From bchristi at openjdk.java.net  Wed Jul 28 22:12:28 2021
From: bchristi at openjdk.java.net (Brent Christian)
Date: Wed, 28 Jul 2021 22:12:28 GMT
Subject: RFR: 8266936: Add a finalization JFR event [v4]
In-Reply-To: <ZhRmSB07Rzd1fay76np0B3hc-V9gy2s2UxZiCfENIMY=.247c6641-6536-409f-bd13-2b662cacbafb@github.com>
References: <PpWS13N5Xk6jE-2GGuVjVbd9KgG11x85fFDHww7fMeA=.cbfa8c67-2ead-4db5-ade3-f2bc45565b11@github.com>
 <ZhRmSB07Rzd1fay76np0B3hc-V9gy2s2UxZiCfENIMY=.247c6641-6536-409f-bd13-2b662cacbafb@github.com>
Message-ID: <U9VvUUulhh0m5GgRndwQBjNHVAhjpV5wPnDYs6Nl6Zw=.62249a44-00a5-4e21-b9e9-6f3c02b0e703@github.com>

On Tue, 27 Jul 2021 15:14:29 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Greetings,
>> 
>> Object.finalize() was deprecated in JDK9. There is an ongoing effort to replace and mitigate Object.finalize() uses in the JDK libraries; please see https://bugs.openjdk.java.net/browse/JDK-8253568 for more information. 
>> 
>> We also like to assist users in replacing and mitigating uses in non-JDK code.
>> 
>> Hence, this changeset adds a periodic JFR event to help identify which classes are overriding Object.finalize().
>> 
>> Thanks
>> Markus
>
> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove build directive

Hi, Bernd

The JFR event can complement static bytecode analysis, reporting which classes with finalizers actually get loaded at runtime. 

I agree that it would be useful to add a count for finalizers that get run, either as part of this PR, or as a follow-up.  I would hesitate to add timing, though.  It's important to keep the overhead of this event low, and finalize() methods should already show up in current profilers.

Thanks,
-Brent

> _Mailing list message from [Bernd Eckenfels](mailto:ecki at zusammenkunft.net) on [core-libs-dev](mailto:core-libs-dev at mail.openjdk.java.net):_
> 
> Hello,
> 
> I know I am a bit late, but just wanted to mention, that since finding finalizers with Bytecode analysis is doable (and probably easier to deal with such scan reports), I don?t see much value in a JFR event, especially considering it even has native code executed. (Not so sure about dynamically loaded classes, would the event content help to identify sources?)
> 
> Having said that, this event would be more useful from a runtime perspective if It would actually record execution counts and time per class. Then one can concentrate on the worst offenders, first and even use it for runtime monitoring. Is there already a finalizer profiler?
> 
> Gruss
> Bernd

-------------

PR: https://git.openjdk.java.net/jdk/pull/4731

From iignatyev at openjdk.java.net  Thu Jul 29 00:53:12 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Thu, 29 Jul 2021 00:53:12 GMT
Subject: [jdk17] RFR: 8067223: [TESTBUG] Rename Whitebox API package
Message-ID: <39PNb3wa-43yB5IFR3XroqFf4vMNZPitzF85lO1Gw58=.f2587741-d2c4-467d-b722-b17269587e7a@github.com>

Hi all,

could you please review this big tedious and trivial(-ish) patch which moves `sun.hotspot.WhiteBox` and related classes to `jdk.test.whitebox` package?

the majority of the patch is the following substitutions:
 - `s~sun/hotspot/WhiteBox~jdk/test/whitebox/WhiteBox~g`
 - `s/sun.hotspot.parser/jdk.test.whitebox.parser/g`
 - `s/sun.hotspot.cpuinfo/jdk.test.whitebox.cpuinfo/g`
 - `s/sun.hotspot.code/jdk.test.whitebox.code/g`
 - `s/sun.hotspot.gc/jdk.test.whitebox.gc/g`
 - `s/sun.hotspot.WhiteBox/jdk.test.whitebox.WhiteBox/g`

testing: tier1-4

Thanks,
-- Igor

-------------

Commit messages:
 - copyright year
 - update TEST.ROOT
 - jdk: s/sun\.hotspot\.gc/jdk.test.whitebox.gc/g
 - jdk: s/sun\.hotspot\.code/jdk.test.whitebox.code/g
 - jdk: s/sun\.hotspot\.WhiteBox/jdk.test.whitebox.WhiteBox/g
 - hotspot: 's~sun/hotspot/WhiteBox~jdk/test/whitebox/WhiteBox~g'
 - hotspot: s/sun\.hotspot\.parser/jdk.test.whitebox.parser/g
 - hotspot: s/sun\.hotspot\.cpuinfo/jdk.test.whitebox.cpuinfo/g
 - hotspot: s/sun\.hotspot\.code/jdk.test.whitebox.code/g
 - hotspot: 's/sun\.hotspot\.gc/jdk.test.whitebox.gc/g'
 - ... and 9 more: https://git.openjdk.java.net/jdk17/compare/c8ae7e5b...8f12f2cf

Changes: https://git.openjdk.java.net/jdk17/pull/290/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=290&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8067223
  Stats: 2310 lines in 949 files changed: 0 ins; 0 del; 2310 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/290.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/290/head:pull/290

PR: https://git.openjdk.java.net/jdk17/pull/290

From kvn at openjdk.java.net  Thu Jul 29 01:33:29 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Thu, 29 Jul 2021 01:33:29 GMT
Subject: [jdk17] RFR: 8067223: [TESTBUG] Rename Whitebox API package
In-Reply-To: <39PNb3wa-43yB5IFR3XroqFf4vMNZPitzF85lO1Gw58=.f2587741-d2c4-467d-b722-b17269587e7a@github.com>
References: <39PNb3wa-43yB5IFR3XroqFf4vMNZPitzF85lO1Gw58=.f2587741-d2c4-467d-b722-b17269587e7a@github.com>
Message-ID: <_3viZFs2iZ00hMdeP3Nq9gTmwfIHeTzZ7NVT8thQ1BM=.10005882-f135-4592-a663-b75747da3f6c@github.com>

On Wed, 28 Jul 2021 17:13:49 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this big tedious and trivial(-ish) patch which moves `sun.hotspot.WhiteBox` and related classes to `jdk.test.whitebox` package?
> 
> the majority of the patch is the following substitutions:
>  - `s~sun/hotspot/WhiteBox~jdk/test/whitebox/WhiteBox~g`
>  - `s/sun.hotspot.parser/jdk.test.whitebox.parser/g`
>  - `s/sun.hotspot.cpuinfo/jdk.test.whitebox.cpuinfo/g`
>  - `s/sun.hotspot.code/jdk.test.whitebox.code/g`
>  - `s/sun.hotspot.gc/jdk.test.whitebox.gc/g`
>  - `s/sun.hotspot.WhiteBox/jdk.test.whitebox.WhiteBox/g`
> 
> testing: tier1-4
> 
> Thanks,
> -- Igor

I know that tests fixes could be pushed during RDP2 without approval.
But these one is very big and it is not a fix - it is enhancement.

What is the reason you want to push it into JDK 17 just few days before first Release Candidate? Instead of pushing it into JDK 18.

And I can't even review it because GutHub UI hangs on these big changes.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/290

From dholmes at openjdk.java.net  Thu Jul 29 01:59:34 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 29 Jul 2021 01:59:34 GMT
Subject: [jdk17] RFR: 8067223: [TESTBUG] Rename Whitebox API package
In-Reply-To: <_3viZFs2iZ00hMdeP3Nq9gTmwfIHeTzZ7NVT8thQ1BM=.10005882-f135-4592-a663-b75747da3f6c@github.com>
References: <39PNb3wa-43yB5IFR3XroqFf4vMNZPitzF85lO1Gw58=.f2587741-d2c4-467d-b722-b17269587e7a@github.com>
 <_3viZFs2iZ00hMdeP3Nq9gTmwfIHeTzZ7NVT8thQ1BM=.10005882-f135-4592-a663-b75747da3f6c@github.com>
Message-ID: <uS-q6EG6pQtgTQbK3VDUnBF5MovH0hpRlC9CDTlEGDc=.01714903-9472-417a-a901-ea52bea6ed0a@github.com>

On Thu, 29 Jul 2021 01:30:37 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Hi all,
>> 
>> could you please review this big tedious and trivial(-ish) patch which moves `sun.hotspot.WhiteBox` and related classes to `jdk.test.whitebox` package?
>> 
>> the majority of the patch is the following substitutions:
>>  - `s~sun/hotspot/WhiteBox~jdk/test/whitebox/WhiteBox~g`
>>  - `s/sun.hotspot.parser/jdk.test.whitebox.parser/g`
>>  - `s/sun.hotspot.cpuinfo/jdk.test.whitebox.cpuinfo/g`
>>  - `s/sun.hotspot.code/jdk.test.whitebox.code/g`
>>  - `s/sun.hotspot.gc/jdk.test.whitebox.gc/g`
>>  - `s/sun.hotspot.WhiteBox/jdk.test.whitebox.WhiteBox/g`
>> 
>> testing: tier1-4
>> 
>> Thanks,
>> -- Igor
>
> I know that tests fixes could be pushed during RDP2 without approval.
> But these one is very big and it is not a fix - it is enhancement.
> 
> What is the reason you want to push it into JDK 17 just few days before first Release Candidate? Instead of pushing it into JDK 18.
> 
> And I can't even review it because GutHub UI hangs on these big changes.

I agree with @vnkozlov this too big and disruptive for 17 at this stage of the release.

I also think a better approach to this cleanup would have been to copy the WhiteBox class to the new package structure, then update the tests in chunks, then remove the old WhiteBox classes when that is complete.

Thanks,
David

-------------

PR: https://git.openjdk.java.net/jdk17/pull/290

From dholmes at openjdk.java.net  Thu Jul 29 05:27:31 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 29 Jul 2021 05:27:31 GMT
Subject: RFR: JDK-8256844: Make NMT late-initializable
In-Reply-To: <Ze_dKp-5-dse_657jTXTD4kbHSBeOQcLvqeluE0DXjI=.9214cb10-f1f1-48cb-8d96-12621a51a904@github.com>
References: <Ze_dKp-5-dse_657jTXTD4kbHSBeOQcLvqeluE0DXjI=.9214cb10-f1f1-48cb-8d96-12621a51a904@github.com>
Message-ID: <bEiPTPFqv16cxPhcsF_nhZA8J3drHQYVRMM92k8HVNQ=.89f81018-3017-484d-ab08-b81f8d223c10@github.com>

On Thu, 22 Jul 2021 14:58:47 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Short: this patch makes NMT available in custom-launcher scenarios and during gtests. It simplifies NMT initialization. It adds a lot of NMT-specific testing, cleans them up and makes them sideeffect-free.
> 
> ---------
> 
> NMT continues to be an extremely useful tool for SAP to tackle memory problems in the JVM.
> 
> However, NMT is of limited use due to the following restrictions:
> 
> - NMT cannot be used if the hotspot is embedded into a custom launcher unless the launcher actively cooperates. Just creating and invoking the JVM is not enough, it needs to do some steps prior to loading the hotspot. This limitation is not well known (nor, do I believe, documented). Many products don't do this, e.g., you cannot use NMT with IntelliJ. For us at SAP this problem limits NMT usefulness greatly since our VMs are often embedded into custom launchers and modifying every launcher is impossible.
> - Worse, if that custom launcher links the libjvm *statically* there is just no way to activate NMT at all. This is the reason NMT cannot be used in the `gtestlauncher`.
> - Related to that is that we cannot pass NMT options via `JAVA_TOOL_OPTIONS` and `-XX:Flags=<file>`.
> - The fact that NMT cannot be used in gtests is really a pity since it would allow us to both test NMT itself more rigorously and check for memory leaks while testing other stuff.
> 
> The reason for all this is that NMT initialization happens very early, on the first call to `os::malloc()`. And those calls happen already during dynamic C++ initialization - a long time before the VM gets around parsing arguments. So, regular VM argument parsing is too late to parse NMT arguments.
> 
> The current solution is to pass NMT arguments via a specially prepared environment variable: `NMT_LEVEL_<PID>=<NMT arguments>`. That environment variable has to be set by the embedding launcher, before it loads the libjvm. Since its name contains the PID, we cannot even set that variable in the shell before starting the launcher.
> 
> All that means that every launcher needs to especially parse and process the NMT arguments given at the command line (or via whatever method) and prepare the environment variable. `java` itself does this. This only works before the libjvm.so is loaded, before its dynamic C++ initialization. For that reason, it does not work if the launcher links statically against the hotspot, since in that case C++ initialization of the launcher and hotspot are folded into one phase with no possibility of executing code beforehand.
> 
> And since it bypasses argument handling in the VM, it bypasses a number of argument processing ways, e.g., `JAVA_TOOL_OPTIONS`.
> 
> ------
> 
> This patch fixes these shortcomings by making NMT late-initializable: it can now be initialized after normal VM argument parsing, like all other parts of the VM. This greatly simplifies NMT initialization and makes it work automagically for every third party launcher, as well as within our gtests.
> 
> The glaring problem with late-initializing NMT is the NMT malloc headers. If we rule out just always having them (unacceptable in terms of memory overhead), there is no safe way to determine, in os::free(), if an allocation came from before or after NMT initialization ran, and therefore what to do with its malloc headers. For a more extensive explanation, please see the comment block `nmtPreInit.hpp` and the discussion with @kimbarrett and @zhengyu123 in the JBS comment section.
> 
> The heart of this patch is a new way to track early, pre-NMT-init allocations. These are tracked via a lookup table. This was a suggestion by Kim and it worked out well.
> 
> Changes in detail:
> 
> - pre-NMT-init handling:
> 	- the new files `nmtPreInit.hpp/cpp` take case of NMT pre-init handling. They contain a small global lookup table managing C-heap blocks allocated in the pre-NMT-init phase.
> 	- `os::malloc()/os::realloc()/os::free()` defer to this code before doing anything else.
> 	- Please see the extensive comment block at the start of `nmtPreinit.hpp` explaining the details.
> 
> - Changes to NMT:
> 	- Before, NMT initialization was spread over two phases, `initialize()` and `late_initialize()`. Those were merged into one and simplified - there is only one initialization now which happens after argument parsing.
> 	- Minor changes were needed for the `NMT_TrackingLevel` enum - to simplify code, I changed NMT_unknown to be numerically 0. A new comment block in `nmtCommon.hpp` now clearly specifies what's what, including allowed level state transitions.
> 	- New utility functions to translate tracking level from/to strings added to `NMTUtil`
> 	- NMT has never been able to handle virtual memory allocations before initialization, which is fine since os::reserve_memory() is not called before VM parses arguments. We now assert that.
> 	- All code outside the VM handling NMT initialization (eg. libjli) has been removed, as has the code testing it.
> 
> - Gtests:
> 	- Some existing gtests had to be modified: before, they all changed global state (turning NMT on/off) before testing. This is not allowed anymore, to keep NMT simple. Also, this pattern disturbed other tests.
> 	- The new way to test is to passively check whether NMT has been switched on or off, and do tests accordingly: if on, full tests, if off, test just what makes sense in off-state. That does not disturb neighboring tests, gives us actually better coverage all around.
> 	- It is now possible to start the gtestlauncher with NMT on! Which additionally gives us good coverage.
> 	- To actually do gtests with NMT - since it's disabled by default - we now run NMT-enabled gtests as part of the hotspot jtreg NMT wrapper. This pattern we have done for a number of other facitilites, see all the tests in test/hotspot/jtreg/gtest.. . It works very well.
> 	- Finally, a new gtest has been written to test the NMT preinit lookup map in isolation, placed in `gtest/nmt/test_nmtpreinitmap.cpp`.
> 	
> - jtreg:
> 	- A new test has been added, `runtime/NMT/NMTInitializationTest.java`, testing NMT initialization in the face of many many VM arguments.
> 
> -------------
> 
> Tests:
> - ran manually all new tests on 64-bit and 32-bit Linux
> - GHAs
> - The patch has been active in SAPs test systems for a while now.

src/hotspot/share/services/memTracker.cpp line 147:

> 145:   if (tracking_level() >= NMT_summary) {
> 146:     report(true, output, MemReporterBase::default_scale); // just print summary for error case.
> 147:     output->print("Preinit state:");

print_cr? Or need space after ':'  ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4874

From dholmes at openjdk.java.net  Thu Jul 29 06:40:30 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 29 Jul 2021 06:40:30 GMT
Subject: RFR: JDK-8256844: Make NMT late-initializable
In-Reply-To: <Ze_dKp-5-dse_657jTXTD4kbHSBeOQcLvqeluE0DXjI=.9214cb10-f1f1-48cb-8d96-12621a51a904@github.com>
References: <Ze_dKp-5-dse_657jTXTD4kbHSBeOQcLvqeluE0DXjI=.9214cb10-f1f1-48cb-8d96-12621a51a904@github.com>
Message-ID: <AZ2cA0l1q5QW5ni-nAICe9i9t0cpry0JUecLASkzBH8=.7615cb8b-fe0d-4e03-b106-62b9ddc5845b@github.com>

On Thu, 22 Jul 2021 14:58:47 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Short: this patch makes NMT available in custom-launcher scenarios and during gtests. It simplifies NMT initialization. It adds a lot of NMT-specific testing, cleans them up and makes them sideeffect-free.
> 
> ---------
> 
> NMT continues to be an extremely useful tool for SAP to tackle memory problems in the JVM.
> 
> However, NMT is of limited use due to the following restrictions:
> 
> - NMT cannot be used if the hotspot is embedded into a custom launcher unless the launcher actively cooperates. Just creating and invoking the JVM is not enough, it needs to do some steps prior to loading the hotspot. This limitation is not well known (nor, do I believe, documented). Many products don't do this, e.g., you cannot use NMT with IntelliJ. For us at SAP this problem limits NMT usefulness greatly since our VMs are often embedded into custom launchers and modifying every launcher is impossible.
> - Worse, if that custom launcher links the libjvm *statically* there is just no way to activate NMT at all. This is the reason NMT cannot be used in the `gtestlauncher`.
> - Related to that is that we cannot pass NMT options via `JAVA_TOOL_OPTIONS` and `-XX:Flags=<file>`.
> - The fact that NMT cannot be used in gtests is really a pity since it would allow us to both test NMT itself more rigorously and check for memory leaks while testing other stuff.
> 
> The reason for all this is that NMT initialization happens very early, on the first call to `os::malloc()`. And those calls happen already during dynamic C++ initialization - a long time before the VM gets around parsing arguments. So, regular VM argument parsing is too late to parse NMT arguments.
> 
> The current solution is to pass NMT arguments via a specially prepared environment variable: `NMT_LEVEL_<PID>=<NMT arguments>`. That environment variable has to be set by the embedding launcher, before it loads the libjvm. Since its name contains the PID, we cannot even set that variable in the shell before starting the launcher.
> 
> All that means that every launcher needs to especially parse and process the NMT arguments given at the command line (or via whatever method) and prepare the environment variable. `java` itself does this. This only works before the libjvm.so is loaded, before its dynamic C++ initialization. For that reason, it does not work if the launcher links statically against the hotspot, since in that case C++ initialization of the launcher and hotspot are folded into one phase with no possibility of executing code beforehand.
> 
> And since it bypasses argument handling in the VM, it bypasses a number of argument processing ways, e.g., `JAVA_TOOL_OPTIONS`.
> 
> ------
> 
> This patch fixes these shortcomings by making NMT late-initializable: it can now be initialized after normal VM argument parsing, like all other parts of the VM. This greatly simplifies NMT initialization and makes it work automagically for every third party launcher, as well as within our gtests.
> 
> The glaring problem with late-initializing NMT is the NMT malloc headers. If we rule out just always having them (unacceptable in terms of memory overhead), there is no safe way to determine, in os::free(), if an allocation came from before or after NMT initialization ran, and therefore what to do with its malloc headers. For a more extensive explanation, please see the comment block `nmtPreInit.hpp` and the discussion with @kimbarrett and @zhengyu123 in the JBS comment section.
> 
> The heart of this patch is a new way to track early, pre-NMT-init allocations. These are tracked via a lookup table. This was a suggestion by Kim and it worked out well.
> 
> Changes in detail:
> 
> - pre-NMT-init handling:
> 	- the new files `nmtPreInit.hpp/cpp` take case of NMT pre-init handling. They contain a small global lookup table managing C-heap blocks allocated in the pre-NMT-init phase.
> 	- `os::malloc()/os::realloc()/os::free()` defer to this code before doing anything else.
> 	- Please see the extensive comment block at the start of `nmtPreinit.hpp` explaining the details.
> 
> - Changes to NMT:
> 	- Before, NMT initialization was spread over two phases, `initialize()` and `late_initialize()`. Those were merged into one and simplified - there is only one initialization now which happens after argument parsing.
> 	- Minor changes were needed for the `NMT_TrackingLevel` enum - to simplify code, I changed NMT_unknown to be numerically 0. A new comment block in `nmtCommon.hpp` now clearly specifies what's what, including allowed level state transitions.
> 	- New utility functions to translate tracking level from/to strings added to `NMTUtil`
> 	- NMT has never been able to handle virtual memory allocations before initialization, which is fine since os::reserve_memory() is not called before VM parses arguments. We now assert that.
> 	- All code outside the VM handling NMT initialization (eg. libjli) has been removed, as has the code testing it.
> 
> - Gtests:
> 	- Some existing gtests had to be modified: before, they all changed global state (turning NMT on/off) before testing. This is not allowed anymore, to keep NMT simple. Also, this pattern disturbed other tests.
> 	- The new way to test is to passively check whether NMT has been switched on or off, and do tests accordingly: if on, full tests, if off, test just what makes sense in off-state. That does not disturb neighboring tests, gives us actually better coverage all around.
> 	- It is now possible to start the gtestlauncher with NMT on! Which additionally gives us good coverage.
> 	- To actually do gtests with NMT - since it's disabled by default - we now run NMT-enabled gtests as part of the hotspot jtreg NMT wrapper. This pattern we have done for a number of other facitilites, see all the tests in test/hotspot/jtreg/gtest.. . It works very well.
> 	- Finally, a new gtest has been written to test the NMT preinit lookup map in isolation, placed in `gtest/nmt/test_nmtpreinitmap.cpp`.
> 	
> - jtreg:
> 	- A new test has been added, `runtime/NMT/NMTInitializationTest.java`, testing NMT initialization in the face of many many VM arguments.
> 
> -------------
> 
> Tests:
> - ran manually all new tests on 64-bit and 32-bit Linux
> - GHAs
> - The patch has been active in SAPs test systems for a while now.

Hi Thomas,

I had a look through this and it seems reasonable, but I'm not familiar enough with the details to approve at this stage.

A few nits below.

Thanks,
David

src/hotspot/share/services/nmtCommon.hpp line 127:

> 125:   }
> 126: 
> 127:   // parses the tracking level from a string. Returns NMT_unknown if

Nit: start sentence with capital P

src/hotspot/share/services/nmtCommon.hpp line 131:

> 129:   static NMT_TrackingLevel parse_tracking_level(const char* s);
> 130: 
> 131:   // returns textual representation of a tracking level.

Nit: start sentence with capital R

src/hotspot/share/services/nmtPreInit.hpp line 114:

> 112: //
> 113: // We use a basic open hashmap, dimensioned generously - hash collisions should be very rare.
> 114: //  The table is customized for holding malloced pointers. One main point of this map is that we do

Nit: double-space at line start (and for rest of comment block)

src/hotspot/share/services/nmtPreInit.hpp line 140:

> 138: 
> 139:   // table_size: keep table size a prime and the hash function simple; this
> 140:   //  seems to give a good distribution for malloce'd pointers on all our libc variants.

typo: malloce'd

src/hotspot/share/services/nmtPreInit.hpp line 268:

> 266:       add_to_map(a);
> 267:       (*rc) = a->payload();
> 268:       _num_mallocs_pre ++;

style nit: no space with unary operator

src/java.base/share/native/libjli/java.c line 807:

> 805:  */
> 806: static void
> 807: SetJvmEnvironment(int argc, char **argv) {

This doesn't seem to do anything any more.

test/hotspot/gtest/nmt/test_nmtpreinitmap.cpp line 2:

> 1: /*
> 2:  * Copyright (c) 2017, 2020, Oracle and/or its affiliates. All rights reserved.

New file should only have single, current, copyright year

-------------

PR: https://git.openjdk.java.net/jdk/pull/4874

From github.com+1701815+mkarg at openjdk.java.net  Thu Jul 29 08:11:33 2021
From: github.com+1701815+mkarg at openjdk.java.net (Markus KARG)
Date: Thu, 29 Jul 2021 08:11:33 GMT
Subject: RFR: 8265891: (ch) InputStream returned by
 Channels.newInputStream should override transferTo [v6]
In-Reply-To: <eqqcs-9h_-p55lUyHJmmQgqbLCZ48MyBtDPi9eZH_bM=.17d7f6d4-6a37-4350-b774-e7040c85cab9@github.com>
References: <XlU5gCBUEa4qTTz8yhMeElh95FuiPcFYQ_nj_WYvbLE=.6e9fc6a4-f3b1-4faf-91f0-d8b06f875780@github.com>
 <5PpEoJT1JZoo75hz4HAQFkipRfXCr_7MyTE8g4yhhgc=.5eeefcfe-205b-4b02-a59b-bead8b410139@github.com>
 <eqqcs-9h_-p55lUyHJmmQgqbLCZ48MyBtDPi9eZH_bM=.17d7f6d4-6a37-4350-b774-e7040c85cab9@github.com>
Message-ID: <gRdJJ4CgTIrzXmSpyJOboD0XKhq4VZX1GQqlq8FYrws=.eb4be86d-23f7-4eab-b368-3f3efc6bff44@github.com>

On Tue, 27 Jul 2021 00:57:02 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Markus KARG 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/nio/ch/ChannelOutputStream.java line 85:
> 
>> 83:     private byte[] bs;       // Invoker's previous array
>> 84:     private byte[] b1;
>> 85: 
> 
> It might be better to put the field declarations at the beginning of the class before the static methods.

This is a question of style and personal likes. Code maintenance is much easier if variables are defined *near* to its first use, not *far away* (as in the Pascal or C language). If the reviewers want me to change it, I will do it.

> test/jdk/sun/nio/ch/ChannelInputStream/TransferTo.java line 67:
> 
>> 65:         test(readableByteChannelInput(), defaultOutput());
>> 66:     }
>> 67: 
> 
> This test looks like it's doing what it's supposed to do. I'm not asking to change it, but I think using TestNG might have given a simpler result with less work. For example, there could be one `DataProvider` supplying inputs which feed a `@Test` which expects an NPE, and another `DataProvider` supplying input-output pairs which feeds a `@Test` which validates the functionality.

No doubt, using modern tools would have spared me work, and indeed I would have chosen JUnit or TestNG if there would be a clear commitment to that tool *upfront*. For now, I see now use in reworking the code afterwards.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4263

From github.com+1701815+mkarg at openjdk.java.net  Thu Jul 29 08:15:32 2021
From: github.com+1701815+mkarg at openjdk.java.net (Markus KARG)
Date: Thu, 29 Jul 2021 08:15:32 GMT
Subject: RFR: 8265891: (ch) InputStream returned by
 Channels.newInputStream should override transferTo [v6]
In-Reply-To: <IZKluRfiLnIovyrAw3TdXDSzB6e59nHmG3ee7PEtjSE=.a778bb70-9938-4599-a3d9-9ad8fa235b00@github.com>
References: <XlU5gCBUEa4qTTz8yhMeElh95FuiPcFYQ_nj_WYvbLE=.6e9fc6a4-f3b1-4faf-91f0-d8b06f875780@github.com>
 <5PpEoJT1JZoo75hz4HAQFkipRfXCr_7MyTE8g4yhhgc=.5eeefcfe-205b-4b02-a59b-bead8b410139@github.com>
 <IZKluRfiLnIovyrAw3TdXDSzB6e59nHmG3ee7PEtjSE=.a778bb70-9938-4599-a3d9-9ad8fa235b00@github.com>
Message-ID: <D-BolUEcvPGEA-JzbvXEUQTtaxUbl7duhesuVERIZc4=.4edfe8a0-8284-45cf-a2ad-993d795b14b6@github.com>

On Mon, 26 Jul 2021 23:59:05 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Markus KARG 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/nio/ch/ChannelInputStream.java line 179:
> 
>> 177:             for (long n = srcSize - srcPos; bytesWritten < n;)
>> 178:                 bytesWritten += src.transferTo(srcPos + bytesWritten, Long.MAX_VALUE, dest);
>> 179:             return bytesWritten;
> 
> If `src` is extended at an inconvenient point in time, for example between the return from a call to `src.transferTo()` that makes `bytesWritten < n` false and the evaluation of that terminating condition, then it appears that not all the content of `src` will be transferred to `dest`. I am not however sure that this violates any contract but it could be a behavioral change from the existing implementation.

The JavaDocs in `InputStream::transferTo` *cleary* tell the caller that there is **no** guarantee of *any* specific behavior in that particular case: 
>The behavior for the case where the input and/or output stream is asynchronously closed, or the thread interrupted during the transfer, is highly input and output stream specific, and therefore not specified.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4263

From daniel.peintner at gmail.com  Thu Jul 29 08:36:49 2021
From: daniel.peintner at gmail.com (Daniel Peintner)
Date: Thu, 29 Jul 2021 10:36:49 +0200
Subject: jpackage MacOS Notarization
In-Reply-To: <9d2ab55d-7ab7-b4a9-d49d-3f8e92e8da6a@oracle.com>
References: <CAAoP7T5tO86Lt+WbwGv5iLuFcNRNgxsyCLaynQpUcAEkeqW-Zg@mail.gmail.com>
 <9d2ab55d-7ab7-b4a9-d49d-3f8e92e8da6a@oracle.com>
Message-ID: <CAAoP7T6x61mQsK+8NMn2APK7LtUHjnU0QLV3XpeZvgqNM-uM5w@mail.gmail.com>

Kevin, Andy,

Thanks for your quick response.

Full support for notarization in jpackage was added in JDK 17. Can you
> try an early access build of JDK 17 [1] and see if that works for you?
>

I did try JDK17-ea-32 also with the same result.

Since I do understand it is difficult reproduce the problem I put together
a *very* simple test application which you can find in the "non-modular"
branch here:
https://github.com/danielpeintner/Java11Test/tree/non-modular

It is a gradle project. It uses Java 11 to run but in build.gradle on
line#83 [1] one can set the jpackage location (JDK17-ea-32 in this case).

The process is as follows
* ./gradlew build
* ./gradlew jpackage    // creates the dmg/pkg in folder build/jpackage
* afterwards Apple notarization process can be started

Note: notarization of dmg or pkg lead to the same failure.
See [2] for the full log w.r.t. pkg.

I hope this helps you to be able to reproduce the issue.

Thanks for your investigations!

-- Daniel

[1]
https://github.com/danielpeintner/Java11Test/blob/6e5f34b1a0ba9c1e8ba1f6b15d6915237d8f5b7e/build.gradle#L83
[2]
https://osxapps-ssl.itunes.apple.com/itunes-assets/Enigma115/v4/90/4a/11/904a111c-01c7-ecc1-466c-40e7e8a09c56/developer_log.json?accessKey=1627741411_2564804966498057981_aHPs%2Fq9bzxGsY5Kd46U1QyWR8hmHJjLJLbUPpbvBqinIjiylTLsQy1APCJPkNN2w%2BZknT9OCl6zkzAyUm99EIBrm6tnOkZoWiwNG7TyukwCtAnIh%2FGpNAkLYfBpyDYjMaf7jQq8JekzxjYewhFuPDcJufWNrfuEX%2FN6zZoyz73I%3D


>
>
> -- Kevin
>
> [1] https://jdk.java.net/17
>
> On 7/28/2021 8:27 AM, Daniel Peintner wrote:
> > All,
> >
> > I am trying to notarize an app (built with jpackage) for MacOS.
> >
> > jpackage at first *seems* to properly sign all resources with the
> available
> > --mac-sign options et cetera.
> >
> > Having said that, there are still remaining issues
> > 1. The app cannot be properly installed
> >     (without hacks like xattr -d com.apple.quarantine
> /Applications/myAPP.app
> > ).
> > 2. I am also not able to properly notarize the app.
> >
> > According to online resources there seem to exist issues in *past* about
> > notarization but according to [1, 2] the issues are fixed.
> >
> > As mentioned, I still have issues :-(
> > Am I really the only one still having problems?
> >
> > Java Version: AdoptOpenJDK-16.0.1+9 (tried Oracle JDK also without
> success)
> >
> > The issue seems to boil down to 2 errors (attached the error log from
> Apple
> > notarization process).
> > * app Folder
> > * libjli.dylib
> >
> > I thought I better ask first on the mailing list before creating an
> actual
> > bug report.
> >
> > Note1: I used to use the *old* javapackager that worked with the same
> > signature/credentials.
> > Note2: running jpackage without --mac-sign options causes many more
> errors
> > in notarization (Hence, jpackage signs most resources but fails with
> some)
> >
> > Any help / hint appreciated.
> >
> > Thanks,
> >
> > -- Daniel
> >
> > [1] https://bugs.openjdk.java.net/browse/JDK-8257488
> > [2] https://bugs.openjdk.java.net/browse/JDK-8251892
> >
> >
> >
> > ## APPLE LOG ##
> >
> > {
> >    "logFormatVersion": 1,
> >    "jobId": "...",
> >    "status": "Invalid",
> >    "statusSummary": "Archive contains critical validation errors",
> >    "statusCode": 4000,
> >    "archiveFilename": "myAPP-21.07.28.dmg",
> >    "uploadDate": "2021-07-28T14:31:24Z",
> >    "sha256": "...",
> >    "ticketContents": null,
> >    "issues": [
> >      {
> >        "severity": "error",
> >        "code": null,
> >        "path": "myAPP-21.07.28.dmg/myAPP.app/Contents/MacOS/myAPP",
> >        "message": "The signature of the binary is invalid.",
> >        "docUrl": null,
> >        "architecture": "x86_64"
> >      },
> >      {
> >        "severity": "error",
> >        "code": null,
> >        "path":
> "myAPP-21.07.28.dmg/myAPP.app/Contents/runtime/Contents/MacOS/libjli.dylib",
> >        "message": "The signature of the binary is invalid.",
> >        "docUrl": null,
> >        "architecture": "x86_64"
> >      }
> >    ]
> > }
>
>

From andy.herrick at oracle.com  Thu Jul 29 13:29:09 2021
From: andy.herrick at oracle.com (Andy Herrick)
Date: Thu, 29 Jul 2021 09:29:09 -0400
Subject: [External] : Re: jpackage MacOS Notarization
In-Reply-To: <CAAoP7T6x61mQsK+8NMn2APK7LtUHjnU0QLV3XpeZvgqNM-uM5w@mail.gmail.com>
References: <CAAoP7T5tO86Lt+WbwGv5iLuFcNRNgxsyCLaynQpUcAEkeqW-Zg@mail.gmail.com>
 <9d2ab55d-7ab7-b4a9-d49d-3f8e92e8da6a@oracle.com>
 <CAAoP7T6x61mQsK+8NMn2APK7LtUHjnU0QLV3XpeZvgqNM-uM5w@mail.gmail.com>
Message-ID: <acd8140d-8d76-89bf-38d5-3c480f7bde48@oracle.com>

The 'build.gradle' in this branch has --mac-signing-key-user-name 
commented out.

> ??????????? installerOptions += [
> ??????????????? '--mac-sign',
> ??????????????? // 
> '--mac-s'SIGNING_KEY_USER_NAME'igning-key-user-name', 
> System.getenv('SIGNING_KEY_USER_NAME'),
> ??????????????? // '--mac-signing-keychain', 
> System.getenv('SIGNING_KEYCHAIN_PATH')
> ??????????? ]

clearly this cannot work, I assume you were just trying things ...

What is the full name of the certificate you intended to use, what 
keychain is it shown in "Keychain Access", and what are you normal 
values for your environment variables: 'SIGNING_KEY_USER_NAME' and 
'SIGNING_KEYCHAIN_PATH' ?

/Andy

On 7/29/2021 4:36 AM, Daniel Peintner wrote:
> Kevin, Andy,
>
> Thanks for your quick?response.
>
>     Full support for notarization in jpackage was added in JDK 17. Can
>     you
>     try an early access build of JDK 17 [1] and see if that works for you?
>
>
> I did try JDK17-ea-32 also with the same result.
>
> Since I do understand it is difficult reproduce the problem I put 
> together a *very* simple test application which you can find in the 
> "non-modular" branch here:
> https://github.com/danielpeintner/Java11Test/tree/non-modular 
> <https://urldefense.com/v3/__https://github.com/danielpeintner/Java11Test/tree/non-modular__;!!ACWV5N9M2RV99hQ!YvL54my0xzs3wyk7t0zm5Yq-EqGBosUDctM0AdcMUSubDbppL8XZzIJ3AE2ZACADEA$>
>
> It is a gradle project. It uses Java 11 to run but in build.gradle on 
> line#83[1] one can set the jpackage?location (JDK17-ea-32 in this case).
>
> The process is as?follows
> * ./gradlew build
> *?./gradlew?jpackage??? // creates the dmg/pkg in folder build/jpackage
> * afterwards Apple?notarization?process can be started
>
> Note: notarization of dmg or pkg lead to the same failure.
> See [2] for the full log w.r.t. pkg.
>
> I hope this helps you to be able to reproduce the issue.
>
> Thanks for your investigations!
>
> -- Daniel
>
> [1] 
> https://github.com/danielpeintner/Java11Test/blob/6e5f34b1a0ba9c1e8ba1f6b15d6915237d8f5b7e/build.gradle#L83 
> <https://urldefense.com/v3/__https://github.com/danielpeintner/Java11Test/blob/6e5f34b1a0ba9c1e8ba1f6b15d6915237d8f5b7e/build.gradle*L83__;Iw!!ACWV5N9M2RV99hQ!YvL54my0xzs3wyk7t0zm5Yq-EqGBosUDctM0AdcMUSubDbppL8XZzIJ3AE03e0qq7A$>
> [2] 
> https://osxapps-ssl.itunes.apple.com/itunes-assets/Enigma115/v4/90/4a/11/904a111c-01c7-ecc1-466c-40e7e8a09c56/developer_log.json?accessKey=1627741411_2564804966498057981_aHPs%2Fq9bzxGsY5Kd46U1QyWR8hmHJjLJLbUPpbvBqinIjiylTLsQy1APCJPkNN2w%2BZknT9OCl6zkzAyUm99EIBrm6tnOkZoWiwNG7TyukwCtAnIh%2FGpNAkLYfBpyDYjMaf7jQq8JekzxjYewhFuPDcJufWNrfuEX%2FN6zZoyz73I%3D 
> <https://urldefense.com/v3/__https://osxapps-ssl.itunes.apple.com/itunes-assets/Enigma115/v4/90/4a/11/904a111c-01c7-ecc1-466c-40e7e8a09c56/developer_log.json?accessKey=1627741411_2564804966498057981_aHPs*2Fq9bzxGsY5Kd46U1QyWR8hmHJjLJLbUPpbvBqinIjiylTLsQy1APCJPkNN2w*2BZknT9OCl6zkzAyUm99EIBrm6tnOkZoWiwNG7TyukwCtAnIh*2FGpNAkLYfBpyDYjMaf7jQq8JekzxjYewhFuPDcJufWNrfuEX*2FN6zZoyz73I*3D__;JSUlJSU!!ACWV5N9M2RV99hQ!YvL54my0xzs3wyk7t0zm5Yq-EqGBosUDctM0AdcMUSubDbppL8XZzIJ3AE0bBsP8Hg$>
>
>
>     -- Kevin
>
>     [1] https://jdk.java.net/17
>     <https://urldefense.com/v3/__https://jdk.java.net/17__;!!ACWV5N9M2RV99hQ!YvL54my0xzs3wyk7t0zm5Yq-EqGBosUDctM0AdcMUSubDbppL8XZzIJ3AE0PgDN5dA$>
>
>     On 7/28/2021 8:27 AM, Daniel Peintner wrote:
>     > All,
>     >
>     > I am trying to notarize an app (built with jpackage) for MacOS.
>     >
>     > jpackage at first *seems* to properly sign all resources with
>     the available
>     > --mac-sign options et cetera.
>     >
>     > Having said that, there are still remaining issues
>     > 1. The app cannot be properly installed
>     >? ? ?(without hacks like xattr -d com.apple.quarantine
>     /Applications/myAPP.app
>     > ).
>     > 2. I am also not able to properly notarize the app.
>     >
>     > According to online resources there seem to exist issues in
>     *past* about
>     > notarization but according to [1, 2] the issues are fixed.
>     >
>     > As mentioned, I still have issues :-(
>     > Am I really the only one still having problems?
>     >
>     > Java Version: AdoptOpenJDK-16.0.1+9 (tried Oracle JDK also
>     without success)
>     >
>     > The issue seems to boil down to 2 errors (attached the error log
>     from Apple
>     > notarization process).
>     > * app Folder
>     > * libjli.dylib
>     >
>     > I thought I better ask first on the mailing list before creating
>     an actual
>     > bug report.
>     >
>     > Note1: I used to use the *old* javapackager that worked with the
>     same
>     > signature/credentials.
>     > Note2: running jpackage without --mac-sign options causes many
>     more errors
>     > in notarization (Hence, jpackage signs most resources but fails
>     with some)
>     >
>     > Any help / hint appreciated.
>     >
>     > Thanks,
>     >
>     > -- Daniel
>     >
>     > [1] https://bugs.openjdk.java.net/browse/JDK-8257488
>     <https://bugs.openjdk.java.net/browse/JDK-8257488>
>     > [2] https://bugs.openjdk.java.net/browse/JDK-8251892
>     <https://bugs.openjdk.java.net/browse/JDK-8251892>
>     >
>     >
>     >
>     > ## APPLE LOG ##
>     >
>     > {
>     >? ? "logFormatVersion": 1,
>     >? ? "jobId": "...",
>     >? ? "status": "Invalid",
>     >? ? "statusSummary": "Archive contains critical validation errors",
>     >? ? "statusCode": 4000,
>     >? ? "archiveFilename": "myAPP-21.07.28.dmg",
>     >? ? "uploadDate": "2021-07-28T14:31:24Z",
>     >? ? "sha256": "...",
>     >? ? "ticketContents": null,
>     >? ? "issues": [
>     >? ? ? {
>     >? ? ? ? "severity": "error",
>     >? ? ? ? "code": null,
>     >? ? ? ? "path": "myAPP-21.07.28.dmg/myAPP.app/Contents/MacOS/myAPP",
>     >? ? ? ? "message": "The signature of the binary is invalid.",
>     >? ? ? ? "docUrl": null,
>     >? ? ? ? "architecture": "x86_64"
>     >? ? ? },
>     >? ? ? {
>     >? ? ? ? "severity": "error",
>     >? ? ? ? "code": null,
>     >? ? ? ? "path":
>     "myAPP-21.07.28.dmg/myAPP.app/Contents/runtime/Contents/MacOS/libjli.dylib",
>     >? ? ? ? "message": "The signature of the binary is invalid.",
>     >? ? ? ? "docUrl": null,
>     >? ? ? ? "architecture": "x86_64"
>     >? ? ? }
>     >? ? ]
>     > }
>

From daniel.peintner at gmail.com  Thu Jul 29 14:00:47 2021
From: daniel.peintner at gmail.com (Daniel Peintner)
Date: Thu, 29 Jul 2021 16:00:47 +0200
Subject: [External] : Re: jpackage MacOS Notarization
In-Reply-To: <acd8140d-8d76-89bf-38d5-3c480f7bde48@oracle.com>
References: <CAAoP7T5tO86Lt+WbwGv5iLuFcNRNgxsyCLaynQpUcAEkeqW-Zg@mail.gmail.com>
 <9d2ab55d-7ab7-b4a9-d49d-3f8e92e8da6a@oracle.com>
 <CAAoP7T6x61mQsK+8NMn2APK7LtUHjnU0QLV3XpeZvgqNM-uM5w@mail.gmail.com>
 <acd8140d-8d76-89bf-38d5-3c480f7bde48@oracle.com>
Message-ID: <CAAoP7T5rJf10agh-dxwSJHVr_phpAxF7q9O+fOCquY1g7BTcaQ@mail.gmail.com>

Hi Andy,

Since I don't know your setup I did not put anything there.

'--mac-sign' is enough to use the defaults in my setup.

It looks for the signing keys installed on my machine that start with
"Developer
ID Application " similar to
'--mac-signing-key-user-name', 'Developer ID Application: '
etc.

If you want to test it you need to add your credentials which I do not know.

Hope this clarifies things,

-- Daniel



On Thu, Jul 29, 2021 at 3:29 PM Andy Herrick <andy.herrick at oracle.com>
wrote:

> The 'build.gradle' in this branch has --mac-signing-key-user-name
> commented out.
>
>             installerOptions += [
>                 '--mac-sign',
>                 // '--mac-s'SIGNING_KEY_USER_NAME'igning-key-user-name',
> System.getenv('SIGNING_KEY_USER_NAME'),
>                 // '--mac-signing-keychain',
> System.getenv('SIGNING_KEYCHAIN_PATH')
>             ]
>
> clearly this cannot work, I assume you were just trying things ...
>
> What is the full name of the certificate you intended to use, what
> keychain is it shown in "Keychain Access", and what are you normal values
> for your environment variables: 'SIGNING_KEY_USER_NAME' and
> 'SIGNING_KEYCHAIN_PATH' ?
>
> /Andy
> On 7/29/2021 4:36 AM, Daniel Peintner wrote:
>
> Kevin, Andy,
>
> Thanks for your quick response.
>
> Full support for notarization in jpackage was added in JDK 17. Can you
>> try an early access build of JDK 17 [1] and see if that works for you?
>>
>
> I did try JDK17-ea-32 also with the same result.
>
> Since I do understand it is difficult reproduce the problem I put together
> a *very* simple test application which you can find in the "non-modular"
> branch here:
> https://github.com/danielpeintner/Java11Test/tree/non-modular
> <https://urldefense.com/v3/__https://github.com/danielpeintner/Java11Test/tree/non-modular__;!!ACWV5N9M2RV99hQ!YvL54my0xzs3wyk7t0zm5Yq-EqGBosUDctM0AdcMUSubDbppL8XZzIJ3AE2ZACADEA$>
>
> It is a gradle project. It uses Java 11 to run but in build.gradle on
> line#83 [1] one can set the jpackage location (JDK17-ea-32 in this case).
>
> The process is as follows
> * ./gradlew build
> * ./gradlew jpackage    // creates the dmg/pkg in folder build/jpackage
> * afterwards Apple notarization process can be started
>
> Note: notarization of dmg or pkg lead to the same failure.
> See [2] for the full log w.r.t. pkg.
>
> I hope this helps you to be able to reproduce the issue.
>
> Thanks for your investigations!
>
> -- Daniel
>
> [1]
> https://github.com/danielpeintner/Java11Test/blob/6e5f34b1a0ba9c1e8ba1f6b15d6915237d8f5b7e/build.gradle#L83
> <https://urldefense.com/v3/__https://github.com/danielpeintner/Java11Test/blob/6e5f34b1a0ba9c1e8ba1f6b15d6915237d8f5b7e/build.gradle*L83__;Iw!!ACWV5N9M2RV99hQ!YvL54my0xzs3wyk7t0zm5Yq-EqGBosUDctM0AdcMUSubDbppL8XZzIJ3AE03e0qq7A$>
> [2]
> https://osxapps-ssl.itunes.apple.com/itunes-assets/Enigma115/v4/90/4a/11/904a111c-01c7-ecc1-466c-40e7e8a09c56/developer_log.json?accessKey=1627741411_2564804966498057981_aHPs%2Fq9bzxGsY5Kd46U1QyWR8hmHJjLJLbUPpbvBqinIjiylTLsQy1APCJPkNN2w%2BZknT9OCl6zkzAyUm99EIBrm6tnOkZoWiwNG7TyukwCtAnIh%2FGpNAkLYfBpyDYjMaf7jQq8JekzxjYewhFuPDcJufWNrfuEX%2FN6zZoyz73I%3D
> <https://urldefense.com/v3/__https://osxapps-ssl.itunes.apple.com/itunes-assets/Enigma115/v4/90/4a/11/904a111c-01c7-ecc1-466c-40e7e8a09c56/developer_log.json?accessKey=1627741411_2564804966498057981_aHPs*2Fq9bzxGsY5Kd46U1QyWR8hmHJjLJLbUPpbvBqinIjiylTLsQy1APCJPkNN2w*2BZknT9OCl6zkzAyUm99EIBrm6tnOkZoWiwNG7TyukwCtAnIh*2FGpNAkLYfBpyDYjMaf7jQq8JekzxjYewhFuPDcJufWNrfuEX*2FN6zZoyz73I*3D__;JSUlJSU!!ACWV5N9M2RV99hQ!YvL54my0xzs3wyk7t0zm5Yq-EqGBosUDctM0AdcMUSubDbppL8XZzIJ3AE0bBsP8Hg$>
>
>
>>
>>
>> -- Kevin
>>
>> [1] https://jdk.java.net/17
>> <https://urldefense.com/v3/__https://jdk.java.net/17__;!!ACWV5N9M2RV99hQ!YvL54my0xzs3wyk7t0zm5Yq-EqGBosUDctM0AdcMUSubDbppL8XZzIJ3AE0PgDN5dA$>
>>
>> On 7/28/2021 8:27 AM, Daniel Peintner wrote:
>> > All,
>> >
>> > I am trying to notarize an app (built with jpackage) for MacOS.
>> >
>> > jpackage at first *seems* to properly sign all resources with the
>> available
>> > --mac-sign options et cetera.
>> >
>> > Having said that, there are still remaining issues
>> > 1. The app cannot be properly installed
>> >     (without hacks like xattr -d com.apple.quarantine
>> /Applications/myAPP.app
>> > ).
>> > 2. I am also not able to properly notarize the app.
>> >
>> > According to online resources there seem to exist issues in *past* about
>> > notarization but according to [1, 2] the issues are fixed.
>> >
>> > As mentioned, I still have issues :-(
>> > Am I really the only one still having problems?
>> >
>> > Java Version: AdoptOpenJDK-16.0.1+9 (tried Oracle JDK also without
>> success)
>> >
>> > The issue seems to boil down to 2 errors (attached the error log from
>> Apple
>> > notarization process).
>> > * app Folder
>> > * libjli.dylib
>> >
>> > I thought I better ask first on the mailing list before creating an
>> actual
>> > bug report.
>> >
>> > Note1: I used to use the *old* javapackager that worked with the same
>> > signature/credentials.
>> > Note2: running jpackage without --mac-sign options causes many more
>> errors
>> > in notarization (Hence, jpackage signs most resources but fails with
>> some)
>> >
>> > Any help / hint appreciated.
>> >
>> > Thanks,
>> >
>> > -- Daniel
>> >
>> > [1] https://bugs.openjdk.java.net/browse/JDK-8257488
>> > [2] https://bugs.openjdk.java.net/browse/JDK-8251892
>> >
>> >
>> >
>> > ## APPLE LOG ##
>> >
>> > {
>> >    "logFormatVersion": 1,
>> >    "jobId": "...",
>> >    "status": "Invalid",
>> >    "statusSummary": "Archive contains critical validation errors",
>> >    "statusCode": 4000,
>> >    "archiveFilename": "myAPP-21.07.28.dmg",
>> >    "uploadDate": "2021-07-28T14:31:24Z",
>> >    "sha256": "...",
>> >    "ticketContents": null,
>> >    "issues": [
>> >      {
>> >        "severity": "error",
>> >        "code": null,
>> >        "path": "myAPP-21.07.28.dmg/myAPP.app/Contents/MacOS/myAPP",
>> >        "message": "The signature of the binary is invalid.",
>> >        "docUrl": null,
>> >        "architecture": "x86_64"
>> >      },
>> >      {
>> >        "severity": "error",
>> >        "code": null,
>> >        "path":
>> "myAPP-21.07.28.dmg/myAPP.app/Contents/runtime/Contents/MacOS/libjli.dylib",
>> >        "message": "The signature of the binary is invalid.",
>> >        "docUrl": null,
>> >        "architecture": "x86_64"
>> >      }
>> >    ]
>> > }
>>
>>

From andy.herrick at oracle.com  Thu Jul 29 15:58:09 2021
From: andy.herrick at oracle.com (Andy Herrick)
Date: Thu, 29 Jul 2021 11:58:09 -0400
Subject: [External] : Re: jpackage MacOS Notarization
In-Reply-To: <CAAoP7T5rJf10agh-dxwSJHVr_phpAxF7q9O+fOCquY1g7BTcaQ@mail.gmail.com>
References: <CAAoP7T5tO86Lt+WbwGv5iLuFcNRNgxsyCLaynQpUcAEkeqW-Zg@mail.gmail.com>
 <9d2ab55d-7ab7-b4a9-d49d-3f8e92e8da6a@oracle.com>
 <CAAoP7T6x61mQsK+8NMn2APK7LtUHjnU0QLV3XpeZvgqNM-uM5w@mail.gmail.com>
 <acd8140d-8d76-89bf-38d5-3c480f7bde48@oracle.com>
 <CAAoP7T5rJf10agh-dxwSJHVr_phpAxF7q9O+fOCquY1g7BTcaQ@mail.gmail.com>
Message-ID: <7092667d-6ac9-1e82-27e4-3bca64fd5a8b@oracle.com>

sorry - code looks for certificate key starting with: "Developer ID 
Application: " + <value of mac-signing-key-user-name> in order to not 
have to put full user name in.? I missed that that with null user name 
that causes it to look for anything starting with "Developer ID 
Application: " (same thing with "Developer ID Installer: " for .pkg 
signing).? And macos? looks at the non-default keychains as well as the 
default ones when no keychain is specified.

/Andy

On 7/29/2021 10:00 AM, Daniel Peintner wrote:
> Hi Andy,
>
> Since I don't know your setup I did not put anything there.
>
> '--mac-sign' is enough to use the defaults in my setup.
>
> It looks for the signing keys installed on my machine that start with 
> "Developer ID Application " similar to
> '--mac-signing-key-user-name', 'Developer ID Application: '
> etc.
>
> If you want to test it you need to add your credentials which I do not 
> know.
>
> Hope this clarifies things,
>
> -- Daniel
>
>
>
> On Thu, Jul 29, 2021 at 3:29 PM Andy Herrick <andy.herrick at oracle.com 
> <mailto:andy.herrick at oracle.com>> wrote:
>
>     The 'build.gradle' in this branch has --mac-signing-key-user-name
>     commented out.
>
>>     ??????????? installerOptions += [
>>     ??????????????? '--mac-sign',
>>     ??????????????? //
>>     '--mac-s'SIGNING_KEY_USER_NAME'igning-key-user-name',
>>     System.getenv('SIGNING_KEY_USER_NAME'),
>>     ??????????????? // '--mac-signing-keychain',
>>     System.getenv('SIGNING_KEYCHAIN_PATH')
>>     ??????????? ]
>
>     clearly this cannot work, I assume you were just trying things ...
>
>     What is the full name of the certificate you intended to use, what
>     keychain is it shown in "Keychain Access", and what are you normal
>     values for your environment variables: 'SIGNING_KEY_USER_NAME' and
>     'SIGNING_KEYCHAIN_PATH' ?
>
>     /Andy
>
>     On 7/29/2021 4:36 AM, Daniel Peintner wrote:
>>     Kevin, Andy,
>>
>>     Thanks for your quick?response.
>>
>>         Full support for notarization in jpackage was added in JDK
>>         17. Can you
>>         try an early access build of JDK 17 [1] and see if that works
>>         for you?
>>
>>
>>     I did try JDK17-ea-32 also with the same result.
>>
>>     Since I do understand it is difficult reproduce the problem I put
>>     together a *very* simple test application which you can find in
>>     the "non-modular" branch here:
>>     https://github.com/danielpeintner/Java11Test/tree/non-modular
>>     <https://urldefense.com/v3/__https://github.com/danielpeintner/Java11Test/tree/non-modular__;!!ACWV5N9M2RV99hQ!YvL54my0xzs3wyk7t0zm5Yq-EqGBosUDctM0AdcMUSubDbppL8XZzIJ3AE2ZACADEA$>
>>
>>     It is a gradle project. It uses Java 11 to run but in
>>     build.gradle on line#83[1] one can set the jpackage?location
>>     (JDK17-ea-32 in this case).
>>
>>     The process is as?follows
>>     * ./gradlew build
>>     *?./gradlew?jpackage??? // creates the dmg/pkg in folder
>>     build/jpackage
>>     * afterwards Apple?notarization?process can be started
>>
>>     Note: notarization of dmg or pkg lead to the same failure.
>>     See [2] for the full log w.r.t. pkg.
>>
>>     I hope this helps you to be able to reproduce the issue.
>>
>>     Thanks for your investigations!
>>
>>     -- Daniel
>>
>>     [1]
>>     https://github.com/danielpeintner/Java11Test/blob/6e5f34b1a0ba9c1e8ba1f6b15d6915237d8f5b7e/build.gradle#L83
>>     <https://urldefense.com/v3/__https://github.com/danielpeintner/Java11Test/blob/6e5f34b1a0ba9c1e8ba1f6b15d6915237d8f5b7e/build.gradle*L83__;Iw!!ACWV5N9M2RV99hQ!YvL54my0xzs3wyk7t0zm5Yq-EqGBosUDctM0AdcMUSubDbppL8XZzIJ3AE03e0qq7A$>
>>     [2]
>>     https://osxapps-ssl.itunes.apple.com/itunes-assets/Enigma115/v4/90/4a/11/904a111c-01c7-ecc1-466c-40e7e8a09c56/developer_log.json?accessKey=1627741411_2564804966498057981_aHPs%2Fq9bzxGsY5Kd46U1QyWR8hmHJjLJLbUPpbvBqinIjiylTLsQy1APCJPkNN2w%2BZknT9OCl6zkzAyUm99EIBrm6tnOkZoWiwNG7TyukwCtAnIh%2FGpNAkLYfBpyDYjMaf7jQq8JekzxjYewhFuPDcJufWNrfuEX%2FN6zZoyz73I%3D
>>     <https://urldefense.com/v3/__https://osxapps-ssl.itunes.apple.com/itunes-assets/Enigma115/v4/90/4a/11/904a111c-01c7-ecc1-466c-40e7e8a09c56/developer_log.json?accessKey=1627741411_2564804966498057981_aHPs*2Fq9bzxGsY5Kd46U1QyWR8hmHJjLJLbUPpbvBqinIjiylTLsQy1APCJPkNN2w*2BZknT9OCl6zkzAyUm99EIBrm6tnOkZoWiwNG7TyukwCtAnIh*2FGpNAkLYfBpyDYjMaf7jQq8JekzxjYewhFuPDcJufWNrfuEX*2FN6zZoyz73I*3D__;JSUlJSU!!ACWV5N9M2RV99hQ!YvL54my0xzs3wyk7t0zm5Yq-EqGBosUDctM0AdcMUSubDbppL8XZzIJ3AE0bBsP8Hg$>
>>
>>
>>         -- Kevin
>>
>>         [1] https://jdk.java.net/17
>>         <https://urldefense.com/v3/__https://jdk.java.net/17__;!!ACWV5N9M2RV99hQ!YvL54my0xzs3wyk7t0zm5Yq-EqGBosUDctM0AdcMUSubDbppL8XZzIJ3AE0PgDN5dA$>
>>
>>         On 7/28/2021 8:27 AM, Daniel Peintner wrote:
>>         > All,
>>         >
>>         > I am trying to notarize an app (built with jpackage) for MacOS.
>>         >
>>         > jpackage at first *seems* to properly sign all resources
>>         with the available
>>         > --mac-sign options et cetera.
>>         >
>>         > Having said that, there are still remaining issues
>>         > 1. The app cannot be properly installed
>>         >? ? ?(without hacks like xattr -d com.apple.quarantine
>>         /Applications/myAPP.app
>>         > ).
>>         > 2. I am also not able to properly notarize the app.
>>         >
>>         > According to online resources there seem to exist issues in
>>         *past* about
>>         > notarization but according to [1, 2] the issues are fixed.
>>         >
>>         > As mentioned, I still have issues :-(
>>         > Am I really the only one still having problems?
>>         >
>>         > Java Version: AdoptOpenJDK-16.0.1+9 (tried Oracle JDK also
>>         without success)
>>         >
>>         > The issue seems to boil down to 2 errors (attached the
>>         error log from Apple
>>         > notarization process).
>>         > * app Folder
>>         > * libjli.dylib
>>         >
>>         > I thought I better ask first on the mailing list before
>>         creating an actual
>>         > bug report.
>>         >
>>         > Note1: I used to use the *old* javapackager that worked
>>         with the same
>>         > signature/credentials.
>>         > Note2: running jpackage without --mac-sign options causes
>>         many more errors
>>         > in notarization (Hence, jpackage signs most resources but
>>         fails with some)
>>         >
>>         > Any help / hint appreciated.
>>         >
>>         > Thanks,
>>         >
>>         > -- Daniel
>>         >
>>         > [1] https://bugs.openjdk.java.net/browse/JDK-8257488
>>         <https://bugs.openjdk.java.net/browse/JDK-8257488>
>>         > [2] https://bugs.openjdk.java.net/browse/JDK-8251892
>>         <https://bugs.openjdk.java.net/browse/JDK-8251892>
>>         >
>>         >
>>         >
>>         > ## APPLE LOG ##
>>         >
>>         > {
>>         >? ? "logFormatVersion": 1,
>>         >? ? "jobId": "...",
>>         >? ? "status": "Invalid",
>>         >? ? "statusSummary": "Archive contains critical validation
>>         errors",
>>         >? ? "statusCode": 4000,
>>         >? ? "archiveFilename": "myAPP-21.07.28.dmg",
>>         >? ? "uploadDate": "2021-07-28T14:31:24Z",
>>         >? ? "sha256": "...",
>>         >? ? "ticketContents": null,
>>         >? ? "issues": [
>>         >? ? ? {
>>         >? ? ? ? "severity": "error",
>>         >? ? ? ? "code": null,
>>         >? ? ? ? "path":
>>         "myAPP-21.07.28.dmg/myAPP.app/Contents/MacOS/myAPP",
>>         >? ? ? ? "message": "The signature of the binary is invalid.",
>>         >? ? ? ? "docUrl": null,
>>         >? ? ? ? "architecture": "x86_64"
>>         >? ? ? },
>>         >? ? ? {
>>         >? ? ? ? "severity": "error",
>>         >? ? ? ? "code": null,
>>         >? ? ? ? "path":
>>         "myAPP-21.07.28.dmg/myAPP.app/Contents/runtime/Contents/MacOS/libjli.dylib",
>>         >? ? ? ? "message": "The signature of the binary is invalid.",
>>         >? ? ? ? "docUrl": null,
>>         >? ? ? ? "architecture": "x86_64"
>>         >? ? ? }
>>         >? ? ]
>>         > }
>>

From jboes at openjdk.java.net  Thu Jul 29 15:58:29 2021
From: jboes at openjdk.java.net (Julia Boes)
Date: Thu, 29 Jul 2021 15:58:29 GMT
Subject: RFR: 8271396: Spelling errors
In-Reply-To: <al0SRVpmZ3Jta5hZkVrGWCBNM9X330njP-87Gtj2Xrk=.d7a1bea3-1b54-4084-be08-831b4eff898b@github.com>
References: <U-l1fZ9G8ctKEjq6IdJJBGXJzJJeI4JUjaemwOzhdHo=.1e30f73c-cf88-4394-b59f-98aa5664c9db@github.com>
 <qsybKx5QEt_0qEvwE9hXSUZrCdY6FSAfBAINYLqbtvM=.2d27e252-6d6e-4070-9127-f9d257e4ea54@github.com>
 <ECY56wmiBbQOh06b4r_yI7IykEom57iFFgIQNnhQMGY=.a16517dc-67bc-43a6-b0ef-d1eab0d6970a@github.com>
 <c8D3av6T1vVqUc0YgytVzPMZoVwmk3pAQwgCU9OaTGY=.88b57352-b1a0-4563-b651-6f624560dbe7@github.com>
 <al0SRVpmZ3Jta5hZkVrGWCBNM9X330njP-87Gtj2Xrk=.d7a1bea3-1b54-4084-be08-831b4eff898b@github.com>
Message-ID: <6pKjSeljbRVUY95MMl6XydDzNvJde-Pa1DSN6OfM7mM=.8b5ea3f5-dce4-49d3-8090-023734e19061@github.com>

On Wed, 28 Jul 2021 17:23:51 GMT, Emmanuel Bourg <github.com+54304+ebourg at openjdk.org> wrote:

>> @ebourg for future PRs please do not force push after the PR is out for review. Just push incremental commits normally. The Skara tooling will squash them all into a single commit.
>
> @kevinrushforth I'll do that, thank you for the hint

@ebourg Thanks for updating the copyright. If you integrate again, I can sponsor.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2385

From github.com+54304+ebourg at openjdk.java.net  Thu Jul 29 16:06:37 2021
From: github.com+54304+ebourg at openjdk.java.net (Emmanuel Bourg)
Date: Thu, 29 Jul 2021 16:06:37 GMT
Subject: Integrated: 8271396: Spelling errors
In-Reply-To: <U-l1fZ9G8ctKEjq6IdJJBGXJzJJeI4JUjaemwOzhdHo=.1e30f73c-cf88-4394-b59f-98aa5664c9db@github.com>
References: <U-l1fZ9G8ctKEjq6IdJJBGXJzJJeI4JUjaemwOzhdHo=.1e30f73c-cf88-4394-b59f-98aa5664c9db@github.com>
Message-ID: <9uAMUJBjsby1KkwiwU8wrYEw0ozGjXD7Xnjil0nLoXg=.fd3b9a16-c42a-4806-a174-8b6b0b565abb@github.com>

On Wed, 3 Feb 2021 19:12:25 GMT, Emmanuel Bourg <github.com+54304+ebourg at openjdk.org> wrote:

> This PR fixes the following spelling errors:
> 
>  choosen  -> chosen
>  commad   -> command
>  hiearchy -> hierarchy
>  leagacy  -> legacy
>  minium   -> minimum
>  subsytem -> subsystem
>  unamed   -> unnamed

This pull request has now been integrated.

Changeset: d09b0284
Author:    Emmanuel Bourg <ebourg at apache.org>
Committer: Julia Boes <jboes at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d09b028407ff9d0e8c2dfd9cc5d0dca19c4497e3
Stats:     103 lines in 34 files changed: 0 ins; 0 del; 103 mod

8271396: Spelling errors

Reviewed-by: tschatzl, chegar, iris, psadhukhan, cjplummer

-------------

PR: https://git.openjdk.java.net/jdk/pull/2385

From github.com+54304+ebourg at openjdk.java.net  Thu Jul 29 16:11:36 2021
From: github.com+54304+ebourg at openjdk.java.net (Emmanuel Bourg)
Date: Thu, 29 Jul 2021 16:11:36 GMT
Subject: RFR: 8271396: Spelling errors [v2]
In-Reply-To: <axOY0lG3CInpykz-_Ur_wY8dRvr4QsfktJ9gD0vvirA=.c8302d67-79c3-4e99-853c-65701d049c4a@github.com>
References: <U-l1fZ9G8ctKEjq6IdJJBGXJzJJeI4JUjaemwOzhdHo=.1e30f73c-cf88-4394-b59f-98aa5664c9db@github.com>
 <axOY0lG3CInpykz-_Ur_wY8dRvr4QsfktJ9gD0vvirA=.c8302d67-79c3-4e99-853c-65701d049c4a@github.com>
Message-ID: <1IourDXaaOqLbUP1_8BfEui3NErozrWkUoBcYUmYAx8=.82ca7fd0-732d-41ab-ad90-8e77412b8ac2@github.com>

On Wed, 28 Jul 2021 17:12:04 GMT, Emmanuel Bourg <github.com+54304+ebourg at openjdk.org> wrote:

>> This PR fixes the following spelling errors:
>> 
>>  choosen  -> chosen
>>  commad   -> command
>>  hiearchy -> hierarchy
>>  leagacy  -> legacy
>>  minium   -> minimum
>>  subsytem -> subsystem
>>  unamed   -> unnamed
>
> Emmanuel Bourg has updated the pull request with a new target base 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:
> 
>   8271396: Fix spelling errors
>   
>    choosen  -> chosen
>    commad   -> command
>    hiearchy -> hierarchy
>    leagacy  -> legacy
>    minium   -> minimum
>    subsytem -> subsystem
>    unamed   -> unnamed

Thank you, glad to land my first commit to OpenJDK

-------------

PR: https://git.openjdk.java.net/jdk/pull/2385

From rriggs at openjdk.java.net  Thu Jul 29 16:44:55 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 29 Jul 2021 16:44:55 GMT
Subject: [jdk17] RFR: 8271489: (doc) Clarify Filter Factory example
Message-ID: <0p6tjDXve1NzwIv5CqU2RjJgL9R0t0Je8scHatsVlTU=.a49cd354-ca52-4a8c-8481-dde3431a4a27@github.com>

Improve the clarity of comments in the ObjectInputFilter FilterInThread example.

-------------

Commit messages:
 - 8271489: (doc) Clarify Filter Factory example
 - 8270398: Enhance canonicalization
 - 8270404: Better canonicalization
 - Merge
 - Merge
 - 8263531: Remove unused buffer int
 - 8262731: [macOS] Exception from "Printable.print" is swallowed during "PrinterJob.print"
 - 8269763: The JEditorPane is blank after JDK-8265167
 - 8265580: Enhanced style for RTF kit
 - 8265574: Improve handling of sheets
 - ... and 15 more: https://git.openjdk.java.net/jdk17/compare/c1304519...650e1561

Changes: https://git.openjdk.java.net/jdk17/pull/292/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=292&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8271489
  Stats: 1001 lines in 42 files changed: 625 ins; 181 del; 195 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/292.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/292/head:pull/292

PR: https://git.openjdk.java.net/jdk17/pull/292

From bpb at openjdk.java.net  Thu Jul 29 16:45:34 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 29 Jul 2021 16:45:34 GMT
Subject: RFR: 8265891: (ch) InputStream returned by
 Channels.newInputStream should override transferTo [v6]
In-Reply-To: <D-BolUEcvPGEA-JzbvXEUQTtaxUbl7duhesuVERIZc4=.4edfe8a0-8284-45cf-a2ad-993d795b14b6@github.com>
References: <XlU5gCBUEa4qTTz8yhMeElh95FuiPcFYQ_nj_WYvbLE=.6e9fc6a4-f3b1-4faf-91f0-d8b06f875780@github.com>
 <5PpEoJT1JZoo75hz4HAQFkipRfXCr_7MyTE8g4yhhgc=.5eeefcfe-205b-4b02-a59b-bead8b410139@github.com>
 <IZKluRfiLnIovyrAw3TdXDSzB6e59nHmG3ee7PEtjSE=.a778bb70-9938-4599-a3d9-9ad8fa235b00@github.com>
 <D-BolUEcvPGEA-JzbvXEUQTtaxUbl7duhesuVERIZc4=.4edfe8a0-8284-45cf-a2ad-993d795b14b6@github.com>
Message-ID: <UQzAp1eaWHObRgVpa8bwHLdbdyauIE9NdpDd-MwsvUM=.cd00637c-80bf-43da-8ab3-97825a7d92d0@github.com>

On Thu, 29 Jul 2021 08:12:23 GMT, Markus KARG <github.com+1701815+mkarg at openjdk.org> wrote:

>> src/java.base/share/classes/sun/nio/ch/ChannelInputStream.java line 179:
>> 
>>> 177:             for (long n = srcSize - srcPos; bytesWritten < n;)
>>> 178:                 bytesWritten += src.transferTo(srcPos + bytesWritten, Long.MAX_VALUE, dest);
>>> 179:             return bytesWritten;
>> 
>> If `src` is extended at an inconvenient point in time, for example between the return from a call to `src.transferTo()` that makes `bytesWritten < n` false and the evaluation of that terminating condition, then it appears that not all the content of `src` will be transferred to `dest`. I am not however sure that this violates any contract but it could be a behavioral change from the existing implementation.
>
> The JavaDocs in `InputStream::transferTo` *cleary* tell the caller that there is **no** guarantee of *any* specific behavior in that particular case: 
>>The behavior for the case where the input and/or output stream is asynchronously closed, or the thread interrupted during the transfer, is highly input and output stream specific, and therefore not specified.

Good point.

>> src/java.base/share/classes/sun/nio/ch/ChannelOutputStream.java line 85:
>> 
>>> 83:     private byte[] bs;       // Invoker's previous array
>>> 84:     private byte[] b1;
>>> 85: 
>> 
>> It might be better to put the field declarations at the beginning of the class before the static methods.
>
> This is a question of style and personal likes. Code maintenance is much easier if variables are defined *near* to its first use, not *far away* (as in the Pascal or C language). If the reviewers want me to change it, I will do it.

It's actually a matter of convention but I think it can remain as it is.

>> test/jdk/sun/nio/ch/ChannelInputStream/TransferTo.java line 67:
>> 
>>> 65:         test(readableByteChannelInput(), defaultOutput());
>>> 66:     }
>>> 67: 
>> 
>> This test looks like it's doing what it's supposed to do. I'm not asking to change it, but I think using TestNG might have given a simpler result with less work. For example, there could be one `DataProvider` supplying inputs which feed a `@Test` which expects an NPE, and another `DataProvider` supplying input-output pairs which feeds a `@Test` which validates the functionality.
>
> No doubt, using modern tools would have spared me work, and indeed I would have chosen JUnit or TestNG if there would be a clear commitment to that tool *upfront*. For now, I see now use in reworking the code afterwards.

No need to rework it now.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4263

From rriggs at openjdk.java.net  Thu Jul 29 17:46:36 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 29 Jul 2021 17:46:36 GMT
Subject: [jdk17] Withdrawn: 8271489: (doc) Clarify Filter Factory example
In-Reply-To: <0p6tjDXve1NzwIv5CqU2RjJgL9R0t0Je8scHatsVlTU=.a49cd354-ca52-4a8c-8481-dde3431a4a27@github.com>
References: <0p6tjDXve1NzwIv5CqU2RjJgL9R0t0Je8scHatsVlTU=.a49cd354-ca52-4a8c-8481-dde3431a4a27@github.com>
Message-ID: <4o8A0bH9cVUSjB1lO6rW6Z3QT1KTxpu9Z0IaWK3c_-g=.25c55618-f4b9-46d6-9e4e-39674df24ca9@github.com>

On Thu, 29 Jul 2021 16:36:21 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Improve the clarity of comments in the ObjectInputFilter FilterInThread example.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk17/pull/292

From lancea at openjdk.java.net  Thu Jul 29 18:21:07 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Thu, 29 Jul 2021 18:21:07 GMT
Subject: RFR: 8251329: (zipfs) Files.walkFileTree walks infinitely if zip
 has dir named "." inside [v3]
In-Reply-To: <BnwVE1xrk_yNwA-SSQWdU-s3Q6aWxeoNn2udHvQi9QE=.40ebc385-34fd-4be1-98ea-1514c46c89fb@github.com>
References: <BnwVE1xrk_yNwA-SSQWdU-s3Q6aWxeoNn2udHvQi9QE=.40ebc385-34fd-4be1-98ea-1514c46c89fb@github.com>
Message-ID: <yDLTHJdWNZPTUfj2K0TAdMSGj21csVGcXorLKl2YVRk=.c41cf54d-28be-4414-82ab-36daa4cba473@github.com>

> Hi,
> 
> As discussed in the https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-July/079621.html thread, this is the revised patch to address the use of '.' and '..' within Zip FS
> 
> Zip FS needs to use "." and ".." as links to the current and parent directories and cannot reliably support entries that have "." and ".." as name elements.  This patch updates Zip Fs  to reject ZIP files that have entries in the CEN that can't be used for files in a file system.
> 
> 
> Mach5 tiers 1 through 3 have been run without any errors encountered .
> 
> Best,
> Lance

Lance Andersen has updated the pull request with a new target base 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:

 - Add Impl Note to Zip FS module-info
 - Merge
 - Add missing Copyright header and address minor comments
 - Address missing linefeed  after package name
 - Address overzelous intellij import update
 - Patch to address JDK-8251329

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4900/files
  - new: https://git.openjdk.java.net/jdk/pull/4900/files/2265ffe1..22731ac3

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4900&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4900&range=01-02

  Stats: 3049 lines in 76 files changed: 1357 ins; 359 del; 1333 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4900.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4900/head:pull/4900

PR: https://git.openjdk.java.net/jdk/pull/4900

From rriggs at openjdk.java.net  Thu Jul 29 19:13:39 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 29 Jul 2021 19:13:39 GMT
Subject: [jdk17] RFR: 8271489: (doc) Clarify Filter Factory example
Message-ID: <aqqjzgdCsv6n6SbvfU5K2HLSF7HUeiMgx96VCt9xqBk=.b0518f30-1340-44f7-9620-2fd1b868bb0a@github.com>

Improve the clarity of comments in the ObjectInputFilter FilterInThread example.

-------------

Commit messages:
 - 8271489: (doc) Clarify Filter Factory example

Changes: https://git.openjdk.java.net/jdk17/pull/293/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=293&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8271489
  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/293.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/293/head:pull/293

PR: https://git.openjdk.java.net/jdk17/pull/293

From kcr at openjdk.java.net  Thu Jul 29 19:20:28 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 29 Jul 2021 19:20:28 GMT
Subject: [jdk17] RFR: 8271489: (doc) Clarify Filter Factory example
In-Reply-To: <aqqjzgdCsv6n6SbvfU5K2HLSF7HUeiMgx96VCt9xqBk=.b0518f30-1340-44f7-9620-2fd1b868bb0a@github.com>
References: <aqqjzgdCsv6n6SbvfU5K2HLSF7HUeiMgx96VCt9xqBk=.b0518f30-1340-44f7-9620-2fd1b868bb0a@github.com>
Message-ID: <SpmuFr1Kbaos9E0Xh62ruVyOWmAbadCAlXiACFrxbhk=.1267fdbb-6e6c-4531-8a53-5e2c34f7d46d@github.com>

On Thu, 29 Jul 2021 19:05:58 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Improve the clarity of comments in the ObjectInputFilter FilterInThread example.

Marked as reviewed by kcr (Author).

-------------

PR: https://git.openjdk.java.net/jdk17/pull/293

From iris at openjdk.java.net  Thu Jul 29 19:20:28 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Thu, 29 Jul 2021 19:20:28 GMT
Subject: [jdk17] RFR: 8271489: (doc) Clarify Filter Factory example
In-Reply-To: <aqqjzgdCsv6n6SbvfU5K2HLSF7HUeiMgx96VCt9xqBk=.b0518f30-1340-44f7-9620-2fd1b868bb0a@github.com>
References: <aqqjzgdCsv6n6SbvfU5K2HLSF7HUeiMgx96VCt9xqBk=.b0518f30-1340-44f7-9620-2fd1b868bb0a@github.com>
Message-ID: <GeOAxNspjZ7pTefbnD4CZiEQBkzEnHHBMxElonceggA=.15549728-3fec-46df-a99b-7bcbe7830d7f@github.com>

On Thu, 29 Jul 2021 19:05:58 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Improve the clarity of comments in the ObjectInputFilter FilterInThread example.

Marked as reviewed by iris (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk17/pull/293

From bpb at openjdk.java.net  Thu Jul 29 19:47:31 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 29 Jul 2021 19:47:31 GMT
Subject: [jdk17] RFR: 8271489: (doc) Clarify Filter Factory example
In-Reply-To: <aqqjzgdCsv6n6SbvfU5K2HLSF7HUeiMgx96VCt9xqBk=.b0518f30-1340-44f7-9620-2fd1b868bb0a@github.com>
References: <aqqjzgdCsv6n6SbvfU5K2HLSF7HUeiMgx96VCt9xqBk=.b0518f30-1340-44f7-9620-2fd1b868bb0a@github.com>
Message-ID: <WtQqTN3agW1-YsiPBdGcIiLqbt3WZiIe1E1Z2yutG5M=.1f9b510e-642a-454c-ba7c-aae8c77ac89f@github.com>

On Thu, 29 Jul 2021 19:05:58 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Improve the clarity of comments in the ObjectInputFilter FilterInThread example.

Marked as reviewed by bpb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk17/pull/293

From naoto at openjdk.java.net  Thu Jul 29 19:47:31 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 29 Jul 2021 19:47:31 GMT
Subject: [jdk17] RFR: 8271489: (doc) Clarify Filter Factory example
In-Reply-To: <aqqjzgdCsv6n6SbvfU5K2HLSF7HUeiMgx96VCt9xqBk=.b0518f30-1340-44f7-9620-2fd1b868bb0a@github.com>
References: <aqqjzgdCsv6n6SbvfU5K2HLSF7HUeiMgx96VCt9xqBk=.b0518f30-1340-44f7-9620-2fd1b868bb0a@github.com>
Message-ID: <xcs8jK6e9pAU74L9UQHYaM-C3Iv_x7jGVCG_q0kv3Sg=.b82bb8a8-53c4-4bfe-bcb4-5a9363836d3d@github.com>

On Thu, 29 Jul 2021 19:05:58 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Improve the clarity of comments in the ObjectInputFilter FilterInThread example.

Marked as reviewed by naoto (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk17/pull/293

From github.com+1701815+mkarg at openjdk.java.net  Thu Jul 29 20:00:34 2021
From: github.com+1701815+mkarg at openjdk.java.net (Markus KARG)
Date: Thu, 29 Jul 2021 20:00:34 GMT
Subject: RFR: 8265891: (ch) InputStream returned by
 Channels.newInputStream should override transferTo [v6]
In-Reply-To: <UQzAp1eaWHObRgVpa8bwHLdbdyauIE9NdpDd-MwsvUM=.cd00637c-80bf-43da-8ab3-97825a7d92d0@github.com>
References: <XlU5gCBUEa4qTTz8yhMeElh95FuiPcFYQ_nj_WYvbLE=.6e9fc6a4-f3b1-4faf-91f0-d8b06f875780@github.com>
 <5PpEoJT1JZoo75hz4HAQFkipRfXCr_7MyTE8g4yhhgc=.5eeefcfe-205b-4b02-a59b-bead8b410139@github.com>
 <IZKluRfiLnIovyrAw3TdXDSzB6e59nHmG3ee7PEtjSE=.a778bb70-9938-4599-a3d9-9ad8fa235b00@github.com>
 <D-BolUEcvPGEA-JzbvXEUQTtaxUbl7duhesuVERIZc4=.4edfe8a0-8284-45cf-a2ad-993d795b14b6@github.com>
 <UQzAp1eaWHObRgVpa8bwHLdbdyauIE9NdpDd-MwsvUM=.cd00637c-80bf-43da-8ab3-97825a7d92d0@github.com>
Message-ID: <AC0DI4y81YwidEwnIAAqKjbRCPrFWdBJVz1k2LmOvu8=.497fd5dc-91b2-4294-8049-a5766323539a@github.com>

On Thu, 29 Jul 2021 16:42:35 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> The JavaDocs in `InputStream::transferTo` *cleary* tell the caller that there is **no** guarantee of *any* specific behavior in that particular case: 
>>>The behavior for the case where the input and/or output stream is asynchronously closed, or the thread interrupted during the transfer, is highly input and output stream specific, and therefore not specified.
>
> Good point.

:-)

>> This is a question of style and personal likes. Code maintenance is much easier if variables are defined *near* to its first use, not *far away* (as in the Pascal or C language). If the reviewers want me to change it, I will do it.
>
> It's actually a matter of convention but I think it can remain as it is.

Ok for me, otherwise just clearly tell me and I do change it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4263

From rriggs at openjdk.java.net  Thu Jul 29 20:25:37 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 29 Jul 2021 20:25:37 GMT
Subject: [jdk17] Integrated: 8271489: (doc) Clarify Filter Factory example
In-Reply-To: <aqqjzgdCsv6n6SbvfU5K2HLSF7HUeiMgx96VCt9xqBk=.b0518f30-1340-44f7-9620-2fd1b868bb0a@github.com>
References: <aqqjzgdCsv6n6SbvfU5K2HLSF7HUeiMgx96VCt9xqBk=.b0518f30-1340-44f7-9620-2fd1b868bb0a@github.com>
Message-ID: <HFTQXjVOYPFVLGNA8klraJDXAY6s-Mb8iFdyYvYylRw=.0ec4d1c7-4796-4c20-84af-fdc54897f94e@github.com>

On Thu, 29 Jul 2021 19:05:58 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Improve the clarity of comments in the ObjectInputFilter FilterInThread example.

This pull request has now been integrated.

Changeset: 286d3136
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.java.net/jdk17/commit/286d31363551b00c4b3f50f5ee388f8e7875d0a1
Stats:     4 lines in 1 file changed: 0 ins; 0 del; 4 mod

8271489: (doc) Clarify Filter Factory example

Reviewed-by: iris, kcr, naoto, bpb

-------------

PR: https://git.openjdk.java.net/jdk17/pull/293

From jwilhelm at openjdk.java.net  Thu Jul 29 21:13:54 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Thu, 29 Jul 2021 21:13:54 GMT
Subject: RFR: Merge jdk17
Message-ID: <CNX52IYMLFuHSkGdn1tu6IYQIDVoT3ezc6GfGlzJcVM=.aaa1bf4c-ad37-434b-ae34-e7560e956bf8@github.com>

Forwardport JDK 17 -> JDK 18

-------------

Commit messages:
 - Merge
 - 8271489: (doc) Clarify Filter Factory example

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=4939&range=00.0
 - jdk17: https://webrevs.openjdk.java.net/?repo=jdk&pr=4939&range=00.1

Changes: https://git.openjdk.java.net/jdk/pull/4939/files
  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4939.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4939/head:pull/4939

PR: https://git.openjdk.java.net/jdk/pull/4939

From jwilhelm at openjdk.java.net  Thu Jul 29 21:55:06 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Thu, 29 Jul 2021 21:55:06 GMT
Subject: Integrated: Merge jdk17
In-Reply-To: <CNX52IYMLFuHSkGdn1tu6IYQIDVoT3ezc6GfGlzJcVM=.aaa1bf4c-ad37-434b-ae34-e7560e956bf8@github.com>
References: <CNX52IYMLFuHSkGdn1tu6IYQIDVoT3ezc6GfGlzJcVM=.aaa1bf4c-ad37-434b-ae34-e7560e956bf8@github.com>
Message-ID: <bUu1D2rH2-MJ-jqtxiwymRYG5Kch1z44hMuSxkE83tc=.a3517570-862f-4812-b744-21243ffdc4c8@github.com>

On Thu, 29 Jul 2021 21:05:31 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 17 -> JDK 18

This pull request has now been integrated.

Changeset: 048fb2cb
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/048fb2cb179234c403ee01ddc4acbdc4795c08ee
Stats:     4 lines in 1 file changed: 0 ins; 0 del; 4 mod

Merge

-------------

PR: https://git.openjdk.java.net/jdk/pull/4939

From jwilhelm at openjdk.java.net  Thu Jul 29 21:55:03 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Thu, 29 Jul 2021 21:55:03 GMT
Subject: RFR: Merge jdk17 [v2]
In-Reply-To: <CNX52IYMLFuHSkGdn1tu6IYQIDVoT3ezc6GfGlzJcVM=.aaa1bf4c-ad37-434b-ae34-e7560e956bf8@github.com>
References: <CNX52IYMLFuHSkGdn1tu6IYQIDVoT3ezc6GfGlzJcVM=.aaa1bf4c-ad37-434b-ae34-e7560e956bf8@github.com>
Message-ID: <bjZjqb9JIttsLFpWLcNVof4GYHK2uSdYXc5ufY1Fh1E=.19e303f8-1fd9-4f7a-88e1-3ca20cb61441@github.com>

> Forwardport JDK 17 -> JDK 18

Jesper Wilhelmsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 358 commits:

 - Merge
 - 8271396: Spelling errors
   
   Reviewed-by: tschatzl, chegar, iris, psadhukhan, cjplummer
 - 8268019: C2: assert(no_dead_loop) failed: dead loop detected
   
   Reviewed-by: kvn, thartmann
 - 8270886: Crash in PhaseIdealLoop::verify_strip_mined_scheduling
   
   Reviewed-by: kvn, thartmann
 - Merge
 - 8225082: Remove IdenTrust certificate that is expiring in September 2021
   
   Reviewed-by: shade, mullan
 - 8269851: OperatingSystemMXBean getProcessCpuLoad reports incorrect process cpu usage in containers
   
   Co-authored-by: Severin Gehwolf <sgehwolf at openjdk.org>
   Reviewed-by: sgehwolf
 - 8271353: PerfDataManager::destroy crashes in VM_Exit
   
   Reviewed-by: dholmes, stuefe, minqi
 - 8270061: Change parameter order of ResourceHashtable
   
   Reviewed-by: coleenp, stuefe
 - 8270925: replay dump using CICrashAt does not include inlining data
   
   Reviewed-by: kvn, thartmann
 - ... and 348 more: https://git.openjdk.java.net/jdk/compare/286d3136...ead1faac

-------------

Changes: https://git.openjdk.java.net/jdk/pull/4939/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4939&range=01
  Stats: 61561 lines in 1328 files changed: 29006 ins; 26122 del; 6433 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4939.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4939/head:pull/4939

PR: https://git.openjdk.java.net/jdk/pull/4939

From hboehm at google.com  Thu Jul 29 22:07:27 2021
From: hboehm at google.com (Hans Boehm)
Date: Thu, 29 Jul 2021 15:07:27 -0700
Subject: PhantomReferences
Message-ID: <CAMOCf+j1fR19e+-D07dJ809Nu3KGBjanuc-CXVruETb+wrwqDA@mail.gmail.com>

Here's another finalization-related issue, this time hopefully appropriate
for this list. This was inspired by looking at the Ugawa, Jones, and Ritson
paper from ISMM 2014, which I belatedly had a chance to look at.

The java.lang.ref spec says:

"An object is phantom reachable if it is neither strongly, softly, nor
weakly reachable, it has been finalized, and some phantom reference refers
to it."

It notably does not say that such an object must not be reachable from
unfinalized objects.

I currently believe that:

1) This spec is not as intended, in that it allows a PhantomReference to X
to be enqueued while X is still actively being used. My understanding is
that PhantomReferences were invented largely to make that impossible.

2) Real production implementations enforce a stronger requirement, which
includes that the PhantomReference must not reachable from unfinalized
objects with a nontrivial finalizer, which prevents this problem.

3) The ISMM 2014 paper may have been confused by this, in that it seems to
mirror the official spec rather than the usual implementation. It
(surprisingly to me) does not appear to address the fact that
implementations generally mark reachable objects in at least two stages:
(1) Reachability from roots, and (2) Reachability from roots U unfinalized
finalizable objects, where the result of the first phase is used to
determine WeakReference clearing, while the result of the second phase
determines PhantomReference clearing, and what to collect.

Am I correct?

A scenario that I believe can fail according to the spec, but cannot and
must not fail in real life, is the following, where F1 and F2 are objects
with nontrivial finalizers, and P is the referent of a PhantomReference:

Consider F1 --> P,  where P has a PhantomReference referring to it, and
<root> -> F2 -> null.  Then

1) F1's finalizer runs and notionally P's (empty) finalizer runs. F1
modifies F2, so it gets a strong reference to P.

[ P has now been finalized. We have <root> -> F2 -> P ]

2) <root> is cleared, making F2 unreachable.

[ P is not strongly, softly or weakly referenced, and has been finalized.
Therefore P is phantom reachable. ]

3) The PhantomReference to P is enqueued, resulting in running a Cleaner
that e.g. deallocates native memory required by P.

4) F2's finalizer runs and accesses P.

5) Bad stuff.

Although this is arguably a weird corner case that is unlikely to occur
frequently, I think it profoundly changes the algorithms used to implement
this. "Has been finalized" is not the correct check; it's reachability from
a not-yet-finalized object that matters. Hence the implementation must do a
reachability analysis not technically required by the current spec.

[ Just saying that in the spec probably doesn't work either. I suspect the
fact that the finalizer is nontrivial also matters to get reasonable
progress guarantees. Currently I think the spec doesn't have that notion,
but it seems annoyingly essential. ]

Clearly, this problem goes away if you get rid of finalizers and merge
{Phantom,Weak}References, which is presumably the intended end state, but
not one that looks imminent to me.

Hans

From naoto at openjdk.java.net  Thu Jul 29 22:56:35 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 29 Jul 2021 22:56:35 GMT
Subject: RFR: 8251329: (zipfs) Files.walkFileTree walks infinitely if zip
 has dir named "." inside [v3]
In-Reply-To: <yDLTHJdWNZPTUfj2K0TAdMSGj21csVGcXorLKl2YVRk=.c41cf54d-28be-4414-82ab-36daa4cba473@github.com>
References: <BnwVE1xrk_yNwA-SSQWdU-s3Q6aWxeoNn2udHvQi9QE=.40ebc385-34fd-4be1-98ea-1514c46c89fb@github.com>
 <yDLTHJdWNZPTUfj2K0TAdMSGj21csVGcXorLKl2YVRk=.c41cf54d-28be-4414-82ab-36daa4cba473@github.com>
Message-ID: <7zHatSac3UvRIlIuqeW4IvcvLIHAkc0P75O_gznJdlA=.e892404c-8063-4174-bb89-a5b295ac7507@github.com>

On Thu, 29 Jul 2021 18:21:07 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Hi,
>> 
>> As discussed in the https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-July/079621.html thread, this is the revised patch to address the use of '.' and '..' within Zip FS
>> 
>> Zip FS needs to use "." and ".." as links to the current and parent directories and cannot reliably support entries that have "." and ".." as name elements.  This patch updates Zip Fs  to reject ZIP files that have entries in the CEN that can't be used for files in a file system.
>> 
>> 
>> Mach5 tiers 1 through 3 have been run without any errors encountered .
>> 
>> Best,
>> Lance
>
> Lance Andersen has updated the pull request with a new target base 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:
> 
>  - Add Impl Note to Zip FS module-info
>  - Merge
>  - Add missing Copyright header and address minor comments
>  - Address missing linefeed  after package name
>  - Address overzelous intellij import update
>  - Patch to address JDK-8251329

src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 1622:

> 1620:             index++;
> 1621:         }
> 1622:         return dotOrDotDotFound;

Could simply return `false` here, and eliminate the local variable `dotOrDotDotFound`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4900

From coleenp at openjdk.java.net  Thu Jul 29 23:06:30 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Thu, 29 Jul 2021 23:06:30 GMT
Subject: RFR: JDK-8256844: Make NMT late-initializable
In-Reply-To: <Ze_dKp-5-dse_657jTXTD4kbHSBeOQcLvqeluE0DXjI=.9214cb10-f1f1-48cb-8d96-12621a51a904@github.com>
References: <Ze_dKp-5-dse_657jTXTD4kbHSBeOQcLvqeluE0DXjI=.9214cb10-f1f1-48cb-8d96-12621a51a904@github.com>
Message-ID: <rTeSwF9Asx2ubpKeNiWKyeQimGIueSI891YBrCxf6jQ=.67422d7a-6b38-40d3-ad93-2b333d2eb5f6@github.com>

On Thu, 22 Jul 2021 14:58:47 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Short: this patch makes NMT available in custom-launcher scenarios and during gtests. It simplifies NMT initialization. It adds a lot of NMT-specific testing, cleans them up and makes them sideeffect-free.
> 
> ---------
> 
> NMT continues to be an extremely useful tool for SAP to tackle memory problems in the JVM.
> 
> However, NMT is of limited use due to the following restrictions:
> 
> - NMT cannot be used if the hotspot is embedded into a custom launcher unless the launcher actively cooperates. Just creating and invoking the JVM is not enough, it needs to do some steps prior to loading the hotspot. This limitation is not well known (nor, do I believe, documented). Many products don't do this, e.g., you cannot use NMT with IntelliJ. For us at SAP this problem limits NMT usefulness greatly since our VMs are often embedded into custom launchers and modifying every launcher is impossible.
> - Worse, if that custom launcher links the libjvm *statically* there is just no way to activate NMT at all. This is the reason NMT cannot be used in the `gtestlauncher`.
> - Related to that is that we cannot pass NMT options via `JAVA_TOOL_OPTIONS` and `-XX:Flags=<file>`.
> - The fact that NMT cannot be used in gtests is really a pity since it would allow us to both test NMT itself more rigorously and check for memory leaks while testing other stuff.
> 
> The reason for all this is that NMT initialization happens very early, on the first call to `os::malloc()`. And those calls happen already during dynamic C++ initialization - a long time before the VM gets around parsing arguments. So, regular VM argument parsing is too late to parse NMT arguments.
> 
> The current solution is to pass NMT arguments via a specially prepared environment variable: `NMT_LEVEL_<PID>=<NMT arguments>`. That environment variable has to be set by the embedding launcher, before it loads the libjvm. Since its name contains the PID, we cannot even set that variable in the shell before starting the launcher.
> 
> All that means that every launcher needs to especially parse and process the NMT arguments given at the command line (or via whatever method) and prepare the environment variable. `java` itself does this. This only works before the libjvm.so is loaded, before its dynamic C++ initialization. For that reason, it does not work if the launcher links statically against the hotspot, since in that case C++ initialization of the launcher and hotspot are folded into one phase with no possibility of executing code beforehand.
> 
> And since it bypasses argument handling in the VM, it bypasses a number of argument processing ways, e.g., `JAVA_TOOL_OPTIONS`.
> 
> ------
> 
> This patch fixes these shortcomings by making NMT late-initializable: it can now be initialized after normal VM argument parsing, like all other parts of the VM. This greatly simplifies NMT initialization and makes it work automagically for every third party launcher, as well as within our gtests.
> 
> The glaring problem with late-initializing NMT is the NMT malloc headers. If we rule out just always having them (unacceptable in terms of memory overhead), there is no safe way to determine, in os::free(), if an allocation came from before or after NMT initialization ran, and therefore what to do with its malloc headers. For a more extensive explanation, please see the comment block `nmtPreInit.hpp` and the discussion with @kimbarrett and @zhengyu123 in the JBS comment section.
> 
> The heart of this patch is a new way to track early, pre-NMT-init allocations. These are tracked via a lookup table. This was a suggestion by Kim and it worked out well.
> 
> Changes in detail:
> 
> - pre-NMT-init handling:
> 	- the new files `nmtPreInit.hpp/cpp` take case of NMT pre-init handling. They contain a small global lookup table managing C-heap blocks allocated in the pre-NMT-init phase.
> 	- `os::malloc()/os::realloc()/os::free()` defer to this code before doing anything else.
> 	- Please see the extensive comment block at the start of `nmtPreinit.hpp` explaining the details.
> 
> - Changes to NMT:
> 	- Before, NMT initialization was spread over two phases, `initialize()` and `late_initialize()`. Those were merged into one and simplified - there is only one initialization now which happens after argument parsing.
> 	- Minor changes were needed for the `NMT_TrackingLevel` enum - to simplify code, I changed NMT_unknown to be numerically 0. A new comment block in `nmtCommon.hpp` now clearly specifies what's what, including allowed level state transitions.
> 	- New utility functions to translate tracking level from/to strings added to `NMTUtil`
> 	- NMT has never been able to handle virtual memory allocations before initialization, which is fine since os::reserve_memory() is not called before VM parses arguments. We now assert that.
> 	- All code outside the VM handling NMT initialization (eg. libjli) has been removed, as has the code testing it.
> 
> - Gtests:
> 	- Some existing gtests had to be modified: before, they all changed global state (turning NMT on/off) before testing. This is not allowed anymore, to keep NMT simple. Also, this pattern disturbed other tests.
> 	- The new way to test is to passively check whether NMT has been switched on or off, and do tests accordingly: if on, full tests, if off, test just what makes sense in off-state. That does not disturb neighboring tests, gives us actually better coverage all around.
> 	- It is now possible to start the gtestlauncher with NMT on! Which additionally gives us good coverage.
> 	- To actually do gtests with NMT - since it's disabled by default - we now run NMT-enabled gtests as part of the hotspot jtreg NMT wrapper. This pattern we have done for a number of other facitilites, see all the tests in test/hotspot/jtreg/gtest.. . It works very well.
> 	- Finally, a new gtest has been written to test the NMT preinit lookup map in isolation, placed in `gtest/nmt/test_nmtpreinitmap.cpp`.
> 	
> - jtreg:
> 	- A new test has been added, `runtime/NMT/NMTInitializationTest.java`, testing NMT initialization in the face of many many VM arguments.
> 
> -------------
> 
> Tests:
> - ran manually all new tests on 64-bit and 32-bit Linux
> - GHAs
> - The patch has been active in SAPs test systems for a while now.

This is an interesting and it seems a better way to solve this problem.   Where were you all those years ago??  I hope @zhengyu123 has a chance to review it.
Also interesting is that we were wondering how we could return malloc'd memory on JVM creation failure, and this might partially help with that larger problem.

src/hotspot/share/services/nmtPreInit.hpp line 128:

> 126:   // Returns start of the user data area
> 127:   void* payload()             { return this + 1; }
> 128:   const void* payload() const { return this + 1; }

This is an odd looking overload (that I wouldn't have thought possible).  Maybe one of these payloads can be renamed to why it's const.

src/hotspot/share/services/nmtPreInit.hpp line 166:

> 164:   NMTPreInitAllocation** find_entry(const void* p) const {
> 165:     const unsigned index = index_for_key(p);
> 166:     NMTPreInitAllocation** aa = (NMTPreInitAllocation**) (&(_entries[index]));

Why is this cast needed?

-------------

Marked as reviewed by coleenp (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4874

From bpb at openjdk.java.net  Thu Jul 29 23:33:41 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 29 Jul 2021 23:33:41 GMT
Subject: RFR: 8271225: Add floorDivExact() method to java.lang.[Strict]Math
Message-ID: <UjrIFBKK3_zfLS7w4h-sTsj82K6A4-jIGEB-mt4BA44=.2ac74fd5-598e-4092-9881-fe9fe9146a83@github.com>

Add methods `floorDivExact(int,int)` and `floorDivExact(long,long)` to `java.lang.Math` and `java.lang.StrictMath`.

-------------

Commit messages:
 - 8271225: Add floorDivExact() method to java.lang.[Strict]Math

Changes: https://git.openjdk.java.net/jdk/pull/4941/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4941&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8271225
  Stats: 245 lines in 3 files changed: 236 ins; 0 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4941.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4941/head:pull/4941

PR: https://git.openjdk.java.net/jdk/pull/4941

From bpb at openjdk.java.net  Thu Jul 29 23:33:42 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 29 Jul 2021 23:33:42 GMT
Subject: RFR: 8271225: Add floorDivExact() method to java.lang.[Strict]Math
In-Reply-To: <UjrIFBKK3_zfLS7w4h-sTsj82K6A4-jIGEB-mt4BA44=.2ac74fd5-598e-4092-9881-fe9fe9146a83@github.com>
References: <UjrIFBKK3_zfLS7w4h-sTsj82K6A4-jIGEB-mt4BA44=.2ac74fd5-598e-4092-9881-fe9fe9146a83@github.com>
Message-ID: <TL7VMwfVUeh-qvQ5rZdowpf7FCpCIWzBuTWXT9umtws=.32a9761d-5847-4270-9f69-bfb8812cc591@github.com>

On Thu, 29 Jul 2021 23:27:32 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Add methods `floorDivExact(int,int)` and `floorDivExact(long,long)` to `java.lang.Math` and `java.lang.StrictMath`.

The `floorDivExact()` methods are identical to their `floorDiv()` counterparts aside from that they throw an `ArithmeticException` when the dividend is `MIN_VALUE` and the divisor is `-1`. These methods behave with respect to the methods `floorDiv()` as the methods `divideExact()` behave with respect to the division operator `/`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4941

From bpb at openjdk.java.net  Thu Jul 29 23:42:41 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 29 Jul 2021 23:42:41 GMT
Subject: RFR: 8265891: (ch) InputStream returned by
 Channels.newInputStream should override transferTo [v6]
In-Reply-To: <AC0DI4y81YwidEwnIAAqKjbRCPrFWdBJVz1k2LmOvu8=.497fd5dc-91b2-4294-8049-a5766323539a@github.com>
References: <XlU5gCBUEa4qTTz8yhMeElh95FuiPcFYQ_nj_WYvbLE=.6e9fc6a4-f3b1-4faf-91f0-d8b06f875780@github.com>
 <5PpEoJT1JZoo75hz4HAQFkipRfXCr_7MyTE8g4yhhgc=.5eeefcfe-205b-4b02-a59b-bead8b410139@github.com>
 <IZKluRfiLnIovyrAw3TdXDSzB6e59nHmG3ee7PEtjSE=.a778bb70-9938-4599-a3d9-9ad8fa235b00@github.com>
 <D-BolUEcvPGEA-JzbvXEUQTtaxUbl7duhesuVERIZc4=.4edfe8a0-8284-45cf-a2ad-993d795b14b6@github.com>
 <UQzAp1eaWHObRgVpa8bwHLdbdyauIE9NdpDd-MwsvUM=.cd00637c-80bf-43da-8ab3-97825a7d92d0@github.com>
 <AC0DI4y81YwidEwnIAAqKjbRCPrFWdBJVz1k2LmOvu8=.497fd5dc-91b2-4294-8049-a5766323539a@github.com>
Message-ID: <1llS7FL5O9A3depy1oQWVTEBSuRQ1iKbJrhQUcEgREY=.020798ab-c8ce-40a1-804e-1112f51f6a44@github.com>

On Thu, 29 Jul 2021 19:56:40 GMT, Markus KARG <github.com+1701815+mkarg at openjdk.org> wrote:

>> It's actually a matter of convention but I think it can remain as it is.
>
> Ok for me, otherwise just clearly tell me and I do change it.

I think you can leave it unless someone else thinks otherwise.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4263

From lancea at openjdk.java.net  Fri Jul 30 00:55:57 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Fri, 30 Jul 2021 00:55:57 GMT
Subject: RFR: 8251329: (zipfs) Files.walkFileTree walks infinitely if zip
 has dir named "." inside [v4]
In-Reply-To: <BnwVE1xrk_yNwA-SSQWdU-s3Q6aWxeoNn2udHvQi9QE=.40ebc385-34fd-4be1-98ea-1514c46c89fb@github.com>
References: <BnwVE1xrk_yNwA-SSQWdU-s3Q6aWxeoNn2udHvQi9QE=.40ebc385-34fd-4be1-98ea-1514c46c89fb@github.com>
Message-ID: <_HLwah9MHEE00YhzFYmKEg38WvW5atpQetuzzv6qtbE=.6614b555-0b70-463c-aed1-2a6cc892089a@github.com>

> Hi,
> 
> As discussed in the https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-July/079621.html thread, this is the revised patch to address the use of '.' and '..' within Zip FS
> 
> Zip FS needs to use "." and ".." as links to the current and parent directories and cannot reliably support entries that have "." and ".." as name elements.  This patch updates Zip Fs  to reject ZIP files that have entries in the CEN that can't be used for files in a file system.
> 
> 
> Mach5 tiers 1 through 3 have been run without any errors encountered .
> 
> Best,
> Lance

Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:

  Remove uneeded variable

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4900/files
  - new: https://git.openjdk.java.net/jdk/pull/4900/files/22731ac3..67c726af

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4900&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4900&range=02-03

  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4900.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4900/head:pull/4900

PR: https://git.openjdk.java.net/jdk/pull/4900

From jpai at openjdk.java.net  Fri Jul 30 01:46:33 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Fri, 30 Jul 2021 01:46:33 GMT
Subject: RFR: 8251329: (zipfs) Files.walkFileTree walks infinitely if zip
 has dir named "." inside [v3]
In-Reply-To: <yDLTHJdWNZPTUfj2K0TAdMSGj21csVGcXorLKl2YVRk=.c41cf54d-28be-4414-82ab-36daa4cba473@github.com>
References: <BnwVE1xrk_yNwA-SSQWdU-s3Q6aWxeoNn2udHvQi9QE=.40ebc385-34fd-4be1-98ea-1514c46c89fb@github.com>
 <yDLTHJdWNZPTUfj2K0TAdMSGj21csVGcXorLKl2YVRk=.c41cf54d-28be-4414-82ab-36daa4cba473@github.com>
Message-ID: <ylloIpcL8HiX8Q45Dv-4yi72VT6nyd8UMtdmWr4EuoY=.10f5d387-9743-410c-8df2-dc48a5711e5d@github.com>

On Thu, 29 Jul 2021 18:21:07 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Hi,
>> 
>> As discussed in the https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-July/079621.html thread, this is the revised patch to address the use of '.' and '..' within Zip FS
>> 
>> Zip FS needs to use "." and ".." as links to the current and parent directories and cannot reliably support entries that have "." and ".." as name elements.  This patch updates Zip Fs  to reject ZIP files that have entries in the CEN that can't be used for files in a file system.
>> 
>> 
>> Mach5 tiers 1 through 3 have been run without any errors encountered .
>> 
>> Best,
>> Lance
>
> Lance Andersen has updated the pull request with a new target base 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:
> 
>  - Add Impl Note to Zip FS module-info
>  - Merge
>  - Add missing Copyright header and address minor comments
>  - Address missing linefeed  after package name
>  - Address overzelous intellij import update
>  - Patch to address JDK-8251329

src/jdk.zipfs/share/classes/module-info.java line 49:

> 47:  *
> 48:  * @implNote The Zip File System will throw a ZipException when opening an
> 49:  * existing Zip file that contains Zip entries with "." or ".." in its name elements.

Hello Lance, reading this sentence adds a bit of confusion since it uses the word "contains". Had I not known the implemenation details, this sentence would have made me think zip file with name elements of the form `foo.bar` or `hello..`  would also be rejected since these name elements "contain" `.` or `..`

Do you think we should change the word to something like "The Zip File System will throw a ZipException when opening an existing Zip file that has "." or ".." named entries"?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4900

From kbarrett at openjdk.java.net  Fri Jul 30 04:06:29 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Fri, 30 Jul 2021 04:06:29 GMT
Subject: RFR: JDK-8256844: Make NMT late-initializable
In-Reply-To: <rTeSwF9Asx2ubpKeNiWKyeQimGIueSI891YBrCxf6jQ=.67422d7a-6b38-40d3-ad93-2b333d2eb5f6@github.com>
References: <Ze_dKp-5-dse_657jTXTD4kbHSBeOQcLvqeluE0DXjI=.9214cb10-f1f1-48cb-8d96-12621a51a904@github.com>
 <rTeSwF9Asx2ubpKeNiWKyeQimGIueSI891YBrCxf6jQ=.67422d7a-6b38-40d3-ad93-2b333d2eb5f6@github.com>
Message-ID: <I_H8qAj7GzW14TXK-i3OLvU0UlLnNr27toU60-hyrAc=.1530f028-f77a-40d4-854a-ced3e4cde329@github.com>

On Thu, 29 Jul 2021 22:52:07 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Short: this patch makes NMT available in custom-launcher scenarios and during gtests. It simplifies NMT initialization. It adds a lot of NMT-specific testing, cleans them up and makes them sideeffect-free.
>> 
>> ---------
>> 
>> NMT continues to be an extremely useful tool for SAP to tackle memory problems in the JVM.
>> 
>> However, NMT is of limited use due to the following restrictions:
>> 
>> - NMT cannot be used if the hotspot is embedded into a custom launcher unless the launcher actively cooperates. Just creating and invoking the JVM is not enough, it needs to do some steps prior to loading the hotspot. This limitation is not well known (nor, do I believe, documented). Many products don't do this, e.g., you cannot use NMT with IntelliJ. For us at SAP this problem limits NMT usefulness greatly since our VMs are often embedded into custom launchers and modifying every launcher is impossible.
>> - Worse, if that custom launcher links the libjvm *statically* there is just no way to activate NMT at all. This is the reason NMT cannot be used in the `gtestlauncher`.
>> - Related to that is that we cannot pass NMT options via `JAVA_TOOL_OPTIONS` and `-XX:Flags=<file>`.
>> - The fact that NMT cannot be used in gtests is really a pity since it would allow us to both test NMT itself more rigorously and check for memory leaks while testing other stuff.
>> 
>> The reason for all this is that NMT initialization happens very early, on the first call to `os::malloc()`. And those calls happen already during dynamic C++ initialization - a long time before the VM gets around parsing arguments. So, regular VM argument parsing is too late to parse NMT arguments.
>> 
>> The current solution is to pass NMT arguments via a specially prepared environment variable: `NMT_LEVEL_<PID>=<NMT arguments>`. That environment variable has to be set by the embedding launcher, before it loads the libjvm. Since its name contains the PID, we cannot even set that variable in the shell before starting the launcher.
>> 
>> All that means that every launcher needs to especially parse and process the NMT arguments given at the command line (or via whatever method) and prepare the environment variable. `java` itself does this. This only works before the libjvm.so is loaded, before its dynamic C++ initialization. For that reason, it does not work if the launcher links statically against the hotspot, since in that case C++ initialization of the launcher and hotspot are folded into one phase with no possibility of executing code beforehand.
>> 
>> And since it bypasses argument handling in the VM, it bypasses a number of argument processing ways, e.g., `JAVA_TOOL_OPTIONS`.
>> 
>> ------
>> 
>> This patch fixes these shortcomings by making NMT late-initializable: it can now be initialized after normal VM argument parsing, like all other parts of the VM. This greatly simplifies NMT initialization and makes it work automagically for every third party launcher, as well as within our gtests.
>> 
>> The glaring problem with late-initializing NMT is the NMT malloc headers. If we rule out just always having them (unacceptable in terms of memory overhead), there is no safe way to determine, in os::free(), if an allocation came from before or after NMT initialization ran, and therefore what to do with its malloc headers. For a more extensive explanation, please see the comment block `nmtPreInit.hpp` and the discussion with @kimbarrett and @zhengyu123 in the JBS comment section.
>> 
>> The heart of this patch is a new way to track early, pre-NMT-init allocations. These are tracked via a lookup table. This was a suggestion by Kim and it worked out well.
>> 
>> Changes in detail:
>> 
>> - pre-NMT-init handling:
>> 	- the new files `nmtPreInit.hpp/cpp` take case of NMT pre-init handling. They contain a small global lookup table managing C-heap blocks allocated in the pre-NMT-init phase.
>> 	- `os::malloc()/os::realloc()/os::free()` defer to this code before doing anything else.
>> 	- Please see the extensive comment block at the start of `nmtPreinit.hpp` explaining the details.
>> 
>> - Changes to NMT:
>> 	- Before, NMT initialization was spread over two phases, `initialize()` and `late_initialize()`. Those were merged into one and simplified - there is only one initialization now which happens after argument parsing.
>> 	- Minor changes were needed for the `NMT_TrackingLevel` enum - to simplify code, I changed NMT_unknown to be numerically 0. A new comment block in `nmtCommon.hpp` now clearly specifies what's what, including allowed level state transitions.
>> 	- New utility functions to translate tracking level from/to strings added to `NMTUtil`
>> 	- NMT has never been able to handle virtual memory allocations before initialization, which is fine since os::reserve_memory() is not called before VM parses arguments. We now assert that.
>> 	- All code outside the VM handling NMT initialization (eg. libjli) has been removed, as has the code testing it.
>> 
>> - Gtests:
>> 	- Some existing gtests had to be modified: before, they all changed global state (turning NMT on/off) before testing. This is not allowed anymore, to keep NMT simple. Also, this pattern disturbed other tests.
>> 	- The new way to test is to passively check whether NMT has been switched on or off, and do tests accordingly: if on, full tests, if off, test just what makes sense in off-state. That does not disturb neighboring tests, gives us actually better coverage all around.
>> 	- It is now possible to start the gtestlauncher with NMT on! Which additionally gives us good coverage.
>> 	- To actually do gtests with NMT - since it's disabled by default - we now run NMT-enabled gtests as part of the hotspot jtreg NMT wrapper. This pattern we have done for a number of other facitilites, see all the tests in test/hotspot/jtreg/gtest.. . It works very well.
>> 	- Finally, a new gtest has been written to test the NMT preinit lookup map in isolation, placed in `gtest/nmt/test_nmtpreinitmap.cpp`.
>> 	
>> - jtreg:
>> 	- A new test has been added, `runtime/NMT/NMTInitializationTest.java`, testing NMT initialization in the face of many many VM arguments.
>> 
>> -------------
>> 
>> Tests:
>> - ran manually all new tests on 64-bit and 32-bit Linux
>> - GHAs
>> - The patch has been active in SAPs test systems for a while now.
>
> src/hotspot/share/services/nmtPreInit.hpp line 128:
> 
>> 126:   // Returns start of the user data area
>> 127:   void* payload()             { return this + 1; }
>> 128:   const void* payload() const { return this + 1; }
> 
> This is an odd looking overload (that I wouldn't have thought possible).  Maybe one of these payloads can be renamed to why it's const.

[Not a review, just a drive-by comment.]  This is a normal and idiomatic overload on the const-ness of `this`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4874

From kbarrett at openjdk.java.net  Fri Jul 30 04:12:31 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Fri, 30 Jul 2021 04:12:31 GMT
Subject: RFR: JDK-8256844: Make NMT late-initializable
In-Reply-To: <rTeSwF9Asx2ubpKeNiWKyeQimGIueSI891YBrCxf6jQ=.67422d7a-6b38-40d3-ad93-2b333d2eb5f6@github.com>
References: <Ze_dKp-5-dse_657jTXTD4kbHSBeOQcLvqeluE0DXjI=.9214cb10-f1f1-48cb-8d96-12621a51a904@github.com>
 <rTeSwF9Asx2ubpKeNiWKyeQimGIueSI891YBrCxf6jQ=.67422d7a-6b38-40d3-ad93-2b333d2eb5f6@github.com>
Message-ID: <roJSglaPAiSyPkrjG_ueXqw67K_q_MHinTg_y346dDo=.282149ae-ae17-4d3a-bb5d-cc804771201b@github.com>

On Thu, 29 Jul 2021 22:53:42 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Short: this patch makes NMT available in custom-launcher scenarios and during gtests. It simplifies NMT initialization. It adds a lot of NMT-specific testing, cleans them up and makes them sideeffect-free.
>> 
>> ---------
>> 
>> NMT continues to be an extremely useful tool for SAP to tackle memory problems in the JVM.
>> 
>> However, NMT is of limited use due to the following restrictions:
>> 
>> - NMT cannot be used if the hotspot is embedded into a custom launcher unless the launcher actively cooperates. Just creating and invoking the JVM is not enough, it needs to do some steps prior to loading the hotspot. This limitation is not well known (nor, do I believe, documented). Many products don't do this, e.g., you cannot use NMT with IntelliJ. For us at SAP this problem limits NMT usefulness greatly since our VMs are often embedded into custom launchers and modifying every launcher is impossible.
>> - Worse, if that custom launcher links the libjvm *statically* there is just no way to activate NMT at all. This is the reason NMT cannot be used in the `gtestlauncher`.
>> - Related to that is that we cannot pass NMT options via `JAVA_TOOL_OPTIONS` and `-XX:Flags=<file>`.
>> - The fact that NMT cannot be used in gtests is really a pity since it would allow us to both test NMT itself more rigorously and check for memory leaks while testing other stuff.
>> 
>> The reason for all this is that NMT initialization happens very early, on the first call to `os::malloc()`. And those calls happen already during dynamic C++ initialization - a long time before the VM gets around parsing arguments. So, regular VM argument parsing is too late to parse NMT arguments.
>> 
>> The current solution is to pass NMT arguments via a specially prepared environment variable: `NMT_LEVEL_<PID>=<NMT arguments>`. That environment variable has to be set by the embedding launcher, before it loads the libjvm. Since its name contains the PID, we cannot even set that variable in the shell before starting the launcher.
>> 
>> All that means that every launcher needs to especially parse and process the NMT arguments given at the command line (or via whatever method) and prepare the environment variable. `java` itself does this. This only works before the libjvm.so is loaded, before its dynamic C++ initialization. For that reason, it does not work if the launcher links statically against the hotspot, since in that case C++ initialization of the launcher and hotspot are folded into one phase with no possibility of executing code beforehand.
>> 
>> And since it bypasses argument handling in the VM, it bypasses a number of argument processing ways, e.g., `JAVA_TOOL_OPTIONS`.
>> 
>> ------
>> 
>> This patch fixes these shortcomings by making NMT late-initializable: it can now be initialized after normal VM argument parsing, like all other parts of the VM. This greatly simplifies NMT initialization and makes it work automagically for every third party launcher, as well as within our gtests.
>> 
>> The glaring problem with late-initializing NMT is the NMT malloc headers. If we rule out just always having them (unacceptable in terms of memory overhead), there is no safe way to determine, in os::free(), if an allocation came from before or after NMT initialization ran, and therefore what to do with its malloc headers. For a more extensive explanation, please see the comment block `nmtPreInit.hpp` and the discussion with @kimbarrett and @zhengyu123 in the JBS comment section.
>> 
>> The heart of this patch is a new way to track early, pre-NMT-init allocations. These are tracked via a lookup table. This was a suggestion by Kim and it worked out well.
>> 
>> Changes in detail:
>> 
>> - pre-NMT-init handling:
>> 	- the new files `nmtPreInit.hpp/cpp` take case of NMT pre-init handling. They contain a small global lookup table managing C-heap blocks allocated in the pre-NMT-init phase.
>> 	- `os::malloc()/os::realloc()/os::free()` defer to this code before doing anything else.
>> 	- Please see the extensive comment block at the start of `nmtPreinit.hpp` explaining the details.
>> 
>> - Changes to NMT:
>> 	- Before, NMT initialization was spread over two phases, `initialize()` and `late_initialize()`. Those were merged into one and simplified - there is only one initialization now which happens after argument parsing.
>> 	- Minor changes were needed for the `NMT_TrackingLevel` enum - to simplify code, I changed NMT_unknown to be numerically 0. A new comment block in `nmtCommon.hpp` now clearly specifies what's what, including allowed level state transitions.
>> 	- New utility functions to translate tracking level from/to strings added to `NMTUtil`
>> 	- NMT has never been able to handle virtual memory allocations before initialization, which is fine since os::reserve_memory() is not called before VM parses arguments. We now assert that.
>> 	- All code outside the VM handling NMT initialization (eg. libjli) has been removed, as has the code testing it.
>> 
>> - Gtests:
>> 	- Some existing gtests had to be modified: before, they all changed global state (turning NMT on/off) before testing. This is not allowed anymore, to keep NMT simple. Also, this pattern disturbed other tests.
>> 	- The new way to test is to passively check whether NMT has been switched on or off, and do tests accordingly: if on, full tests, if off, test just what makes sense in off-state. That does not disturb neighboring tests, gives us actually better coverage all around.
>> 	- It is now possible to start the gtestlauncher with NMT on! Which additionally gives us good coverage.
>> 	- To actually do gtests with NMT - since it's disabled by default - we now run NMT-enabled gtests as part of the hotspot jtreg NMT wrapper. This pattern we have done for a number of other facitilites, see all the tests in test/hotspot/jtreg/gtest.. . It works very well.
>> 	- Finally, a new gtest has been written to test the NMT preinit lookup map in isolation, placed in `gtest/nmt/test_nmtpreinitmap.cpp`.
>> 	
>> - jtreg:
>> 	- A new test has been added, `runtime/NMT/NMTInitializationTest.java`, testing NMT initialization in the face of many many VM arguments.
>> 
>> -------------
>> 
>> Tests:
>> - ran manually all new tests on 64-bit and 32-bit Linux
>> - GHAs
>> - The patch has been active in SAPs test systems for a while now.
>
> src/hotspot/share/services/nmtPreInit.hpp line 166:
> 
>> 164:   NMTPreInitAllocation** find_entry(const void* p) const {
>> 165:     const unsigned index = index_for_key(p);
>> 166:     NMTPreInitAllocation** aa = (NMTPreInitAllocation**) (&(_entries[index]));
> 
> Why is this cast needed?

[Not a review, just a drive-by comment.]  It's casting away const.  Better would be a const_cast.  And probably moved to the final result, with the body keeping things const-qualified.  And maybe const and non-const overloads of this function.  Or maybe this function shouldn't be const-qualified if a non-const result is always needed, but that doesn't seem likely.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4874

From wuyan at openjdk.java.net  Fri Jul 30 06:49:30 2021
From: wuyan at openjdk.java.net (Wu Yan)
Date: Fri, 30 Jul 2021 06:49:30 GMT
Subject: RFR: 8268231: Aarch64: Use ldp in intrinsics for String.compareTo
 [v4]
In-Reply-To: <nkmR6oTY7W1zdp5DA6diMPtcZwC0tRiLYvIcttPsbA8=.32292edb-96a8-44e1-b00f-881ad796440e@github.com>
References: <XwW4MjGSYmSHa2ZbzrOfvoZi1pe8LJAK7YIKtmNhaDM=.d39df32e-8698-4608-9184-3b19cd175d1a@github.com>
 <F6md9mVnN7YiAwVrRTrLGaRVOGJp2PRCBUpaDRm__j4=.9a428b99-30d9-4c76-823a-19412c282ceb@github.com>
 <CrjCx-SVcCpKtpnITLE1oinQGJky0PtbwoRx7I6qK1E=.a30e021b-5f1a-462e-a074-ab956d2ab991@github.com>
 <JIBFjcKsGGCiaHpLZ1lJkZI8059Ku1I3MJL8pvxUNEE=.35526bb2-c835-48b4-8388-56e390dee166@github.com>
 <KAZ0GJbUUPYV7jkRjD5vNxF5jTLnwZeYNRZyykE8qZc=.70df7d47-f4d9-494a-9d09-6509d8af72ea@github.com>
 <nkmR6oTY7W1zdp5DA6diMPtcZwC0tRiLYvIcttPsbA8=.32292edb-96a8-44e1-b00f-881ad796440e@github.com>
Message-ID: <wXfDioicZKXy7Tideo3h7JRCWWOZse2Nv2IMeb17xu0=.20c1aac0-dfb3-459b-bc35-23943cabf4a7@github.com>

On Wed, 28 Jul 2021 09:55:18 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

> Adding prefetches was one of the reasons to introduce the separate stub for long strings, see the mail below:
> 
> https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2018-April/028888.html


Thank you for pointing this out, we didn't find that adding prefetches was one of the reasons for that optimization before.  

> Did you find there's no benefit to that?

In fact, at first we tested and found that adding prefetch would make it worse in some cases, so we removed prefetch in the LDP version, but after more testing, we found that prefetch is not the cause of the performance degradation. Sorry for this, please ignore the prefetch problem,  I will add prefetch back next.


> We don't really want to have different implementations for each microarchitecture, that would be a testing nightmare.

I aggree. This is the compromise solution that the optimization has no effect (or even slowdown) on some platforms. 
In addition, I found that in [JDK-8202326](https://bugs.openjdk.java.net/browse/JDK-8202326), adding prefetches is only for long strings (the rare cases), maybe we can further optimize longs string with LDP. So should I continue this optimization or close it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4722

From erik.osterlund at oracle.com  Fri Jul 30 08:42:33 2021
From: erik.osterlund at oracle.com (Erik Osterlund)
Date: Fri, 30 Jul 2021 08:42:33 +0000
Subject: PhantomReferences
In-Reply-To: <CAMOCf+j1fR19e+-D07dJ809Nu3KGBjanuc-CXVruETb+wrwqDA@mail.gmail.com>
References: <CAMOCf+j1fR19e+-D07dJ809Nu3KGBjanuc-CXVruETb+wrwqDA@mail.gmail.com>
Message-ID: <BN0PR10MB51766CA42F1F7D2FE3469164F4EC9@BN0PR10MB5176.namprd10.prod.outlook.com>

Hi Hans,

> -----Original Message-----
> From: core-libs-dev <core-libs-dev-retn at openjdk.java.net> On Behalf Of
> Hans Boehm
> Sent: Friday, 30 July 2021 00:07
> To: core-libs-dev <core-libs-dev at openjdk.java.net>
> Subject: PhantomReferences
> 
> Here's another finalization-related issue, this time hopefully appropriate for
> this list. This was inspired by looking at the Ugawa, Jones, and Ritson paper
> from ISMM 2014, which I belatedly had a chance to look at.
> 
> The java.lang.ref spec says:
> 
> "An object is phantom reachable if it is neither strongly, softly, nor weakly
> reachable, it has been finalized, and some phantom reference refers to it."
> 
> It notably does not say that such an object must not be reachable from
> unfinalized objects.
> 
> I currently believe that:
> 
> 1) This spec is not as intended, in that it allows a PhantomReference to X to
> be enqueued while X is still actively being used. My understanding is that
> PhantomReferences were invented largely to make that impossible.

Agreed.

> 2) Real production implementations enforce a stronger requirement, which
> includes that the PhantomReference must not reachable from unfinalized
> objects with a nontrivial finalizer, which prevents this problem.

Correct.

> 3) The ISMM 2014 paper may have been confused by this, in that it seems to
> mirror the official spec rather than the usual implementation. It (surprisingly
> to me) does not appear to address the fact that implementations generally
> mark reachable objects in at least two stages:
> (1) Reachability from roots, and (2) Reachability from roots U unfinalized
> finalizable objects, where the result of the first phase is used to determine
> WeakReference clearing, while the result of the second phase determines
> PhantomReference clearing, and what to collect.
> 
> Am I correct?

I have also looked at that paper a bit, as well as had some discussions with the authors of that paper regarding finalizers and phantoms. They gave me a link to the code to help clarify what they have been up to, which was very helpful: https://github.com/rejones/sapphire/

Skimming through the code, I came to the conclusion that they do trace from finalizers like traditional collectors, between processing of weak and phantom references. So they are also computing transitive properties correctly AFAICT. However, there are some other issues with this though. The algorithm only allows you to load non-phantom strength references after marking terminates and before reference processing has executed, because the transitive closure of finalizers has yet to be computed before then. It is assumed that nobody would be interested in loading a phantom strength reference in this window of time. The paper says:

"Phantom reference objects are straightforward to process in an
OTF manner since there is no interaction between collector and
mutator: PantomReference.get() always returns null."

Now this was implemented in JikesRVM where AFAICT there is no class unloading implemented (a great source of phantom strength references in HotSpot). I believe the JNI spec was also a bit more vague at the time, and jweaks were indeed implemented with weak strength in their code. So since PhantomReference.get() just returns null, they could dodge most issues with phatom strength loads - a core assumption of the algorithm.
We also enjoy making our lives as painful as possible and since that paper was written, we added refersTo() to j.l.r.Reference, which also has to work on PhantomReference, with phantom strength semantics. That would be the nail in the coffin for such simplifications, as now PhantomReference itself indeed does have such mutator interactions, before concurrent reference processing has a chance to run.

ZGC also implements concurrent reference processing. Our approach is to during concurrent marking perform both the normal marking from strong roots, and finalizable marking from finalizers, both in the same concurrent marking phase. This requires an extra bit map to keep track of objects that are reachable from finalizers as well (but not through strong roots). The liveness can move around a bit during the marking (finalizable reachable can get transitively promoted to strongly reachable, but not the other way around), but once we marking terminates, we get a snapshot of this liveness information, that does not change. Then we have internally explicitly marked what strength each reference access has through an access API, such that weak references check the strong bitmap if the value will become concurrently cleared by the reference processor, while phantom references do the corresponding same thing using the other bitmap. That way, we can always when reading a phantom reference, lazily compute the same value that the concurrent reference processor would. We would be thrilled to remove that extra bit map we only need to deal with finalizers though. But that is what allows us to perform phantom loads right after marking terminates, and before concurrent reference processing has started, with the same semantics as-if it was all done STW.

> A scenario that I believe can fail according to the spec, but cannot and must
> not fail in real life, is the following, where F1 and F2 are objects with
> nontrivial finalizers, and P is the referent of a PhantomReference:
> 
> Consider F1 --> P,  where P has a PhantomReference referring to it, and
> <root> -> F2 -> null.  Then
> 
> 1) F1's finalizer runs and notionally P's (empty) finalizer runs. F1 modifies F2,
> so it gets a strong reference to P.
> 
> [ P has now been finalized. We have <root> -> F2 -> P ]
> 
> 2) <root> is cleared, making F2 unreachable.
> 
> [ P is not strongly, softly or weakly referenced, and has been finalized.
> Therefore P is phantom reachable. ]
> 
> 3) The PhantomReference to P is enqueued, resulting in running a Cleaner
> that e.g. deallocates native memory required by P.
> 
> 4) F2's finalizer runs and accesses P.
> 
> 5) Bad stuff.
> 
> Although this is arguably a weird corner case that is unlikely to occur
> frequently, I think it profoundly changes the algorithms used to implement
> this. "Has been finalized" is not the correct check; it's reachability from a not-
> yet-finalized object that matters. Hence the implementation must do a
> reachability analysis not technically required by the current spec.

Agreed.

> [ Just saying that in the spec probably doesn't work either. I suspect the fact
> that the finalizer is nontrivial also matters to get reasonable progress
> guarantees. Currently I think the spec doesn't have that notion, but it seems
> annoyingly essential. ]
> 
> Clearly, this problem goes away if you get rid of finalizers and merge
> {Phantom,Weak}References, which is presumably the intended end state,
> but not one that looks imminent to me.

Right.

/Erik

> Hans

From stuefe at openjdk.java.net  Fri Jul 30 09:35:28 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Fri, 30 Jul 2021 09:35:28 GMT
Subject: RFR: JDK-8256844: Make NMT late-initializable
In-Reply-To: <I_H8qAj7GzW14TXK-i3OLvU0UlLnNr27toU60-hyrAc=.1530f028-f77a-40d4-854a-ced3e4cde329@github.com>
References: <Ze_dKp-5-dse_657jTXTD4kbHSBeOQcLvqeluE0DXjI=.9214cb10-f1f1-48cb-8d96-12621a51a904@github.com>
 <rTeSwF9Asx2ubpKeNiWKyeQimGIueSI891YBrCxf6jQ=.67422d7a-6b38-40d3-ad93-2b333d2eb5f6@github.com>
 <I_H8qAj7GzW14TXK-i3OLvU0UlLnNr27toU60-hyrAc=.1530f028-f77a-40d4-854a-ced3e4cde329@github.com>
Message-ID: <eEhXFsXnwTqnIiBC3yAKoXepAmefbQ_nYqUY-HuWcrU=.36c90671-d0c8-43d1-a702-bfe48a76b54c@github.com>

On Fri, 30 Jul 2021 04:03:57 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> src/hotspot/share/services/nmtPreInit.hpp line 128:
>> 
>>> 126:   // Returns start of the user data area
>>> 127:   void* payload()             { return this + 1; }
>>> 128:   const void* payload() const { return this + 1; }
>> 
>> This is an odd looking overload (that I wouldn't have thought possible).  Maybe one of these payloads can be renamed to why it's const.
>
> [Not a review, just a drive-by comment.]  This is a normal and idiomatic overload on the const-ness of `this`.

To expand on Kim's answer. This is a way to solve const/nonconst problems like https://github.com/openjdk/jdk/pull/4938/files#r679639391. 

You get a const version (suitably returning a write-protected pointer) which the compiler chooses in const code, and a non-const version for non-const code, and no awkward const-casts are needed from the outside.

In this case the implementation is simple enough that I just duplicated it; were it more complex, I'd call one in terms of the other. We do this in other places too, see e.g. `ResourceHashTable::lookup_node`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4874

From stuefe at openjdk.java.net  Fri Jul 30 09:50:33 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Fri, 30 Jul 2021 09:50:33 GMT
Subject: RFR: JDK-8256844: Make NMT late-initializable
In-Reply-To: <AZ2cA0l1q5QW5ni-nAICe9i9t0cpry0JUecLASkzBH8=.7615cb8b-fe0d-4e03-b106-62b9ddc5845b@github.com>
References: <Ze_dKp-5-dse_657jTXTD4kbHSBeOQcLvqeluE0DXjI=.9214cb10-f1f1-48cb-8d96-12621a51a904@github.com>
 <AZ2cA0l1q5QW5ni-nAICe9i9t0cpry0JUecLASkzBH8=.7615cb8b-fe0d-4e03-b106-62b9ddc5845b@github.com>
Message-ID: <gVwRpIoZR8izyT_3xsaJMP8erHgSSx8k6SLlWdnDkw8=.18b64ea5-5b45-41d4-96cd-5d7a4274cff1@github.com>

On Thu, 29 Jul 2021 06:37:36 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Hi Thomas,
> 
> I had a look through this and it seems reasonable, but I'm not familiar enough with the details to approve at this stage.
> 
> A few nits below.
> 
> Thanks,
> David

I did not expect a quick review for this one, so thanks for looking at this! All your suggestions make sense, I'll incorporate them.

..Thomas

-------------

PR: https://git.openjdk.java.net/jdk/pull/4874

From stuefe at openjdk.java.net  Fri Jul 30 09:50:34 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Fri, 30 Jul 2021 09:50:34 GMT
Subject: RFR: JDK-8256844: Make NMT late-initializable
In-Reply-To: <roJSglaPAiSyPkrjG_ueXqw67K_q_MHinTg_y346dDo=.282149ae-ae17-4d3a-bb5d-cc804771201b@github.com>
References: <Ze_dKp-5-dse_657jTXTD4kbHSBeOQcLvqeluE0DXjI=.9214cb10-f1f1-48cb-8d96-12621a51a904@github.com>
 <rTeSwF9Asx2ubpKeNiWKyeQimGIueSI891YBrCxf6jQ=.67422d7a-6b38-40d3-ad93-2b333d2eb5f6@github.com>
 <roJSglaPAiSyPkrjG_ueXqw67K_q_MHinTg_y346dDo=.282149ae-ae17-4d3a-bb5d-cc804771201b@github.com>
Message-ID: <rPHahvPZT8ple-qppNMJEfBoz-dAbMJ4KQKr6XUFtXE=.1424d75e-f4d1-4fc9-919b-a3ea497c49d5@github.com>

On Fri, 30 Jul 2021 04:09:32 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> src/hotspot/share/services/nmtPreInit.hpp line 166:
>> 
>>> 164:   NMTPreInitAllocation** find_entry(const void* p) const {
>>> 165:     const unsigned index = index_for_key(p);
>>> 166:     NMTPreInitAllocation** aa = (NMTPreInitAllocation**) (&(_entries[index]));
>> 
>> Why is this cast needed?
>
> [Not a review, just a drive-by comment.]  It's casting away const.  Better would be a const_cast.  And probably moved to the final result, with the body keeping things const-qualified.  And maybe const and non-const overloads of this function.  Or maybe this function shouldn't be const-qualified if a non-const result is always needed, but that doesn't seem likely.

I'll rethink this.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4874

From stuefe at openjdk.java.net  Fri Jul 30 09:50:33 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Fri, 30 Jul 2021 09:50:33 GMT
Subject: RFR: JDK-8256844: Make NMT late-initializable
In-Reply-To: <rTeSwF9Asx2ubpKeNiWKyeQimGIueSI891YBrCxf6jQ=.67422d7a-6b38-40d3-ad93-2b333d2eb5f6@github.com>
References: <Ze_dKp-5-dse_657jTXTD4kbHSBeOQcLvqeluE0DXjI=.9214cb10-f1f1-48cb-8d96-12621a51a904@github.com>
 <rTeSwF9Asx2ubpKeNiWKyeQimGIueSI891YBrCxf6jQ=.67422d7a-6b38-40d3-ad93-2b333d2eb5f6@github.com>
Message-ID: <iZ7WptYlKPCVRXDsu2SsMJhijMkM1DPWzcX9FYct69M=.62d2b846-bda5-47c8-a337-98f77b38e05b@github.com>

On Thu, 29 Jul 2021 23:03:46 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This is an interesting and it seems a better way to solve this problem. Where were you all those years ago?? I hope @zhengyu123 has a chance to review it.

Thank you! I was here, but we were not yet doing much upstream :) To be fair, this problem got quite involved and did cost me some cycles and false starts. I fully understand that the first solution uses the environment variable approach.

I spend some time investigating different ideas with this one; at first I did not use a hash-table but a static pre-allocated buffer from which I fed early allocations. But the code got too complex, and Kim's suggestion with the side table turned out just to be a lot simpler.

> Also interesting is that we were wondering how we could return malloc'd memory on JVM creation failure, and this might partially help with that larger problem.

Yes, this would be trivial now, to return that memory. Though I am afraid it would be a small part only. But NMT may be instrumental in releasing all memory, since it knows everything. Only, its not always enabled.

Is that a real-life problem? Are there cases where the launcher would want to live on if the JVM failed to load?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4874

From aph at redhat.com  Fri Jul 30 10:33:18 2021
From: aph at redhat.com (Andrew Haley)
Date: Fri, 30 Jul 2021 11:33:18 +0100
Subject: RFR: 8268231: Aarch64: Use ldp in intrinsics for String.compareTo
 [v4]
In-Reply-To: <wXfDioicZKXy7Tideo3h7JRCWWOZse2Nv2IMeb17xu0=.20c1aac0-dfb3-459b-bc35-23943cabf4a7@github.com>
References: <XwW4MjGSYmSHa2ZbzrOfvoZi1pe8LJAK7YIKtmNhaDM=.d39df32e-8698-4608-9184-3b19cd175d1a@github.com>
 <F6md9mVnN7YiAwVrRTrLGaRVOGJp2PRCBUpaDRm__j4=.9a428b99-30d9-4c76-823a-19412c282ceb@github.com>
 <CrjCx-SVcCpKtpnITLE1oinQGJky0PtbwoRx7I6qK1E=.a30e021b-5f1a-462e-a074-ab956d2ab991@github.com>
 <JIBFjcKsGGCiaHpLZ1lJkZI8059Ku1I3MJL8pvxUNEE=.35526bb2-c835-48b4-8388-56e390dee166@github.com>
 <KAZ0GJbUUPYV7jkRjD5vNxF5jTLnwZeYNRZyykE8qZc=.70df7d47-f4d9-494a-9d09-6509d8af72ea@github.com>
 <nkmR6oTY7W1zdp5DA6diMPtcZwC0tRiLYvIcttPsbA8=.32292edb-96a8-44e1-b00f-881ad796440e@github.com>
 <wXfDioicZKXy7Tideo3h7JRCWWOZse2Nv2IMeb17xu0=.20c1aac0-dfb3-459b-bc35-23943cabf4a7@github.com>
Message-ID: <29f1b64a-67eb-1c49-cbb3-b42247c0d072@redhat.com>

On 7/30/21 7:49 AM, Wu Yan wrote:

> I aggree. This is the compromise solution that the optimization
> has no effect (or even slowdown) on some platforms.
> In addition, I found that in
> [JDK-8202326](https://bugs.openjdk.java.net/browse/JDK-8202326),
> adding prefetches is only for long strings (the rare cases),
> maybe we can further optimize longs string with LDP. So should
> I continue this optimization or close it.

IMO, we don't want to be using the vector unit unless it does
some good, and if you can do this sort of thing in the CPU core
you should, so I like that. I was (still am) tempted to approve
it, but Nick says there are still bugs in corner cases.

I think you should probably close it. Comparison of really long
Strings is so rare that I can't find any examples of where it
actually happens. Array comparisons, sure, but Strings, not so
much.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From alanb at openjdk.java.net  Fri Jul 30 11:27:30 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 30 Jul 2021 11:27:30 GMT
Subject: RFR: 8251329: (zipfs) Files.walkFileTree walks infinitely if zip
 has dir named "." inside [v3]
In-Reply-To: <ylloIpcL8HiX8Q45Dv-4yi72VT6nyd8UMtdmWr4EuoY=.10f5d387-9743-410c-8df2-dc48a5711e5d@github.com>
References: <BnwVE1xrk_yNwA-SSQWdU-s3Q6aWxeoNn2udHvQi9QE=.40ebc385-34fd-4be1-98ea-1514c46c89fb@github.com>
 <yDLTHJdWNZPTUfj2K0TAdMSGj21csVGcXorLKl2YVRk=.c41cf54d-28be-4414-82ab-36daa4cba473@github.com>
 <ylloIpcL8HiX8Q45Dv-4yi72VT6nyd8UMtdmWr4EuoY=.10f5d387-9743-410c-8df2-dc48a5711e5d@github.com>
Message-ID: <uGv-_9dkbCqhIeoCQhRJ7lEs3l22ZoVckOrHqcvsKac=.50c73a0d-37d6-41fa-8348-5f5c1a22ef12@github.com>

On Fri, 30 Jul 2021 01:43:56 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Lance Andersen has updated the pull request with a new target base 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:
>> 
>>  - Add Impl Note to Zip FS module-info
>>  - Merge
>>  - Add missing Copyright header and address minor comments
>>  - Address missing linefeed  after package name
>>  - Address overzelous intellij import update
>>  - Patch to address JDK-8251329
>
> src/jdk.zipfs/share/classes/module-info.java line 49:
> 
>> 47:  *
>> 48:  * @implNote The Zip File System will throw a ZipException when opening an
>> 49:  * existing Zip file that contains Zip entries with "." or ".." in its name elements.
> 
> Hello Lance, reading this sentence adds a bit of confusion since it uses the word "contains". Had I not known the implemenation details, this sentence would have made me think zip file with name elements of the form `foo.bar` or `hello..`  would also be rejected since these name elements "contain" `.` or `..`
> 
> Do you think we should change the word to something like "The Zip File System will throw a ZipException when opening an existing Zip file that has "." or ".." named entries"?

I think the `@implNote` tag can be dropped here. For the text then maybe it could be tweaked to something like "The ZIP file system provider does not support opening an existing ZIP that contains entries with ...".

-------------

PR: https://git.openjdk.java.net/jdk/pull/4900

From ngasson at openjdk.java.net  Fri Jul 30 11:34:28 2021
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Fri, 30 Jul 2021 11:34:28 GMT
Subject: RFR: 8268231: Aarch64: Use ldp in intrinsics for String.compareTo
In-Reply-To: <29f1b64a-67eb-1c49-cbb3-b42247c0d072@redhat.com>
References: <XwW4MjGSYmSHa2ZbzrOfvoZi1pe8LJAK7YIKtmNhaDM=.d39df32e-8698-4608-9184-3b19cd175d1a@github.com>
 <29f1b64a-67eb-1c49-cbb3-b42247c0d072@redhat.com>
Message-ID: <RX1rSM4xGBZR71MaKubG9qOP9TJY2CpvzvyDQqcPSZU=.fe87956d-a338-473a-bf0a-4d47032e8378@github.com>

On Fri, 30 Jul 2021 10:36:01 GMT, Andrew Haley <aph at redhat.com> wrote:

> 
> I was (still am) tempted to approve it, but Nick says there are still bugs in corner cases.
> 

I meant the earlier String.compareTo that this is partially replacing. This one might be fine but I just wanted to check it had be thoroughly tested. For reference they were:

https://bugs.openjdk.java.net/browse/JDK-8215100
https://bugs.openjdk.java.net/browse/JDK-8237524
https://bugs.openjdk.java.net/browse/JDK-8218966

-------------

PR: https://git.openjdk.java.net/jdk/pull/4722

From alanb at openjdk.java.net  Fri Jul 30 12:12:30 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 30 Jul 2021 12:12:30 GMT
Subject: RFR: 8265891: (ch) InputStream returned by
 Channels.newInputStream should override transferTo [v6]
In-Reply-To: <AC0DI4y81YwidEwnIAAqKjbRCPrFWdBJVz1k2LmOvu8=.497fd5dc-91b2-4294-8049-a5766323539a@github.com>
References: <XlU5gCBUEa4qTTz8yhMeElh95FuiPcFYQ_nj_WYvbLE=.6e9fc6a4-f3b1-4faf-91f0-d8b06f875780@github.com>
 <5PpEoJT1JZoo75hz4HAQFkipRfXCr_7MyTE8g4yhhgc=.5eeefcfe-205b-4b02-a59b-bead8b410139@github.com>
 <IZKluRfiLnIovyrAw3TdXDSzB6e59nHmG3ee7PEtjSE=.a778bb70-9938-4599-a3d9-9ad8fa235b00@github.com>
 <D-BolUEcvPGEA-JzbvXEUQTtaxUbl7duhesuVERIZc4=.4edfe8a0-8284-45cf-a2ad-993d795b14b6@github.com>
 <UQzAp1eaWHObRgVpa8bwHLdbdyauIE9NdpDd-MwsvUM=.cd00637c-80bf-43da-8ab3-97825a7d92d0@github.com>
 <AC0DI4y81YwidEwnIAAqKjbRCPrFWdBJVz1k2LmOvu8=.497fd5dc-91b2-4294-8049-a5766323539a@github.com>
Message-ID: <RL6f0JWEcP22xlawlCxU3zhNrUhJ6iy_rgEr2ZXA688=.b4abee11-6c2c-4d60-8790-e6b05c45f10f@github.com>

On Thu, 29 Jul 2021 19:57:30 GMT, Markus KARG <github.com+1701815+mkarg at openjdk.org> wrote:

>> Good point.
>
> :-)

Is this loop correct for the case that the channel gets truncated? In that case transferTo will return 0 as no bytes will be transferred and I'm concerned this code will go into an infinite loop.

Also can you can check that IllegalBlockingModeException is thrown for the case ch is a SelectableChannel configured non-blocking and the destination is a FileChannel?

Just on naming, the existing channel implementations use "dst" for the destination and "wbc" (not "oc") for writable byte channels. Just mentioning it so that the new code can be kept consistent where possible.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4263

From avoitylov at openjdk.java.net  Fri Jul 30 12:22:27 2021
From: avoitylov at openjdk.java.net (Aleksei Voitylov)
Date: Fri, 30 Jul 2021 12:22:27 GMT
Subject: RFR: 8270321: Startup regressions in 18-b5 caused by JDK-8266310
In-Reply-To: <W0x401I1NqmAUe7fn05M-YVVBaP1yD98xoXz0kNw5UM=.a60b4e7d-c7e9-406e-bde4-1341519a439a@github.com>
References: <W0x401I1NqmAUe7fn05M-YVVBaP1yD98xoXz0kNw5UM=.a60b4e7d-c7e9-406e-bde4-1341519a439a@github.com>
Message-ID: <ZdMRbgfMq0KXlen9IAGR9B6IFDf8MLen3vrywxVqqE8=.6b74f434-bcf7-4358-aa21-42102866e593@github.com>

On Fri, 23 Jul 2021 18:03:31 GMT, Sergey Chernyshev <github.com+6394632+sercher at openjdk.org> wrote:

> Dear colleagues,
> 
> Please review the patch that replaces the lambdas with anonymous classes which solves the startup time regression as shown below.
> 
> I attached the Bytestacks flamegraphs for both original (regression) and fixed versions. The flamegraphs clearly show the lambdas were causing the performance issue.
> 
> [bytestacks_flamegraphs.zip](https://github.com/openjdk/jdk/files/6870446/bytestacks_flamegraphs.zip)
> 
> Although the proposed JDK-8270321 patch fixes the startup time (it might appear even better than it was before the regression was introduced, i.e. before JDK-8266310) and generally fixes the footprint regression, it may increase MaxRSS slightly compared to the version before JDK-8266310, which is shown in the below graphs. (updated)
> 
> ![StartupTime2](https://user-images.githubusercontent.com/6394632/126898224-a05fda62-f723-4f2c-9af9-e02cbfe1c9c8.png)
> 
> ![MaxRSS](https://user-images.githubusercontent.com/6394632/126822404-899ab904-efc1-4377-9e0d-d8cdb5c0e5d0.png)
> 
> (update: added ZGC graphs)
> 
> ![StartupTime_ZGC](https://user-images.githubusercontent.com/6394632/126898242-52c09582-c2a4-4623-aad2-f47055277193.png)
> 
> ![MaxRSS_ZGC](https://user-images.githubusercontent.com/6394632/126898244-31c3eeb5-a768-4a52-8960-960cc4a72d7b.png)
> 
> I additionally include the heap objects histograms to show the change does not increase the total live objects size significantly with only 1000 bytes the total difference, namely 1116128 bytes in 25002 live objects after the proposed fix JDK-8270321 compared to 1115128 bytes in 24990 objects in the version with the original patch reverted (i.e. before JDK-8266310).
> 
> [histograms.zip](https://github.com/openjdk/jdk/files/6870457/histograms.zip)
> 
> The patch was tested w/hotspot/tier1/tier2 test groups.

Thanks Sergey for dealing with this while I was on vacation, and sorry for causing this regression! Looks good (not a reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4893

From zgu at openjdk.java.net  Fri Jul 30 13:06:32 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Fri, 30 Jul 2021 13:06:32 GMT
Subject: RFR: JDK-8256844: Make NMT late-initializable
In-Reply-To: <Ze_dKp-5-dse_657jTXTD4kbHSBeOQcLvqeluE0DXjI=.9214cb10-f1f1-48cb-8d96-12621a51a904@github.com>
References: <Ze_dKp-5-dse_657jTXTD4kbHSBeOQcLvqeluE0DXjI=.9214cb10-f1f1-48cb-8d96-12621a51a904@github.com>
Message-ID: <lWySsJZvEV89He7k4lBTTN_ki4qxE_UJ-4ZZ3ShYBHg=.74ad62ca-40d2-4003-a416-b82faa7608d9@github.com>

On Thu, 22 Jul 2021 14:58:47 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Short: this patch makes NMT available in custom-launcher scenarios and during gtests. It simplifies NMT initialization. It adds a lot of NMT-specific testing, cleans them up and makes them sideeffect-free.
> 
> ---------
> 
> NMT continues to be an extremely useful tool for SAP to tackle memory problems in the JVM.
> 
> However, NMT is of limited use due to the following restrictions:
> 
> - NMT cannot be used if the hotspot is embedded into a custom launcher unless the launcher actively cooperates. Just creating and invoking the JVM is not enough, it needs to do some steps prior to loading the hotspot. This limitation is not well known (nor, do I believe, documented). Many products don't do this, e.g., you cannot use NMT with IntelliJ. For us at SAP this problem limits NMT usefulness greatly since our VMs are often embedded into custom launchers and modifying every launcher is impossible.
> - Worse, if that custom launcher links the libjvm *statically* there is just no way to activate NMT at all. This is the reason NMT cannot be used in the `gtestlauncher`.
> - Related to that is that we cannot pass NMT options via `JAVA_TOOL_OPTIONS` and `-XX:Flags=<file>`.
> - The fact that NMT cannot be used in gtests is really a pity since it would allow us to both test NMT itself more rigorously and check for memory leaks while testing other stuff.
> 
> The reason for all this is that NMT initialization happens very early, on the first call to `os::malloc()`. And those calls happen already during dynamic C++ initialization - a long time before the VM gets around parsing arguments. So, regular VM argument parsing is too late to parse NMT arguments.
> 
> The current solution is to pass NMT arguments via a specially prepared environment variable: `NMT_LEVEL_<PID>=<NMT arguments>`. That environment variable has to be set by the embedding launcher, before it loads the libjvm. Since its name contains the PID, we cannot even set that variable in the shell before starting the launcher.
> 
> All that means that every launcher needs to especially parse and process the NMT arguments given at the command line (or via whatever method) and prepare the environment variable. `java` itself does this. This only works before the libjvm.so is loaded, before its dynamic C++ initialization. For that reason, it does not work if the launcher links statically against the hotspot, since in that case C++ initialization of the launcher and hotspot are folded into one phase with no possibility of executing code beforehand.
> 
> And since it bypasses argument handling in the VM, it bypasses a number of argument processing ways, e.g., `JAVA_TOOL_OPTIONS`.
> 
> ------
> 
> This patch fixes these shortcomings by making NMT late-initializable: it can now be initialized after normal VM argument parsing, like all other parts of the VM. This greatly simplifies NMT initialization and makes it work automagically for every third party launcher, as well as within our gtests.
> 
> The glaring problem with late-initializing NMT is the NMT malloc headers. If we rule out just always having them (unacceptable in terms of memory overhead), there is no safe way to determine, in os::free(), if an allocation came from before or after NMT initialization ran, and therefore what to do with its malloc headers. For a more extensive explanation, please see the comment block `nmtPreInit.hpp` and the discussion with @kimbarrett and @zhengyu123 in the JBS comment section.
> 
> The heart of this patch is a new way to track early, pre-NMT-init allocations. These are tracked via a lookup table. This was a suggestion by Kim and it worked out well.
> 
> Changes in detail:
> 
> - pre-NMT-init handling:
> 	- the new files `nmtPreInit.hpp/cpp` take case of NMT pre-init handling. They contain a small global lookup table managing C-heap blocks allocated in the pre-NMT-init phase.
> 	- `os::malloc()/os::realloc()/os::free()` defer to this code before doing anything else.
> 	- Please see the extensive comment block at the start of `nmtPreinit.hpp` explaining the details.
> 
> - Changes to NMT:
> 	- Before, NMT initialization was spread over two phases, `initialize()` and `late_initialize()`. Those were merged into one and simplified - there is only one initialization now which happens after argument parsing.
> 	- Minor changes were needed for the `NMT_TrackingLevel` enum - to simplify code, I changed NMT_unknown to be numerically 0. A new comment block in `nmtCommon.hpp` now clearly specifies what's what, including allowed level state transitions.
> 	- New utility functions to translate tracking level from/to strings added to `NMTUtil`
> 	- NMT has never been able to handle virtual memory allocations before initialization, which is fine since os::reserve_memory() is not called before VM parses arguments. We now assert that.
> 	- All code outside the VM handling NMT initialization (eg. libjli) has been removed, as has the code testing it.
> 
> - Gtests:
> 	- Some existing gtests had to be modified: before, they all changed global state (turning NMT on/off) before testing. This is not allowed anymore, to keep NMT simple. Also, this pattern disturbed other tests.
> 	- The new way to test is to passively check whether NMT has been switched on or off, and do tests accordingly: if on, full tests, if off, test just what makes sense in off-state. That does not disturb neighboring tests, gives us actually better coverage all around.
> 	- It is now possible to start the gtestlauncher with NMT on! Which additionally gives us good coverage.
> 	- To actually do gtests with NMT - since it's disabled by default - we now run NMT-enabled gtests as part of the hotspot jtreg NMT wrapper. This pattern we have done for a number of other facitilites, see all the tests in test/hotspot/jtreg/gtest.. . It works very well.
> 	- Finally, a new gtest has been written to test the NMT preinit lookup map in isolation, placed in `gtest/nmt/test_nmtpreinitmap.cpp`.
> 	
> - jtreg:
> 	- A new test has been added, `runtime/NMT/NMTInitializationTest.java`, testing NMT initialization in the face of many many VM arguments.
> 
> -------------
> 
> Tests:
> - ran manually all new tests on 64-bit and 32-bit Linux
> - GHAs
> - The patch has been active in SAPs test systems for a while now.

Sorry for late review. 

Did a quick scan and have a few questions, will do more detail reading later.

src/hotspot/share/services/nmtPreInit.hpp line 108:

> 106: //   - lookup speed is paramount since lookup is done for every os::free() call.
> 107: //   - insert/delete speed only matters for VM startup - after NMT initialization the lookup
> 108: //     table is readonly

This comment does not seem to be true, you have find_and_remove() that alters table.

src/hotspot/share/services/nmtPreInit.hpp line 202:

> 200:     assert((*aa) != NULL, "Entry not found: " PTR_FORMAT, p2i(p));
> 201:     NMTPreInitAllocation* a = (*aa);
> 202:     (*aa) = (*aa)->next;         // remove from its list

Could this be a race? There is no synchronization, read/write result could be arbitrary.

src/hotspot/share/services/nmtPreInit.hpp line 309:

> 307:         ::memcpy(p_new, a->payload(), MIN2(a->size, new_size));
> 308:         (*rc) = p_new;
> 309:         _num_reallocs_pre_to_post++;

post-NMT-init counter updates are racy.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4874

From iignatyev at openjdk.java.net  Fri Jul 30 15:36:35 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Fri, 30 Jul 2021 15:36:35 GMT
Subject: [jdk17] RFR: 8067223: [TESTBUG] Rename Whitebox API package
In-Reply-To: <_3viZFs2iZ00hMdeP3Nq9gTmwfIHeTzZ7NVT8thQ1BM=.10005882-f135-4592-a663-b75747da3f6c@github.com>
References: <39PNb3wa-43yB5IFR3XroqFf4vMNZPitzF85lO1Gw58=.f2587741-d2c4-467d-b722-b17269587e7a@github.com>
 <_3viZFs2iZ00hMdeP3Nq9gTmwfIHeTzZ7NVT8thQ1BM=.10005882-f135-4592-a663-b75747da3f6c@github.com>
Message-ID: <vbMMrWc-L2sFBeqYiJ65t7TlmvhtrG_bXJhpONPqBfs=.ea8d576a-7a39-4cd0-b709-a6b5b96637e9@github.com>

On Thu, 29 Jul 2021 01:30:37 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Hi all,
>> 
>> could you please review this big tedious and trivial(-ish) patch which moves `sun.hotspot.WhiteBox` and related classes to `jdk.test.whitebox` package?
>> 
>> the majority of the patch is the following substitutions:
>>  - `s~sun/hotspot/WhiteBox~jdk/test/whitebox/WhiteBox~g`
>>  - `s/sun.hotspot.parser/jdk.test.whitebox.parser/g`
>>  - `s/sun.hotspot.cpuinfo/jdk.test.whitebox.cpuinfo/g`
>>  - `s/sun.hotspot.code/jdk.test.whitebox.code/g`
>>  - `s/sun.hotspot.gc/jdk.test.whitebox.gc/g`
>>  - `s/sun.hotspot.WhiteBox/jdk.test.whitebox.WhiteBox/g`
>> 
>> testing: tier1-4
>> 
>> Thanks,
>> -- Igor
>
> I know that tests fixes could be pushed during RDP2 without approval.
> But these one is very big and it is not a fix - it is enhancement.
> 
> What is the reason you want to push it into JDK 17 just few days before first Release Candidate? Instead of pushing it into JDK 18.
> 
> And I can't even review it because GutHub UI hangs on these big changes.

@vnkozlov, @dholmes-ora,

Thank you for looking at this!

I want this to be integrated into JDK 17 b/c some "external" libraries use (used to use) WhiteBox API, e.g. jcstress[[2]] used WhiteBox API to deoptimize compiled methods[[3]], and it would be easier for maintainers of such libraries to condition package name based on JDK major version. Also, given JDK 17 is an LTS, it would be beneficial for everyone not to have big differences in test bases b/w it and the mainline.

according to JEP 3, test RFEs are allowed until the very end and don't require late enhancement approval: "Enhancements to tests and documentation during RDP 1 and RDP 2 do not require approval, as long as the relevant issues are identified with a noreg-self or noreg-doc label, as appropriate"[[1]]. So, process-wise, I don't see any issues w/ integrating this RFE, yet, I fully agree that due to its size, this patch can be disruptive and can cause massive failures, which is something we obviously don't want at the current stage of JDK 17. 

I like David's idea about phasing this clean-up, and, due to the reasons described above, I would like to integrate the first part, copying WhiteBox classes to the new package structure and associated changes w/o updating all the tests, into JDK 17 and update the tests on the mainline (w/ backporting into jdk17u).

WDYT?

Cheers,
-- Igor

[1]: https://openjdk.java.net/jeps/3#Late-Enhancement-Request-Process
[2]: https://github.com/openjdk/jcstress
[3]: https://github.com/openjdk/jcstress/blob/df83b446f187ae0b0fa31fa54decb59db9e955da/jcstress-core/src/main/java/org/openjdk/jcstress/vm/WhiteBoxSupport.java

-------------

PR: https://git.openjdk.java.net/jdk17/pull/290

From lancea at openjdk.java.net  Fri Jul 30 15:43:52 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Fri, 30 Jul 2021 15:43:52 GMT
Subject: RFR: 8251329: (zipfs) Files.walkFileTree walks infinitely if zip
 has dir named "." inside [v5]
In-Reply-To: <BnwVE1xrk_yNwA-SSQWdU-s3Q6aWxeoNn2udHvQi9QE=.40ebc385-34fd-4be1-98ea-1514c46c89fb@github.com>
References: <BnwVE1xrk_yNwA-SSQWdU-s3Q6aWxeoNn2udHvQi9QE=.40ebc385-34fd-4be1-98ea-1514c46c89fb@github.com>
Message-ID: <O0Y1U6kfFjKDahEZNqTPyZt1NLLYSC9dgo5dd9AzIJU=.c0af9501-bb91-4cca-849b-cf6989110f28@github.com>

> Hi,
> 
> As discussed in the https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-July/079621.html thread, this is the revised patch to address the use of '.' and '..' within Zip FS
> 
> Zip FS needs to use "." and ".." as links to the current and parent directories and cannot reliably support entries that have "." and ".." as name elements.  This patch updates Zip Fs  to reject ZIP files that have entries in the CEN that can't be used for files in a file system.
> 
> 
> Mach5 tiers 1 through 3 have been run without any errors encountered .
> 
> Best,
> Lance

Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:

  Update note added to Zip FS module-info

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4900/files
  - new: https://git.openjdk.java.net/jdk/pull/4900/files/67c726af..0bf065ea

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4900&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4900&range=03-04

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4900.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4900/head:pull/4900

PR: https://git.openjdk.java.net/jdk/pull/4900

From lancea at openjdk.java.net  Fri Jul 30 15:47:31 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Fri, 30 Jul 2021 15:47:31 GMT
Subject: RFR: 8251329: (zipfs) Files.walkFileTree walks infinitely if zip
 has dir named "." inside [v3]
In-Reply-To: <uGv-_9dkbCqhIeoCQhRJ7lEs3l22ZoVckOrHqcvsKac=.50c73a0d-37d6-41fa-8348-5f5c1a22ef12@github.com>
References: <BnwVE1xrk_yNwA-SSQWdU-s3Q6aWxeoNn2udHvQi9QE=.40ebc385-34fd-4be1-98ea-1514c46c89fb@github.com>
 <yDLTHJdWNZPTUfj2K0TAdMSGj21csVGcXorLKl2YVRk=.c41cf54d-28be-4414-82ab-36daa4cba473@github.com>
 <ylloIpcL8HiX8Q45Dv-4yi72VT6nyd8UMtdmWr4EuoY=.10f5d387-9743-410c-8df2-dc48a5711e5d@github.com>
 <uGv-_9dkbCqhIeoCQhRJ7lEs3l22ZoVckOrHqcvsKac=.50c73a0d-37d6-41fa-8348-5f5c1a22ef12@github.com>
Message-ID: <jVFxzEa0TAqVCyqF_As36AGCUSfAodpTQg0NuOIRQ8c=.e2e100e9-7b32-484a-9550-2053247017d1@github.com>

On Fri, 30 Jul 2021 11:24:37 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/jdk.zipfs/share/classes/module-info.java line 49:
>> 
>>> 47:  *
>>> 48:  * @implNote The Zip File System will throw a ZipException when opening an
>>> 49:  * existing Zip file that contains Zip entries with "." or ".." in its name elements.
>> 
>> Hello Lance, reading this sentence adds a bit of confusion since it uses the word "contains". Had I not known the implemenation details, this sentence would have made me think zip file with name elements of the form `foo.bar` or `hello..`  would also be rejected since these name elements "contain" `.` or `..`
>> 
>> Do you think we should change the word to something like "The Zip File System will throw a ZipException when opening an existing Zip file that has "." or ".." named entries"?
>
> I think the `@implNote` tag can be dropped here. For the text then maybe it could be tweaked to something like "The ZIP file system provider does not support opening an existing ZIP that contains entries with ...".

Updated the note removing `@impleNote` thought about pre-pending **Note:** to make the wording stick out but held off for now. Updated the Release note accordingly

Jaikiran,  I think the use of name elements is fine as we use similar phrasing in `Path::getName()`

-------------

PR: https://git.openjdk.java.net/jdk/pull/4900

From github.com+6394632+sercher at openjdk.java.net  Fri Jul 30 16:13:32 2021
From: github.com+6394632+sercher at openjdk.java.net (Sergey Chernyshev)
Date: Fri, 30 Jul 2021 16:13:32 GMT
Subject: Integrated: 8270321: Startup regressions in 18-b5 caused by
 JDK-8266310
In-Reply-To: <W0x401I1NqmAUe7fn05M-YVVBaP1yD98xoXz0kNw5UM=.a60b4e7d-c7e9-406e-bde4-1341519a439a@github.com>
References: <W0x401I1NqmAUe7fn05M-YVVBaP1yD98xoXz0kNw5UM=.a60b4e7d-c7e9-406e-bde4-1341519a439a@github.com>
Message-ID: <VmLeXD0LaFFUuwmQUARz-YauM4wXvxjFKCv76GgOxJc=.b1e2d7d9-0add-4513-9af3-9236b33ae3a6@github.com>

On Fri, 23 Jul 2021 18:03:31 GMT, Sergey Chernyshev <github.com+6394632+sercher at openjdk.org> wrote:

> Dear colleagues,
> 
> Please review the patch that replaces the lambdas with anonymous classes which solves the startup time regression as shown below.
> 
> I attached the Bytestacks flamegraphs for both original (regression) and fixed versions. The flamegraphs clearly show the lambdas were causing the performance issue.
> 
> [bytestacks_flamegraphs.zip](https://github.com/openjdk/jdk/files/6870446/bytestacks_flamegraphs.zip)
> 
> Although the proposed JDK-8270321 patch fixes the startup time (it might appear even better than it was before the regression was introduced, i.e. before JDK-8266310) and generally fixes the footprint regression, it may increase MaxRSS slightly compared to the version before JDK-8266310, which is shown in the below graphs. (updated)
> 
> ![StartupTime2](https://user-images.githubusercontent.com/6394632/126898224-a05fda62-f723-4f2c-9af9-e02cbfe1c9c8.png)
> 
> ![MaxRSS](https://user-images.githubusercontent.com/6394632/126822404-899ab904-efc1-4377-9e0d-d8cdb5c0e5d0.png)
> 
> (update: added ZGC graphs)
> 
> ![StartupTime_ZGC](https://user-images.githubusercontent.com/6394632/126898242-52c09582-c2a4-4623-aad2-f47055277193.png)
> 
> ![MaxRSS_ZGC](https://user-images.githubusercontent.com/6394632/126898244-31c3eeb5-a768-4a52-8960-960cc4a72d7b.png)
> 
> I additionally include the heap objects histograms to show the change does not increase the total live objects size significantly with only 1000 bytes the total difference, namely 1116128 bytes in 25002 live objects after the proposed fix JDK-8270321 compared to 1115128 bytes in 24990 objects in the version with the original patch reverted (i.e. before JDK-8266310).
> 
> [histograms.zip](https://github.com/openjdk/jdk/files/6870457/histograms.zip)
> 
> The patch was tested w/hotspot/tier1/tier2 test groups.

This pull request has now been integrated.

Changeset: 5b3c4182
Author:    Sergey Chernyshev <serge.chernyshev at bell-sw.com>
Committer: Alexander Scherbatiy <alexsch at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/5b3c418249cfb53ae2ba530bcbbcdb5e509e4775
Stats:     35 lines in 1 file changed: 17 ins; 3 del; 15 mod

8270321: Startup regressions in 18-b5 caused by JDK-8266310

Reviewed-by: mchung, alanb

-------------

PR: https://git.openjdk.java.net/jdk/pull/4893

From stuefe at openjdk.java.net  Fri Jul 30 16:31:29 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Fri, 30 Jul 2021 16:31:29 GMT
Subject: RFR: JDK-8256844: Make NMT late-initializable
In-Reply-To: <lWySsJZvEV89He7k4lBTTN_ki4qxE_UJ-4ZZ3ShYBHg=.74ad62ca-40d2-4003-a416-b82faa7608d9@github.com>
References: <Ze_dKp-5-dse_657jTXTD4kbHSBeOQcLvqeluE0DXjI=.9214cb10-f1f1-48cb-8d96-12621a51a904@github.com>
 <lWySsJZvEV89He7k4lBTTN_ki4qxE_UJ-4ZZ3ShYBHg=.74ad62ca-40d2-4003-a416-b82faa7608d9@github.com>
Message-ID: <jQJOR8fLq_Apjy_zQVeHHe-tgLq-hdUv75QPhF5EPhs=.12f3aef9-e711-4a91-bbb5-32d22ad8d14f@github.com>

On Fri, 30 Jul 2021 12:56:59 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> Short: this patch makes NMT available in custom-launcher scenarios and during gtests. It simplifies NMT initialization. It adds a lot of NMT-specific testing, cleans them up and makes them sideeffect-free.
>> 
>> ---------
>> 
>> NMT continues to be an extremely useful tool for SAP to tackle memory problems in the JVM.
>> 
>> However, NMT is of limited use due to the following restrictions:
>> 
>> - NMT cannot be used if the hotspot is embedded into a custom launcher unless the launcher actively cooperates. Just creating and invoking the JVM is not enough, it needs to do some steps prior to loading the hotspot. This limitation is not well known (nor, do I believe, documented). Many products don't do this, e.g., you cannot use NMT with IntelliJ. For us at SAP this problem limits NMT usefulness greatly since our VMs are often embedded into custom launchers and modifying every launcher is impossible.
>> - Worse, if that custom launcher links the libjvm *statically* there is just no way to activate NMT at all. This is the reason NMT cannot be used in the `gtestlauncher`.
>> - Related to that is that we cannot pass NMT options via `JAVA_TOOL_OPTIONS` and `-XX:Flags=<file>`.
>> - The fact that NMT cannot be used in gtests is really a pity since it would allow us to both test NMT itself more rigorously and check for memory leaks while testing other stuff.
>> 
>> The reason for all this is that NMT initialization happens very early, on the first call to `os::malloc()`. And those calls happen already during dynamic C++ initialization - a long time before the VM gets around parsing arguments. So, regular VM argument parsing is too late to parse NMT arguments.
>> 
>> The current solution is to pass NMT arguments via a specially prepared environment variable: `NMT_LEVEL_<PID>=<NMT arguments>`. That environment variable has to be set by the embedding launcher, before it loads the libjvm. Since its name contains the PID, we cannot even set that variable in the shell before starting the launcher.
>> 
>> All that means that every launcher needs to especially parse and process the NMT arguments given at the command line (or via whatever method) and prepare the environment variable. `java` itself does this. This only works before the libjvm.so is loaded, before its dynamic C++ initialization. For that reason, it does not work if the launcher links statically against the hotspot, since in that case C++ initialization of the launcher and hotspot are folded into one phase with no possibility of executing code beforehand.
>> 
>> And since it bypasses argument handling in the VM, it bypasses a number of argument processing ways, e.g., `JAVA_TOOL_OPTIONS`.
>> 
>> ------
>> 
>> This patch fixes these shortcomings by making NMT late-initializable: it can now be initialized after normal VM argument parsing, like all other parts of the VM. This greatly simplifies NMT initialization and makes it work automagically for every third party launcher, as well as within our gtests.
>> 
>> The glaring problem with late-initializing NMT is the NMT malloc headers. If we rule out just always having them (unacceptable in terms of memory overhead), there is no safe way to determine, in os::free(), if an allocation came from before or after NMT initialization ran, and therefore what to do with its malloc headers. For a more extensive explanation, please see the comment block `nmtPreInit.hpp` and the discussion with @kimbarrett and @zhengyu123 in the JBS comment section.
>> 
>> The heart of this patch is a new way to track early, pre-NMT-init allocations. These are tracked via a lookup table. This was a suggestion by Kim and it worked out well.
>> 
>> Changes in detail:
>> 
>> - pre-NMT-init handling:
>> 	- the new files `nmtPreInit.hpp/cpp` take case of NMT pre-init handling. They contain a small global lookup table managing C-heap blocks allocated in the pre-NMT-init phase.
>> 	- `os::malloc()/os::realloc()/os::free()` defer to this code before doing anything else.
>> 	- Please see the extensive comment block at the start of `nmtPreinit.hpp` explaining the details.
>> 
>> - Changes to NMT:
>> 	- Before, NMT initialization was spread over two phases, `initialize()` and `late_initialize()`. Those were merged into one and simplified - there is only one initialization now which happens after argument parsing.
>> 	- Minor changes were needed for the `NMT_TrackingLevel` enum - to simplify code, I changed NMT_unknown to be numerically 0. A new comment block in `nmtCommon.hpp` now clearly specifies what's what, including allowed level state transitions.
>> 	- New utility functions to translate tracking level from/to strings added to `NMTUtil`
>> 	- NMT has never been able to handle virtual memory allocations before initialization, which is fine since os::reserve_memory() is not called before VM parses arguments. We now assert that.
>> 	- All code outside the VM handling NMT initialization (eg. libjli) has been removed, as has the code testing it.
>> 
>> - Gtests:
>> 	- Some existing gtests had to be modified: before, they all changed global state (turning NMT on/off) before testing. This is not allowed anymore, to keep NMT simple. Also, this pattern disturbed other tests.
>> 	- The new way to test is to passively check whether NMT has been switched on or off, and do tests accordingly: if on, full tests, if off, test just what makes sense in off-state. That does not disturb neighboring tests, gives us actually better coverage all around.
>> 	- It is now possible to start the gtestlauncher with NMT on! Which additionally gives us good coverage.
>> 	- To actually do gtests with NMT - since it's disabled by default - we now run NMT-enabled gtests as part of the hotspot jtreg NMT wrapper. This pattern we have done for a number of other facitilites, see all the tests in test/hotspot/jtreg/gtest.. . It works very well.
>> 	- Finally, a new gtest has been written to test the NMT preinit lookup map in isolation, placed in `gtest/nmt/test_nmtpreinitmap.cpp`.
>> 	
>> - jtreg:
>> 	- A new test has been added, `runtime/NMT/NMTInitializationTest.java`, testing NMT initialization in the face of many many VM arguments.
>> 
>> -------------
>> 
>> Tests:
>> - ran manually all new tests on 64-bit and 32-bit Linux
>> - GHAs
>> - The patch has been active in SAPs test systems for a while now.
>
> src/hotspot/share/services/nmtPreInit.hpp line 202:
> 
>> 200:     assert((*aa) != NULL, "Entry not found: " PTR_FORMAT, p2i(p));
>> 201:     NMTPreInitAllocation* a = (*aa);
>> 202:     (*aa) = (*aa)->next;         // remove from its list
> 
> Could this be a race? There is no synchronization, read/write result could be arbitrary.

The code is implicitly thread-safe because the hashmap is only modified in the pre-NMT-init phase. After NMT initialization, the table is read-only. During pre-NMT-init we are effectively single-threaded - at most two threads access the map, the thread loading the libjvm, and the thread calling CreateJavaVM, but not at the same time.

See also the asserts in the AllStatic class `NMTPreInit`.

(I should have described it more clearly, will add a comment.)

-------------

PR: https://git.openjdk.java.net/jdk/pull/4874

From stuefe at openjdk.java.net  Fri Jul 30 16:39:31 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Fri, 30 Jul 2021 16:39:31 GMT
Subject: RFR: JDK-8256844: Make NMT late-initializable
In-Reply-To: <lWySsJZvEV89He7k4lBTTN_ki4qxE_UJ-4ZZ3ShYBHg=.74ad62ca-40d2-4003-a416-b82faa7608d9@github.com>
References: <Ze_dKp-5-dse_657jTXTD4kbHSBeOQcLvqeluE0DXjI=.9214cb10-f1f1-48cb-8d96-12621a51a904@github.com>
 <lWySsJZvEV89He7k4lBTTN_ki4qxE_UJ-4ZZ3ShYBHg=.74ad62ca-40d2-4003-a416-b82faa7608d9@github.com>
Message-ID: <oW65arkqYYvhUjDI2XBU7qXk4yuvlbhDsZgc4xUBQNU=.c7e82176-8b46-4999-bb31-6770ab7189ea@github.com>

On Fri, 30 Jul 2021 13:03:32 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> Sorry for late review.
> 
> Did a quick scan and have a few questions, will do more detail reading later.

Thanks a lot, I appreciate your feedback!

> src/hotspot/share/services/nmtPreInit.hpp line 108:
> 
>> 106: //   - lookup speed is paramount since lookup is done for every os::free() call.
>> 107: //   - insert/delete speed only matters for VM startup - after NMT initialization the lookup
>> 108: //     table is readonly
> 
> This comment does not seem to be true, you have find_and_remove() that alters table.

The point is *after NMT initialization* - `find_and_remove` only gets called before NMT initialization; after that, we only do non-modifying lookup. You'll find the logic in `NMTPreInit::handle_realloc()` and `NMTPreInit::handle_free()`, respectively.

The basic idea behind this is that we remove pointers from the map as long as we can without risking concurrency issues, which is until NMT initialization. After that, we leave the map alone. It was either that or protect the map with a lock, and this is the lesser of two evils since the map is usually sparsely populated.

> src/hotspot/share/services/nmtPreInit.hpp line 309:
> 
>> 307:         ::memcpy(p_new, a->payload(), MIN2(a->size, new_size));
>> 308:         (*rc) = p_new;
>> 309:         _num_reallocs_pre_to_post++;
> 
> post-NMT-init counter updates are racy.

True, this is racy. It's just for diagnostics though - I rather remove them than make them atomic since we would pay for this with every malloc. Or, maybe atomic + debug only?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4874

From zgu at openjdk.java.net  Fri Jul 30 16:39:31 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Fri, 30 Jul 2021 16:39:31 GMT
Subject: RFR: JDK-8256844: Make NMT late-initializable
In-Reply-To: <jQJOR8fLq_Apjy_zQVeHHe-tgLq-hdUv75QPhF5EPhs=.12f3aef9-e711-4a91-bbb5-32d22ad8d14f@github.com>
References: <Ze_dKp-5-dse_657jTXTD4kbHSBeOQcLvqeluE0DXjI=.9214cb10-f1f1-48cb-8d96-12621a51a904@github.com>
 <lWySsJZvEV89He7k4lBTTN_ki4qxE_UJ-4ZZ3ShYBHg=.74ad62ca-40d2-4003-a416-b82faa7608d9@github.com>
 <jQJOR8fLq_Apjy_zQVeHHe-tgLq-hdUv75QPhF5EPhs=.12f3aef9-e711-4a91-bbb5-32d22ad8d14f@github.com>
Message-ID: <WfwpvRjCoDqtG5CL_ZU5qTzS87AnWt4_ZcpXQtZQmmI=.f42fe57b-f85f-4714-a4c0-7210dc241ae2@github.com>

On Fri, 30 Jul 2021 16:28:54 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> src/hotspot/share/services/nmtPreInit.hpp line 202:
>> 
>>> 200:     assert((*aa) != NULL, "Entry not found: " PTR_FORMAT, p2i(p));
>>> 201:     NMTPreInitAllocation* a = (*aa);
>>> 202:     (*aa) = (*aa)->next;         // remove from its list
>> 
>> Could this be a race? There is no synchronization, read/write result could be arbitrary.
>
> The code is implicitly thread-safe because the hashmap is only modified in the pre-NMT-init phase. After NMT initialization, the table is read-only. During pre-NMT-init we are effectively single-threaded - at most two threads access the map, the thread loading the libjvm, and the thread calling CreateJavaVM, but not at the same time.
> 
> See also the asserts in the AllStatic class `NMTPreInit`.
> 
> (I should have described it more clearly, will add a comment.)

So, you are saying that there is no memory that is malloc'd pre-NMT-init phase and freed post-NMT-init phase?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4874

From naoto at openjdk.java.net  Fri Jul 30 17:09:29 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 30 Jul 2021 17:09:29 GMT
Subject: RFR: 8251329: (zipfs) Files.walkFileTree walks infinitely if zip
 has dir named "." inside [v5]
In-Reply-To: <O0Y1U6kfFjKDahEZNqTPyZt1NLLYSC9dgo5dd9AzIJU=.c0af9501-bb91-4cca-849b-cf6989110f28@github.com>
References: <BnwVE1xrk_yNwA-SSQWdU-s3Q6aWxeoNn2udHvQi9QE=.40ebc385-34fd-4be1-98ea-1514c46c89fb@github.com>
 <O0Y1U6kfFjKDahEZNqTPyZt1NLLYSC9dgo5dd9AzIJU=.c0af9501-bb91-4cca-849b-cf6989110f28@github.com>
Message-ID: <V9bOfRpGfDTHX_vRB0eVxsOemTo-GXAtkrEdbQkT8dA=.540f8940-214c-43de-808c-01bfbd9b81dd@github.com>

On Fri, 30 Jul 2021 15:43:52 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Hi,
>> 
>> As discussed in the https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-July/079621.html thread, this is the revised patch to address the use of '.' and '..' within Zip FS
>> 
>> Zip FS needs to use "." and ".." as links to the current and parent directories and cannot reliably support entries that have "." and ".." as name elements.  This patch updates Zip Fs  to reject ZIP files that have entries in the CEN that can't be used for files in a file system.
>> 
>> 
>> Mach5 tiers 1 through 3 have been run without any errors encountered .
>> 
>> Best,
>> Lance
>
> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update note added to Zip FS module-info

Looks good to me.

test/jdk/jdk/nio/zipfs/HasDotDotTest.java line 116:

> 114:     @Test(dataProvider = "checkForDotOrDotDotPaths")
> 115:     public void hasDotOrDotDotTest(String path) throws IOException {
> 116:         if(DEBUG) {

Nit: space after `if`

-------------

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4900

From lancea at openjdk.java.net  Fri Jul 30 17:22:59 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Fri, 30 Jul 2021 17:22:59 GMT
Subject: RFR: 8251329: (zipfs) Files.walkFileTree walks infinitely if zip
 has dir named "." inside [v6]
In-Reply-To: <BnwVE1xrk_yNwA-SSQWdU-s3Q6aWxeoNn2udHvQi9QE=.40ebc385-34fd-4be1-98ea-1514c46c89fb@github.com>
References: <BnwVE1xrk_yNwA-SSQWdU-s3Q6aWxeoNn2udHvQi9QE=.40ebc385-34fd-4be1-98ea-1514c46c89fb@github.com>
Message-ID: <14bj0f-zLqVMsHsMvKV96kj8VyhOHya_6eOHj2DUbnM=.8f96c9d0-d64b-47bc-9f97-0b5b3a037e16@github.com>

> Hi,
> 
> As discussed in the https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-July/079621.html thread, this is the revised patch to address the use of '.' and '..' within Zip FS
> 
> Zip FS needs to use "." and ".." as links to the current and parent directories and cannot reliably support entries that have "." and ".." as name elements.  This patch updates Zip Fs  to reject ZIP files that have entries in the CEN that can't be used for files in a file system.
> 
> 
> Mach5 tiers 1 through 3 have been run without any errors encountered .
> 
> Best,
> Lance

Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:

  Add missing space in if statement

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4900/files
  - new: https://git.openjdk.java.net/jdk/pull/4900/files/0bf065ea..292e698f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4900&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4900&range=04-05

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4900.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4900/head:pull/4900

PR: https://git.openjdk.java.net/jdk/pull/4900

From zgu at openjdk.java.net  Fri Jul 30 18:57:35 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Fri, 30 Jul 2021 18:57:35 GMT
Subject: RFR: JDK-8256844: Make NMT late-initializable
In-Reply-To: <oW65arkqYYvhUjDI2XBU7qXk4yuvlbhDsZgc4xUBQNU=.c7e82176-8b46-4999-bb31-6770ab7189ea@github.com>
References: <Ze_dKp-5-dse_657jTXTD4kbHSBeOQcLvqeluE0DXjI=.9214cb10-f1f1-48cb-8d96-12621a51a904@github.com>
 <lWySsJZvEV89He7k4lBTTN_ki4qxE_UJ-4ZZ3ShYBHg=.74ad62ca-40d2-4003-a416-b82faa7608d9@github.com>
 <oW65arkqYYvhUjDI2XBU7qXk4yuvlbhDsZgc4xUBQNU=.c7e82176-8b46-4999-bb31-6770ab7189ea@github.com>
Message-ID: <f2oANLOKxbfmlyrVjNFONloPdvC5jl6d6VkQT4x8MvU=.0ba34ab9-34a2-4b0d-a6d5-1b0bde7a83b0@github.com>

On Fri, 30 Jul 2021 16:36:41 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> src/hotspot/share/services/nmtPreInit.hpp line 309:
>> 
>>> 307:         ::memcpy(p_new, a->payload(), MIN2(a->size, new_size));
>>> 308:         (*rc) = p_new;
>>> 309:         _num_reallocs_pre_to_post++;
>> 
>> post-NMT-init counter updates are racy.
>
> True, this is racy. It's just for diagnostics though - I rather remove them than make them atomic since we would pay for this with every malloc. Or, maybe atomic + debug only?

Either one is fine.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4874

From stuefe at openjdk.java.net  Fri Jul 30 18:57:32 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Fri, 30 Jul 2021 18:57:32 GMT
Subject: RFR: JDK-8256844: Make NMT late-initializable
In-Reply-To: <UUeV2veIE-FOsxkNuNFGB4qRsvlnf7RDRcN99vy890U=.b670144b-0f33-4696-805f-ee2c338be99f@github.com>
References: <Ze_dKp-5-dse_657jTXTD4kbHSBeOQcLvqeluE0DXjI=.9214cb10-f1f1-48cb-8d96-12621a51a904@github.com>
 <lWySsJZvEV89He7k4lBTTN_ki4qxE_UJ-4ZZ3ShYBHg=.74ad62ca-40d2-4003-a416-b82faa7608d9@github.com>
 <jQJOR8fLq_Apjy_zQVeHHe-tgLq-hdUv75QPhF5EPhs=.12f3aef9-e711-4a91-bbb5-32d22ad8d14f@github.com>
 <WfwpvRjCoDqtG5CL_ZU5qTzS87AnWt4_ZcpXQtZQmmI=.f42fe57b-f85f-4714-a4c0-7210dc241ae2@github.com>
 <UUeV2veIE-FOsxkNuNFGB4qRsvlnf7RDRcN99vy890U=.b670144b-0f33-4696-805f-ee2c338be99f@github.com>
Message-ID: <ps2U4K4ivBDuU4N6VtruTbXqj-iTxXyB6x7-CsjhREs=.05eaedad-e12b-4300-a0e3-cd5a848c5eba@github.com>

On Fri, 30 Jul 2021 18:28:44 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> So, you are saying that there is no memory that is malloc'd pre-NMT-init phase and freed post-NMT-init phase?
>
> Okay, I see. It just leaks those memory, so the table can be read-only.

Exactly. There are a few allocs that either get free'd or realloc'ed post-init, but not enough to make freeing them worth it if it means having to serialize access to the lookup table.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4874

From zgu at openjdk.java.net  Fri Jul 30 18:57:31 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Fri, 30 Jul 2021 18:57:31 GMT
Subject: RFR: JDK-8256844: Make NMT late-initializable
In-Reply-To: <WfwpvRjCoDqtG5CL_ZU5qTzS87AnWt4_ZcpXQtZQmmI=.f42fe57b-f85f-4714-a4c0-7210dc241ae2@github.com>
References: <Ze_dKp-5-dse_657jTXTD4kbHSBeOQcLvqeluE0DXjI=.9214cb10-f1f1-48cb-8d96-12621a51a904@github.com>
 <lWySsJZvEV89He7k4lBTTN_ki4qxE_UJ-4ZZ3ShYBHg=.74ad62ca-40d2-4003-a416-b82faa7608d9@github.com>
 <jQJOR8fLq_Apjy_zQVeHHe-tgLq-hdUv75QPhF5EPhs=.12f3aef9-e711-4a91-bbb5-32d22ad8d14f@github.com>
 <WfwpvRjCoDqtG5CL_ZU5qTzS87AnWt4_ZcpXQtZQmmI=.f42fe57b-f85f-4714-a4c0-7210dc241ae2@github.com>
Message-ID: <UUeV2veIE-FOsxkNuNFGB4qRsvlnf7RDRcN99vy890U=.b670144b-0f33-4696-805f-ee2c338be99f@github.com>

On Fri, 30 Jul 2021 16:33:17 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> The code is implicitly thread-safe because the hashmap is only modified in the pre-NMT-init phase. After NMT initialization, the table is read-only. During pre-NMT-init we are effectively single-threaded - at most two threads access the map, the thread loading the libjvm, and the thread calling CreateJavaVM, but not at the same time.
>> 
>> See also the asserts in the AllStatic class `NMTPreInit`.
>> 
>> (I should have described it more clearly, will add a comment.)
>
> So, you are saying that there is no memory that is malloc'd pre-NMT-init phase and freed post-NMT-init phase?

Okay, I see. It just leaks those memory, so the table can be read-only.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4874

From zgu at openjdk.java.net  Fri Jul 30 20:17:32 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Fri, 30 Jul 2021 20:17:32 GMT
Subject: RFR: JDK-8256844: Make NMT late-initializable
In-Reply-To: <Ze_dKp-5-dse_657jTXTD4kbHSBeOQcLvqeluE0DXjI=.9214cb10-f1f1-48cb-8d96-12621a51a904@github.com>
References: <Ze_dKp-5-dse_657jTXTD4kbHSBeOQcLvqeluE0DXjI=.9214cb10-f1f1-48cb-8d96-12621a51a904@github.com>
Message-ID: <q0uMTkqIIoUJ-tNbreJxKT6tvRlPw84OPD00gqfllpI=.aa38b235-be60-4cab-a51d-f82604868f4e@github.com>

On Thu, 22 Jul 2021 14:58:47 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Short: this patch makes NMT available in custom-launcher scenarios and during gtests. It simplifies NMT initialization. It adds a lot of NMT-specific testing, cleans them up and makes them sideeffect-free.
> 
> ---------
> 
> NMT continues to be an extremely useful tool for SAP to tackle memory problems in the JVM.
> 
> However, NMT is of limited use due to the following restrictions:
> 
> - NMT cannot be used if the hotspot is embedded into a custom launcher unless the launcher actively cooperates. Just creating and invoking the JVM is not enough, it needs to do some steps prior to loading the hotspot. This limitation is not well known (nor, do I believe, documented). Many products don't do this, e.g., you cannot use NMT with IntelliJ. For us at SAP this problem limits NMT usefulness greatly since our VMs are often embedded into custom launchers and modifying every launcher is impossible.
> - Worse, if that custom launcher links the libjvm *statically* there is just no way to activate NMT at all. This is the reason NMT cannot be used in the `gtestlauncher`.
> - Related to that is that we cannot pass NMT options via `JAVA_TOOL_OPTIONS` and `-XX:Flags=<file>`.
> - The fact that NMT cannot be used in gtests is really a pity since it would allow us to both test NMT itself more rigorously and check for memory leaks while testing other stuff.
> 
> The reason for all this is that NMT initialization happens very early, on the first call to `os::malloc()`. And those calls happen already during dynamic C++ initialization - a long time before the VM gets around parsing arguments. So, regular VM argument parsing is too late to parse NMT arguments.
> 
> The current solution is to pass NMT arguments via a specially prepared environment variable: `NMT_LEVEL_<PID>=<NMT arguments>`. That environment variable has to be set by the embedding launcher, before it loads the libjvm. Since its name contains the PID, we cannot even set that variable in the shell before starting the launcher.
> 
> All that means that every launcher needs to especially parse and process the NMT arguments given at the command line (or via whatever method) and prepare the environment variable. `java` itself does this. This only works before the libjvm.so is loaded, before its dynamic C++ initialization. For that reason, it does not work if the launcher links statically against the hotspot, since in that case C++ initialization of the launcher and hotspot are folded into one phase with no possibility of executing code beforehand.
> 
> And since it bypasses argument handling in the VM, it bypasses a number of argument processing ways, e.g., `JAVA_TOOL_OPTIONS`.
> 
> ------
> 
> This patch fixes these shortcomings by making NMT late-initializable: it can now be initialized after normal VM argument parsing, like all other parts of the VM. This greatly simplifies NMT initialization and makes it work automagically for every third party launcher, as well as within our gtests.
> 
> The glaring problem with late-initializing NMT is the NMT malloc headers. If we rule out just always having them (unacceptable in terms of memory overhead), there is no safe way to determine, in os::free(), if an allocation came from before or after NMT initialization ran, and therefore what to do with its malloc headers. For a more extensive explanation, please see the comment block `nmtPreInit.hpp` and the discussion with @kimbarrett and @zhengyu123 in the JBS comment section.
> 
> The heart of this patch is a new way to track early, pre-NMT-init allocations. These are tracked via a lookup table. This was a suggestion by Kim and it worked out well.
> 
> Changes in detail:
> 
> - pre-NMT-init handling:
> 	- the new files `nmtPreInit.hpp/cpp` take case of NMT pre-init handling. They contain a small global lookup table managing C-heap blocks allocated in the pre-NMT-init phase.
> 	- `os::malloc()/os::realloc()/os::free()` defer to this code before doing anything else.
> 	- Please see the extensive comment block at the start of `nmtPreinit.hpp` explaining the details.
> 
> - Changes to NMT:
> 	- Before, NMT initialization was spread over two phases, `initialize()` and `late_initialize()`. Those were merged into one and simplified - there is only one initialization now which happens after argument parsing.
> 	- Minor changes were needed for the `NMT_TrackingLevel` enum - to simplify code, I changed NMT_unknown to be numerically 0. A new comment block in `nmtCommon.hpp` now clearly specifies what's what, including allowed level state transitions.
> 	- New utility functions to translate tracking level from/to strings added to `NMTUtil`
> 	- NMT has never been able to handle virtual memory allocations before initialization, which is fine since os::reserve_memory() is not called before VM parses arguments. We now assert that.
> 	- All code outside the VM handling NMT initialization (eg. libjli) has been removed, as has the code testing it.
> 
> - Gtests:
> 	- Some existing gtests had to be modified: before, they all changed global state (turning NMT on/off) before testing. This is not allowed anymore, to keep NMT simple. Also, this pattern disturbed other tests.
> 	- The new way to test is to passively check whether NMT has been switched on or off, and do tests accordingly: if on, full tests, if off, test just what makes sense in off-state. That does not disturb neighboring tests, gives us actually better coverage all around.
> 	- It is now possible to start the gtestlauncher with NMT on! Which additionally gives us good coverage.
> 	- To actually do gtests with NMT - since it's disabled by default - we now run NMT-enabled gtests as part of the hotspot jtreg NMT wrapper. This pattern we have done for a number of other facitilites, see all the tests in test/hotspot/jtreg/gtest.. . It works very well.
> 	- Finally, a new gtest has been written to test the NMT preinit lookup map in isolation, placed in `gtest/nmt/test_nmtpreinitmap.cpp`.
> 	
> - jtreg:
> 	- A new test has been added, `runtime/NMT/NMTInitializationTest.java`, testing NMT initialization in the face of many many VM arguments.
> 
> -------------
> 
> Tests:
> - ran manually all new tests on 64-bit and 32-bit Linux
> - GHAs
> - The patch has been active in SAPs test systems for a while now.

Looks good in general.

src/hotspot/share/services/nmtPreInit.hpp line 153:

> 151: 
> 152:   static unsigned calculate_hash(const void* p) {
> 153:     uintptr_t tmp = p2i(p);

malloc memory usually is 2-machine word aligned, maybe tmp = tmp >> LP64_ONLY(4) NOT_LP64(3) can result better hash distribution?

-------------

Marked as reviewed by zgu (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4874

From alanb at openjdk.java.net  Sat Jul 31 09:40:31 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sat, 31 Jul 2021 09:40:31 GMT
Subject: RFR: 8251329: (zipfs) Files.walkFileTree walks infinitely if zip
 has dir named "." inside [v6]
In-Reply-To: <14bj0f-zLqVMsHsMvKV96kj8VyhOHya_6eOHj2DUbnM=.8f96c9d0-d64b-47bc-9f97-0b5b3a037e16@github.com>
References: <BnwVE1xrk_yNwA-SSQWdU-s3Q6aWxeoNn2udHvQi9QE=.40ebc385-34fd-4be1-98ea-1514c46c89fb@github.com>
 <14bj0f-zLqVMsHsMvKV96kj8VyhOHya_6eOHj2DUbnM=.8f96c9d0-d64b-47bc-9f97-0b5b3a037e16@github.com>
Message-ID: <eef9RQM0P7hYZSw-_W4wj8F0_rDbM_pDk7arxbrF4hM=.576373e1-e180-4f18-8e6e-f946e280ea7c@github.com>

On Fri, 30 Jul 2021 17:22:59 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Hi,
>> 
>> As discussed in the https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-July/079621.html thread, this is the revised patch to address the use of '.' and '..' within Zip FS
>> 
>> Zip FS needs to use "." and ".." as links to the current and parent directories and cannot reliably support entries that have "." and ".." as name elements.  This patch updates Zip Fs  to reject ZIP files that have entries in the CEN that can't be used for files in a file system.
>> 
>> 
>> Mach5 tiers 1 through 3 have been run without any errors encountered .
>> 
>> Best,
>> Lance
>
> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add missing space in if statement

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4900

From github.com+1701815+mkarg at openjdk.java.net  Sat Jul 31 13:17:09 2021
From: github.com+1701815+mkarg at openjdk.java.net (Markus KARG)
Date: Sat, 31 Jul 2021 13:17:09 GMT
Subject: RFR: 8265891: (ch) InputStream returned by
 Channels.newInputStream should override transferTo [v6]
In-Reply-To: <RL6f0JWEcP22xlawlCxU3zhNrUhJ6iy_rgEr2ZXA688=.b4abee11-6c2c-4d60-8790-e6b05c45f10f@github.com>
References: <XlU5gCBUEa4qTTz8yhMeElh95FuiPcFYQ_nj_WYvbLE=.6e9fc6a4-f3b1-4faf-91f0-d8b06f875780@github.com>
 <5PpEoJT1JZoo75hz4HAQFkipRfXCr_7MyTE8g4yhhgc=.5eeefcfe-205b-4b02-a59b-bead8b410139@github.com>
 <IZKluRfiLnIovyrAw3TdXDSzB6e59nHmG3ee7PEtjSE=.a778bb70-9938-4599-a3d9-9ad8fa235b00@github.com>
 <D-BolUEcvPGEA-JzbvXEUQTtaxUbl7duhesuVERIZc4=.4edfe8a0-8284-45cf-a2ad-993d795b14b6@github.com>
 <UQzAp1eaWHObRgVpa8bwHLdbdyauIE9NdpDd-MwsvUM=.cd00637c-80bf-43da-8ab3-97825a7d92d0@github.com>
 <AC0DI4y81YwidEwnIAAqKjbRCPrFWdBJVz1k2LmOvu8=.497fd5dc-91b2-4294-8049-a5766323539a@github.com>
 <RL6f0JWEcP22xlawlCxU3zhNrUhJ6iy_rgEr2ZXA688=.b4abee11-6c2c-4d60-8790-e6b05c45f10f@github.com>
Message-ID: <v6VO-i9pTbZ-nFktsPex13dbxWkznsSCUtUbWiSltm8=.807072c3-d39a-47b0-ae2c-bf21a41c264b@github.com>

On Fri, 30 Jul 2021 12:09:30 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Just on naming, the existing channel implementations use "dst" for the destination and "wbc" (not "oc") for writable byte channels. Just mentioning it so that the new code can be kept consistent where possible.

I have renamed `dest` to `dst` and `oc` to `wbc` in https://github.com/openjdk/jdk/pull/4263/commits/f91d5422c41e25410a81aad54a45b2d0e171305a.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4263

From github.com+1701815+mkarg at openjdk.java.net  Sat Jul 31 13:17:08 2021
From: github.com+1701815+mkarg at openjdk.java.net (Markus KARG)
Date: Sat, 31 Jul 2021 13:17:08 GMT
Subject: RFR: 8265891: (ch) InputStream returned by
 Channels.newInputStream should override transferTo [v7]
In-Reply-To: <XlU5gCBUEa4qTTz8yhMeElh95FuiPcFYQ_nj_WYvbLE=.6e9fc6a4-f3b1-4faf-91f0-d8b06f875780@github.com>
References: <XlU5gCBUEa4qTTz8yhMeElh95FuiPcFYQ_nj_WYvbLE=.6e9fc6a4-f3b1-4faf-91f0-d8b06f875780@github.com>
Message-ID: <sNd5lVF-Z9OoK1ltwyCzLC-5xXSwPTUda-oEpKo5rJQ=.9319c08d-c044-422f-8500-3be4ba2773db@github.com>

> This PR-*draft* is **work in progress** and an invitation to discuss a possible solution for issue [JDK-8265891](https://bugs.openjdk.java.net/browse/JDK-8265891). It is *not yet* intended for a final review.
> 
> As proposed in JDK-8265891, this PR provides an implementation for `Channels.newInputStream().transferTo()` which provide superior performance compared to the current implementation. The changes are:
> * Prevents transfers through the JVM heap as much as possibly by offloading to deeper levels via NIO, hence allowing the operating system to optimize the transfer.
> * Using more JRE heap in the fallback case when no NIO is possible (still only KiBs, hence mostl ynegligible even on SBCs) to better perform on modern hardware / fast I/O devides.
> 
> Using JMH I have benchmarked both, the original implementation and this implementation, and (depending on the used hardware and use case) performance change was approx. doubled performance. So this PoC proofs that it makes sense to finalize this work and turn it into an actual OpenJDK contribution. 
> 
> I encourage everybody to discuss this draft:
> * Are there valid arguments for *not* doing this change?
> * Is there a *better* way to improve performance of `Channels.newInputStream().transferTo()`?
> * How to go on from here: What is missing to get this ready for an actual review?

Markus KARG has updated the pull request incrementally with one additional commit since the last revision:

  Draft: Renamed oc to wbc and dest to dst

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4263/files
  - new: https://git.openjdk.java.net/jdk/pull/4263/files/1f9dba3d..f91d5422

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4263&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4263&range=05-06

  Stats: 17 lines in 1 file changed: 0 ins; 0 del; 17 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4263.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4263/head:pull/4263

PR: https://git.openjdk.java.net/jdk/pull/4263

From github.com+1701815+mkarg at openjdk.java.net  Sat Jul 31 14:14:03 2021
From: github.com+1701815+mkarg at openjdk.java.net (Markus KARG)
Date: Sat, 31 Jul 2021 14:14:03 GMT
Subject: RFR: 8265891: (ch) InputStream returned by
 Channels.newInputStream should override transferTo [v8]
In-Reply-To: <XlU5gCBUEa4qTTz8yhMeElh95FuiPcFYQ_nj_WYvbLE=.6e9fc6a4-f3b1-4faf-91f0-d8b06f875780@github.com>
References: <XlU5gCBUEa4qTTz8yhMeElh95FuiPcFYQ_nj_WYvbLE=.6e9fc6a4-f3b1-4faf-91f0-d8b06f875780@github.com>
Message-ID: <MdGtXn1mTIdFLuD9JnJgGq8p24Q6duL2_u5rSR0DZyk=.c64f1f51-0a40-4851-ad2f-06ce16585d8b@github.com>

> This PR-*draft* is **work in progress** and an invitation to discuss a possible solution for issue [JDK-8265891](https://bugs.openjdk.java.net/browse/JDK-8265891). It is *not yet* intended for a final review.
> 
> As proposed in JDK-8265891, this PR provides an implementation for `Channels.newInputStream().transferTo()` which provide superior performance compared to the current implementation. The changes are:
> * Prevents transfers through the JVM heap as much as possibly by offloading to deeper levels via NIO, hence allowing the operating system to optimize the transfer.
> * Using more JRE heap in the fallback case when no NIO is possible (still only KiBs, hence mostl ynegligible even on SBCs) to better perform on modern hardware / fast I/O devides.
> 
> Using JMH I have benchmarked both, the original implementation and this implementation, and (depending on the used hardware and use case) performance change was approx. doubled performance. So this PoC proofs that it makes sense to finalize this work and turn it into an actual OpenJDK contribution. 
> 
> I encourage everybody to discuss this draft:
> * Are there valid arguments for *not* doing this change?
> * Is there a *better* way to improve performance of `Channels.newInputStream().transferTo()`?
> * How to go on from here: What is missing to get this ready for an actual review?

Markus KARG has updated the pull request incrementally with two additional commits since the last revision:

 - Draft: Renamed r to bytesRead
 - Draft: Prevent infinite loop after truncation

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4263/files
  - new: https://git.openjdk.java.net/jdk/pull/4263/files/f91d5422..f3e37fe1

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4263&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4263&range=06-07

  Stats: 16 lines in 1 file changed: 2 ins; 2 del; 12 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4263.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4263/head:pull/4263

PR: https://git.openjdk.java.net/jdk/pull/4263

From github.com+1701815+mkarg at openjdk.java.net  Sat Jul 31 14:38:04 2021
From: github.com+1701815+mkarg at openjdk.java.net (Markus KARG)
Date: Sat, 31 Jul 2021 14:38:04 GMT
Subject: RFR: 8265891: (ch) InputStream returned by
 Channels.newInputStream should override transferTo [v9]
In-Reply-To: <XlU5gCBUEa4qTTz8yhMeElh95FuiPcFYQ_nj_WYvbLE=.6e9fc6a4-f3b1-4faf-91f0-d8b06f875780@github.com>
References: <XlU5gCBUEa4qTTz8yhMeElh95FuiPcFYQ_nj_WYvbLE=.6e9fc6a4-f3b1-4faf-91f0-d8b06f875780@github.com>
Message-ID: <acfH4DF_94kY0uCz_smLNKPfx44fEMYQg7aiZc-kvww=.c49913b2-01f2-458d-89f3-92e3c7c36b0e@github.com>

> This PR-*draft* is **work in progress** and an invitation to discuss a possible solution for issue [JDK-8265891](https://bugs.openjdk.java.net/browse/JDK-8265891). It is *not yet* intended for a final review.
> 
> As proposed in JDK-8265891, this PR provides an implementation for `Channels.newInputStream().transferTo()` which provide superior performance compared to the current implementation. The changes are:
> * Prevents transfers through the JVM heap as much as possibly by offloading to deeper levels via NIO, hence allowing the operating system to optimize the transfer.
> * Using more JRE heap in the fallback case when no NIO is possible (still only KiBs, hence mostl ynegligible even on SBCs) to better perform on modern hardware / fast I/O devides.
> 
> Using JMH I have benchmarked both, the original implementation and this implementation, and (depending on the used hardware and use case) performance change was approx. doubled performance. So this PoC proofs that it makes sense to finalize this work and turn it into an actual OpenJDK contribution. 
> 
> I encourage everybody to discuss this draft:
> * Are there valid arguments for *not* doing this change?
> * Is there a *better* way to improve performance of `Channels.newInputStream().transferTo()`?
> * How to go on from here: What is missing to get this ready for an actual review?

Markus KARG 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 two new commits since the last revision:

 - Draft: Renamed r to bytesRead
 - Draft: Prevent infinite loop after truncation

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4263/files
  - new: https://git.openjdk.java.net/jdk/pull/4263/files/f3e37fe1..e0724718

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4263&range=08
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4263&range=07-08

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4263.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4263/head:pull/4263

PR: https://git.openjdk.java.net/jdk/pull/4263

From github.com+1701815+mkarg at openjdk.java.net  Sat Jul 31 14:41:39 2021
From: github.com+1701815+mkarg at openjdk.java.net (Markus KARG)
Date: Sat, 31 Jul 2021 14:41:39 GMT
Subject: RFR: 8265891: (ch) InputStream returned by
 Channels.newInputStream should override transferTo [v6]
In-Reply-To: <v6VO-i9pTbZ-nFktsPex13dbxWkznsSCUtUbWiSltm8=.807072c3-d39a-47b0-ae2c-bf21a41c264b@github.com>
References: <XlU5gCBUEa4qTTz8yhMeElh95FuiPcFYQ_nj_WYvbLE=.6e9fc6a4-f3b1-4faf-91f0-d8b06f875780@github.com>
 <5PpEoJT1JZoo75hz4HAQFkipRfXCr_7MyTE8g4yhhgc=.5eeefcfe-205b-4b02-a59b-bead8b410139@github.com>
 <IZKluRfiLnIovyrAw3TdXDSzB6e59nHmG3ee7PEtjSE=.a778bb70-9938-4599-a3d9-9ad8fa235b00@github.com>
 <D-BolUEcvPGEA-JzbvXEUQTtaxUbl7duhesuVERIZc4=.4edfe8a0-8284-45cf-a2ad-993d795b14b6@github.com>
 <UQzAp1eaWHObRgVpa8bwHLdbdyauIE9NdpDd-MwsvUM=.cd00637c-80bf-43da-8ab3-97825a7d92d0@github.com>
 <AC0DI4y81YwidEwnIAAqKjbRCPrFWdBJVz1k2LmOvu8=.497fd5dc-91b2-4294-8049-a5766323539a@github.com>
 <RL6f0JWEcP22xlawlCxU3zhNrUhJ6iy_rgEr2ZXA688=.b4abee11-6c2c-4d60-8790-e6b05c45f10f@github.com>
 <v6VO-i9pTbZ-nFktsPex13dbxWkznsSCUtUbWiSltm8=.807072c3-d39a-47b0-ae2c-bf21a41c264b@github.com>
Message-ID: <kj9rYshksvPAyIdUjhlR5As1A1TYdfBfLMMDb8P7Yuo=.e32a782b-3cfb-4297-8b48-cac1d4d77de5@github.com>

On Sat, 31 Jul 2021 13:12:54 GMT, Markus KARG <github.com+1701815+mkarg at openjdk.org> wrote:

>> Is this loop correct for the case that the channel gets truncated? In that case transferTo will return 0 as no bytes will be transferred and I'm concerned this code will go into an infinite loop.
>> 
>> Also can you can check that IllegalBlockingModeException is thrown for the case ch is a SelectableChannel configured non-blocking and the destination is a FileChannel?
>> 
>> Just on naming, the existing channel implementations use "dst" for the destination and "wbc" (not "oc") for writable byte channels. Just mentioning it so that the new code can be kept consistent where possible.
>
>> Just on naming, the existing channel implementations use "dst" for the destination and "wbc" (not "oc") for writable byte channels. Just mentioning it so that the new code can be kept consistent where possible.
> 
> I have renamed `dest` to `dst` and `oc` to `wbc` in https://github.com/openjdk/jdk/pull/4263/commits/f91d5422c41e25410a81aad54a45b2d0e171305a.

> Is this loop correct for the case that the channel gets truncated? In that case transferTo will return 0 as no bytes will be transferred and I'm concerned this code will go into an infinite loop.

Good catch, indeed missed this particular situation!

The modified code found in https://github.com/openjdk/jdk/pull/4263/commits/4b501b205c6f1c48bbc82d7a154aed3fc41b1a20 should be safe from infinite loops, as it checks the actual file length in each iteration (even if this costs us one more `synchronized` per iteration).

This will also improve the situation with concurrent *extension* of the file as outlined in:

>If src is extended at an inconvenient point in time, for example between the return from a call to src.transferTo() that makes bytesWritten < n false and the evaluation of that terminating condition, then it appears that not all the content of src will be transferred to dest. I am not however sure that this violates any contract but it could be a behavioral change from the existing implementation.

As `size()` is called in each iteration, it will pick up the appendend bytes. Still the situation exists that some bytes are *replaced* in the source file -- but that is actually out-of-scope of this PR...! ;-)

-------------

PR: https://git.openjdk.java.net/jdk/pull/4263

From github.com+1701815+mkarg at openjdk.java.net  Sat Jul 31 16:02:05 2021
From: github.com+1701815+mkarg at openjdk.java.net (Markus KARG)
Date: Sat, 31 Jul 2021 16:02:05 GMT
Subject: RFR: 8265891: (ch) InputStream returned by
 Channels.newInputStream should override transferTo [v10]
In-Reply-To: <XlU5gCBUEa4qTTz8yhMeElh95FuiPcFYQ_nj_WYvbLE=.6e9fc6a4-f3b1-4faf-91f0-d8b06f875780@github.com>
References: <XlU5gCBUEa4qTTz8yhMeElh95FuiPcFYQ_nj_WYvbLE=.6e9fc6a4-f3b1-4faf-91f0-d8b06f875780@github.com>
Message-ID: <PhwB86a3itLg2DEMOyTnmiOukpDcloT5_enLmYH1MJY=.d1b0ea1a-9b6e-43ef-b348-05891b63bd4d@github.com>

> This PR-*draft* is **work in progress** and an invitation to discuss a possible solution for issue [JDK-8265891](https://bugs.openjdk.java.net/browse/JDK-8265891). It is *not yet* intended for a final review.
> 
> As proposed in JDK-8265891, this PR provides an implementation for `Channels.newInputStream().transferTo()` which provide superior performance compared to the current implementation. The changes are:
> * Prevents transfers through the JVM heap as much as possibly by offloading to deeper levels via NIO, hence allowing the operating system to optimize the transfer.
> * Using more JRE heap in the fallback case when no NIO is possible (still only KiBs, hence mostl ynegligible even on SBCs) to better perform on modern hardware / fast I/O devides.
> 
> Using JMH I have benchmarked both, the original implementation and this implementation, and (depending on the used hardware and use case) performance change was approx. doubled performance. So this PoC proofs that it makes sense to finalize this work and turn it into an actual OpenJDK contribution. 
> 
> I encourage everybody to discuss this draft:
> * Are there valid arguments for *not* doing this change?
> * Is there a *better* way to improve performance of `Channels.newInputStream().transferTo()`?
> * How to go on from here: What is missing to get this ready for an actual review?

Markus KARG has updated the pull request incrementally with one additional commit since the last revision:

  Draft: Throwing IllegalBlockingModeException if src is SelectableChannel and dst is FileChannel

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4263/files
  - new: https://git.openjdk.java.net/jdk/pull/4263/files/e0724718..8e2889fd

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4263&range=09
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4263&range=08-09

  Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4263.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4263/head:pull/4263

PR: https://git.openjdk.java.net/jdk/pull/4263

From github.com+1701815+mkarg at openjdk.java.net  Sat Jul 31 16:02:07 2021
From: github.com+1701815+mkarg at openjdk.java.net (Markus KARG)
Date: Sat, 31 Jul 2021 16:02:07 GMT
Subject: RFR: 8265891: (ch) InputStream returned by
 Channels.newInputStream should override transferTo [v6]
In-Reply-To: <kj9rYshksvPAyIdUjhlR5As1A1TYdfBfLMMDb8P7Yuo=.e32a782b-3cfb-4297-8b48-cac1d4d77de5@github.com>
References: <XlU5gCBUEa4qTTz8yhMeElh95FuiPcFYQ_nj_WYvbLE=.6e9fc6a4-f3b1-4faf-91f0-d8b06f875780@github.com>
 <5PpEoJT1JZoo75hz4HAQFkipRfXCr_7MyTE8g4yhhgc=.5eeefcfe-205b-4b02-a59b-bead8b410139@github.com>
 <IZKluRfiLnIovyrAw3TdXDSzB6e59nHmG3ee7PEtjSE=.a778bb70-9938-4599-a3d9-9ad8fa235b00@github.com>
 <D-BolUEcvPGEA-JzbvXEUQTtaxUbl7duhesuVERIZc4=.4edfe8a0-8284-45cf-a2ad-993d795b14b6@github.com>
 <UQzAp1eaWHObRgVpa8bwHLdbdyauIE9NdpDd-MwsvUM=.cd00637c-80bf-43da-8ab3-97825a7d92d0@github.com>
 <AC0DI4y81YwidEwnIAAqKjbRCPrFWdBJVz1k2LmOvu8=.497fd5dc-91b2-4294-8049-a5766323539a@github.com>
 <RL6f0JWEcP22xlawlCxU3zhNrUhJ6iy_rgEr2ZXA688=.b4abee11-6c2c-4d60-8790-e6b05c45f10f@github.com>
 <v6VO-i9pTbZ-nFktsPex13dbxWkznsSCUtUbWiSltm8=.807072c3-d39a-47b0-ae2c-bf21a41c264b@github.com>
 <kj9rYshksvPAyIdUjhlR5As1A1TYdfBfLMMDb8P7Yuo=.e32a782b-3cfb-4297-8b48-cac1d4d77de5@github.com>
Message-ID: <XNg_rSaiybQpqnEKbsnUDsjpjD_L8ZS8NcR3LM56jO0=.1d60c4f0-ac46-4fc1-8784-4d51bb12c6e6@github.com>

On Sat, 31 Jul 2021 14:39:02 GMT, Markus KARG <github.com+1701815+mkarg at openjdk.org> wrote:

>>> Just on naming, the existing channel implementations use "dst" for the destination and "wbc" (not "oc") for writable byte channels. Just mentioning it so that the new code can be kept consistent where possible.
>> 
>> I have renamed `dest` to `dst` and `oc` to `wbc` in https://github.com/openjdk/jdk/pull/4263/commits/f91d5422c41e25410a81aad54a45b2d0e171305a.
>
>> Is this loop correct for the case that the channel gets truncated? In that case transferTo will return 0 as no bytes will be transferred and I'm concerned this code will go into an infinite loop.
> 
> Good catch, indeed missed this particular situation!
> 
> The modified code found in https://github.com/openjdk/jdk/pull/4263/commits/4b501b205c6f1c48bbc82d7a154aed3fc41b1a20 should be safe from infinite loops, as it checks the actual file length in each iteration (even if this costs us one more `synchronized` per iteration).
> 
> This will also improve the situation with concurrent *extension* of the file as outlined in:
> 
>>If src is extended at an inconvenient point in time, for example between the return from a call to src.transferTo() that makes bytesWritten < n false and the evaluation of that terminating condition, then it appears that not all the content of src will be transferred to dest. I am not however sure that this violates any contract but it could be a behavioral change from the existing implementation.
> 
> As `size()` is called in each iteration, it will pick up the appendend bytes. Still the situation exists that some bytes are *replaced* in the source file -- but that is actually out-of-scope of this PR...! ;-)

> Also can you can check that IllegalBlockingModeException is thrown for the case ch is a SelectableChannel configured non-blocking and the destination is a FileChannel?

Done in https://github.com/openjdk/jdk/pull/4263/commits/8e2889fd6138d8aa8e308a1cd2aea3546a7c43a7, but honestly I'd kindly like to ask for a brief explanation why this has to be done. What actual bad effect would happen if I do not throw?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4263

From alanb at openjdk.java.net  Sat Jul 31 17:36:30 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sat, 31 Jul 2021 17:36:30 GMT
Subject: RFR: 8265891: (ch) InputStream returned by
 Channels.newInputStream should override transferTo [v6]
In-Reply-To: <XNg_rSaiybQpqnEKbsnUDsjpjD_L8ZS8NcR3LM56jO0=.1d60c4f0-ac46-4fc1-8784-4d51bb12c6e6@github.com>
References: <XlU5gCBUEa4qTTz8yhMeElh95FuiPcFYQ_nj_WYvbLE=.6e9fc6a4-f3b1-4faf-91f0-d8b06f875780@github.com>
 <5PpEoJT1JZoo75hz4HAQFkipRfXCr_7MyTE8g4yhhgc=.5eeefcfe-205b-4b02-a59b-bead8b410139@github.com>
 <IZKluRfiLnIovyrAw3TdXDSzB6e59nHmG3ee7PEtjSE=.a778bb70-9938-4599-a3d9-9ad8fa235b00@github.com>
 <D-BolUEcvPGEA-JzbvXEUQTtaxUbl7duhesuVERIZc4=.4edfe8a0-8284-45cf-a2ad-993d795b14b6@github.com>
 <UQzAp1eaWHObRgVpa8bwHLdbdyauIE9NdpDd-MwsvUM=.cd00637c-80bf-43da-8ab3-97825a7d92d0@github.com>
 <AC0DI4y81YwidEwnIAAqKjbRCPrFWdBJVz1k2LmOvu8=.497fd5dc-91b2-4294-8049-a5766323539a@github.com>
 <RL6f0JWEcP22xlawlCxU3zhNrUhJ6iy_rgEr2ZXA688=.b4abee11-6c2c-4d60-8790-e6b05c45f10f@github.com>
 <v6VO-i9pTbZ-nFktsPex13dbxWkznsSCUtUbWiSltm8=.807072c3-d39a-47b0-ae2c-bf21a41c264b@github.com>
 <kj9rYshksvPAyIdUjhlR5As1A1TYdfBfLMMDb8P7Yuo=.e32a782b-3cfb-4297-8b48-cac1d4d77de5@github.com>
 <XNg_rSaiybQpqnEKbsnUDsjpjD_L8ZS8NcR3LM56jO0=.1d60c4f0-ac46-4fc1-8784-4d51bb12c6e6@github.com>
Message-ID: <FwCL5TrB0b64s9UwjBUdE-cgWX8ImaLL-AagyFR62vY=.ef3b9775-7ca9-4e70-8cce-4adfc78a254a@github.com>

On Sat, 31 Jul 2021 15:58:07 GMT, Markus KARG <github.com+1701815+mkarg at openjdk.org> wrote:

>>> Is this loop correct for the case that the channel gets truncated? In that case transferTo will return 0 as no bytes will be transferred and I'm concerned this code will go into an infinite loop.
>> 
>> Good catch, indeed missed this particular situation!
>> 
>> The modified code found in https://github.com/openjdk/jdk/pull/4263/commits/4b501b205c6f1c48bbc82d7a154aed3fc41b1a20 should be safe from infinite loops, as it checks the actual file length in each iteration (even if this costs us one more `synchronized` per iteration).
>> 
>> This will also improve the situation with concurrent *extension* of the file as outlined in:
>> 
>>>If src is extended at an inconvenient point in time, for example between the return from a call to src.transferTo() that makes bytesWritten < n false and the evaluation of that terminating condition, then it appears that not all the content of src will be transferred to dest. I am not however sure that this violates any contract but it could be a behavioral change from the existing implementation.
>> 
>> As `size()` is called in each iteration, it will pick up the appendend bytes. Still the situation exists that some bytes are *replaced* in the source file -- but that is actually out-of-scope of this PR...! ;-)
>
>> Also can you can check that IllegalBlockingModeException is thrown for the case ch is a SelectableChannel configured non-blocking and the destination is a FileChannel?
> 
> Done in https://github.com/openjdk/jdk/pull/4263/commits/8e2889fd6138d8aa8e308a1cd2aea3546a7c43a7, but honestly I'd kindly like to ask for a brief explanation why this has to be done. What actual bad effect would happen if I do not throw?

> The modified code found in [4b501b2](https://github.com/openjdk/jdk/commit/4b501b205c6f1c48bbc82d7a154aed3fc41b1a20) should be safe from infinite loops, as it checks the actual file length in each iteration (even if this costs us one more `synchronized` per iteration).

I need to look at it closely but I suspect this introduces a potential overflow. Also if output stream is backed by a SocketChannel configured non-blocking then FC::transferTo may return 0 so I assume there is a potential infinite loop there too. I suspect the eventually patch will need have to make use of the blockingLock to prevent the underlying channels from being changed to non-blocking during the transfer.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4263

From iignatyev at openjdk.java.net  Sat Jul 31 20:42:10 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Sat, 31 Jul 2021 20:42:10 GMT
Subject: [jdk17] RFR: 8067223: [TESTBUG] Rename Whitebox API package [v2]
In-Reply-To: <39PNb3wa-43yB5IFR3XroqFf4vMNZPitzF85lO1Gw58=.f2587741-d2c4-467d-b722-b17269587e7a@github.com>
References: <39PNb3wa-43yB5IFR3XroqFf4vMNZPitzF85lO1Gw58=.f2587741-d2c4-467d-b722-b17269587e7a@github.com>
Message-ID: <aLR3YLrRbGBPBTqkWXIkfzse3vaVRtoVRBXVdDGHVZg=.f5f7811e-32b7-45ee-8fba-db1de599649c@github.com>

> Hi all,
> 
> could you please review this big tedious and trivial(-ish) patch which moves `sun.hotspot.WhiteBox` and related classes to `jdk.test.whitebox` package?
> 
> the majority of the patch is the following substitutions:
>  - `s~sun/hotspot/WhiteBox~jdk/test/whitebox/WhiteBox~g`
>  - `s/sun.hotspot.parser/jdk.test.whitebox.parser/g`
>  - `s/sun.hotspot.cpuinfo/jdk.test.whitebox.cpuinfo/g`
>  - `s/sun.hotspot.code/jdk.test.whitebox.code/g`
>  - `s/sun.hotspot.gc/jdk.test.whitebox.gc/g`
>  - `s/sun.hotspot.WhiteBox/jdk.test.whitebox.WhiteBox/g`
> 
> testing: tier1-4
> 
> Thanks,
> -- Igor

Igor Ignatyev has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains 12 new commits since the last revision:

 - fixed ctw build
 - updated runtime/cds/appcds/JarBuilder to copy j.t.w.WhiteBox's inner class
 - updated requires.VMProps
 - updated TEST.ROOT
 - adjusted hotspot source
 - added test
 - moved and adjusted WhiteBox tests (test/lib-test/sun/hotspot/whitebox)
 - updated ClassFileInstaller to copy j.t.w.WhiteBox's inner class
 - removed sun/hotspot/parser/DiagnosticCommand
 - deprecated sun/hotspot classes
   disallowed s.h.WhiteBox w/ security manager
 - ... and 2 more: https://git.openjdk.java.net/jdk17/compare/8f12f2cf...237e8860

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/290/files
  - new: https://git.openjdk.java.net/jdk17/pull/290/files/8f12f2cf..237e8860

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk17&pr=290&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk17&pr=290&range=00-01

  Stats: 3248 lines in 939 files changed: 969 ins; 0 del; 2279 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/290.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/290/head:pull/290

PR: https://git.openjdk.java.net/jdk17/pull/290

From iignatyev at openjdk.java.net  Sat Jul 31 20:51:46 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Sat, 31 Jul 2021 20:51:46 GMT
Subject: [jdk17] RFR: 8067223: [TESTBUG] Rename Whitebox API package [v2]
In-Reply-To: <aLR3YLrRbGBPBTqkWXIkfzse3vaVRtoVRBXVdDGHVZg=.f5f7811e-32b7-45ee-8fba-db1de599649c@github.com>
References: <39PNb3wa-43yB5IFR3XroqFf4vMNZPitzF85lO1Gw58=.f2587741-d2c4-467d-b722-b17269587e7a@github.com>
 <aLR3YLrRbGBPBTqkWXIkfzse3vaVRtoVRBXVdDGHVZg=.f5f7811e-32b7-45ee-8fba-db1de599649c@github.com>
Message-ID: <dy5pWN9zaFu2PCgZkfSir78NuuZxPS4JoVNIuPwVAwM=.8d3eb7ec-c4d0-4ac7-9165-f6f203215ca4@github.com>

On Sat, 31 Jul 2021 20:42:10 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

>> Hi all,
>> 
>> could you please review this big tedious and trivial(-ish) patch which moves `sun.hotspot.WhiteBox` and related classes to `jdk.test.whitebox` package?
>> 
>> the majority of the patch is the following substitutions:
>>  - `s~sun/hotspot/WhiteBox~jdk/test/whitebox/WhiteBox~g`
>>  - `s/sun.hotspot.parser/jdk.test.whitebox.parser/g`
>>  - `s/sun.hotspot.cpuinfo/jdk.test.whitebox.cpuinfo/g`
>>  - `s/sun.hotspot.code/jdk.test.whitebox.code/g`
>>  - `s/sun.hotspot.gc/jdk.test.whitebox.gc/g`
>>  - `s/sun.hotspot.WhiteBox/jdk.test.whitebox.WhiteBox/g`
>> 
>> testing: tier1-4
>> 
>> Thanks,
>> -- Igor
>
> Igor Ignatyev has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR.

Vladimir, David,

I've (forced) pushed a smaller version of the renaming. instead of removing `sun.hotspot` classes, it copies them to `jdk.test.whitebox` (w/ `s.h.parser.DiagnosticCommand` being removed as it's used in WhiteBox signature and it was easier to update a few tests that use it), updates hotspot code to register native methods for both `sun.hotspot.WhiteBox` and `jdk.test.whitebox.WhiteBox` classes. To make it easier and not to introduce extra dependency, I've made it impossible to use `s.h.WB` w/ a security manager enabled, otherwise there would be a dependency b/w `s.h.WB` and `j.t.w.WB$WhiteBoxPermission` or there would be 2 permissions. There are no open JDK tests that are impacted by this limitation.

With minor tweaks in closed source, the patch successfully passes Oracle's tier1-4.

-- Igor

-------------

PR: https://git.openjdk.java.net/jdk17/pull/290

From github.com+1701815+mkarg at openjdk.java.net  Sat Jul 31 21:23:32 2021
From: github.com+1701815+mkarg at openjdk.java.net (Markus KARG)
Date: Sat, 31 Jul 2021 21:23:32 GMT
Subject: RFR: 8265891: (ch) InputStream returned by
 Channels.newInputStream should override transferTo [v6]
In-Reply-To: <FwCL5TrB0b64s9UwjBUdE-cgWX8ImaLL-AagyFR62vY=.ef3b9775-7ca9-4e70-8cce-4adfc78a254a@github.com>
References: <XlU5gCBUEa4qTTz8yhMeElh95FuiPcFYQ_nj_WYvbLE=.6e9fc6a4-f3b1-4faf-91f0-d8b06f875780@github.com>
 <5PpEoJT1JZoo75hz4HAQFkipRfXCr_7MyTE8g4yhhgc=.5eeefcfe-205b-4b02-a59b-bead8b410139@github.com>
 <IZKluRfiLnIovyrAw3TdXDSzB6e59nHmG3ee7PEtjSE=.a778bb70-9938-4599-a3d9-9ad8fa235b00@github.com>
 <D-BolUEcvPGEA-JzbvXEUQTtaxUbl7duhesuVERIZc4=.4edfe8a0-8284-45cf-a2ad-993d795b14b6@github.com>
 <UQzAp1eaWHObRgVpa8bwHLdbdyauIE9NdpDd-MwsvUM=.cd00637c-80bf-43da-8ab3-97825a7d92d0@github.com>
 <AC0DI4y81YwidEwnIAAqKjbRCPrFWdBJVz1k2LmOvu8=.497fd5dc-91b2-4294-8049-a5766323539a@github.com>
 <RL6f0JWEcP22xlawlCxU3zhNrUhJ6iy_rgEr2ZXA688=.b4abee11-6c2c-4d60-8790-e6b05c45f10f@github.com>
 <v6VO-i9pTbZ-nFktsPex13dbxWkznsSCUtUbWiSltm8=.807072c3-d39a-47b0-ae2c-bf21a41c264b@github.com>
 <kj9rYshksvPAyIdUjhlR5As1A1TYdfBfLMMDb8P7Yuo=.e32a782b-3cfb-4297-8b48-cac1d4d77de5@github.com>
 <XNg_rSaiybQpqnEKbsnUDsjpjD_L8ZS8NcR3LM56jO0=.1d60c4f0-ac46-4fc1-8784-4d51bb12c6e6@github.com>
 <FwCL5TrB0b64s9UwjBUdE-cgWX8ImaLL-Aa
 gyFR62vY=.ef3b9775-7ca9-4e70-8cce-4adfc78a254a@github.com>
Message-ID: <oeFYG206jRvtO_n90mejVC57y6NZMMBpkYu8y_ovc9s=.4b30fc16-483e-418a-a088-88a14ba8f31c@github.com>

On Sat, 31 Jul 2021 17:33:50 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I need to look at it closely but I suspect this introduces a potential overflow. Also if output stream is backed by a SocketChannel configured non-blocking then FC::transferTo may return 0 so I assume there is a potential infinite loop there too. I suspect the eventually patch will need have to make use of the blockingLock to prevent the underlying channels from being changed to non-blocking during the transfer.

I need to confess that my NIO knowledge is not deep enough to follow you closely, so I trust on your advice how to go on from here.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4263