From smarks at openjdk.java.net  Thu Oct  1 00:21:16 2020
From: smarks at openjdk.java.net (Stuart Marks)
Date: Thu, 1 Oct 2020 00:21:16 GMT
Subject: RFR: 8156071: List.of: reduce array copying during creation
Message-ID: <-pkG69_yCpZxK0LBMz3Dw_m2VkTK6BhhWBY02UkidfQ=.c1f424e8-5716-4858-aaa0-488a9e553107@github.com>

Plumb new internal static factory method to trust the array passed in, avoiding unnecessary copying. JMH results for
the benchmark show about 15% improvement for the cases that were optimized, namely the 3 to 10 fixed arg cases.

# VM options: -verbose:gc -XX:+UseParallelGC -Xms4g -Xmx4g --enable-preview -verbose:gc -XX:+UsePara
llelGC -Xms4g -Xmx4g -Xint
# Warmup: 5 iterations, 1 s each
# Measurement: 5 iterations, 2 s each

WITHOUT varargs optimization:

Benchmark         Mode  Cnt     Score     Error   Units
ListArgs.list00  thrpt   15  6019.539 ? 144.040  ops/ms
ListArgs.list01  thrpt   15  1985.009 ?  40.606  ops/ms
ListArgs.list02  thrpt   15  1854.812 ?  17.488  ops/ms
ListArgs.list03  thrpt   15   963.866 ?  10.262  ops/ms
ListArgs.list04  thrpt   15   908.116 ?   6.278  ops/ms
ListArgs.list05  thrpt   15   848.607 ?  16.701  ops/ms
ListArgs.list06  thrpt   15   822.282 ?   8.905  ops/ms
ListArgs.list07  thrpt   15   780.057 ?  11.214  ops/ms
ListArgs.list08  thrpt   15   745.295 ?  19.204  ops/ms
ListArgs.list09  thrpt   15   704.596 ?  14.003  ops/ms
ListArgs.list10  thrpt   15   696.436 ?   4.914  ops/ms
ListArgs.list11  thrpt   15   661.908 ?  11.041  ops/ms

WITH varargs optimization:

Benchmark         Mode  Cnt     Score    Error   Units
ListArgs.list00  thrpt   15  6172.298 ? 62.736  ops/ms
ListArgs.list01  thrpt   15  1987.724 ? 45.468  ops/ms
ListArgs.list02  thrpt   15  1843.419 ? 10.693  ops/ms
ListArgs.list03  thrpt   15  1126.946 ? 30.952  ops/ms
ListArgs.list04  thrpt   15  1050.440 ? 17.859  ops/ms
ListArgs.list05  thrpt   15   999.275 ? 23.656  ops/ms
ListArgs.list06  thrpt   15   948.844 ? 19.615  ops/ms
ListArgs.list07  thrpt   15   897.541 ? 15.531  ops/ms
ListArgs.list08  thrpt   15   853.359 ? 18.755  ops/ms
ListArgs.list09  thrpt   15   826.394 ?  8.284  ops/ms
ListArgs.list10  thrpt   15   779.231 ?  4.104  ops/ms
ListArgs.list11  thrpt   15   650.888 ?  3.948  ops/ms

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

Commit messages:
 - 8156071: reduce varargs array creation and unnecessary copying during creation

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

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

From jiefu at openjdk.java.net  Thu Oct  1 00:28:24 2020
From: jiefu at openjdk.java.net (Jie Fu)
Date: Thu, 1 Oct 2020 00:28:24 GMT
Subject: RFR: 8223347: Integration of Vector API (Incubator)
In-Reply-To: <rLfx3nIDLTjn61XoBxS6EY-BREU1FdHBQ5CRtzzAkfU=.f0f96a40-a80f-4f83-aeea-5aa3f4a70974@github.com>
References: <-PE4TwXgvq2bemAn_8csjn4_j7zoAolnQz6QQt3z0Wk=.eaa9999f-0713-4349-b31d-934717aa37a1@github.com>
 <Wjf0eE62n-O_7VgiU_d-dDzs7IenyPwAc17CWpZg12M=.720b9f62-8815-410f-b761-4abe218367b4@github.com>
 <-JIanIoqecCK7WfRPElGiS9Gora2wP3NfpGZ3hNL_Hg=.2ccfa0e9-33c6-430b-9303-66829e97e6ff@github.com>
 <rLfx3nIDLTjn61XoBxS6EY-BREU1FdHBQ5CRtzzAkfU=.f0f96a40-a80f-4f83-aeea-5aa3f4a70974@github.com>
Message-ID: <jv80exoUyT056smJgSiBX6i4dz0EJwcNmMSR4VohFsI=.18bee132-b005-4897-bfb8-4524234698e5@github.com>

On Wed, 30 Sep 2020 18:19:53 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Hi @PaulSandoz ,
>> 
>> This integration seems to miss https://github.com/openjdk/panama-vector/pull/1, which had fixed crashes on AVX512
>> machines.
>> Thanks.
>
> @DamonFool we can follow up later for that fix (and others in `vectorIntrinsics`), after this PR integrates. I don't
> want to perturb the code that has already been reviewed, which requires yet more additional review.

Hi @PaulSandoz ,

I think it would be better to integrate it [1] in this MR.

I have tested this MR on our AVX512 machines and it still crashes.
Also, for the sake of maintenance, it seems NOT a good idea to push a problematic commit into the jdk main-line repo.

As for the review process, I don't think it's a problem since the fix [1] is clear and small enough.

What do you think?

Thanks.

[1] https://github.com/openjdk/panama-vector/commit/1af35c357066743935bd3f48ce3610a41761f89a

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

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

From alex.buckley at oracle.com  Thu Oct  1 00:38:42 2020
From: alex.buckley at oracle.com (Alex Buckley)
Date: Wed, 30 Sep 2020 17:38:42 -0700
Subject: RFR: 8253455: Record Classes javax.lang.model changes [v5]
In-Reply-To: <2b78ecff-a1a1-d465-1183-2e054bb4ba84@oracle.com>
References: <_EiRbvHonuflkmP-H77rZp9DQCpMs74zdWG3aO0_z0U=.c3b70b2f-75f2-4638-a4b4-a911e3f0851f@github.com>
 <v8zqzx525Kb84xZkqI51A-Do9oI1cZhdbNLaUQWR6iI=.6172c14b-c4af-4457-9f6b-a212590092df@github.com>
 <bzC3QILWo-EZ5kFs0O2h6HAPeuufnVP8vqUywAMJLrI=.73f203ff-288a-478e-94b3-56951a65ec60@github.com>
 <74fa9c6a-2345-6364-ac74-96ce508d3fae@oracle.com>
 <b635e3ab-8338-3841-d862-93040a7a6bca@oracle.com>
 <2b78ecff-a1a1-d465-1183-2e054bb4ba84@oracle.com>
Message-ID: <0b01b652-2a39-ca37-6bdd-fb247fb0f173@oracle.com>

On 9/30/2020 4:48 PM, Joe Darcy wrote:> Conversely, the fact that an API 
element is preview on one release and
> non-preview in a subsequent one does not necessarily imply the spec has 
> changed. (Although it might have changed, of course.)
> 
> Non-preview methods don't necessarily have *exactly* the same semantics 
> between releases either, subject to our general API evolution policies.

I recognize that a permanent API element may have its behavior changed 
in some situations, and we would leave @since alone in that context. For 
example, a method flagged with @since 8 might have been extended in 9 to 
handle modules, and we would not dream of saying @since 9.

However, a preview API element has an order of magnitude more freedom to 
change than a permanent API element. This means that the element 
previewing in 15 might have the same name and signature as the element 
which previewed in 14, but with novel behavior in some _or even all_ 
situations ... if that happens, then it would be misleading to suggest 
that the novel aspect of the element's spec has been present since 14 
just because the element itself has been present since 14. The element 
in 15 is not really the same element as in 14, and the element in 16 
might not be the same element as in 15. Updating @since to 16 when the 
element becomes permanent wipes the slate clean (the preview behavior no 
longer matters) and lets the element join the club of "non-preview and 
not-deprecated-for-removal API elements" which "can be assumed to be 
present in the next release."

Alex

From psandoz at openjdk.java.net  Thu Oct  1 01:04:44 2020
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Thu, 1 Oct 2020 01:04:44 GMT
Subject: RFR: 8223347: Integration of Vector API (Incubator)
In-Reply-To: <jv80exoUyT056smJgSiBX6i4dz0EJwcNmMSR4VohFsI=.18bee132-b005-4897-bfb8-4524234698e5@github.com>
References: <-PE4TwXgvq2bemAn_8csjn4_j7zoAolnQz6QQt3z0Wk=.eaa9999f-0713-4349-b31d-934717aa37a1@github.com>
 <Wjf0eE62n-O_7VgiU_d-dDzs7IenyPwAc17CWpZg12M=.720b9f62-8815-410f-b761-4abe218367b4@github.com>
 <-JIanIoqecCK7WfRPElGiS9Gora2wP3NfpGZ3hNL_Hg=.2ccfa0e9-33c6-430b-9303-66829e97e6ff@github.com>
 <rLfx3nIDLTjn61XoBxS6EY-BREU1FdHBQ5CRtzzAkfU=.f0f96a40-a80f-4f83-aeea-5aa3f4a70974@github.com>
 <jv80exoUyT056smJgSiBX6i4dz0EJwcNmMSR4VohFsI=.18bee132-b005-4897-bfb8-4524234698e5@github.com>
Message-ID: <QISydl09AaT2tr_75ysKQV68AWJMLydsOJRl3H6_Ih0=.3235cfd9-01a0-49bb-8ad2-692e54a10b78@github.com>

On Thu, 1 Oct 2020 00:25:46 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> @DamonFool we can follow up later for that fix (and others in `vectorIntrinsics`), after this PR integrates. I don't
>> want to perturb the code that has already been reviewed, which requires yet more additional review.
>
> Hi @PaulSandoz ,
> 
> I think it would be better to integrate it [1] in this MR.
> 
> I have tested this MR on our AVX512 machines and it still crashes.
> Also, for the sake of maintenance, it seems NOT a good idea to push a problematic commit into the jdk main-line repo.
> 
> As for the review process, I don't think it's a problem since the fix [1] is clear and small enough.
> 
> What do you think?
> 
> Thanks.
> 
> [1] https://github.com/openjdk/panama-vector/commit/1af35c357066743935bd3f48ce3610a41761f89a

@DamonFool I appreciate your efforts on this but i want to hold back on that issue and follow up very quickly after
integration of this PR. This change has been through an extremely long and arduous review process, and i want to stick
to what was reviewed and not ask reviewers to go through further cycles on what overall is a very large change.
Unfortunately this change is in a holding pattern waiting for the CSR to be approved thereby increasing the window
where we might find further issues (that if we had already integrated may have been dealt with separately perhaps in a
less timely fashion with respect to that integration). Unless an issue is extremely severe I think we should queue them
up in `panama-vector/vectorIntrinsics` (there is at least one more for ARM SVE that is queued up). Since the issue you
describe effects one instruction, for one type, on AVX512, its impact is limited and will be mitigated by a quick
follow up.

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

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

From jiefu at openjdk.java.net  Thu Oct  1 01:27:19 2020
From: jiefu at openjdk.java.net (Jie Fu)
Date: Thu, 1 Oct 2020 01:27:19 GMT
Subject: RFR: 8223347: Integration of Vector API (Incubator)
In-Reply-To: <QISydl09AaT2tr_75ysKQV68AWJMLydsOJRl3H6_Ih0=.3235cfd9-01a0-49bb-8ad2-692e54a10b78@github.com>
References: <-PE4TwXgvq2bemAn_8csjn4_j7zoAolnQz6QQt3z0Wk=.eaa9999f-0713-4349-b31d-934717aa37a1@github.com>
 <Wjf0eE62n-O_7VgiU_d-dDzs7IenyPwAc17CWpZg12M=.720b9f62-8815-410f-b761-4abe218367b4@github.com>
 <-JIanIoqecCK7WfRPElGiS9Gora2wP3NfpGZ3hNL_Hg=.2ccfa0e9-33c6-430b-9303-66829e97e6ff@github.com>
 <rLfx3nIDLTjn61XoBxS6EY-BREU1FdHBQ5CRtzzAkfU=.f0f96a40-a80f-4f83-aeea-5aa3f4a70974@github.com>
 <jv80exoUyT056smJgSiBX6i4dz0EJwcNmMSR4VohFsI=.18bee132-b005-4897-bfb8-4524234698e5@github.com>
 <QISydl09AaT2tr_75ysKQV68AWJMLydsOJRl3H6_Ih0=.3235cfd9-01a0-49bb-8ad2-692e54a10b78@github.com>
Message-ID: <M_fNC3Rb6xKhjMR0jsqXZsshGQc2b9pzYar08lKyO0E=.c1935fab-20ff-4d7e-b3a9-4b83c0b37504@github.com>

On Thu, 1 Oct 2020 01:01:23 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Hi @PaulSandoz ,
>> 
>> I think it would be better to integrate it [1] in this MR.
>> 
>> I have tested this MR on our AVX512 machines and it still crashes.
>> Also, for the sake of maintenance, it seems NOT a good idea to push a problematic commit into the jdk main-line repo.
>> 
>> As for the review process, I don't think it's a problem since the fix [1] is clear and small enough.
>> 
>> What do you think?
>> 
>> Thanks.
>> 
>> [1] https://github.com/openjdk/panama-vector/commit/1af35c357066743935bd3f48ce3610a41761f89a
>
> @DamonFool I appreciate your efforts on this but i want to hold back on that issue and follow up very quickly after
> integration of this PR. This change has been through an extremely long and arduous review process, and i want to stick
> to what was reviewed and not ask reviewers to go through further cycles on what overall is a very large change.
> Unfortunately this change is in a holding pattern waiting for the CSR to be approved thereby increasing the window
> where we might find further issues (that if we had already integrated may have been dealt with separately perhaps in a
> less timely fashion with respect to that integration). Unless an issue is extremely severe I think we should queue them
> up in `panama-vector/vectorIntrinsics` (there is at least one more for ARM SVE that is queued up). Since the issue you
> describe effects one instruction, for one type, on AVX512, its impact is limited and will be mitigated by a quick
> follow up.

Okay.
I can understand it.

Vector API is very valuable to us.
Hope the follow-ups can be integrated as soon as possible.
And thank you all for your great work.

Best regards,
Jie

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

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

From vromero at openjdk.java.net  Thu Oct  1 01:31:04 2020
From: vromero at openjdk.java.net (Vicente Romero)
Date: Thu, 1 Oct 2020 01:31:04 GMT
Subject: RFR: 8246774: implementing Record Classes as a standard feature
 in Java [v9]
In-Reply-To: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com>
References: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com>
Message-ID: <0aKjS2ruCGPqJsSjll3RsknZpCuGsAkrQaANwVqPTMs=.b9628de2-6f3e-41d0-9c59-6b85dd6d71f5@github.com>

> Co-authored-by: Vicente Romero <vicente.romero at oracle.com>
> Co-authored-by: Harold Seigel <harold.seigel at oracle.com>
> Co-authored-by: Jonathan Gibbons <jonathan.gibbons at oracle.com>
> Co-authored-by: Brian Goetz <brian.goetz at oracle.com>
> Co-authored-by: Maurizio Cimadamore <maurizio.cimadamore at oracle.com>
> Co-authored-by: Joe Darcy <joe.darcy at oracle.com>
> Co-authored-by: Chris Hegarty <chris.hegarty at oracle.com>
> Co-authored-by: Jan Lahoda <jan.lahoda at oracle.com>

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

  remove unnecessary jtreg tags from tests, remove othervm etc when applicable

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/290/files
  - new: https://git.openjdk.java.net/jdk/pull/290/files/76e3d278..7501148d

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

  Stats: 102 lines in 54 files changed: 33 ins; 19 del; 50 mod
  Patch: https://git.openjdk.java.net/jdk/pull/290.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/290/head:pull/290

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

From vromero at openjdk.java.net  Thu Oct  1 01:33:58 2020
From: vromero at openjdk.java.net (Vicente Romero)
Date: Thu, 1 Oct 2020 01:33:58 GMT
Subject: RFR: 8246774: implementing Record Classes as a standard feature
 in Java [v3]
In-Reply-To: <k8_cOlCKyAroIecYRo2xd2XmdFkNHb8Y6uHfitphERk=.8eb0cfb8-8afc-41f4-a7d9-5efb987255dd@github.com>
References: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com>
 <GlZ4WYI2PfUv1RGPznKvPe4D-U38cy7F7GHHILPvqxk=.499a774b-f7a6-4991-874f-f059024d81c5@github.com>
 <q_s7ziInBK8kbTajJl6Y6nopmER0XqCsQAQXEMQXylw=.b91d6669-3998-4daf-99b0-3535141b0584@github.com>
 <k8_cOlCKyAroIecYRo2xd2XmdFkNHb8Y6uHfitphERk=.8eb0cfb8-8afc-41f4-a7d9-5efb987255dd@github.com>
Message-ID: <cyPxglprUl2qDz5rHUEwKYFaz48pXxV8bvO-BxaxoFk=.361c9d9b-07a5-480a-8a66-66c85bc844c4@github.com>

On Wed, 30 Sep 2020 08:54:14 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

>> test/langtools/tools/javac/records/LocalStaticDeclarations.java line 33:
>> 
>>> 31:  *          jdk.compiler/com.sun.tools.javac.util
>>> 32:  * @build combo.ComboTestHelper
>>> 33:  * @compile LocalStaticDeclarations.java
>> 
>> This, and other, explicit at compile tags could be elided, no? The test source file will be implicitly compiled by the
>> at run tag. I believe that the explicit at compile tag was added original so that the enable preview and source version
>> options could be passed to javac - neither of which are needed any more.
>
> Does this test need an @run tag rather than an @compile tag ?  ( the @run with implicitly compile the source file,
> before running it )

@ChrisHegarty I have created commit
[7501148](https://github.com/openjdk/jdk/pull/290/commits/7501148dd4c21847699a84d6dc5ef100d993b78d) to address this
issue, thanks

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

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

From enikitin at openjdk.java.net  Thu Oct  1 04:57:39 2020
From: enikitin at openjdk.java.net (Evgeny Nikitin)
Date: Thu, 1 Oct 2020 04:57:39 GMT
Subject: RFR: 8229186: Improve error messages for TestStringIntrinsics
 failures [v6]
In-Reply-To: <Br6z5yt0kTbZwIQyTI9lz7czaYpjw5vCd5ZCbbrSIcM=.6a8096f1-91ed-4673-bab3-3bfae758ab95@github.com>
References: <Br6z5yt0kTbZwIQyTI9lz7czaYpjw5vCd5ZCbbrSIcM=.6a8096f1-91ed-4673-bab3-3bfae758ab95@github.com>
Message-ID: <b3GkK3NPrSYq9sWmkUDW9mZN6kMRoGVLFNBxCMIEsPs=.6119e887-b2e1-4c94-aa52-8200faec288a@github.com>

> pre-Skara RFR thread: [link](https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-May/038416.html)
> 
> Error reporting was improved by writing a C-style escaped string representations for the variables passed to the
> methods being tested. For array comparisons, a dedicated diff-formatter was implemented.
> Sample output for comparing byte arrays (with artificial failure):
>  ----------System.err:(21/1553)----------
>  Result: (false) of 'arrayEqualsB' is not equal to expected (true)
>  Arrays differ starting from [index: 7]:
>  ... 5, 6,   7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, ...
>  ... 5, 6, 125, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, ...
>            ^^^^
>  java.lang.RuntimeException: Result: (false) of 'arrayEqualsB' is not
>  equal to expected (true)
>           at
>  compiler.intrinsics.string.TestStringIntrinsics.invokeAndCheckArrays(TestStringIntrinsics.java:273)
>            at ... stack trace continues - E.N.
>  Sample output for comparing char arrays:
>  ----------System.err:(21/1579)*----------
>  Result: (false) of 'arrayEqualsC' is not equal to expected (true)
>  Arrays differ starting from [index: 7]:
>  ... \\u0005, \\u0006, \\u0007, \\u0008, \\u0009, \\n, ...
>  ... \\u0005, \\u0006,      }, \\u0008, \\u0009, \\n, ...
>                      ^^^^^^^
>  java.lang.RuntimeException: Result: (false) of 'arrayEqualsC' is not
>  equal to expected (true)
>           at
>  compiler.intrinsics.string.TestStringIntrinsics.invokeAndCheckArrays(TestStringIntrinsics.java:280)
>            at
>  ... and so on - E.N.
> 
> testing: open/test/hotspot/jtreg/compiler/intrinsics/string/TestStringIntrinsics.java on linux, windows, macosx.

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

  Use SB to build TestStringIntrinsics message, avoid type guessing in ArrayDiff

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/112/files
  - new: https://git.openjdk.java.net/jdk/pull/112/files/e6fb6d04..f0b1df89

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

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

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

From enikitin at openjdk.java.net  Thu Oct  1 04:57:39 2020
From: enikitin at openjdk.java.net (Evgeny Nikitin)
Date: Thu, 1 Oct 2020 04:57:39 GMT
Subject: RFR: 8229186: Improve error messages for TestStringIntrinsics
 failures [v6]
In-Reply-To: <6vRhHgd3e0gnEqpA5d_R7PMM_QK2OQicLzjRM5tQ69k=.c7d9e131-533f-4418-a101-1890ecc9c4c9@github.com>
References: <Br6z5yt0kTbZwIQyTI9lz7czaYpjw5vCd5ZCbbrSIcM=.6a8096f1-91ed-4673-bab3-3bfae758ab95@github.com>
 <uzmhG9x3aJF-EyQYadD6p0pjomV06woiap87zbVjXfM=.19f41894-e928-4045-afbb-aa067423bf1b@github.com>
 <e4bmQ7bHHXdsL62jNPUOIvPgiaa-oWfCEAA2RCYchE0=.b5900a29-010f-408a-b8b5-06d2ddc1d712@github.com>
 <P-NaJJIL-KW9jx7H1lwArCwkYYP2R_cgZxihKTIgfqk=.cf66a55d-44ed-4a11-be85-0060639f13aa@github.com>
 <o8UBLHUt_fUVItaOOt6FAQ-a8oY4GV-g8vK1J7hYTzs=.81884762-adda-4027-8783-953384ddc426@github.com>
 <6vRhHgd3e0gnEqpA5d_R7PMM_QK2OQicLzjRM5tQ69k=.c7d9e131-533f-4418-a101-1890ecc9c4c9@github.com>
Message-ID: <zUSDZ8EGnta8bWKs0aG9g_N9r7-x4SFDKj3KxRpccH4=.ffeb8d06-e2a4-48ef-9b03-23578e682d29@github.com>

On Wed, 30 Sep 2020 21:19:03 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> I'd use `StringBuilder` to construct the message.

Fixed, please check the f0b1df8.

> wouldn't the following patch do?

Wow, that worked. That type erasure... pushed in the same commit f0b1df8.

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

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

From iignatyev at openjdk.java.net  Thu Oct  1 06:21:11 2020
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Thu, 1 Oct 2020 06:21:11 GMT
Subject: RFR: 8229186: Improve error messages for TestStringIntrinsics
 failures [v6]
In-Reply-To: <b3GkK3NPrSYq9sWmkUDW9mZN6kMRoGVLFNBxCMIEsPs=.6119e887-b2e1-4c94-aa52-8200faec288a@github.com>
References: <Br6z5yt0kTbZwIQyTI9lz7czaYpjw5vCd5ZCbbrSIcM=.6a8096f1-91ed-4673-bab3-3bfae758ab95@github.com>
 <b3GkK3NPrSYq9sWmkUDW9mZN6kMRoGVLFNBxCMIEsPs=.6119e887-b2e1-4c94-aa52-8200faec288a@github.com>
Message-ID: <9thYXJXttNl2VIj3C5eGuFwEIwgZZ-TeGbeX67LqQl0=.987baa49-c4c4-466a-b115-ca261bec62b7@github.com>

On Thu, 1 Oct 2020 04:57:39 GMT, Evgeny Nikitin <enikitin at openjdk.org> wrote:

>> pre-Skara RFR thread: [link](https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-May/038416.html)
>> 
>> Error reporting was improved by writing a C-style escaped string representations for the variables passed to the
>> methods being tested. For array comparisons, a dedicated diff-formatter was implemented.
>> Sample output for comparing byte arrays (with artificial failure):
>>  ----------System.err:(21/1553)----------
>>  Result: (false) of 'arrayEqualsB' is not equal to expected (true)
>>  Arrays differ starting from [index: 7]:
>>  ... 5, 6,   7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, ...
>>  ... 5, 6, 125, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, ...
>>            ^^^^
>>  java.lang.RuntimeException: Result: (false) of 'arrayEqualsB' is not
>>  equal to expected (true)
>>           at
>>  compiler.intrinsics.string.TestStringIntrinsics.invokeAndCheckArrays(TestStringIntrinsics.java:273)
>>            at ... stack trace continues - E.N.
>>  Sample output for comparing char arrays:
>>  ----------System.err:(21/1579)*----------
>>  Result: (false) of 'arrayEqualsC' is not equal to expected (true)
>>  Arrays differ starting from [index: 7]:
>>  ... \\u0005, \\u0006, \\u0007, \\u0008, \\u0009, \\n, ...
>>  ... \\u0005, \\u0006,      }, \\u0008, \\u0009, \\n, ...
>>                      ^^^^^^^
>>  java.lang.RuntimeException: Result: (false) of 'arrayEqualsC' is not
>>  equal to expected (true)
>>           at
>>  compiler.intrinsics.string.TestStringIntrinsics.invokeAndCheckArrays(TestStringIntrinsics.java:280)
>>            at
>>  ... and so on - E.N.
>> 
>> testing: open/test/hotspot/jtreg/compiler/intrinsics/string/TestStringIntrinsics.java on linux, windows, macosx.
>
> Evgeny Nikitin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use SB to build TestStringIntrinsics message, avoid type guessing in ArrayDiff

LGTM

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

Marked as reviewed by iignatyev (Reviewer).

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

From github.com+232002+martin-g at openjdk.java.net  Thu Oct  1 06:29:58 2020
From: github.com+232002+martin-g at openjdk.java.net (Martin Grigorov)
Date: Thu, 1 Oct 2020 06:29:58 GMT
Subject: RFR: 8156071: List.of: reduce array copying during creation
In-Reply-To: <-pkG69_yCpZxK0LBMz3Dw_m2VkTK6BhhWBY02UkidfQ=.c1f424e8-5716-4858-aaa0-488a9e553107@github.com>
References: <-pkG69_yCpZxK0LBMz3Dw_m2VkTK6BhhWBY02UkidfQ=.c1f424e8-5716-4858-aaa0-488a9e553107@github.com>
Message-ID: <qK-TMrKwrRyrefv541CsxYvjrKQjVG7fjF_btOrjf6w=.008781c9-a2ea-4b0b-8249-932a71a12dca@github.com>

On Thu, 1 Oct 2020 00:13:28 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> Plumb new internal static factory method to trust the array passed in, avoiding unnecessary copying. JMH results for
> the benchmark show about 15% improvement for the cases that were optimized, namely the 3 to 10 fixed arg cases.
> # VM options: -verbose:gc -XX:+UseParallelGC -Xms4g -Xmx4g --enable-preview -verbose:gc -XX:+UsePara
> llelGC -Xms4g -Xmx4g -Xint
> # Warmup: 5 iterations, 1 s each
> # Measurement: 5 iterations, 2 s each
> 
> WITHOUT varargs optimization:
> 
> Benchmark         Mode  Cnt     Score     Error   Units
> ListArgs.list00  thrpt   15  6019.539 ? 144.040  ops/ms
> ListArgs.list01  thrpt   15  1985.009 ?  40.606  ops/ms
> ListArgs.list02  thrpt   15  1854.812 ?  17.488  ops/ms
> ListArgs.list03  thrpt   15   963.866 ?  10.262  ops/ms
> ListArgs.list04  thrpt   15   908.116 ?   6.278  ops/ms
> ListArgs.list05  thrpt   15   848.607 ?  16.701  ops/ms
> ListArgs.list06  thrpt   15   822.282 ?   8.905  ops/ms
> ListArgs.list07  thrpt   15   780.057 ?  11.214  ops/ms
> ListArgs.list08  thrpt   15   745.295 ?  19.204  ops/ms
> ListArgs.list09  thrpt   15   704.596 ?  14.003  ops/ms
> ListArgs.list10  thrpt   15   696.436 ?   4.914  ops/ms
> ListArgs.list11  thrpt   15   661.908 ?  11.041  ops/ms
> 
> WITH varargs optimization:
> 
> Benchmark         Mode  Cnt     Score    Error   Units
> ListArgs.list00  thrpt   15  6172.298 ? 62.736  ops/ms
> ListArgs.list01  thrpt   15  1987.724 ? 45.468  ops/ms
> ListArgs.list02  thrpt   15  1843.419 ? 10.693  ops/ms
> ListArgs.list03  thrpt   15  1126.946 ? 30.952  ops/ms
> ListArgs.list04  thrpt   15  1050.440 ? 17.859  ops/ms
> ListArgs.list05  thrpt   15   999.275 ? 23.656  ops/ms
> ListArgs.list06  thrpt   15   948.844 ? 19.615  ops/ms
> ListArgs.list07  thrpt   15   897.541 ? 15.531  ops/ms
> ListArgs.list08  thrpt   15   853.359 ? 18.755  ops/ms
> ListArgs.list09  thrpt   15   826.394 ?  8.284  ops/ms
> ListArgs.list10  thrpt   15   779.231 ?  4.104  ops/ms
> ListArgs.list11  thrpt   15   650.888 ?  3.948  ops/ms

src/java.base/share/classes/jdk/internal/access/SharedSecrets.java line 88:

> 86:         if (javaUtilCollectionAccess == null) {
> 87:             try {
> 88:                 Class.forName("java.util.ImmutableCollections$Access", true, null);

How does this work ? It attempts to load this class but `javaUtilCollectionAccess` is never assigned to a new value.

**Update**: I just noticed this is the getter.

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

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

From alanb at openjdk.java.net  Thu Oct  1 06:55:36 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 1 Oct 2020 06:55:36 GMT
Subject: RFR: 8204256: improve jlink error message to report unsupported
 class file format
In-Reply-To: <PESIYTROv6I4IrTC3aNS8De3N0NR4jrKjLAT4KG9VBc=.c93211af-82c7-4ec1-9846-16e8e284c559@github.com>
References: <fc0WYkvegw3_1RBfXVVy7Vs6HcX7b9UIq7fZ2kK4cCY=.218de7d9-7abf-4eec-af30-d2926464349c@github.com>
 <4G3_8Xep8bMY6mC17exBywM_HTJNLQI_JJkURTzg8QU=.6b26d80c-3e4d-46a5-abfe-1ff58af8b51f@github.com>
 <A0Vm50jN4M86KA8WbWzf2gSdfynWNi9lLdOcOfPKpdc=.1d56ffb6-0107-4ec0-bcab-3af2e411e826@github.com>
 <YQUXcPWFnSSR808GyNnSW_o8iL5aWRRGIqG5G80TYYY=.d558f1d1-a5b3-4489-949c-f9dfbedc4590@github.com>
 <PESIYTROv6I4IrTC3aNS8De3N0NR4jrKjLAT4KG9VBc=.c93211af-82c7-4ec1-9846-16e8e284c559@github.com>
Message-ID: <OlqxCK35p3vCmVcbI1otDWQOgUIdAoVVLUTqQP13hXg=.0913de5f-c0ee-4764-a5df-3d89c096eb45@github.com>

On Wed, 30 Sep 2020 22:21:59 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> @mlchung's second suggestion would be the easiest route to take. I wanted to avoid fishing into exception messages or
>> anything along those lines. The initial work to this fix was to explore how tricky attaining that kind of parity is.
>> Alternatively we could change the existing exception message path and modify it so it's in line with the simpler
>> solution as well? That makes sense to me, anyway.
>
>> Alternatively we could change the existing exception message path and modify it so it's in line with the simpler
>> solution as well? That makes sense to me, anyway.
> 
> Sounds reasonable to me.

Add a cause may work but it should probably be predicted on isLinkPhase as otherwise it will leak through to usages of
the ModuleFinder API.

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

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

From shade at openjdk.java.net  Thu Oct  1 09:13:26 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 1 Oct 2020 09:13:26 GMT
Subject: RFR: 8253727: [cgroups v2] Memory and swap limits reported
 incorrectly [v5]
In-Reply-To: <lszPLGLBbbjEh9uLM-18VLB7YTpJGtSEBULx87gwvgc=.461b4d7a-b845-4f2a-81c4-9955dc04a021@github.com>
References: <eEf5RovqXA-uPv8v7b05ngbVcpk7FTSI8bhq8-okwxQ=.bdb019c0-ad2c-43c0-9e99-b8e36b6d517f@github.com>
 <lszPLGLBbbjEh9uLM-18VLB7YTpJGtSEBULx87gwvgc=.461b4d7a-b845-4f2a-81c4-9955dc04a021@github.com>
Message-ID: <XU7in8HfIlS7fbWPcXQuGUxeNo_e8JsHw8j8Hpq1-jE=.0aa16953-1201-43b3-b33e-6b39ff601c50@github.com>

On Wed, 30 Sep 2020 09:37:41 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Account for interface files for swap and memory being reported independently.
>> The cgroup v1-like value is now reported by adding the memory.max value to
>> the memory.swap.max value.
>> 
>> Testing: Container tests on Linux x86_64 on cgroups v2 with crun 0.15
>
> Severin Gehwolf 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 shade (Reviewer).

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

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

From sgehwolf at openjdk.java.net  Thu Oct  1 09:28:35 2020
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Thu, 1 Oct 2020 09:28:35 GMT
Subject: RFR: 8253727: [cgroups v2] Memory and swap limits reported
 incorrectly [v5]
In-Reply-To: <XU7in8HfIlS7fbWPcXQuGUxeNo_e8JsHw8j8Hpq1-jE=.0aa16953-1201-43b3-b33e-6b39ff601c50@github.com>
References: <eEf5RovqXA-uPv8v7b05ngbVcpk7FTSI8bhq8-okwxQ=.bdb019c0-ad2c-43c0-9e99-b8e36b6d517f@github.com>
 <lszPLGLBbbjEh9uLM-18VLB7YTpJGtSEBULx87gwvgc=.461b4d7a-b845-4f2a-81c4-9955dc04a021@github.com>
 <XU7in8HfIlS7fbWPcXQuGUxeNo_e8JsHw8j8Hpq1-jE=.0aa16953-1201-43b3-b33e-6b39ff601c50@github.com>
Message-ID: <1Mxt3m-eu_X4vjWZ2Q4lZtaFhQDd7_J5oOaHsC6bZlM=.9c61625f-e263-4b6f-b95b-4a9775c20cee@github.com>

On Thu, 1 Oct 2020 09:11:05 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Severin Gehwolf 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:
>>   8253727: [cgroups v2] Memory and swap limits reported incorrectly
>
> Marked as reviewed by shade (Reviewer).

Thanks for the review, @shipilev!

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

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

From sgehwolf at openjdk.java.net  Thu Oct  1 09:32:00 2020
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Thu, 1 Oct 2020 09:32:00 GMT
Subject: Integrated: 8253727: [cgroups v2] Memory and swap limits reported
 incorrectly
In-Reply-To: <eEf5RovqXA-uPv8v7b05ngbVcpk7FTSI8bhq8-okwxQ=.bdb019c0-ad2c-43c0-9e99-b8e36b6d517f@github.com>
References: <eEf5RovqXA-uPv8v7b05ngbVcpk7FTSI8bhq8-okwxQ=.bdb019c0-ad2c-43c0-9e99-b8e36b6d517f@github.com>
Message-ID: <KF5exK5-7s3exL5lccxZgURBCFnm6aYjrPQOMac98K8=.5407ef4c-6005-4acc-86b6-7f2ab91c4afc@github.com>

On Mon, 28 Sep 2020 17:22:21 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Account for interface files for swap and memory being reported independently.
> The cgroup v1-like value is now reported by adding the memory.max value to
> the memory.swap.max value.
> 
> Testing: Container tests on Linux x86_64 on cgroups v2 with crun 0.15

This pull request has now been integrated.

Changeset: 3e96721c
Author:    Severin Gehwolf <sgehwolf at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/3e96721c
Stats:     47 lines in 3 files changed: 42 ins; 0 del; 5 mod

8253727: [cgroups v2] Memory and swap limits reported incorrectly

Account for interface files for swap and memory being reported independently.
The cgroup v1-like value is now reported by adding the memory.max value to
the memory.swap.max value, and memory.current and memory.swap.current
respectively.

Reviewed-by: bobv, shade

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

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

From chegar at openjdk.java.net  Thu Oct  1 09:32:03 2020
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Thu, 1 Oct 2020 09:32:03 GMT
Subject: RFR: 8246774: implementing Record Classes as a standard feature
 in Java [v9]
In-Reply-To: <0aKjS2ruCGPqJsSjll3RsknZpCuGsAkrQaANwVqPTMs=.b9628de2-6f3e-41d0-9c59-6b85dd6d71f5@github.com>
References: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com>
 <0aKjS2ruCGPqJsSjll3RsknZpCuGsAkrQaANwVqPTMs=.b9628de2-6f3e-41d0-9c59-6b85dd6d71f5@github.com>
Message-ID: <CzfhUtqIVJn-RZMR5ZHTYU4qGyGrq15l6W08bJz1ZIA=.9f3e5ff7-f89c-411f-a50e-7cf39d3898e9@github.com>

On Thu, 1 Oct 2020 01:31:04 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Co-authored-by: Vicente Romero <vicente.romero at oracle.com>
>> Co-authored-by: Harold Seigel <harold.seigel at oracle.com>
>> Co-authored-by: Jonathan Gibbons <jonathan.gibbons at oracle.com>
>> Co-authored-by: Brian Goetz <brian.goetz at oracle.com>
>> Co-authored-by: Maurizio Cimadamore <maurizio.cimadamore at oracle.com>
>> Co-authored-by: Joe Darcy <joe.darcy at oracle.com>
>> Co-authored-by: Chris Hegarty <chris.hegarty at oracle.com>
>> Co-authored-by: Jan Lahoda <jan.lahoda at oracle.com>
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove unnecessary jtreg tags from tests, remove othervm etc when applicable

Marked as reviewed by chegar (Reviewer).

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

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

From sverre.moe at gmail.com  Thu Oct  1 11:08:19 2020
From: sverre.moe at gmail.com (Sverre Moe)
Date: Thu, 1 Oct 2020 13:08:19 +0200
Subject: jpackage rpm bug
In-Reply-To: <CALAJ+5AvpTPPANzmJ1kEbW38SZMcOHaP4Em2tXC0YODqnywioQ@mail.gmail.com>
References: <CALAJ+5AvpTPPANzmJ1kEbW38SZMcOHaP4Em2tXC0YODqnywioQ@mail.gmail.com>
Message-ID: <CALAJ+5B+uc-fZYJfcetmU_wNW4_2VhXibqHMEr-DWAVUTAJCcg@mail.gmail.com>

I have just checked that it also happens with JDK 15.

I will file a bug report on this. I could not find an existing OpenJDK bug
for jpackage that described this problem.

/Sverre

tir. 29. sep. 2020 kl. 20:41 skrev Sverre Moe <sverre.moe at gmail.com>:

> I think I found a bug in jpackage.
>
> When using a resource directory with a desktop-file and a spec-file.
> The resulting RPM file will contain the desktop file, but its filename is
> wrong. It is adding the application name twice.
>
> Instead of "test-application.desktop" the RPM contains
> "test-application-test-application.desktop".
>
> I created a test application project on GitHub to demonstrate this problem.
> https://github.com/DJViking/test-application
>
> Running the gradle task createPackage will create an RPM with the desktop
> file.
> ~> export JAVA_HOME=/usr/java/jdk-14
> ~> ./gradlew createPackage
>
> /Sverre
>
>
>

From alanb at openjdk.java.net  Thu Oct  1 13:31:46 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 1 Oct 2020 13:31:46 GMT
Subject: RFR: 8253761: Wrong URI syntax printed by jar --describe-module
In-Reply-To: <GoJ43lbyj8ktcJfP8vpa6J3LK2_nFCyo4eFwJfPSFcY=.50f190e3-f244-43e8-95be-9377417d9c9b@github.com>
References: <GoJ43lbyj8ktcJfP8vpa6J3LK2_nFCyo4eFwJfPSFcY=.50f190e3-f244-43e8-95be-9377417d9c9b@github.com>
Message-ID: <KX2hm__Fl4-b1qiK2FOHEYcmt4xNoMfZiZpCRu1G2jY=.457dfb03-27c0-41bc-850b-c1540e15f712@github.com>

On Tue, 29 Sep 2020 05:38:18 GMT, Christian Stein <cstein at openjdk.org> wrote:

> This commit replaces `"/!"` with `"!/"` in order to generate
> valid URIs when printing a module description of a modular
> JAR file. A valid URI is described here: [1]
> 
> https://bugs.openjdk.java.net/browse/JDK-8253761
> 
> [1] https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/net/JarURLConnection.html

The change looks good.

test/jdk/tools/jar/modularJar/Basic.java has tests for jar --describe-module and maybe we could add a test to this to
make sure that it outputs the expected JAR URL.

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

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

From cstein at openjdk.java.net  Thu Oct  1 14:38:04 2020
From: cstein at openjdk.java.net (Christian Stein)
Date: Thu, 1 Oct 2020 14:38:04 GMT
Subject: RFR: 8253761: Wrong URI syntax printed by jar --describe-module
In-Reply-To: <KX2hm__Fl4-b1qiK2FOHEYcmt4xNoMfZiZpCRu1G2jY=.457dfb03-27c0-41bc-850b-c1540e15f712@github.com>
References: <GoJ43lbyj8ktcJfP8vpa6J3LK2_nFCyo4eFwJfPSFcY=.50f190e3-f244-43e8-95be-9377417d9c9b@github.com>
 <KX2hm__Fl4-b1qiK2FOHEYcmt4xNoMfZiZpCRu1G2jY=.457dfb03-27c0-41bc-850b-c1540e15f712@github.com>
Message-ID: <WpA1zwswZsUK3UpcmF011Lja4yNoaZrWcAbJUjG3yn4=.c62c2842-58db-49ff-af82-eb1cfb2577e2@github.com>

On Thu, 1 Oct 2020 13:21:50 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> `test/jdk/tools/jar/modularJar/Basic.java` has tests for jar --describe-module and maybe we could add a test to this to
> make sure that it outputs the expected JAR URL.

Tests are always good to have.

Should I extend the existing `@Test public void describeModuleFoo() ...` method or should I add a new method that
ensures the expected URL is emitted?

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

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

From jpai at openjdk.java.net  Thu Oct  1 14:42:21 2020
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Thu, 1 Oct 2020 14:42:21 GMT
Subject: RFR: 8242882: opening jar file with large manifest might throw
 NegativeArraySizeException [v3]
In-Reply-To: <hUjGc7cxtQADYr19j7gmDTTH4PV1YrGw2DPSwVwvAHE=.bee3f7fb-c67d-47e3-bdf0-b98ef81ad9b1@github.com>
References: <17lthSuYGInBHE2r3hBs0yXvMIZWWQkdLhYYBfRUMfM=.b59db398-6dc4-4b34-b141-2c58f189bce8@github.com>
 <q-vcP-zrDTMzykGdhPiuDQ7bPaK7k8k330j_elpMXw8=.b53d6c8e-f3cf-482e-82ca-8a9b279c13b0@github.com>
 <walZv4s6gD2YsjJX3EVFI8iXqLpfJDv9jcHTwOatj_M=.1e2327d1-487b-4654-b827-9b1426c20f4e@github.com>
 <hUjGc7cxtQADYr19j7gmDTTH4PV1YrGw2DPSwVwvAHE=.bee3f7fb-c67d-47e3-bdf0-b98ef81ad9b1@github.com>
Message-ID: <zlkHMsi5wGUbSGiiWRlXi69_REvhkcUXzr7j4XMOugY=.a382a430-9896-43dd-8852-ade48de34018@github.com>

On Wed, 30 Sep 2020 18:38:40 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> I think it's fine either way.
>
> If you are going to validate the message, which I probably would not,  it would be important to make sure it document
> if the message is changed in JarFile::getBytes, that the test needs updated.  Otherwise it will be easy to miss.

Hello Lance,
I decided to remove the assertion on the exception message. I have updated the PR accordingly.

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

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

From jpai at openjdk.java.net  Thu Oct  1 14:42:21 2020
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Thu, 1 Oct 2020 14:42:21 GMT
Subject: RFR: 8242882: opening jar file with large manifest might throw
 NegativeArraySizeException [v3]
In-Reply-To: <17lthSuYGInBHE2r3hBs0yXvMIZWWQkdLhYYBfRUMfM=.b59db398-6dc4-4b34-b141-2c58f189bce8@github.com>
References: <17lthSuYGInBHE2r3hBs0yXvMIZWWQkdLhYYBfRUMfM=.b59db398-6dc4-4b34-b141-2c58f189bce8@github.com>
Message-ID: <9AgaGLA8q63mDTKDeavbyfZVntagI0bd0Kb7rkQQYyg=.67d4410c-b7db-4048-87d0-4ec1f9d93cd2@github.com>

> Can I please get a review and a sponsor for a fix for https://bugs.openjdk.java.net/browse/JDK-8242882?
> 
> As noted in that JBS issue, if the size of the Manifest entry in the jar happens to be very large (such that it exceeds
> the `Integer.MAX_VALUE`), then the current code in `JarFile#getBytes` can lead to a `NegativeArraySizeException`.  This
> is due to the: if (len != -1 && len <= 65535)  block which evaluates to `true` when the size of the manifest entry is
> larger than `Integer.MAX_VALUE`. As a result, this then ends up calling the code which can lead to the
> `NegativeArraySizeException`.  The commit in this PR fixes that issue by changing those `if/else` blocks to prevent
> this issue and instead use a code path that leads to the `InputStream#readAllBytes()` which internally has the
> necessary checks to throw the expected `OutOfMemoryError`.  This commit also includes a jtreg test case which
> reproduces the issue and verifies the fix.

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

  Second round of review comments addressed

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/323/files
  - new: https://git.openjdk.java.net/jdk/pull/323/files/279c7c83..a011b0d6

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

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

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

From jpai at openjdk.java.net  Thu Oct  1 14:42:24 2020
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Thu, 1 Oct 2020 14:42:24 GMT
Subject: RFR: 8242882: opening jar file with large manifest might throw
 NegativeArraySizeException [v2]
In-Reply-To: <JSDhWxPp22Zr5vWtjs0iveljOW1Ej0WycVdbRHzqPEA=.dfa9db34-b7b2-440e-9bca-0c19dc450b48@github.com>
References: <17lthSuYGInBHE2r3hBs0yXvMIZWWQkdLhYYBfRUMfM=.b59db398-6dc4-4b34-b141-2c58f189bce8@github.com>
 <Eyd8QE33uB1pr8qEtknKqPwJUXzxuvQnkb_LzUHg858=.16a8fb43-c74c-40d6-a681-ffcc4a5ac42a@github.com>
 <JSDhWxPp22Zr5vWtjs0iveljOW1Ej0WycVdbRHzqPEA=.dfa9db34-b7b2-440e-9bca-0c19dc450b48@github.com>
Message-ID: <tsp044AyIttSb2D8mVDj9VneD6nK61iEFu7Af0uvJTk=.e96dbe4a-5e2b-44ef-ad36-9df1bde90ce4@github.com>

On Wed, 30 Sep 2020 17:21:14 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address the review comments and introduce an array size check in JarFile.getBytes() method itself
>
> src/java.base/share/classes/java/util/jar/JarFile.java line 161:
> 
>> 159:      * OutOfMemoryError: Required array size too large
>> 160:      */
>> 161:     private static final int MAX_BUFFER_SIZE = Integer.MAX_VALUE - 8;
> 
> "/**" comments are generally only used for public documentation.  For use here, probably a single line // comment would
> be sufficient to explain what this value is.
> This constant is also named, "MAX_ARRAY_SIZE" in various places, which seems more applicable to this case.

Hello Brent,

I've updated the PR with your suggested changes for this member variable name and the comment.

> src/java.base/share/classes/java/util/jar/JarFile.java line 801:
> 
>> 799:             if (len > MAX_BUFFER_SIZE) {
>> 800:                 throw new OutOfMemoryError("Required array size too large");
>> 801:             }
> 
> I would just add a new `long zeSize` to read and check `ze.getSize()`, and then (int) cast it into `len`, as before.
> Then I think no changes would be needed past L802, `int bytesRead;`

Done. Changed it based on your input.

> test/jdk/java/util/jar/JarFile/LargeManifestOOMTest.java line 78:
> 
>> 76:             bw.write("OOM-Test: ");
>> 77:             for (long i = 0; i < 2147483648L; i++) {
>> 78:                 bw.write("a");
> 
> As you probably noticed, this test takes a little while to run.  One way to speed it up a little would be to write more
> characters at a time.  While we're at it, we may as well make the Manifest well-formed by breaking it into 72-byte
> lines.  See "Line length" under:
> https://docs.oracle.com/en/java/javase/15/docs/specs/jar/jar.html#notes-on-manifest-and-signature-files  Just write
> enough lines to exceed Integer.MAX_VALUE bytes.

I decided to slightly change the way this large manifest file was being created. I borrowed the idea from
`Zip64SizeTest`[1] to create the file and set its length to a large value. I hope that is OK. If not, let me know, I
will change this part.

[1] https://github.com/openjdk/jdk/blob/master/test/jdk/java/util/zip/ZipFile/Zip64SizeTest.java#L121

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

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

From prr at openjdk.java.net  Thu Oct  1 15:29:07 2020
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 1 Oct 2020 15:29:07 GMT
Subject: RFR: 8253747: tools/jpackage/share/AppImagePackageTest.java fails
 with InstalledPackageSize: 0
In-Reply-To: <T9HeNI34-w7d8Jy-MYhnm5xjEfmIIpfvQAANMUVail4=.77c177e6-9721-493f-a0b6-3f16afcab13e@github.com>
References: <T9HeNI34-w7d8Jy-MYhnm5xjEfmIIpfvQAANMUVail4=.77c177e6-9721-493f-a0b6-3f16afcab13e@github.com>
Message-ID: <b8U2tmW3yhLNPPEgg4H-rdkXZJu9zPt9jc8bSh8-dqA=.551a1c29-a1ab-4bee-9d6b-f3da4e0b4bc9@github.com>

On Tue, 29 Sep 2020 15:50:36 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> 8253747: tools/jpackage/share/AppImagePackageTest.java fails with InstalledPackageSize: 0
> Updated Debian code in test to get package size in BK, allowing for non-zero size less than 1KB

Marked as reviewed by prr (Reviewer).

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

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

From luhenry at microsoft.com  Thu Oct  1 15:48:12 2020
From: luhenry at microsoft.com (Ludovic Henry)
Date: Thu, 1 Oct 2020 15:48:12 +0000
Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v12]
In-Reply-To: <t08mgMBggFEJuzguHzW9OPI3AgtasklRfHSO95q3YA4=.98e321ac-8db2-462f-b311-7de33dcb9091@github.com>
References: <rKAoubbLMIMVqS6En_xKWMT8jpEwBU5TF83A-AhWg2E=.908578cd-0877-431e-9447-d5a04e0dc970@github.com>
 <qv-WAepDb6KDawneV5Mw_HXjDB-xBnJkdeIAlquh6bU=.3af0c77f-fe7b-4bee-913b-6e6de513f0bd@github.com>
 <t08mgMBggFEJuzguHzW9OPI3AgtasklRfHSO95q3YA4=.98e321ac-8db2-462f-b311-7de33dcb9091@github.com>
Message-ID: <MWHPR21MB05117D496C7A5BBA833297F7B0300@MWHPR21MB0511.namprd21.prod.outlook.com>

Hi,

As we now have a whole bunch of reviews (thank you all!), we would need a sponsor to get it merged.

Thank you :) 

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

PR: https://github.com/openjdk/jdk/pull/212

From fguallini at openjdk.java.net  Thu Oct  1 17:47:04 2020
From: fguallini at openjdk.java.net (Fernando Guallini)
Date: Thu, 1 Oct 2020 17:47:04 GMT
Subject: Integrated: 8232840:
 java/math/BigInteger/largeMemory/SymmetricRangeTests.java fails due to
 "OutOfMemoryError: Requested array size exceeds VM limit"
In-Reply-To: <HhOCwZZL8VEJfmmxYE7uW57LlarmtMy9dVS6lyyINJQ=.5881db5c-dd06-49c0-9777-c5c707222ef2@github.com>
References: <HhOCwZZL8VEJfmmxYE7uW57LlarmtMy9dVS6lyyINJQ=.5881db5c-dd06-49c0-9777-c5c707222ef2@github.com>
Message-ID: <PN0V0jlgpKF_6ysUrLqcCXzB4ThfyucvEHRTtiQr31I=.c74da147-3cc8-469b-abea-230c90cd5d67@github.com>

On Wed, 30 Sep 2020 11:06:16 GMT, Fernando Guallini <fguallini at openjdk.org> wrote:

> SymmetricRangeTests.java was added to ProblemList as it was throwing OOM time ago. Now, tests have been executed
> multiple times again with a combination of VM options with 100% pass rate, the issue could not be reproduced anymore,
> it seems quite stable to be removed from the ProblemList at this time.  Required os.maxMemory has been increased as a
> preventive measure to run the tests only in an system where memory available is enough to give the JVM some elbow room

This pull request has now been integrated.

Changeset: cfd41c0c
Author:    Fernando Guallini <fguallini at openjdk.org>
Committer: Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/cfd41c0c
Stats:     2 lines in 2 files changed: 0 ins; 1 del; 1 mod

8232840: java/math/BigInteger/largeMemory/SymmetricRangeTests.java fails due to "OutOfMemoryError: Requested array size
exceeds VM limit"

Reviewed-by: alanb

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

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

From herrick at openjdk.java.net  Thu Oct  1 18:40:04 2020
From: herrick at openjdk.java.net (Andy Herrick)
Date: Thu, 1 Oct 2020 18:40:04 GMT
Subject: Integrated: 8253747: tools/jpackage/share/AppImagePackageTest.java
 fails with InstalledPackageSize: 0
In-Reply-To: <T9HeNI34-w7d8Jy-MYhnm5xjEfmIIpfvQAANMUVail4=.77c177e6-9721-493f-a0b6-3f16afcab13e@github.com>
References: <T9HeNI34-w7d8Jy-MYhnm5xjEfmIIpfvQAANMUVail4=.77c177e6-9721-493f-a0b6-3f16afcab13e@github.com>
Message-ID: <kLNVLUfEGodUJ1hvmBhb19aj-kfMNuVrqBkY8mYmpB8=.edba99ed-df4d-4c97-acd7-54206baa7d6e@github.com>

On Tue, 29 Sep 2020 15:50:36 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> 8253747: tools/jpackage/share/AppImagePackageTest.java fails with InstalledPackageSize: 0
> Updated Debian code in test to get package size in BK, allowing for non-zero size less than 1KB

This pull request has now been integrated.

Changeset: 9230c2aa
Author:    Andy Herrick <herrick at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/9230c2aa
Stats:     10 lines in 1 file changed: 9 ins; 0 del; 1 mod

8253747: tools/jpackage/share/AppImagePackageTest.java fails with InstalledPackageSize: 0

Reviewed-by: almatvee, prr

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

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

From igraves at openjdk.java.net  Thu Oct  1 19:19:18 2020
From: igraves at openjdk.java.net (Ian Graves)
Date: Thu, 1 Oct 2020 19:19:18 GMT
Subject: RFR: 8204256: improve jlink error message to report unsupported
 class file format [v2]
In-Reply-To: <fc0WYkvegw3_1RBfXVVy7Vs6HcX7b9UIq7fZ2kK4cCY=.218de7d9-7abf-4eec-af30-d2926464349c@github.com>
References: <fc0WYkvegw3_1RBfXVVy7Vs6HcX7b9UIq7fZ2kK4cCY=.218de7d9-7abf-4eec-af30-d2926464349c@github.com>
Message-ID: <qGVlFtUbSi5Uo7ZVOhgIFjaBYjpD-5yo7_nPWOcbWQA=.81eefc43-09be-4c89-a018-d0de0f9d1292@github.com>

> This pull request contains a change to facilitate better error messages in jlink for when jlink creates an image from
> jmod files that are unsupported by the runtime by being _too new_. The existing behavior supports modules that are too
> old via an error about a mismatched version.  The solution to this problem is constrained by jlink's use of some
> specified behavior by java.lang.module.ModuleFinder. The solution in this PR is to subclass some existing exceptions
> internally as to signal to jlink more specific error conditions when attempting to find and open modules.  Bug here:
> https://bugs.openjdk.java.net/browse/JDK-8204256
> New Error message example:
> 
>  reading module: /Users/igraves/dev/jdk-otro/build/macosx-x64/images/jmods/java.security.sasl.jmod
> java.lang.module.FindException: Error reading module:
> /Users/igraves/dev/jdk-otro/build/macosx-x64/images/jmods/java.security.sasl.jmod 	at
> java.base/jdk.internal.module.ModulePath.readModule(ModulePath.java:350) 	at
> java.base/jdk.internal.module.ModulePath.scanDirectory(ModulePath.java:284) 	at
> java.base/jdk.internal.module.ModulePath.scan(ModulePath.java:232) 	at
> java.base/jdk.internal.module.ModulePath.scanNextEntry(ModulePath.java:190) 	at
> java.base/jdk.internal.module.ModulePath.find(ModulePath.java:154) 	at
> jdk.jlink/jdk.tools.jlink.internal.JlinkTask.newModuleFinder(JlinkTask.java:443) 	at
> jdk.jlink/jdk.tools.jlink.internal.JlinkTask.initJlinkConfig(JlinkTask.java:374) 	at
> jdk.jlink/jdk.tools.jlink.internal.JlinkTask.run(JlinkTask.java:267) 	at
> jdk.jlink/jdk.tools.jlink.internal.Main.run(Main.java:54) 	at jdk.jlink/jdk.tools.jlink.internal.Main.main(Main.java:33)
> Caused by: java.lang.module.InvalidModuleDescriptorException: Unsupported major.minor version 60.0
> 	at java.base/jdk.internal.module.ModuleInfo.invalidModuleDescriptor(ModuleInfo.java:1088)
> 	at java.base/jdk.internal.module.ModuleInfo.doRead(ModuleInfo.java:192)
> 	at java.base/jdk.internal.module.ModuleInfo.read(ModuleInfo.java:129)
> 	at java.base/jdk.internal.module.ModulePath.readJMod(ModulePath.java:395)
> 	at java.base/jdk.internal.module.ModulePath.readModule(ModulePath.java:343)
> 	... 9 more```

Ian Graves 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:

  Print stack traces for find exceptions in JLink

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/409/files
  - new: https://git.openjdk.java.net/jdk/pull/409/files/1eb85453..bee11534

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

  Stats: 150 lines in 6 files changed: 5 ins; 120 del; 25 mod
  Patch: https://git.openjdk.java.net/jdk/pull/409.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/409/head:pull/409

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

From igraves at openjdk.java.net  Thu Oct  1 19:19:18 2020
From: igraves at openjdk.java.net (Ian Graves)
Date: Thu, 1 Oct 2020 19:19:18 GMT
Subject: RFR: 8204256: improve jlink error message to report unsupported
 class file format [v2]
In-Reply-To: <OlqxCK35p3vCmVcbI1otDWQOgUIdAoVVLUTqQP13hXg=.0913de5f-c0ee-4764-a5df-3d89c096eb45@github.com>
References: <fc0WYkvegw3_1RBfXVVy7Vs6HcX7b9UIq7fZ2kK4cCY=.218de7d9-7abf-4eec-af30-d2926464349c@github.com>
 <4G3_8Xep8bMY6mC17exBywM_HTJNLQI_JJkURTzg8QU=.6b26d80c-3e4d-46a5-abfe-1ff58af8b51f@github.com>
 <A0Vm50jN4M86KA8WbWzf2gSdfynWNi9lLdOcOfPKpdc=.1d56ffb6-0107-4ec0-bcab-3af2e411e826@github.com>
 <YQUXcPWFnSSR808GyNnSW_o8iL5aWRRGIqG5G80TYYY=.d558f1d1-a5b3-4489-949c-f9dfbedc4590@github.com>
 <PESIYTROv6I4IrTC3aNS8De3N0NR4jrKjLAT4KG9VBc=.c93211af-82c7-4ec1-9846-16e8e284c559@github.com>
 <OlqxCK35p3vCmVcbI1otDWQOgUIdAoVVLUTqQP13hXg=.0913de5f-c0ee-4764-a5df-3d89c096eb45@github.com>
Message-ID: <0V571UaGaol6GG-p46k1xxbWJj-NBkUavf2oYekmyBA=.8792028a-5d80-403f-a705-cfc9537dd44b@github.com>

On Thu, 1 Oct 2020 06:53:04 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>>> Alternatively we could change the existing exception message path and modify it so it's in line with the simpler
>>> solution as well? That makes sense to me, anyway.
>> 
>> Sounds reasonable to me.
>
> Add a cause may work but it should probably be predicted on isLinkPhase as otherwise it will leak through to usages of
> the ModuleFinder API.

So after some thought and discussion offline, I've pushed a pretty different change that slims all of this down to
simply printing an exception stack trace to the log/stdout when a FindException is thrown. This isn't the same way as
the other error, but I believe for reasons given elsewhere that this is okay.

This exception is thrown when we're looking into module that is newer than the current runtime's supported module
versions. This should never be supported and is unique from the existing case where we don't link modules that are
older versions than the runtime's supported version. This leaves that code path alone.

Since the FindException is a broad exception and can be thrown for a variety of reasons, printing the stack trace
should provide visibility into what the problem is while keeping any kind of coupling in jlink to that exception to a
minimum.

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

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

From igraves at openjdk.java.net  Thu Oct  1 19:19:18 2020
From: igraves at openjdk.java.net (Ian Graves)
Date: Thu, 1 Oct 2020 19:19:18 GMT
Subject: RFR: 8204256: improve jlink error message to report unsupported
 class file format [v2]
In-Reply-To: <0V571UaGaol6GG-p46k1xxbWJj-NBkUavf2oYekmyBA=.8792028a-5d80-403f-a705-cfc9537dd44b@github.com>
References: <fc0WYkvegw3_1RBfXVVy7Vs6HcX7b9UIq7fZ2kK4cCY=.218de7d9-7abf-4eec-af30-d2926464349c@github.com>
 <4G3_8Xep8bMY6mC17exBywM_HTJNLQI_JJkURTzg8QU=.6b26d80c-3e4d-46a5-abfe-1ff58af8b51f@github.com>
 <A0Vm50jN4M86KA8WbWzf2gSdfynWNi9lLdOcOfPKpdc=.1d56ffb6-0107-4ec0-bcab-3af2e411e826@github.com>
 <YQUXcPWFnSSR808GyNnSW_o8iL5aWRRGIqG5G80TYYY=.d558f1d1-a5b3-4489-949c-f9dfbedc4590@github.com>
 <PESIYTROv6I4IrTC3aNS8De3N0NR4jrKjLAT4KG9VBc=.c93211af-82c7-4ec1-9846-16e8e284c559@github.com>
 <OlqxCK35p3vCmVcbI1otDWQOgUIdAoVVLUTqQP13hXg=.0913de5f-c0ee-4764-a5df-3d89c096eb45@github.com>
 <0V571UaGaol6GG-p46k1xxbWJj-NBkUavf2oYekmyBA=.8792028a-5d80-403f-a705-cfc9537dd44b@github.com>
Message-ID: <lLHjZCTeYXlKCGvYT9F2B1gh8oYX8uokOS6mCYtfsTQ=.3d507387-7a9b-4cd4-b1a0-b78293bdb3ba@github.com>

On Thu, 1 Oct 2020 18:11:02 GMT, Ian Graves <igraves at openjdk.org> wrote:

>> Add a cause may work but it should probably be predicted on isLinkPhase as otherwise it will leak through to usages of
>> the ModuleFinder API.
>
> So after some thought and discussion offline, I've pushed a pretty different change that slims all of this down to
> simply printing an exception stack trace to the log/stdout when a FindException is thrown. This isn't the same way as
> the other error, but I believe for reasons given elsewhere that this is okay.  This exception is thrown when we're
> looking into module that is newer than the current runtime's supported module versions. This should never be supported
> and is unique from the existing case where we don't link modules that are older versions than the runtime's supported
> version. This leaves that code path alone.  Since the FindException is a broad exception and can be thrown for a
> variety of reasons, printing the stack trace should provide visibility into what the problem is while keeping any kind
> of coupling in jlink to that exception to a minimum.

New error message:

Error: Error reading module: /Users/igraves/dev/jdk-otro/build/macosx-x64/images/jmods/java.security.sasl.jmod
java.lang.module.FindException: Error reading module:
/Users/igraves/dev/jdk-otro/build/macosx-x64/images/jmods/java.security.sasl.jmod 	at
java.base/jdk.internal.module.ModulePath.readModule(ModulePath.java:350) 	at
java.base/jdk.internal.module.ModulePath.scanDirectory(ModulePath.java:284) 	at
java.base/jdk.internal.module.ModulePath.scan(ModulePath.java:232) 	at
java.base/jdk.internal.module.ModulePath.scanNextEntry(ModulePath.java:190) 	at
java.base/jdk.internal.module.ModulePath.find(ModulePath.java:154) 	at
jdk.jlink/jdk.tools.jlink.internal.JlinkTask.newModuleFinder(JlinkTask.java:443) 	at
jdk.jlink/jdk.tools.jlink.internal.JlinkTask.initJlinkConfig(JlinkTask.java:374) 	at
jdk.jlink/jdk.tools.jlink.internal.JlinkTask.run(JlinkTask.java:267) 	at
jdk.jlink/jdk.tools.jlink.internal.Main.run(Main.java:54) 	at jdk.jlink/jdk.tools.jlink.internal.Main.main(Main.java:33)
Caused by: java.lang.module.InvalidModuleDescriptorException: Unsupported major.minor version 60.0
	at java.base/jdk.internal.module.ModuleInfo.invalidModuleDescriptor(ModuleInfo.java:1088)
	at java.base/jdk.internal.module.ModuleInfo.doRead(ModuleInfo.java:192)
	at java.base/jdk.internal.module.ModuleInfo.read(ModuleInfo.java:129)
	at java.base/jdk.internal.module.ModulePath.readJMod(ModulePath.java:395)
	at java.base/jdk.internal.module.ModulePath.readModule(ModulePath.java:343)
	... 9 more

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

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

From lmesnik at openjdk.java.net  Thu Oct  1 19:54:05 2020
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Thu, 1 Oct 2020 19:54:05 GMT
Subject: RFR: 8229186: Improve error messages for TestStringIntrinsics
 failures [v6]
In-Reply-To: <b3GkK3NPrSYq9sWmkUDW9mZN6kMRoGVLFNBxCMIEsPs=.6119e887-b2e1-4c94-aa52-8200faec288a@github.com>
References: <Br6z5yt0kTbZwIQyTI9lz7czaYpjw5vCd5ZCbbrSIcM=.6a8096f1-91ed-4673-bab3-3bfae758ab95@github.com>
 <b3GkK3NPrSYq9sWmkUDW9mZN6kMRoGVLFNBxCMIEsPs=.6119e887-b2e1-4c94-aa52-8200faec288a@github.com>
Message-ID: <BAPITdSC4Qh9hS0VNQ0lJuiUnrAug3puTLhsWufTdkc=.b924cb4c-8f37-4a3d-8d49-b15b9378c0bc@github.com>

On Thu, 1 Oct 2020 04:57:39 GMT, Evgeny Nikitin <enikitin at openjdk.org> wrote:

>> pre-Skara RFR thread: [link](https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-May/038416.html)
>> 
>> Error reporting was improved by writing a C-style escaped string representations for the variables passed to the
>> methods being tested. For array comparisons, a dedicated diff-formatter was implemented.
>> Sample output for comparing byte arrays (with artificial failure):
>>  ----------System.err:(21/1553)----------
>>  Result: (false) of 'arrayEqualsB' is not equal to expected (true)
>>  Arrays differ starting from [index: 7]:
>>  ... 5, 6,   7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, ...
>>  ... 5, 6, 125, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, ...
>>            ^^^^
>>  java.lang.RuntimeException: Result: (false) of 'arrayEqualsB' is not
>>  equal to expected (true)
>>           at
>>  compiler.intrinsics.string.TestStringIntrinsics.invokeAndCheckArrays(TestStringIntrinsics.java:273)
>>            at ... stack trace continues - E.N.
>>  Sample output for comparing char arrays:
>>  ----------System.err:(21/1579)*----------
>>  Result: (false) of 'arrayEqualsC' is not equal to expected (true)
>>  Arrays differ starting from [index: 7]:
>>  ... \\u0005, \\u0006, \\u0007, \\u0008, \\u0009, \\n, ...
>>  ... \\u0005, \\u0006,      }, \\u0008, \\u0009, \\n, ...
>>                      ^^^^^^^
>>  java.lang.RuntimeException: Result: (false) of 'arrayEqualsC' is not
>>  equal to expected (true)
>>           at
>>  compiler.intrinsics.string.TestStringIntrinsics.invokeAndCheckArrays(TestStringIntrinsics.java:280)
>>            at
>>  ... and so on - E.N.
>> 
>> testing: open/test/hotspot/jtreg/compiler/intrinsics/string/TestStringIntrinsics.java on linux, windows, macosx.
>
> Evgeny Nikitin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use SB to build TestStringIntrinsics message, avoid type guessing in ArrayDiff

Changes requested by lmesnik (Committer).

test/lib/jdk/test/lib/format/Format.java line 2:

> 1: /*
> 2:  * Copyright (c) 2015, 2020, Oracle and/or its affiliates. All rights reserved.

Shouldn't be just 2020?

test/lib/jdk/test/lib/format/Diff.java line 30:

> 28:
> 29: /**
> 30:  * An abstraction representing formattabe difference between two or more objects

typo in 'formattabe'

test/lib/jdk/test/lib/format/ArrayDiff.java line 81:

> 79:      * Default limits for the formatter
> 80:      */
> 81:     public static class Defaults {

Does it make sense to move them into Diff? Seems like very generic formatter properties to me.

test/lib-test/jdk/test/lib/format/ArrayDiffTest.java line 38:

> 36:  * @run testng jdk.test.lib.format.ArrayDiffTest
> 37:  */
> 38: public class ArrayDiffTest {

Might be it makes sense to check null values. Also, reversed checks. For example there is first = [1, ..], second = [].
But no check for  first = [], second = [1, ..] for some cases,

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

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

From sspitsyn at openjdk.java.net  Thu Oct  1 20:22:08 2020
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Thu, 1 Oct 2020 20:22:08 GMT
Subject: RFR: 8252537: Updated @exception with @throws [v4]
In-Reply-To: <1uaoGmT1-Bw11W4ki15HeUk6PPmAPnHC4kK5nOu4K2o=.5838a706-9f19-4f00-a481-0430c7dc50b4@github.com>
References: <jWf2YS8e4ZhTRfuFPquC4jxUS-urxG4ZDQ2B5FM86rQ=.a0467b19-1e45-4fad-abd6-256f720ef5b7@github.com>
 <1uaoGmT1-Bw11W4ki15HeUk6PPmAPnHC4kK5nOu4K2o=.5838a706-9f19-4f00-a481-0430c7dc50b4@github.com>
Message-ID: <WYDM3-7XavMOiNNmDwyXjPHGq6No8T0uQy8r1ltBtAU=.5e68b429-587a-459d-ab75-189fbbde2f7e@github.com>

On Sun, 27 Sep 2020 12:46:21 GMT, Vipin Sharma <vsharma at openjdk.org> wrote:

>> Updated @exception with @throws for core-libs, it fixes all open sub-tasks of JDK-8252536.
>> 
>> Open Subtasks part of this fix are:
>> 1. JDK-8252537
>> 2. JDK-8252539
>> 3. JDK-8252540
>> 4. JDK-8252541
>> 
>> Previous conversation on this:
>> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-September/068540.html
>
> Vipin Sharma has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replaced <code>...</code> with {@code ...} for modified statement in java.sql

Marked as reviewed by sspitsyn (Reviewer).

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

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

From iklam at openjdk.java.net  Thu Oct  1 21:09:05 2020
From: iklam at openjdk.java.net (Ioi Lam)
Date: Thu, 1 Oct 2020 21:09:05 GMT
Subject: RFR: 8247536: Support for pre-generated java.lang.invoke classes
 in CDS static archive [v7]
In-Reply-To: <NS8V8hor2FJLWonf64meNwpjYop9siRLWfICNcsrJ6k=.71f8e54f-8fb6-44d3-8a78-0a1b424e403c@github.com>
References: <Y_Bas-poGnDtvcJbqbmeIAPQRNxzvarBToQWALn9TTE=.e846cd3c-0e7b-48d3-8ffa-be3c03acffb0@github.com>
 <NS8V8hor2FJLWonf64meNwpjYop9siRLWfICNcsrJ6k=.71f8e54f-8fb6-44d3-8a78-0a1b424e403c@github.com>
Message-ID: <XrhihBeJ1hn0PBrndhMacl6M7rbba7Cm0TcpMjkEfgg=.ac099ba6-920a-4bc9-ab5c-0f5fd925cf40@github.com>

On Wed, 30 Sep 2020 04:59:20 GMT, Yumin Qi <minqi at openjdk.org> wrote:

>> This patch is reorganized after 8252725, which is separated from this patch to refactor jlink glugin code. The previous
>> webrev with hg can be found at: http://cr.openjdk.java.net/~minqi/2020/8247536/webrev-05. With 8252725 integrated, the
>> regeneration of holder classes is simply to call the new added GenerateJLIClassesHelper.cdsGenerateHolderClasses
>> function.  Tests: tier1-4
>
> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove trailing word of line which is not used in holder class regeneration. There is a trailing LF (Line Feed) so trim
>   white spaces from both front and end of the line or it will fail method type validation.

Changes requested by iklam (Reviewer).

test/hotspot/jtreg/runtime/cds/appcds/DumpClassListWithLF.java line 70:

> 68:                 "Hello",
> 69:                 "@lambda-form-invoker [LF_RESOLVE] java.lang.invoke.DirectMethodHandle$Holder invokeNothing  L7_L
> (anyword)", 70:                 "@lambda-form-invoker [LF_RESOLVE] java.lang.invoke.DirectMethodHandle$Holder
> invokeNothing  LL_I anyword"),

We shouldn't allow the classlist to contain arbitrary data. These two cases should generate an error.

src/hotspot/share/classfile/lambdaFormInvokers.cpp line 52:

> 50:
> 51: // trim white spaces from front and end of string.
> 52: char* trim(char* s) {

I think this creates unnecessary dependency between the C code and the Java code. The C code assumes that the Java code
has appended something like "(salvaged)" into the output, and tries to get rid of that in a non-obvious way. It's
better to modify the Java code from

static void traceSpeciesType(String cn, Class<?> salvage) {
    if (TRACE_RESOLVE || CDS.isDumpLoadedClassList()) {
        String traceSP = SPECIES_RESOLVE + " " + cn + (salvage != null ? " (salvaged)" : " (generated)");
        if (TRACE_RESOLVE) {
            System.out.println(traceSP);
        }
        CDS.logTraceResolve(traceSP);
    }
}

to

    if (TRACE_RESOLVE || CDS.isDumpLoadedClassList()) {
        String traceSP = SPECIES_RESOLVE + " " + cn;
        if (TRACE_RESOLVE) {
            System.out.println(traceSP + (salvage != null ? " (salvaged)" : " (generated)"));
        }
        CDS.logTraceResolve(traceSP);
    }

test/hotspot/jtreg/runtime/cds/appcds/DumpClassListWithLF.java line 85:

> 83:             appJar, classlist(
> 84:                 "Hello",
> 85:                 "@lambda-form-invoker [LF_XYRESOLVE] java.lang.invoke.DirectMethodHandle$Holder invokeStatic  L7_L
> (any)",

We should not allow incorrect input. This should generate an error.

test/hotspot/jtreg/runtime/cds/appcds/DumpClassListWithLF.java line 78:

> 76:                 "Hello",
> 77:                 "@lambda-form-invoker [LF_RESOLVE] my.nonexist.package.MyNonExistClassName$holder invokeStatic
> L7_L", 78:                 "@lambda-form-invoker [LF_RESOLVE] my.nonexist.package.MyNonExistClassName$holder
> invokeStatic  LL_I"),

I think it's dangerous to allow arbitrary class names here. InvokerBytecodeGenerator doesn't check the classname. This
will make it possible to overwrite the contents of arbitrary classes. We should have a check here and allow only the
specific holder classes that are supported.

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

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

From iklam at openjdk.java.net  Thu Oct  1 21:14:05 2020
From: iklam at openjdk.java.net (Ioi Lam)
Date: Thu, 1 Oct 2020 21:14:05 GMT
Subject: RFR: 8247536: Support for pre-generated java.lang.invoke classes
 in CDS static archive [v7]
In-Reply-To: <NS8V8hor2FJLWonf64meNwpjYop9siRLWfICNcsrJ6k=.71f8e54f-8fb6-44d3-8a78-0a1b424e403c@github.com>
References: <Y_Bas-poGnDtvcJbqbmeIAPQRNxzvarBToQWALn9TTE=.e846cd3c-0e7b-48d3-8ffa-be3c03acffb0@github.com>
 <NS8V8hor2FJLWonf64meNwpjYop9siRLWfICNcsrJ6k=.71f8e54f-8fb6-44d3-8a78-0a1b424e403c@github.com>
Message-ID: <0pxum63ap0sTm7YsoOevKNQEhKZQQmfvigtIxyg2clc=.50b5da47-754e-4b03-9111-1e99d0311312@github.com>

On Wed, 30 Sep 2020 04:59:20 GMT, Yumin Qi <minqi at openjdk.org> wrote:

>> This patch is reorganized after 8252725, which is separated from this patch to refactor jlink glugin code. The previous
>> webrev with hg can be found at: http://cr.openjdk.java.net/~minqi/2020/8247536/webrev-05. With 8252725 integrated, the
>> regeneration of holder classes is simply to call the new added GenerateJLIClassesHelper.cdsGenerateHolderClasses
>> function.  Tests: tier1-4
>
> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove trailing word of line which is not used in holder class regeneration. There is a trailing LF (Line Feed) so trim
>   white spaces from both front and end of the line or it will fail method type validation.

Changes requested by iklam (Reviewer).

src/java.base/share/classes/jdk/internal/misc/CDS.java line 30:

> 28: public class CDS {
> 29:     // cache the result
> 30:     static private boolean isDumpLoadedClassList;

`isDumpLoadedClassList` is not gramatically correct. Also the field should be final. How about:

static final private boolean isDumpingClassList = isDumpingClassList0();
public static boolean isDumpingClassList() {
    return isDumpingClassList;
}
private static boolean isDumpingClassList0();

src/java.base/share/classes/jdk/internal/misc/CDS.java line 82:

> 80:      * log output to DumpLoadedClassList
> 81:      */
> 82:     public static void logTraceResolve(String line) {

`logTraceResolve` is too generic. How about `CDS.logLambdaFormInvoker()` to match the `@lambda-form-invoker` in the
classlist file?

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

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

From mchung at openjdk.java.net  Thu Oct  1 22:49:03 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Thu, 1 Oct 2020 22:49:03 GMT
Subject: RFR: 8204256: improve jlink error message to report unsupported
 class file format [v2]
In-Reply-To: <qGVlFtUbSi5Uo7ZVOhgIFjaBYjpD-5yo7_nPWOcbWQA=.81eefc43-09be-4c89-a018-d0de0f9d1292@github.com>
References: <fc0WYkvegw3_1RBfXVVy7Vs6HcX7b9UIq7fZ2kK4cCY=.218de7d9-7abf-4eec-af30-d2926464349c@github.com>
 <qGVlFtUbSi5Uo7ZVOhgIFjaBYjpD-5yo7_nPWOcbWQA=.81eefc43-09be-4c89-a018-d0de0f9d1292@github.com>
Message-ID: <UOeX1EtrXyzdkhFeBx-prDjTGZwWh1my4NSODNZQwYg=.ef69bb7d-d883-47e3-b080-3dbabc45f104@github.com>

On Thu, 1 Oct 2020 19:19:18 GMT, Ian Graves <igraves at openjdk.org> wrote:

>> This pull request contains a change to facilitate better error messages in jlink for when jlink creates an image from
>> jmod files that are unsupported by the runtime by being _too new_. The existing behavior supports modules that are too
>> old via an error about a mismatched version.  The solution to this problem is constrained by jlink's use of some
>> specified behavior by java.lang.module.ModuleFinder. The solution in this PR is to subclass some existing exceptions
>> internally as to signal to jlink more specific error conditions when attempting to find and open modules.  Bug here:
>> https://bugs.openjdk.java.net/browse/JDK-8204256
>> New Error message example:
>> 
>>  reading module: /Users/igraves/dev/jdk-otro/build/macosx-x64/images/jmods/java.security.sasl.jmod
>> java.lang.module.FindException: Error reading module:
>> /Users/igraves/dev/jdk-otro/build/macosx-x64/images/jmods/java.security.sasl.jmod 	at
>> java.base/jdk.internal.module.ModulePath.readModule(ModulePath.java:350) 	at
>> java.base/jdk.internal.module.ModulePath.scanDirectory(ModulePath.java:284) 	at
>> java.base/jdk.internal.module.ModulePath.scan(ModulePath.java:232) 	at
>> java.base/jdk.internal.module.ModulePath.scanNextEntry(ModulePath.java:190) 	at
>> java.base/jdk.internal.module.ModulePath.find(ModulePath.java:154) 	at
>> jdk.jlink/jdk.tools.jlink.internal.JlinkTask.newModuleFinder(JlinkTask.java:443) 	at
>> jdk.jlink/jdk.tools.jlink.internal.JlinkTask.initJlinkConfig(JlinkTask.java:374) 	at
>> jdk.jlink/jdk.tools.jlink.internal.JlinkTask.run(JlinkTask.java:267) 	at
>> jdk.jlink/jdk.tools.jlink.internal.Main.run(Main.java:54) 	at jdk.jlink/jdk.tools.jlink.internal.Main.main(Main.java:33)
>> Caused by: java.lang.module.InvalidModuleDescriptorException: Unsupported major.minor version 60.0
>> 	at java.base/jdk.internal.module.ModuleInfo.invalidModuleDescriptor(ModuleInfo.java:1088)
>> 	at java.base/jdk.internal.module.ModuleInfo.doRead(ModuleInfo.java:192)
>> 	at java.base/jdk.internal.module.ModuleInfo.read(ModuleInfo.java:129)
>> 	at java.base/jdk.internal.module.ModulePath.readJMod(ModulePath.java:395)
>> 	at java.base/jdk.internal.module.ModulePath.readModule(ModulePath.java:343)
>> 	... 9 more```
>
> Ian Graves 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.

Given that linking with JMODs of an unsupported class file version is rare case,
it's not a bad choice to go with this simplest solution printing the stack trace.

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 232:

> 230:             if (remaining.size() > 0 && !options.suggestProviders) {
> 231:                 throw taskHelper.newBadArgs("err.orphan.arguments",
> 232:                         remaining.stream().collect(Collectors.joining(" ")))

Formatting nit: this change makes it a little hard to see it's an argument passed to `newBadArgs`.

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

Marked as reviewed by mchung (Reviewer).

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

From david.holmes at oracle.com  Thu Oct  1 21:50:28 2020
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 2 Oct 2020 07:50:28 +1000
Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v12]
In-Reply-To: <MWHPR21MB05117D496C7A5BBA833297F7B0300@MWHPR21MB0511.namprd21.prod.outlook.com>
References: <rKAoubbLMIMVqS6En_xKWMT8jpEwBU5TF83A-AhWg2E=.908578cd-0877-431e-9447-d5a04e0dc970@github.com>
 <qv-WAepDb6KDawneV5Mw_HXjDB-xBnJkdeIAlquh6bU=.3af0c77f-fe7b-4bee-913b-6e6de513f0bd@github.com>
 <t08mgMBggFEJuzguHzW9OPI3AgtasklRfHSO95q3YA4=.98e321ac-8db2-462f-b311-7de33dcb9091@github.com>
 <MWHPR21MB05117D496C7A5BBA833297F7B0300@MWHPR21MB0511.namprd21.prod.outlook.com>
Message-ID: <1b89dc62-87fe-baa0-24c7-1f07bbdd5e48@oracle.com>

Hi,

On 2/10/2020 1:48 am, Ludovic Henry wrote:
> Hi,
> 
> As we now have a whole bunch of reviews (thank you all!), we would need a sponsor to get it merged.

The JEP is not yet targeted so we have to wait for that formality. But 
once that happens I can sponsor for you.

Also note that the PR references the wrong JEP so can you please edit 
the description to fix that.

Meanwhile I'll see if I can take this for a spin through our internal 
testing.

Cheers,
David
-----

> Thank you :)
> 
> -------------
> 
> PR: https://github.com/openjdk/jdk/pull/212
> 

From luhenry at microsoft.com  Thu Oct  1 21:56:53 2020
From: luhenry at microsoft.com (Ludovic Henry)
Date: Thu, 1 Oct 2020 21:56:53 +0000
Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v12]
In-Reply-To: <1b89dc62-87fe-baa0-24c7-1f07bbdd5e48@oracle.com>
References: <rKAoubbLMIMVqS6En_xKWMT8jpEwBU5TF83A-AhWg2E=.908578cd-0877-431e-9447-d5a04e0dc970@github.com>
 <qv-WAepDb6KDawneV5Mw_HXjDB-xBnJkdeIAlquh6bU=.3af0c77f-fe7b-4bee-913b-6e6de513f0bd@github.com>
 <t08mgMBggFEJuzguHzW9OPI3AgtasklRfHSO95q3YA4=.98e321ac-8db2-462f-b311-7de33dcb9091@github.com>
 <MWHPR21MB05117D496C7A5BBA833297F7B0300@MWHPR21MB0511.namprd21.prod.outlook.com>
 <1b89dc62-87fe-baa0-24c7-1f07bbdd5e48@oracle.com>
Message-ID: <MWHPR21MB05112D9AB69CF5FC740B609AB0300@MWHPR21MB0511.namprd21.prod.outlook.com>

Hi David,

> The JEP is not yet targeted so we have to wait for that formality. But once that happens I can sponsor for you.

Perfect, I didn't know about the need for the JEP to be targeted before the merge.

> Also note that the PR references the wrong JEP so can you please edit the description to fix that.

I'll work with @Monica to update the PR's description to point to https://openjdk.java.net/jeps/391 instead.

Thank you!
Ludovic
 

From luhenry at microsoft.com  Thu Oct  1 22:14:16 2020
From: luhenry at microsoft.com (Ludovic Henry)
Date: Thu, 1 Oct 2020 22:14:16 +0000
Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v12]
In-Reply-To: <b61ef9c2-8599-8432-25cf-75ce3ef24fd0@oracle.com>
References: <rKAoubbLMIMVqS6En_xKWMT8jpEwBU5TF83A-AhWg2E=.908578cd-0877-431e-9447-d5a04e0dc970@github.com>
 <qv-WAepDb6KDawneV5Mw_HXjDB-xBnJkdeIAlquh6bU=.3af0c77f-fe7b-4bee-913b-6e6de513f0bd@github.com>
 <t08mgMBggFEJuzguHzW9OPI3AgtasklRfHSO95q3YA4=.98e321ac-8db2-462f-b311-7de33dcb9091@github.com>
 <MWHPR21MB05117D496C7A5BBA833297F7B0300@MWHPR21MB0511.namprd21.prod.outlook.com>
 <1b89dc62-87fe-baa0-24c7-1f07bbdd5e48@oracle.com>
 <MWHPR21MB05112D9AB69CF5FC740B609AB0300@MWHPR21MB0511.namprd21.prod.outlook.com>
 <b61ef9c2-8599-8432-25cf-75ce3ef24fd0@oracle.com>
Message-ID: <MWHPR21MB0511FBB19387F6D9F172AF59B0300@MWHPR21MB0511.namprd21.prod.outlook.com>

It?s me who made a mistake. This PR should be associated with JEP 388 as you are rightly pointing out.

From: Daniel D. Daugherty <daniel.daugherty at oracle.com>
Sent: Thursday, October 1, 2020 3:05 PM
To: Ludovic Henry <luhenry at microsoft.com>; David Holmes <david.holmes at oracle.com>; David Holmes <dholmes at openjdk.java.net>; Andrew Haley <aph at openjdk.java.net>; Chris Plummer <cjplummer at openjdk.java.net>; Magnus Ihse Bursie <ihse at openjdk.java.net>; build-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; serviceability-dev at openjdk.java.net; shenandoah-dev at openjdk.java.net; Monica Beckwith <Monica.Beckwith at microsoft.com>
Subject: Re: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v12]

So I'm confused... this PR is associated with this bug ID:


Issue

  *   JDK-8248238<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8248238&data=02%7C01%7Cluhenry%40microsoft.com%7Ce428223ea04a45c2d40308d866562328%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371867436454353&sdata=FV0tr%2FktSPQDxHkI1JMr7UCgW4ygPi8d4yKsGuPVUg8%3D&reserved=0>: Implementation of JEP: Windows AArch64 Support


and JDK-8248238 is associated with this JEP:


JDK-8248496<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8248496&data=02%7C01%7Cluhenry%40microsoft.com%7Ce428223ea04a45c2d40308d866562328%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371867436454353&sdata=HAjFLX%2BtIaKz%2FFULuav%2BUXn6qTZb%2BkjiS4ijsWw7RQE%3D&reserved=0> JEP 388: Windows/AArch64 Port

Am I missing something here?

Dan

On 10/1/20 5:56 PM, Ludovic Henry wrote:

Hi David,



The JEP is not yet targeted so we have to wait for that formality. But once that happens I can sponsor for you.



Perfect, I didn't know about the need for the JEP to be targeted before the merge.



Also note that the PR references the wrong JEP so can you please edit the description to fix that.



I'll work with @Monica to update the PR's description to point to https://openjdk.java.net/jeps/391<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fopenjdk.java.net%2Fjeps%2F391&data=02%7C01%7Cluhenry%40microsoft.com%7Ce428223ea04a45c2d40308d866562328%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371867436464348&sdata=Pj%2FNQvzEa8mrhvY75OFVBG7k623Mgnr56Xo3On%2BoQGo%3D&reserved=0> instead.



Thank you!

Ludovic




From daniel.daugherty at oracle.com  Thu Oct  1 22:05:03 2020
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Thu, 1 Oct 2020 18:05:03 -0400
Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v12]
In-Reply-To: <MWHPR21MB05112D9AB69CF5FC740B609AB0300@MWHPR21MB0511.namprd21.prod.outlook.com>
References: <rKAoubbLMIMVqS6En_xKWMT8jpEwBU5TF83A-AhWg2E=.908578cd-0877-431e-9447-d5a04e0dc970@github.com>
 <qv-WAepDb6KDawneV5Mw_HXjDB-xBnJkdeIAlquh6bU=.3af0c77f-fe7b-4bee-913b-6e6de513f0bd@github.com>
 <t08mgMBggFEJuzguHzW9OPI3AgtasklRfHSO95q3YA4=.98e321ac-8db2-462f-b311-7de33dcb9091@github.com>
 <MWHPR21MB05117D496C7A5BBA833297F7B0300@MWHPR21MB0511.namprd21.prod.outlook.com>
 <1b89dc62-87fe-baa0-24c7-1f07bbdd5e48@oracle.com>
 <MWHPR21MB05112D9AB69CF5FC740B609AB0300@MWHPR21MB0511.namprd21.prod.outlook.com>
Message-ID: <b61ef9c2-8599-8432-25cf-75ce3ef24fd0@oracle.com>

So I'm confused... this PR is associated with this bug ID:

>
>       Issue
>
>   * JDK-8248238 <https://bugs.openjdk.java.net/browse/JDK-8248238>:
>     Implementation of JEP: Windows AArch64 Support
>


and JDK-8248238 is associated with this JEP:

> JDK-8248496 <https://bugs.openjdk.java.net/browse/JDK-8248496> JEP 
> 388: Windows/AArch64 Port 

Am I missing something here?

Dan


On 10/1/20 5:56 PM, Ludovic Henry wrote:
> Hi David,
>
>> The JEP is not yet targeted so we have to wait for that formality. But once that happens I can sponsor for you.
> Perfect, I didn't know about the need for the JEP to be targeted before the merge.
>
>> Also note that the PR references the wrong JEP so can you please edit the description to fix that.
> I'll work with @Monica to update the PR's description to point to https://openjdk.java.net/jeps/391 instead.
>
> Thank you!
> Ludovic
>   


From github.com+70893615+jasontatton-aws at openjdk.java.net  Fri Oct  2 08:40:58 2020
From: github.com+70893615+jasontatton-aws at openjdk.java.net (Jason Tatton)
Date: Fri, 2 Oct 2020 08:40:58 GMT
Subject: RFR: 8173585: Intrinsify StringLatin1.indexOf(char) [v4]
In-Reply-To: <_T0873dC5tfUtGn9r1_Y21JkPKRt-za3MM9hPN2GQKQ=.b865fe53-5417-424f-81b6-1566a330640e@github.com>
References: <_T0873dC5tfUtGn9r1_Y21JkPKRt-za3MM9hPN2GQKQ=.b865fe53-5417-424f-81b6-1566a330640e@github.com>
Message-ID: <Zw-pc6-7I0QmKg9KVIDxG3CKtK4ZRGrgID0J0UsNHoc=.b0cfcc25-801c-4611-b501-f3d67c5ef347@github.com>

> This is an implementation of the indexOf(char) intrinsic for StringLatin1 (1 byte encoded Strings). It is provided for
> x86 and ARM64. The implementation is greatly inspired by the indexOf(char) intrinsic for StringUTF16. To incorporate it
> I had to make a small change to StringLatin1.java (refactor of functionality to intrisified private method) as well as
> code for C2.  Submitted to: hotspot-compiler-dev and core-libs-dev as this patch contains a change to hotspot and
> java/lang/StringLatin1.java  https://bugs.openjdk.java.net/browse/JDK-8173585
> 
> Details of testing:
> ============
> I have created a jtreg test ?compiler/intrinsics/string/TestStringLatin1IndexOfChar? to cover this new intrinsic. Note
> that, particularly for the x86 implementation of the intrinsic, the code path taken is dependent upon the length of the
> input String. Hence the test has been designed to cover all these cases. In summary they are:
> - A ?short? string of < 16 characters.
> - A SIMD String of 16 ? 31 characters.
> - A AVX2 SIMD String of 32 characters+.
> 
> Hardware used for testing:
> -----------------------------
> 
> - Intel Xeon CPU E5-2680 (JVM did not recognize this as having AVX2 support) ? Intel i7 processor (with AVX2 support).
> - AWS Graviton 2 (ARM 64 processor).
> 
> I also ran; ?run-test-tier1? and ?run-test-tier2? for: x86_64 and aarch64.
> 
> Possible future enhancements:
> ====================
> For the x86 implementation there may be two further improvements we can make in order to improve performance of both
> the StringUTF16 and StringLatin1 indexOf(char) intrinsics:
> 1. Make use of AVX-512 instructions.
> 2. For ?short? Strings (see below), I think it may be possible to modify the existing algorithm to still use SSE SIMD
> instructions instead of a loop.
> Benchmark results:
> ============
> **Without** the new StringLatin1 indexOf(char) intrinsic:
> 
> | Benchmark  | Mode | Cnt | Score | Error | Units |
> | ------------- | ------------- |------------- |------------- |------------- |------------- |
> | IndexOfBenchmark.latin1_mixed_char | avgt | 5 | **26,389.129** | ? 182.581 | ns/op |
> | IndexOfBenchmark.utf16_mixed_char | avgt | 5 | 17,885.383 | ? 435.933  | ns/op |
> 
> 
> **With** the new StringLatin1 indexOf(char) intrinsic:
> 
> | Benchmark  | Mode | Cnt | Score | Error | Units |
> | ------------- | ------------- |------------- |------------- |------------- |------------- |
> | IndexOfBenchmark.latin1_mixed_char | avgt | 5 | **17,875.185** | ? 407.716  | ns/op |
> | IndexOfBenchmark.utf16_mixed_char | avgt | 5 | 18,292.802 | ? 167.306  | ns/op |
> 
> 
> The objective of the patch is to bring the performance of StringLatin1 indexOf(char) in line with StringUTF16
> indexOf(char) for x86 and ARM64. We can see above that this has been achieved. Similar results were obtained when
> running on ARM.

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

  8173585: Intrinsify StringLatin1.indexOf(char)
  
  Rewrite of unit test and newlines added to end of files
  
  Changes to unit test:
  - main test adjusted such that Strings gennerated are much longer (up to
  2048 characters) and of the form: azaza, aazaazaa, aaazaaazaaa, etc with
  'z' being the search character searched for. Multiple instances of the
  search character are included in the String in order to validate that
  the starting offset is correctly handleded. Results are compared to non
  intrinsified version of the code. Longer strings means that the looping
  functionality of the various paths is entered into.
  - Run configurations introduced such that it checks behaviour where use
  of SSE and AVX instructions are restricted.
  - Tier4InvocationThreshold adjusted so as to ensure C2 code iis invoked.
  
  Other changes:
  - newlines added at end of files

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/71/files
  - new: https://git.openjdk.java.net/jdk/pull/71/files/c8cc441e..c8a2849e

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

  Stats: 60 lines in 3 files changed: 26 ins; 6 del; 28 mod
  Patch: https://git.openjdk.java.net/jdk/pull/71.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/71/head:pull/71

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

From github.com+70893615+jasontatton-aws at openjdk.java.net  Fri Oct  2 08:41:01 2020
From: github.com+70893615+jasontatton-aws at openjdk.java.net (Jason Tatton)
Date: Fri, 2 Oct 2020 08:41:01 GMT
Subject: RFR: 8173585: Intrinsify StringLatin1.indexOf(char) [v2]
In-Reply-To: <qoapFFx0wHJf23lRFgOirJacVFNjLIEaMK04qDMq4lE=.1fc3c70d-0fb1-4133-8965-5a517ba39f9e@github.com>
References: <_T0873dC5tfUtGn9r1_Y21JkPKRt-za3MM9hPN2GQKQ=.b865fe53-5417-424f-81b6-1566a330640e@github.com>
 <-DRWR4_f5u6DsSGHAuPnpHrhaG8Una8BXf4zDekQjLM=.469b08b6-a8b2-4a6b-8ab8-1a40810aede0@github.com>
 <qoapFFx0wHJf23lRFgOirJacVFNjLIEaMK04qDMq4lE=.1fc3c70d-0fb1-4133-8965-5a517ba39f9e@github.com>
Message-ID: <ER_bEOfG727YIzqxrRwfCT_igk6EiIztp6iy0-nFbKk=.012aced0-f1df-4a8b-894c-e762b28362b6@github.com>

On Mon, 21 Sep 2020 10:11:28 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> Jason Tatton has updated the pull request with a new target base due to a merge or a rebase. The pull request now
>> contains four commits:
>>  - Merge master
>>  - 8173585: further whitespace changes required by jcheck
>>  - JDK-8173585 - whitespace changes required by jcheck
>>  - JDK-8173585
>
> test/hotspot/jtreg/compiler/intrinsics/string/TestStringLatin1IndexOfChar.java line 24:
> 
>> 22:
>> 23:     public static void main(String[] args) throws Exception {
>> 24:         for (int i = 0; i < 100_0; ++i) {//repeat such that we enter into C2 code...
> 
> The placement of the underscore looks strange to me. I'd expect it to separate thousands (like 1_000) if at all but not
> sure if id use it for one thousand at all as that's really not such a big number that it is hard to read..
> Also, the Tier4InvocationThreshold is 5000 so I'm not sure youre reaching C2?

I have added Tier4InvocationThreshold=200 to the unit test config in order to trigger generation earlier

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

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

From enikitin at openjdk.java.net  Fri Oct  2 08:43:05 2020
From: enikitin at openjdk.java.net (Evgeny Nikitin)
Date: Fri, 2 Oct 2020 08:43:05 GMT
Subject: RFR: 8229186: Improve error messages for TestStringIntrinsics
 failures [v7]
In-Reply-To: <Br6z5yt0kTbZwIQyTI9lz7czaYpjw5vCd5ZCbbrSIcM=.6a8096f1-91ed-4673-bab3-3bfae758ab95@github.com>
References: <Br6z5yt0kTbZwIQyTI9lz7czaYpjw5vCd5ZCbbrSIcM=.6a8096f1-91ed-4673-bab3-3bfae758ab95@github.com>
Message-ID: <tX2jE7MTAEZd4Jpimn1OYnTGsnLpdxxZgVaSDJLPyBE=.f5700d0a-9e7a-4ae0-b670-171db4b0e8b7@github.com>

> pre-Skara RFR thread: [link](https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-May/038416.html)
> 
> Error reporting was improved by writing a C-style escaped string representations for the variables passed to the
> methods being tested. For array comparisons, a dedicated diff-formatter was implemented.
> Sample output for comparing byte arrays (with artificial failure):
>  ----------System.err:(21/1553)----------
>  Result: (false) of 'arrayEqualsB' is not equal to expected (true)
>  Arrays differ starting from [index: 7]:
>  ... 5, 6,   7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, ...
>  ... 5, 6, 125, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, ...
>            ^^^^
>  java.lang.RuntimeException: Result: (false) of 'arrayEqualsB' is not
>  equal to expected (true)
>           at
>  compiler.intrinsics.string.TestStringIntrinsics.invokeAndCheckArrays(TestStringIntrinsics.java:273)
>            at ... stack trace continues - E.N.
>  Sample output for comparing char arrays:
>  ----------System.err:(21/1579)*----------
>  Result: (false) of 'arrayEqualsC' is not equal to expected (true)
>  Arrays differ starting from [index: 7]:
>  ... \\u0005, \\u0006, \\u0007, \\u0008, \\u0009, \\n, ...
>  ... \\u0005, \\u0006,      }, \\u0008, \\u0009, \\n, ...
>                      ^^^^^^^
>  java.lang.RuntimeException: Result: (false) of 'arrayEqualsC' is not
>  equal to expected (true)
>           at
>  compiler.intrinsics.string.TestStringIntrinsics.invokeAndCheckArrays(TestStringIntrinsics.java:280)
>            at
>  ... and so on - E.N.
> 
> testing: open/test/hotspot/jtreg/compiler/intrinsics/string/TestStringIntrinsics.java on linux, windows, macosx.

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

  Fix typos and comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/112/files
  - new: https://git.openjdk.java.net/jdk/pull/112/files/f0b1df89..d792e6d0

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

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

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

From enikitin at openjdk.java.net  Fri Oct  2 08:43:07 2020
From: enikitin at openjdk.java.net (Evgeny Nikitin)
Date: Fri, 2 Oct 2020 08:43:07 GMT
Subject: RFR: 8229186: Improve error messages for TestStringIntrinsics
 failures [v6]
In-Reply-To: <BAPITdSC4Qh9hS0VNQ0lJuiUnrAug3puTLhsWufTdkc=.b924cb4c-8f37-4a3d-8d49-b15b9378c0bc@github.com>
References: <Br6z5yt0kTbZwIQyTI9lz7czaYpjw5vCd5ZCbbrSIcM=.6a8096f1-91ed-4673-bab3-3bfae758ab95@github.com>
 <b3GkK3NPrSYq9sWmkUDW9mZN6kMRoGVLFNBxCMIEsPs=.6119e887-b2e1-4c94-aa52-8200faec288a@github.com>
 <BAPITdSC4Qh9hS0VNQ0lJuiUnrAug3puTLhsWufTdkc=.b924cb4c-8f37-4a3d-8d49-b15b9378c0bc@github.com>
Message-ID: <2eymP8HCQa_-BOJA3Iy-rIiHxtLhQCOzrWDVJSJUrn0=.c7da1aac-e1c6-4e88-9658-b1c9deeaf2db@github.com>

On Thu, 1 Oct 2020 19:39:25 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Evgeny Nikitin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use SB to build TestStringIntrinsics message, avoid type guessing in ArrayDiff
>
> test/lib/jdk/test/lib/format/Format.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2015, 2020, Oracle and/or its affiliates. All rights reserved.
> 
> Shouldn't be just 2020?

Fixed in the d792e6d0ab9, thanks.

> test/lib/jdk/test/lib/format/Diff.java line 30:
> 
>> 28:
>> 29: /**
>> 30:  * An abstraction representing formattabe difference between two or more objects
> 
> typo in 'formattabe'

Also fixed in the d792e6d0ab9, thanks.

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

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

From github.com+70893615+jasontatton-aws at openjdk.java.net  Fri Oct  2 08:47:47 2020
From: github.com+70893615+jasontatton-aws at openjdk.java.net (Jason Tatton)
Date: Fri, 2 Oct 2020 08:47:47 GMT
Subject: RFR: 8173585: Intrinsify StringLatin1.indexOf(char) [v2]
In-Reply-To: <qoapFFx0wHJf23lRFgOirJacVFNjLIEaMK04qDMq4lE=.1fc3c70d-0fb1-4133-8965-5a517ba39f9e@github.com>
References: <_T0873dC5tfUtGn9r1_Y21JkPKRt-za3MM9hPN2GQKQ=.b865fe53-5417-424f-81b6-1566a330640e@github.com>
 <-DRWR4_f5u6DsSGHAuPnpHrhaG8Una8BXf4zDekQjLM=.469b08b6-a8b2-4a6b-8ab8-1a40810aede0@github.com>
 <qoapFFx0wHJf23lRFgOirJacVFNjLIEaMK04qDMq4lE=.1fc3c70d-0fb1-4133-8965-5a517ba39f9e@github.com>
Message-ID: <ek__ufm173KBifOKT3E9NbWnO52ln-Gw2H4AtARIBno=.0eff465e-63db-4644-acb1-b6d6645ecfed@github.com>

On Tue, 22 Sep 2020 15:19:37 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> Jason Tatton has updated the pull request with a new target base due to a merge or a rebase. The pull request now
>> contains four commits:
>>  - Merge master
>>  - 8173585: further whitespace changes required by jcheck
>>  - JDK-8173585 - whitespace changes required by jcheck
>>  - JDK-8173585
>
> Hi Jason,
> 
> thanks for bringing String.indexOf() for latin strings up to date with the Unicode version.
> 
> Your changes look good except a few minor issues I've commented on right in the code.
> 
> I'd only like to ask you if you could possibly improve your test a little bit. As far as I understand, your search text
> is a consecutive sequence of "abc" characters, so you'll always find the character your searching for within the next
> three characters of the source text. This won't exercise the loops of your intrinsic. Maybe you can also add some test
> versions where the search character will be found beyond the first 32/64 characters after "fromIndex"?

@simonis Thank you for the corrections, I have ammended them in the latest comit as follows:

Changes to unit test:
- main test adjusted such that Strings gennerated are much longer (up to 2048 characters) and of the form: `azaza`,
  `aazaazaa`, `aaazaaazaaa`, etc with `'z'` being the search character searched for. Multiple instances of the search
  character are included in the String in order to validate that the starting offset is correctly handleded. Results are
  compared to non intrinsified version of the code. Longer strings means that the looping functionality of the various
  paths is entered into.
- Run configurations introduced such that it checks behaviour where use of SSE and AVX instructions are restricted.
- Tier4InvocationThreshold adjusted so as to ensure C2 code iis invoked.

Other changes:
- newlines added at end of files

@vnkozlov here are the performance numbers as requested. I have included performance of the UTF16 version of the
intrinsic for reference:

| UseAVX= | UseSSE= | Benchmark                         | Mode | Cnt | Score       | Error       | Units |
|---------|---------|-----------------------------------|------|-----|-------------|-------------|-------|
|         | 0       | IndexOfBenchmark.latin1_long_char | avgt | 5   | **447,493.398** | ? 4,666.386 | ns/op |
| 0       |         | IndexOfBenchmark.latin1_long_char | avgt | 5   | **104,735.941** | ? 2,484.403 | ns/op |
| 1       |         | IndexOfBenchmark.latin1_long_char | avgt | 5   | **104,342.844** | ? 2,656.343 | ns/op |
| 2       |         | IndexOfBenchmark.latin1_long_char | avgt | 5   | **61,000.418**  | ? 1,543.951 | ns/op |
| 3       |         | IndexOfBenchmark.latin1_long_char | avgt | 5   | **60,607.988**  | ? 1,466.354 | ns/op |
|         | 0       | IndexOfBenchmark.utf16_long_char  | avgt | 5   | 672,475.302 | ? 4,998.596 | ns/op |
| 0       |         | IndexOfBenchmark.utf16_long_char  | avgt | 5   | 175,521.654 | ? 7,549.094 | ns/op |
| 1       |         | IndexOfBenchmark.utf16_long_char  | avgt | 5   | 172,514.981 | ? 3,561.040 | ns/op |
| 2       |         | IndexOfBenchmark.utf16_long_char  | avgt | 5   | 120,725.748 | ? 2,004.400 | ns/op |
| 3       |         | IndexOfBenchmark.utf16_long_char  | avgt | 5   | 120,664.623 | ? 1,988.419 | ns/op |

I think the results are as expected, we see improvements in performance as the range of SSE and AVX instructions which
can be used is expanded upon. Note that no improvement is observed with UseAVX=3 because there is no AVX-512 code in
these intrinsics.

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

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

From enikitin at openjdk.java.net  Fri Oct  2 08:50:06 2020
From: enikitin at openjdk.java.net (Evgeny Nikitin)
Date: Fri, 2 Oct 2020 08:50:06 GMT
Subject: RFR: 8229186: Improve error messages for TestStringIntrinsics
 failures [v8]
In-Reply-To: <Br6z5yt0kTbZwIQyTI9lz7czaYpjw5vCd5ZCbbrSIcM=.6a8096f1-91ed-4673-bab3-3bfae758ab95@github.com>
References: <Br6z5yt0kTbZwIQyTI9lz7czaYpjw5vCd5ZCbbrSIcM=.6a8096f1-91ed-4673-bab3-3bfae758ab95@github.com>
Message-ID: <hzpKNVfoRMK3EWzNuKggPrNcC_jv42UBw5_NDQCYw9g=.4d68041b-2988-4e85-9d8d-7f094eee8041@github.com>

> pre-Skara RFR thread: [link](https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-May/038416.html)
> 
> Error reporting was improved by writing a C-style escaped string representations for the variables passed to the
> methods being tested. For array comparisons, a dedicated diff-formatter was implemented.
> Sample output for comparing byte arrays (with artificial failure):
>  ----------System.err:(21/1553)----------
>  Result: (false) of 'arrayEqualsB' is not equal to expected (true)
>  Arrays differ starting from [index: 7]:
>  ... 5, 6,   7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, ...
>  ... 5, 6, 125, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, ...
>            ^^^^
>  java.lang.RuntimeException: Result: (false) of 'arrayEqualsB' is not
>  equal to expected (true)
>           at
>  compiler.intrinsics.string.TestStringIntrinsics.invokeAndCheckArrays(TestStringIntrinsics.java:273)
>            at ... stack trace continues - E.N.
>  Sample output for comparing char arrays:
>  ----------System.err:(21/1579)*----------
>  Result: (false) of 'arrayEqualsC' is not equal to expected (true)
>  Arrays differ starting from [index: 7]:
>  ... \\u0005, \\u0006, \\u0007, \\u0008, \\u0009, \\n, ...
>  ... \\u0005, \\u0006,      }, \\u0008, \\u0009, \\n, ...
>                      ^^^^^^^
>  java.lang.RuntimeException: Result: (false) of 'arrayEqualsC' is not
>  equal to expected (true)
>           at
>  compiler.intrinsics.string.TestStringIntrinsics.invokeAndCheckArrays(TestStringIntrinsics.java:280)
>            at
>  ... and so on - E.N.
> 
> testing: open/test/hotspot/jtreg/compiler/intrinsics/string/TestStringIntrinsics.java on linux, windows, macosx.

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

  Make ArrayDiff.Defaults a generic Diff.Defaults

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/112/files
  - new: https://git.openjdk.java.net/jdk/pull/112/files/d792e6d0..81f7a9d9

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

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

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

From enikitin at openjdk.java.net  Fri Oct  2 08:50:07 2020
From: enikitin at openjdk.java.net (Evgeny Nikitin)
Date: Fri, 2 Oct 2020 08:50:07 GMT
Subject: RFR: 8229186: Improve error messages for TestStringIntrinsics
 failures [v6]
In-Reply-To: <BAPITdSC4Qh9hS0VNQ0lJuiUnrAug3puTLhsWufTdkc=.b924cb4c-8f37-4a3d-8d49-b15b9378c0bc@github.com>
References: <Br6z5yt0kTbZwIQyTI9lz7czaYpjw5vCd5ZCbbrSIcM=.6a8096f1-91ed-4673-bab3-3bfae758ab95@github.com>
 <b3GkK3NPrSYq9sWmkUDW9mZN6kMRoGVLFNBxCMIEsPs=.6119e887-b2e1-4c94-aa52-8200faec288a@github.com>
 <BAPITdSC4Qh9hS0VNQ0lJuiUnrAug3puTLhsWufTdkc=.b924cb4c-8f37-4a3d-8d49-b15b9378c0bc@github.com>
Message-ID: <7ClZi2nnkEYbwdpe8DfphsQS_wFssq_vfKoFi80U5QE=.8f724488-5788-4960-877a-ecb739ae20b6@github.com>

On Thu, 1 Oct 2020 19:43:09 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Evgeny Nikitin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use SB to build TestStringIntrinsics message, avoid type guessing in ArrayDiff
>
> test/lib/jdk/test/lib/format/ArrayDiff.java line 81:
> 
>> 79:      * Default limits for the formatter
>> 80:      */
>> 81:     public static class Defaults {
> 
> Does it make sense to move them into Diff? Seems like very generic formatter properties to me.

I can imagine different defaults for different diff formatters, but they probably would be very similar. Let's try your
suggestion, the 81f7a9d9b88.

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

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

From alanb at openjdk.java.net  Fri Oct  2 09:37:38 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 2 Oct 2020 09:37:38 GMT
Subject: RFR: 8204256: improve jlink error message to report unsupported
 class file format [v2]
In-Reply-To: <UOeX1EtrXyzdkhFeBx-prDjTGZwWh1my4NSODNZQwYg=.ef69bb7d-d883-47e3-b080-3dbabc45f104@github.com>
References: <fc0WYkvegw3_1RBfXVVy7Vs6HcX7b9UIq7fZ2kK4cCY=.218de7d9-7abf-4eec-af30-d2926464349c@github.com>
 <qGVlFtUbSi5Uo7ZVOhgIFjaBYjpD-5yo7_nPWOcbWQA=.81eefc43-09be-4c89-a018-d0de0f9d1292@github.com>
 <UOeX1EtrXyzdkhFeBx-prDjTGZwWh1my4NSODNZQwYg=.ef69bb7d-d883-47e3-b080-3dbabc45f104@github.com>
Message-ID: <nJbYVfIPDYdgsMc-z11yd_EQXSUjUfzGyDTGkNgL4w8=.6da132ea-f04e-49e3-a072-4572e4f414c5@github.com>

On Thu, 1 Oct 2020 22:46:43 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Ian Graves 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.
>
> Given that linking with JMODs of an unsupported class file version is rare case,
> it's not a bad choice to go with this simplest solution printing the stack trace.

What if we removed the handling of specific exceptions from L278-L285 so that the special handling is limited to
BadArgs? If anything other than BadArgs is throw then it can print the exception to log output along with the cause (if
not null). No objection. That might avoid the tool emitting a "scary" stack trace when an error occurs.

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

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

From michaelm at openjdk.java.net  Fri Oct  2 11:07:59 2020
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Fri, 2 Oct 2020 11:07:59 GMT
Subject: RFR: 8245194: Unix domain socket channel implementation [v12]
In-Reply-To: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
References: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
Message-ID: <JJ4LdK57Ydn6L4KN4NWX-LEKvWPHu0DJZnwK0HE2OjU=.033af211-900d-4e8c-aa90-f327d79b4f1c@github.com>

> Continuing this review as a PR on github with the comments below incorporated. I expect there will be a few more
> iterations before integrating.
> On 06/09/2020 19:47, Alan Bateman wrote:
>> On 26/08/2020 15:24, Michael McMahon wrote:
>>>
>>> As I mentioned the other day, I wasn't able to use the suggested method on Windows which returns an absolute path. So,
>>> I added a method to WindowsPath which returns the path in the expected UTF-8 encoding as a byte[]. Let me know what you
>>> think of that.
>>>
>>> There is a fair bit of other refactoring and simplification done also. Next version is at:
>>>
>>> http://cr.openjdk.java.net/~michaelm/8245194/impl.webrev/webrev.9/
>>>
>> Adding a method to WindowsPath to encode the path using UTF-8 is okay but I don't think we should be caching it as the
>> encoding for sun_path is an outlier on Windows. I'm also a bit dubious about encoding a relative path when the resolved
>> path (before encoding) is > 247 chars. The documentation on the MS site isn't very completely and I think there are a
>> number points that require clarification to fully understand how this will work with relative, directly relative and
>> drive relative paths.
>>
> 
> Maybe it would be better to just use the path returned from toString() and do the conversion to UTF-8 externally. That
> would leave WindowsPath unchanged.
>> In the same area, the new PathUtil is a bit inconsistent with the existing provider code. One suggestion is to add a
>> method to AbstractFileSystemProvider instead. That is the base class the platform providers and would be a better place
>> to get the file path in bytes.
>>
> 
> Okay, I gave the method a name that is specific to Unix domain sockets because this UTF-8 strangeness is not likely to
> be useful by other components.
>> One other comment on the changes to the file system provider it should be okay to change UnixUserPrinipals ad its
>> fromUid and fromGid method to be public. This would mean that the patch shouldn't need to add UnixUserGroup (the main
>> issue is that class is that it means we end up with two classes with static factory methods doing the same thing).
> 
> Okay, that does simplify it a bit.
> 
> Thanks,
> Michael.
> 
>> -Alan.
>>
>>
>>
>>
>>
>>

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

  unixdomainchannels:
  (1) rename UnixDomainHelper to UnixDomainSocketsUtil
  (2) remove hardcoded /tmp and /var/tmp paths from UnixDomainSocketsUtil
  (3) replace (2) with documented system/networking properties
  (4) Small update to UnixDomainSocketAddress API
  (5) CSR for (3) and (4) submitted at JDK-8253930
  (6) Update build to generate net.properties from shared net.properties.common
      plus platform specific additions.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/52/files
  - new: https://git.openjdk.java.net/jdk/pull/52/files/c40d2059..275e0928

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

  Stats: 357 lines in 10 files changed: 194 ins; 154 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/52.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/52/head:pull/52

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

From michaelm at openjdk.java.net  Fri Oct  2 11:28:49 2020
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Fri, 2 Oct 2020 11:28:49 GMT
Subject: RFR: 8245194: Unix domain socket channel implementation [v13]
In-Reply-To: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
References: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
Message-ID: <aBHqAWehNAtKiaFFhz9cnd_oLXsZuyqa3xaiT_Fi3F0=.cc48c0a7-de65-46f1-94f3-7aa91fe25817@github.com>

> Continuing this review as a PR on github with the comments below incorporated. I expect there will be a few more
> iterations before integrating.
> On 06/09/2020 19:47, Alan Bateman wrote:
>> On 26/08/2020 15:24, Michael McMahon wrote:
>>>
>>> As I mentioned the other day, I wasn't able to use the suggested method on Windows which returns an absolute path. So,
>>> I added a method to WindowsPath which returns the path in the expected UTF-8 encoding as a byte[]. Let me know what you
>>> think of that.
>>>
>>> There is a fair bit of other refactoring and simplification done also. Next version is at:
>>>
>>> http://cr.openjdk.java.net/~michaelm/8245194/impl.webrev/webrev.9/
>>>
>> Adding a method to WindowsPath to encode the path using UTF-8 is okay but I don't think we should be caching it as the
>> encoding for sun_path is an outlier on Windows. I'm also a bit dubious about encoding a relative path when the resolved
>> path (before encoding) is > 247 chars. The documentation on the MS site isn't very completely and I think there are a
>> number points that require clarification to fully understand how this will work with relative, directly relative and
>> drive relative paths.
>>
> 
> Maybe it would be better to just use the path returned from toString() and do the conversion to UTF-8 externally. That
> would leave WindowsPath unchanged.
>> In the same area, the new PathUtil is a bit inconsistent with the existing provider code. One suggestion is to add a
>> method to AbstractFileSystemProvider instead. That is the base class the platform providers and would be a better place
>> to get the file path in bytes.
>>
> 
> Okay, I gave the method a name that is specific to Unix domain sockets because this UTF-8 strangeness is not likely to
> be useful by other components.
>> One other comment on the changes to the file system provider it should be okay to change UnixUserPrinipals ad its
>> fromUid and fromGid method to be public. This would mean that the patch shouldn't need to add UnixUserGroup (the main
>> issue is that class is that it means we end up with two classes with static factory methods doing the same thing).
> 
> Okay, that does simplify it a bit.
> 
> Thanks,
> Michael.
> 
>> -Alan.
>>
>>
>>
>>
>>
>>

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

  unixdomainchannels: error in the last commit in make/modules/java.base/Copy.gmk

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/52/files
  - new: https://git.openjdk.java.net/jdk/pull/52/files/275e0928..dc70cd6e

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

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

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

From erikj at openjdk.java.net  Fri Oct  2 13:05:41 2020
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Fri, 2 Oct 2020 13:05:41 GMT
Subject: RFR: 8245194: Unix domain socket channel implementation [v13]
In-Reply-To: <aBHqAWehNAtKiaFFhz9cnd_oLXsZuyqa3xaiT_Fi3F0=.cc48c0a7-de65-46f1-94f3-7aa91fe25817@github.com>
References: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
 <aBHqAWehNAtKiaFFhz9cnd_oLXsZuyqa3xaiT_Fi3F0=.cc48c0a7-de65-46f1-94f3-7aa91fe25817@github.com>
Message-ID: <9xiq9e72dtTcgcf4OvNEVUenyY_nBoZOqdfrEJi-KsI=.fb41e8ad-7ad5-47a7-b10d-3176ea3756e8@github.com>

On Fri, 2 Oct 2020 11:28:49 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Continuing this review as a PR on github with the comments below incorporated. I expect there will be a few more
>> iterations before integrating.
>> On 06/09/2020 19:47, Alan Bateman wrote:
>>> On 26/08/2020 15:24, Michael McMahon wrote:
>>>>
>>>> As I mentioned the other day, I wasn't able to use the suggested method on Windows which returns an absolute path. So,
>>>> I added a method to WindowsPath which returns the path in the expected UTF-8 encoding as a byte[]. Let me know what you
>>>> think of that.
>>>>
>>>> There is a fair bit of other refactoring and simplification done also. Next version is at:
>>>>
>>>> http://cr.openjdk.java.net/~michaelm/8245194/impl.webrev/webrev.9/
>>>>
>>> Adding a method to WindowsPath to encode the path using UTF-8 is okay but I don't think we should be caching it as the
>>> encoding for sun_path is an outlier on Windows. I'm also a bit dubious about encoding a relative path when the resolved
>>> path (before encoding) is > 247 chars. The documentation on the MS site isn't very completely and I think there are a
>>> number points that require clarification to fully understand how this will work with relative, directly relative and
>>> drive relative paths.
>>>
>> 
>> Maybe it would be better to just use the path returned from toString() and do the conversion to UTF-8 externally. That
>> would leave WindowsPath unchanged.
>>> In the same area, the new PathUtil is a bit inconsistent with the existing provider code. One suggestion is to add a
>>> method to AbstractFileSystemProvider instead. That is the base class the platform providers and would be a better place
>>> to get the file path in bytes.
>>>
>> 
>> Okay, I gave the method a name that is specific to Unix domain sockets because this UTF-8 strangeness is not likely to
>> be useful by other components.
>>> One other comment on the changes to the file system provider it should be okay to change UnixUserPrinipals ad its
>>> fromUid and fromGid method to be public. This would mean that the patch shouldn't need to add UnixUserGroup (the main
>>> issue is that class is that it means we end up with two classes with static factory methods doing the same thing).
>> 
>> Okay, that does simplify it a bit.
>> 
>> Thanks,
>> Michael.
>> 
>>> -Alan.
>>>
>>>
>>>
>>>
>>>
>>>
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   unixdomainchannels: error in the last commit in make/modules/java.base/Copy.gmk

make/modules/java.base/Copy.gmk line 190:

> 188: NET_PROPERTIES_SRC +=
> $(TOPDIR)/src/java.base/$(OPENJDK_TARGET_OS_TYPE)/conf/net.properties.$(OPENJDK_TARGET_OS_TYPE) 189:
> 190: NET_PROPERTIES_SRC_LIST := $(NET_PROPERTIES_SRC)

This variable seems unnecessary as it's just a copy of NET_PROPERTIES_SRC. I would suggest just adding an S for plural
to the original variable.

make/modules/java.base/Copy.gmk line 195:

> 193: 	$(call MakeTargetDir)
> 194: 	$(RM) $@ $@.tmp
> 195: 	$(foreach f,$(NET_PROPERTIES_SRC_LIST),$(CAT) $(f) >> $@.tmp;)

This can be simplified. Cat takes multiple files as input, so no need for 'foreach'. Also no need to go via a temp
file. We have make configured to delete targets if a recipe fails, so the tmp dance isn't needed. (I know we still have
this pattern all over the place, but we are trying to quit the practice)

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

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

From michaelm at openjdk.java.net  Fri Oct  2 13:19:40 2020
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Fri, 2 Oct 2020 13:19:40 GMT
Subject: RFR: 8245194: Unix domain socket channel implementation [v13]
In-Reply-To: <9xiq9e72dtTcgcf4OvNEVUenyY_nBoZOqdfrEJi-KsI=.fb41e8ad-7ad5-47a7-b10d-3176ea3756e8@github.com>
References: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
 <aBHqAWehNAtKiaFFhz9cnd_oLXsZuyqa3xaiT_Fi3F0=.cc48c0a7-de65-46f1-94f3-7aa91fe25817@github.com>
 <9xiq9e72dtTcgcf4OvNEVUenyY_nBoZOqdfrEJi-KsI=.fb41e8ad-7ad5-47a7-b10d-3176ea3756e8@github.com>
Message-ID: <YtR77VD8mHamrlKl9EQPn7XpWAcGUffub8nXTSA_GWI=.2083690e-2ce1-4c35-b053-c5f4501a9841@github.com>

On Fri, 2 Oct 2020 12:58:02 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   unixdomainchannels: error in the last commit in make/modules/java.base/Copy.gmk
>
> make/modules/java.base/Copy.gmk line 195:
> 
>> 193: 	$(call MakeTargetDir)
>> 194: 	$(RM) $@ $@.tmp
>> 195: 	$(foreach f,$(NET_PROPERTIES_SRC_LIST),$(CAT) $(f) >> $@.tmp;)
> 
> This can be simplified. Cat takes multiple files as input, so no need for 'foreach'. Also no need to go via a temp
> file. We have make configured to delete targets if a recipe fails, so the tmp dance isn't needed. (I know we still have
> this pattern all over the place, but we are trying to quit the practice)

Good points. I will update as suggested. Thanks.

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

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

From avoitylov at openjdk.java.net  Fri Oct  2 13:55:18 2020
From: avoitylov at openjdk.java.net (Aleksei Voitylov)
Date: Fri, 2 Oct 2020 13:55:18 GMT
Subject: RFR: JDK-8247589: Implementation of Alpine Linux/x64 Port [v3]
In-Reply-To: <bjBywiEZ6tEHsG5xi2185_J-tduz4ezP8r6wVKbX1lY=.f6574f6f-be11-4d7c-8ebc-50b24ad8015d@github.com>
References: <bjBywiEZ6tEHsG5xi2185_J-tduz4ezP8r6wVKbX1lY=.f6574f6f-be11-4d7c-8ebc-50b24ad8015d@github.com>
Message-ID: <QO-Vk-TfNz_xAoJkgbUUxZacmJgX6tVAjfu63E4MGLQ=.a3975b8b-4c46-42fd-bde7-0d5b2c7e3e22@github.com>

> continuing the review thread from here https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-September/068546.html
> 
>> The download side of using JNI in these tests is that it complicates the
>> setup a bit for those that run jtreg directly and/or just build the JDK
>> and not the test libraries. You could reduce this burden a bit by
>> limiting the load library/isMusl check to Linux only, meaning isMusl
>> would not be called on other platforms.
>>
>> The alternative you suggest above might indeed be better. I assume you
>> don't mean splitting the tests but rather just adding a second @test
>> description so that the vm.musl case runs the test with a system
>> property that allows the test know the expected load library path behavior.
> 
> I have updated the PR to split the two tests in multiple @test s.
> 
>> The updated comment in java_md.c in this looks good. A minor comment on
>> Platform.isBusybox is Files.isSymbolicLink returning true implies that
>> the link exists so no need to check for exists too. Also the
>> if-then-else style for the new class in ProcessBuilder/Basic.java is
>> inconsistent with the rest of the test so it stands out.
> 
> Thank you, these changes are done in the updated PR.
> 
>> Given the repo transition this weekend then I assume you'll create a PR
>> for the final review at least. Also I see JEP 386 hasn't been targeted
>> yet but I assume Boris, as owner, will propose-to-target and wait for it
>> to be targeted before it is integrated.
> 
> Yes. How can this be best accomplished with the new git workflow?
> - we can continue the review process till the end and I will request the integration to happen only after the JEP is
>   targeted. I guess this step is now done by typing "slash integrate" in a comment.
> - we can pause the review process now until the JEP is targeted.
> 
> In the first case I'm kindly asking the Reviewers who already chimed in on that to re-confirm the review here.

Aleksei Voitylov has updated the pull request with a new target base 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 'JDK-8247589' of https://github.com/voitylov/jdk into JDK-8247589
 - JDK-8247589: Implementation of Alpine Linux/x64 Port
 - JDK-8247589: Implementation of Alpine Linux/x64 Port
 - JDK-8247589: Implementation of Alpine Linux/x64 Port
 - JDK-8247589: Implementation of Alpine Linux/x64 Port

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/49/files
  - new: https://git.openjdk.java.net/jdk/pull/49/files/d5994cb5..705b8555

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

  Stats: 73505 lines in 3006 files changed: 26172 ins; 37386 del; 9947 mod
  Patch: https://git.openjdk.java.net/jdk/pull/49.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/49/head:pull/49

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

From vsharma at openjdk.java.net  Fri Oct  2 14:53:41 2020
From: vsharma at openjdk.java.net (Vipin Sharma)
Date: Fri, 2 Oct 2020 14:53:41 GMT
Subject: Integrated: 8252537: Updated @exception with @throws
In-Reply-To: <jWf2YS8e4ZhTRfuFPquC4jxUS-urxG4ZDQ2B5FM86rQ=.a0467b19-1e45-4fad-abd6-256f720ef5b7@github.com>
References: <jWf2YS8e4ZhTRfuFPquC4jxUS-urxG4ZDQ2B5FM86rQ=.a0467b19-1e45-4fad-abd6-256f720ef5b7@github.com>
Message-ID: <bEHH55IJ3Yu3hJhLXyddRclpdjmJxfjoXJHhkgREQ6c=.d4fb4eb0-22a9-4e7d-b466-813d4f3e7a02@github.com>

On Wed, 9 Sep 2020 19:29:30 GMT, Vipin Sharma <vsharma at openjdk.org> wrote:

> Updated @exception with @throws for core-libs, it fixes all open sub-tasks of JDK-8252536.
> 
> Open Subtasks part of this fix are:
> 1. JDK-8252537
> 2. JDK-8252539
> 3. JDK-8252540
> 4. JDK-8252541
> 
> Previous conversation on this:
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-September/068540.html

This pull request has now been integrated.

Changeset: dffe9db2
Author:    Vipin Sharma <vsharma at openjdk.org>
Committer: Lance Andersen <lancea at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/dffe9db2
Stats:     2109 lines in 86 files changed: 0 ins; 0 del; 2109 mod

8252537: Updated @exception with @throws
8252536: Replace @exception with @throws for core-libs
8252539: Replace @exception with @throws java.rmi.activation package
8252540: Replace @exception with @throws java.rmi.registry package
8252541: Replace @exception with @throws java.rmi.server package

Reviewed-by: rriggs, sspitsyn, lancea

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

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

From Roger.Riggs at oracle.com  Fri Oct  2 15:24:31 2020
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Fri, 2 Oct 2020 11:24:31 -0400
Subject: 8251989: Unified Hex formatting and parsing utility
In-Reply-To: <2d6a44f3-a307-beba-deb7-48b26f7e1afa@oracle.com>
References: <mailman.23.1598529301.11454.core-libs-dev@openjdk.java.net>
 <1BAC4282-314D-4009-B2F7-28B6FDACBA28@oracle.com>
 <465e58eb-a18e-5aa9-42ad-be5f41c67c8f@oracle.com>
 <fb2d1f56-7453-1330-f18e-8dc887a7812b@oracle.com>
 <2d6a44f3-a307-beba-deb7-48b26f7e1afa@oracle.com>
Message-ID: <506165b1-ec19-240f-d7c8-ef7055efa955@oracle.com>

Hi Brian,

The correction on the signature is updated in the PR.
 ?? https://github.com/openjdk/jdk/pull/482

Thanks, Roger


On 9/28/20 1:48 PM, Brian Goetz wrote:
> Minor nit:
>
> ??? Appendable foo(Appendable bar)
>
> should be
>
> ??? <A extend Appendable> A foo(A bar)
>
> That way, if you say
>
> ??? hex.formatHex(aStringBuilder, bytes)
> ?????? .foo()
>
> where foo() is a method on StringBuilder but not on Appendable, it 
> will still work as expected.
>
> On 9/28/2020 11:32 AM, Roger Riggs wrote:
>> After some reflection on the comments, suggestions, and other advice 
>> offered
>> the Hex format API has undergone a significant rewrite.
>>
>> The improvements include:
>>
>> ?- Merged format and parse classes into a single class HexFormat that 
>> holds parameters and has methods for all conversions
>> ?- Simplified static factories and added builder methods to create 
>> HexFormat copies with modified parameters.
>> ?- Consistent naming of methods for conversion of byte arrays to 
>> formatted strings and back: formatHex and parseHex
>> ?- Consistent naming of methods for conversion of primitive types: 
>> toHexDigits... and fromHexDigits...
>> ?- Prefix and suffixes now apply to each formatted value, not the 
>> string as a whole
>> ?- Using java.util.Appendable as a target for buffered conversions so 
>> output to Writers and PrintStreams
>> ?? like System.out are supported in addition to StringBuilder. 
>> (IOExceptions are converted to unchecked exceptions)
>>
>> The HexFormat javadoc is at:
>> http://cr.openjdk.java.net/~rriggs/8251989-hex-formatter/java.base/java/util/HexFormat.html 
>>
>>
>> Thanks to all that commented and made suggestions on core-libs-dev 
>> and privately.
>>
>> Please review and comment.? When the API has settled, I'll turn it 
>> into a PR and CSR.
>>
>> Thanks, Roger
>>
>>
>>
>>
>>
>


From rriggs at openjdk.java.net  Fri Oct  2 15:24:51 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 2 Oct 2020 15:24:51 GMT
Subject: RFR: 8251989: Hex formatting and parsing utility
Message-ID: <HSEn47GMS1K3g57mrTZeQk-WZHl3pKGHpX_OOf8VnsU=.740863c2-f9e4-43c4-b500-614aab4078b1@github.com>

java.util.HexFormat utility:

 - Format and parse hexadecimal strings, with parameters for delimiter, prefix, suffix and upper/lowercase
 - Static factories and builder methods to create HexFormat copies with modified parameters.
 - Consistent naming of methods for conversion of byte arrays to formatted strings and back: formatHex and parseHex
 - Consistent naming of methods for conversion of primitive types: toHexDigits... and fromHexDigits...
 - Prefix and suffixes now apply to each formatted value, not the string as a whole
 - Using java.util.Appendable as a target for buffered conversions so output to Writers and PrintStreams
   like System.out are supported in addition to StringBuilder. (IOExceptions are converted to unchecked exceptions)
 - Immutable and thread safe, a "value-based" class

See the [HexFormat
javadoc](http://cr.openjdk.java.net/~rriggs/8251989-hex-formatter/java.base/java/util/HexFormat.html) for details.

Review comments and suggestions welcome.

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

Commit messages:
 - 8251989: Hex formatting and parsing utility

Changes: https://git.openjdk.java.net/jdk/pull/482/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=482&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8251989
  Stats: 1665 lines in 12 files changed: 1503 ins; 144 del; 18 mod
  Patch: https://git.openjdk.java.net/jdk/pull/482.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/482/head:pull/482

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

From avoitylov at openjdk.java.net  Fri Oct  2 15:39:09 2020
From: avoitylov at openjdk.java.net (Aleksei Voitylov)
Date: Fri, 2 Oct 2020 15:39:09 GMT
Subject: RFR: JDK-8247589: Implementation of Alpine Linux/x64 Port [v4]
In-Reply-To: <bjBywiEZ6tEHsG5xi2185_J-tduz4ezP8r6wVKbX1lY=.f6574f6f-be11-4d7c-8ebc-50b24ad8015d@github.com>
References: <bjBywiEZ6tEHsG5xi2185_J-tduz4ezP8r6wVKbX1lY=.f6574f6f-be11-4d7c-8ebc-50b24ad8015d@github.com>
Message-ID: <zbd1NoINSF9tougbINghMsT_1_hbwndAy_9h3sVLre8=.627c59e1-7036-4e18-9f94-fd3981ad968a@github.com>

> continuing the review thread from here https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-September/068546.html
> 
>> The download side of using JNI in these tests is that it complicates the
>> setup a bit for those that run jtreg directly and/or just build the JDK
>> and not the test libraries. You could reduce this burden a bit by
>> limiting the load library/isMusl check to Linux only, meaning isMusl
>> would not be called on other platforms.
>>
>> The alternative you suggest above might indeed be better. I assume you
>> don't mean splitting the tests but rather just adding a second @test
>> description so that the vm.musl case runs the test with a system
>> property that allows the test know the expected load library path behavior.
> 
> I have updated the PR to split the two tests in multiple @test s.
> 
>> The updated comment in java_md.c in this looks good. A minor comment on
>> Platform.isBusybox is Files.isSymbolicLink returning true implies that
>> the link exists so no need to check for exists too. Also the
>> if-then-else style for the new class in ProcessBuilder/Basic.java is
>> inconsistent with the rest of the test so it stands out.
> 
> Thank you, these changes are done in the updated PR.
> 
>> Given the repo transition this weekend then I assume you'll create a PR
>> for the final review at least. Also I see JEP 386 hasn't been targeted
>> yet but I assume Boris, as owner, will propose-to-target and wait for it
>> to be targeted before it is integrated.
> 
> Yes. How can this be best accomplished with the new git workflow?
> - we can continue the review process till the end and I will request the integration to happen only after the JEP is
>   targeted. I guess this step is now done by typing "slash integrate" in a comment.
> - we can pause the review process now until the JEP is targeted.
> 
> In the first case I'm kindly asking the Reviewers who already chimed in on that to re-confirm the review here.

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

  test2

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/49/files
  - new: https://git.openjdk.java.net/jdk/pull/49/files/705b8555..5feda5ff

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

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

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

From iignatyev at openjdk.java.net  Fri Oct  2 15:41:41 2020
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Fri, 2 Oct 2020 15:41:41 GMT
Subject: RFR: 8253750: use build-stable default seed for
 Utils.RANDOM_GENERATOR
In-Reply-To: <RQa3EOXeDAni1G-mu_jM-I9mosypb0gnuLUmFCtGhGo=.92a4f06b-60df-49b6-b6e3-bcf11e7530ab@github.com>
References: <RQa3EOXeDAni1G-mu_jM-I9mosypb0gnuLUmFCtGhGo=.92a4f06b-60df-49b6-b6e3-bcf11e7530ab@github.com>
Message-ID: <rjuoGCzkLKiqcIG5DfoliW32WWpFvoJlvr58r9YE4Yo=.657c9073-0352-40ed-a653-ff4c2bdd24c2@github.com>

On Tue, 29 Sep 2020 00:06:02 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review the patch which updates `jdk.test.lib.Utils` to use md5 hash-sum of `java.vm.version` property
> as default seed for `Utils.RANDOM_GENERATOR`?
> from JBS:
>> using the same seed for all runs of a build will make it possible (easier) to compare results from different test runs
>> (e.g. on different platforms, w/ different flags) and consequently will make test results analysis easier.
> 
> the patch also updates `RandomGeneratorTest` test, so it expects now that the same values are generated if no seed is
> provided.
> testing: ? tier1

ping?

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

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

From avoitylov at openjdk.java.net  Fri Oct  2 15:45:56 2020
From: avoitylov at openjdk.java.net (Aleksei Voitylov)
Date: Fri, 2 Oct 2020 15:45:56 GMT
Subject: RFR: JDK-8247589: Implementation of Alpine Linux/x64 Port [v5]
In-Reply-To: <bjBywiEZ6tEHsG5xi2185_J-tduz4ezP8r6wVKbX1lY=.f6574f6f-be11-4d7c-8ebc-50b24ad8015d@github.com>
References: <bjBywiEZ6tEHsG5xi2185_J-tduz4ezP8r6wVKbX1lY=.f6574f6f-be11-4d7c-8ebc-50b24ad8015d@github.com>
Message-ID: <BQe_x7nqP_NOWC5UAi2stqKPMv0mZZyieHIRQqZRjn0=.65fbff6a-5ba1-46c0-b94b-dcddb8a8486e@github.com>

> continuing the review thread from here https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-September/068546.html
> 
>> The download side of using JNI in these tests is that it complicates the
>> setup a bit for those that run jtreg directly and/or just build the JDK
>> and not the test libraries. You could reduce this burden a bit by
>> limiting the load library/isMusl check to Linux only, meaning isMusl
>> would not be called on other platforms.
>>
>> The alternative you suggest above might indeed be better. I assume you
>> don't mean splitting the tests but rather just adding a second @test
>> description so that the vm.musl case runs the test with a system
>> property that allows the test know the expected load library path behavior.
> 
> I have updated the PR to split the two tests in multiple @test s.
> 
>> The updated comment in java_md.c in this looks good. A minor comment on
>> Platform.isBusybox is Files.isSymbolicLink returning true implies that
>> the link exists so no need to check for exists too. Also the
>> if-then-else style for the new class in ProcessBuilder/Basic.java is
>> inconsistent with the rest of the test so it stands out.
> 
> Thank you, these changes are done in the updated PR.
> 
>> Given the repo transition this weekend then I assume you'll create a PR
>> for the final review at least. Also I see JEP 386 hasn't been targeted
>> yet but I assume Boris, as owner, will propose-to-target and wait for it
>> to be targeted before it is integrated.
> 
> Yes. How can this be best accomplished with the new git workflow?
> - we can continue the review process till the end and I will request the integration to happen only after the JEP is
>   targeted. I guess this step is now done by typing "slash integrate" in a comment.
> - we can pause the review process now until the JEP is targeted.
> 
> In the first case I'm kindly asking the Reviewers who already chimed in on that to re-confirm the review here.

Aleksei Voitylov 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/49/files
  - new: https://git.openjdk.java.net/jdk/pull/49/files/5feda5ff..b7ffed87

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

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

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

From rriggs at openjdk.java.net  Fri Oct  2 15:53:39 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 2 Oct 2020 15:53:39 GMT
Subject: RFR: 8251989: Hex formatting and parsing utility
In-Reply-To: <HSEn47GMS1K3g57mrTZeQk-WZHl3pKGHpX_OOf8VnsU=.740863c2-f9e4-43c4-b500-614aab4078b1@github.com>
References: <HSEn47GMS1K3g57mrTZeQk-WZHl3pKGHpX_OOf8VnsU=.740863c2-f9e4-43c4-b500-614aab4078b1@github.com>
Message-ID: <X-O2yD1-1el59xpXjEPhSNWFJAWLhT5lrsa1Bs8gGLw=.7f5b1392-8146-4cbf-b598-a46595f6c241@github.com>

On Fri, 2 Oct 2020 15:18:04 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> java.util.HexFormat utility:
> 
>  - Format and parse hexadecimal strings, with parameters for delimiter, prefix, suffix and upper/lowercase
>  - Static factories and builder methods to create HexFormat copies with modified parameters.
>  - Consistent naming of methods for conversion of byte arrays to formatted strings and back: formatHex and parseHex
>  - Consistent naming of methods for conversion of primitive types: toHexDigits... and fromHexDigits...
>  - Prefix and suffixes now apply to each formatted value, not the string as a whole
>  - Using java.util.Appendable as a target for buffered conversions so output to Writers and PrintStreams
>    like System.out are supported in addition to StringBuilder. (IOExceptions are converted to unchecked exceptions)
>  - Immutable and thread safe, a "value-based" class
> 
> See the [HexFormat
> javadoc](http://cr.openjdk.java.net/~rriggs/8251989-hex-formatter/java.base/java/util/HexFormat.html) for details.
> Review comments and suggestions welcome.

To avoid spamming email lists, I'm removing the i18n, net, nio, and security labels since most developers already are
subscribed to core-libs. Please re-add a label if you think it is useful to the email list.

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

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

From kvn at openjdk.java.net  Fri Oct  2 16:00:42 2020
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 2 Oct 2020 16:00:42 GMT
Subject: RFR: 8223347: Integration of Vector API (Incubator)
In-Reply-To: <-PE4TwXgvq2bemAn_8csjn4_j7zoAolnQz6QQt3z0Wk=.eaa9999f-0713-4349-b31d-934717aa37a1@github.com>
References: <-PE4TwXgvq2bemAn_8csjn4_j7zoAolnQz6QQt3z0Wk=.eaa9999f-0713-4349-b31d-934717aa37a1@github.com>
Message-ID: <uhGPEeAM4UbRTuALm1KsP1XoegcdEjX2pzzCe-r0Rrg=.dcaaca7a-8b23-44a8-bad3-62fd703db861@github.com>

On Fri, 25 Sep 2020 20:14:29 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> This pull request is for integration of the Vector API. It was previously reviewed under conditions when mercurial was
> used for the source code control system. Review threads can be found here (searching for issue number 8223347 in the
> title):  https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-April/thread.html
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-May/thread.html
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-July/thread.html
> 
> If mercurial was still being used the code would be pushed directly, once the CSR is approved. However, in this case a
> pull request is required and needs explicit reviewer approval. Between the final review and this pull request no code
> has changed, except for that related to merging.

Good

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

Marked as reviewed by kvn (Reviewer).

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

From chegar at openjdk.java.net  Fri Oct  2 16:00:41 2020
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Fri, 2 Oct 2020 16:00:41 GMT
Subject: RFR: 8223347: Integration of Vector API (Incubator)
In-Reply-To: <-PE4TwXgvq2bemAn_8csjn4_j7zoAolnQz6QQt3z0Wk=.eaa9999f-0713-4349-b31d-934717aa37a1@github.com>
References: <-PE4TwXgvq2bemAn_8csjn4_j7zoAolnQz6QQt3z0Wk=.eaa9999f-0713-4349-b31d-934717aa37a1@github.com>
Message-ID: <HsVLqkwC-bwnsSoh_vr7_sq0wd_aOK62j8kP1SQK6QA=.bda773ef-473e-4221-9eb4-b27c41a9def1@github.com>

On Fri, 25 Sep 2020 20:14:29 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> This pull request is for integration of the Vector API. It was previously reviewed under conditions when mercurial was
> used for the source code control system. Review threads can be found here (searching for issue number 8223347 in the
> title):  https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-April/thread.html
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-May/thread.html
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-July/thread.html
> 
> If mercurial was still being used the code would be pushed directly, once the CSR is approved. However, in this case a
> pull request is required and needs explicit reviewer approval. Between the final review and this pull request no code
> has changed, except for that related to merging.

Marked as reviewed by chegar (Reviewer).

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

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

From douglas.surber at oracle.com  Fri Oct  2 16:16:42 2020
From: douglas.surber at oracle.com (Douglas Surber)
Date: Fri, 2 Oct 2020 09:16:42 -0700
Subject: RFR: 8251989: Hex formatting and parsing utility
In-Reply-To: <mailman.5210.1601654030.25523.core-libs-dev@openjdk.java.net>
References: <mailman.5210.1601654030.25523.core-libs-dev@openjdk.java.net>
Message-ID: <A383530B-F96B-452C-BBF0-0DCBB844D479@oracle.com>

This looks good overall. I would change the names of withPrefix and withSuffix to withBytePrefix and withByteSuffix and add some words to their JavaDoc clarifying that they  apply to the individual bytes.

Douglas

> On Oct 2, 2020, at 8:53 AM, core-libs-dev-request at openjdk.java.net wrote:
> 
> Date: Fri, 2 Oct 2020 15:53:39 GMT
> From: Roger Riggs <rriggs at openjdk.java.net <mailto:rriggs at openjdk.java.net>>
> To: <core-libs-dev at openjdk.java.net <mailto:core-libs-dev at openjdk.java.net>>
> Subject: Re: RFR: 8251989: Hex formatting and parsing utility
> Message-ID:
> 	<X-O2yD1-1el59xpXjEPhSNWFJAWLhT5lrsa1Bs8gGLw=.7f5b1392-8146-4cbf-b598-a46595f6c241 at github.com <mailto:X-O2yD1-1el59xpXjEPhSNWFJAWLhT5lrsa1Bs8gGLw=.7f5b1392-8146-4cbf-b598-a46595f6c241 at github.com>>
> 	
> Content-Type: text/plain; charset=utf-8
> 
> On Fri, 2 Oct 2020 15:18:04 GMT, Roger Riggs <rriggs at openjdk.org <mailto:rriggs at openjdk.org>> wrote:
> 
>> java.util.HexFormat utility:
>> 
>> - Format and parse hexadecimal strings, with parameters for delimiter, prefix, suffix and upper/lowercase
>> - Static factories and builder methods to create HexFormat copies with modified parameters.
>> - Consistent naming of methods for conversion of byte arrays to formatted strings and back: formatHex and parseHex
>> - Consistent naming of methods for conversion of primitive types: toHexDigits... and fromHexDigits...
>> - Prefix and suffixes now apply to each formatted value, not the string as a whole
>> - Using java.util.Appendable as a target for buffered conversions so output to Writers and PrintStreams
>>   like System.out are supported in addition to StringBuilder. (IOExceptions are converted to unchecked exceptions)
>> - Immutable and thread safe, a "value-based" class
>> 
>> See the [HexFormat
>> javadoc](http://cr.openjdk.java.net/~rriggs/8251989-hex-formatter/java.base/java/util/HexFormat.html <http://cr.openjdk.java.net/~rriggs/8251989-hex-formatter/java.base/java/util/HexFormat.html>) for details.
>> Review comments and suggestions welcome.
> 
> To avoid spamming email lists, I'm removing the i18n, net, nio, and security labels since most developers already are
> subscribed to core-libs. Please re-add a label if you think it is useful to the email list.
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/482 <https://git.openjdk.java.net/jdk/pull/482>
> 


From ccheung at openjdk.java.net  Fri Oct  2 16:30:01 2020
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Fri, 2 Oct 2020 16:30:01 GMT
Subject: RFR: 8247666: Support Lambda proxy classes in static CDS archive
 [v3]
In-Reply-To: <ynh4JzHY75GjEn5_oCtmRNy9HMFsU34O2PlhSwD41tU=.1a3770f9-9091-429f-8d03-31b826f9b093@github.com>
References: <ynh4JzHY75GjEn5_oCtmRNy9HMFsU34O2PlhSwD41tU=.1a3770f9-9091-429f-8d03-31b826f9b093@github.com>
Message-ID: <pvSPAXeOsA-4mxsmAMzKbw8qeAxizhxzDrajr9p7cy4=.004ba246-f90e-4926-b4ec-19bead011c86@github.com>

> Following up on archiving lambda proxy classes in dynamic CDS archive
> ([JDK-8198698](https://bugs.openjdk.java.net/browse/JDK-8198698)), this RFE adds the functionality of archiving of
> lambda proxy classes in static CDS archive.
> When the -XX:DumpLoadedClassList is enabled, the constant pool index related to LambdaMetafactory that are resolved
> during application execution will be included in the classlist. The entry for a lambda proxy class in a class list will
> be of the following format:
> `@lambda-proxy: <classname> <cp index>`
> 
> e.g.
> `@lambda-proxy: test/java/lang/invoke/MethodHandlesGeneralTest 233`
> `@lambda-proxy: test/java/lang/invoke/MethodHandlesGeneralTest 355`
> 
> When dumping a CDS archive using the -Xshare:dump and -XX:ExtraSharedClassListFile options, when the above
> `@lambda-proxy` entry is encountered while parsing the classlist, we will resolve the corresponding constant pool
> indices (233 and 355 in the above example). As a result, lambda proxy classes will be generated for the constant pool
> entries, and will be cached using a similar mechanism to JDK-8198698.  During dumping, there is check on the cp index
> and on the created BootstrapInfo using the cp index. VM will exit with an error message if the check has failed.
> During runtime when looking up a lambda proxy class, the lookup will be perform on the static CDS archive and if not
> found, then lookup from the dynamic archive if one is specified.  (Only name change (IsDynamicDumpingEnabled ->
> IsCDSDumpingEnabled) is involved in the core-libs code.)
> Testing: tiers 1,2,3,4.
> 
> Performance results (javac on HelloWorld on linux-x64):
> Results of " perf stat -r 40 bin/javac -J-Xshare:on -J-XX:SharedArchiveFile=javac2.jsa Bench_HelloWorld.java "
>    1:   2228016795  2067752708 (-160264087)      -----    377.760   349.110 (-28.650)      -----
>    2:   2223051476  2063016483 (-160034993)      -----    374.580   350.620 (-23.960)      ----
>    3:   2225908334  2067673847 (-158234487)      -----    375.220   350.990 (-24.230)      ----
>    4:   2225835999  2064596883 (-161239116)      -----    374.670   349.840 (-24.830)      ----
>    5:   2226005510  2061694332 (-164311178)      -----    373.512   351.120 (-22.392)      ----
>    6:   2225574949  2062657482 (-162917467)      -----    374.710   348.380 (-26.330)      -----
>    7:   2224702424  2064634122 (-160068302)      -----    373.670   349.510 (-24.160)      ----
>    8:   2226662277  2066301134 (-160361143)      -----    375.350   349.790 (-25.560)      ----
>    9:   2226761470  2063162795 (-163598675)      -----    374.260   351.290 (-22.970)      ----
>   10:   2230149089  2066203307 (-163945782)      -----    374.760   350.620 (-24.140)      ----
> ============================================================
>         2226266109  2064768307 (-161497801)      -----    374.848   350.126 (-24.722)      ----
> instr delta =   -161497801    -7.2542%
> time  delta =      -24.722 ms -6.5951%

Calvin Cheung has updated the pull request with a new target base 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 8247666
 - exclude archived lambda proxy classes in the classlist
 - updated systemDictionaryShared.[c|h]pp based on suggestions from Ioi
 - fix extraneous whitespace
 - 8247666 (initial commit)

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/364/files
  - new: https://git.openjdk.java.net/jdk/pull/364/files/d66667d4..c82b39f1

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

  Stats: 18818 lines in 2008 files changed: 6756 ins; 4063 del; 7999 mod
  Patch: https://git.openjdk.java.net/jdk/pull/364.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/364/head:pull/364

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

From sgehwolf at openjdk.java.net  Fri Oct  2 16:41:49 2020
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Fri, 2 Oct 2020 16:41:49 GMT
Subject: RFR: 8245543: Cgroups: Incorrect detection logic on some systems
 (still reproducible)
Message-ID: <CWATRi437QpkCA1sx-EsHFqVlSCV-G8EgkEoGdJgPHc=.a743be7e-8a00-4d91-866d-86ccf3fe714f@github.com>

An issue similar to [JDK-8239559](https://bugs.openjdk.java.net/browse/JDK-8239559) has been discovered. On the
affected system, `/proc/self/mountinfo` contains a line such as this one:

35 26 0:26 / /sys/fs/cgroup/systemd rw,nosuid,nodev,noexec,relatime - cgroup systemd rw,name=systemd
 

Note that `/proc/cgroups` looks like this:

#subsys_name	hierarchy	num_cgroups	enabled
cpuset	0	1	1
cpu	0	1	1
cpuacct	0	1	1
blkio	0	1	1
memory	0	1	1
devices	0	1	1
freezer	0	1	1
net_cls	0	1	1
perf_event	0	1	1
net_prio	0	1	1
hugetlb	0	1	1
pids	0	1	1

This is in fact a cgroups v1 system with systemd put into a separate namespace via FS type `cgroup`. That mountinfo
line confuses the cgroups version detection heuristic. It only looked whether or not there is **any** entry in
mountinfo of FS-type `cgroup` . That's wrong. A better heuristic would be looking at controllers we care about: `cpu`,
`cpuacct`, `memory`, `cpuset` for hotspot and some more for the Java side. The proposed fix on the hotspot side is to
set `any_cgroup_mounts_found` to true only if one of those controllers show up in mountinfo. Otherwise, we know it's
cgroup v2 due to the zero hierarchy ids.

For the Java side the proposal is to add some parsing for mountinfo lines and look for `cgroup` FS-type lines which
aren't also mounted purely for systemd.

**Testing**

 - [x] Linux x86_64 container tests on cgroup v1 (fastdebug)
 - [x] Linux x86_64 container tests on cgroup v2 (fastdebug)
 - [x] Added regression test which fails prior the patch and passes after
 - [ ] Submit testing (still running)

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

Commit messages:
 - 8245543: Cgroups: Incorrect detection logic on some systems (still reproducible)

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

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

From sgehwolf at openjdk.java.net  Fri Oct  2 16:41:49 2020
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Fri, 2 Oct 2020 16:41:49 GMT
Subject: RFR: 8245543: Cgroups: Incorrect detection logic on some systems
 (still reproducible)
In-Reply-To: <CWATRi437QpkCA1sx-EsHFqVlSCV-G8EgkEoGdJgPHc=.a743be7e-8a00-4d91-866d-86ccf3fe714f@github.com>
References: <CWATRi437QpkCA1sx-EsHFqVlSCV-G8EgkEoGdJgPHc=.a743be7e-8a00-4d91-866d-86ccf3fe714f@github.com>
Message-ID: <GQPVanQ-V8oL4npQHUXk5xw5pxR4fF8z3C_Wj5l7uDw=.1f4b9c49-252f-47dd-a0cf-6d36794928db@github.com>

On Fri, 2 Oct 2020 16:34:49 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> An issue similar to [JDK-8239559](https://bugs.openjdk.java.net/browse/JDK-8239559) has been discovered. On the
> affected system, `/proc/self/mountinfo` contains a line such as this one:
> 
> 35 26 0:26 / /sys/fs/cgroup/systemd rw,nosuid,nodev,noexec,relatime - cgroup systemd rw,name=systemd
>  
> 
> Note that `/proc/cgroups` looks like this:
> 
> #subsys_name	hierarchy	num_cgroups	enabled
> cpuset	0	1	1
> cpu	0	1	1
> cpuacct	0	1	1
> blkio	0	1	1
> memory	0	1	1
> devices	0	1	1
> freezer	0	1	1
> net_cls	0	1	1
> perf_event	0	1	1
> net_prio	0	1	1
> hugetlb	0	1	1
> pids	0	1	1
> 
> This is in fact a cgroups v1 system with systemd put into a separate namespace via FS type `cgroup`. That mountinfo
> line confuses the cgroups version detection heuristic. It only looked whether or not there is **any** entry in
> mountinfo of FS-type `cgroup` . That's wrong. A better heuristic would be looking at controllers we care about: `cpu`,
> `cpuacct`, `memory`, `cpuset` for hotspot and some more for the Java side. The proposed fix on the hotspot side is to
> set `any_cgroup_mounts_found` to true only if one of those controllers show up in mountinfo. Otherwise, we know it's
> cgroup v2 due to the zero hierarchy ids.  For the Java side the proposal is to add some parsing for mountinfo lines and
> look for `cgroup` FS-type lines which aren't also mounted purely for systemd.
> **Testing**
> 
>  - [x] Linux x86_64 container tests on cgroup v1 (fastdebug)
>  - [x] Linux x86_64 container tests on cgroup v2 (fastdebug)
>  - [x] Added regression test which fails prior the patch and passes after
>  - [ ] Submit testing (still running)

@bulasevich Do you want to give this a spin?

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

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

From rriggs at openjdk.java.net  Fri Oct  2 17:11:38 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 2 Oct 2020 17:11:38 GMT
Subject: RFR: 8253750: use build-stable default seed for
 Utils.RANDOM_GENERATOR
In-Reply-To: <rjuoGCzkLKiqcIG5DfoliW32WWpFvoJlvr58r9YE4Yo=.657c9073-0352-40ed-a653-ff4c2bdd24c2@github.com>
References: <RQa3EOXeDAni1G-mu_jM-I9mosypb0gnuLUmFCtGhGo=.92a4f06b-60df-49b6-b6e3-bcf11e7530ab@github.com>
 <rjuoGCzkLKiqcIG5DfoliW32WWpFvoJlvr58r9YE4Yo=.657c9073-0352-40ed-a653-ff4c2bdd24c2@github.com>
Message-ID: <-nJ85Iyg2_335BQ19H6gKf2gEc4GU_Bg5iTzrvGSKUk=.d17d917e-8afa-455c-985b-d7280013d5d3@github.com>

On Fri, 2 Oct 2020 15:39:01 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

>> Hi all,
>> 
>> could you please review the patch which updates `jdk.test.lib.Utils` to use md5 hash-sum of `java.vm.version` property
>> as default seed for `Utils.RANDOM_GENERATOR`?
>> from JBS:
>>> using the same seed for all runs of a build will make it possible (easier) to compare results from different test runs
>>> (e.g. on different platforms, w/ different flags) and consequently will make test results analysis easier.
>> 
>> the patch also updates `RandomGeneratorTest` test, so it expects now that the same values are generated if no seed is
>> provided.
>> testing: ? tier1
>
> ping?

Is this really a good idea?  The purpose of using random numbers is to get broader coverage on multiple runs.
If the seed only changes once per version (6 months), that reduces test coverage.
At least for dev submitted runs, I would like to be different for every build (unless overridden).

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

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

From mbeckwit at openjdk.java.net  Fri Oct  2 17:20:45 2020
From: mbeckwit at openjdk.java.net (Monica Beckwith)
Date: Fri, 2 Oct 2020 17:20:45 GMT
Subject: RFR: 8248238: Implementation: JEP 388: Windows AArch64 Support
 [v12]
In-Reply-To: <t08mgMBggFEJuzguHzW9OPI3AgtasklRfHSO95q3YA4=.98e321ac-8db2-462f-b311-7de33dcb9091@github.com>
References: <rKAoubbLMIMVqS6En_xKWMT8jpEwBU5TF83A-AhWg2E=.908578cd-0877-431e-9447-d5a04e0dc970@github.com>
 <qv-WAepDb6KDawneV5Mw_HXjDB-xBnJkdeIAlquh6bU=.3af0c77f-fe7b-4bee-913b-6e6de513f0bd@github.com>
 <t08mgMBggFEJuzguHzW9OPI3AgtasklRfHSO95q3YA4=.98e321ac-8db2-462f-b311-7de33dcb9091@github.com>
Message-ID: <CiPvM88WFx_o1P3zYlEFsdSrLK2sxrNQfWQVgPfOHi4=.fcf0ed66-c945-4760-b217-110b123fdc2f@github.com>

On Wed, 30 Sep 2020 00:40:29 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Monica Beckwith has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   change string representation for r18 to "r18_tls" on every platform
>
> Marked as reviewed by dholmes (Reviewer).

> The JEP is not yet targeted so we have to wait for that formality. But
> once that happens I can sponsor for you.

Thanks.
>
> Also note that the PR references the wrong JEP so can you please edit
> the description to fix that.

Added JEP # (388) here and updated the JBS entry.
After looking at JEPs 386, 377, and 379, I also did the following:
- listed JDK-8248238 as a sub-task for JDK-8248496
- added this PR link in a comment for the JEP.

As soon as the JEP is targetted, I will update the "Fix version" for the 'Implementation' (JDK-8248238) and ping you
@dholmes-ora .
> 
> Meanwhile I'll see if I can take this for a spin through our internal
> testing.
Thanks so much.

Regards,
Monica

> 
> Cheers,
> David

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

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

From joe.darcy at oracle.com  Fri Oct  2 17:26:37 2020
From: joe.darcy at oracle.com (Joe Darcy)
Date: Fri, 2 Oct 2020 10:26:37 -0700
Subject: RFR: 8253750: use build-stable default seed for
 Utils.RANDOM_GENERATOR
In-Reply-To: <-nJ85Iyg2_335BQ19H6gKf2gEc4GU_Bg5iTzrvGSKUk=.d17d917e-8afa-455c-985b-d7280013d5d3@github.com>
References: <RQa3EOXeDAni1G-mu_jM-I9mosypb0gnuLUmFCtGhGo=.92a4f06b-60df-49b6-b6e3-bcf11e7530ab@github.com>
 <rjuoGCzkLKiqcIG5DfoliW32WWpFvoJlvr58r9YE4Yo=.657c9073-0352-40ed-a653-ff4c2bdd24c2@github.com>
 <-nJ85Iyg2_335BQ19H6gKf2gEc4GU_Bg5iTzrvGSKUk=.d17d917e-8afa-455c-985b-d7280013d5d3@github.com>
Message-ID: <f28bc380-0c94-cc6e-3bfe-c8b3c040a734@oracle.com>

I agree with Roger that this change should *not* go forward since it 
would have the effect of reducing test coverage.

Regression tests that use randomness should using the "randomness" jtreg 
label and should output the seed value used so a failing result can be 
replicated.

Thanks,

-Joe

On 10/2/2020 10:11 AM, Roger Riggs wrote:
> On Fri, 2 Oct 2020 15:39:01 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:
>
>>> Hi all,
>>>
>>> could you please review the patch which updates `jdk.test.lib.Utils` to use md5 hash-sum of `java.vm.version` property
>>> as default seed for `Utils.RANDOM_GENERATOR`?
>>> from JBS:
>>>> using the same seed for all runs of a build will make it possible (easier) to compare results from different test runs
>>>> (e.g. on different platforms, w/ different flags) and consequently will make test results analysis easier.
>>> the patch also updates `RandomGeneratorTest` test, so it expects now that the same values are generated if no seed is
>>> provided.
>>> testing: ? tier1
>> ping?
> Is this really a good idea?  The purpose of using random numbers is to get broader coverage on multiple runs.
> If the seed only changes once per version (6 months), that reduces test coverage.
> At least for dev submitted runs, I would like to be different for every build (unless overridden).
>
> -------------
>
> PR: https://git.openjdk.java.net/jdk/pull/391

From rriggs at openjdk.java.net  Fri Oct  2 17:43:43 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 2 Oct 2020 17:43:43 GMT
Subject: RFR: 8253876: jdk/test/lib/hexdump/ASN1FormatterTest.java fails with
 "AssertionError: Lines expected [126] but found [202]"
Message-ID: <ASCOaOEaKxCTMEzRTADTMkIxJZ3y5fTD1D2bC_Zyi7k=.de0aea66-338c-46be-9fa5-89a52dd4b119@github.com>

The HexPrinter test utility should be ignoring \r characters from the formatter.
It looks for \n and generates System.lineSeparator() at the end of each line.

With this fix, the ASN1FormatterTest can be removed from the ProblemList.

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

Commit messages:
 - 8253876: Unexpected CR on Windows and remove from problem list.

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

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

From iignatyev at openjdk.java.net  Fri Oct  2 17:50:38 2020
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Fri, 2 Oct 2020 17:50:38 GMT
Subject: RFR: 8253750: use build-stable default seed for
 Utils.RANDOM_GENERATOR
In-Reply-To: <-nJ85Iyg2_335BQ19H6gKf2gEc4GU_Bg5iTzrvGSKUk=.d17d917e-8afa-455c-985b-d7280013d5d3@github.com>
References: <RQa3EOXeDAni1G-mu_jM-I9mosypb0gnuLUmFCtGhGo=.92a4f06b-60df-49b6-b6e3-bcf11e7530ab@github.com>
 <rjuoGCzkLKiqcIG5DfoliW32WWpFvoJlvr58r9YE4Yo=.657c9073-0352-40ed-a653-ff4c2bdd24c2@github.com>
 <-nJ85Iyg2_335BQ19H6gKf2gEc4GU_Bg5iTzrvGSKUk=.d17d917e-8afa-455c-985b-d7280013d5d3@github.com>
Message-ID: <Zu_I7aS8615GcRVX0msj8-PXdKucGAH1wBvI4LaYIYw=.0484ed4d-41dd-4263-a593-19955b4fa4eb@github.com>

On Fri, 2 Oct 2020 17:09:07 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> ping?
>
> Is this really a good idea?  The purpose of using random numbers is to get broader coverage on multiple runs.
> If the seed only changes once per version (6 months), that reduces test coverage.
> At least for dev submitted runs, I would like to be different for every build (unless overridden).

Hi Roger,

it's exactly that you want it to be. It is different for every build (not every release, as we are using
`java.vm.version` not `java.version`) unless overridden, each dev submitted run and each CI builds have different
`java.vm.version` (e.g. the last two mach5 CI builds have `16-ea+19-938` and `16-ea+19-939` as their `java.vm.version`,
one of my ad-hoc mach5 runs -- `16-internal+0-2020-10-01-2150482.igor.ignatyev.jdk`, my local build --
`16-internal+0-2020-10-01-2252075.iignatye...`, ) and hence would get different seeds. all the test tasks for these
builds, on the other hand, would use the same seed, so one could be more confident that if test `T` passed on all
platforms but platform `P`, it's platform `P` specific problem, there before this fix, one would need to rerun test `T`
on each platform with the _faling_ seed and on platform `P` with at least one _passing_ seed, this problem becomes even
more acute when you start considering all build flavor, vm flags, host configurations we cover in our testing.

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

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

From iignatyev at openjdk.java.net  Fri Oct  2 17:57:38 2020
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Fri, 2 Oct 2020 17:57:38 GMT
Subject: RFR: 8253750: use build-stable default seed for
 Utils.RANDOM_GENERATOR
In-Reply-To: <Zu_I7aS8615GcRVX0msj8-PXdKucGAH1wBvI4LaYIYw=.0484ed4d-41dd-4263-a593-19955b4fa4eb@github.com>
References: <RQa3EOXeDAni1G-mu_jM-I9mosypb0gnuLUmFCtGhGo=.92a4f06b-60df-49b6-b6e3-bcf11e7530ab@github.com>
 <rjuoGCzkLKiqcIG5DfoliW32WWpFvoJlvr58r9YE4Yo=.657c9073-0352-40ed-a653-ff4c2bdd24c2@github.com>
 <-nJ85Iyg2_335BQ19H6gKf2gEc4GU_Bg5iTzrvGSKUk=.d17d917e-8afa-455c-985b-d7280013d5d3@github.com>
 <Zu_I7aS8615GcRVX0msj8-PXdKucGAH1wBvI4LaYIYw=.0484ed4d-41dd-4263-a593-19955b4fa4eb@github.com>
Message-ID: <bowHG3A_CwoXcxZy6_ItkYUF7UtL_uJr-cyy30tSn68=.053e04ee-dfa8-4002-8c0d-aa4e1e3f638b@github.com>

On Fri, 2 Oct 2020 17:47:40 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

>> Is this really a good idea?  The purpose of using random numbers is to get broader coverage on multiple runs.
>> If the seed only changes once per version (6 months), that reduces test coverage.
>> At least for dev submitted runs, I would like to be different for every build (unless overridden).
>
> Hi Roger,
> 
> it's exactly that you want it to be. It is different for every build (not every release, as we are using
> `java.vm.version` not `java.version`) unless overridden, each dev submitted run and each CI builds have different
> `java.vm.version` (e.g. the last two mach5 CI builds have `16-ea+19-938` and `16-ea+19-939` as their `java.vm.version`,
> one of my ad-hoc mach5 runs -- `16-internal+0-2020-10-01-2150482.igor.ignatyev.jdk`, my local build --
> `16-internal+0-2020-10-01-2252075.iignatye...`, ) and hence would get different seeds. all the test tasks for these
> builds, on the other hand, would use the same seed, so one could be more confident that if test `T` passed on all
> platforms but platform `P`, it's platform `P` specific problem, there before this fix, one would need to rerun test `T`
> on each platform with the _faling_ seed and on platform `P` with at least one _passing_ seed, this problem becomes even
> more acute when you start considering all build flavor, vm flags, host configurations we cover in our testing.

Hi Joe,

this change indeed reduces test coverage, but not drastically (one can even argue that it doesn't reduce coverage as
generally speaking you can merge coverage from runs with different configurations, e.g. run on different platforms),
due to that and the reasons I wrote in my response to Roger, I don't think the reducing coverage is an issue here, nor
do I think that possible impact on coverage overweights the benefits we get from comparable runs.

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

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

From lmesnik at openjdk.java.net  Fri Oct  2 18:01:40 2020
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Fri, 2 Oct 2020 18:01:40 GMT
Subject: RFR: 8229186: Improve error messages for TestStringIntrinsics
 failures [v8]
In-Reply-To: <hzpKNVfoRMK3EWzNuKggPrNcC_jv42UBw5_NDQCYw9g=.4d68041b-2988-4e85-9d8d-7f094eee8041@github.com>
References: <Br6z5yt0kTbZwIQyTI9lz7czaYpjw5vCd5ZCbbrSIcM=.6a8096f1-91ed-4673-bab3-3bfae758ab95@github.com>
 <hzpKNVfoRMK3EWzNuKggPrNcC_jv42UBw5_NDQCYw9g=.4d68041b-2988-4e85-9d8d-7f094eee8041@github.com>
Message-ID: <9mGAphCyQ34v3jOr4qiR4jkUccvdv1noUw5VrjwyBoc=.a282b928-a862-43c9-a206-41b0c6da3c7b@github.com>

On Fri, 2 Oct 2020 08:50:06 GMT, Evgeny Nikitin <enikitin at openjdk.org> wrote:

>> pre-Skara RFR thread: [link](https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-May/038416.html)
>> 
>> Error reporting was improved by writing a C-style escaped string representations for the variables passed to the
>> methods being tested. For array comparisons, a dedicated diff-formatter was implemented.
>> Sample output for comparing byte arrays (with artificial failure):
>>  ----------System.err:(21/1553)----------
>>  Result: (false) of 'arrayEqualsB' is not equal to expected (true)
>>  Arrays differ starting from [index: 7]:
>>  ... 5, 6,   7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, ...
>>  ... 5, 6, 125, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, ...
>>            ^^^^
>>  java.lang.RuntimeException: Result: (false) of 'arrayEqualsB' is not
>>  equal to expected (true)
>>           at
>>  compiler.intrinsics.string.TestStringIntrinsics.invokeAndCheckArrays(TestStringIntrinsics.java:273)
>>            at ... stack trace continues - E.N.
>>  Sample output for comparing char arrays:
>>  ----------System.err:(21/1579)*----------
>>  Result: (false) of 'arrayEqualsC' is not equal to expected (true)
>>  Arrays differ starting from [index: 7]:
>>  ... \\u0005, \\u0006, \\u0007, \\u0008, \\u0009, \\n, ...
>>  ... \\u0005, \\u0006,      }, \\u0008, \\u0009, \\n, ...
>>                      ^^^^^^^
>>  java.lang.RuntimeException: Result: (false) of 'arrayEqualsC' is not
>>  equal to expected (true)
>>           at
>>  compiler.intrinsics.string.TestStringIntrinsics.invokeAndCheckArrays(TestStringIntrinsics.java:280)
>>            at
>>  ... and so on - E.N.
>> 
>> testing: open/test/hotspot/jtreg/compiler/intrinsics/string/TestStringIntrinsics.java on linux, windows, macosx.
>
> Evgeny Nikitin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make ArrayDiff.Defaults a generic Diff.Defaults

Marked as reviewed by lmesnik (Committer).

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

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

From rriggs at openjdk.java.net  Fri Oct  2 18:49:37 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 2 Oct 2020 18:49:37 GMT
Subject: RFR: 8253750: use build-stable default seed for
 Utils.RANDOM_GENERATOR
In-Reply-To: <RQa3EOXeDAni1G-mu_jM-I9mosypb0gnuLUmFCtGhGo=.92a4f06b-60df-49b6-b6e3-bcf11e7530ab@github.com>
References: <RQa3EOXeDAni1G-mu_jM-I9mosypb0gnuLUmFCtGhGo=.92a4f06b-60df-49b6-b6e3-bcf11e7530ab@github.com>
Message-ID: <mo0lfq_iw1eyJBqdTO7yWC-j2a--ZZiYdtkzGGcquwg=.b3b947ce-fd62-4c27-ac65-37b7380b80b0@github.com>

On Tue, 29 Sep 2020 00:06:02 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review the patch which updates `jdk.test.lib.Utils` to use md5 hash-sum of `java.vm.version` property
> as default seed for `Utils.RANDOM_GENERATOR`?
> from JBS:
>> using the same seed for all runs of a build will make it possible (easier) to compare results from different test runs
>> (e.g. on different platforms, w/ different flags) and consequently will make test results analysis easier.
> 
> the patch also updates `RandomGeneratorTest` test, so it expects now that the same values are generated if no seed is
> provided.
> testing: ? tier1

ok, if I read the code closely and know how the promoted build process works then I see your rationale.
Please update the bug report and edit the PR description to describe the conditions under which the seed
for random is computed from the build number. Its might be clearer to refer to the Runtime.Version build information
in the description.  Also make it clear that unless the system property is set, it will use a 'random' seed.

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

Changes requested by rriggs (Reviewer).

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

From weijun at openjdk.java.net  Fri Oct  2 19:16:38 2020
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 2 Oct 2020 19:16:38 GMT
Subject: RFR: 8251989: Hex formatting and parsing utility
In-Reply-To: <HSEn47GMS1K3g57mrTZeQk-WZHl3pKGHpX_OOf8VnsU=.740863c2-f9e4-43c4-b500-614aab4078b1@github.com>
References: <HSEn47GMS1K3g57mrTZeQk-WZHl3pKGHpX_OOf8VnsU=.740863c2-f9e4-43c4-b500-614aab4078b1@github.com>
Message-ID: <E4uO8-HUWk8Yyetoq_zp-U3QsEUsA2cWMWs23AcTAss=.25b2feca-d571-44ae-9871-74455fe32619@github.com>

On Fri, 2 Oct 2020 15:18:04 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> java.util.HexFormat utility:
> 
>  - Format and parse hexadecimal strings, with parameters for delimiter, prefix, suffix and upper/lowercase
>  - Static factories and builder methods to create HexFormat copies with modified parameters.
>  - Consistent naming of methods for conversion of byte arrays to formatted strings and back: formatHex and parseHex
>  - Consistent naming of methods for conversion of primitive types: toHexDigits... and fromHexDigits...
>  - Prefix and suffixes now apply to each formatted value, not the string as a whole
>  - Using java.util.Appendable as a target for buffered conversions so output to Writers and PrintStreams
>    like System.out are supported in addition to StringBuilder. (IOExceptions are converted to unchecked exceptions)
>  - Immutable and thread safe, a "value-based" class
> 
> See the [HexFormat
> javadoc](http://cr.openjdk.java.net/~rriggs/8251989-hex-formatter/java.base/java/util/HexFormat.html) for details.
> Review comments and suggestions welcome.

The class name already has `Hex` inside, and methods names still contain it. Also, I found it unexpected that
`fromHexDigits` returns an integer. Can we use `encode`, `decode`, `decodeInt`, `decodeLong` etc?

src/java.base/share/classes/java/util/HexFormat.java line 213:

> 211:      * @param delimiter the {@code delimiter}, non-null, may be empty
> 212:      * @return a copy of this {@code HexFormat} with the {@code delimiter}
> 213:      */

Is this very useful now that we already have `ofDelimeter(String)`?

src/java.base/share/classes/java/util/HexFormat.java line 290:

> 288:      * @return returns {@code true} if the hexadecimal digits will be uppercase,
> 289:      *          otherwise {@code false}
> 290:      */

Can someone choose their own `digits`? If not, how about "=="?

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

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

From smarks at openjdk.java.net  Fri Oct  2 19:41:38 2020
From: smarks at openjdk.java.net (Stuart Marks)
Date: Fri, 2 Oct 2020 19:41:38 GMT
Subject: RFR: 8156071: List.of: reduce array copying during creation
In-Reply-To: <qK-TMrKwrRyrefv541CsxYvjrKQjVG7fjF_btOrjf6w=.008781c9-a2ea-4b0b-8249-932a71a12dca@github.com>
References: <-pkG69_yCpZxK0LBMz3Dw_m2VkTK6BhhWBY02UkidfQ=.c1f424e8-5716-4858-aaa0-488a9e553107@github.com>
 <qK-TMrKwrRyrefv541CsxYvjrKQjVG7fjF_btOrjf6w=.008781c9-a2ea-4b0b-8249-932a71a12dca@github.com>
Message-ID: <YXZM7zPKwma4gAiA-oZJ5cA3gxHwG1oQ4YrmwNncGiU=.7b1763bd-9d15-44b9-b9f4-6ac12af5b984@github.com>

On Thu, 1 Oct 2020 06:26:39 GMT, Martin Grigorov <github.com+232002+martin-g at openjdk.org> wrote:

>> Plumb new internal static factory method to trust the array passed in, avoiding unnecessary copying. JMH results for
>> the benchmark show about 15% improvement for the cases that were optimized, namely the 3 to 10 fixed arg cases.
>> # VM options: -verbose:gc -XX:+UseParallelGC -Xms4g -Xmx4g --enable-preview -verbose:gc -XX:+UsePara
>> llelGC -Xms4g -Xmx4g -Xint
>> # Warmup: 5 iterations, 1 s each
>> # Measurement: 5 iterations, 2 s each
>> 
>> WITHOUT varargs optimization:
>> 
>> Benchmark         Mode  Cnt     Score     Error   Units
>> ListArgs.list00  thrpt   15  6019.539 ? 144.040  ops/ms
>> ListArgs.list01  thrpt   15  1985.009 ?  40.606  ops/ms
>> ListArgs.list02  thrpt   15  1854.812 ?  17.488  ops/ms
>> ListArgs.list03  thrpt   15   963.866 ?  10.262  ops/ms
>> ListArgs.list04  thrpt   15   908.116 ?   6.278  ops/ms
>> ListArgs.list05  thrpt   15   848.607 ?  16.701  ops/ms
>> ListArgs.list06  thrpt   15   822.282 ?   8.905  ops/ms
>> ListArgs.list07  thrpt   15   780.057 ?  11.214  ops/ms
>> ListArgs.list08  thrpt   15   745.295 ?  19.204  ops/ms
>> ListArgs.list09  thrpt   15   704.596 ?  14.003  ops/ms
>> ListArgs.list10  thrpt   15   696.436 ?   4.914  ops/ms
>> ListArgs.list11  thrpt   15   661.908 ?  11.041  ops/ms
>> 
>> WITH varargs optimization:
>> 
>> Benchmark         Mode  Cnt     Score    Error   Units
>> ListArgs.list00  thrpt   15  6172.298 ? 62.736  ops/ms
>> ListArgs.list01  thrpt   15  1987.724 ? 45.468  ops/ms
>> ListArgs.list02  thrpt   15  1843.419 ? 10.693  ops/ms
>> ListArgs.list03  thrpt   15  1126.946 ? 30.952  ops/ms
>> ListArgs.list04  thrpt   15  1050.440 ? 17.859  ops/ms
>> ListArgs.list05  thrpt   15   999.275 ? 23.656  ops/ms
>> ListArgs.list06  thrpt   15   948.844 ? 19.615  ops/ms
>> ListArgs.list07  thrpt   15   897.541 ? 15.531  ops/ms
>> ListArgs.list08  thrpt   15   853.359 ? 18.755  ops/ms
>> ListArgs.list09  thrpt   15   826.394 ?  8.284  ops/ms
>> ListArgs.list10  thrpt   15   779.231 ?  4.104  ops/ms
>> ListArgs.list11  thrpt   15   650.888 ?  3.948  ops/ms
>
> src/java.base/share/classes/jdk/internal/access/SharedSecrets.java line 88:
> 
>> 86:         if (javaUtilCollectionAccess == null) {
>> 87:             try {
>> 88:                 Class.forName("java.util.ImmutableCollections$Access", true, null);
> 
> How does this work ? It attempts to load this class but `javaUtilCollectionAccess` is never assigned to a new value.
> 
> **Update**: I just noticed this is the getter.

Yeah the SharedSecrets stuff is pretty twisted

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

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

From volker.simonis at gmail.com  Fri Oct  2 19:44:49 2020
From: volker.simonis at gmail.com (Volker Simonis)
Date: Fri, 2 Oct 2020 21:44:49 +0200
Subject: Request for Discussion: 8253952: Work around wrong usage of
 ZipOutputStream.putNextEntry() in user code
Message-ID: <CA+3eh12_-fNxf_KFK68WEqVoD_n6CD7RCbe=LoKCyCeUQ3w0oQ@mail.gmail.com>

Hi,

I'd like to get your opinion on a workaround for a common but wrong
usage pattern of ZipOutputStream.putNextEntry() in user code. I've
created a Draft PR with all the gory details (which I'll include here
for your convenience). Please let me know what you think?

https://github.com/openjdk/jdk/pull/489
https://bugs.openjdk.java.net/browse/JDK-8253952

### Summary

Work around wrong usage of `ZipOutputStream.putNextEntry()` in user
code which can lead to the `ZipException "invalid entry compressed
size"`.

### Motivation

In general it is not safe to directly write a ZipEntry obtained from
`ZipInputStream.getNextEntry()`, `ZipFile.entries()`,
`ZipFile.getEntry()` or `ZipFile.stream()` with
`ZipOutputStream.putNextEntry()` to a `ZipOutputStream` and then read
the entries data from the `ZipInputStream` and write it to the
`ZipOutputStream` as follows:
```
 ZipEntry entry;
 ZipInputStream zis = new ZipInputStream(...);
 ZipOutputStream zos = new ZipOutputStream(...);
 while((entry = zis.getNextEntry()) != null) {
     zos.putNextEntry(entry);
     zis.transferTo(zos);
 }
```
The problem with this code is that the zip file format does not record
the compression level used for deflation in its entries. In general,
it doesn't even mandate a predefined compression ratio per compression
level. Therefore the compressed size recorded in a `ZipEntry` read
from a zip file might differ from the new compressed size produced by
the receiving `ZipOutputStream`. Such a difference will result in a
`ZipException` with the following message:
```
 java.util.zip.ZipException: invalid entry compressed size (expected
12 but got 7 bytes)
```
The correct way of copying all entries from one zip file into another
requires the creation of a new `ZipEntry` or at least resetting of the
compressed size field. E.g.:
```
 while((entry = zis.getNextEntry()) != null) {
     ZipEntry newEntry = new ZipEntry(entry.getName());
     zos.putNextEntry(newEntry);
     zis.transferTo(zos);
 }
```
or:
```
 while((entry = zis.getNextEntry()) != null) {
     entry.setCompressedSize(-1);
     zos.putNextEntry(entry);
     zis.transferTo(zos);
 }
```
Unfortunately, there's a lot of user code out there which gets this
wrong and uses the bad coding pattern described before. Searching for
`"java.util.zip.ZipException: invalid entry compressed size (expected
12 but got 7 bytes)"` gives ~2500 hits (~100 on StackOverflow). It's
also no hard to find plenty of instances of this anti-pattern on
GitHub when doing a code search for `ZipEntry` and `putNextEntry()`.
E.g. [Gradle 4.x wrapper task][1] is affected as well as the latest
version of the [mockableAndroidJar task][2]. I've recently fixed two
occurrences of this pattern in OpenJDK (see [JDK-8240333][3] and
[JDK-8240235][4]) but there still exist more of them (e.g.
[`test/jdk/java/util/zip/ZipFile/CopyJar.java`][5] which is there
since 1999 :).

### Description

So while this has clearly been a problem before, it apparently wasn't
painful enough to trigger any action from the side of the JDK.
However, recently quite some zlib forks with [superior deflate/inflate
performance have evolved][6]. Using them with OpenJDK is quite
straight-forward: one just has to configure the alternative
implementations by setting `LD_LIBRARY_PATH` or `LD_PRELOAD`
correspondingly. We've seen big saving by using these new zlib
implementations for selected services in production and the only
reason why we haven't enabled them by default until now is the problem
I've just described. The reason why these new libraries uncover the
described anti-pattern much more often is because their compression
ratio is slightly different from that of the default zlib library.
This can easily trigger a `ZipException` even if an application is not
using a different compression levels but just a zip file created with
another zlib version.

I'd therefore like to propose and discuss the following workaround for
the wrong `ZipOutputStream.putNextEntry()` usage in user code:

- add an `@apiNote` to `ZipOutputStream.putNextEntry()` which explains
the problem in order to prevent future authors fromuseing it. I've
drafted a preliminary version of such a note in the [PR][8].

- add a system property to control the usage of `ZipEntry`'s
compressed size field in `ZipOutputStream.putNextEntry()`. The
property can be used to ignore the compressed size if it was
implicitly determined from the zip file and not explicitly set by
calling `ZipEntry.setCompressedSize()`. I've implemented a version of
this idea together with a regression test which demonstrates both, the
bad original behaviour and the mitigation with the help of the new
system property in [PR][8].

### Technical Details

A zip file consists of a stream of File Entries followed by a Central
Directory (see [here for a more detailed specification][7]). Each File
Entry is composed of a Local File Header (LFH) followed by the
compressed Data and an optional Data Descriptor. The LFH contains the
File Name and among other attributes the Compressed and Uncompressed
size and CRC of the Data. In the case where the latter three
attributes are not available at the time when the LFH is created, this
fact will be recorded in a flag of the LFH and will trigger the
creation of a Data Descriptor with the corresponding information right
after the Data section. Finally, the Central Directory contains one
Central Directory File Header (CDFH) for each entry of the zip
archive. The CDFH is an extended version of the LFH and the ultimate
reference for the contents of the zip archive. The redundancy between
LFH and CDFH is a tribute to zip's long history when it was used to
store archives on multiple floppy discs and the CDFH allowed to update
the archive by only writing to the last disc which contained the
Central Directory.

`ZipEntries` read with `ZipInputStream.getNextEntry()` will initially
only contain the information from the LFH. Only after the next entry
was read (or after `ZipInputStream.closeEntry()` was called
explicitly), will the previously read entry be updated with the data
from the Data Descriptor. `ZipInputStream` doesn't inspect the Central
Directory at all.

On the other hand, `ZipFile` only queries the Central Directory for
`ZipEntry` information so all `ZipEntries` returned by
`ZipFile.entries()`, `ZipFile.getEntry()` and `ZipFile.stream()` will
always instantly contain the full Compressed and Uncompressed Size and
CRC information for each entry independently of the LFH contents.

### Risks and Assumptions

If we choose to ignore the implicitly recorded compressed size in a
`ZipEntry` read from a zip file when writing it to a
`ZipOutputStream`, this will lead to zip files with incomplete
information in the LFH and an additional Data Descriptor as described
before. However, the result is still fully compatible to the zip file
specification. It's also not unusual, because by default all new zip
files created with `ZipOutputStream` will contain LFHs without
Compressed and Uncompressed Size and CRC information and an additional
Data Descriptor. Theoretically it is possible to create new zip files
with `ZipOutputStream` class and Compressed and Uncompressed Size and
CRC information in the LFH but that's complex and inefficient because
it requires two steps. A first step to determine the crc and
compressed size of the data and a second step to actually write the
data to the `ZipOutputStream` (which will compress it a second time).
This is because the current API offers no possibility to write already
compressed data to a `ZipOutputStream`.

Consequently, the only straight-forward way of creating zip files from
Java which have all the data in the LFH and no Data Descriptor is by
copying `ZipEntries` from an existing zip file with the buggy method
described before. This incidentally worked more or less reliable for a
long time but breaks miserably when using different zlib
implementations. Ignoring the implicitly set compressed size of
`ZipEntries` can easily fix this problem.

I'm not aware of any tool which can not handle such files and if it
exists it would have problems with the majority of Java created zip
files anyway (e.g. all jar-files created with the jar tool have zip
entries with incomplete LFH data and additional Data Descriptor).

Ignoring the implicitly set compressed size of `ZipEntries` has no
measurable performance impact and will increase the size of zip
archives which used to have the complete file information in the LFH
before by 16 bytes per entry. On the other hand it will give us the
freedom to use whatever zip implementation we like :)


[1]: https://github.com/gradle/gradle/blob/e76905e3a/subprojects/build-init/src/main/java/org/gradle/api/tasks/wrapper/Wrapper.java#L152-L158
[2]: https://android.googlesource.com/platform/tools/base/+/refs/heads/master/build-system/builder/src/main/java/com/android/builder/testing/MockableJarGenerator.java#86
[3]: https://bugs.openjdk.java.net/browse/JDK-8240333
[4]: https://bugs.openjdk.java.net/browse/JDK-8240235
[5]: https://github.com/openjdk/jdk/blob/master/test/jdk/java/util/zip/ZipFile/CopyJar.java
[6]: https://github.com/simonis/zlib-bench/blob/master/Results.md
[7]: https://en.wikipedia.org/wiki/Zip_(file_format)
[8]: https://github.com/openjdk/jdk/pull/489

From smarks at openjdk.java.net  Fri Oct  2 19:45:36 2020
From: smarks at openjdk.java.net (Stuart Marks)
Date: Fri, 2 Oct 2020 19:45:36 GMT
Subject: RFR: 8156071: List.of: reduce array copying during creation
In-Reply-To: <-pkG69_yCpZxK0LBMz3Dw_m2VkTK6BhhWBY02UkidfQ=.c1f424e8-5716-4858-aaa0-488a9e553107@github.com>
References: <-pkG69_yCpZxK0LBMz3Dw_m2VkTK6BhhWBY02UkidfQ=.c1f424e8-5716-4858-aaa0-488a9e553107@github.com>
Message-ID: <VAtMnZfYc0x6JBS8jJjK46q2Q9MXMvyha44oIScWaDE=.0d237575-18b0-465b-b589-359474d1d011@github.com>

On Thu, 1 Oct 2020 00:13:28 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> Plumb new internal static factory method to trust the array passed in, avoiding unnecessary copying. JMH results for
> the benchmark show about 15% improvement for the cases that were optimized, namely the 3 to 10 fixed arg cases.
> # VM options: -verbose:gc -XX:+UseParallelGC -Xms4g -Xmx4g --enable-preview -verbose:gc -XX:+UsePara
> llelGC -Xms4g -Xmx4g -Xint
> # Warmup: 5 iterations, 1 s each
> # Measurement: 5 iterations, 2 s each
> 
> WITHOUT varargs optimization:
> 
> Benchmark         Mode  Cnt     Score     Error   Units
> ListArgs.list00  thrpt   15  6019.539 ? 144.040  ops/ms
> ListArgs.list01  thrpt   15  1985.009 ?  40.606  ops/ms
> ListArgs.list02  thrpt   15  1854.812 ?  17.488  ops/ms
> ListArgs.list03  thrpt   15   963.866 ?  10.262  ops/ms
> ListArgs.list04  thrpt   15   908.116 ?   6.278  ops/ms
> ListArgs.list05  thrpt   15   848.607 ?  16.701  ops/ms
> ListArgs.list06  thrpt   15   822.282 ?   8.905  ops/ms
> ListArgs.list07  thrpt   15   780.057 ?  11.214  ops/ms
> ListArgs.list08  thrpt   15   745.295 ?  19.204  ops/ms
> ListArgs.list09  thrpt   15   704.596 ?  14.003  ops/ms
> ListArgs.list10  thrpt   15   696.436 ?   4.914  ops/ms
> ListArgs.list11  thrpt   15   661.908 ?  11.041  ops/ms
> 
> WITH varargs optimization:
> 
> Benchmark         Mode  Cnt     Score    Error   Units
> ListArgs.list00  thrpt   15  6172.298 ? 62.736  ops/ms
> ListArgs.list01  thrpt   15  1987.724 ? 45.468  ops/ms
> ListArgs.list02  thrpt   15  1843.419 ? 10.693  ops/ms
> ListArgs.list03  thrpt   15  1126.946 ? 30.952  ops/ms
> ListArgs.list04  thrpt   15  1050.440 ? 17.859  ops/ms
> ListArgs.list05  thrpt   15   999.275 ? 23.656  ops/ms
> ListArgs.list06  thrpt   15   948.844 ? 19.615  ops/ms
> ListArgs.list07  thrpt   15   897.541 ? 15.531  ops/ms
> ListArgs.list08  thrpt   15   853.359 ? 18.755  ops/ms
> ListArgs.list09  thrpt   15   826.394 ?  8.284  ops/ms
> ListArgs.list10  thrpt   15   779.231 ?  4.104  ops/ms
> ListArgs.list11  thrpt   15   650.888 ?  3.948  ops/ms

After a hint from @cl4es I ran the benchmarks with `-prof gc`. The allocation rate is reduced by about 40% per
operation in the cases where the optimization was applied.

WITHOUT varargs optimization:

ListArgs.list00:?gc.alloc.rate.norm           thrpt    5    ? 10??               B/op
ListArgs.list01:?gc.alloc.rate.norm           thrpt    5    24.000 ?    0.001    B/op
ListArgs.list02:?gc.alloc.rate.norm           thrpt    5    24.000 ?    0.001    B/op
ListArgs.list03:?gc.alloc.rate.norm           thrpt    5    80.000 ?    0.001    B/op
ListArgs.list04:?gc.alloc.rate.norm           thrpt    5    80.036 ?    0.309    B/op
ListArgs.list05:?gc.alloc.rate.norm           thrpt    5    96.037 ?    0.316    B/op
ListArgs.list06:?gc.alloc.rate.norm           thrpt    5    96.038 ?    0.326    B/op
ListArgs.list07:?gc.alloc.rate.norm           thrpt    5   112.042 ?    0.361    B/op
ListArgs.list08:?gc.alloc.rate.norm           thrpt    5   112.043 ?    0.367    B/op
ListArgs.list09:?gc.alloc.rate.norm           thrpt    5   128.045 ?    0.385    B/op
ListArgs.list10:?gc.alloc.rate.norm           thrpt    5   128.046 ?    0.391    B/op
ListArgs.list11:?gc.alloc.rate.norm           thrpt    5   144.047 ?    0.406    B/op

WITH varargs optimization:

ListArgs.list00:?gc.alloc.rate.norm           thrpt    5    ? 10??               B/op
ListArgs.list01:?gc.alloc.rate.norm           thrpt    5    24.000 ?    0.001    B/op
ListArgs.list02:?gc.alloc.rate.norm           thrpt    5    24.000 ?    0.001    B/op
ListArgs.list03:?gc.alloc.rate.norm           thrpt    5    48.000 ?    0.001    B/op
ListArgs.list04:?gc.alloc.rate.norm           thrpt    5    48.000 ?    0.001    B/op
ListArgs.list05:?gc.alloc.rate.norm           thrpt    5    56.000 ?    0.001    B/op
ListArgs.list06:?gc.alloc.rate.norm           thrpt    5    56.000 ?    0.001    B/op
ListArgs.list07:?gc.alloc.rate.norm           thrpt    5    64.000 ?    0.001    B/op
ListArgs.list08:?gc.alloc.rate.norm           thrpt    5    64.000 ?    0.001    B/op
ListArgs.list09:?gc.alloc.rate.norm           thrpt    5    72.000 ?    0.001    B/op
ListArgs.list10:?gc.alloc.rate.norm           thrpt    5    72.000 ?    0.001    B/op
ListArgs.list11:?gc.alloc.rate.norm           thrpt    5   144.050 ?    0.427    B/op

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

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

From rriggs at openjdk.java.net  Fri Oct  2 20:18:37 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 2 Oct 2020 20:18:37 GMT
Subject: RFR: 8251989: Hex formatting and parsing utility
In-Reply-To: <E4uO8-HUWk8Yyetoq_zp-U3QsEUsA2cWMWs23AcTAss=.25b2feca-d571-44ae-9871-74455fe32619@github.com>
References: <HSEn47GMS1K3g57mrTZeQk-WZHl3pKGHpX_OOf8VnsU=.740863c2-f9e4-43c4-b500-614aab4078b1@github.com>
 <E4uO8-HUWk8Yyetoq_zp-U3QsEUsA2cWMWs23AcTAss=.25b2feca-d571-44ae-9871-74455fe32619@github.com>
Message-ID: <LilzVg5AkGDhPfEuKl6kh2eRblrElgFGCe5K1ZufuQ0=.bdd4829f-fa59-4357-89cf-563a32048529@github.com>

On Fri, 2 Oct 2020 18:12:36 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> java.util.HexFormat utility:
>> 
>>  - Format and parse hexadecimal strings, with parameters for delimiter, prefix, suffix and upper/lowercase
>>  - Static factories and builder methods to create HexFormat copies with modified parameters.
>>  - Consistent naming of methods for conversion of byte arrays to formatted strings and back: formatHex and parseHex
>>  - Consistent naming of methods for conversion of primitive types: toHexDigits... and fromHexDigits...
>>  - Prefix and suffixes now apply to each formatted value, not the string as a whole
>>  - Using java.util.Appendable as a target for buffered conversions so output to Writers and PrintStreams
>>    like System.out are supported in addition to StringBuilder. (IOExceptions are converted to unchecked exceptions)
>>  - Immutable and thread safe, a "value-based" class
>> 
>> See the [HexFormat
>> javadoc](http://cr.openjdk.java.net/~rriggs/8251989-hex-formatter/java.base/java/util/HexFormat.html) for details.
>> Review comments and suggestions welcome.
>
> src/java.base/share/classes/java/util/HexFormat.java line 213:
> 
>> 211:      * @param delimiter the {@code delimiter}, non-null, may be empty
>> 212:      * @return a copy of this {@code HexFormat} with the {@code delimiter}
>> 213:      */
> 
> Is this very useful now that we already have `ofDelimeter(String)`?

withDelimiter(delim) is there for symmetry and completeness, the same goes for withLowercase().
You could start with HexFormat.of() and then augment it withDelimiter().

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

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

From rriggs at openjdk.java.net  Fri Oct  2 20:21:38 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 2 Oct 2020 20:21:38 GMT
Subject: RFR: 8251989: Hex formatting and parsing utility
In-Reply-To: <E4uO8-HUWk8Yyetoq_zp-U3QsEUsA2cWMWs23AcTAss=.25b2feca-d571-44ae-9871-74455fe32619@github.com>
References: <HSEn47GMS1K3g57mrTZeQk-WZHl3pKGHpX_OOf8VnsU=.740863c2-f9e4-43c4-b500-614aab4078b1@github.com>
 <E4uO8-HUWk8Yyetoq_zp-U3QsEUsA2cWMWs23AcTAss=.25b2feca-d571-44ae-9871-74455fe32619@github.com>
Message-ID: <LvxxngI4eIpf81LEUfsDfvtNypqxeHwS4-ioIubCFPs=.e30963eb-2ccc-4278-8ce8-f44fccee1a83@github.com>

On Fri, 2 Oct 2020 18:14:32 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> java.util.HexFormat utility:
>> 
>>  - Format and parse hexadecimal strings, with parameters for delimiter, prefix, suffix and upper/lowercase
>>  - Static factories and builder methods to create HexFormat copies with modified parameters.
>>  - Consistent naming of methods for conversion of byte arrays to formatted strings and back: formatHex and parseHex
>>  - Consistent naming of methods for conversion of primitive types: toHexDigits... and fromHexDigits...
>>  - Prefix and suffixes now apply to each formatted value, not the string as a whole
>>  - Using java.util.Appendable as a target for buffered conversions so output to Writers and PrintStreams
>>    like System.out are supported in addition to StringBuilder. (IOExceptions are converted to unchecked exceptions)
>>  - Immutable and thread safe, a "value-based" class
>> 
>> See the [HexFormat
>> javadoc](http://cr.openjdk.java.net/~rriggs/8251989-hex-formatter/java.base/java/util/HexFormat.html) for details.
>> Review comments and suggestions welcome.
>
> src/java.base/share/classes/java/util/HexFormat.java line 290:
> 
>> 288:      * @return returns {@code true} if the hexadecimal digits will be uppercase,
>> 289:      *          otherwise {@code false}
>> 290:      */
> 
> Can someone choose their own `digits`? If not, how about "=="?

I don't think it would be called HexFormat doing Hexadecimal conversions if it could be an arbitrary set of digits.
The Arrays.equals implementation contains the == test so its implementers choice.

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

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

From rriggs at openjdk.java.net  Fri Oct  2 20:38:38 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 2 Oct 2020 20:38:38 GMT
Subject: RFR: 8251989: Hex formatting and parsing utility
In-Reply-To: <E4uO8-HUWk8Yyetoq_zp-U3QsEUsA2cWMWs23AcTAss=.25b2feca-d571-44ae-9871-74455fe32619@github.com>
References: <HSEn47GMS1K3g57mrTZeQk-WZHl3pKGHpX_OOf8VnsU=.740863c2-f9e4-43c4-b500-614aab4078b1@github.com>
 <E4uO8-HUWk8Yyetoq_zp-U3QsEUsA2cWMWs23AcTAss=.25b2feca-d571-44ae-9871-74455fe32619@github.com>
Message-ID: <tdhXqYoXDTi2xWgTBeTjhiGbzpu4RFFD_PTbR_uIiAs=.ae174fba-abd9-489a-b252-8036195ec829@github.com>

On Fri, 2 Oct 2020 19:14:14 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> The class name already has `Hex` inside, and methods names still contain it. Also, I found it unexpected that
> `fromHexDigits` returns an integer. Can we use `encode`, `decode`, `decodeInt`, `decodeLong` etc?

Including 'Hex' in the method names reinforces the function, without it, more context is required to make the code
readable.

The decoding of hexadecimal digits to a binary number is at its core untyped and unsigned for all three fromHexDigits
methods. A signed type such as byte does implicit sign extension and in many use cases it would need to be masked
before the value is used. An explicit cast in the source to a smaller primitive makes the use clearer explicit.

The formatHex and parseHex methods operating on byte arrays are quite different than toHexDigits and fromHexDigits.
When operating on byte arrays, the prefix, suffix, and delimiter are included in the conversion.
The toHexDigits and fromHexDigits methods do not include prefix and suffix, and delimiter and just convert.
The different naming helps create a clear distinction.  Also it was mentioned in comments on the first version of the
API, that encode and decode can be ambiguous as to which direction the conversion is going.

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

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

From psandoz at openjdk.java.net  Fri Oct  2 20:41:45 2020
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Fri, 2 Oct 2020 20:41:45 GMT
Subject: RFR: 8156071: List.of: reduce array copying during creation
In-Reply-To: <-pkG69_yCpZxK0LBMz3Dw_m2VkTK6BhhWBY02UkidfQ=.c1f424e8-5716-4858-aaa0-488a9e553107@github.com>
References: <-pkG69_yCpZxK0LBMz3Dw_m2VkTK6BhhWBY02UkidfQ=.c1f424e8-5716-4858-aaa0-488a9e553107@github.com>
Message-ID: <wgUqYY_pcHsD2y5zL7eSmlQubVzCxw7MjOKoQia1Cf4=.b2f66e7b-4c61-49f7-a036-e5b9b0ab562d@github.com>

On Thu, 1 Oct 2020 00:13:28 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> Plumb new internal static factory method to trust the array passed in, avoiding unnecessary copying. JMH results for
> the benchmark show about 15% improvement for the cases that were optimized, namely the 3 to 10 fixed arg cases.
> # VM options: -verbose:gc -XX:+UseParallelGC -Xms4g -Xmx4g --enable-preview -verbose:gc -XX:+UsePara
> llelGC -Xms4g -Xmx4g -Xint
> # Warmup: 5 iterations, 1 s each
> # Measurement: 5 iterations, 2 s each
> 
> WITHOUT varargs optimization:
> 
> Benchmark         Mode  Cnt     Score     Error   Units
> ListArgs.list00  thrpt   15  6019.539 ? 144.040  ops/ms
> ListArgs.list01  thrpt   15  1985.009 ?  40.606  ops/ms
> ListArgs.list02  thrpt   15  1854.812 ?  17.488  ops/ms
> ListArgs.list03  thrpt   15   963.866 ?  10.262  ops/ms
> ListArgs.list04  thrpt   15   908.116 ?   6.278  ops/ms
> ListArgs.list05  thrpt   15   848.607 ?  16.701  ops/ms
> ListArgs.list06  thrpt   15   822.282 ?   8.905  ops/ms
> ListArgs.list07  thrpt   15   780.057 ?  11.214  ops/ms
> ListArgs.list08  thrpt   15   745.295 ?  19.204  ops/ms
> ListArgs.list09  thrpt   15   704.596 ?  14.003  ops/ms
> ListArgs.list10  thrpt   15   696.436 ?   4.914  ops/ms
> ListArgs.list11  thrpt   15   661.908 ?  11.041  ops/ms
> 
> WITH varargs optimization:
> 
> Benchmark         Mode  Cnt     Score    Error   Units
> ListArgs.list00  thrpt   15  6172.298 ? 62.736  ops/ms
> ListArgs.list01  thrpt   15  1987.724 ? 45.468  ops/ms
> ListArgs.list02  thrpt   15  1843.419 ? 10.693  ops/ms
> ListArgs.list03  thrpt   15  1126.946 ? 30.952  ops/ms
> ListArgs.list04  thrpt   15  1050.440 ? 17.859  ops/ms
> ListArgs.list05  thrpt   15   999.275 ? 23.656  ops/ms
> ListArgs.list06  thrpt   15   948.844 ? 19.615  ops/ms
> ListArgs.list07  thrpt   15   897.541 ? 15.531  ops/ms
> ListArgs.list08  thrpt   15   853.359 ? 18.755  ops/ms
> ListArgs.list09  thrpt   15   826.394 ?  8.284  ops/ms
> ListArgs.list10  thrpt   15   779.231 ?  4.104  ops/ms
> ListArgs.list11  thrpt   15   650.888 ?  3.948  ops/ms

Looks good, i wondered why the performance results were so slow then i looked more closely and saw "-Xint" was used. I
usually don't ascribe much value to micro benchmarks run in interpreter only mode, but hey any shaving off startup time
is welcome. Less allocation is definitely welcome (although i do wish C2 was better at eliding redundant array
initialization and allocation).

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

Marked as reviewed by psandoz (Reviewer).

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

From Roger.Riggs at oracle.com  Fri Oct  2 20:42:50 2020
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Fri, 2 Oct 2020 16:42:50 -0400
Subject: RFR: 8251989: Hex formatting and parsing utility
In-Reply-To: <A383530B-F96B-452C-BBF0-0DCBB844D479@oracle.com>
References: <mailman.5210.1601654030.25523.core-libs-dev@openjdk.java.net>
 <A383530B-F96B-452C-BBF0-0DCBB844D479@oracle.com>
Message-ID: <87cc33eb-5340-cdb7-7c74-ebba2af83c8a@oracle.com>

Hi Douglas,

The javadoc and descriptions of prefix and suffix could use some 
reinforcement
that they apply only to the formatted bytes of the array.
Adding Byte to the method names makes them a bit unwieldy.

Thanks, Roger

On 10/2/20 12:16 PM, Douglas Surber wrote:
> This looks good overall. I would change the names of withPrefix and withSuffix to withBytePrefix and withByteSuffix and add some words to their JavaDoc clarifying that they  apply to the individual bytes.
>
> Douglas
>
>
> PR: https://git.openjdk.java.net/jdk/pull/482 <https://git.openjdk.java.net/jdk/pull/482>
>


From iignatyev at openjdk.java.net  Fri Oct  2 20:46:48 2020
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Fri, 2 Oct 2020 20:46:48 GMT
Subject: RFR: 8253750: use build-stable default seed for
 Utils.RANDOM_GENERATOR [v2]
In-Reply-To: <RQa3EOXeDAni1G-mu_jM-I9mosypb0gnuLUmFCtGhGo=.92a4f06b-60df-49b6-b6e3-bcf11e7530ab@github.com>
References: <RQa3EOXeDAni1G-mu_jM-I9mosypb0gnuLUmFCtGhGo=.92a4f06b-60df-49b6-b6e3-bcf11e7530ab@github.com>
Message-ID: <D-CpLwXgIf54u15Yjd0XkHH9Rdakox0qUsEsoU8arxQ=.951a1d6c-6d9b-4a27-b9d5-64c9409b5633@github.com>

> Hi all,
> 
> could you please review the patch which updates `jdk.test.lib.Utils` to use md5 hash-sum of `java.vm.version` property
> as default seed for `Utils.RANDOM_GENERATOR`?
> from JBS:
>> using the same seed for all runs of a build will make it possible (easier) to compare results from different test runs
>> (e.g. on different platforms, w/ different flags) and consequently will make test results analysis easier. the proposed
>> solution is to use the seed based on Runtime.version() / "java.vm.version", which are different from build to build, if
>> there is no seed specified by "jdk.test.lib.random.seed" property.
> 
> the patch also updates `RandomGeneratorTest` test, so it expects now that the same values are generated if no seed is
> provided.
> testing: ? tier1

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

  used Runtime.version() instead of ${java.vm.version}
  updated javadoc

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/391/files
  - new: https://git.openjdk.java.net/jdk/pull/391/files/b5437f75..381e14f7

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

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

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

From iignatyev at openjdk.java.net  Fri Oct  2 20:50:38 2020
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Fri, 2 Oct 2020 20:50:38 GMT
Subject: RFR: 8253750: use build-stable default seed for
 Utils.RANDOM_GENERATOR [v2]
In-Reply-To: <mo0lfq_iw1eyJBqdTO7yWC-j2a--ZZiYdtkzGGcquwg=.b3b947ce-fd62-4c27-ac65-37b7380b80b0@github.com>
References: <RQa3EOXeDAni1G-mu_jM-I9mosypb0gnuLUmFCtGhGo=.92a4f06b-60df-49b6-b6e3-bcf11e7530ab@github.com>
 <mo0lfq_iw1eyJBqdTO7yWC-j2a--ZZiYdtkzGGcquwg=.b3b947ce-fd62-4c27-ac65-37b7380b80b0@github.com>
Message-ID: <jFT7OUgGs2nhE7uyRwzcyNIJRQ6VUBBtqhF5Depcdk0=.8d6bb43a-72a1-4a2b-a092-ef55dffeea75@github.com>

On Fri, 2 Oct 2020 18:46:39 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Igor Ignatyev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   used Runtime.version() instead of ${java.vm.version}
>>   updated javadoc
>
> ok, if I read the code closely and know how the promoted build process works then I see your rationale.
> Please update the bug report and edit the PR description to describe the conditions under which the seed
> for random is computed from the build number. Its might be clearer to refer to the Runtime.Version build information
> in the description.  Also make it clear that unless the system property is set, it will use a 'random' seed.

@RogerRiggs , I have updated the code to use `Runtime::version` and updated the docs to better reflect how `seed` value
is being set, as well as added some explanation to both the JBS issue and PR. please let me know if it's still not
clear enough.

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

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

From zgu at openjdk.java.net  Fri Oct  2 21:07:43 2020
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Fri, 2 Oct 2020 21:07:43 GMT
Subject: RFR: 8253948: Memory leak in ImageFileReader
Message-ID: <yAHLpx1yD7FfAOAhEqrSV0r_xb6sRkbhhC3UIo1AlTA=.73f7defb-4fa1-426d-865a-34b1a63aef9a@github.com>

ImageFileReader allocates ImageModuleData in ImageFileReader::open(), but never free.

Also renamed module_data to _module_data to be consistent with other member variables.

Test:
- [x] tier1 on Linux x86_64

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

Commit messages:
 - 8253948: Memory leak in ImageFileReader

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

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

From mchung at openjdk.java.net  Fri Oct  2 21:56:38 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Fri, 2 Oct 2020 21:56:38 GMT
Subject: RFR: 8204256: improve jlink error message to report unsupported
 class file format [v2]
In-Reply-To: <nJbYVfIPDYdgsMc-z11yd_EQXSUjUfzGyDTGkNgL4w8=.6da132ea-f04e-49e3-a072-4572e4f414c5@github.com>
References: <fc0WYkvegw3_1RBfXVVy7Vs6HcX7b9UIq7fZ2kK4cCY=.218de7d9-7abf-4eec-af30-d2926464349c@github.com>
 <qGVlFtUbSi5Uo7ZVOhgIFjaBYjpD-5yo7_nPWOcbWQA=.81eefc43-09be-4c89-a018-d0de0f9d1292@github.com>
 <UOeX1EtrXyzdkhFeBx-prDjTGZwWh1my4NSODNZQwYg=.ef69bb7d-d883-47e3-b080-3dbabc45f104@github.com>
 <nJbYVfIPDYdgsMc-z11yd_EQXSUjUfzGyDTGkNgL4w8=.6da132ea-f04e-49e3-a072-4572e4f414c5@github.com>
Message-ID: <ABfr9TlMBFwU3SYHsjHAJbqwOCOLbnyzsIGOSZAYlvE=.01d36959-3220-4685-86c7-eb56505627e7@github.com>

On Fri, 2 Oct 2020 09:34:59 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Given that linking with JMODs of an unsupported class file version is rare case,
>> it's not a bad choice to go with this simplest solution printing the stack trace.
>
> What if we removed the handling of specific exceptions from L278-L285 so that the special handling is limited to
> BadArgs? If anything other than BadArgs is throw then it can print the exception to log output along with the cause (if
> not null). No objection. That might avoid the tool emitting a "scary" stack trace when an error occurs.

I think for `ResolutionException` and IAE (and possibly `PluginException`), the exception message should be helpful
enough to correct for example user-errors and that's why this special catch block.

Having another look, I think `FindException` may just fall into the last `Throwable` handler.   The new catch block may
not be needed.

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

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

From mchung at openjdk.java.net  Fri Oct  2 22:50:44 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Fri, 2 Oct 2020 22:50:44 GMT
Subject: RFR: 8247666: Support Lambda proxy classes in static CDS archive
 [v3]
In-Reply-To: <pvSPAXeOsA-4mxsmAMzKbw8qeAxizhxzDrajr9p7cy4=.004ba246-f90e-4926-b4ec-19bead011c86@github.com>
References: <ynh4JzHY75GjEn5_oCtmRNy9HMFsU34O2PlhSwD41tU=.1a3770f9-9091-429f-8d03-31b826f9b093@github.com>
 <pvSPAXeOsA-4mxsmAMzKbw8qeAxizhxzDrajr9p7cy4=.004ba246-f90e-4926-b4ec-19bead011c86@github.com>
Message-ID: <Ao0IiVWZYxqktD3M6lqoxTGlURbSnX3-vg3LKoU-mls=.13c222b0-69c4-40d7-b35e-887c934dbe77@github.com>

On Fri, 2 Oct 2020 16:30:01 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> Following up on archiving lambda proxy classes in dynamic CDS archive
>> ([JDK-8198698](https://bugs.openjdk.java.net/browse/JDK-8198698)), this RFE adds the functionality of archiving of
>> lambda proxy classes in static CDS archive.
>> When the -XX:DumpLoadedClassList is enabled, the constant pool index related to LambdaMetafactory that are resolved
>> during application execution will be included in the classlist. The entry for a lambda proxy class in a class list will
>> be of the following format:
>> `@lambda-proxy: <classname> <cp index>`
>> 
>> e.g.
>> `@lambda-proxy: test/java/lang/invoke/MethodHandlesGeneralTest 233`
>> `@lambda-proxy: test/java/lang/invoke/MethodHandlesGeneralTest 355`
>> 
>> When dumping a CDS archive using the -Xshare:dump and -XX:ExtraSharedClassListFile options, when the above
>> `@lambda-proxy` entry is encountered while parsing the classlist, we will resolve the corresponding constant pool
>> indices (233 and 355 in the above example). As a result, lambda proxy classes will be generated for the constant pool
>> entries, and will be cached using a similar mechanism to JDK-8198698.  During dumping, there is check on the cp index
>> and on the created BootstrapInfo using the cp index. VM will exit with an error message if the check has failed.
>> During runtime when looking up a lambda proxy class, the lookup will be perform on the static CDS archive and if not
>> found, then lookup from the dynamic archive if one is specified.  (Only name change (IsDynamicDumpingEnabled ->
>> IsCDSDumpingEnabled) is involved in the core-libs code.)
>> Testing: tiers 1,2,3,4.
>> 
>> Performance results (javac on HelloWorld on linux-x64):
>> Results of " perf stat -r 40 bin/javac -J-Xshare:on -J-XX:SharedArchiveFile=javac2.jsa Bench_HelloWorld.java "
>>    1:   2228016795  2067752708 (-160264087)      -----    377.760   349.110 (-28.650)      -----
>>    2:   2223051476  2063016483 (-160034993)      -----    374.580   350.620 (-23.960)      ----
>>    3:   2225908334  2067673847 (-158234487)      -----    375.220   350.990 (-24.230)      ----
>>    4:   2225835999  2064596883 (-161239116)      -----    374.670   349.840 (-24.830)      ----
>>    5:   2226005510  2061694332 (-164311178)      -----    373.512   351.120 (-22.392)      ----
>>    6:   2225574949  2062657482 (-162917467)      -----    374.710   348.380 (-26.330)      -----
>>    7:   2224702424  2064634122 (-160068302)      -----    373.670   349.510 (-24.160)      ----
>>    8:   2226662277  2066301134 (-160361143)      -----    375.350   349.790 (-25.560)      ----
>>    9:   2226761470  2063162795 (-163598675)      -----    374.260   351.290 (-22.970)      ----
>>   10:   2230149089  2066203307 (-163945782)      -----    374.760   350.620 (-24.140)      ----
>> ============================================================
>>         2226266109  2064768307 (-161497801)      -----    374.848   350.126 (-24.722)      ----
>> instr delta =   -161497801    -7.2542%
>> time  delta =      -24.722 ms -6.5951%
>
> Calvin Cheung has updated the pull request with a new target base 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 8247666
>  - exclude archived lambda proxy classes in the classlist
>  - updated systemDictionaryShared.[c|h]pp based on suggestions from Ioi
>  - fix extraneous whitespace
>  - 8247666 (initial commit)

> @lambda-proxy: test/java/lang/invoke/MethodHandlesGeneralTest 233
@lambda-proxy: test/java/lang/invoke/MethodHandlesGeneralTest 355

It seems very fragile to require listing the CP index to `invokedynamic` entries of a class file.   Have you considered
a simpler usage model without CP indices and default to all `invokedynamic` to `LambdaMetaFactory`?

src/java.base/share/classes/jdk/internal/misc/CDS.java line 56:

> 54:      * Check if CDS dumping is enabled via the DynamicDumpSharedSpaces or the DumpSharedSpaces flag.
> 55:      */
> 56:     public static native boolean isCDSDumpingEnabled();

I suggest to rename `CDS::isCDSDumpingEnabled` to `CDS:isDumpingEnabled` as this method is a static method in `CDS`
case and the word `CDS` in the method name is just noise.

JVM entry point `JVM_IsCDSDumpingEnabled`  is good.

src/hotspot/share/prims/jvm.cpp line 3834:

> 3832:
> 3833: JVM_ENTRY(jboolean, JVM_IsCDSDumpingEnabled(JNIEnv* env))
> 3834:     JVMWrapper("JVM_IsCDSDumpingEnable");

typo: missing `d` s/Enable/Enabled/

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

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

From zgu at openjdk.java.net  Fri Oct  2 23:12:38 2020
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Fri, 2 Oct 2020 23:12:38 GMT
Subject: RFR: 8253948: Memory leak in ImageFileReader
In-Reply-To: <yAHLpx1yD7FfAOAhEqrSV0r_xb6sRkbhhC3UIo1AlTA=.73f7defb-4fa1-426d-865a-34b1a63aef9a@github.com>
References: <yAHLpx1yD7FfAOAhEqrSV0r_xb6sRkbhhC3UIo1AlTA=.73f7defb-4fa1-426d-865a-34b1a63aef9a@github.com>
Message-ID: <XTSINriFFV75mpXz3_XTZE-_xm38AEYWCpEBw3sqbzs=.2ee13dca-8bbd-4609-b4db-4973eb767dcf@github.com>

On Fri, 2 Oct 2020 20:47:16 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> ImageFileReader allocates ImageModuleData in ImageFileReader::open(), but never free.
> 
> Also renamed module_data to _module_data to be consistent with other member variables.
> 
> Test:
> - [x] tier1 on Linux x86_64

ImageFileReader is also used in hotspot runtime

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

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

From rriggs at openjdk.java.net  Fri Oct  2 23:13:39 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 2 Oct 2020 23:13:39 GMT
Subject: RFR: 8253750: use build-stable default seed for
 Utils.RANDOM_GENERATOR [v2]
In-Reply-To: <D-CpLwXgIf54u15Yjd0XkHH9Rdakox0qUsEsoU8arxQ=.951a1d6c-6d9b-4a27-b9d5-64c9409b5633@github.com>
References: <RQa3EOXeDAni1G-mu_jM-I9mosypb0gnuLUmFCtGhGo=.92a4f06b-60df-49b6-b6e3-bcf11e7530ab@github.com>
 <D-CpLwXgIf54u15Yjd0XkHH9Rdakox0qUsEsoU8arxQ=.951a1d6c-6d9b-4a27-b9d5-64c9409b5633@github.com>
Message-ID: <NX_cAjZJPewgSzG-OEjdddnm0q8furdjLseCx9KlnXM=.9c5a6fc5-6537-47c3-9981-38659d5bbc76@github.com>

On Fri, 2 Oct 2020 20:46:48 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

>> Hi all,
>> 
>> could you please review the patch which updates `jdk.test.lib.Utils` to use md5 hash-sum of `java.vm.version` property
>> as default seed for `Utils.RANDOM_GENERATOR`?
>> from JBS:
>>> using the same seed for all runs of a build will make it possible (easier) to compare results from different test runs
>>> (e.g. on different platforms, w/ different flags) and consequently will make test results analysis easier. the proposed
>>> solution is to use the seed based on Runtime.version() / "java.vm.version", which are different from build to build, if
>>> there is no seed specified by "jdk.test.lib.random.seed" property.
>> 
>> the patch also updates `RandomGeneratorTest` test, so it expects now that the same values are generated if no seed is
>> provided.
>> testing: ? tier1
>
> Igor Ignatyev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   used Runtime.version() instead of ${java.vm.version}
>   updated javadoc

The code and description are reversed from what I suggested.

The seed should *only* be computed from the version information if it is a promoted or weekly build.
All other builds should use a random seed.

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

Changes requested by rriggs (Reviewer).

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

From zgu at openjdk.java.net  Sat Oct  3 00:12:42 2020
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Sat, 3 Oct 2020 00:12:42 GMT
Subject: RFR: 8253960: Memory leak in Java_java_lang_ClassLoader_defineClass0()
Message-ID: <BAK4q1qNuAQOQB5TRrxP6jLQEFIjvGJG1FWYItkE35A=.26aa8616-1922-483e-ac70-6f77a3aa5e53@github.com>

The memory leak is quite obvious. Early return results 'body' not been released.

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

Commit messages:
 - 8253960: Memory leak in Java_java_lang_ClassLoader_defineClass0()

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

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

From mchung at openjdk.java.net  Sat Oct  3 02:02:37 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Sat, 3 Oct 2020 02:02:37 GMT
Subject: RFR: 8253960: Memory leak in
 Java_java_lang_ClassLoader_defineClass0()
In-Reply-To: <BAK4q1qNuAQOQB5TRrxP6jLQEFIjvGJG1FWYItkE35A=.26aa8616-1922-483e-ac70-6f77a3aa5e53@github.com>
References: <BAK4q1qNuAQOQB5TRrxP6jLQEFIjvGJG1FWYItkE35A=.26aa8616-1922-483e-ac70-6f77a3aa5e53@github.com>
Message-ID: <D11SfyGeclw7_oDh4WRsDBi--pD0qLbu-uEZxRd0TaA=.bc311271-ac4b-41a3-8fc7-4f880ab0f4d8@github.com>

On Sat, 3 Oct 2020 00:05:40 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> The memory leak is quite obvious. Early return results 'body' not been released.
> 
> Test:
> 
> - [x] tier1 on Linux x86_64

Thanks for catching this.  Looks good.

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

Marked as reviewed by mchung (Reviewer).

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

From stuefe at openjdk.java.net  Sat Oct  3 05:27:37 2020
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Sat, 3 Oct 2020 05:27:37 GMT
Subject: RFR: 8253960: Memory leak in
 Java_java_lang_ClassLoader_defineClass0()
In-Reply-To: <BAK4q1qNuAQOQB5TRrxP6jLQEFIjvGJG1FWYItkE35A=.26aa8616-1922-483e-ac70-6f77a3aa5e53@github.com>
References: <BAK4q1qNuAQOQB5TRrxP6jLQEFIjvGJG1FWYItkE35A=.26aa8616-1922-483e-ac70-6f77a3aa5e53@github.com>
Message-ID: <JvlUD-C0c534YZXeTJdajeM_y4ZSrXCyWev_0CyFelE=.0aa98494-50d6-458a-ae2f-7df0481a71f1@github.com>

On Sat, 3 Oct 2020 00:05:40 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> The memory leak is quite obvious. Early return results 'body' not been released.
> 
> Test:
> 
> - [x] tier1 on Linux x86_64

Look good!

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

Marked as reviewed by stuefe (Reviewer).

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

From alanb at openjdk.java.net  Sat Oct  3 06:10:36 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sat, 3 Oct 2020 06:10:36 GMT
Subject: RFR: 8253960: Memory leak in
 Java_java_lang_ClassLoader_defineClass0()
In-Reply-To: <BAK4q1qNuAQOQB5TRrxP6jLQEFIjvGJG1FWYItkE35A=.26aa8616-1922-483e-ac70-6f77a3aa5e53@github.com>
References: <BAK4q1qNuAQOQB5TRrxP6jLQEFIjvGJG1FWYItkE35A=.26aa8616-1922-483e-ac70-6f77a3aa5e53@github.com>
Message-ID: <oGIt_fS5cVMw-7i-AAUhbdCubIQyAzc1CAbx5x65gjc=.8f1456fa-beef-4204-a54e-9fc4a6172ec8@github.com>

On Sat, 3 Oct 2020 00:05:40 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> The memory leak is quite obvious. Early return results 'body' not been released.
> 
> Test:
> 
> - [x] tier1 on Linux x86_64

Should this be renamed to "Memory leak in Lookup.defineClass"? I don't think it impacts anything extending or using the
ClassLoader.

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

Marked as reviewed by alanb (Reviewer).

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

From alanb at openjdk.java.net  Sat Oct  3 16:20:37 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sat, 3 Oct 2020 16:20:37 GMT
Subject: RFR: 8253948: Memory leak in ImageFileReader
In-Reply-To: <yAHLpx1yD7FfAOAhEqrSV0r_xb6sRkbhhC3UIo1AlTA=.73f7defb-4fa1-426d-865a-34b1a63aef9a@github.com>
References: <yAHLpx1yD7FfAOAhEqrSV0r_xb6sRkbhhC3UIo1AlTA=.73f7defb-4fa1-426d-865a-34b1a63aef9a@github.com>
Message-ID: <Elpk6jjUdqnP2idwIf7DZ8SwZD1AqRn8O9bYxmrcuoc=.149ea544-f9d0-490c-b2da-f9191ff41293@github.com>

On Fri, 2 Oct 2020 20:47:16 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> ImageFileReader allocates ImageModuleData in ImageFileReader::open(), but never free.
> 
> Also renamed module_data to _module_data to be consistent with other member variables.
> 
> Test:
> - [x] tier1 on Linux x86_64

The jimage file is opened at startup and should never be closed. However the jrtfs provider (used by IDEs and other
tools to access the resources in a target run-time image) may run into it so good to get it fixed.

Can you fix the formatting to use 4-space indentation consistently?

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

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

From Alan.Bateman at oracle.com  Sat Oct  3 19:11:10 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 3 Oct 2020 20:11:10 +0100
Subject: Request for Discussion: 8253952: Work around wrong usage of
 ZipOutputStream.putNextEntry() in user code
In-Reply-To: <CA+3eh12_-fNxf_KFK68WEqVoD_n6CD7RCbe=LoKCyCeUQ3w0oQ@mail.gmail.com>
References: <CA+3eh12_-fNxf_KFK68WEqVoD_n6CD7RCbe=LoKCyCeUQ3w0oQ@mail.gmail.com>
Message-ID: <4658d3a6-3360-fb84-e5ff-20dc6cc61b92@oracle.com>

On 02/10/2020 20:44, Volker Simonis wrote:
> Hi,
>
> I'd like to get your opinion on a workaround for a common but wrong
> usage pattern of ZipOutputStream.putNextEntry() in user code. I've
> created a Draft PR with all the gory details (which I'll include here
> for your convenience). Please let me know what you think?
>
java.util.zip is JDK 1.1 era API and has several usability issues.Yes, 
ZOS.putNextEntry method can be a hazard. Adding an @apiNote with an 
example showing how to use API correctly shouldn't be an issue. I don't 
think the proposal to add a system property to change the behavior is 
feasible, at least not without changing the spec but even then it would 
be very icky. Have you explored adding a better API instead of a 
workaround? It wouldn't be hard to have ZipEntry define a writeTo or 
transferTo method for example.

-Alan.

From enikitin at openjdk.java.net  Sat Oct  3 19:15:00 2020
From: enikitin at openjdk.java.net (Evgeny Nikitin)
Date: Sat, 3 Oct 2020 19:15:00 GMT
Subject: RFR: 8229186: Improve error messages for TestStringIntrinsics
 failures [v9]
In-Reply-To: <Br6z5yt0kTbZwIQyTI9lz7czaYpjw5vCd5ZCbbrSIcM=.6a8096f1-91ed-4673-bab3-3bfae758ab95@github.com>
References: <Br6z5yt0kTbZwIQyTI9lz7czaYpjw5vCd5ZCbbrSIcM=.6a8096f1-91ed-4673-bab3-3bfae758ab95@github.com>
Message-ID: <8MKmW-2_q3RYbIsye58L3XfOmaLItKlb8M8WB2-1cmI=.4b5a0dc0-e379-47bf-8479-10f18f0cbf0e@github.com>

> pre-Skara RFR thread: [link](https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-May/038416.html)
> 
> Error reporting was improved by writing a C-style escaped string representations for the variables passed to the
> methods being tested. For array comparisons, a dedicated diff-formatter was implemented.
> Sample output for comparing byte arrays (with artificial failure):
>  ----------System.err:(21/1553)----------
>  Result: (false) of 'arrayEqualsB' is not equal to expected (true)
>  Arrays differ starting from [index: 7]:
>  ... 5, 6,   7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, ...
>  ... 5, 6, 125, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, ...
>            ^^^^
>  java.lang.RuntimeException: Result: (false) of 'arrayEqualsB' is not
>  equal to expected (true)
>           at
>  compiler.intrinsics.string.TestStringIntrinsics.invokeAndCheckArrays(TestStringIntrinsics.java:273)
>            at ... stack trace continues - E.N.
>  Sample output for comparing char arrays:
>  ----------System.err:(21/1579)*----------
>  Result: (false) of 'arrayEqualsC' is not equal to expected (true)
>  Arrays differ starting from [index: 7]:
>  ... \\u0005, \\u0006, \\u0007, \\u0008, \\u0009, \\n, ...
>  ... \\u0005, \\u0006,      }, \\u0008, \\u0009, \\n, ...
>                      ^^^^^^^
>  java.lang.RuntimeException: Result: (false) of 'arrayEqualsC' is not
>  equal to expected (true)
>           at
>  compiler.intrinsics.string.TestStringIntrinsics.invokeAndCheckArrays(TestStringIntrinsics.java:280)
>            at
>  ... and so on - E.N.
> 
> testing: open/test/hotspot/jtreg/compiler/intrinsics/string/TestStringIntrinsics.java on linux, windows, macosx.

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

  Add null values support and two-way testing

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/112/files
  - new: https://git.openjdk.java.net/jdk/pull/112/files/81f7a9d9..39992fcb

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

  Stats: 323 lines in 3 files changed: 137 ins; 3 del; 183 mod
  Patch: https://git.openjdk.java.net/jdk/pull/112.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/112/head:pull/112

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

From enikitin at openjdk.java.net  Sat Oct  3 19:20:38 2020
From: enikitin at openjdk.java.net (Evgeny Nikitin)
Date: Sat, 3 Oct 2020 19:20:38 GMT
Subject: RFR: 8229186: Improve error messages for TestStringIntrinsics
 failures [v6]
In-Reply-To: <BAPITdSC4Qh9hS0VNQ0lJuiUnrAug3puTLhsWufTdkc=.b924cb4c-8f37-4a3d-8d49-b15b9378c0bc@github.com>
References: <Br6z5yt0kTbZwIQyTI9lz7czaYpjw5vCd5ZCbbrSIcM=.6a8096f1-91ed-4673-bab3-3bfae758ab95@github.com>
 <b3GkK3NPrSYq9sWmkUDW9mZN6kMRoGVLFNBxCMIEsPs=.6119e887-b2e1-4c94-aa52-8200faec288a@github.com>
 <BAPITdSC4Qh9hS0VNQ0lJuiUnrAug3puTLhsWufTdkc=.b924cb4c-8f37-4a3d-8d49-b15b9378c0bc@github.com>
Message-ID: <glSdGefTbKPPGKPJSK07X_w78mL1Jn9BwWHBI1BHXMU=.228eb149-ba8f-4547-b6cf-c1cf92081273@github.com>

On Thu, 1 Oct 2020 19:51:00 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Evgeny Nikitin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use SB to build TestStringIntrinsics message, avoid type guessing in ArrayDiff
>
> test/lib-test/jdk/test/lib/format/ArrayDiffTest.java line 38:
> 
>> 36:  * @run testng jdk.test.lib.format.ArrayDiffTest
>> 37:  */
>> 38: public class ArrayDiffTest {
> 
> Might be it makes sense to check null values. Also, reversed checks. For example there is first = [1, ..], second = [].
> But no check for  first = [], second = [1, ..] for some cases,

Fixed in the 39992fcba97. That ended in finding a minor issue, actually
([ArrayDiff.java:180](https://github.com/openjdk/jdk/pull/112/commits/39992fcba979a2f6bf7ea73aff92461b13220ee2#diff-374ead0149950fce10be8d9d37cca320L180)).
Sometimes reversing can be valuable, thanks!

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

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

From alanb at openjdk.java.net  Sat Oct  3 19:21:38 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sat, 3 Oct 2020 19:21:38 GMT
Subject: RFR: 8253761: Wrong URI syntax printed by jar --describe-module
In-Reply-To: <WpA1zwswZsUK3UpcmF011Lja4yNoaZrWcAbJUjG3yn4=.c62c2842-58db-49ff-af82-eb1cfb2577e2@github.com>
References: <GoJ43lbyj8ktcJfP8vpa6J3LK2_nFCyo4eFwJfPSFcY=.50f190e3-f244-43e8-95be-9377417d9c9b@github.com>
 <KX2hm__Fl4-b1qiK2FOHEYcmt4xNoMfZiZpCRu1G2jY=.457dfb03-27c0-41bc-850b-c1540e15f712@github.com>
 <WpA1zwswZsUK3UpcmF011Lja4yNoaZrWcAbJUjG3yn4=.c62c2842-58db-49ff-af82-eb1cfb2577e2@github.com>
Message-ID: <-1XHmzbRjoSG_fSaIWdhIUPuF8ZEcz8VmG-iWZ8NoQw=.92ae1a1f-fd51-431b-bcde-ca01d603aa04@github.com>

On Thu, 1 Oct 2020 14:35:50 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> The change looks good.
>> 
>> test/jdk/tools/jar/modularJar/Basic.java has tests for jar --describe-module and maybe we could add a test to this to
>> make sure that it outputs the expected JAR URL.
>
>> `test/jdk/tools/jar/modularJar/Basic.java` has tests for jar --describe-module and maybe we could add a test to this to
>> make sure that it outputs the expected JAR URL.
> 
> Tests are always good to have.
> 
> Should I extend the existing `@Test public void describeModuleFoo() ...` method or should I add a new method that
> ensures the expected URL is emitted?

A new assert in the describeModuleFoo test would be great, thank you!

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

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

From alanb at openjdk.java.net  Sun Oct  4 08:30:38 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sun, 4 Oct 2020 08:30:38 GMT
Subject: RFR: 8245194: Unix domain socket channel implementation [v13]
In-Reply-To: <YtR77VD8mHamrlKl9EQPn7XpWAcGUffub8nXTSA_GWI=.2083690e-2ce1-4c35-b053-c5f4501a9841@github.com>
References: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
 <aBHqAWehNAtKiaFFhz9cnd_oLXsZuyqa3xaiT_Fi3F0=.cc48c0a7-de65-46f1-94f3-7aa91fe25817@github.com>
 <9xiq9e72dtTcgcf4OvNEVUenyY_nBoZOqdfrEJi-KsI=.fb41e8ad-7ad5-47a7-b10d-3176ea3756e8@github.com>
 <YtR77VD8mHamrlKl9EQPn7XpWAcGUffub8nXTSA_GWI=.2083690e-2ce1-4c35-b053-c5f4501a9841@github.com>
Message-ID: <9t4xh-s8zuCV1pMwpenVJyThc6PUmbfVAd8CEo0Moec=.20e01f2f-7ca9-495c-b710-d738c758ccb6@github.com>

On Fri, 2 Oct 2020 13:17:04 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> make/modules/java.base/Copy.gmk line 195:
>> 
>>> 193: 	$(call MakeTargetDir)
>>> 194: 	$(RM) $@ $@.tmp
>>> 195: 	$(foreach f,$(NET_PROPERTIES_SRC_LIST),$(CAT) $(f) >> $@.tmp;)
>> 
>> This can be simplified. Cat takes multiple files as input, so no need for 'foreach'. Also no need to go via a temp
>> file. We have make configured to delete targets if a recipe fails, so the tmp dance isn't needed. (I know we still have
>> this pattern all over the place, but we are trying to quit the practice)
>
> Good points. I will update as suggested. Thanks.

I would prefer if we didn't rename net.properties. Can we use the same approach as lib/security/default.policy where
the share and platform specific are concatenated?

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

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

From alanb at openjdk.java.net  Sun Oct  4 08:44:38 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sun, 4 Oct 2020 08:44:38 GMT
Subject: RFR: 8242068: Signed JAR support for RSASSA-PSS and EdDSA
In-Reply-To: <QCs1eQY1q6bMoER9ad8yBuPS5dDA7pGrdM1lOf2DUpQ=.5c6ecfaa-07b5-443a-bd9b-9b91011a2ad7@github.com>
References: <QCs1eQY1q6bMoER9ad8yBuPS5dDA7pGrdM1lOf2DUpQ=.5c6ecfaa-07b5-443a-bd9b-9b91011a2ad7@github.com>
Message-ID: <X0uGHgb_CmFVkK6193nuQv8EyJQUMbaoxVCQ4QI9QnQ=.f35f6f3e-3948-4df2-a54c-3ee7d5a35faf@github.com>

On Wed, 23 Sep 2020 14:41:59 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Major points in CSR at https://bugs.openjdk.java.net/browse/JDK-8245274:
> 
> - new sigalg "RSASSA-PSS", "EdDSA", "Ed25519" and "Ed448" can be used in jarsigner
> 
> - The ".RSA" and ".EC" block extension types (PKCS #7 SignedData inside a signed JAR) are reused for new signature
>   algorithms
> 
> - A new JarSigner property "directsign"
> 
> - Updating the jarsigner tool doc
> 
> Major code changes:
> 
> - Always use the signature algorithm directly as SignerInfo::signatureAlgorithm. We used to use the encryption algorithm
>   there like RSA, DSA, and EC. Now it's always SHA1withRSA or RSASSA-PSS.
> 
> - Move signature related utilities methods from AlgorithmId.java to SignatureUtil.java
> 
> - Add new SignatureUtil methods fromKey() and fromSignature() to simplify creating Signature and getting its AlgorithmId
> 
> - Use the new methods in PKCS10, X509CertImpl, and X509CRLImpl signing
> 
> - Add a new (and intuitive, IMHO) PKCS7::generateNewSignedData capable of all old and new signature algorithms
> 
> - Mark all -altsign related code deprecated and they can be removed once ContentSigner is removed

Changes requested by alanb (Reviewer).

test/lib/jdk/test/lib/util/JarUtils.java line 90:

> 88:                 String name = toJarEntryName(entry);
> 89:                 jos.putNextEntry(new JarEntry(name));
> 90:                 if (Files.exists(dir.resolve(entry))) {

This is test infrastructure that we use in several areas and changing it to allow file paths to files that don't exist
be problematic. Is there any reason why the jarsigner can't create an empty or dummy file to put into the JAR file?

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

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

From michaelm at openjdk.java.net  Sun Oct  4 13:14:49 2020
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Sun, 4 Oct 2020 13:14:49 GMT
Subject: RFR: 8245194: Unix domain socket channel implementation [v14]
In-Reply-To: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
References: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
Message-ID: <quEqJdCbjSrirA9ItzvUxkmTaj115Y8z69jfXS6uu0s=.bd3d0f91-1019-4463-ab11-dfb53093e0b5@github.com>

> Continuing this review as a PR on github with the comments below incorporated. I expect there will be a few more
> iterations before integrating.
> On 06/09/2020 19:47, Alan Bateman wrote:
>> On 26/08/2020 15:24, Michael McMahon wrote:
>>>
>>> As I mentioned the other day, I wasn't able to use the suggested method on Windows which returns an absolute path. So,
>>> I added a method to WindowsPath which returns the path in the expected UTF-8 encoding as a byte[]. Let me know what you
>>> think of that.
>>>
>>> There is a fair bit of other refactoring and simplification done also. Next version is at:
>>>
>>> http://cr.openjdk.java.net/~michaelm/8245194/impl.webrev/webrev.9/
>>>
>> Adding a method to WindowsPath to encode the path using UTF-8 is okay but I don't think we should be caching it as the
>> encoding for sun_path is an outlier on Windows. I'm also a bit dubious about encoding a relative path when the resolved
>> path (before encoding) is > 247 chars. The documentation on the MS site isn't very completely and I think there are a
>> number points that require clarification to fully understand how this will work with relative, directly relative and
>> drive relative paths.
>>
> 
> Maybe it would be better to just use the path returned from toString() and do the conversion to UTF-8 externally. That
> would leave WindowsPath unchanged.
>> In the same area, the new PathUtil is a bit inconsistent with the existing provider code. One suggestion is to add a
>> method to AbstractFileSystemProvider instead. That is the base class the platform providers and would be a better place
>> to get the file path in bytes.
>>
> 
> Okay, I gave the method a name that is specific to Unix domain sockets because this UTF-8 strangeness is not likely to
> be useful by other components.
>> One other comment on the changes to the file system provider it should be okay to change UnixUserPrinipals ad its
>> fromUid and fromGid method to be public. This would mean that the patch shouldn't need to add UnixUserGroup (the main
>> issue is that class is that it means we end up with two classes with static factory methods doing the same thing).
> 
> Okay, that does simplify it a bit.
> 
> Thanks,
> Michael.
> 
>> -Alan.
>>
>>
>>
>>
>>
>>

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

  - simplified Copy.gmk to CAT source files directly
  - renamed net.properties source files to all be net.properties

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/52/files
  - new: https://git.openjdk.java.net/jdk/pull/52/files/dc70cd6e..0096645e

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

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

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

From michaelm at openjdk.java.net  Sun Oct  4 13:14:50 2020
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Sun, 4 Oct 2020 13:14:50 GMT
Subject: RFR: 8245194: Unix domain socket channel implementation [v13]
In-Reply-To: <9t4xh-s8zuCV1pMwpenVJyThc6PUmbfVAd8CEo0Moec=.20e01f2f-7ca9-495c-b710-d738c758ccb6@github.com>
References: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
 <aBHqAWehNAtKiaFFhz9cnd_oLXsZuyqa3xaiT_Fi3F0=.cc48c0a7-de65-46f1-94f3-7aa91fe25817@github.com>
 <9xiq9e72dtTcgcf4OvNEVUenyY_nBoZOqdfrEJi-KsI=.fb41e8ad-7ad5-47a7-b10d-3176ea3756e8@github.com>
 <YtR77VD8mHamrlKl9EQPn7XpWAcGUffub8nXTSA_GWI=.2083690e-2ce1-4c35-b053-c5f4501a9841@github.com>
 <9t4xh-s8zuCV1pMwpenVJyThc6PUmbfVAd8CEo0Moec=.20e01f2f-7ca9-495c-b710-d738c758ccb6@github.com>
Message-ID: <Rgzc9LEZ3V4MIWDI_xpbE1UNg6oEfgIn2aj5TtiWumU=.e0fc42c4-9e22-49e8-be9f-82c3330feb22@github.com>

On Sun, 4 Oct 2020 08:27:39 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Good points. I will update as suggested. Thanks.
>
> I would prefer if we didn't rename net.properties. Can we use the same approach as lib/security/default.policy where
> the share and platform specific are concatenated?

Okay, I have just pushed these suggested updates.

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

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

From weijun at openjdk.java.net  Sun Oct  4 13:34:38 2020
From: weijun at openjdk.java.net (Weijun Wang)
Date: Sun, 4 Oct 2020 13:34:38 GMT
Subject: RFR: 8242068: Signed JAR support for RSASSA-PSS and EdDSA
In-Reply-To: <X0uGHgb_CmFVkK6193nuQv8EyJQUMbaoxVCQ4QI9QnQ=.f35f6f3e-3948-4df2-a54c-3ee7d5a35faf@github.com>
References: <QCs1eQY1q6bMoER9ad8yBuPS5dDA7pGrdM1lOf2DUpQ=.5c6ecfaa-07b5-443a-bd9b-9b91011a2ad7@github.com>
 <X0uGHgb_CmFVkK6193nuQv8EyJQUMbaoxVCQ4QI9QnQ=.f35f6f3e-3948-4df2-a54c-3ee7d5a35faf@github.com>
Message-ID: <KZaJIKR89X5U6ZVUgPH3VfFf7-f_z8A43qBjdBn4xhs=.54c255aa-a4f1-475b-85d2-c49157b1cf6c@github.com>

On Sun, 4 Oct 2020 08:41:28 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Major points in CSR at https://bugs.openjdk.java.net/browse/JDK-8245274:
>> 
>> - new sigalg "RSASSA-PSS", "EdDSA", "Ed25519" and "Ed448" can be used in jarsigner
>> 
>> - The ".RSA" and ".EC" block extension types (PKCS #7 SignedData inside a signed JAR) are reused for new signature
>>   algorithms
>> 
>> - A new JarSigner property "directsign"
>> 
>> - Updating the jarsigner tool doc
>> 
>> Major code changes:
>> 
>> - Always use the signature algorithm directly as SignerInfo::signatureAlgorithm. We used to use the encryption algorithm
>>   there like RSA, DSA, and EC. Now it's always SHA1withRSA or RSASSA-PSS.
>> 
>> - Move signature related utilities methods from AlgorithmId.java to SignatureUtil.java
>> 
>> - Add new SignatureUtil methods fromKey() and fromSignature() to simplify creating Signature and getting its AlgorithmId
>> 
>> - Use the new methods in PKCS10, X509CertImpl, and X509CRLImpl signing
>> 
>> - Add a new (and intuitive, IMHO) PKCS7::generateNewSignedData capable of all old and new signature algorithms
>> 
>> - Mark all -altsign related code deprecated and they can be removed once ContentSigner is removed
>
> test/lib/jdk/test/lib/util/JarUtils.java line 90:
> 
>> 88:                 String name = toJarEntryName(entry);
>> 89:                 jos.putNextEntry(new JarEntry(name));
>> 90:                 if (Files.exists(dir.resolve(entry))) {
> 
> This is test infrastructure that we use in several areas and changing it to allow file paths to files that don't exist
> be problematic. Is there any reason why the jarsigner can't create an empty or dummy file to put into the JAR file?

Sorry, I'll revert the change and create files myself. I just thought any existing call to this method should have the
file already created there, but it could be a problem if the creation is not trivial and might fail.

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

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

From weijun at openjdk.java.net  Sun Oct  4 14:02:49 2020
From: weijun at openjdk.java.net (Weijun Wang)
Date: Sun, 4 Oct 2020 14:02:49 GMT
Subject: RFR: 8242068: Signed JAR support for RSASSA-PSS and EdDSA [v2]
In-Reply-To: <QCs1eQY1q6bMoER9ad8yBuPS5dDA7pGrdM1lOf2DUpQ=.5c6ecfaa-07b5-443a-bd9b-9b91011a2ad7@github.com>
References: <QCs1eQY1q6bMoER9ad8yBuPS5dDA7pGrdM1lOf2DUpQ=.5c6ecfaa-07b5-443a-bd9b-9b91011a2ad7@github.com>
Message-ID: <z_uCA9phPF8kM2A9RzMcjgFL_xie8wUlU4eoTXYSe6o=.877c7e47-836b-4bbb-9ab6-db4445cc0eac@github.com>

> Major points in CSR at https://bugs.openjdk.java.net/browse/JDK-8245274:
> 
> - new sigalg "RSASSA-PSS", "EdDSA", "Ed25519" and "Ed448" can be used in jarsigner
> 
> - The ".RSA" and ".EC" block extension types (PKCS #7 SignedData inside a signed JAR) are reused for new signature
>   algorithms
> 
> - A new JarSigner property "directsign"
> 
> - Updating the jarsigner tool doc
> 
> Major code changes:
> 
> - Always use the signature algorithm directly as SignerInfo::signatureAlgorithm. We used to use the encryption algorithm
>   there like RSA, DSA, and EC. Now it's always SHA1withRSA or RSASSA-PSS.
> 
> - Move signature related utilities methods from AlgorithmId.java to SignatureUtil.java
> 
> - Add new SignatureUtil methods fromKey() and fromSignature() to simplify creating Signature and getting its AlgorithmId
> 
> - Use the new methods in PKCS10, X509CertImpl, and X509CRLImpl signing
> 
> - Add a new (and intuitive, IMHO) PKCS7::generateNewSignedData capable of all old and new signature algorithms
> 
> - Mark all -altsign related code deprecated and they can be removed once ContentSigner is removed

Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The pull request now
contains three commits:

 - extract some methods, rollback JarUtils, deperated version from 15 to 16.
 - Merge
 - 8242068: Signed JAR support for RSASSA-PSS and EdDSA

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

Changes: https://git.openjdk.java.net/jdk/pull/322/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=322&range=01
  Stats: 1696 lines in 21 files changed: 972 ins; 555 del; 169 mod
  Patch: https://git.openjdk.java.net/jdk/pull/322.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/322/head:pull/322

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

From weijun at openjdk.java.net  Sun Oct  4 14:09:48 2020
From: weijun at openjdk.java.net (Weijun Wang)
Date: Sun, 4 Oct 2020 14:09:48 GMT
Subject: RFR: 8242068: Signed JAR support for RSASSA-PSS and EdDSA [v3]
In-Reply-To: <QCs1eQY1q6bMoER9ad8yBuPS5dDA7pGrdM1lOf2DUpQ=.5c6ecfaa-07b5-443a-bd9b-9b91011a2ad7@github.com>
References: <QCs1eQY1q6bMoER9ad8yBuPS5dDA7pGrdM1lOf2DUpQ=.5c6ecfaa-07b5-443a-bd9b-9b91011a2ad7@github.com>
Message-ID: <q0VlYunB4zj21My1nzw4fYOT8zh-mH6AAXdbHwSlbrI=.58b08800-56a4-4951-bf84-6afcd7d15741@github.com>

> Major points in CSR at https://bugs.openjdk.java.net/browse/JDK-8245274:
> 
> - new sigalg "RSASSA-PSS", "EdDSA", "Ed25519" and "Ed448" can be used in jarsigner
> 
> - The ".RSA" and ".EC" block extension types (PKCS #7 SignedData inside a signed JAR) are reused for new signature
>   algorithms
> 
> - A new JarSigner property "directsign"
> 
> - Updating the jarsigner tool doc
> 
> Major code changes:
> 
> - Always use the signature algorithm directly as SignerInfo::signatureAlgorithm. We used to use the encryption algorithm
>   there like RSA, DSA, and EC. Now it's always SHA1withRSA or RSASSA-PSS.
> 
> - Move signature related utilities methods from AlgorithmId.java to SignatureUtil.java
> 
> - Add new SignatureUtil methods fromKey() and fromSignature() to simplify creating Signature and getting its AlgorithmId
> 
> - Use the new methods in PKCS10, X509CertImpl, and X509CRLImpl signing
> 
> - Add a new (and intuitive, IMHO) PKCS7::generateNewSignedData capable of all old and new signature algorithms
> 
> - Mark all -altsign related code deprecated and they can be removed once ContentSigner is removed

Weijun Wang 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:

  extract some methods, rollback JarUtils, deprecated version from 15 to 16.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/322/files
  - new: https://git.openjdk.java.net/jdk/pull/322/files/c05af70a..5d455bae

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

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

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

From weijun at openjdk.java.net  Sun Oct  4 14:12:37 2020
From: weijun at openjdk.java.net (Weijun Wang)
Date: Sun, 4 Oct 2020 14:12:37 GMT
Subject: RFR: 8242068: Signed JAR support for RSASSA-PSS and EdDSA [v3]
In-Reply-To: <X0uGHgb_CmFVkK6193nuQv8EyJQUMbaoxVCQ4QI9QnQ=.f35f6f3e-3948-4df2-a54c-3ee7d5a35faf@github.com>
References: <QCs1eQY1q6bMoER9ad8yBuPS5dDA7pGrdM1lOf2DUpQ=.5c6ecfaa-07b5-443a-bd9b-9b91011a2ad7@github.com>
 <X0uGHgb_CmFVkK6193nuQv8EyJQUMbaoxVCQ4QI9QnQ=.f35f6f3e-3948-4df2-a54c-3ee7d5a35faf@github.com>
Message-ID: <YZosP6RrebV_FqMuO7aNEHOrXKPXvSwHKlN05FnFfFo=.1e300a10-62e8-43e4-8874-d4bed8f76971@github.com>

On Sun, 4 Oct 2020 08:41:40 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Weijun Wang 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 requested by alanb (Reviewer).

Note: I force pushed a new commit to correct a typo in the summary line.

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

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

From cstein at openjdk.java.net  Sun Oct  4 17:13:52 2020
From: cstein at openjdk.java.net (Christian Stein)
Date: Sun, 4 Oct 2020 17:13:52 GMT
Subject: RFR: 8253761: Wrong URI syntax printed by jar --describe-module
 [v2]
In-Reply-To: <GoJ43lbyj8ktcJfP8vpa6J3LK2_nFCyo4eFwJfPSFcY=.50f190e3-f244-43e8-95be-9377417d9c9b@github.com>
References: <GoJ43lbyj8ktcJfP8vpa6J3LK2_nFCyo4eFwJfPSFcY=.50f190e3-f244-43e8-95be-9377417d9c9b@github.com>
Message-ID: <XY62VEHO_5_jMqF4fMiUkn_UNYLX_XnTLp6SsTliP68=.052ffa72-a1b7-4846-af6d-cda020d4a925@github.com>

> This commit replaces `"/!"` with `"!/"` in order to generate
> valid URIs when printing a module description of a modular
> JAR file. A valid URI is described here: [1]
> 
> https://bugs.openjdk.java.net/browse/JDK-8253761
> 
> [1] https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/net/JarURLConnection.html

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

  Assert that the expected JAR URI is emitted

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/393/files
  - new: https://git.openjdk.java.net/jdk/pull/393/files/7df9f472..acbde567

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

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

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

From cstein at openjdk.java.net  Sun Oct  4 17:29:40 2020
From: cstein at openjdk.java.net (Christian Stein)
Date: Sun, 4 Oct 2020 17:29:40 GMT
Subject: RFR: 8253761: Wrong URI syntax printed by jar --describe-module
In-Reply-To: <-1XHmzbRjoSG_fSaIWdhIUPuF8ZEcz8VmG-iWZ8NoQw=.92ae1a1f-fd51-431b-bcde-ca01d603aa04@github.com>
References: <GoJ43lbyj8ktcJfP8vpa6J3LK2_nFCyo4eFwJfPSFcY=.50f190e3-f244-43e8-95be-9377417d9c9b@github.com>
 <KX2hm__Fl4-b1qiK2FOHEYcmt4xNoMfZiZpCRu1G2jY=.457dfb03-27c0-41bc-850b-c1540e15f712@github.com>
 <WpA1zwswZsUK3UpcmF011Lja4yNoaZrWcAbJUjG3yn4=.c62c2842-58db-49ff-af82-eb1cfb2577e2@github.com>
 <-1XHmzbRjoSG_fSaIWdhIUPuF8ZEcz8VmG-iWZ8NoQw=.92ae1a1f-fd51-431b-bcde-ca01d603aa04@github.com>
Message-ID: <g2xPz8RM-0RV6pO74DD3_i0WekIu42Ub9I8aHuyWdg4=.504094c5-926d-4065-adfa-e885f360a463@github.com>

On Sat, 3 Oct 2020 19:19:08 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>>> `test/jdk/tools/jar/modularJar/Basic.java` has tests for jar --describe-module and maybe we could add a test to this to
>>> make sure that it outputs the expected JAR URL.
>> 
>> Tests are always good to have.
>> 
>> Should I extend the existing `@Test public void describeModuleFoo() ...` method or should I add a new method that
>> ensures the expected URL is emitted?
>
> A new assert in the describeModuleFoo test would be great, thank you!

How do I trigger a "pre-submit testing using GitHub Actions workflow"[[1]] to be started for this PR?

[1]: https://mail.openjdk.java.net/pipermail/jdk-dev/2020-September/004736.html

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

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

From weijun at openjdk.java.net  Sun Oct  4 17:29:50 2020
From: weijun at openjdk.java.net (Weijun Wang)
Date: Sun, 4 Oct 2020 17:29:50 GMT
Subject: RFR: 8242068: Signed JAR support for RSASSA-PSS and EdDSA [v4]
In-Reply-To: <QCs1eQY1q6bMoER9ad8yBuPS5dDA7pGrdM1lOf2DUpQ=.5c6ecfaa-07b5-443a-bd9b-9b91011a2ad7@github.com>
References: <QCs1eQY1q6bMoER9ad8yBuPS5dDA7pGrdM1lOf2DUpQ=.5c6ecfaa-07b5-443a-bd9b-9b91011a2ad7@github.com>
Message-ID: <tJxHRT0yAT3RKEtqHZ_ZnyJf_739XlZjyp5N3XF3bOQ=.bfa47524-9bd6-453f-aa47-c3ea5b08f894@github.com>

> Major points in CSR at https://bugs.openjdk.java.net/browse/JDK-8245274:
> 
> - new sigalg "RSASSA-PSS", "EdDSA", "Ed25519" and "Ed448" can be used in jarsigner
> 
> - The ".RSA" and ".EC" block extension types (PKCS #7 SignedData inside a signed JAR) are reused for new signature
>   algorithms
> 
> - A new JarSigner property "directsign"
> 
> - Updating the jarsigner tool doc
> 
> Major code changes:
> 
> - Always use the signature algorithm directly as SignerInfo::signatureAlgorithm. We used to use the encryption algorithm
>   there like RSA, DSA, and EC. Now it's always SHA1withRSA or RSASSA-PSS.
> 
> - Move signature related utilities methods from AlgorithmId.java to SignatureUtil.java
> 
> - Add new SignatureUtil methods fromKey() and fromSignature() to simplify creating Signature and getting its AlgorithmId
> 
> - Use the new methods in PKCS10, X509CertImpl, and X509CRLImpl signing
> 
> - Add a new (and intuitive, IMHO) PKCS7::generateNewSignedData capable of all old and new signature algorithms
> 
> - Mark all -altsign related code deprecated and they can be removed once ContentSigner is removed

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

  fotgot to read one property

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/322/files
  - new: https://git.openjdk.java.net/jdk/pull/322/files/5d455bae..fecf30d7

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

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

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

From bulasevich at openjdk.java.net  Sun Oct  4 18:17:38 2020
From: bulasevich at openjdk.java.net (Boris Ulasevich)
Date: Sun, 4 Oct 2020 18:17:38 GMT
Subject: RFR: 8245543: Cgroups: Incorrect detection logic on some systems
 (still reproducible)
In-Reply-To: <CWATRi437QpkCA1sx-EsHFqVlSCV-G8EgkEoGdJgPHc=.a743be7e-8a00-4d91-866d-86ccf3fe714f@github.com>
References: <CWATRi437QpkCA1sx-EsHFqVlSCV-G8EgkEoGdJgPHc=.a743be7e-8a00-4d91-866d-86ccf3fe714f@github.com>
Message-ID: <5PIk4w58jDVRPA8DTWjVRBzuVxRH5HxxYM_cb8bc-jg=.a715f356-856a-430d-b641-98345ca5ad62@github.com>

On Fri, 2 Oct 2020 16:34:49 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> An issue similar to [JDK-8239559](https://bugs.openjdk.java.net/browse/JDK-8239559) has been discovered. On the
> affected system, `/proc/self/mountinfo` contains a line such as this one:
> 
> 35 26 0:26 / /sys/fs/cgroup/systemd rw,nosuid,nodev,noexec,relatime - cgroup systemd rw,name=systemd
>  
> 
> Note that `/proc/cgroups` looks like this:
> 
> #subsys_name	hierarchy	num_cgroups	enabled
> cpuset	0	1	1
> cpu	0	1	1
> cpuacct	0	1	1
> blkio	0	1	1
> memory	0	1	1
> devices	0	1	1
> freezer	0	1	1
> net_cls	0	1	1
> perf_event	0	1	1
> net_prio	0	1	1
> hugetlb	0	1	1
> pids	0	1	1
> 
> This is in fact a cgroups v1 system with systemd put into a separate namespace via FS type `cgroup`. That mountinfo
> line confuses the cgroups version detection heuristic. It only looked whether or not there is **any** entry in
> mountinfo of FS-type `cgroup` . That's wrong. A better heuristic would be looking at controllers we care about: `cpu`,
> `cpuacct`, `memory`, `cpuset` for hotspot and some more for the Java side. The proposed fix on the hotspot side is to
> set `any_cgroup_mounts_found` to true only if one of those controllers show up in mountinfo. Otherwise, we know it's
> cgroup v2 due to the zero hierarchy ids.  For the Java side the proposal is to add some parsing for mountinfo lines and
> look for `cgroup` FS-type lines which aren't also mounted purely for systemd.
> **Testing**
> 
>  - [x] Linux x86_64 container tests on cgroup v1 (fastdebug)
>  - [x] Linux x86_64 container tests on cgroup v2 (fastdebug)
>  - [x] Added regression test which fails prior the patch and passes after
>  - [ ] Submit testing (still running)

src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemFactory.java line 72:

> 70:      *  Pattern explanation:
> 71:      *
> 72:      *  /`````\    /`````\    /`````\    /```````\    /```````\    /```\ (8) /```````\     (10) + (11)

Alternatively, consider the inline comment:

    private static final Pattern MOUNTINFO_PATTERN = Pattern.compile(
        "^[^\\s]+\\s+[^\\s]+\\s+[^\\s]+\\s+" +  // (1) + (2) + (3)
        "([^\\s]+)\\s+([^\\s]+)\\s+"         +  // (4) + (5) - group 1,2: mount point, mount options
        "[^-]+-\\s+"    +                       // (6) + (7) + (8)
        "([^\\s]+)\\s+" +                       // (9) - group 3: fstype
        ".*$");                                 // (10) + (11)

src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemFactory.java line 80:

> 78:      */
> 79:     private static final Pattern MOUNTINFO_PATTERN =
> 80:
> Pattern.compile("^[^\\s]+\\s+[^\\s]+\\s+[^\\s]+\\s+([^\\s]+)\\s+([^\\s]+)\\s+[^-]+-\\s+([^\\s]+)\\s+.*$");

Only group_3 = fstype is used in the pattern, right?

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

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

From bulasevich at openjdk.java.net  Sun Oct  4 18:17:37 2020
From: bulasevich at openjdk.java.net (Boris Ulasevich)
Date: Sun, 4 Oct 2020 18:17:37 GMT
Subject: RFR: 8245543: Cgroups: Incorrect detection logic on some systems
 (still reproducible)
In-Reply-To: <GQPVanQ-V8oL4npQHUXk5xw5pxR4fF8z3C_Wj5l7uDw=.1f4b9c49-252f-47dd-a0cf-6d36794928db@github.com>
References: <CWATRi437QpkCA1sx-EsHFqVlSCV-G8EgkEoGdJgPHc=.a743be7e-8a00-4d91-866d-86ccf3fe714f@github.com>
 <GQPVanQ-V8oL4npQHUXk5xw5pxR4fF8z3C_Wj5l7uDw=.1f4b9c49-252f-47dd-a0cf-6d36794928db@github.com>
Message-ID: <p3wicme6jMQZ8q_ATLI4V-qN3p0PvWL8QACK3SCpE50=.bfa7b1e4-137b-4045-95f9-cb5fa7391ce5@github.com>

On Fri, 2 Oct 2020 16:39:09 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> An issue similar to [JDK-8239559](https://bugs.openjdk.java.net/browse/JDK-8239559) has been discovered. On the
>> affected system, `/proc/self/mountinfo` contains a line such as this one:
>> 
>> 35 26 0:26 / /sys/fs/cgroup/systemd rw,nosuid,nodev,noexec,relatime - cgroup systemd rw,name=systemd
>>  
>> 
>> Note that `/proc/cgroups` looks like this:
>> 
>> #subsys_name	hierarchy	num_cgroups	enabled
>> cpuset	0	1	1
>> cpu	0	1	1
>> cpuacct	0	1	1
>> blkio	0	1	1
>> memory	0	1	1
>> devices	0	1	1
>> freezer	0	1	1
>> net_cls	0	1	1
>> perf_event	0	1	1
>> net_prio	0	1	1
>> hugetlb	0	1	1
>> pids	0	1	1
>> 
>> This is in fact a cgroups v1 system with systemd put into a separate namespace via FS type `cgroup`. That mountinfo
>> line confuses the cgroups version detection heuristic. It only looked whether or not there is **any** entry in
>> mountinfo of FS-type `cgroup` . That's wrong. A better heuristic would be looking at controllers we care about: `cpu`,
>> `cpuacct`, `memory`, `cpuset` for hotspot and some more for the Java side. The proposed fix on the hotspot side is to
>> set `any_cgroup_mounts_found` to true only if one of those controllers show up in mountinfo. Otherwise, we know it's
>> cgroup v2 due to the zero hierarchy ids.  For the Java side the proposal is to add some parsing for mountinfo lines and
>> look for `cgroup` FS-type lines which aren't also mounted purely for systemd.
>> **Testing**
>> 
>>  - [x] Linux x86_64 container tests on cgroup v1 (fastdebug)
>>  - [x] Linux x86_64 container tests on cgroup v2 (fastdebug)
>>  - [x] Added regression test which fails prior the patch and passes after
>>  - [ ] Submit testing (still running)
>
> @bulasevich Do you want to give this a spin?

The change looks reasonable. I checked the fail - it is gone with the change! And both jtreg tests passed.

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

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

From dholmes at openjdk.java.net  Mon Oct  5 03:24:44 2020
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 5 Oct 2020 03:24:44 GMT
Subject: RFR: 8248238: Implementation: JEP 388: Windows AArch64 Support
 [v12]
In-Reply-To: <CiPvM88WFx_o1P3zYlEFsdSrLK2sxrNQfWQVgPfOHi4=.fcf0ed66-c945-4760-b217-110b123fdc2f@github.com>
References: <rKAoubbLMIMVqS6En_xKWMT8jpEwBU5TF83A-AhWg2E=.908578cd-0877-431e-9447-d5a04e0dc970@github.com>
 <qv-WAepDb6KDawneV5Mw_HXjDB-xBnJkdeIAlquh6bU=.3af0c77f-fe7b-4bee-913b-6e6de513f0bd@github.com>
 <t08mgMBggFEJuzguHzW9OPI3AgtasklRfHSO95q3YA4=.98e321ac-8db2-462f-b311-7de33dcb9091@github.com>
 <CiPvM88WFx_o1P3zYlEFsdSrLK2sxrNQfWQVgPfOHi4=.fcf0ed66-c945-4760-b217-110b123fdc2f@github.com>
Message-ID: <LK0WRkI3CZFruGt7SiyE8d2wdSdbU8rOnYxLacqVDK4=.6ab0c4ad-bc33-41e1-82a9-d8506eb3fb57@github.com>

On Fri, 2 Oct 2020 17:16:50 GMT, Monica Beckwith <mbeckwit at openjdk.org> wrote:

>> Marked as reviewed by dholmes (Reviewer).
>
>> The JEP is not yet targeted so we have to wait for that formality. But
>> once that happens I can sponsor for you.
> 
> Thanks.
>>
>> Also note that the PR references the wrong JEP so can you please edit
>> the description to fix that.
> 
> Added JEP # (388) here and updated the JBS entry.
> After looking at JEPs 386, 377, and 379, I also did the following:
> - listed JDK-8248238 as a sub-task for JDK-8248496
> - added this PR link in a comment for the JEP.
> 
> As soon as the JEP is targetted, I will update the "Fix version" for the 'Implementation' (JDK-8248238) and ping you
> @dholmes-ora .
>> 
>> Meanwhile I'll see if I can take this for a spin through our internal
>> testing.
> Thanks so much.
> 
> Regards,
> Monica
> 
>> 
>> Cheers,
>> David

@mo-beck The initial comment still has this incorrect link:

[2] https://openjdk.java.net/jeps/8251280

Please edit the comment and fix the link.

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

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

From mbeckwit at openjdk.java.net  Mon Oct  5 03:24:45 2020
From: mbeckwit at openjdk.java.net (Monica Beckwith)
Date: Mon, 5 Oct 2020 03:24:45 GMT
Subject: Integrated: 8248238: Implementation: JEP 388: Windows AArch64 Support
In-Reply-To: <rKAoubbLMIMVqS6En_xKWMT8jpEwBU5TF83A-AhWg2E=.908578cd-0877-431e-9447-d5a04e0dc970@github.com>
References: <rKAoubbLMIMVqS6En_xKWMT8jpEwBU5TF83A-AhWg2E=.908578cd-0877-431e-9447-d5a04e0dc970@github.com>
Message-ID: <FqlQiJC3-0QDxFjIzvzg8a3sWpaItdwvKPMtlW5Qzk4=.cd813073-a978-4e3f-b3a7-e1909b523fd3@github.com>

On Wed, 16 Sep 2020 20:26:10 GMT, Monica Beckwith <mbeckwit at openjdk.org> wrote:

> This is a continuation of https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html
>  
> Changes since then:
> * We've improved the write barrier as suggested by Andrew [1]
> * The define-guards around R18 have been changed to `R18_RESERVED`. This will be enabled for Windows only for now but
>   will be required for the upcoming macOS+Aarch64 [2] port as well.
> * We've incorporated https://github.com/openjdk/jdk/pull/154 by @AntonKozlov in our PR for now and built the
>   Windows-specific CPU feature detection on top of it.
> 
> [1] https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009597.html
> [2] https://openjdk.java.net/jeps/8251280

This pull request has now been integrated.

Changeset: 9604ee82
Author:    Monica Beckwith <mbeckwit at openjdk.org>
Committer: David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/9604ee82
Stats:     2566 lines in 62 files changed: 2208 ins; 126 del; 232 mod

8248238: Implementation: JEP 388: Windows AArch64 Support

Co-authored-by: Monica Beckwith <mbeckwit at openjdk.org>
Co-authored-by: Ludovic Henry <luhenry at openjdk.org>
Co-authored-by: Bernhard Urban-Forster <burban at openjdk.org>
Reviewed-by: dholmes, cjplummer, aph, ihse

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

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

From mbeckwit at openjdk.java.net  Mon Oct  5 04:11:47 2020
From: mbeckwit at openjdk.java.net (Monica Beckwith)
Date: Mon, 5 Oct 2020 04:11:47 GMT
Subject: RFR: 8248238: Implementation: JEP 388: Windows AArch64 Support
 [v12]
In-Reply-To: <LK0WRkI3CZFruGt7SiyE8d2wdSdbU8rOnYxLacqVDK4=.6ab0c4ad-bc33-41e1-82a9-d8506eb3fb57@github.com>
References: <rKAoubbLMIMVqS6En_xKWMT8jpEwBU5TF83A-AhWg2E=.908578cd-0877-431e-9447-d5a04e0dc970@github.com>
 <qv-WAepDb6KDawneV5Mw_HXjDB-xBnJkdeIAlquh6bU=.3af0c77f-fe7b-4bee-913b-6e6de513f0bd@github.com>
 <t08mgMBggFEJuzguHzW9OPI3AgtasklRfHSO95q3YA4=.98e321ac-8db2-462f-b311-7de33dcb9091@github.com>
 <CiPvM88WFx_o1P3zYlEFsdSrLK2sxrNQfWQVgPfOHi4=.fcf0ed66-c945-4760-b217-110b123fdc2f@github.com>
 <LK0WRkI3CZFruGt7SiyE8d2wdSdbU8rOnYxLacqVDK4=.6ab0c4ad-bc33-41e1-82a9-d8506eb3fb57@github.com>
Message-ID: <BsWqHVHVTtimGeQhZ2F_4qGKOn_21g1Vsoo9L1nkQLk=.867b108d-8101-48b7-b4dd-0f2f92cb8e1d@github.com>

On Mon, 5 Oct 2020 03:20:43 GMT, David Holmes <dholmes at openjdk.org> wrote:

> @mo-beck The initial comment still has this incorrect link:
> 
> [2] https://openjdk.java.net/jeps/8251280
> 
> Please edit the comment and fix the link.

That was a link to the macOS + Arm64 port. But I have removed it as it wasn't needed in the description of this
implementation.

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

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

From kbarrett at openjdk.java.net  Mon Oct  5 08:31:49 2020
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Mon, 5 Oct 2020 08:31:49 GMT
Subject: RFR: 8188055: (ref) Add Reference::refersTo predicate
Message-ID: <D4HSg8FT20Eaxk5KJkkw0GgETSxRkBn1ipS3Dt0kPto=.e4bab078-2e04-4413-90cb-9bfafb2a6831@github.com>

Finally returning to this review that was started in April 2020.  I've
recast it as a github PR.  I think the security concern raised by Gil
has been adequately answered.
https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-April/029203.html
https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-July/030401.html
https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-August/030677.html
https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-September/030793.html

Please review a new function: java.lang.ref.Reference.refersTo.

This function is needed to test the referent of a Reference object without
artificially extending the lifetime of the referent object, as may happen
when calling Reference.get.  Some garbage collectors require extending the
lifetime of a weak referent when accessed, in order to maintain collector
invariants.  Lifetime extension may occur with any collector when the
Reference is a SoftReference, as calling get indicates recent access.  This
new function also allows testing the referent of a PhantomReference, which
can't be accessed by calling get.

The new function uses native methods whose implementations are in the VM so
they can use the Access API.  It is the intent that these methods will be
intrinsified by optimizing compilers like C2 or graal, but that hasn't been
implemented yet.  Bear that in mind before rushing off to change existing
uses of Reference.get.

There are two native methods involved, one in Reference and an override in
PhantomReference, both package private in java.lang.ref. The reason for this
split is to simplify the intrinsification. This is a change from the version
from April 2020; that version had a single native method in Reference,
implemented using the ON_UNKNOWN_OOP_REF Access reference strength category.
However, adding support for that category in the compilers adds significant
implementation effort and complexity. Splitting avoids that complexity.

Testing:
mach5 tier1
Locally (linux-x64) verified the new test passes with various garbage collectors.

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

Commit messages:
 - new function

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

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

From sgehwolf at openjdk.java.net  Mon Oct  5 08:39:47 2020
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Mon, 5 Oct 2020 08:39:47 GMT
Subject: RFR: 8245543: Cgroups: Incorrect detection logic on some systems
 (still reproducible) [v2]
In-Reply-To: <CWATRi437QpkCA1sx-EsHFqVlSCV-G8EgkEoGdJgPHc=.a743be7e-8a00-4d91-866d-86ccf3fe714f@github.com>
References: <CWATRi437QpkCA1sx-EsHFqVlSCV-G8EgkEoGdJgPHc=.a743be7e-8a00-4d91-866d-86ccf3fe714f@github.com>
Message-ID: <kexKKqKQ6Dak2IagWfCqgLQqX7hFMdfDrnSpzs6PbUg=.67287686-54df-474a-aa39-1fd151f0b9fb@github.com>

> An issue similar to [JDK-8239559](https://bugs.openjdk.java.net/browse/JDK-8239559) has been discovered. On the
> affected system, `/proc/self/mountinfo` contains a line such as this one:
> 
> 35 26 0:26 / /sys/fs/cgroup/systemd rw,nosuid,nodev,noexec,relatime - cgroup systemd rw,name=systemd
>  
> 
> Note that `/proc/cgroups` looks like this:
> 
> #subsys_name	hierarchy	num_cgroups	enabled
> cpuset	0	1	1
> cpu	0	1	1
> cpuacct	0	1	1
> blkio	0	1	1
> memory	0	1	1
> devices	0	1	1
> freezer	0	1	1
> net_cls	0	1	1
> perf_event	0	1	1
> net_prio	0	1	1
> hugetlb	0	1	1
> pids	0	1	1
> 
> This is in fact a cgroups v1 system with systemd put into a separate namespace via FS type `cgroup`. That mountinfo
> line confuses the cgroups version detection heuristic. It only looked whether or not there is **any** entry in
> mountinfo of FS-type `cgroup` . That's wrong. A better heuristic would be looking at controllers we care about: `cpu`,
> `cpuacct`, `memory`, `cpuset` for hotspot and some more for the Java side. The proposed fix on the hotspot side is to
> set `any_cgroup_mounts_found` to true only if one of those controllers show up in mountinfo. Otherwise, we know it's
> cgroup v2 due to the zero hierarchy ids.  For the Java side the proposal is to add some parsing for mountinfo lines and
> look for `cgroup` FS-type lines which aren't also mounted purely for systemd.
> **Testing**
> 
>  - [x] Linux x86_64 container tests on cgroup v1 (fastdebug)
>  - [x] Linux x86_64 container tests on cgroup v2 (fastdebug)
>  - [x] Added regression test which fails prior the patch and passes after
>  - [ ] Submit testing (still running)

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

  8245543: Cgroups: Incorrect detection logic on some systems (still reproducible)

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/485/files
  - new: https://git.openjdk.java.net/jdk/pull/485/files/b7c7f510..6c4fadd1

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

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

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

From sgehwolf at openjdk.java.net  Mon Oct  5 08:39:48 2020
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Mon, 5 Oct 2020 08:39:48 GMT
Subject: RFR: 8245543: Cgroups: Incorrect detection logic on some systems
 (still reproducible) [v2]
In-Reply-To: <5PIk4w58jDVRPA8DTWjVRBzuVxRH5HxxYM_cb8bc-jg=.a715f356-856a-430d-b641-98345ca5ad62@github.com>
References: <CWATRi437QpkCA1sx-EsHFqVlSCV-G8EgkEoGdJgPHc=.a743be7e-8a00-4d91-866d-86ccf3fe714f@github.com>
 <5PIk4w58jDVRPA8DTWjVRBzuVxRH5HxxYM_cb8bc-jg=.a715f356-856a-430d-b641-98345ca5ad62@github.com>
Message-ID: <us2F114jXVkhbq-yASGl5A5lHV2wMTKTNfImk4M-L2s=.c226bb29-4558-4307-9058-b3cadad48382@github.com>

On Sun, 4 Oct 2020 18:12:14 GMT, Boris Ulasevich <bulasevich at openjdk.org> wrote:

>> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8245543: Cgroups: Incorrect detection logic on some systems (still reproducible)
>
> src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemFactory.java line 72:
> 
>> 70:      *  Pattern explanation:
>> 71:      *
>> 72:      *  /`````\    /`````\    /`````\    /```````\    /```````\    /```\ (8) /```````\     (10) + (11)
> 
> Alternatively, consider the inline comment:
> 
>     private static final Pattern MOUNTINFO_PATTERN = Pattern.compile(
>         "^[^\\s]+\\s+[^\\s]+\\s+[^\\s]+\\s+" +  // (1) + (2) + (3)
>         "([^\\s]+)\\s+([^\\s]+)\\s+"         +  // (4) + (5) - group 1,2: mount point, mount options
>         "[^-]+-\\s+"    +                       // (6) + (7) + (8)
>         "([^\\s]+)\\s+" +                       // (9) - group 3: fstype
>         ".*$");                                 // (10) + (11)

Good suggestion. I've changed it to what you've suggested and removed the unused groups 1 and 2.

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

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

From sgehwolf at openjdk.java.net  Mon Oct  5 09:02:37 2020
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Mon, 5 Oct 2020 09:02:37 GMT
Subject: RFR: 8245543: Cgroups: Incorrect detection logic on some systems
 (still reproducible)
In-Reply-To: <p3wicme6jMQZ8q_ATLI4V-qN3p0PvWL8QACK3SCpE50=.bfa7b1e4-137b-4045-95f9-cb5fa7391ce5@github.com>
References: <CWATRi437QpkCA1sx-EsHFqVlSCV-G8EgkEoGdJgPHc=.a743be7e-8a00-4d91-866d-86ccf3fe714f@github.com>
 <GQPVanQ-V8oL4npQHUXk5xw5pxR4fF8z3C_Wj5l7uDw=.1f4b9c49-252f-47dd-a0cf-6d36794928db@github.com>
 <p3wicme6jMQZ8q_ATLI4V-qN3p0PvWL8QACK3SCpE50=.bfa7b1e4-137b-4045-95f9-cb5fa7391ce5@github.com>
Message-ID: <WhAslIX2i5viA-xU-nI9nNZRV91_XmEkwozi8NkWyLs=.a8ada202-c231-4837-9ac2-0091bb1bc510@github.com>

On Sun, 4 Oct 2020 18:14:37 GMT, Boris Ulasevich <bulasevich at openjdk.org> wrote:

> The change looks reasonable. I checked the fail - it is gone with the change! And both jtreg tests passed.

Thanks for the review and for testing it!

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

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

From sgehwolf at openjdk.java.net  Mon Oct  5 09:02:38 2020
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Mon, 5 Oct 2020 09:02:38 GMT
Subject: RFR: 8245543: Cgroups: Incorrect detection logic on some systems
 (still reproducible) [v2]
In-Reply-To: <5PIk4w58jDVRPA8DTWjVRBzuVxRH5HxxYM_cb8bc-jg=.a715f356-856a-430d-b641-98345ca5ad62@github.com>
References: <CWATRi437QpkCA1sx-EsHFqVlSCV-G8EgkEoGdJgPHc=.a743be7e-8a00-4d91-866d-86ccf3fe714f@github.com>
 <5PIk4w58jDVRPA8DTWjVRBzuVxRH5HxxYM_cb8bc-jg=.a715f356-856a-430d-b641-98345ca5ad62@github.com>
Message-ID: <aYRHT6XXDenNo-3JQTyshrni0Itt8dJeU4j30fv64Rk=.85f8b9ae-4ac1-4488-b1b3-82c1001fb8f4@github.com>

On Sun, 4 Oct 2020 18:12:39 GMT, Boris Ulasevich <bulasevich at openjdk.org> wrote:

>> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8245543: Cgroups: Incorrect detection logic on some systems (still reproducible)
>
> src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemFactory.java line 80:
> 
>> 78:      */
>> 79:     private static final Pattern MOUNTINFO_PATTERN =
>> 80:
>> Pattern.compile("^[^\\s]+\\s+[^\\s]+\\s+[^\\s]+\\s+([^\\s]+)\\s+([^\\s]+)\\s+[^-]+-\\s+([^\\s]+)\\s+.*$");
> 
> Only group_3 = fstype is used in the pattern, right?

Yes. I've removed unused groups now, though.

Originally, my thinking was that `mount root` and `mount path` would be useful too so I kept it in. It would certainly
be useful for getting rid of reading `/proc/self/mountinfo` twice on the Java side. As a future enhancement we could do
away with double parsing of mount info by keeping track of relevant cgroup controller info. I've filed
[JDK-8254001](https://bugs.openjdk.java.net/browse/JDK-8254001) to track this.

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

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

From rwestberg at openjdk.java.net  Mon Oct  5 09:56:39 2020
From: rwestberg at openjdk.java.net (Robin Westberg)
Date: Mon, 5 Oct 2020 09:56:39 GMT
Subject: RFR: 8253761: Wrong URI syntax printed by jar --describe-module
In-Reply-To: <g2xPz8RM-0RV6pO74DD3_i0WekIu42Ub9I8aHuyWdg4=.504094c5-926d-4065-adfa-e885f360a463@github.com>
References: <GoJ43lbyj8ktcJfP8vpa6J3LK2_nFCyo4eFwJfPSFcY=.50f190e3-f244-43e8-95be-9377417d9c9b@github.com>
 <KX2hm__Fl4-b1qiK2FOHEYcmt4xNoMfZiZpCRu1G2jY=.457dfb03-27c0-41bc-850b-c1540e15f712@github.com>
 <WpA1zwswZsUK3UpcmF011Lja4yNoaZrWcAbJUjG3yn4=.c62c2842-58db-49ff-af82-eb1cfb2577e2@github.com>
 <-1XHmzbRjoSG_fSaIWdhIUPuF8ZEcz8VmG-iWZ8NoQw=.92ae1a1f-fd51-431b-bcde-ca01d603aa04@github.com>
 <g2xPz8RM-0RV6pO74DD3_i0WekIu42Ub9I8aHuyWdg4=.504094c5-926d-4065-adfa-e885f360a463@github.com>
Message-ID: <en7lwN3njdMt7yY8fRCoHWoPHPNYXd-XQgHkVRgEkJU=.713f04d3-60f2-45ee-8538-5593b680a389@github.com>

On Sun, 4 Oct 2020 17:26:19 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> A new assert in the describeModuleFoo test would be great, thank you!
>
> How do I trigger a "pre-submit testing using GitHub Actions workflow"[[1]] to be started for this PR?
> 
> [1]: https://mail.openjdk.java.net/pipermail/jdk-dev/2020-September/004736.html

The workflow definition file needs to be present in your branch, but it seems to be a bit too old (`This branch is 2
commits ahead, 85 commits behind openjdk:master.`). So simply merge `jdk/master` into your branch and they should be
triggered.

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

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

From volker.simonis at gmail.com  Mon Oct  5 10:04:51 2020
From: volker.simonis at gmail.com (Volker Simonis)
Date: Mon, 5 Oct 2020 12:04:51 +0200
Subject: Request for Discussion: 8253952: Work around wrong usage of
 ZipOutputStream.putNextEntry() in user code
In-Reply-To: <4658d3a6-3360-fb84-e5ff-20dc6cc61b92@oracle.com>
References: <CA+3eh12_-fNxf_KFK68WEqVoD_n6CD7RCbe=LoKCyCeUQ3w0oQ@mail.gmail.com>
 <4658d3a6-3360-fb84-e5ff-20dc6cc61b92@oracle.com>
Message-ID: <CA+3eh10vr3vs92UPu7PwiaofZpf46QuzsuFf4bvf26gbYKF3-g@mail.gmail.com>

Hi Alan,

thanks a lot for your feedback. Please find my answers inline below:

On Sat, Oct 3, 2020 at 9:11 PM Alan Bateman <Alan.Bateman at oracle.com> wrote:
>
> On 02/10/2020 20:44, Volker Simonis wrote:
> > Hi,
> >
> > I'd like to get your opinion on a workaround for a common but wrong
> > usage pattern of ZipOutputStream.putNextEntry() in user code. I've
> > created a Draft PR with all the gory details (which I'll include here
> > for your convenience). Please let me know what you think?
> >
> java.util.zip is JDK 1.1 era API and has several usability issues.Yes,

I know and I think it's high time to fix them :)

> ZOS.putNextEntry method can be a hazard. Adding an @apiNote with an
> example showing how to use API correctly shouldn't be an issue.

OK. I'll open a new issue so we can handle that independently.

> I don't
> think the proposal to add a system property to change the behavior is
> feasible, at least not without changing the spec but even then it would
> be very icky.

Why do you think so? The answer to this question is especially
important to me because we are considering doing this in our internal
version independently of upstream OpenJKD (and potentially also in 8 &
11).

The spec doesn't currently say anything about the exact zip format
created by ZipOutputStream. I.e. it doesn't mention if ZipOutputStream
creates Local File Headers with compressed size information or if it
puts the compressed size information into the Data Descriptor.
Currently this depends solely on the compressed size value of the
corresponding ZipEntry. But as I've detailed in my initial mail, using
this value is not correct in general if it was determined implicitly
by reading it from a zip file because there's no way to determine the
compression level and exact deflater implementation which produced
that entry. Using that value can only work by chance if the source zip
entry was created by the exact same zip implementation with the exact
same compression level that is used by  the current ZipOutputStream.

Notice that the new property won't change any of the current behaviour
if we call ZipEntry.setCompressedSize() to explicitly set the
compressed size of a ZipEntry object. So if somebody really knows the
compressed size of a ZipEntry (e.g. by manually compressing the data
before), he still can use  setCompressedSize() to trigger the creation
of a LFH with compressed size information. But again, there's nothing
in the spec of ZipOutputStream that mandates the creation of a
specific LFH or that mandates that ZipOutputStream is honoring the
compressed size information from a ZipEntry.

The spec also doesn't say anything about the nature of a ZipEntry we
get from ZipInputStream or ZipFile and especially not if it has the
compressed size attribute set or not. As I've described before, for
ZipInputStream this depends on the format of the zip file and if the
corresponding entry has that information in the LFH. For ZipEntries we
get from ZipFile, the compressed size is always set because ZipFile
uses the Central Directory File Header.

Finally, although that's clearly not proof, I just want to mention
that I've run the corresponding regression and JCK tests without any
issues.

So can you please be more specific why do you think such a property
would require a spec change and if you still think so how and in which
part of the spec?

And just as a side note, we also use the "jdk.util.zip.inhibitZip64"
property in ZipOutputStream for a similar reason. I just wonder how
that could pass the CCC process as I couldn't even find any
documentation for it :)

> Have you explored adding a better API instead of a
> workaround? It wouldn't be hard to have ZipEntry define a writeTo or
> transferTo method for example.

I thought about that but unfortunately I think that's not trivial and
it certainly wouldn't solve the problem with the existing bad user
code which I want to address with the new system property.

I'm also not sure which semantics you envision for
ZipEntry.transferTo()? If it is only meant to copy a ZipEntry object
from one file into another, that would have the same problems except
that we would have the chance to specify its semantics such that it
would always ignore its compressed size attribute.

If you mean that  ZipEntry.transferTo() will be intended to copy a
ZipEntry together with the associated, compressed data that will be
much harder if not impossible to implement with the current API. The
first problem is that ZipEntry has no reference to its associated
ZipFile or ZipInputStream. The much bigger problem is that
ZipInputSream is a "streaming" API. We might read from a zip file
which doesn't have the compressed size information in the LFH. In such
a case, it would be impossible to read the compressed data from the
stream because we don't know its length. We can only start to inflate
the data until inflation stops. Only at that point we know the
compressed size of the entry. But at that point we can't access the
compressed data any more.

So instead of trying to fix this old API, maybe it's time for a
completely new one? I've also started to think a little bit about
creating a new compression/decompression library. It could be
implemented as service with the help of the SPI and could provide
support for additional compression formats as well. What do you think
about such an idea?

Best regards,
Volker

>
> -Alan.

From sgehwolf at openjdk.java.net  Mon Oct  5 10:12:39 2020
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Mon, 5 Oct 2020 10:12:39 GMT
Subject: RFR: 8245543: Cgroups: Incorrect detection logic on some systems
 (still reproducible)
In-Reply-To: <WhAslIX2i5viA-xU-nI9nNZRV91_XmEkwozi8NkWyLs=.a8ada202-c231-4837-9ac2-0091bb1bc510@github.com>
References: <CWATRi437QpkCA1sx-EsHFqVlSCV-G8EgkEoGdJgPHc=.a743be7e-8a00-4d91-866d-86ccf3fe714f@github.com>
 <GQPVanQ-V8oL4npQHUXk5xw5pxR4fF8z3C_Wj5l7uDw=.1f4b9c49-252f-47dd-a0cf-6d36794928db@github.com>
 <p3wicme6jMQZ8q_ATLI4V-qN3p0PvWL8QACK3SCpE50=.bfa7b1e4-137b-4045-95f9-cb5fa7391ce5@github.com>
 <WhAslIX2i5viA-xU-nI9nNZRV91_XmEkwozi8NkWyLs=.a8ada202-c231-4837-9ac2-0091bb1bc510@github.com>
Message-ID: <KjxtazSZzF-w2Vcm0WuTzlKGWTrRq9J8wSpnutCNADo=.72a3458f-fc7c-4090-b0f0-ead08869ebb9@github.com>

On Mon, 5 Oct 2020 09:00:17 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> The change looks reasonable. I checked the fail - it is gone with the change! And both jtreg tests passed.
>
>> The change looks reasonable. I checked the fail - it is gone with the change! And both jtreg tests passed.
> 
> Thanks for the review and for testing it!

@bobvandette Could you perhaps have a look at this? Many thanks in advance!

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

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

From cstein at openjdk.java.net  Mon Oct  5 10:15:45 2020
From: cstein at openjdk.java.net (Christian Stein)
Date: Mon, 5 Oct 2020 10:15:45 GMT
Subject: RFR: 8253761: Wrong URI syntax printed by jar --describe-module
 [v3]
In-Reply-To: <GoJ43lbyj8ktcJfP8vpa6J3LK2_nFCyo4eFwJfPSFcY=.50f190e3-f244-43e8-95be-9377417d9c9b@github.com>
References: <GoJ43lbyj8ktcJfP8vpa6J3LK2_nFCyo4eFwJfPSFcY=.50f190e3-f244-43e8-95be-9377417d9c9b@github.com>
Message-ID: <C0xfj1ijhqH_WTBeQUAbMp4cseY0gzK_nkpwUQAD5gw=.e08d4ecb-1bd3-466d-a8ac-1a0b8b2531ba@github.com>

> This commit replaces `"/!"` with `"!/"` in order to generate
> valid URIs when printing a module description of a modular
> JAR file. A valid URI is described here: [1]
> 
> https://bugs.openjdk.java.net/browse/JDK-8253761
> 
> [1] https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/net/JarURLConnection.html

Christian Stein has updated the pull request with a new target base due to a merge or a rebase. The pull request now
contains one commit:

  8253761: Fix URI syntax of jar --describe-module

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

Changes: https://git.openjdk.java.net/jdk/pull/393/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=393&range=02
  Stats: 7 lines in 2 files changed: 4 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/393.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/393/head:pull/393

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

From cstein at openjdk.java.net  Mon Oct  5 10:15:46 2020
From: cstein at openjdk.java.net (Christian Stein)
Date: Mon, 5 Oct 2020 10:15:46 GMT
Subject: RFR: 8253761: Wrong URI syntax printed by jar --describe-module
In-Reply-To: <en7lwN3njdMt7yY8fRCoHWoPHPNYXd-XQgHkVRgEkJU=.713f04d3-60f2-45ee-8538-5593b680a389@github.com>
References: <GoJ43lbyj8ktcJfP8vpa6J3LK2_nFCyo4eFwJfPSFcY=.50f190e3-f244-43e8-95be-9377417d9c9b@github.com>
 <KX2hm__Fl4-b1qiK2FOHEYcmt4xNoMfZiZpCRu1G2jY=.457dfb03-27c0-41bc-850b-c1540e15f712@github.com>
 <WpA1zwswZsUK3UpcmF011Lja4yNoaZrWcAbJUjG3yn4=.c62c2842-58db-49ff-af82-eb1cfb2577e2@github.com>
 <-1XHmzbRjoSG_fSaIWdhIUPuF8ZEcz8VmG-iWZ8NoQw=.92ae1a1f-fd51-431b-bcde-ca01d603aa04@github.com>
 <g2xPz8RM-0RV6pO74DD3_i0WekIu42Ub9I8aHuyWdg4=.504094c5-926d-4065-adfa-e885f360a463@github.com>
 <en7lwN3njdMt7yY8fRCoHWoPHPNYXd-XQgHkVRgEkJU=.713f04d3-60f2-45ee-8538-5593b680a389@github.com>
Message-ID: <93yWBvJNiKenvcgmOYASLyruoMYcsYILHJ9ccBXR-HE=.a68bd529-9c5b-4129-ba3b-434d5ef70563@github.com>

On Mon, 5 Oct 2020 09:53:39 GMT, Robin Westberg <rwestberg at openjdk.org> wrote:

>> How do I trigger a "pre-submit testing using GitHub Actions workflow"[[1]] to be started for this PR?
>> 
>> [1]: https://mail.openjdk.java.net/pipermail/jdk-dev/2020-September/004736.html
>
> The workflow definition file needs to be present in your branch, but it seems to be a bit too old (`This branch is 2
> commits ahead, 85 commits behind openjdk:master.`). So simply merge `jdk/master` into your branch and they should be
> triggered.

Rebased and squashed commits. Let's see...

They're running: https://github.com/sormuras/jdk/actions/runs/289171488

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

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

From sgehwolf at openjdk.java.net  Mon Oct  5 10:16:49 2020
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Mon, 5 Oct 2020 10:16:49 GMT
Subject: RFR: 8245543: Cgroups: Incorrect detection logic on some systems
 (still reproducible) [v3]
In-Reply-To: <CWATRi437QpkCA1sx-EsHFqVlSCV-G8EgkEoGdJgPHc=.a743be7e-8a00-4d91-866d-86ccf3fe714f@github.com>
References: <CWATRi437QpkCA1sx-EsHFqVlSCV-G8EgkEoGdJgPHc=.a743be7e-8a00-4d91-866d-86ccf3fe714f@github.com>
Message-ID: <9Y61ZqGTPrr7PY1UjY55Y3UdjZHu08tfn0iE6AhUb9Q=.2da3dbc9-55c2-48ac-b087-a2b26f0c6378@github.com>

> An issue similar to [JDK-8239559](https://bugs.openjdk.java.net/browse/JDK-8239559) has been discovered. On the
> affected system, `/proc/self/mountinfo` contains a line such as this one:
> 
> 35 26 0:26 / /sys/fs/cgroup/systemd rw,nosuid,nodev,noexec,relatime - cgroup systemd rw,name=systemd
>  
> 
> Note that `/proc/cgroups` looks like this:
> 
> #subsys_name	hierarchy	num_cgroups	enabled
> cpuset	0	1	1
> cpu	0	1	1
> cpuacct	0	1	1
> blkio	0	1	1
> memory	0	1	1
> devices	0	1	1
> freezer	0	1	1
> net_cls	0	1	1
> perf_event	0	1	1
> net_prio	0	1	1
> hugetlb	0	1	1
> pids	0	1	1
> 
> This is in fact a cgroups v1 system with systemd put into a separate namespace via FS type `cgroup`. That mountinfo
> line confuses the cgroups version detection heuristic. It only looked whether or not there is **any** entry in
> mountinfo of FS-type `cgroup` . That's wrong. A better heuristic would be looking at controllers we care about: `cpu`,
> `cpuacct`, `memory`, `cpuset` for hotspot and some more for the Java side. The proposed fix on the hotspot side is to
> set `any_cgroup_mounts_found` to true only if one of those controllers show up in mountinfo. Otherwise, we know it's
> cgroup v2 due to the zero hierarchy ids.  For the Java side the proposal is to add some parsing for mountinfo lines and
> look for `cgroup` FS-type lines which aren't also mounted purely for systemd.
> **Testing**
> 
>  - [x] Linux x86_64 container tests on cgroup v1 (fastdebug)
>  - [x] Linux x86_64 container tests on cgroup v2 (fastdebug)
>  - [x] Added regression test which fails prior the patch and passes after
>  - [x] Submit testing

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

  Fix typo in comment

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/485/files
  - new: https://git.openjdk.java.net/jdk/pull/485/files/6c4fadd1..d334ac60

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

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

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

From pliden at openjdk.java.net  Mon Oct  5 11:04:38 2020
From: pliden at openjdk.java.net (Per Liden)
Date: Mon, 5 Oct 2020 11:04:38 GMT
Subject: RFR: 8188055: (ref) Add Reference::refersTo predicate
In-Reply-To: <D4HSg8FT20Eaxk5KJkkw0GgETSxRkBn1ipS3Dt0kPto=.e4bab078-2e04-4413-90cb-9bfafb2a6831@github.com>
References: <D4HSg8FT20Eaxk5KJkkw0GgETSxRkBn1ipS3Dt0kPto=.e4bab078-2e04-4413-90cb-9bfafb2a6831@github.com>
Message-ID: <lNHgojO3Jrdaaq9RPiRq4IexTIjxVunPQKWg3f02m34=.d6c68bfd-b622-46b8-8737-be1cee2765f0@github.com>

On Sun, 4 Oct 2020 03:59:59 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Finally returning to this review that was started in April 2020.  I've
> recast it as a github PR.  I think the security concern raised by Gil
> has been adequately answered.
> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-April/029203.html
> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-July/030401.html
> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-August/030677.html
> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-September/030793.html
> 
> Please review a new function: java.lang.ref.Reference.refersTo.
> 
> This function is needed to test the referent of a Reference object without
> artificially extending the lifetime of the referent object, as may happen
> when calling Reference.get.  Some garbage collectors require extending the
> lifetime of a weak referent when accessed, in order to maintain collector
> invariants.  Lifetime extension may occur with any collector when the
> Reference is a SoftReference, as calling get indicates recent access.  This
> new function also allows testing the referent of a PhantomReference, which
> can't be accessed by calling get.
> 
> The new function uses native methods whose implementations are in the VM so
> they can use the Access API.  It is the intent that these methods will be
> intrinsified by optimizing compilers like C2 or graal, but that hasn't been
> implemented yet.  Bear that in mind before rushing off to change existing
> uses of Reference.get.
> 
> There are two native methods involved, one in Reference and an override in
> PhantomReference, both package private in java.lang.ref. The reason for this
> split is to simplify the intrinsification. This is a change from the version
> from April 2020; that version had a single native method in Reference,
> implemented using the ON_UNKNOWN_OOP_REF Access reference strength category.
> However, adding support for that category in the compilers adds significant
> implementation effort and complexity. Splitting avoids that complexity.
> 
> Testing:
> mach5 tier1
> Locally (linux-x64) verified the new test passes with various garbage collectors.

test/hotspot/jtreg/gc/TestReferenceRefersTo.java line 179:

> 177:             // For some collectors, calling get() will keep testObject4 alive.
> 178:             // For example, SATB collectors or ZGC, but not collectors using
> 179:             // incremental update barriers like CMS.

Remove obsolete CMS comment?

test/hotspot/jtreg/gc/TestReferenceRefersTo.java line 65:

> 63:
> 64:     private static WeakReference<TestObject> testWeak2 = null;
> 65:     private static WeakReference<TestObject> testWeak3 = null;

It looks like test*2 and test*3 test the same thing in both tests, so test*3 could be removed, and test*4 could be
renamed test*3.

src/hotspot/share/prims/jvm.cpp line 3446:

> 3444:   oop referent = HeapAccess<on_ref | AS_NO_KEEPALIVE>::oop_load_at(ref_oop, offset);
> 3445:   return referent == JNIHandles::resolve(o);
> 3446: }

How about moving the inner logic to java_lang_ref_{Reference,PhantomReference}::refers_to() functions?

src/hotspot/share/prims/jvm.cpp line 3451:

> 3449:   JVMWrapper("JVM_ReferenceRefersTo");
> 3450:   return referenceRefersTo<ON_WEAK_OOP_REF>(ref, o);
> 3451: JVM_END

... and let this be something like:

JVM_ENTRY(jboolean, JVM_ReferenceRefersTo(JNIEnv* env, jobject ref, jobject o))
  JVMWrapper("JVM_ReferenceRefersTo");
  oop ref_oop = JNIHandles::resolve_non_null(ref);
  oop cmp_oop = JNIHandles::resolve(o);
  return java_lang_ref_Reference::refers_to(ref_oop, cmp_oop);
JVM_END

src/hotspot/share/prims/jvm.cpp line 3460:

> 3458:   JVMWrapper("JVM_PhantomReferenceRefersTo");
> 3459:   return referenceRefersTo<ON_PHANTOM_OOP_REF>(ref, o);
> 3460: JVM_END

... and let this be something like:

JVM_ENTRY(jboolean, JVM_PhantomReferenceRefersTo(JNIEnv* env, jobject ref, jobject o))
  JVMWrapper("JVM_ReferenceRefersTo");
  oop ref_oop = JNIHandles::resolve_non_null(ref);
  oop cmp_oop = JNIHandles::resolve(o);
  return java_lang_ref_PhantomReference::refers_to(ref_oop, cmp_oop);
JVM_END

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

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

From alanb at openjdk.java.net  Mon Oct  5 11:59:41 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 5 Oct 2020 11:59:41 GMT
Subject: RFR: 8253761: Wrong URI syntax printed by jar --describe-module
In-Reply-To: <93yWBvJNiKenvcgmOYASLyruoMYcsYILHJ9ccBXR-HE=.a68bd529-9c5b-4129-ba3b-434d5ef70563@github.com>
References: <GoJ43lbyj8ktcJfP8vpa6J3LK2_nFCyo4eFwJfPSFcY=.50f190e3-f244-43e8-95be-9377417d9c9b@github.com>
 <KX2hm__Fl4-b1qiK2FOHEYcmt4xNoMfZiZpCRu1G2jY=.457dfb03-27c0-41bc-850b-c1540e15f712@github.com>
 <WpA1zwswZsUK3UpcmF011Lja4yNoaZrWcAbJUjG3yn4=.c62c2842-58db-49ff-af82-eb1cfb2577e2@github.com>
 <-1XHmzbRjoSG_fSaIWdhIUPuF8ZEcz8VmG-iWZ8NoQw=.92ae1a1f-fd51-431b-bcde-ca01d603aa04@github.com>
 <g2xPz8RM-0RV6pO74DD3_i0WekIu42Ub9I8aHuyWdg4=.504094c5-926d-4065-adfa-e885f360a463@github.com>
 <en7lwN3njdMt7yY8fRCoHWoPHPNYXd-XQgHkVRgEkJU=.713f04d3-60f2-45ee-8538-5593b680a389@github.com>
 <93yWBvJNiKenvcgmOYASLyruoMYcsYILHJ9ccBXR-HE=.a68bd529-9c5b-4129-ba3b-434d5ef70563@github.com>
Message-ID: <dL1TskN-_-kC5T6ZEfU1kSuIqLOSEhE_JXtoHbC0fxA=.fc3c9cc4-3bd9-48ec-b9e8-5d988658486d@github.com>

On Mon, 5 Oct 2020 10:11:45 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> The workflow definition file needs to be present in your branch, but it seems to be a bit too old (`This branch is 2
>> commits ahead, 85 commits behind openjdk:master.`). So simply merge `jdk/master` into your branch and they should be
>> triggered.
>
> Rebased and squashed commits. Let's see...
> 
> They're running: https://github.com/sormuras/jdk/actions/runs/289171488

I think the change exposes issues in a couple of tests. It looks like partialUpdateFooModuleInfo
(modularJar/Basic.java) expects the wrong result, as does some of the tests in mmrjar/Basic.java.

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

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

From zgu at openjdk.java.net  Mon Oct  5 12:43:36 2020
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Mon, 5 Oct 2020 12:43:36 GMT
Subject: RFR: 8253948: Memory leak in ImageFileReader [v2]
In-Reply-To: <yAHLpx1yD7FfAOAhEqrSV0r_xb6sRkbhhC3UIo1AlTA=.73f7defb-4fa1-426d-865a-34b1a63aef9a@github.com>
References: <yAHLpx1yD7FfAOAhEqrSV0r_xb6sRkbhhC3UIo1AlTA=.73f7defb-4fa1-426d-865a-34b1a63aef9a@github.com>
Message-ID: <cZ8ifE273y9uCIl6JJrF_g2djbSGdyPJtb07lJ4JqBc=.98de3abb-a74a-4211-8b45-7ef2c9c9fc69@github.com>

> ImageFileReader allocates ImageModuleData in ImageFileReader::open(), but never free.
> 
> Also renamed module_data to _module_data to be consistent with other member variables.
> 
> Test:
> - [x] tier1 on Linux x86_64

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

  Fix indents

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/490/files
  - new: https://git.openjdk.java.net/jdk/pull/490/files/925fb03b..18326c81

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

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

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

From alanb at openjdk.java.net  Mon Oct  5 12:49:41 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 5 Oct 2020 12:49:41 GMT
Subject: RFR: 8253948: Memory leak in ImageFileReader [v2]
In-Reply-To: <Elpk6jjUdqnP2idwIf7DZ8SwZD1AqRn8O9bYxmrcuoc=.149ea544-f9d0-490c-b2da-f9191ff41293@github.com>
References: <yAHLpx1yD7FfAOAhEqrSV0r_xb6sRkbhhC3UIo1AlTA=.73f7defb-4fa1-426d-865a-34b1a63aef9a@github.com>
 <Elpk6jjUdqnP2idwIf7DZ8SwZD1AqRn8O9bYxmrcuoc=.149ea544-f9d0-490c-b2da-f9191ff41293@github.com>
Message-ID: <5pMS58rzRBTEFEEBc2rEVbAs6aL-79XW4gG6ztemSYY=.7884a8c4-1b6c-45d8-ad6c-aded06291705@github.com>

On Sat, 3 Oct 2020 16:17:50 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix indents
>
> The jimage file is opened at startup and should never be closed. However the jrtfs provider (used by IDEs and other
> tools to access the resources in a target run-time image) may run into it so good to get it fixed.
> Can you fix the formatting to use 4-space indentation consistently?

I should have been clearer. The indentation issues are with changed lines 375, 446-447, and 581.

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

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

From erikj at openjdk.java.net  Mon Oct  5 13:01:56 2020
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Mon, 5 Oct 2020 13:01:56 GMT
Subject: RFR: 8245194: Unix domain socket channel implementation [v14]
In-Reply-To: <quEqJdCbjSrirA9ItzvUxkmTaj115Y8z69jfXS6uu0s=.bd3d0f91-1019-4463-ab11-dfb53093e0b5@github.com>
References: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
 <quEqJdCbjSrirA9ItzvUxkmTaj115Y8z69jfXS6uu0s=.bd3d0f91-1019-4463-ab11-dfb53093e0b5@github.com>
Message-ID: <kh5i83aWg5Gx5xEvp1WQh2zLUi5nDrDGji8ImAq1iAk=.175405a2-bb66-478b-98f2-cbcdc429162d@github.com>

On Sun, 4 Oct 2020 13:14:49 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Continuing this review as a PR on github with the comments below incorporated. I expect there will be a few more
>> iterations before integrating.
>> On 06/09/2020 19:47, Alan Bateman wrote:
>>> On 26/08/2020 15:24, Michael McMahon wrote:
>>>>
>>>> As I mentioned the other day, I wasn't able to use the suggested method on Windows which returns an absolute path. So,
>>>> I added a method to WindowsPath which returns the path in the expected UTF-8 encoding as a byte[]. Let me know what you
>>>> think of that.
>>>>
>>>> There is a fair bit of other refactoring and simplification done also. Next version is at:
>>>>
>>>> http://cr.openjdk.java.net/~michaelm/8245194/impl.webrev/webrev.9/
>>>>
>>> Adding a method to WindowsPath to encode the path using UTF-8 is okay but I don't think we should be caching it as the
>>> encoding for sun_path is an outlier on Windows. I'm also a bit dubious about encoding a relative path when the resolved
>>> path (before encoding) is > 247 chars. The documentation on the MS site isn't very completely and I think there are a
>>> number points that require clarification to fully understand how this will work with relative, directly relative and
>>> drive relative paths.
>>>
>> 
>> Maybe it would be better to just use the path returned from toString() and do the conversion to UTF-8 externally. That
>> would leave WindowsPath unchanged.
>>> In the same area, the new PathUtil is a bit inconsistent with the existing provider code. One suggestion is to add a
>>> method to AbstractFileSystemProvider instead. That is the base class the platform providers and would be a better place
>>> to get the file path in bytes.
>>>
>> 
>> Okay, I gave the method a name that is specific to Unix domain sockets because this UTF-8 strangeness is not likely to
>> be useful by other components.
>>> One other comment on the changes to the file system provider it should be okay to change UnixUserPrinipals ad its
>>> fromUid and fromGid method to be public. This would mean that the patch shouldn't need to add UnixUserGroup (the main
>>> issue is that class is that it means we end up with two classes with static factory methods doing the same thing).
>> 
>> Okay, that does simplify it a bit.
>> 
>> Thanks,
>> Michael.
>> 
>>> -Alan.
>>>
>>>
>>>
>>>
>>>
>>>
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   - simplified Copy.gmk to CAT source files directly
>   - renamed net.properties source files to all be net.properties

Build changes look good.

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

Marked as reviewed by erikj (Reviewer).

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

From zgu at openjdk.java.net  Mon Oct  5 13:07:54 2020
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Mon, 5 Oct 2020 13:07:54 GMT
Subject: RFR: 8253948: Memory leak in ImageFileReader [v3]
In-Reply-To: <yAHLpx1yD7FfAOAhEqrSV0r_xb6sRkbhhC3UIo1AlTA=.73f7defb-4fa1-426d-865a-34b1a63aef9a@github.com>
References: <yAHLpx1yD7FfAOAhEqrSV0r_xb6sRkbhhC3UIo1AlTA=.73f7defb-4fa1-426d-865a-34b1a63aef9a@github.com>
Message-ID: <Qgd3Do1xPDkCfkNbY7EzLVFbzo8tBGQYe225Rxtm0Eg=.36f65476-2aa5-44ca-95d6-e4ce3b2ffb74@github.com>

> ImageFileReader allocates ImageModuleData in ImageFileReader::open(), but never free.
> 
> Also renamed module_data to _module_data to be consistent with other member variables.
> 
> Test:
> - [x] tier1 on Linux x86_64

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

  More indentation fixes

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/490/files
  - new: https://git.openjdk.java.net/jdk/pull/490/files/18326c81..c066d4ec

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

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

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

From alanb at openjdk.java.net  Mon Oct  5 13:11:53 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 5 Oct 2020 13:11:53 GMT
Subject: RFR: 8253948: Memory leak in ImageFileReader [v3]
In-Reply-To: <Qgd3Do1xPDkCfkNbY7EzLVFbzo8tBGQYe225Rxtm0Eg=.36f65476-2aa5-44ca-95d6-e4ce3b2ffb74@github.com>
References: <yAHLpx1yD7FfAOAhEqrSV0r_xb6sRkbhhC3UIo1AlTA=.73f7defb-4fa1-426d-865a-34b1a63aef9a@github.com>
 <Qgd3Do1xPDkCfkNbY7EzLVFbzo8tBGQYe225Rxtm0Eg=.36f65476-2aa5-44ca-95d6-e4ce3b2ffb74@github.com>
Message-ID: <BMKh8mkyI7oNnx8MzvYWtNJ3yArgARBeplIkstXPozo=.4b5e1efc-b157-4fe3-b652-5f47dc2eb01b@github.com>

On Mon, 5 Oct 2020 13:07:54 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> ImageFileReader allocates ImageModuleData in ImageFileReader::open(), but never free.
>> 
>> Also renamed module_data to _module_data to be consistent with other member variables.
>> 
>> Test:
>> - [x] tier1 on Linux x86_64
>
> Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More indentation fixes

Marked as reviewed by alanb (Reviewer).

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

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

From zgu at openjdk.java.net  Mon Oct  5 13:12:44 2020
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Mon, 5 Oct 2020 13:12:44 GMT
Subject: Integrated: 8253960: Memory leak in
 Java_java_lang_ClassLoader_defineClass0()
In-Reply-To: <BAK4q1qNuAQOQB5TRrxP6jLQEFIjvGJG1FWYItkE35A=.26aa8616-1922-483e-ac70-6f77a3aa5e53@github.com>
References: <BAK4q1qNuAQOQB5TRrxP6jLQEFIjvGJG1FWYItkE35A=.26aa8616-1922-483e-ac70-6f77a3aa5e53@github.com>
Message-ID: <tHPUhReNKz7vaaHbGHp1AUUVsQE5xXkh23fg6VImJho=.b7c84ce2-7247-4c03-beda-62ceafeb2fa1@github.com>

On Sat, 3 Oct 2020 00:05:40 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> The memory leak is quite obvious. Early return results 'body' not been released.
> 
> Test:
> 
> - [x] tier1 on Linux x86_64

This pull request has now been integrated.

Changeset: 19219a96
Author:    Zhengyu Gu <zgu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/19219a96
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8253960: Memory leak in Java_java_lang_ClassLoader_defineClass0()

Reviewed-by: mchung, stuefe, alanb

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

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

From zgu at openjdk.java.net  Mon Oct  5 13:54:47 2020
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Mon, 5 Oct 2020 13:54:47 GMT
Subject: Integrated: 8253948: Memory leak in ImageFileReader
In-Reply-To: <yAHLpx1yD7FfAOAhEqrSV0r_xb6sRkbhhC3UIo1AlTA=.73f7defb-4fa1-426d-865a-34b1a63aef9a@github.com>
References: <yAHLpx1yD7FfAOAhEqrSV0r_xb6sRkbhhC3UIo1AlTA=.73f7defb-4fa1-426d-865a-34b1a63aef9a@github.com>
Message-ID: <lvAmWxRFwTnIpNl0HlFVbJx9fBOFh1LHzNwXpmc1dH8=.02de66ad-666c-4830-8fe7-eb0795c562c8@github.com>

On Fri, 2 Oct 2020 20:47:16 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> ImageFileReader allocates ImageModuleData in ImageFileReader::open(), but never free.
> 
> Also renamed module_data to _module_data to be consistent with other member variables.
> 
> Test:
> - [x] tier1 on Linux x86_64

This pull request has now been integrated.

Changeset: 81dae70f
Author:    Zhengyu Gu <zgu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/81dae70f
Stats:     15 lines in 2 files changed: 10 ins; 0 del; 5 mod

8253948: Memory leak in ImageFileReader

Reviewed-by: alanb

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

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

From cstein at openjdk.java.net  Mon Oct  5 14:11:41 2020
From: cstein at openjdk.java.net (Christian Stein)
Date: Mon, 5 Oct 2020 14:11:41 GMT
Subject: RFR: 8253761: Wrong URI syntax printed by jar --describe-module
In-Reply-To: <dL1TskN-_-kC5T6ZEfU1kSuIqLOSEhE_JXtoHbC0fxA=.fc3c9cc4-3bd9-48ec-b9e8-5d988658486d@github.com>
References: <GoJ43lbyj8ktcJfP8vpa6J3LK2_nFCyo4eFwJfPSFcY=.50f190e3-f244-43e8-95be-9377417d9c9b@github.com>
 <KX2hm__Fl4-b1qiK2FOHEYcmt4xNoMfZiZpCRu1G2jY=.457dfb03-27c0-41bc-850b-c1540e15f712@github.com>
 <WpA1zwswZsUK3UpcmF011Lja4yNoaZrWcAbJUjG3yn4=.c62c2842-58db-49ff-af82-eb1cfb2577e2@github.com>
 <-1XHmzbRjoSG_fSaIWdhIUPuF8ZEcz8VmG-iWZ8NoQw=.92ae1a1f-fd51-431b-bcde-ca01d603aa04@github.com>
 <g2xPz8RM-0RV6pO74DD3_i0WekIu42Ub9I8aHuyWdg4=.504094c5-926d-4065-adfa-e885f360a463@github.com>
 <en7lwN3njdMt7yY8fRCoHWoPHPNYXd-XQgHkVRgEkJU=.713f04d3-60f2-45ee-8538-5593b680a389@github.com>
 <93yWBvJNiKenvcgmOYASLyruoMYcsYILHJ9ccBXR-HE=.a68bd529-9c5b-4129-ba3b-434d5ef70563@github.com>
 <dL1TskN-_-kC5T6ZEfU1kSuIqLOSEhE_JXtoHbC0fxA=.fc3c9cc4-3bd9-48ec-b9e8-5d988658486d@github.com>
Message-ID: <Bp45DgSbJYnjN_A7JdwhVFYgfAx45ZFewpOD330hrNo=.2b1a33d9-c729-4577-b3b6-1e60cb07f4b8@github.com>

On Mon, 5 Oct 2020 11:56:49 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Rebased and squashed commits. Let's see...
>> 
>> They're running: https://github.com/sormuras/jdk/actions/runs/289171488
>
> I think the change exposes issues in a couple of tests. It looks like partialUpdateFooModuleInfo
> (modularJar/Basic.java) expects the wrong result, as does some of the tests in mmrjar/Basic.java.

I can't find the `modularJar/Basic.java` test run in the logs. In which job/tier/part does it hide?

> I think the change exposes issues in a couple of tests.

The one that fails the linked "pre-submit test" run above is already reported as
https://bugs.openjdk.java.net/browse/JDK-8249095 ("Aux.java" is not a valid file name on Windows).

> It looks like partialUpdateFooModuleInfo (modularJar/Basic.java) expects the wrong result, as does some of the tests in
> mmrjar/Basic.java.

Something for a follow-up issue/PR?

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

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

From alanb at openjdk.java.net  Mon Oct  5 14:50:46 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 5 Oct 2020 14:50:46 GMT
Subject: RFR: 8253761: Wrong URI syntax printed by jar --describe-module
In-Reply-To: <Bp45DgSbJYnjN_A7JdwhVFYgfAx45ZFewpOD330hrNo=.2b1a33d9-c729-4577-b3b6-1e60cb07f4b8@github.com>
References: <GoJ43lbyj8ktcJfP8vpa6J3LK2_nFCyo4eFwJfPSFcY=.50f190e3-f244-43e8-95be-9377417d9c9b@github.com>
 <KX2hm__Fl4-b1qiK2FOHEYcmt4xNoMfZiZpCRu1G2jY=.457dfb03-27c0-41bc-850b-c1540e15f712@github.com>
 <WpA1zwswZsUK3UpcmF011Lja4yNoaZrWcAbJUjG3yn4=.c62c2842-58db-49ff-af82-eb1cfb2577e2@github.com>
 <-1XHmzbRjoSG_fSaIWdhIUPuF8ZEcz8VmG-iWZ8NoQw=.92ae1a1f-fd51-431b-bcde-ca01d603aa04@github.com>
 <g2xPz8RM-0RV6pO74DD3_i0WekIu42Ub9I8aHuyWdg4=.504094c5-926d-4065-adfa-e885f360a463@github.com>
 <en7lwN3njdMt7yY8fRCoHWoPHPNYXd-XQgHkVRgEkJU=.713f04d3-60f2-45ee-8538-5593b680a389@github.com>
 <93yWBvJNiKenvcgmOYASLyruoMYcsYILHJ9ccBXR-HE=.a68bd529-9c5b-4129-ba3b-434d5ef70563@github.com>
 <dL1TskN-_-kC5T6ZEfU1kSuIqLOSEhE_JXtoHbC0fxA=.fc3c9cc4-3bd9-48ec-b9e8-5d988658486d@github.com>
 <Bp45DgSbJYnjN_A7JdwhVFYgfAx45ZFewpOD330hrNo=.2b1a33d9-c729-4577-b3b6-1e60cb07f4b8@github.com>
Message-ID: <5NjPvAfeD450cyljZArqpKV8JnmOfBhmcZOiDTdHJA4=.03347315-5968-459e-b0e2-670bd3a7df9c@github.com>

On Mon, 5 Oct 2020 14:08:32 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> I think the change exposes issues in a couple of tests. It looks like partialUpdateFooModuleInfo
>> (modularJar/Basic.java) expects the wrong result, as does some of the tests in mmrjar/Basic.java.
>
> I can't find the `modularJar/Basic.java` test run in the logs. In which job/tier/part does it hide?
> 
>> I think the change exposes issues in a couple of tests.
> 
> The one that fails the linked "pre-submit test" run above is already reported as
> https://bugs.openjdk.java.net/browse/JDK-8249095 ("Aux.java" is not a valid file name on Windows).
>> It looks like partialUpdateFooModuleInfo (modularJar/Basic.java) expects the wrong result, as does some of the tests in
>> mmrjar/Basic.java.
> 
> Something for a follow-up issue/PR?

The tests are test/jdk/tools/jar/modularJar/Basic.java and test/jdk/tools/jar/mmrjar/Basic.java. I've verified that
they will fail with the update to the jar tool so we'll need to change this as part of this PR.

The tests are in the core_tools test group, which seems to be tier2. I suspect the pre-submit job is running tier1.

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

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

From michaelm at openjdk.java.net  Mon Oct  5 15:12:47 2020
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Mon, 5 Oct 2020 15:12:47 GMT
Subject: RFR: 8245194: Unix domain socket channel implementation [v14]
In-Reply-To: <kh5i83aWg5Gx5xEvp1WQh2zLUi5nDrDGji8ImAq1iAk=.175405a2-bb66-478b-98f2-cbcdc429162d@github.com>
References: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
 <quEqJdCbjSrirA9ItzvUxkmTaj115Y8z69jfXS6uu0s=.bd3d0f91-1019-4463-ab11-dfb53093e0b5@github.com>
 <kh5i83aWg5Gx5xEvp1WQh2zLUi5nDrDGji8ImAq1iAk=.175405a2-bb66-478b-98f2-cbcdc429162d@github.com>
Message-ID: <pj2L_CiUy60Ifew4KZ37wJl5tDPin3_ZPzW0rL-IoBE=.feca82ef-4de2-46d7-8810-989bb1d1a72a@github.com>

On Mon, 5 Oct 2020 12:58:52 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   - simplified Copy.gmk to CAT source files directly
>>   - renamed net.properties source files to all be net.properties
>
> Build changes look good.

Thanks again Alan. Assume where there is no comment from me below that suggestions are accepted:
I will push an update based on these changes soon.

Michael.

> _Mailing list message from [Alan Bateman](mailto:Alan.Bateman at oracle.com) on
> [nio-dev](mailto:nio-dev at openjdk.java.net):_
> On 04/10/2020 14:14, Michael McMahon wrote:
> Another round of comments, this time on v14.
> 
> src/java.base/share/classes/java/net/StandardProtocolFamily.java
> - the enum constant is "UNIX" and might be better to put "Local" in
> parentheses rather than "Unix domain".
> 
> src/java.base/share/classes/java/nio/channels/package-info.java
> - L260 ends with "family only", I think "only" can be dropped.
> 
> src/java.base/share/classes/java/net/UnixDomainSocketAddress.java
> - left over "fix message" comments in constructor
> - a few formatting nits in the equals method due to a spurious space in
> the expression at L192, and missing a space at L194.
> 

I don't see a missing space at L194 ?

> src/java.base/share/classes/sun/net/util/SocketExceptions.java
> - Can of(IOException e, SocketAddress addr) check enhancedExceptionText
> to avoid the ugly check in the ofXXX methods?
> - Can you explain the inconsistency in the null handling for the address
> types, maybe a left over from an early prototype?
> 

The null check was always there for Inet sockets. It is not required for Unix
but would be benign. So, the check can be promoted to the calling method.

> src/java.base/share/classes/sun/nio/ch/ServerSocketChannelImpl.java
> src/java.base/share/classes/sun/nio/ch/SocketChannelImpl.java
> - I think we need to change the class descriptions of both to start with
> "Base implementations ..."
> - We need to find a clean way to push the socket() method down to the
> InetXXXImpl classes as they are the only classes that should know about
> the socket adaptors.

Only way to do this is to define yet another implXXX method (implSocket)
but I think it is worthwhile as neither the field nor the implementation
belong in the super class

> 
> src/java.base/share/classes/sun/nio/ch/UnixDomainServerSocketChannelImpl.java
> - implBind should not loop/retry when a local address is provided

It actually catches the BindException and rethrows it when 'local != null, but maybe
the comment above the loop is confusing. I will reword it.

> - what behavior is expected when getTempDir returns null?

I was assuming that ${java.io.tmpdir} would always be defined, but I see
getTempDir() could be more robust in dealing with errors in the preceding
search steps. So, in the unlikely event that ${java.io.tmpdir} is not defined
null would be returned. I will change to throw a BindException in that case.

> - Why doesn't this code use SecureRandom, as is done in the Windows
> Selector implementation.

It does use SecureRandom but only uses the Random api.

> - Can supportedOptions be changed to return
> Set.of(StandardSocketOptions.SO_RCVBUF)?

I can simplify that code definitely, but I think for consistency it should
still return a static unmodifiable instance

> - toString has a left over "TODO".
> - The message for the IOException in implBind should start with a
> capital to be consistent with the other exceptions thrown in this area
> 
> src/java.base/share/classes/sun/nio/ch/UnixDomainSockets.java
> - The initializer sets the system property
> "jdk.nio.channels.unixdomain.maxnamelength". Looks like it's to help the
> tests so need to find another solution for the tests.

Okay, the tests didn't really need this anyway

> - checkCapability should be renamed to checkPermission as it does a
> security manager check. Would it more be consistent with existing code
> if changed to "if (sm != null) sm.checkPermission(...)"
> - Can inTempDirectory be removed as it doesn't seem to be used and
> raises several questions if it is needed.
> - getTempName should use the path separator rather than "/".? Also I
> don't think "nio" should be in the name.
> - Can the init method be removed, may be a left over from a previous
> iteration.
> - The left breaks in the initialization of UNNAMED and support seem
> unnecessary, maybe they were very long in previous iterations?
> - Several methods are public, is that intentional, or maybe a left over?
> 
> src/java.base/unix/native/libnio/ch/UnixDomainSockets.c
> => Is the intention to put the NET_ functions into libnet or libnio? The
> function prototypes are declared in net_util.h but the functions have
> been compiled in libnio.
> 

They were probably in libnet originally, but makes more sense to be
in libnio. So, I will move the function prototypes to nio_util.h and rename
them to remove the NET_ prefix.

> src/java.base/share/classes/sun/nio/ch/Net.java
> - spurious blank line, probably left over from a previous iteration.
> 
> src/java.base/unix/classes/sun/nio/fs/UnixFileSystemProvider.java
> src/java.base/windows/classes/sun/nio/fs/WindowsFileSystemProvider.java
> - getSunPathForSocketFile should not accept null, let
> to{Unix,Windows}Path handle it
> 
> src/java.base/windows/classes/sun/nio/ch/PipeImpl.java
> src/java.base/windows/classes/sun/nio/ch/SinkChannelImpl.java
> src/java.base/windows/classes/sun/nio/ch/WindowsSelectorImpl.java
> - The changes to PipeImpl look like they will set TCP_NODELAY for users
> of the Pipe API on older Windows releases. I think I would prefer to see
> a parameter on the PipeImpl constructor to indicate if there should
> buffered/nodelay or not. That way it will be clearer for the two usages
> of PipeImpl.

Right, good point.

> - The volatile noUnixDomainSockets does not need to be initialized to false.
> 
> src/jdk.net/share/classes/jdk/net/UnixDomainPrincipal.java
> - if records are finalized in Java 16 then this may be a candidate to be
> a record
> 

Right. I don't think there is anything we can do further we can do right now
on this point, but if records make it, then it would be a simple API change to make.

> test/jdk/java/nio/channels/etc/ProtocolFamilies.java
> - minor nit but the existing test uses "ssc", "sc", and "dc" so best to
> keep it consistent if you can.
> 
> test/jdk/jdk/nio/Basic.java
> - can you change this to use
> Class.forName("sun.nio.ch.InetSocketChannelImpl"), that should be
> cleaner and void the retry and introducing getFD1.
> 

Good idea, but needs to be "sun.nio.ch.SocketChannelImpl" I think

> I'm still working through the changes to the InheritedChannel
> implementation and all the changes/additions of tests so more comments
> soon on that aspect of the patch.
> 
> -Alan.

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

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

From cstein at openjdk.java.net  Mon Oct  5 15:49:55 2020
From: cstein at openjdk.java.net (Christian Stein)
Date: Mon, 5 Oct 2020 15:49:55 GMT
Subject: RFR: 8253761: Wrong URI syntax printed by jar --describe-module
 [v4]
In-Reply-To: <GoJ43lbyj8ktcJfP8vpa6J3LK2_nFCyo4eFwJfPSFcY=.50f190e3-f244-43e8-95be-9377417d9c9b@github.com>
References: <GoJ43lbyj8ktcJfP8vpa6J3LK2_nFCyo4eFwJfPSFcY=.50f190e3-f244-43e8-95be-9377417d9c9b@github.com>
Message-ID: <YRMakgLfJNkEZDr9fFtQJFUG5aTPxfBLwG3Y8MVF4-I=.a5d9b257-5c3e-43b6-ac1d-d4fe9eea79d7@github.com>

> This commit replaces `"/!"` with `"!/"` in order to generate
> valid URIs when printing a module description of a modular
> JAR file. A valid URI is described here: [1]
> 
> https://bugs.openjdk.java.net/browse/JDK-8253761
> 
> [1] https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/net/JarURLConnection.html

Christian Stein 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:

  8253761: Fix URI syntax of jar --describe-module

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/393/files
  - new: https://git.openjdk.java.net/jdk/pull/393/files/b8ead33a..49ee4d2b

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

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

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

From mdoerr at openjdk.java.net  Mon Oct  5 15:55:40 2020
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Mon, 5 Oct 2020 15:55:40 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
In-Reply-To: <he1sdFygQNDTv03lTN6u5wQXvtUjim_2NLcG3nnnBz4=.c9869632-e2eb-4851-8b24-47cf60cbc464@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <FXyd9RkZbpfeKA5u6TbKbVpdBb104NV3Rv82Cc6uS8Q=.24926cff-3b94-47ab-a6c9-e82afc132a0c@github.com>
 <l2ppFeoFNQ7kC32YLjHoJCFMM2-uHaLn1A6GOM2Tk_c=.a957060e-d63b-4189-b722-206fcf755950@github.com>
 <fApRZ6p-C8wjyeYrq9ppoVyVsbA8ucNtS_vMnBBCNYo=.65d29ece-36c0-4fac-a48f-f4e08feb3ba3@github.com>
 <zibkjfdlG7QrBw18sEO6h3oEjvccEYHF1TtrKjk0J0Y=.e7f40f86-b8b4-4c23-a168-50214bebb96c@github.com>
 <3zdj-jaGgS6_W7mNPSnlZr6JECPKSybWxR1-yy5bZ8Q=.90bff33b-0da1-49cf-9833-ee08caf55c6f@github.com>
 <he1sdFygQNDTv03lTN6u5wQXvtUjim_2NLcG3nnnBz4=.c9869632-e2eb-4851-8b24-47cf60cbc464@github.com>
Message-ID: <7fS4cztWp4ebESEXcO7lrRepZZSye1KBoQGOyYvUwfM=.df0e2d21-7867-431c-89b9-dcf0ab001640@github.com>

On Wed, 30 Sep 2020 19:16:58 GMT, CoreyAshford <github.com+51754783+CoreyAshford at openjdk.org> wrote:

>>> Did you try on x86? AOT is not supported on PPC64.
>> 
>> I didn't.  No wonder.  Thank you!
>
>> Did you try on x86? AOT is not supported on PPC64.
> 
> After looking at this a bit, I find that there seems to be an assumption in the code that if there is an intrinsic
> symbol defined in aotCodeHeap.cpp using the SET_AOT_GLOBAL_SYMBOL_VALUE macro, it is required that the intrinsic is
> implemented for every arch that implements AOT.  In this case, there isn't an implementation for x86_64 (yet), so
> that's why the failure is occurring.  I was tempted to put in an arch-specific #if for ppc arch only, but I don't see
> any arch-specific code in this area, and it doesn't make sense either because AOT isn't supported on ppc at all.
> Another alternative is to remove the SET_AOT_GLOBAL_SYMBOL_VALUE for decodeBlock, since the implementation is not
> defined (yet) for any arch which supports AOT.  A third alternative would be to leave the macro call in, but comment it
> out, saying to uncomment it when it's supported on all AOT-capable arches.  Any thoughts?

Nobody replied, so I suggest to leave aotCodeHeap.cpp as it was. AOT folks can add it when they need it.

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

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

From cstein at openjdk.java.net  Mon Oct  5 15:56:41 2020
From: cstein at openjdk.java.net (Christian Stein)
Date: Mon, 5 Oct 2020 15:56:41 GMT
Subject: RFR: 8253761: Wrong URI syntax printed by jar --describe-module
In-Reply-To: <5NjPvAfeD450cyljZArqpKV8JnmOfBhmcZOiDTdHJA4=.03347315-5968-459e-b0e2-670bd3a7df9c@github.com>
References: <GoJ43lbyj8ktcJfP8vpa6J3LK2_nFCyo4eFwJfPSFcY=.50f190e3-f244-43e8-95be-9377417d9c9b@github.com>
 <KX2hm__Fl4-b1qiK2FOHEYcmt4xNoMfZiZpCRu1G2jY=.457dfb03-27c0-41bc-850b-c1540e15f712@github.com>
 <WpA1zwswZsUK3UpcmF011Lja4yNoaZrWcAbJUjG3yn4=.c62c2842-58db-49ff-af82-eb1cfb2577e2@github.com>
 <-1XHmzbRjoSG_fSaIWdhIUPuF8ZEcz8VmG-iWZ8NoQw=.92ae1a1f-fd51-431b-bcde-ca01d603aa04@github.com>
 <g2xPz8RM-0RV6pO74DD3_i0WekIu42Ub9I8aHuyWdg4=.504094c5-926d-4065-adfa-e885f360a463@github.com>
 <en7lwN3njdMt7yY8fRCoHWoPHPNYXd-XQgHkVRgEkJU=.713f04d3-60f2-45ee-8538-5593b680a389@github.com>
 <93yWBvJNiKenvcgmOYASLyruoMYcsYILHJ9ccBXR-HE=.a68bd529-9c5b-4129-ba3b-434d5ef70563@github.com>
 <dL1TskN-_-kC5T6ZEfU1kSuIqLOSEhE_JXtoHbC0fxA=.fc3c9cc4-3bd9-48ec-b9e8-5d988658486d@github.com>
 <Bp45DgSbJYnjN_A7JdwhVFYgfAx45ZFewpOD330hrNo=.2b1a33d9-c729-4577-b3b6-1e60cb07f4b8@github.com>
 <5NjPvAfeD450cyljZArqpKV8JnmOfBhmcZOiDTdHJA4=.03347315-5968-459e-b0e2-670bd3a7df9c@github.com>
Message-ID: <OZ7-mHyJZbGsyHKEl85DeudjLA8GX-FwF-yLPlVngmc=.7ac6973b-a32a-41bd-a629-884c7308ab32@github.com>

On Mon, 5 Oct 2020 14:47:43 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> I can't find the `modularJar/Basic.java` test run in the logs. In which job/tier/part does it hide?
>> 
>>> I think the change exposes issues in a couple of tests.
>> 
>> The one that fails the linked "pre-submit test" run above is already reported as
>> https://bugs.openjdk.java.net/browse/JDK-8249095 ("Aux.java" is not a valid file name on Windows).
>>> It looks like partialUpdateFooModuleInfo (modularJar/Basic.java) expects the wrong result, as does some of the tests in
>>> mmrjar/Basic.java.
>> 
>> Something for a follow-up issue/PR?
>
> The tests are test/jdk/tools/jar/modularJar/Basic.java and test/jdk/tools/jar/mmrjar/Basic.java. I've verified that
> they will fail with the update to the jar tool so we'll need to change this as part of this PR.
> The tests are in the core_tools test group, which seems to be tier2. I suspect the pre-submit job is running tier1.

I replaced all occurances of `"/!"` with the correct `"!/"` delimiter in both test files.

Hoping that I touched every failing assertion, as I am still struggling to set up a working JDK build environment
locally. On Windows...

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

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

From github.com+51754783+coreyashford at openjdk.java.net  Mon Oct  5 16:11:41 2020
From: github.com+51754783+coreyashford at openjdk.java.net (CoreyAshford)
Date: Mon, 5 Oct 2020 16:11:41 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
In-Reply-To: <7fS4cztWp4ebESEXcO7lrRepZZSye1KBoQGOyYvUwfM=.df0e2d21-7867-431c-89b9-dcf0ab001640@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <FXyd9RkZbpfeKA5u6TbKbVpdBb104NV3Rv82Cc6uS8Q=.24926cff-3b94-47ab-a6c9-e82afc132a0c@github.com>
 <l2ppFeoFNQ7kC32YLjHoJCFMM2-uHaLn1A6GOM2Tk_c=.a957060e-d63b-4189-b722-206fcf755950@github.com>
 <fApRZ6p-C8wjyeYrq9ppoVyVsbA8ucNtS_vMnBBCNYo=.65d29ece-36c0-4fac-a48f-f4e08feb3ba3@github.com>
 <zibkjfdlG7QrBw18sEO6h3oEjvccEYHF1TtrKjk0J0Y=.e7f40f86-b8b4-4c23-a168-50214bebb96c@github.com>
 <3zdj-jaGgS6_W7mNPSnlZr6JECPKSybWxR1-yy5bZ8Q=.90bff33b-0da1-49cf-9833-ee08caf55c6f@github.com>
 <he1sdFygQNDTv03lTN6u5wQXvtUjim_2NLcG3nnnBz4=.c9869632-e2eb-4851-8b24-47cf60cbc464@github.com>
 <7fS4cztWp4ebESEXcO7lrRepZZSye1KBoQGOyYvUwfM=.df0e2d21-7867-431c-89b9-dcf0ab001640@github.com>
Message-ID: <y5IrWAdwvO19UfV70N8ntGwn4o5UYzL5bASq9xxEJgA=.06b323eb-4b72-43f3-9bc4-60c5b065a8a9@github.com>

On Mon, 5 Oct 2020 15:53:26 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Nobody replied, so I suggest to leave aotCodeHeap.cpp as it was. AOT folks can add it when they need it.

Ok, I will drop that change from that PR.  Thank you.

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

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

From minqi at openjdk.java.net  Mon Oct  5 16:42:52 2020
From: minqi at openjdk.java.net (Yumin Qi)
Date: Mon, 5 Oct 2020 16:42:52 GMT
Subject: RFR: 8247536: Support for pre-generated java.lang.invoke classes
 in CDS static archive [v8]
In-Reply-To: <Y_Bas-poGnDtvcJbqbmeIAPQRNxzvarBToQWALn9TTE=.e846cd3c-0e7b-48d3-8ffa-be3c03acffb0@github.com>
References: <Y_Bas-poGnDtvcJbqbmeIAPQRNxzvarBToQWALn9TTE=.e846cd3c-0e7b-48d3-8ffa-be3c03acffb0@github.com>
Message-ID: <-7yd4KLXoqQqOIaMdI0m_6GxtCoo0LWHFBBPWvv2sBA=.30020f59-27f6-4cb1-ab22-13ed3355fc31@github.com>

> This patch is reorganized after 8252725, which is separated from this patch to refactor jlink glugin code. The previous
> webrev with hg can be found at: http://cr.openjdk.java.net/~minqi/2020/8247536/webrev-05. With 8252725 integrated, the
> regeneration of holder classes is simply to call the new added GenerateJLIClassesHelper.cdsGenerateHolderClasses
> function.  Tests: tier1-4

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

  Move the check work to java, restore code in VM. Modified test code according to the changes. The invoke name
  verififcation is not implemented since not all the holder class are processed, not all the functions of processed
  holder classes are added. For holder class with DirectMethodHandle in its name, only the name in the
  DMH_METHOD_TYPE_MAP keyset is added, ithe line with other names just gets skipped silently. This makes the verification
  on invoke names difficul, a name not in the keyset should not fail the test. Also add a boolean to
  cdsGenerateHolderClasses to indicate call path.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/193/files
  - new: https://git.openjdk.java.net/jdk/pull/193/files/9b0f523b..125112b3

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

  Stats: 87 lines in 3 files changed: 70 ins; 10 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/193.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/193/head:pull/193

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

From iignatyev at openjdk.java.net  Mon Oct  5 16:46:55 2020
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Mon, 5 Oct 2020 16:46:55 GMT
Subject: RFR: 8253750: use build-stable default seed for
 Utils.RANDOM_GENERATOR [v2]
In-Reply-To: <NX_cAjZJPewgSzG-OEjdddnm0q8furdjLseCx9KlnXM=.9c5a6fc5-6537-47c3-9981-38659d5bbc76@github.com>
References: <RQa3EOXeDAni1G-mu_jM-I9mosypb0gnuLUmFCtGhGo=.92a4f06b-60df-49b6-b6e3-bcf11e7530ab@github.com>
 <D-CpLwXgIf54u15Yjd0XkHH9Rdakox0qUsEsoU8arxQ=.951a1d6c-6d9b-4a27-b9d5-64c9409b5633@github.com>
 <NX_cAjZJPewgSzG-OEjdddnm0q8furdjLseCx9KlnXM=.9c5a6fc5-6537-47c3-9981-38659d5bbc76@github.com>
Message-ID: <qfSAPBhmGV_nhkuACJiuDUEN_HK8_z82sP1MqkOBFiA=.d823349a-6387-4646-81ee-1fd63681b982@github.com>

On Fri, 2 Oct 2020 23:10:13 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Igor Ignatyev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   used Runtime.version() instead of ${java.vm.version}
>>   updated javadoc
>
> The code and description are reversed from what I suggested.
> 
> The seed should *only* be computed from the version information if it is a promoted or weekly build.
> All other builds should use a random seed.

Hi @RogerRiggs

I guess I have misinterpreted your sentence about system property being set (as `java.vm.version` is always set and the
only other property which mattered in this context is `jdk.test.lib.random.seed`). in any case, I agree that for
_personal_ builds, it's more desirable to have different seeds on each execution, especially given the fact that the
version string is set at configure-time and not at build-time, so one might end up with the same version string for a
very long time.

I have reworked the code a bit, so now version-based seed is used only for _promotable_ builds (i.e. ones that have
build number and it's greater than 0); local and remote/mach5 ad-hoc builds (by default) don't specify a build number,
so a random seed value will be used for them. and as before, if `jdk.test.lib.random.seed` is set, its value will be
used as seed oblivious to build type.

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

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

From iignatyev at openjdk.java.net  Mon Oct  5 16:46:55 2020
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Mon, 5 Oct 2020 16:46:55 GMT
Subject: RFR: 8253750: use build-stable default seed for
 Utils.RANDOM_GENERATOR [v3]
In-Reply-To: <RQa3EOXeDAni1G-mu_jM-I9mosypb0gnuLUmFCtGhGo=.92a4f06b-60df-49b6-b6e3-bcf11e7530ab@github.com>
References: <RQa3EOXeDAni1G-mu_jM-I9mosypb0gnuLUmFCtGhGo=.92a4f06b-60df-49b6-b6e3-bcf11e7530ab@github.com>
Message-ID: <AIFV5ZwLYCPyA9X3Ezvb0ZRUSmdAPRAnzdkTd3aaBjo=.95bd0e9e-93e9-4211-892d-43fc473fc695@github.com>

> Hi all,
> 
> could you please review the patch which updates `jdk.test.lib.Utils` to use md5 hash-sum of `java.vm.version` property
> as default seed for `Utils.RANDOM_GENERATOR`?
> from JBS:
>> using the same seed for all runs of a build will make it possible (easier) to compare results from different test runs
>> (e.g. on different platforms, w/ different flags) and consequently will make test results analysis easier. the proposed
>> solution is to use the seed based on Runtime.version() / "java.vm.version", which are different from build to build, if
>> there is no seed specified by "jdk.test.lib.random.seed" property.
> 
> the patch also updates `RandomGeneratorTest` test, so it expects now that the same values are generated if no seed is
> provided.
> testing: ? tier1

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

  use random seed for personal/internal builds

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/391/files
  - new: https://git.openjdk.java.net/jdk/pull/391/files/381e14f7..07d85a20

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

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

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

From smarks at openjdk.java.net  Mon Oct  5 17:03:48 2020
From: smarks at openjdk.java.net (Stuart Marks)
Date: Mon, 5 Oct 2020 17:03:48 GMT
Subject: Integrated: 8156071: List.of: reduce array copying during creation
In-Reply-To: <-pkG69_yCpZxK0LBMz3Dw_m2VkTK6BhhWBY02UkidfQ=.c1f424e8-5716-4858-aaa0-488a9e553107@github.com>
References: <-pkG69_yCpZxK0LBMz3Dw_m2VkTK6BhhWBY02UkidfQ=.c1f424e8-5716-4858-aaa0-488a9e553107@github.com>
Message-ID: <zo9tujHtFHPOSMQKty_OiKlFgjmgIzQNCHdi_91Wzpk=.711249cf-dd9c-4e6a-9e27-588ee75f1f9b@github.com>

On Thu, 1 Oct 2020 00:13:28 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> Plumb new internal static factory method to trust the array passed in, avoiding unnecessary copying. JMH results for
> the benchmark show about 15% improvement for the cases that were optimized, namely the 3 to 10 fixed arg cases.
> # VM options: -verbose:gc -XX:+UseParallelGC -Xms4g -Xmx4g --enable-preview -verbose:gc -XX:+UsePara
> llelGC -Xms4g -Xmx4g -Xint
> # Warmup: 5 iterations, 1 s each
> # Measurement: 5 iterations, 2 s each
> 
> WITHOUT varargs optimization:
> 
> Benchmark         Mode  Cnt     Score     Error   Units
> ListArgs.list00  thrpt   15  6019.539 ? 144.040  ops/ms
> ListArgs.list01  thrpt   15  1985.009 ?  40.606  ops/ms
> ListArgs.list02  thrpt   15  1854.812 ?  17.488  ops/ms
> ListArgs.list03  thrpt   15   963.866 ?  10.262  ops/ms
> ListArgs.list04  thrpt   15   908.116 ?   6.278  ops/ms
> ListArgs.list05  thrpt   15   848.607 ?  16.701  ops/ms
> ListArgs.list06  thrpt   15   822.282 ?   8.905  ops/ms
> ListArgs.list07  thrpt   15   780.057 ?  11.214  ops/ms
> ListArgs.list08  thrpt   15   745.295 ?  19.204  ops/ms
> ListArgs.list09  thrpt   15   704.596 ?  14.003  ops/ms
> ListArgs.list10  thrpt   15   696.436 ?   4.914  ops/ms
> ListArgs.list11  thrpt   15   661.908 ?  11.041  ops/ms
> 
> WITH varargs optimization:
> 
> Benchmark         Mode  Cnt     Score    Error   Units
> ListArgs.list00  thrpt   15  6172.298 ? 62.736  ops/ms
> ListArgs.list01  thrpt   15  1987.724 ? 45.468  ops/ms
> ListArgs.list02  thrpt   15  1843.419 ? 10.693  ops/ms
> ListArgs.list03  thrpt   15  1126.946 ? 30.952  ops/ms
> ListArgs.list04  thrpt   15  1050.440 ? 17.859  ops/ms
> ListArgs.list05  thrpt   15   999.275 ? 23.656  ops/ms
> ListArgs.list06  thrpt   15   948.844 ? 19.615  ops/ms
> ListArgs.list07  thrpt   15   897.541 ? 15.531  ops/ms
> ListArgs.list08  thrpt   15   853.359 ? 18.755  ops/ms
> ListArgs.list09  thrpt   15   826.394 ?  8.284  ops/ms
> ListArgs.list10  thrpt   15   779.231 ?  4.104  ops/ms
> ListArgs.list11  thrpt   15   650.888 ?  3.948  ops/ms

This pull request has now been integrated.

Changeset: 88d75c9a
Author:    Stuart Marks <smarks at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/88d75c9a
Stats:     203 lines in 6 files changed: 185 ins; 0 del; 18 mod

8156071: List.of: reduce array copying during creation

Reviewed-by: psandoz, redestad

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

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

From alanb at openjdk.java.net  Mon Oct  5 17:04:42 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 5 Oct 2020 17:04:42 GMT
Subject: RFR: 8253761: Wrong URI syntax printed by jar --describe-module
 [v4]
In-Reply-To: <YRMakgLfJNkEZDr9fFtQJFUG5aTPxfBLwG3Y8MVF4-I=.a5d9b257-5c3e-43b6-ac1d-d4fe9eea79d7@github.com>
References: <GoJ43lbyj8ktcJfP8vpa6J3LK2_nFCyo4eFwJfPSFcY=.50f190e3-f244-43e8-95be-9377417d9c9b@github.com>
 <YRMakgLfJNkEZDr9fFtQJFUG5aTPxfBLwG3Y8MVF4-I=.a5d9b257-5c3e-43b6-ac1d-d4fe9eea79d7@github.com>
Message-ID: <zAr6-kJ_0o4bMn37RTDo6sA8QD6Z9BbIyyvqblydrzc=.8e945f0e-a756-48cf-bed8-3aeedbe13cfe@github.com>

On Mon, 5 Oct 2020 15:49:55 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> This commit replaces `"/!"` with `"!/"` in order to generate
>> valid URIs when printing a module description of a modular
>> JAR file. A valid URI is described here: [1]
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8253761
>> 
>> [1] https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/net/JarURLConnection.html
>
> Christian Stein 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 alanb (Reviewer).

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

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

From Alan.Bateman at oracle.com  Mon Oct  5 18:13:19 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 5 Oct 2020 19:13:19 +0100
Subject: Request for Discussion: 8253952: Work around wrong usage of
 ZipOutputStream.putNextEntry() in user code
In-Reply-To: <CA+3eh10vr3vs92UPu7PwiaofZpf46QuzsuFf4bvf26gbYKF3-g@mail.gmail.com>
References: <CA+3eh12_-fNxf_KFK68WEqVoD_n6CD7RCbe=LoKCyCeUQ3w0oQ@mail.gmail.com>
 <4658d3a6-3360-fb84-e5ff-20dc6cc61b92@oracle.com>
 <CA+3eh10vr3vs92UPu7PwiaofZpf46QuzsuFf4bvf26gbYKF3-g@mail.gmail.com>
Message-ID: <99e80b7e-7702-338d-cd92-c9d1a396dfa5@oracle.com>

On 05/10/2020 11:04, Volker Simonis wrote:
> :
>> I don't
>> think the proposal to add a system property to change the behavior is
>> feasible, at least not without changing the spec but even then it would
>> be very icky.
> Why do you think so? The answer to this question is especially
> important to me because we are considering doing this in our internal
> version independently of upstream OpenJKD (and potentially also in 8 &
> 11).
Introducing system properties to change the behavior of APIs and "fix" 
existing code is really icky. For the main line, then I think it would 
be good to explore the impact of changing the existing putNextEntry or 
introducing a new API. The compatibility impact of the former may not be 
significant but I would expect the spec would be clarified as part of 
this (that is what I was trying to say above). Exploring new APIs would 
be good and a method on ZipEntry may not be too bad (you have a 
reference to the target ZOS in the implementation).

> :
>
> And just as a side note, we also use the "jdk.util.zip.inhibitZip64"
> property in ZipOutputStream for a similar reason. I just wonder how
> that could pass the CCC process as I couldn't even find any
> documentation for it :)
ZIP64 was very problematic at the time as it wasn't supported by several 
tools. The system property was introduced to disable the feature/support 
so that Java applications didn't create ZIP files that other tools 
couldn't consume. It would be good to get an up to date picture on ZIP64 
support as it might be that this switch can be removed. It pre-dates the 
CSR? process but there was a CCC at the time.

-Alan

From cstein at openjdk.java.net  Mon Oct  5 18:19:47 2020
From: cstein at openjdk.java.net (Christian Stein)
Date: Mon, 5 Oct 2020 18:19:47 GMT
Subject: Integrated: 8253761: Wrong URI syntax printed by jar --describe-module
In-Reply-To: <GoJ43lbyj8ktcJfP8vpa6J3LK2_nFCyo4eFwJfPSFcY=.50f190e3-f244-43e8-95be-9377417d9c9b@github.com>
References: <GoJ43lbyj8ktcJfP8vpa6J3LK2_nFCyo4eFwJfPSFcY=.50f190e3-f244-43e8-95be-9377417d9c9b@github.com>
Message-ID: <MspDdRK28CJINiXknh5RosSMFnZodmVqcG6cqSmy70E=.9fc09364-ccef-4cfb-a65b-1b5c784bd0e8@github.com>

On Tue, 29 Sep 2020 05:38:18 GMT, Christian Stein <cstein at openjdk.org> wrote:

> This commit replaces `"/!"` with `"!/"` in order to generate
> valid URIs when printing a module description of a modular
> JAR file. A valid URI is described here: [1]
> 
> https://bugs.openjdk.java.net/browse/JDK-8253761
> 
> [1] https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/net/JarURLConnection.html

This pull request has now been integrated.

Changeset: f2f77f7b
Author:    Christian Stein <cstein at openjdk.org>
Committer: Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f2f77f7b
Stats:     12 lines in 3 files changed: 4 ins; 0 del; 8 mod

8253761: Wrong URI syntax printed by jar --describe-module

Reviewed-by: alanb

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

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

From github.com+51754783+coreyashford at openjdk.java.net  Mon Oct  5 18:29:58 2020
From: github.com+51754783+coreyashford at openjdk.java.net (CoreyAshford)
Date: Mon, 5 Oct 2020 18:29:58 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v2]
In-Reply-To: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
Message-ID: <6P-wrlA7c9wlXEhcoAYW5J9W2jwTmTTj3PkDObPh0LA=.c11aa048-8853-4e1c-a689-c34b89c15f12@github.com>

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

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

 - AOT: Revert change to aotCodeHeap.cpp for decodeBlock
   
   Don't add the SET_AOT_GLOBAL_SYMBOL_VALUE macro for decode block until all
   arches that implement AOT, implement the decodeBlock intrinsic.
 - Base64.java decodeBlock: Changes from PR review
   
    * Make comparison safer and consistent with the while loop
    * Update comment about the decodeBlock intrinsic so that it matches the new structure
    * Add comment about the lack of a length check on the destination buffer
    * As per issue 8138732, change HotSpotIntrinsicCandidate to IntrinsicCandidate
 - stubGenerator_ppc.cpp: Changes from PR review
   
    * Fix clearing of upper bits to clear 32 bits instead of 31 (due to misreading of clrldi instruction)
    * change and document loop_unrolls setting from 8 to 2 after re-running the benchmark
    * align unrolled loop on a 32-byte boundary
    * replace instruction used for checking isURL from a double word to single
      word instruction since the register is effectively 32 bits wide
    * cosmetic change to realign register comments.
 - TestBase64.java: Changes from PR review
   
    * Use Utils.toByteArrays() method instead of a locally-defined method
    * Generate the two non-Base64 tables dynamically rather than use static initialization
    * Added comments describing the two above-mentioned arrays
 - Expand the Base64 intrinsic regression test to cover decodeBlock
   
   This patch makes four significant changes:
   
   1) The Power implementation of the decodeBlock intrinsic, at least,
   requires a decode length of at least 128 bytes, but the existing test cases
   are much shorter, maxing out at 111 bytes.  So the patch adds a new input
   data file which has longer test cases in it.
   
   2) The original test cases only covers the encoding of just the printable
   subset of the 7-bit ASCII characters.  However, Base64 encoding requires
   being able to encode arbitrary binary data, i.e. it must handle all 256
   8-bit byte encodings.  To remedy this, but keep the original line-oriented
   style of the input data, I added another input file type that uses a simple
   ASCII hexadecimal encoding - two ASCII hex characters per 8-bit byte.  When
   test0 is called, a new parameter is passed that specifies the type of the
   input file, which is either the original ASCII type or the hexadecimal
   format.  So to test both longer input data and arbitrary 8-bit data, the
   newly added input test file has test cases which are both longer and
   encoded in ASCII hex so as to give full 8-bit capability.  When reading
   this type of file, test0 calls a newly-added function to translate the
   ASCII hex to binary data.  Except for the first line of input data, which
   contains all possible 8-bit values sequentially, the input data was
   generated using a random length (between 111 and 520 bytes) buffer filled
   with random 8-bit data, which should give adequate coverage.
   
   3) The original test did not test that the decoder detects illegal Base64
   bytes.  This change chooses a random location in the encoded data to
   corrupt with a randomly-chosen byte which is illegal for the specific
   Base64 encoding that is chosen (i.e. standard or URLsafe).  It then calls
   the decode function to verify that the illegal byte is detected and the
   proper exception is thrown.
   
   4) The test iteration count was originally 100K, but that is far more than
   enough iterations to test the intrinsic.  It takes 20K iterations on each
   instrinsic for HotSpot C2 to begin calling it.  The test originally had
   three types of encodings to test and called the encode intrinsic four times
   for each iteration, which works out to 100K * 3 * 4 = 1.2M calls just to
   encode.  Decode was called four times as well (now five because of the
   illegal byte test).  I believe this is excessive and with the extra test
   data I have added, the test was timing out after ten minutes of execution.
   It appears that it is timing out, not because the intrinsics take a long
   time to run, but because test0 generates an enormous number of discarded
   data buffers for the GC system to recover (the test runs at about 39GB of
   virtual memory on my test machine).  To remedy the timeout problem, I have
   changed the code so that a warmup function of 20K repetitions is performed
   on a fixed buffer, to activate the instrinsic(s).  After the warmup, I have
   reduced the number of iterations to 5K on each test0 call.  This should
   give adequate coverage.
 - Add JMH benchmark for Base64 variable length buffer decoding
 - Add Power9+ intrinsic implementation for Base64 decoding
 - Add HotSpot code to implement Base64 decodeBlock API
 - Add HotSpotIntrinsicCandidate and API for Base64 decoding

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

Changes: https://git.openjdk.java.net/jdk/pull/293/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=293&range=01
  Stats: 1873 lines in 23 files changed: 1846 ins; 4 del; 23 mod
  Patch: https://git.openjdk.java.net/jdk/pull/293.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/293/head:pull/293

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

From github.com+51754783+coreyashford at openjdk.java.net  Mon Oct  5 18:29:59 2020
From: github.com+51754783+coreyashford at openjdk.java.net (CoreyAshford)
Date: Mon, 5 Oct 2020 18:29:59 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v2]
In-Reply-To: <y5IrWAdwvO19UfV70N8ntGwn4o5UYzL5bASq9xxEJgA=.06b323eb-4b72-43f3-9bc4-60c5b065a8a9@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <FXyd9RkZbpfeKA5u6TbKbVpdBb104NV3Rv82Cc6uS8Q=.24926cff-3b94-47ab-a6c9-e82afc132a0c@github.com>
 <l2ppFeoFNQ7kC32YLjHoJCFMM2-uHaLn1A6GOM2Tk_c=.a957060e-d63b-4189-b722-206fcf755950@github.com>
 <fApRZ6p-C8wjyeYrq9ppoVyVsbA8ucNtS_vMnBBCNYo=.65d29ece-36c0-4fac-a48f-f4e08feb3ba3@github.com>
 <zibkjfdlG7QrBw18sEO6h3oEjvccEYHF1TtrKjk0J0Y=.e7f40f86-b8b4-4c23-a168-50214bebb96c@github.com>
 <3zdj-jaGgS6_W7mNPSnlZr6JECPKSybWxR1-yy5bZ8Q=.90bff33b-0da1-49cf-9833-ee08caf55c6f@github.com>
 <he1sdFygQNDTv03lTN6u5wQXvtUjim_2NLcG3nnnBz4=.c9869632-e2eb-4851-8b24-47cf60cbc464@github.com>
 <7fS4cztWp4ebESEXcO7lrRepZZSye1KBoQGOyYvUwfM=.df0e2d21-7867-431c-89b9-dcf0ab001640@github.com>
 <y5IrWAdwvO19UfV70N8ntGwn4o5UYzL5bASq9xxEJgA=.06b323eb-4b72-43f3-9bc4-60c5b065a8a9@github.com>
Message-ID: <CG5i7Se1JWV9BoYKSev-u5-nl0aorK6d55_TiOmPFbo=.de790efa-3c1e-4fa8-96e4-6da70fe37d58@github.com>

On Mon, 5 Oct 2020 16:08:55 GMT, CoreyAshford <github.com+51754783+CoreyAshford at openjdk.org> wrote:

>> Nobody replied, so I suggest to leave aotCodeHeap.cpp as it was. AOT folks can add it when they need it.
>
>> Nobody replied, so I suggest to leave aotCodeHeap.cpp as it was. AOT folks can add it when they need it.
> 
> Ok, I will drop that change from that PR.  Thank you.

I have rebased this PR and made the requested changes.   The force push is only because of the rebase; I have preserved
the commit history.

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

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

From asemenyuk at openjdk.java.net  Mon Oct  5 18:43:47 2020
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Mon, 5 Oct 2020 18:43:47 GMT
Subject: RFR: 8253426: jpackage is unable to generate working EXE for
 add-launcher =?UTF-8?B?4oCm?= [v3]
In-Reply-To: <Xfjo4fNUnqBkODXtufT4SCfLWd5nwjo_RzxiD3DPV4c=.016ab1da-916a-4013-8e7e-f61c04fb7fca@github.com>
References: <fJZt2_5woAa0onUFhNsIJoD0lVbVZQGIIbf0VN_VnpY=.aa7588ae-b25d-4869-8c05-523242dedf2f@github.com>
 <Xfjo4fNUnqBkODXtufT4SCfLWd5nwjo_RzxiD3DPV4c=.016ab1da-916a-4013-8e7e-f61c04fb7fca@github.com>
Message-ID: <GHZ_0CWYM0vr9hX0zIYGiC--blsLVmqYShGL5Z91-U4=.7427323d-fe61-46c6-b56a-691ad2d11ebb@github.com>

On Fri, 25 Sep 2020 21:05:23 GMT, Andy Herrick <herrick at openjdk.org> wrote:

>> 8253426: jpackage is unable to generate working EXE for add-launcher configurations.
>> secondary launchers ignored module, main-jar, and main-class in launcher properties file because  the LAUNCHER_DATA
>> param was not removed from the set of params for each new add-module. testcase added in AddLauncherTest,java
>
> Andy Herrick has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8253426: jpackage is unable to generate working EXE for add-launcher configurations

Marked as reviewed by asemenyuk (Committer).

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

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

From igraves at openjdk.java.net  Mon Oct  5 18:57:52 2020
From: igraves at openjdk.java.net (Ian Graves)
Date: Mon, 5 Oct 2020 18:57:52 GMT
Subject: RFR: 8204256: improve jlink error message to report unsupported
 class file format [v3]
In-Reply-To: <fc0WYkvegw3_1RBfXVVy7Vs6HcX7b9UIq7fZ2kK4cCY=.218de7d9-7abf-4eec-af30-d2926464349c@github.com>
References: <fc0WYkvegw3_1RBfXVVy7Vs6HcX7b9UIq7fZ2kK4cCY=.218de7d9-7abf-4eec-af30-d2926464349c@github.com>
Message-ID: <q89EY996pciPx8Gt5AkuwwfHB4xe8Q7Dov2Vws6hj3U=.06e51550-1090-43ee-ac4f-de1ac041e7e9@github.com>

> This pull request contains a change to facilitate better error messages in jlink for when jlink creates an image from
> jmod files that are unsupported by the runtime by being _too new_. The existing behavior supports modules that are too
> old via an error about a mismatched version.  The solution to this problem is constrained by jlink's use of some
> specified behavior by java.lang.module.ModuleFinder. The solution in this PR is to subclass some existing exceptions
> internally as to signal to jlink more specific error conditions when attempting to find and open modules.  Bug here:
> https://bugs.openjdk.java.net/browse/JDK-8204256
> New Error message example:
> 
>  reading module: /Users/igraves/dev/jdk-otro/build/macosx-x64/images/jmods/java.security.sasl.jmod
> java.lang.module.FindException: Error reading module:
> /Users/igraves/dev/jdk-otro/build/macosx-x64/images/jmods/java.security.sasl.jmod 	at
> java.base/jdk.internal.module.ModulePath.readModule(ModulePath.java:350) 	at
> java.base/jdk.internal.module.ModulePath.scanDirectory(ModulePath.java:284) 	at
> java.base/jdk.internal.module.ModulePath.scan(ModulePath.java:232) 	at
> java.base/jdk.internal.module.ModulePath.scanNextEntry(ModulePath.java:190) 	at
> java.base/jdk.internal.module.ModulePath.find(ModulePath.java:154) 	at
> jdk.jlink/jdk.tools.jlink.internal.JlinkTask.newModuleFinder(JlinkTask.java:443) 	at
> jdk.jlink/jdk.tools.jlink.internal.JlinkTask.initJlinkConfig(JlinkTask.java:374) 	at
> jdk.jlink/jdk.tools.jlink.internal.JlinkTask.run(JlinkTask.java:267) 	at
> jdk.jlink/jdk.tools.jlink.internal.Main.run(Main.java:54) 	at jdk.jlink/jdk.tools.jlink.internal.Main.main(Main.java:33)
> Caused by: java.lang.module.InvalidModuleDescriptorException: Unsupported major.minor version 60.0
> 	at java.base/jdk.internal.module.ModuleInfo.invalidModuleDescriptor(ModuleInfo.java:1088)
> 	at java.base/jdk.internal.module.ModuleInfo.doRead(ModuleInfo.java:192)
> 	at java.base/jdk.internal.module.ModuleInfo.read(ModuleInfo.java:129)
> 	at java.base/jdk.internal.module.ModulePath.readJMod(ModulePath.java:395)
> 	at java.base/jdk.internal.module.ModulePath.readModule(ModulePath.java:343)
> 	... 9 more```

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

  Fixing formatting

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/409/files
  - new: https://git.openjdk.java.net/jdk/pull/409/files/bee11534..835e2902

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

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

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

From igraves at openjdk.java.net  Mon Oct  5 18:57:52 2020
From: igraves at openjdk.java.net (Ian Graves)
Date: Mon, 5 Oct 2020 18:57:52 GMT
Subject: RFR: 8204256: improve jlink error message to report unsupported
 class file format [v2]
In-Reply-To: <ABfr9TlMBFwU3SYHsjHAJbqwOCOLbnyzsIGOSZAYlvE=.01d36959-3220-4685-86c7-eb56505627e7@github.com>
References: <fc0WYkvegw3_1RBfXVVy7Vs6HcX7b9UIq7fZ2kK4cCY=.218de7d9-7abf-4eec-af30-d2926464349c@github.com>
 <qGVlFtUbSi5Uo7ZVOhgIFjaBYjpD-5yo7_nPWOcbWQA=.81eefc43-09be-4c89-a018-d0de0f9d1292@github.com>
 <UOeX1EtrXyzdkhFeBx-prDjTGZwWh1my4NSODNZQwYg=.ef69bb7d-d883-47e3-b080-3dbabc45f104@github.com>
 <nJbYVfIPDYdgsMc-z11yd_EQXSUjUfzGyDTGkNgL4w8=.6da132ea-f04e-49e3-a072-4572e4f414c5@github.com>
 <ABfr9TlMBFwU3SYHsjHAJbqwOCOLbnyzsIGOSZAYlvE=.01d36959-3220-4685-86c7-eb56505627e7@github.com>
Message-ID: <yCJQR1JTXwKYKgLR-CeOhLA_ff7mbsOy1fdBJSPFr_M=.6d5211ff-1589-48fb-b5ba-d09badf49cfd@github.com>

On Fri, 2 Oct 2020 21:54:07 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> What if we removed the handling of specific exceptions from L278-L285 so that the special handling is limited to
>> BadArgs? If anything other than BadArgs is throw then it can print the exception to log output along with the cause (if
>> not null). No objection. That might avoid the tool emitting a "scary" stack trace when an error occurs.
>
> I think for `ResolutionException` and IAE (and possibly `PluginException`), the exception message should be helpful
> enough to correct for example user-errors and that's why this special catch block.
> Having another look, I think `FindException` may just fall into the last `Throwable` handler.   The new catch block may
> not be needed.

I noticed that the `Thorowable` catchall case at the bottom was there, but kept the `FindException` as a distinct block
because the other exceptions exit with a different error code. Catching the `FindException` at the top level is
technically not an abnormal termination, but a "normal" error case.  Does this matter all that much?

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

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

From bpb at openjdk.java.net  Mon Oct  5 19:03:49 2020
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Mon, 5 Oct 2020 19:03:49 GMT
Subject: RFR: 8067127: Tags cleanup
Message-ID: <8YR2pzHDTetS1LChJUDvPtgo_LdMBZggFfmkdLl-HO4=.8016f8e2-aa1f-429f-a744-798807c7964e@github.com>

Please review this change to update some javadoc tags in the java.io package. The changes are to replace some
occurrences of <code>some_code</code> with {@code some_code}. Not all such constructs were replaced as being
infeasible, e.g., tag contains an entity such as <code>*&#47;</code> (DataOutput, Serial), or multiple {@code} tags
would be needed or the result would be ugly (File). It is unclear whether some of the changes which remove the
non-breaking space entity (&nbsp;) are desirable.

Thanks,

Brian

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

Commit messages:
 - 8067127: Tags cleanup

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

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

From bpb at openjdk.java.net  Mon Oct  5 19:24:43 2020
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Mon, 5 Oct 2020 19:24:43 GMT
Subject: RFR: 8067127: Tags cleanup
In-Reply-To: <GlpygQPVSqxt2k5hlw0tei-pKgxPYAzP8Om2RenUrKg=.50bef153-4e8b-4246-bf63-c3c4ceb790ca@github.com>
References: <8YR2pzHDTetS1LChJUDvPtgo_LdMBZggFfmkdLl-HO4=.8016f8e2-aa1f-429f-a744-798807c7964e@github.com>
 <GlpygQPVSqxt2k5hlw0tei-pKgxPYAzP8Om2RenUrKg=.50bef153-4e8b-4246-bf63-c3c4ceb790ca@github.com>
Message-ID: <Jcq_FVPxqbXlblNIvLEq54e-Z0_074tSVrNJMIcwa0Y=.fad49a0f-3b51-423f-9550-f453141d1290@github.com>

On Mon, 5 Oct 2020 19:20:07 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this change to update some javadoc tags in the java.io package. The changes are to replace some
>> occurrences of <code>some_code</code> with {@code some_code}. Not all such constructs were replaced as being
>> infeasible, e.g., tag contains an entity such as <code>*&#47;</code> (DataOutput, Serial), or multiple {@code} tags
>> would be needed or the result would be ugly (File). It is unclear whether some of the changes which remove the
>> non-breaking space entity (&nbsp;) are desirable.  Thanks,  Brian
>
> From the perspective of the Standard Doclet this change looks good. I have to note, however, that there are minor
> losses in markup, e.g. unused italic highlighting such as `<i>c</i>`. On that I don't have an opinion.

Thanks. I didn't think that the loss of italics was significant where this change was applied.

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

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

From prappo at openjdk.java.net  Mon Oct  5 19:24:42 2020
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Mon, 5 Oct 2020 19:24:42 GMT
Subject: RFR: 8067127: Tags cleanup
In-Reply-To: <8YR2pzHDTetS1LChJUDvPtgo_LdMBZggFfmkdLl-HO4=.8016f8e2-aa1f-429f-a744-798807c7964e@github.com>
References: <8YR2pzHDTetS1LChJUDvPtgo_LdMBZggFfmkdLl-HO4=.8016f8e2-aa1f-429f-a744-798807c7964e@github.com>
Message-ID: <GlpygQPVSqxt2k5hlw0tei-pKgxPYAzP8Om2RenUrKg=.50bef153-4e8b-4246-bf63-c3c4ceb790ca@github.com>

On Mon, 5 Oct 2020 18:59:00 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Please review this change to update some javadoc tags in the java.io package. The changes are to replace some
> occurrences of <code>some_code</code> with {@code some_code}. Not all such constructs were replaced as being
> infeasible, e.g., tag contains an entity such as <code>*&#47;</code> (DataOutput, Serial), or multiple {@code} tags
> would be needed or the result would be ugly (File). It is unclear whether some of the changes which remove the
> non-breaking space entity (&nbsp;) are desirable.  Thanks,  Brian

>From the perspective of the Standard Doclet this change looks good. I have to note, however, that there are minor
losses in markup, e.g. unused italic highlighting such as `<i>c</i>`. On that I don't have an opinion.

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

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

From bobv at openjdk.java.net  Mon Oct  5 19:25:45 2020
From: bobv at openjdk.java.net (Bob Vandette)
Date: Mon, 5 Oct 2020 19:25:45 GMT
Subject: RFR: 8245543: Cgroups: Incorrect detection logic on some systems
 (still reproducible) [v3]
In-Reply-To: <9Y61ZqGTPrr7PY1UjY55Y3UdjZHu08tfn0iE6AhUb9Q=.2da3dbc9-55c2-48ac-b087-a2b26f0c6378@github.com>
References: <CWATRi437QpkCA1sx-EsHFqVlSCV-G8EgkEoGdJgPHc=.a743be7e-8a00-4d91-866d-86ccf3fe714f@github.com>
 <9Y61ZqGTPrr7PY1UjY55Y3UdjZHu08tfn0iE6AhUb9Q=.2da3dbc9-55c2-48ac-b087-a2b26f0c6378@github.com>
Message-ID: <znRYI56jaD-sNQpLDloBsjebFtbuhtk5nx7AUZEsOus=.00600298-0e40-4be3-b3c6-2953db69ad07@github.com>

On Mon, 5 Oct 2020 10:16:49 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> An issue similar to [JDK-8239559](https://bugs.openjdk.java.net/browse/JDK-8239559) has been discovered. On the
>> affected system, `/proc/self/mountinfo` contains a line such as this one:
>> 
>> 35 26 0:26 / /sys/fs/cgroup/systemd rw,nosuid,nodev,noexec,relatime - cgroup systemd rw,name=systemd
>>  
>> 
>> Note that `/proc/cgroups` looks like this:
>> 
>> #subsys_name	hierarchy	num_cgroups	enabled
>> cpuset	0	1	1
>> cpu	0	1	1
>> cpuacct	0	1	1
>> blkio	0	1	1
>> memory	0	1	1
>> devices	0	1	1
>> freezer	0	1	1
>> net_cls	0	1	1
>> perf_event	0	1	1
>> net_prio	0	1	1
>> hugetlb	0	1	1
>> pids	0	1	1
>> 
>> This is in fact a cgroups v1 system with systemd put into a separate namespace via FS type `cgroup`. That mountinfo
>> line confuses the cgroups version detection heuristic. It only looked whether or not there is **any** entry in
>> mountinfo of FS-type `cgroup` . That's wrong. A better heuristic would be looking at controllers we care about: `cpu`,
>> `cpuacct`, `memory`, `cpuset` for hotspot and some more for the Java side. The proposed fix on the hotspot side is to
>> set `any_cgroup_mounts_found` to true only if one of those controllers show up in mountinfo. Otherwise, we know it's
>> cgroup v2 due to the zero hierarchy ids.  For the Java side the proposal is to add some parsing for mountinfo lines and
>> look for `cgroup` FS-type lines which aren't also mounted purely for systemd.
>> **Testing**
>> 
>>  - [x] Linux x86_64 container tests on cgroup v1 (fastdebug)
>>  - [x] Linux x86_64 container tests on cgroup v2 (fastdebug)
>>  - [x] Added regression test which fails prior the patch and passes after
>>  - [x] Submit testing
>
> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo in comment

src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemFactory.java line 150:

> 148:         // find anyway in that case.
> 149:         try (Stream<String> mntInfo = CgroupUtil.readFilePrivileged(Paths.get(mountInfo))) {
> 150:             boolean anyCgroupMounted = mntInfo.anyMatch(CgroupSubsystemFactory::noSystemdCgroupLine);

I'd prefer a similar approach to the hotspot side where you do a positive check for controllers we are interested in
rather than a negative check for systemd.

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

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

From LANCE.ANDERSEN at ORACLE.COM  Mon Oct  5 19:51:01 2020
From: LANCE.ANDERSEN at ORACLE.COM (Lance Andersen)
Date: Mon, 5 Oct 2020 15:51:01 -0400
Subject: Request for Discussion: 8253952: Work around wrong usage of
 ZipOutputStream.putNextEntry() in user code
In-Reply-To: <99e80b7e-7702-338d-cd92-c9d1a396dfa5@oracle.com>
References: <CA+3eh12_-fNxf_KFK68WEqVoD_n6CD7RCbe=LoKCyCeUQ3w0oQ@mail.gmail.com>
 <4658d3a6-3360-fb84-e5ff-20dc6cc61b92@oracle.com>
 <CA+3eh10vr3vs92UPu7PwiaofZpf46QuzsuFf4bvf26gbYKF3-g@mail.gmail.com>
 <99e80b7e-7702-338d-cd92-c9d1a396dfa5@oracle.com>
Message-ID: <DCBE7C9D-A8CB-4A14-8B79-DEA3BE4B2CA8@ORACLE.COM>

Hi Volker,

Thank you for looking into this and creating a draft PR.

On the surface, I don?t see a reason to introduce a  System property.  What challenges do you see  if you used the DataDescriptor unless ZipEntry::setCompressedSize is called?  That seems to address the issue that you discovered without having to introduce a new System property. Or is there an additional concern that is not obvious?  This seems like it would address the problem for existing code that is not well behaved.

The other option is to add an additional method to ZipOutputStream or ZipEntry to address the issue.

Thoughts?

Best
Lance

> On Oct 5, 2020, at 2:13 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> On 05/10/2020 11:04, Volker Simonis wrote:
>> :
>>> I don't
>>> think the proposal to add a system property to change the behavior is
>>> feasible, at least not without changing the spec but even then it would
>>> be very icky.
>> Why do you think so? The answer to this question is especially
>> important to me because we are considering doing this in our internal
>> version independently of upstream OpenJKD (and potentially also in 8 &
>> 11).
> Introducing system properties to change the behavior of APIs and "fix" existing code is really icky. For the main line, then I think it would be good to explore the impact of changing the existing putNextEntry or introducing a new API. The compatibility impact of the former may not be significant but I would expect the spec would be clarified as part of this (that is what I was trying to say above). Exploring new APIs would be good and a method on ZipEntry may not be too bad (you have a reference to the target ZOS in the implementation).
> 
>> :
>> 
>> And just as a side note, we also use the "jdk.util.zip.inhibitZip64"
>> property in ZipOutputStream for a similar reason. I just wonder how
>> that could pass the CCC process as I couldn't even find any
>> documentation for it :)
> ZIP64 was very problematic at the time as it wasn't supported by several tools. The system property was introduced to disable the feature/support so that Java applications didn't create ZIP files that other tools couldn't consume. It would be good to get an up to date picture on ZIP64 support as it might be that this switch can be removed. It pre-dates the CSR  process but there was a CCC at the time.
> 
> -Alan


Best
Lance
------------------




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





From herrick at openjdk.java.net  Mon Oct  5 20:15:42 2020
From: herrick at openjdk.java.net (Andy Herrick)
Date: Mon, 5 Oct 2020 20:15:42 GMT
Subject: RFR: 8253379: [windows] Several jpackage tests failed with error
 code 1638
In-Reply-To: <GKD9xQrmlAkGvMkUDSZdse454-4mUwrkHUyPTWptWck=.f9d2d7c5-1ad0-4363-aaf4-00d4d7058c7b@github.com>
References: <LpRaGB39y6sd9g4cO4JZRPWsYl0oUtSO0l6Smv2xgbo=.992f6c8e-c478-4c3c-bf1e-5f43191336cd@github.com>
 <mO6jx5OxYK4fkCLm5vWPFHkXtiISqE8QRWEaO-0ty5g=.6cfd6aab-cee9-4253-8bce-8c625143ac6b@github.com>
 <GKD9xQrmlAkGvMkUDSZdse454-4mUwrkHUyPTWptWck=.f9d2d7c5-1ad0-4363-aaf4-00d4d7058c7b@github.com>
Message-ID: <G_Crofwu9SHLWBfnlfoHaXKD7IZKGN414o-tGTGv-_c=.89728cf8-019d-463f-9a8a-d411239649aa@github.com>

On Thu, 24 Sep 2020 23:07:30 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> 
> 
> Currently msi wrapper unconditionally adds "/i" on msiexec command line. So passing "/x" option to exe installer would
> not work. I think we need to rework msi wrapper to only support one command line option - "--uninstall" instead of
> passing all command line parameters to nested msiexec invocation.

yes - but until we have that implemented in the wrapper, shouldn't we disable in the tests installing what we can't
unintall ?

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

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

From rriggs at openjdk.java.net  Mon Oct  5 20:51:46 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Mon, 5 Oct 2020 20:51:46 GMT
Subject: RFR: 8067127: Tags cleanup
In-Reply-To: <8YR2pzHDTetS1LChJUDvPtgo_LdMBZggFfmkdLl-HO4=.8016f8e2-aa1f-429f-a744-798807c7964e@github.com>
References: <8YR2pzHDTetS1LChJUDvPtgo_LdMBZggFfmkdLl-HO4=.8016f8e2-aa1f-429f-a744-798807c7964e@github.com>
Message-ID: <dMAmqJXQfWiKQzoO2323FybqqdQ4MNBPFcY78bo-fLs=.34972cc7-b182-4191-bfe7-872c29cff1c2@github.com>

On Mon, 5 Oct 2020 18:59:00 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Please review this change to update some javadoc tags in the java.io package. The changes are to replace some
> occurrences of <code>some_code</code> with {@code some_code}. Not all such constructs were replaced as being
> infeasible, e.g., tag contains an entity such as <code>*&#47;</code> (DataOutput, Serial), or multiple {@code} tags
> would be needed or the result would be ugly (File). It is unclear whether some of the changes which remove the
> non-breaking space entity (&nbsp;) are desirable.  Thanks,  Brian

Marked as reviewed by rriggs (Reviewer).

src/java.base/share/classes/java/io/PipedReader.java line 62:

> 60:      * next character of data will be stored when received from the connected
> 61:      * piped writer. {@code in < 0} implies the buffer is empty,
> 62:      * {@code in==out} implies the buffer is full

Add spaces around ==?

src/java.base/share/classes/java/io/FileFilter.java line 33:

> 31:  *
> 32:  * <p> Instances of this interface may be passed to the {@link
> 33:  * File#listFiles(java.io.FileFilter) listFiles(FileFilter)} method

I would tend to keep {@link on the same line with the rest of the link.

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

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

From rriggs at openjdk.java.net  Mon Oct  5 20:59:44 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Mon, 5 Oct 2020 20:59:44 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v2]
In-Reply-To: <6P-wrlA7c9wlXEhcoAYW5J9W2jwTmTTj3PkDObPh0LA=.c11aa048-8853-4e1c-a689-c34b89c15f12@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <6P-wrlA7c9wlXEhcoAYW5J9W2jwTmTTj3PkDObPh0LA=.c11aa048-8853-4e1c-a689-c34b89c15f12@github.com>
Message-ID: <T48t-_XIiM_NlSZau6pj9hjSxp--n9pktxI6XCZ-W8k=.54c779af-e1af-4e62-9e4f-48ed7145bfc9@github.com>

On Mon, 5 Oct 2020 18:29:58 GMT, CoreyAshford <github.com+51754783+CoreyAshford at openjdk.org> wrote:

>> This patch set encompasses the following commits:
>> 
>> - Adds a new HotSpot intrinsic candidate to the java.lang.Base64 class - decodeBlock(), and provides a flexible API for
>>   the intrinsic.  The API is similar to the existing encodeBlock intrinsic.
>> - Adds the code in HotSpot to check and martial the new intrinsic's arguments to the arch-specific intrinsic
>>   implementation
>> - Adds a Power64LE-specific implementation of the decodeBlock intrinsic.
>> - Adds a JMH microbenchmark for both Base64 encoding and encoding.
>> - Enhances the JTReg hotspot intrinsic "TestBase64.java" regression test to more fully test both decoding and encoding.
>
> CoreyAshford has updated the pull request with a new target base due to a merge or a rebase. The pull request now
> contains ten commits:
>  - AOT: Revert change to aotCodeHeap.cpp for decodeBlock
>    
>    Don't add the SET_AOT_GLOBAL_SYMBOL_VALUE macro for decode block until all
>    arches that implement AOT, implement the decodeBlock intrinsic.
>  - Base64.java decodeBlock: Changes from PR review
>    
>     * Make comparison safer and consistent with the while loop
>     * Update comment about the decodeBlock intrinsic so that it matches the new structure
>     * Add comment about the lack of a length check on the destination buffer
>     * As per issue 8138732, change HotSpotIntrinsicCandidate to IntrinsicCandidate
>  - stubGenerator_ppc.cpp: Changes from PR review
>    
>     * Fix clearing of upper bits to clear 32 bits instead of 31 (due to misreading of clrldi instruction)
>     * change and document loop_unrolls setting from 8 to 2 after re-running the benchmark
>     * align unrolled loop on a 32-byte boundary
>     * replace instruction used for checking isURL from a double word to single
>       word instruction since the register is effectively 32 bits wide
>     * cosmetic change to realign register comments.
>  - TestBase64.java: Changes from PR review
>    
>     * Use Utils.toByteArrays() method instead of a locally-defined method
>     * Generate the two non-Base64 tables dynamically rather than use static initialization
>     * Added comments describing the two above-mentioned arrays
>  - Expand the Base64 intrinsic regression test to cover decodeBlock
>    
>    This patch makes four significant changes:
>    
>    1) The Power implementation of the decodeBlock intrinsic, at least,
>    requires a decode length of at least 128 bytes, but the existing test cases
>    are much shorter, maxing out at 111 bytes.  So the patch adds a new input
>    data file which has longer test cases in it.
>    
>    2) The original test cases only covers the encoding of just the printable
>    subset of the 7-bit ASCII characters.  However, Base64 encoding requires
>    being able to encode arbitrary binary data, i.e. it must handle all 256
>    8-bit byte encodings.  To remedy this, but keep the original line-oriented
>    style of the input data, I added another input file type that uses a simple
>    ASCII hexadecimal encoding - two ASCII hex characters per 8-bit byte.  When
>    test0 is called, a new parameter is passed that specifies the type of the
>    input file, which is either the original ASCII type or the hexadecimal
>    format.  So to test both longer input data and arbitrary 8-bit data, the
>    newly added input test file has test cases which are both longer and
>    encoded in ASCII hex so as to give full 8-bit capability.  When reading
>    this type of file, test0 calls a newly-added function to translate the
>    ASCII hex to binary data.  Except for the first line of input data, which
>    contains all possible 8-bit values sequentially, the input data was
>    generated using a random length (between 111 and 520 bytes) buffer filled
>    with random 8-bit data, which should give adequate coverage.
>    
>    3) The original test did not test that the decoder detects illegal Base64
>    bytes.  This change chooses a random location in the encoded data to
>    corrupt with a randomly-chosen byte which is illegal for the specific
>    Base64 encoding that is chosen (i.e. standard or URLsafe).  It then calls
>    the decode function to verify that the illegal byte is detected and the
>    proper exception is thrown.
>    
>    4) The test iteration count was originally 100K, but that is far more than
>    enough iterations to test the intrinsic.  It takes 20K iterations on each
>    instrinsic for HotSpot C2 to begin calling it.  The test originally had
>    three types of encodings to test and called the encode intrinsic four times
>    for each iteration, which works out to 100K * 3 * 4 = 1.2M calls just to
>    encode.  Decode was called four times as well (now five because of the
>    illegal byte test).  I believe this is excessive and with the extra test
>    data I have added, the test was timing out after ten minutes of execution.
>    It appears that it is timing out, not because the intrinsics take a long
>    time to run, but because test0 generates an enormous number of discarded
>    data buffers for the GC system to recover (the test runs at about 39GB of
>    virtual memory on my test machine).  To remedy the timeout problem, I have
>    changed the code so that a warmup function of 20K repetitions is performed
>    on a fixed buffer, to activate the instrinsic(s).  After the warmup, I have
>    reduced the number of iterations to 5K on each test0 call.  This should
>    give adequate coverage.
>  - Add JMH benchmark for Base64 variable length buffer decoding
>  - Add Power9+ intrinsic implementation for Base64 decoding
>  - Add HotSpot code to implement Base64 decodeBlock API
>  - Add HotSpotIntrinsicCandidate and API for Base64 decoding

Core Libs changes and the test look fine.

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

Marked as reviewed by rriggs (Reviewer).

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

From rriggs at openjdk.java.net  Mon Oct  5 21:07:42 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Mon, 5 Oct 2020 21:07:42 GMT
Subject: RFR: 8253750: use build-stable default seed for
 Utils.RANDOM_GENERATOR [v3]
In-Reply-To: <AIFV5ZwLYCPyA9X3Ezvb0ZRUSmdAPRAnzdkTd3aaBjo=.95bd0e9e-93e9-4211-892d-43fc473fc695@github.com>
References: <RQa3EOXeDAni1G-mu_jM-I9mosypb0gnuLUmFCtGhGo=.92a4f06b-60df-49b6-b6e3-bcf11e7530ab@github.com>
 <AIFV5ZwLYCPyA9X3Ezvb0ZRUSmdAPRAnzdkTd3aaBjo=.95bd0e9e-93e9-4211-892d-43fc473fc695@github.com>
Message-ID: <KQC2ihGQ6_QqzdVrvP3T1drnkMiQp_3wEAdz9fOYrUE=.a1c48ee4-e10d-4467-8bb8-f1a0a71b0985@github.com>

On Mon, 5 Oct 2020 16:46:55 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

>> Hi all,
>> 
>> could you please review the patch which updates `jdk.test.lib.Utils` to use md5 hash-sum of `java.vm.version` property
>> as default seed for `Utils.RANDOM_GENERATOR`?
>> from JBS:
>>> using the same seed for all runs of a build will make it possible (easier) to compare results from different test runs
>>> (e.g. on different platforms, w/ different flags) and consequently will make test results analysis easier. the proposed
>>> solution is to use the seed based on Runtime.version() / "java.vm.version", which are different from build to build, if
>>> there is no seed specified by "jdk.test.lib.random.seed" property.
>> 
>> the patch also updates `RandomGeneratorTest` test, so it expects now that the same values are generated if no seed is
>> provided.
>> testing:
>> ? tier1
>> ? `test/lib-test/jdk/test/lib/` against personal build on linux,windows,macos-x64
>> ? `test/lib-test/jdk/test/lib/` against CI build on linux,windows,macos-x64
>
> Igor Ignatyev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use random seed for personal/internal builds

Can you take a look at the existing jdk.test.lib.RandomFactory and see if we can avoid a separate random number
generator and property?

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

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

From herrick at openjdk.java.net  Mon Oct  5 21:13:46 2020
From: herrick at openjdk.java.net (Andy Herrick)
Date: Mon, 5 Oct 2020 21:13:46 GMT
Subject: Integrated: 8253426: jpackage is unable to generate working EXE for
 add-launcher configurations
In-Reply-To: <fJZt2_5woAa0onUFhNsIJoD0lVbVZQGIIbf0VN_VnpY=.aa7588ae-b25d-4869-8c05-523242dedf2f@github.com>
References: <fJZt2_5woAa0onUFhNsIJoD0lVbVZQGIIbf0VN_VnpY=.aa7588ae-b25d-4869-8c05-523242dedf2f@github.com>
Message-ID: <wyodzVygP44Kd3Q9d2g6PWQ3Na5Imq-q54p-EYHFYck=.f5d8ea6d-3f17-4ee9-b833-5dc1a24b9a7c@github.com>

On Thu, 24 Sep 2020 20:25:27 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> 8253426: jpackage is unable to generate working EXE for add-launcher configurations.
> secondary launchers ignored module, main-jar, and main-class in launcher properties file because  the LAUNCHER_DATA
> param was not removed from the set of params for each new add-module. testcase added in AddLauncherTest,java

This pull request has now been integrated.

Changeset: 4fe68f55
Author:    Andy Herrick <herrick at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/4fe68f55
Stats:     33 lines in 3 files changed: 30 ins; 0 del; 3 mod

8253426: jpackage is unable to generate working EXE for add-launcher configurations

Reviewed-by: almatvee, kizune, asemenyuk

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

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

From iignatyev at openjdk.java.net  Mon Oct  5 21:29:40 2020
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Mon, 5 Oct 2020 21:29:40 GMT
Subject: RFR: 8253750: use build-stable default seed for
 Utils.RANDOM_GENERATOR [v3]
In-Reply-To: <KQC2ihGQ6_QqzdVrvP3T1drnkMiQp_3wEAdz9fOYrUE=.a1c48ee4-e10d-4467-8bb8-f1a0a71b0985@github.com>
References: <RQa3EOXeDAni1G-mu_jM-I9mosypb0gnuLUmFCtGhGo=.92a4f06b-60df-49b6-b6e3-bcf11e7530ab@github.com>
 <AIFV5ZwLYCPyA9X3Ezvb0ZRUSmdAPRAnzdkTd3aaBjo=.95bd0e9e-93e9-4211-892d-43fc473fc695@github.com>
 <KQC2ihGQ6_QqzdVrvP3T1drnkMiQp_3wEAdz9fOYrUE=.a1c48ee4-e10d-4467-8bb8-f1a0a71b0985@github.com>
Message-ID: <eMd9vlpVTa_n9VdWF_aaJxbGtm2-iUsTaTclGmPnnn4=.c32a7487-27b0-4b34-8ff5-06c20fa1b2db@github.com>

On Mon, 5 Oct 2020 21:04:52 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Can you take a look at the existing jdk.test.lib.RandomFactory and see if we can avoid a separate random number
> generator and property?

I am not adding a new separate random number generator or a new property, `jdk.test.lib.Utils.getRandomInstance` has
been around for a long time and is used by lots of tests (most of them are in `/test/hotspot/jtreg`). merging
`Utils.getRandomInstance` and `RandomFactory` (or rather replacing one w/ another) is tracked by
[JDK-8212077](https://bugs.openjdk.java.net/browse/JDK-8212077).

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

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

From mchung at openjdk.java.net  Mon Oct  5 21:45:44 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Mon, 5 Oct 2020 21:45:44 GMT
Subject: RFR: 8204256: improve jlink error message to report unsupported
 class file format [v2]
In-Reply-To: <yCJQR1JTXwKYKgLR-CeOhLA_ff7mbsOy1fdBJSPFr_M=.6d5211ff-1589-48fb-b5ba-d09badf49cfd@github.com>
References: <fc0WYkvegw3_1RBfXVVy7Vs6HcX7b9UIq7fZ2kK4cCY=.218de7d9-7abf-4eec-af30-d2926464349c@github.com>
 <qGVlFtUbSi5Uo7ZVOhgIFjaBYjpD-5yo7_nPWOcbWQA=.81eefc43-09be-4c89-a018-d0de0f9d1292@github.com>
 <UOeX1EtrXyzdkhFeBx-prDjTGZwWh1my4NSODNZQwYg=.ef69bb7d-d883-47e3-b080-3dbabc45f104@github.com>
 <nJbYVfIPDYdgsMc-z11yd_EQXSUjUfzGyDTGkNgL4w8=.6da132ea-f04e-49e3-a072-4572e4f414c5@github.com>
 <ABfr9TlMBFwU3SYHsjHAJbqwOCOLbnyzsIGOSZAYlvE=.01d36959-3220-4685-86c7-eb56505627e7@github.com>
 <yCJQR1JTXwKYKgLR-CeOhLA_ff7mbsOy1fdBJSPFr_M=.6d5211ff-1589-48fb-b5ba-d09badf49cfd@github.com>
Message-ID: <F6z8Yv2EEYj4QsqFngesrQAvtJMdKZv5zD2wpK3fsRk=.e058bb9b-dc7e-4fef-9f2a-76a0002bc815@github.com>

On Mon, 5 Oct 2020 18:53:52 GMT, Ian Graves <igraves at openjdk.org> wrote:

>> I think for `ResolutionException` and IAE (and possibly `PluginException`), the exception message should be helpful
>> enough to correct for example user-errors and that's why this special catch block.
>> Having another look, I think `FindException` may just fall into the last `Throwable` handler.   The new catch block may
>> not be needed.
>
> I noticed that the `Thorowable` catchall case at the bottom was there, but kept the `FindException` as a distinct block
> because the other exceptions exit with a different error code. Catching the `FindException` at the top level is
> technically not an abnormal termination, but a "normal" error case.  Does this matter all that much?

I agree the normal error exit code is appropriate.  The proposed patch is good.  I will sponsor it.

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

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

From github.com+51754783+coreyashford at openjdk.java.net  Mon Oct  5 21:47:42 2020
From: github.com+51754783+coreyashford at openjdk.java.net (CoreyAshford)
Date: Mon, 5 Oct 2020 21:47:42 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v2]
In-Reply-To: <T48t-_XIiM_NlSZau6pj9hjSxp--n9pktxI6XCZ-W8k=.54c779af-e1af-4e62-9e4f-48ed7145bfc9@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <6P-wrlA7c9wlXEhcoAYW5J9W2jwTmTTj3PkDObPh0LA=.c11aa048-8853-4e1c-a689-c34b89c15f12@github.com>
 <T48t-_XIiM_NlSZau6pj9hjSxp--n9pktxI6XCZ-W8k=.54c779af-e1af-4e62-9e4f-48ed7145bfc9@github.com>
Message-ID: <jUYJaiGKl3ktWaYGsPH8p_Nd38t8I5AtdKtaVaDJcR0=.e8417e8d-91b5-41f3-af81-6e485167bd44@github.com>

On Mon, 5 Oct 2020 20:57:25 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> CoreyAshford has updated the pull request with a new target base due to a merge or a rebase. The pull request now
>> contains ten commits:
>>  - AOT: Revert change to aotCodeHeap.cpp for decodeBlock
>>    
>>    Don't add the SET_AOT_GLOBAL_SYMBOL_VALUE macro for decode block until all
>>    arches that implement AOT, implement the decodeBlock intrinsic.
>>  - Base64.java decodeBlock: Changes from PR review
>>    
>>     * Make comparison safer and consistent with the while loop
>>     * Update comment about the decodeBlock intrinsic so that it matches the new structure
>>     * Add comment about the lack of a length check on the destination buffer
>>     * As per issue 8138732, change HotSpotIntrinsicCandidate to IntrinsicCandidate
>>  - stubGenerator_ppc.cpp: Changes from PR review
>>    
>>     * Fix clearing of upper bits to clear 32 bits instead of 31 (due to misreading of clrldi instruction)
>>     * change and document loop_unrolls setting from 8 to 2 after re-running the benchmark
>>     * align unrolled loop on a 32-byte boundary
>>     * replace instruction used for checking isURL from a double word to single
>>       word instruction since the register is effectively 32 bits wide
>>     * cosmetic change to realign register comments.
>>  - TestBase64.java: Changes from PR review
>>    
>>     * Use Utils.toByteArrays() method instead of a locally-defined method
>>     * Generate the two non-Base64 tables dynamically rather than use static initialization
>>     * Added comments describing the two above-mentioned arrays
>>  - Expand the Base64 intrinsic regression test to cover decodeBlock
>>    
>>    This patch makes four significant changes:
>>    
>>    1) The Power implementation of the decodeBlock intrinsic, at least,
>>    requires a decode length of at least 128 bytes, but the existing test cases
>>    are much shorter, maxing out at 111 bytes.  So the patch adds a new input
>>    data file which has longer test cases in it.
>>    
>>    2) The original test cases only covers the encoding of just the printable
>>    subset of the 7-bit ASCII characters.  However, Base64 encoding requires
>>    being able to encode arbitrary binary data, i.e. it must handle all 256
>>    8-bit byte encodings.  To remedy this, but keep the original line-oriented
>>    style of the input data, I added another input file type that uses a simple
>>    ASCII hexadecimal encoding - two ASCII hex characters per 8-bit byte.  When
>>    test0 is called, a new parameter is passed that specifies the type of the
>>    input file, which is either the original ASCII type or the hexadecimal
>>    format.  So to test both longer input data and arbitrary 8-bit data, the
>>    newly added input test file has test cases which are both longer and
>>    encoded in ASCII hex so as to give full 8-bit capability.  When reading
>>    this type of file, test0 calls a newly-added function to translate the
>>    ASCII hex to binary data.  Except for the first line of input data, which
>>    contains all possible 8-bit values sequentially, the input data was
>>    generated using a random length (between 111 and 520 bytes) buffer filled
>>    with random 8-bit data, which should give adequate coverage.
>>    
>>    3) The original test did not test that the decoder detects illegal Base64
>>    bytes.  This change chooses a random location in the encoded data to
>>    corrupt with a randomly-chosen byte which is illegal for the specific
>>    Base64 encoding that is chosen (i.e. standard or URLsafe).  It then calls
>>    the decode function to verify that the illegal byte is detected and the
>>    proper exception is thrown.
>>    
>>    4) The test iteration count was originally 100K, but that is far more than
>>    enough iterations to test the intrinsic.  It takes 20K iterations on each
>>    instrinsic for HotSpot C2 to begin calling it.  The test originally had
>>    three types of encodings to test and called the encode intrinsic four times
>>    for each iteration, which works out to 100K * 3 * 4 = 1.2M calls just to
>>    encode.  Decode was called four times as well (now five because of the
>>    illegal byte test).  I believe this is excessive and with the extra test
>>    data I have added, the test was timing out after ten minutes of execution.
>>    It appears that it is timing out, not because the intrinsics take a long
>>    time to run, but because test0 generates an enormous number of discarded
>>    data buffers for the GC system to recover (the test runs at about 39GB of
>>    virtual memory on my test machine).  To remedy the timeout problem, I have
>>    changed the code so that a warmup function of 20K repetitions is performed
>>    on a fixed buffer, to activate the instrinsic(s).  After the warmup, I have
>>    reduced the number of iterations to 5K on each test0 call.  This should
>>    give adequate coverage.
>>  - Add JMH benchmark for Base64 variable length buffer decoding
>>  - Add Power9+ intrinsic implementation for Base64 decoding
>>  - Add HotSpot code to implement Base64 decodeBlock API
>>  - Add HotSpotIntrinsicCandidate and API for Base64 decoding
>
> Core Libs changes and the test look fine.

8248188: Add IntrinsicCandidate and API for Base64 decoding, add Power64LE intrinsic implementation.

This patch set encompasses the following commits:

Adds a new intrinsic candidate to the java.lang.Base64 class - decodeBlock(), and provides a flexible API for the
intrinsic. The API is similar to the existing encodeBlock intrinsic.

Adds the code in HotSpot to check and martial the new intrinsic's arguments to the arch-specific intrinsic
implementation.

Adds a Power64LE-specific implementation of the decodeBlock intrinsic.

Adds a JMH microbenchmark for both Base64 encoding and encoding.

Enhances the JTReg hotspot intrinsic "TestBase64.java" regression test to more fully test both decoding and encoding.

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

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

From rriggs at openjdk.java.net  Mon Oct  5 22:14:40 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Mon, 5 Oct 2020 22:14:40 GMT
Subject: RFR: 8253750: use build-stable default seed for
 Utils.RANDOM_GENERATOR [v3]
In-Reply-To: <eMd9vlpVTa_n9VdWF_aaJxbGtm2-iUsTaTclGmPnnn4=.c32a7487-27b0-4b34-8ff5-06c20fa1b2db@github.com>
References: <RQa3EOXeDAni1G-mu_jM-I9mosypb0gnuLUmFCtGhGo=.92a4f06b-60df-49b6-b6e3-bcf11e7530ab@github.com>
 <AIFV5ZwLYCPyA9X3Ezvb0ZRUSmdAPRAnzdkTd3aaBjo=.95bd0e9e-93e9-4211-892d-43fc473fc695@github.com>
 <KQC2ihGQ6_QqzdVrvP3T1drnkMiQp_3wEAdz9fOYrUE=.a1c48ee4-e10d-4467-8bb8-f1a0a71b0985@github.com>
 <eMd9vlpVTa_n9VdWF_aaJxbGtm2-iUsTaTclGmPnnn4=.c32a7487-27b0-4b34-8ff5-06c20fa1b2db@github.com>
Message-ID: <lAJPtLWbxb6mWKJKYnd2IKE-4OpdLFZZWlv0x0xAF8A=.5c750f39-7198-40a7-8b92-06768b4395b8@github.com>

On Mon, 5 Oct 2020 21:27:00 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

>> Can you take a look at the existing jdk.test.lib.RandomFactory and see if we can avoid a separate random number
>> generator and property?
>
>> Can you take a look at the existing jdk.test.lib.RandomFactory and see if we can avoid a separate random number
>> generator and property?
> 
> I am not adding a new separate random number generator or a new property, `jdk.test.lib.Utils.getRandomInstance` has
> been around for a long time and is used by lots of tests (most of them are in `/test/hotspot/jtreg`). merging
> `Utils.getRandomInstance` and `RandomFactory` (or rather replacing one w/ another) is tracked by
> [JDK-8212077](https://bugs.openjdk.java.net/browse/JDK-8212077).

I was thinking that the code added to Utils.SEED initialization could just have easily been added to
RandomFactory.getSystemSeed() and not have to be changed later.

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

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

From igraves at openjdk.java.net  Mon Oct  5 22:31:50 2020
From: igraves at openjdk.java.net (Ian Graves)
Date: Mon, 5 Oct 2020 22:31:50 GMT
Subject: RFR: 8253459: Formatter treats index,
 width and precision > Integer.MAX_VALUE incorrectly
Message-ID: <3aYgWcp1IVMM0vQT5UMLSnc2JA1uK9cbtRe283RF37g=.fc2049ef-cdbe-4948-a24b-fdb88cc87a1c@github.com>

The `java.util.Formatter` format specifies support for field widths, argument indexes, or precision lengths of a field
that relate to the variadic arguments supplied to the formatter. These numbers are specified by integers, sometimes
negative. For argument index, it's specified in the documentation that the highest allowed argument is limited by the
largest possible index of an array (ie the largest possible variadic index), but for the other two it's not defined.
Moreover, what happens when a number field in a string is too large or too small to be represented by a 32-bit integer
type is not defined.

This fix adds documentation to specify what error behavior occurs during these cases. Additionally it adds an
additional exception type to throw when an invalid argument index is observed.

A CSR will be required for this PR.

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

Commit messages:
 - Updating docs and throwing errors accordingly

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

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

From igraves at openjdk.java.net  Mon Oct  5 23:22:41 2020
From: igraves at openjdk.java.net (Ian Graves)
Date: Mon, 5 Oct 2020 23:22:41 GMT
Subject: Integrated: 8204256: improve jlink error message to report
 unsupported class file format
In-Reply-To: <fc0WYkvegw3_1RBfXVVy7Vs6HcX7b9UIq7fZ2kK4cCY=.218de7d9-7abf-4eec-af30-d2926464349c@github.com>
References: <fc0WYkvegw3_1RBfXVVy7Vs6HcX7b9UIq7fZ2kK4cCY=.218de7d9-7abf-4eec-af30-d2926464349c@github.com>
Message-ID: <iSA_6FeBEHGhEmMnTKCa5NxMtDKxnrzLMRPh1eLwOtw=.fe1b8e00-ad3a-4406-9116-2fb8937a752f@github.com>

On Tue, 29 Sep 2020 19:33:35 GMT, Ian Graves <igraves at openjdk.org> wrote:

> This pull request contains a change to facilitate better error messages in jlink for when jlink creates an image from
> jmod files that are unsupported by the runtime by being _too new_. The existing behavior supports modules that are too
> old via an error about a mismatched version.  The solution to this problem is constrained by jlink's use of some
> specified behavior by java.lang.module.ModuleFinder. The solution in this PR is to subclass some existing exceptions
> internally as to signal to jlink more specific error conditions when attempting to find and open modules.  Bug here:
> https://bugs.openjdk.java.net/browse/JDK-8204256
> New Error message example:
> 
>  reading module: /Users/igraves/dev/jdk-otro/build/macosx-x64/images/jmods/java.security.sasl.jmod
> java.lang.module.FindException: Error reading module:
> /Users/igraves/dev/jdk-otro/build/macosx-x64/images/jmods/java.security.sasl.jmod 	at
> java.base/jdk.internal.module.ModulePath.readModule(ModulePath.java:350) 	at
> java.base/jdk.internal.module.ModulePath.scanDirectory(ModulePath.java:284) 	at
> java.base/jdk.internal.module.ModulePath.scan(ModulePath.java:232) 	at
> java.base/jdk.internal.module.ModulePath.scanNextEntry(ModulePath.java:190) 	at
> java.base/jdk.internal.module.ModulePath.find(ModulePath.java:154) 	at
> jdk.jlink/jdk.tools.jlink.internal.JlinkTask.newModuleFinder(JlinkTask.java:443) 	at
> jdk.jlink/jdk.tools.jlink.internal.JlinkTask.initJlinkConfig(JlinkTask.java:374) 	at
> jdk.jlink/jdk.tools.jlink.internal.JlinkTask.run(JlinkTask.java:267) 	at
> jdk.jlink/jdk.tools.jlink.internal.Main.run(Main.java:54) 	at jdk.jlink/jdk.tools.jlink.internal.Main.main(Main.java:33)
> Caused by: java.lang.module.InvalidModuleDescriptorException: Unsupported major.minor version 60.0
> 	at java.base/jdk.internal.module.ModuleInfo.invalidModuleDescriptor(ModuleInfo.java:1088)
> 	at java.base/jdk.internal.module.ModuleInfo.doRead(ModuleInfo.java:192)
> 	at java.base/jdk.internal.module.ModuleInfo.read(ModuleInfo.java:129)
> 	at java.base/jdk.internal.module.ModulePath.readJMod(ModulePath.java:395)
> 	at java.base/jdk.internal.module.ModulePath.readModule(ModulePath.java:343)
> 	... 9 more```

This pull request has now been integrated.

Changeset: 5d84e95e
Author:    Ian Graves <igraves at openjdk.org>
Committer: Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/5d84e95e
Stats:     8 lines in 1 file changed: 4 ins; 0 del; 4 mod

8204256: improve jlink error message to report unsupported class file format

Reviewed-by: mchung

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

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

From iignatyev at openjdk.java.net  Mon Oct  5 23:33:40 2020
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Mon, 5 Oct 2020 23:33:40 GMT
Subject: RFR: 8253750: use build-stable default seed for
 Utils.RANDOM_GENERATOR [v3]
In-Reply-To: <lAJPtLWbxb6mWKJKYnd2IKE-4OpdLFZZWlv0x0xAF8A=.5c750f39-7198-40a7-8b92-06768b4395b8@github.com>
References: <RQa3EOXeDAni1G-mu_jM-I9mosypb0gnuLUmFCtGhGo=.92a4f06b-60df-49b6-b6e3-bcf11e7530ab@github.com>
 <AIFV5ZwLYCPyA9X3Ezvb0ZRUSmdAPRAnzdkTd3aaBjo=.95bd0e9e-93e9-4211-892d-43fc473fc695@github.com>
 <KQC2ihGQ6_QqzdVrvP3T1drnkMiQp_3wEAdz9fOYrUE=.a1c48ee4-e10d-4467-8bb8-f1a0a71b0985@github.com>
 <eMd9vlpVTa_n9VdWF_aaJxbGtm2-iUsTaTclGmPnnn4=.c32a7487-27b0-4b34-8ff5-06c20fa1b2db@github.com>
 <lAJPtLWbxb6mWKJKYnd2IKE-4OpdLFZZWlv0x0xAF8A=.5c750f39-7198-40a7-8b92-06768b4395b8@github.com>
Message-ID: <xgrbgOFGVAN8lb6auJ--pXT5aCx4ShHstf81yautId4=.5a73d2ca-c568-4181-87d8-b244951290c6@github.com>

On Mon, 5 Oct 2020 22:12:21 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>>> Can you take a look at the existing jdk.test.lib.RandomFactory and see if we can avoid a separate random number
>>> generator and property?
>> 
>> I am not adding a new separate random number generator or a new property, `jdk.test.lib.Utils.getRandomInstance` has
>> been around for a long time and is used by lots of tests (most of them are in `/test/hotspot/jtreg`). merging
>> `Utils.getRandomInstance` and `RandomFactory` (or rather replacing one w/ another) is tracked by
>> [JDK-8212077](https://bugs.openjdk.java.net/browse/JDK-8212077).
>
> I was thinking that the code added to Utils.SEED initialization could just have easily been added to
> RandomFactory.getSystemSeed() and not have to be changed later.

well, `RandomFactory::getSystemSeed` reads `seed` property, while `Utils.SEED` reads `jdk.test.lib.random.seed`, and
there are tests which use these properties to specify seeds, I'd prefer to leave changing these tests to
[8212077](https://bugs.openjdk.java.net/browse/JDK-8212077). o/c we can add a new method, e.g.
`RandomFactory::getBuildStableSeed`, or refactor `RandomFactory::getSystemSeed` to take property name as an argument,
but I don't think it's really worth it as 8212077 is starting to slowly bubble up in my working queue.

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

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

From mchung at openjdk.java.net  Tue Oct  6 00:22:45 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 6 Oct 2020 00:22:45 GMT
Subject: RFR: 8188055: (ref) Add Reference::refersTo predicate
In-Reply-To: <lNHgojO3Jrdaaq9RPiRq4IexTIjxVunPQKWg3f02m34=.d6c68bfd-b622-46b8-8737-be1cee2765f0@github.com>
References: <D4HSg8FT20Eaxk5KJkkw0GgETSxRkBn1ipS3Dt0kPto=.e4bab078-2e04-4413-90cb-9bfafb2a6831@github.com>
 <lNHgojO3Jrdaaq9RPiRq4IexTIjxVunPQKWg3f02m34=.d6c68bfd-b622-46b8-8737-be1cee2765f0@github.com>
Message-ID: <i3FCf78qIgiN0dK7Onl4YF3dyDJwkxuwGtkrz3lLjBE=.6cbf29f5-f7f3-4bff-baeb-ff31a2752052@github.com>

On Mon, 5 Oct 2020 10:51:02 GMT, Per Liden <pliden at openjdk.org> wrote:

>> Finally returning to this review that was started in April 2020.  I've
>> recast it as a github PR.  I think the security concern raised by Gil
>> has been adequately answered.
>> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-April/029203.html
>> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-July/030401.html
>> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-August/030677.html
>> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-September/030793.html
>> 
>> Please review a new function: java.lang.ref.Reference.refersTo.
>> 
>> This function is needed to test the referent of a Reference object without
>> artificially extending the lifetime of the referent object, as may happen
>> when calling Reference.get.  Some garbage collectors require extending the
>> lifetime of a weak referent when accessed, in order to maintain collector
>> invariants.  Lifetime extension may occur with any collector when the
>> Reference is a SoftReference, as calling get indicates recent access.  This
>> new function also allows testing the referent of a PhantomReference, which
>> can't be accessed by calling get.
>> 
>> The new function uses native methods whose implementations are in the VM so
>> they can use the Access API.  It is the intent that these methods will be
>> intrinsified by optimizing compilers like C2 or graal, but that hasn't been
>> implemented yet.  Bear that in mind before rushing off to change existing
>> uses of Reference.get.
>> 
>> There are two native methods involved, one in Reference and an override in
>> PhantomReference, both package private in java.lang.ref. The reason for this
>> split is to simplify the intrinsification. This is a change from the version
>> from April 2020; that version had a single native method in Reference,
>> implemented using the ON_UNKNOWN_OOP_REF Access reference strength category.
>> However, adding support for that category in the compilers adds significant
>> implementation effort and complexity. Splitting avoids that complexity.
>> 
>> Testing:
>> mach5 tier1
>> Locally (linux-x64) verified the new test passes with various garbage collectors.
>
> src/hotspot/share/prims/jvm.cpp line 3451:
> 
>> 3449:   JVMWrapper("JVM_ReferenceRefersTo");
>> 3450:   return referenceRefersTo<ON_WEAK_OOP_REF>(ref, o);
>> 3451: JVM_END
> 
> ... and let this be something like:
> 
> JVM_ENTRY(jboolean, JVM_ReferenceRefersTo(JNIEnv* env, jobject ref, jobject o))
>   JVMWrapper("JVM_ReferenceRefersTo");
>   oop ref_oop = JNIHandles::resolve_non_null(ref);
>   oop cmp_oop = JNIHandles::resolve(o);
>   return java_lang_ref_Reference::refers_to(ref_oop, cmp_oop);
> JVM_END

I like Per's suggestion that makes it explicitly connect to `Reference::refers_to`.

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

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

From mchung at openjdk.java.net  Tue Oct  6 00:22:44 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 6 Oct 2020 00:22:44 GMT
Subject: RFR: 8188055: (ref) Add Reference::refersTo predicate
In-Reply-To: <D4HSg8FT20Eaxk5KJkkw0GgETSxRkBn1ipS3Dt0kPto=.e4bab078-2e04-4413-90cb-9bfafb2a6831@github.com>
References: <D4HSg8FT20Eaxk5KJkkw0GgETSxRkBn1ipS3Dt0kPto=.e4bab078-2e04-4413-90cb-9bfafb2a6831@github.com>
Message-ID: <Y1IHoNr8vO3OkCbEKw6ywXd4adik1yKKNIS4ABzF0d0=.d21f4183-ef4e-45ed-826d-6613215b6220@github.com>

On Sun, 4 Oct 2020 03:59:59 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Finally returning to this review that was started in April 2020.  I've
> recast it as a github PR.  I think the security concern raised by Gil
> has been adequately answered.
> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-April/029203.html
> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-July/030401.html
> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-August/030677.html
> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-September/030793.html
> 
> Please review a new function: java.lang.ref.Reference.refersTo.
> 
> This function is needed to test the referent of a Reference object without
> artificially extending the lifetime of the referent object, as may happen
> when calling Reference.get.  Some garbage collectors require extending the
> lifetime of a weak referent when accessed, in order to maintain collector
> invariants.  Lifetime extension may occur with any collector when the
> Reference is a SoftReference, as calling get indicates recent access.  This
> new function also allows testing the referent of a PhantomReference, which
> can't be accessed by calling get.
> 
> The new function uses native methods whose implementations are in the VM so
> they can use the Access API.  It is the intent that these methods will be
> intrinsified by optimizing compilers like C2 or graal, but that hasn't been
> implemented yet.  Bear that in mind before rushing off to change existing
> uses of Reference.get.
> 
> There are two native methods involved, one in Reference and an override in
> PhantomReference, both package private in java.lang.ref. The reason for this
> split is to simplify the intrinsification. This is a change from the version
> from April 2020; that version had a single native method in Reference,
> implemented using the ON_UNKNOWN_OOP_REF Access reference strength category.
> However, adding support for that category in the compilers adds significant
> implementation effort and complexity. Splitting avoids that complexity.
> 
> Testing:
> mach5 tier1
> Locally (linux-x64) verified the new test passes with various garbage collectors.

Can you add a unit test in `test/jdk/java/lang/ref` that serves as a basic API test for this new `refersTo` API without
depending the WhiteBox API?     test/hotspot/jtreg/gc` test serves as a more white-boxed type and comprehensive test.

src/java.base/share/classes/java/lang/ref/Reference.java line 361:

> 359:
> 360:     /* Type-erased implementation of refersTo(). */
> 361:     native boolean refersTo0(Object o);

Is there any reason why it can't use the parameter type like `refersTo0(T o)`?  Same for `PhantomReference::refersTo0(T
o)`

src/hotspot/share/include/jvm.h line 334:

> 332:  */
> 333: JNIEXPORT jboolean JNICALL
> 334: JVM_PhantomReferenceRefersTo(JNIEnv *env, jobject ref, jobject o);

Instead of a separate `PhantomReference::refersTo0` native method (and new PhantomReference.c), an alternative approach
could be to detect if `ref` is an instance of `PhantomReference`  or other `Reference` and get the referent accordingly.

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

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

From minqi at openjdk.java.net  Tue Oct  6 00:45:53 2020
From: minqi at openjdk.java.net (Yumin Qi)
Date: Tue, 6 Oct 2020 00:45:53 GMT
Subject: RFR: 8247536: Support for pre-generated java.lang.invoke classes
 in CDS static archive [v9]
In-Reply-To: <Y_Bas-poGnDtvcJbqbmeIAPQRNxzvarBToQWALn9TTE=.e846cd3c-0e7b-48d3-8ffa-be3c03acffb0@github.com>
References: <Y_Bas-poGnDtvcJbqbmeIAPQRNxzvarBToQWALn9TTE=.e846cd3c-0e7b-48d3-8ffa-be3c03acffb0@github.com>
Message-ID: <5zY0JGVR6RGcAnTicYrgLIW1NL0f5-tkR1MMDjNYBTs=.0087b87b-b1f6-497a-8f4b-927246ee71cc@github.com>

> This patch is reorganized after 8252725, which is separated from this patch to refactor jlink glugin code. The previous
> webrev with hg can be found at: http://cr.openjdk.java.net/~minqi/2020/8247536/webrev-05. With 8252725 integrated, the
> regeneration of holder classes is simply to call the new added GenerateJLIClassesHelper.cdsGenerateHolderClasses
> function.  Tests: tier1-4

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

  Moved and renamed cdsGenerateHolderClasses from GenerateJLIClassesHelp to CDS as generateLambdaFormHolderClasses. Added
  input verification function in CDS before class generation. Added more test scenarios. Removed trailing unused ending
  words for output of lambda form trace line in case of DumpLoadedClassList.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/193/files
  - new: https://git.openjdk.java.net/jdk/pull/193/files/125112b3..52764a6e

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

  Stats: 290 lines in 10 files changed: 143 ins; 100 del; 47 mod
  Patch: https://git.openjdk.java.net/jdk/pull/193.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/193/head:pull/193

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

From rriggs at openjdk.java.net  Tue Oct  6 01:15:44 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 6 Oct 2020 01:15:44 GMT
Subject: RFR: 8188055: (ref) Add Reference::refersTo predicate
In-Reply-To: <D4HSg8FT20Eaxk5KJkkw0GgETSxRkBn1ipS3Dt0kPto=.e4bab078-2e04-4413-90cb-9bfafb2a6831@github.com>
References: <D4HSg8FT20Eaxk5KJkkw0GgETSxRkBn1ipS3Dt0kPto=.e4bab078-2e04-4413-90cb-9bfafb2a6831@github.com>
Message-ID: <65nW4xib46bbLUqxAEzQh2ep0m-44hr-lTXVHaJKEAg=.f413edc7-bce7-47cb-a9eb-4fc918afb408@github.com>

On Sun, 4 Oct 2020 03:59:59 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Finally returning to this review that was started in April 2020.  I've
> recast it as a github PR.  I think the security concern raised by Gil
> has been adequately answered.
> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-April/029203.html
> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-July/030401.html
> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-August/030677.html
> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-September/030793.html
> 
> Please review a new function: java.lang.ref.Reference.refersTo.
> 
> This function is needed to test the referent of a Reference object without
> artificially extending the lifetime of the referent object, as may happen
> when calling Reference.get.  Some garbage collectors require extending the
> lifetime of a weak referent when accessed, in order to maintain collector
> invariants.  Lifetime extension may occur with any collector when the
> Reference is a SoftReference, as calling get indicates recent access.  This
> new function also allows testing the referent of a PhantomReference, which
> can't be accessed by calling get.
> 
> The new function uses native methods whose implementations are in the VM so
> they can use the Access API.  It is the intent that these methods will be
> intrinsified by optimizing compilers like C2 or graal, but that hasn't been
> implemented yet.  Bear that in mind before rushing off to change existing
> uses of Reference.get.
> 
> There are two native methods involved, one in Reference and an override in
> PhantomReference, both package private in java.lang.ref. The reason for this
> split is to simplify the intrinsification. This is a change from the version
> from April 2020; that version had a single native method in Reference,
> implemented using the ON_UNKNOWN_OOP_REF Access reference strength category.
> However, adding support for that category in the compilers adds significant
> implementation effort and complexity. Splitting avoids that complexity.
> 
> Testing:
> mach5 tier1
> Locally (linux-x64) verified the new test passes with various garbage collectors.

src/java.base/share/classes/java/lang/ref/PhantomReference.java line 66:

> 64:     @Override
> 65:     native final boolean refersTo0(Object o);
> 66:

How does the existence of this method help future intrinsification?
If it was called somewhere it would be clearer.
Perhaps a comment now or later would help explain its function.

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

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

From dholmes at openjdk.java.net  Tue Oct  6 02:02:45 2020
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 6 Oct 2020 02:02:45 GMT
Subject: RFR: JDK-8247589: Implementation of Alpine Linux/x64 Port [v2]
In-Reply-To: <o4Ql6TAAuuFFuwG8KTHF_bqg_ZliQfcRpuqgNsAGNPA=.2f1aa9d4-0e25-4c5d-b556-701eeba2cc81@github.com>
References: <bjBywiEZ6tEHsG5xi2185_J-tduz4ezP8r6wVKbX1lY=.f6574f6f-be11-4d7c-8ebc-50b24ad8015d@github.com>
 <ZaC0wyl8pFXr1wCN8nuPgSA1pZOAEucaP6mkrJhZYf8=.8f81d618-31f0-4262-990a-980327739d4b@github.com>
 <PgeNNEaSfdBhf5I38_LN-SH3aFQUiFbloD6NG_bzMQA=.1178d2ca-82ca-4ca5-9e27-0bd86dcacb1a@github.com>
 <6jqlCPXe69fPRvYFrytJsECkaa9tJ1hYWISNgyPP4Eg=.40944ef5-93b0-4db4-948b-80bb7898e9e8@github.com>
 <o4Ql6TAAuuFFuwG8KTHF_bqg_ZliQfcRpuqgNsAGNPA=.2f1aa9d4-0e25-4c5d-b556-701eeba2cc81@github.com>
Message-ID: <aw463dmr3OoI-xwE92WKIvGK4tY52jbMb3Bb8yKsu6c=.7fa08759-5663-4450-8576-29d43c1635c1@github.com>

On Fri, 18 Sep 2020 10:56:56 GMT, Aleksei Voitylov <avoitylov at openjdk.org> wrote:

>> thank you Alan, Erik, and David! When the JEP becomes Targeted, I'll use this PR to integrate the changes.
>
> I added the contributors that could be found in the portola project commits. If anyone knows some other contributors I
> missed, I'll be happy to stand corrected.

@voitylov For future reference please don't force-push commits on open PRs as it breaks the commit history. I can no
longer just look at the two most recent commits and see what they added relative to what I had previously reviewed.
Thanks.

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

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

From tvaleev at openjdk.java.net  Tue Oct  6 03:14:41 2020
From: tvaleev at openjdk.java.net (Tagir F.Valeev)
Date: Tue, 6 Oct 2020 03:14:41 GMT
Subject: RFR: 8156071: List.of: reduce array copying during creation
In-Reply-To: <wgUqYY_pcHsD2y5zL7eSmlQubVzCxw7MjOKoQia1Cf4=.b2f66e7b-4c61-49f7-a036-e5b9b0ab562d@github.com>
References: <-pkG69_yCpZxK0LBMz3Dw_m2VkTK6BhhWBY02UkidfQ=.c1f424e8-5716-4858-aaa0-488a9e553107@github.com>
 <wgUqYY_pcHsD2y5zL7eSmlQubVzCxw7MjOKoQia1Cf4=.b2f66e7b-4c61-49f7-a036-e5b9b0ab562d@github.com>
Message-ID: <D_N7RiGqEUDfK62HZE2O9rLUM__Uy46r9BgdtnfGyUs=.68fe00a8-7434-45a8-be36-814866aae992@github.com>

On Fri, 2 Oct 2020 20:38:40 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Plumb new internal static factory method to trust the array passed in, avoiding unnecessary copying. JMH results for
>> the benchmark show about 15% improvement for the cases that were optimized, namely the 3 to 10 fixed arg cases.
>> # VM options: -verbose:gc -XX:+UseParallelGC -Xms4g -Xmx4g --enable-preview -verbose:gc -XX:+UsePara
>> llelGC -Xms4g -Xmx4g -Xint
>> # Warmup: 5 iterations, 1 s each
>> # Measurement: 5 iterations, 2 s each
>> 
>> WITHOUT varargs optimization:
>> 
>> Benchmark         Mode  Cnt     Score     Error   Units
>> ListArgs.list00  thrpt   15  6019.539 ? 144.040  ops/ms
>> ListArgs.list01  thrpt   15  1985.009 ?  40.606  ops/ms
>> ListArgs.list02  thrpt   15  1854.812 ?  17.488  ops/ms
>> ListArgs.list03  thrpt   15   963.866 ?  10.262  ops/ms
>> ListArgs.list04  thrpt   15   908.116 ?   6.278  ops/ms
>> ListArgs.list05  thrpt   15   848.607 ?  16.701  ops/ms
>> ListArgs.list06  thrpt   15   822.282 ?   8.905  ops/ms
>> ListArgs.list07  thrpt   15   780.057 ?  11.214  ops/ms
>> ListArgs.list08  thrpt   15   745.295 ?  19.204  ops/ms
>> ListArgs.list09  thrpt   15   704.596 ?  14.003  ops/ms
>> ListArgs.list10  thrpt   15   696.436 ?   4.914  ops/ms
>> ListArgs.list11  thrpt   15   661.908 ?  11.041  ops/ms
>> 
>> WITH varargs optimization:
>> 
>> Benchmark         Mode  Cnt     Score    Error   Units
>> ListArgs.list00  thrpt   15  6172.298 ? 62.736  ops/ms
>> ListArgs.list01  thrpt   15  1987.724 ? 45.468  ops/ms
>> ListArgs.list02  thrpt   15  1843.419 ? 10.693  ops/ms
>> ListArgs.list03  thrpt   15  1126.946 ? 30.952  ops/ms
>> ListArgs.list04  thrpt   15  1050.440 ? 17.859  ops/ms
>> ListArgs.list05  thrpt   15   999.275 ? 23.656  ops/ms
>> ListArgs.list06  thrpt   15   948.844 ? 19.615  ops/ms
>> ListArgs.list07  thrpt   15   897.541 ? 15.531  ops/ms
>> ListArgs.list08  thrpt   15   853.359 ? 18.755  ops/ms
>> ListArgs.list09  thrpt   15   826.394 ?  8.284  ops/ms
>> ListArgs.list10  thrpt   15   779.231 ?  4.104  ops/ms
>> ListArgs.list11  thrpt   15   650.888 ?  3.948  ops/ms
>
> Looks good, i wondered why the performance results were so slow then i looked more closely and saw "-Xint" was used. I
> usually don't ascribe much value to micro benchmarks run in interpreter only mode, but hey any shaving off startup time
> is welcome. Less allocation is definitely welcome (although i do wish C2 was better at eliding redundant array
> initialization and allocation).

Sorry to be late to the party. I thought that all reviews labeled with core-libs should be mirrored to core-libs-dev
mailing list but I haven't seen it there :(

Please note that the integrated implementation exposes listFromTrustedArray to everybody. No dirty unsafe reflection is
necessary, only single unchecked cast:

  static <T> List<T> untrustedArrayToList(T[] array) {
    @SuppressWarnings("unchecked")
    Function<List<T>, List<T>> finisher =
        (Function<List<T>, List<T>>) Collectors.<T>toUnmodifiableList().finisher();
    ArrayList<T> list = new ArrayList<>() {
      @Override
      public Object[] toArray() {
        return array;
      }
    };
    return finisher.apply(list);
  }

This might be qualified as a security issue.

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

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

From tvaleev at openjdk.java.net  Tue Oct  6 05:10:42 2020
From: tvaleev at openjdk.java.net (Tagir F.Valeev)
Date: Tue, 6 Oct 2020 05:10:42 GMT
Subject: RFR: 8156071: List.of: reduce array copying during creation
In-Reply-To: <D_N7RiGqEUDfK62HZE2O9rLUM__Uy46r9BgdtnfGyUs=.68fe00a8-7434-45a8-be36-814866aae992@github.com>
References: <-pkG69_yCpZxK0LBMz3Dw_m2VkTK6BhhWBY02UkidfQ=.c1f424e8-5716-4858-aaa0-488a9e553107@github.com>
 <wgUqYY_pcHsD2y5zL7eSmlQubVzCxw7MjOKoQia1Cf4=.b2f66e7b-4c61-49f7-a036-e5b9b0ab562d@github.com>
 <D_N7RiGqEUDfK62HZE2O9rLUM__Uy46r9BgdtnfGyUs=.68fe00a8-7434-45a8-be36-814866aae992@github.com>
Message-ID: <cimIDzR9PlwqdQue24nmLeIKKpcyCLBjOwaZwZxeBa8=.3e25a254-ebb7-4c1f-94d7-131556cac4f1@github.com>

On Tue, 6 Oct 2020 03:10:34 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

>> Looks good, i wondered why the performance results were so slow then i looked more closely and saw "-Xint" was used. I
>> usually don't ascribe much value to micro benchmarks run in interpreter only mode, but hey any shaving off startup time
>> is welcome. Less allocation is definitely welcome (although i do wish C2 was better at eliding redundant array
>> initialization and allocation).
>
> Sorry to be late to the party. I thought that all reviews labeled with core-libs should be mirrored to core-libs-dev
> mailing list but I haven't seen it there :(
> Please note that the integrated implementation exposes listFromTrustedArray to everybody. No dirty unsafe reflection is
> necessary, only single unchecked cast:
>   static <T> List<T> untrustedArrayToList(T[] array) {
>     @SuppressWarnings("unchecked")
>     Function<List<T>, List<T>> finisher =
>         (Function<List<T>, List<T>>) Collectors.<T>toUnmodifiableList().finisher();
>     ArrayList<T> list = new ArrayList<>() {
>       @Override
>       public Object[] toArray() {
>         return array;
>       }
>     };
>     return finisher.apply(list);
>   }
> 
> This might be qualified as a security issue.

This could be fixed by adding a classword check to the finisher, like this:

                                   list -> {
                                        if (list.getClass() != ArrayList.class) {
                                            throw new IllegalArgumentException();
                                        }
                                        return (List<T>) SharedSecrets.getJavaUtilCollectionAccess()
                                           .listFromTrustedArray(list.toArray());
                                   },

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

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

From turbanoff at gmail.com  Mon Oct  5 16:57:18 2020
From: turbanoff at gmail.com (Andrey Turbanov)
Date: Mon, 5 Oct 2020 19:57:18 +0300
Subject: Missing space in 'JavaMonitorsInStackTrace' VM option flag
Message-ID: <CAF+DQ5d7N0=AMUEMQQyPFsOUvd4EphPiCvw5w13tdkQShdV8GA@mail.gmail.com>

There is missing space between "are" and "dumped":

Print information about Java monitor locks when the stacks aredumped.


Andrey Turbanov

From alanb at openjdk.java.net  Tue Oct  6 06:10:45 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 6 Oct 2020 06:10:45 GMT
Subject: RFR: 8204256: improve jlink error message to report unsupported
 class file format [v3]
In-Reply-To: <q89EY996pciPx8Gt5AkuwwfHB4xe8Q7Dov2Vws6hj3U=.06e51550-1090-43ee-ac4f-de1ac041e7e9@github.com>
References: <fc0WYkvegw3_1RBfXVVy7Vs6HcX7b9UIq7fZ2kK4cCY=.218de7d9-7abf-4eec-af30-d2926464349c@github.com>
 <q89EY996pciPx8Gt5AkuwwfHB4xe8Q7Dov2Vws6hj3U=.06e51550-1090-43ee-ac4f-de1ac041e7e9@github.com>
Message-ID: <4WwtLGpZUECp1PlQ86NR3gY01Q-i_7vpvUQuiRQqM_Q=.50206a97-e8a0-43fe-80b4-ad445908b022@github.com>

On Mon, 5 Oct 2020 18:57:52 GMT, Ian Graves <igraves at openjdk.org> wrote:

>> This pull request contains a change to facilitate better error messages in jlink for when jlink creates an image from
>> jmod files that are unsupported by the runtime by being _too new_. The existing behavior supports modules that are too
>> old via an error about a mismatched version.  The solution to this problem is constrained by jlink's use of some
>> specified behavior by java.lang.module.ModuleFinder. The solution in this PR is to subclass some existing exceptions
>> internally as to signal to jlink more specific error conditions when attempting to find and open modules.  Bug here:
>> https://bugs.openjdk.java.net/browse/JDK-8204256
>> New Error message example:
>> 
>>  reading module: /Users/igraves/dev/jdk-otro/build/macosx-x64/images/jmods/java.security.sasl.jmod
>> java.lang.module.FindException: Error reading module:
>> /Users/igraves/dev/jdk-otro/build/macosx-x64/images/jmods/java.security.sasl.jmod 	at
>> java.base/jdk.internal.module.ModulePath.readModule(ModulePath.java:350) 	at
>> java.base/jdk.internal.module.ModulePath.scanDirectory(ModulePath.java:284) 	at
>> java.base/jdk.internal.module.ModulePath.scan(ModulePath.java:232) 	at
>> java.base/jdk.internal.module.ModulePath.scanNextEntry(ModulePath.java:190) 	at
>> java.base/jdk.internal.module.ModulePath.find(ModulePath.java:154) 	at
>> jdk.jlink/jdk.tools.jlink.internal.JlinkTask.newModuleFinder(JlinkTask.java:443) 	at
>> jdk.jlink/jdk.tools.jlink.internal.JlinkTask.initJlinkConfig(JlinkTask.java:374) 	at
>> jdk.jlink/jdk.tools.jlink.internal.JlinkTask.run(JlinkTask.java:267) 	at
>> jdk.jlink/jdk.tools.jlink.internal.Main.run(Main.java:54) 	at jdk.jlink/jdk.tools.jlink.internal.Main.main(Main.java:33)
>> Caused by: java.lang.module.InvalidModuleDescriptorException: Unsupported major.minor version 60.0
>> 	at java.base/jdk.internal.module.ModuleInfo.invalidModuleDescriptor(ModuleInfo.java:1088)
>> 	at java.base/jdk.internal.module.ModuleInfo.doRead(ModuleInfo.java:192)
>> 	at java.base/jdk.internal.module.ModuleInfo.read(ModuleInfo.java:129)
>> 	at java.base/jdk.internal.module.ModulePath.readJMod(ModulePath.java:395)
>> 	at java.base/jdk.internal.module.ModulePath.readModule(ModulePath.java:343)
>> 	... 9 more```
>
> Ian Graves has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixing formatting

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 280:

> 278:         } catch (FindException e) {
> 279:             log.println(taskHelper.getMessage("err.prefix") + " " + e.getMessage());
> 280:             e.printStackTrace(log);

I think my preference would be to not print the stack trace here, instead print the exception and the cause. This is to
avoid users of the tool thinking that the tool "has crashed".

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

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

From david.holmes at oracle.com  Tue Oct  6 07:14:16 2020
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 6 Oct 2020 17:14:16 +1000
Subject: Missing space in 'JavaMonitorsInStackTrace' VM option flag
In-Reply-To: <CAF+DQ5d7N0=AMUEMQQyPFsOUvd4EphPiCvw5w13tdkQShdV8GA@mail.gmail.com>
References: <CAF+DQ5d7N0=AMUEMQQyPFsOUvd4EphPiCvw5w13tdkQShdV8GA@mail.gmail.com>
Message-ID: <76770d34-0d4c-38a6-ccfc-c025803eba45@oracle.com>

On 6/10/2020 2:57 am, Andrey Turbanov wrote:
> There is missing space between "are" and "dumped":
> 
> Print information about Java monitor locks when the stacks aredumped.

Thanks Andrey. This is a hotspot issue. I've filed:

https://bugs.openjdk.java.net/browse/JDK-8254061

Cheers,
David


> 
> Andrey Turbanov
> 

From sgehwolf at openjdk.java.net  Tue Oct  6 08:34:42 2020
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Tue, 6 Oct 2020 08:34:42 GMT
Subject: RFR: 8245543: Cgroups: Incorrect detection logic on some systems
 (still reproducible) [v3]
In-Reply-To: <znRYI56jaD-sNQpLDloBsjebFtbuhtk5nx7AUZEsOus=.00600298-0e40-4be3-b3c6-2953db69ad07@github.com>
References: <CWATRi437QpkCA1sx-EsHFqVlSCV-G8EgkEoGdJgPHc=.a743be7e-8a00-4d91-866d-86ccf3fe714f@github.com>
 <9Y61ZqGTPrr7PY1UjY55Y3UdjZHu08tfn0iE6AhUb9Q=.2da3dbc9-55c2-48ac-b087-a2b26f0c6378@github.com>
 <znRYI56jaD-sNQpLDloBsjebFtbuhtk5nx7AUZEsOus=.00600298-0e40-4be3-b3c6-2953db69ad07@github.com>
Message-ID: <5dgnZpaXKV-Q6poVXgt0B0t3P06bGWT8D9JlcJIAtnw=.621aadd7-460f-438b-b46e-925098607bf3@github.com>

On Mon, 5 Oct 2020 19:22:04 GMT, Bob Vandette <bobv at openjdk.org> wrote:

>> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix typo in comment
>
> src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemFactory.java line 150:
> 
>> 148:         // find anyway in that case.
>> 149:         try (Stream<String> mntInfo = CgroupUtil.readFilePrivileged(Paths.get(mountInfo))) {
>> 150:             boolean anyCgroupMounted = mntInfo.anyMatch(CgroupSubsystemFactory::noSystemdCgroupLine);
> 
> I'd prefer a similar approach to the hotspot side where you do a positive check for controllers we are interested in
> rather than a negative check for systemd.

OK. I'll probably fold JDK-8254001 into this one then.

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

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

From dfuchs at openjdk.java.net  Tue Oct  6 09:22:42 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Tue, 6 Oct 2020 09:22:42 GMT
Subject: RFR: 8188055: (ref) Add Reference::refersTo predicate
In-Reply-To: <Y1IHoNr8vO3OkCbEKw6ywXd4adik1yKKNIS4ABzF0d0=.d21f4183-ef4e-45ed-826d-6613215b6220@github.com>
References: <D4HSg8FT20Eaxk5KJkkw0GgETSxRkBn1ipS3Dt0kPto=.e4bab078-2e04-4413-90cb-9bfafb2a6831@github.com>
 <Y1IHoNr8vO3OkCbEKw6ywXd4adik1yKKNIS4ABzF0d0=.d21f4183-ef4e-45ed-826d-6613215b6220@github.com>
Message-ID: <9x0zaxknpYXGIvHun1CkLP0lEC8NQmPTnANxQKjhHF8=.907bdb15-2e2e-4f84-8fe4-ea4ed50534cd@github.com>

On Tue, 6 Oct 2020 00:04:11 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Finally returning to this review that was started in April 2020.  I've
>> recast it as a github PR.  I think the security concern raised by Gil
>> has been adequately answered.
>> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-April/029203.html
>> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-July/030401.html
>> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-August/030677.html
>> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-September/030793.html
>> 
>> Please review a new function: java.lang.ref.Reference.refersTo.
>> 
>> This function is needed to test the referent of a Reference object without
>> artificially extending the lifetime of the referent object, as may happen
>> when calling Reference.get.  Some garbage collectors require extending the
>> lifetime of a weak referent when accessed, in order to maintain collector
>> invariants.  Lifetime extension may occur with any collector when the
>> Reference is a SoftReference, as calling get indicates recent access.  This
>> new function also allows testing the referent of a PhantomReference, which
>> can't be accessed by calling get.
>> 
>> The new function uses native methods whose implementations are in the VM so
>> they can use the Access API.  It is the intent that these methods will be
>> intrinsified by optimizing compilers like C2 or graal, but that hasn't been
>> implemented yet.  Bear that in mind before rushing off to change existing
>> uses of Reference.get.
>> 
>> There are two native methods involved, one in Reference and an override in
>> PhantomReference, both package private in java.lang.ref. The reason for this
>> split is to simplify the intrinsification. This is a change from the version
>> from April 2020; that version had a single native method in Reference,
>> implemented using the ON_UNKNOWN_OOP_REF Access reference strength category.
>> However, adding support for that category in the compilers adds significant
>> implementation effort and complexity. Splitting avoids that complexity.
>> 
>> Testing:
>> mach5 tier1
>> Locally (linux-x64) verified the new test passes with various garbage collectors.
>
> src/java.base/share/classes/java/lang/ref/Reference.java line 361:
> 
>> 359:
>> 360:     /* Type-erased implementation of refersTo(). */
>> 361:     native boolean refersTo0(Object o);
> 
> Is there any reason why it can't use the parameter type like `refersTo0(T o)`?  Same for `PhantomReference::refersTo0(T
> o)`

But should `refersTo` takes a `T`? I mean - if I have a `Reference<?> ref`, the compiler will not let me query
`ref.refersTo(o)`; is this what we want?

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

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

From michaelm at openjdk.java.net  Tue Oct  6 09:36:54 2020
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Tue, 6 Oct 2020 09:36:54 GMT
Subject: RFR: 8245194: Unix domain socket channel implementation [v15]
In-Reply-To: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
References: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
Message-ID: <yKnjNYori5L_X2W-NryG3PSpR05rOj2wgsQNJOz6yZU=.6052e1e6-3ad6-4011-8cd7-82c3a862634b@github.com>

> Continuing this review as a PR on github with the comments below incorporated. I expect there will be a few more
> iterations before integrating.
> On 06/09/2020 19:47, Alan Bateman wrote:
>> On 26/08/2020 15:24, Michael McMahon wrote:
>>>
>>> As I mentioned the other day, I wasn't able to use the suggested method on Windows which returns an absolute path. So,
>>> I added a method to WindowsPath which returns the path in the expected UTF-8 encoding as a byte[]. Let me know what you
>>> think of that.
>>>
>>> There is a fair bit of other refactoring and simplification done also. Next version is at:
>>>
>>> http://cr.openjdk.java.net/~michaelm/8245194/impl.webrev/webrev.9/
>>>
>> Adding a method to WindowsPath to encode the path using UTF-8 is okay but I don't think we should be caching it as the
>> encoding for sun_path is an outlier on Windows. I'm also a bit dubious about encoding a relative path when the resolved
>> path (before encoding) is > 247 chars. The documentation on the MS site isn't very completely and I think there are a
>> number points that require clarification to fully understand how this will work with relative, directly relative and
>> drive relative paths.
>>
> 
> Maybe it would be better to just use the path returned from toString() and do the conversion to UTF-8 externally. That
> would leave WindowsPath unchanged.
>> In the same area, the new PathUtil is a bit inconsistent with the existing provider code. One suggestion is to add a
>> method to AbstractFileSystemProvider instead. That is the base class the platform providers and would be a better place
>> to get the file path in bytes.
>>
> 
> Okay, I gave the method a name that is specific to Unix domain sockets because this UTF-8 strangeness is not likely to
> be useful by other components.
>> One other comment on the changes to the file system provider it should be okay to change UnixUserPrinipals ad its
>> fromUid and fromGid method to be public. This would mean that the patch shouldn't need to add UnixUserGroup (the main
>> issue is that class is that it means we end up with two classes with static factory methods doing the same thing).
> 
> Okay, that does simplify it a bit.
> 
> Thanks,
> Michael.
> 
>> -Alan.
>>
>>
>>
>>
>>
>>

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

  - update after Alan's review on Oct 4
  - includes API change required by JDK-8251952
  - original CSR for the overall change will be resubmitted with
    all api changes consolidated based on this update

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/52/files
  - new: https://git.openjdk.java.net/jdk/pull/52/files/0096645e..17acf10a

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

  Stats: 327 lines in 35 files changed: 108 ins; 125 del; 94 mod
  Patch: https://git.openjdk.java.net/jdk/pull/52.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/52/head:pull/52

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

From michaelm at openjdk.java.net  Tue Oct  6 09:52:10 2020
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Tue, 6 Oct 2020 09:52:10 GMT
Subject: RFR: 8245194: Unix domain socket channel implementation [v16]
In-Reply-To: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
References: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
Message-ID: <hyFYcTMFpVLhyN7qi_hVwR9Ti5KBVwNJNFex9ZQkf28=.5ce14f1a-1f7f-4180-ac0e-254984af0652@github.com>

> Continuing this review as a PR on github with the comments below incorporated. I expect there will be a few more
> iterations before integrating.
> On 06/09/2020 19:47, Alan Bateman wrote:
>> On 26/08/2020 15:24, Michael McMahon wrote:
>>>
>>> As I mentioned the other day, I wasn't able to use the suggested method on Windows which returns an absolute path. So,
>>> I added a method to WindowsPath which returns the path in the expected UTF-8 encoding as a byte[]. Let me know what you
>>> think of that.
>>>
>>> There is a fair bit of other refactoring and simplification done also. Next version is at:
>>>
>>> http://cr.openjdk.java.net/~michaelm/8245194/impl.webrev/webrev.9/
>>>
>> Adding a method to WindowsPath to encode the path using UTF-8 is okay but I don't think we should be caching it as the
>> encoding for sun_path is an outlier on Windows. I'm also a bit dubious about encoding a relative path when the resolved
>> path (before encoding) is > 247 chars. The documentation on the MS site isn't very completely and I think there are a
>> number points that require clarification to fully understand how this will work with relative, directly relative and
>> drive relative paths.
>>
> 
> Maybe it would be better to just use the path returned from toString() and do the conversion to UTF-8 externally. That
> would leave WindowsPath unchanged.
>> In the same area, the new PathUtil is a bit inconsistent with the existing provider code. One suggestion is to add a
>> method to AbstractFileSystemProvider instead. That is the base class the platform providers and would be a better place
>> to get the file path in bytes.
>>
> 
> Okay, I gave the method a name that is specific to Unix domain sockets because this UTF-8 strangeness is not likely to
> be useful by other components.
>> One other comment on the changes to the file system provider it should be okay to change UnixUserPrinipals ad its
>> fromUid and fromGid method to be public. This would mean that the patch shouldn't need to add UnixUserGroup (the main
>> issue is that class is that it means we end up with two classes with static factory methods doing the same thing).
> 
> Okay, that does simplify it a bit.
> 
> Thanks,
> Michael.
> 
>> -Alan.
>>
>>
>>
>>
>>
>>

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

 - Merge branch 'master' into unixdomainchannels
 - - update after Alan's review on Oct 4
   - includes API change required by JDK-8251952
   - original CSR for the overall change will be resubmitted with
     all api changes consolidated based on this update
 - - simplified Copy.gmk to CAT source files directly
   - renamed net.properties source files to all be net.properties
 - unixdomainchannels: error in the last commit in make/modules/java.base/Copy.gmk
 - unixdomainchannels:
   (1) rename UnixDomainHelper to UnixDomainSocketsUtil
   (2) remove hardcoded /tmp and /var/tmp paths from UnixDomainSocketsUtil
   (3) replace (2) with documented system/networking properties
   (4) Small update to UnixDomainSocketAddress API
   (5) CSR for (3) and (4) submitted at JDK-8253930
   (6) Update build to generate net.properties from shared net.properties.common
       plus platform specific additions.
 - Merge branch 'master' into unixdomainchannels
 - unixdomainchannels: remove more cruft from Windows Net.c
 - unixdomainchannels: change to Net.c was missed after all
 - unixdomainchannels: typo in WindowsFileSystemProvider.java
 - unixdomainchannels: Update after Alan's review of Sept 29
 - ... and 8 more: https://git.openjdk.java.net/jdk/compare/96b742dd...36efb46c

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/52/files
  - new: https://git.openjdk.java.net/jdk/pull/52/files/17acf10a..36efb46c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=52&range=15
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=52&range=14-15

  Stats: 15436 lines in 1715 files changed: 5751 ins; 2807 del; 6878 mod
  Patch: https://git.openjdk.java.net/jdk/pull/52.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/52/head:pull/52

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

From volker.simonis at gmail.com  Tue Oct  6 10:08:41 2020
From: volker.simonis at gmail.com (Volker Simonis)
Date: Tue, 6 Oct 2020 12:08:41 +0200
Subject: Request for Discussion: 8253952: Work around wrong usage of
 ZipOutputStream.putNextEntry() in user code
In-Reply-To: <DCBE7C9D-A8CB-4A14-8B79-DEA3BE4B2CA8@ORACLE.COM>
References: <CA+3eh12_-fNxf_KFK68WEqVoD_n6CD7RCbe=LoKCyCeUQ3w0oQ@mail.gmail.com>
 <4658d3a6-3360-fb84-e5ff-20dc6cc61b92@oracle.com>
 <CA+3eh10vr3vs92UPu7PwiaofZpf46QuzsuFf4bvf26gbYKF3-g@mail.gmail.com>
 <99e80b7e-7702-338d-cd92-c9d1a396dfa5@oracle.com>
 <DCBE7C9D-A8CB-4A14-8B79-DEA3BE4B2CA8@ORACLE.COM>
Message-ID: <CA+3eh125PAxoOAWd+nde4oCnYPOptr=y7arxfRLmy5o0mHpo5g@mail.gmail.com>

On Mon, Oct 5, 2020 at 9:53 PM Lance Andersen <LANCE.ANDERSEN at oracle.com> wrote:
>
> Hi Volker,
>
> Thank you for looking into this and creating a draft PR.
>
> On the surface, I don?t see a reason to introduce a  System property.  What challenges do you see  if you used the DataDescriptor unless ZipEntry::setCompressedSize is called?  That seems to address the issue that you discovered without having to introduce a new System property. Or is there an additional concern that is not obvious?  This seems like it would address the problem for existing code that is not well behaved.
>

Sure. That's obviously the simplest and best solution and I'd be
totally happy with it. I just thought there might be a need for
somehow preserving the old and buggy behaviour, that's why I added the
system property.

I've created a simpler version of the fix without property and
adjusted the @apiNote accordingly:

https://github.com/openjdk/jdk/pull/520

Would you be fine with such a solution?

Thank you and best regards,
Volker

> The other option is to add an additional method to ZipOutputStream or ZipEntry to address the issue.
>
> Thoughts?
>
> Best
> Lance
>
> On Oct 5, 2020, at 2:13 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>
> On 05/10/2020 11:04, Volker Simonis wrote:
>
> :
>
> I don't
> think the proposal to add a system property to change the behavior is
> feasible, at least not without changing the spec but even then it would
> be very icky.
>
> Why do you think so? The answer to this question is especially
> important to me because we are considering doing this in our internal
> version independently of upstream OpenJKD (and potentially also in 8 &
> 11).
>
> Introducing system properties to change the behavior of APIs and "fix" existing code is really icky. For the main line, then I think it would be good to explore the impact of changing the existing putNextEntry or introducing a new API. The compatibility impact of the former may not be significant but I would expect the spec would be clarified as part of this (that is what I was trying to say above). Exploring new APIs would be good and a method on ZipEntry may not be too bad (you have a reference to the target ZOS in the implementation).
>
> :
>
> And just as a side note, we also use the "jdk.util.zip.inhibitZip64"
> property in ZipOutputStream for a similar reason. I just wonder how
> that could pass the CCC process as I couldn't even find any
> documentation for it :)
>
> ZIP64 was very problematic at the time as it wasn't supported by several tools. The system property was introduced to disable the feature/support so that Java applications didn't create ZIP files that other tools couldn't consume. It would be good to get an up to date picture on ZIP64 support as it might be that this switch can be removed. It pre-dates the CSR  process but there was a CCC at the time.
>
> -Alan
>
>
>
> Best
> Lance
> ------------------
>
>
>
> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering
> 1 Network Drive
> Burlington, MA 01803
> Lance.Andersen at oracle.com
>
>
>
>

From Alan.Bateman at oracle.com  Tue Oct  6 10:47:42 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 6 Oct 2020 11:47:42 +0100
Subject: Request for Discussion: 8253952: Work around wrong usage of
 ZipOutputStream.putNextEntry() in user code
In-Reply-To: <CA+3eh125PAxoOAWd+nde4oCnYPOptr=y7arxfRLmy5o0mHpo5g@mail.gmail.com>
References: <CA+3eh12_-fNxf_KFK68WEqVoD_n6CD7RCbe=LoKCyCeUQ3w0oQ@mail.gmail.com>
 <4658d3a6-3360-fb84-e5ff-20dc6cc61b92@oracle.com>
 <CA+3eh10vr3vs92UPu7PwiaofZpf46QuzsuFf4bvf26gbYKF3-g@mail.gmail.com>
 <99e80b7e-7702-338d-cd92-c9d1a396dfa5@oracle.com>
 <DCBE7C9D-A8CB-4A14-8B79-DEA3BE4B2CA8@ORACLE.COM>
 <CA+3eh125PAxoOAWd+nde4oCnYPOptr=y7arxfRLmy5o0mHpo5g@mail.gmail.com>
Message-ID: <119e3643-1855-a1dd-7e98-af8ccfd0db6f@oracle.com>

On 06/10/2020 11:08, Volker Simonis wrote:
> Sure. That's obviously the simplest and best solution and I'd be
> totally happy with it. I just thought there might be a need for
> somehow preserving the old and buggy behaviour, that's why I added the
> system property.
>
> I've created a simpler version of the fix without property and
> adjusted the @apiNote accordingly:
>
> https://github.com/openjdk/jdk/pull/520
>
> Would you be fine with such a solution?
>
I think I could go along with the approach but we should clarify the 
spec, meaning the behavior should be in normative text rather than 
apiNote (an apiNote with additional commentary or example code is okay 
of course).

-Alan

From rrich at openjdk.java.net  Tue Oct  6 10:52:55 2020
From: rrich at openjdk.java.net (Richard Reingruber)
Date: Tue, 6 Oct 2020 10:52:55 GMT
Subject: RFR: 8227745: Enable Escape Analysis for Better Performance in
 the Presence of JVMTI Agents [v6]
In-Reply-To: <Ll2RereRbuQLgFtIjv9pS92kPvCVuo-BI0cP1zGjVbo=.dad3a33c-0fc3-44fd-810a-f01448cf564c@github.com>
References: <Ll2RereRbuQLgFtIjv9pS92kPvCVuo-BI0cP1zGjVbo=.dad3a33c-0fc3-44fd-810a-f01448cf564c@github.com>
Message-ID: <rp2LvA1Oar3nMaWPfMR23vFxy94uGMViDFnb-HgbOb0=.38dbe000-cfd4-4ce8-be1c-11b6e42b2c3e@github.com>

> Hi,
> 
> this is the continuation of the review of the implementation for:
> 
> https://bugs.openjdk.java.net/browse/JDK-8227745
> https://bugs.openjdk.java.net/browse/JDK-8233915
> 
> It allows for JIT optimizations based on escape analysis even if JVMTI agents acquire capabilities to access references
> to objects that are subject to such optimizations, e.g. scalar replacement. The implementation reverts such
> optimizations just before access very much as when switching from JIT compiled execution to the interpreter, aka
> "deoptimization".  Webrev.8 was the last one before before the transition to Git/Github:
> 
> http://cr.openjdk.java.net/~rrich/webrevs/8227745/webrev.8/
> 
> Thanks, Richard.

Richard Reingruber has updated the pull request with a new target base due to a merge or a rebase. The pull request now
contains 12 commits:

 - Merge branch 'master' into JDK-8227745
 - Merge branch 'master' into JDK-8227745
 - Make parameter current_thread of JvmtiEnvBase::check_top_frame() a JavaThread* again.
   
   With Asynchronous handshakes the type was changed from JavaThread* to Thread*
   but this is not necessary as check_top_frame() is not executed during a handshake
   / safepoint (robehn confirmed).
 - Merge branch 'master' into JDK-8227745
 - EATests.java: bugfix to prevent ObjectCollectedException
 - Better encapsulation of JvmtiDeferredUpdates. Moved jvmtiDeferredLocalVariableSet to jvmtiDeferredUpdates.hpp
 - EscapeBarrier: moved method comments.
 - Shuffled parameters of EscapeBarrier constructors to better match each other
 - Moved class EscapeBarrier and class JvmtiDeferredUpdates into dedicated files.
 - Merge branch 'master' into JDK-8227745
 - ... and 2 more: https://git.openjdk.java.net/jdk/compare/17285472...1c586cfb

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

Changes: https://git.openjdk.java.net/jdk/pull/119/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=119&range=05
  Stats: 5788 lines in 52 files changed: 5568 ins; 116 del; 104 mod
  Patch: https://git.openjdk.java.net/jdk/pull/119.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/119/head:pull/119

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

From LANCE.ANDERSEN at ORACLE.COM  Tue Oct  6 11:21:11 2020
From: LANCE.ANDERSEN at ORACLE.COM (Lance Andersen)
Date: Tue, 6 Oct 2020 07:21:11 -0400
Subject: Request for Discussion: 8253952: Work around wrong usage of
 ZipOutputStream.putNextEntry() in user code
In-Reply-To: <CA+3eh125PAxoOAWd+nde4oCnYPOptr=y7arxfRLmy5o0mHpo5g@mail.gmail.com>
References: <CA+3eh12_-fNxf_KFK68WEqVoD_n6CD7RCbe=LoKCyCeUQ3w0oQ@mail.gmail.com>
 <4658d3a6-3360-fb84-e5ff-20dc6cc61b92@oracle.com>
 <CA+3eh10vr3vs92UPu7PwiaofZpf46QuzsuFf4bvf26gbYKF3-g@mail.gmail.com>
 <99e80b7e-7702-338d-cd92-c9d1a396dfa5@oracle.com>
 <DCBE7C9D-A8CB-4A14-8B79-DEA3BE4B2CA8@ORACLE.COM>
 <CA+3eh125PAxoOAWd+nde4oCnYPOptr=y7arxfRLmy5o0mHpo5g@mail.gmail.com>
Message-ID: <266D112B-3883-4B6D-886E-1F4CE7641A34@ORACLE.COM>

Hi Volker 

> On Oct 6, 2020, at 6:08 AM, Volker Simonis <volker.simonis at gmail.com> wrote:
> 
> On Mon, Oct 5, 2020 at 9:53 PM Lance Andersen <LANCE.ANDERSEN at oracle.com <mailto:LANCE.ANDERSEN at oracle.com>> wrote:
>> 
>> Hi Volker,
>> 
>> Thank you for looking into this and creating a draft PR.
>> 
>> On the surface, I don?t see a reason to introduce a  System property.  What challenges do you see  if you used the DataDescriptor unless ZipEntry::setCompressedSize is called?  That seems to address the issue that you discovered without having to introduce a new System property. Or is there an additional concern that is not obvious?  This seems like it would address the problem for existing code that is not well behaved.
>> 
> 
> Sure. That's obviously the simplest and best solution and I'd be
> totally happy with it. I just thought there might be a need for
> somehow preserving the old and buggy behaviour, that's why I added the
> system property.
> 
> I've created a simpler version of the fix without property and
> adjusted the @apiNote accordingly:

Thank you for updating your proposal.  We will need to update the javadoc so that the  description of the change is normative and not part of the API note itself.  We will also need to create a CSR for the proposed change in the spec and functionality.  I believe we should also create a release note for this change

Best
Lance
> 
> https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/520__;!!GqivPVa7Brio!O7epzMWqwxuS6aPQIllYZLdRTncNGXj5ioqVYY72igGBVGZgUGAHlQnCJ8mhzRoAvw$ <https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/520__;!!GqivPVa7Brio!O7epzMWqwxuS6aPQIllYZLdRTncNGXj5ioqVYY72igGBVGZgUGAHlQnCJ8mhzRoAvw$> 
> 
> Would you be fine with such a solution?
> 
> Thank you and best regards,
> Volker
> 
>> The other option is to add an additional method to ZipOutputStream or ZipEntry to address the issue.
>> 
>> Thoughts?
>> 
>> Best
>> Lance
>> 
>> On Oct 5, 2020, at 2:13 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>> 
>> On 05/10/2020 11:04, Volker Simonis wrote:
>> 
>> :
>> 
>> I don't
>> think the proposal to add a system property to change the behavior is
>> feasible, at least not without changing the spec but even then it would
>> be very icky.
>> 
>> Why do you think so? The answer to this question is especially
>> important to me because we are considering doing this in our internal
>> version independently of upstream OpenJKD (and potentially also in 8 &
>> 11).
>> 
>> Introducing system properties to change the behavior of APIs and "fix" existing code is really icky. For the main line, then I think it would be good to explore the impact of changing the existing putNextEntry or introducing a new API. The compatibility impact of the former may not be significant but I would expect the spec would be clarified as part of this (that is what I was trying to say above). Exploring new APIs would be good and a method on ZipEntry may not be too bad (you have a reference to the target ZOS in the implementation).
>> 
>> :
>> 
>> And just as a side note, we also use the "jdk.util.zip.inhibitZip64"
>> property in ZipOutputStream for a similar reason. I just wonder how
>> that could pass the CCC process as I couldn't even find any
>> documentation for it :)
>> 
>> ZIP64 was very problematic at the time as it wasn't supported by several tools. The system property was introduced to disable the feature/support so that Java applications didn't create ZIP files that other tools couldn't consume. It would be good to get an up to date picture on ZIP64 support as it might be that this switch can be removed. It pre-dates the CSR  process but there was a CCC at the time.
>> 
>> -Alan
>> 
>> 
>> 
>> Best
>> Lance
>> ------------------
>> 
>> 
>> 
>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
>> Oracle Java Engineering
>> 1 Network Drive
>> Burlington, MA 01803
>> Lance.Andersen at oracle.com


Best
Lance
------------------




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





From rriggs at openjdk.java.net  Tue Oct  6 13:38:08 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 6 Oct 2020 13:38:08 GMT
Subject: RFR: 8253750: use build-stable default seed for
 Utils.RANDOM_GENERATOR [v3]
In-Reply-To: <AIFV5ZwLYCPyA9X3Ezvb0ZRUSmdAPRAnzdkTd3aaBjo=.95bd0e9e-93e9-4211-892d-43fc473fc695@github.com>
References: <RQa3EOXeDAni1G-mu_jM-I9mosypb0gnuLUmFCtGhGo=.92a4f06b-60df-49b6-b6e3-bcf11e7530ab@github.com>
 <AIFV5ZwLYCPyA9X3Ezvb0ZRUSmdAPRAnzdkTd3aaBjo=.95bd0e9e-93e9-4211-892d-43fc473fc695@github.com>
Message-ID: <S0aS_QQOXwZtGw3IWuaf5AAC47l717QHLPFOyKra8NY=.38275d3c-5bb1-4d51-8c83-5f6439747344@github.com>

On Mon, 5 Oct 2020 16:46:55 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

>> Hi all,
>> 
>> could you please review the patch which updates `jdk.test.lib.Utils` to use md5 hash-sum of `java.vm.version` property
>> as default seed for `Utils.RANDOM_GENERATOR`?
>> from JBS:
>>> using the same seed for all runs of a build will make it possible (easier) to compare results from different test runs
>>> (e.g. on different platforms, w/ different flags) and consequently will make test results analysis easier. the proposed
>>> solution is to use the seed based on Runtime.version() / "java.vm.version", which are different from build to build, if
>>> there is no seed specified by "jdk.test.lib.random.seed" property.
>> 
>> the patch also updates `RandomGeneratorTest` test, so it expects now that the same values are generated if no seed is
>> provided.
>> testing:
>> ? tier1
>> ? `test/lib-test/jdk/test/lib/` against personal build on linux,windows,macos-x64
>> ? `test/lib-test/jdk/test/lib/` against CI build on linux,windows,macos-x64
>
> Igor Ignatyev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use random seed for personal/internal builds

Marked as reviewed by rriggs (Reviewer).

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

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

From rriggs at openjdk.java.net  Tue Oct  6 13:38:09 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 6 Oct 2020 13:38:09 GMT
Subject: RFR: 8253750: use build-stable default seed for
 Utils.RANDOM_GENERATOR [v3]
In-Reply-To: <xgrbgOFGVAN8lb6auJ--pXT5aCx4ShHstf81yautId4=.5a73d2ca-c568-4181-87d8-b244951290c6@github.com>
References: <RQa3EOXeDAni1G-mu_jM-I9mosypb0gnuLUmFCtGhGo=.92a4f06b-60df-49b6-b6e3-bcf11e7530ab@github.com>
 <AIFV5ZwLYCPyA9X3Ezvb0ZRUSmdAPRAnzdkTd3aaBjo=.95bd0e9e-93e9-4211-892d-43fc473fc695@github.com>
 <KQC2ihGQ6_QqzdVrvP3T1drnkMiQp_3wEAdz9fOYrUE=.a1c48ee4-e10d-4467-8bb8-f1a0a71b0985@github.com>
 <eMd9vlpVTa_n9VdWF_aaJxbGtm2-iUsTaTclGmPnnn4=.c32a7487-27b0-4b34-8ff5-06c20fa1b2db@github.com>
 <lAJPtLWbxb6mWKJKYnd2IKE-4OpdLFZZWlv0x0xAF8A=.5c750f39-7198-40a7-8b92-06768b4395b8@github.com>
 <xgrbgOFGVAN8lb6auJ--pXT5aCx4ShHstf81yautId4=.5a73d2ca-c568-4181-87d8-b244951290c6@github.com>
Message-ID: <s63g3pN3B0G58ReRGkqYgLY1gB60DnWwsEynMij9hC0=.c07a661f-1067-411a-bc25-4bb70e3875ab@github.com>

On Mon, 5 Oct 2020 23:30:37 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

>> I was thinking that the code added to Utils.SEED initialization could just have easily been added to
>> RandomFactory.getSystemSeed() and not have to be changed later.
>
> well, `RandomFactory::getSystemSeed` reads `seed` property, while `Utils.SEED` reads `jdk.test.lib.random.seed`, and
> there are tests which use these properties to specify seeds, I'd prefer to leave changing these tests to
> [8212077](https://bugs.openjdk.java.net/browse/JDK-8212077). o/c we can add a new method, e.g.
> `RandomFactory::getBuildStableSeed`, or refactor `RandomFactory::getSystemSeed` to take property name as an argument,
> but I don't think it's really worth it as 8212077 is starting to slowly bubble up in my working queue.

If the factories duplication will get combined/resolved with 8212077, I'll leave that up to you.

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

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

From simonis at openjdk.java.net  Tue Oct  6 13:51:21 2020
From: simonis at openjdk.java.net (Volker Simonis)
Date: Tue, 6 Oct 2020 13:51:21 GMT
Subject: RFR: 8253952: Work around wrong usage of
 ZipOutputStream.putNextEntry() in user code
Message-ID: <0nq5oFKOj6AZqCW6jF268-6oKRI6UkS6TRIHo-_5vKw=.d13c7016-4473-4b20-9117-100b368d3716@github.com>

### Summary

Work around wrong usage of `ZipOutputStream.putNextEntry()` in user code which can lead to the `ZipException "invalid
entry compressed size"`.

### Motivation

In general it is not safe to directly write a ZipEntry obtained from `ZipInputStream.getNextEntry()`,
`ZipFile.entries()`, `ZipFile.getEntry()` or `ZipFile.stream()` with `ZipOutputStream.putNextEntry()` to a
`ZipOutputStream` and then read the entries data from the `ZipInputStream` and write it to the `ZipOutputStream` as
follows:
 ZipEntry entry;
 ZipInputStream zis = new ZipInputStream(...);
 ZipOutputStream zos = new ZipOutputStream(...);
 while((entry = zis.getNextEntry()) != null) {
     zos.putNextEntry(entry);
     zis.transferTo(zos);
 }
The problem with this code is that the zip file format does not record the compression level used for deflation in its
entries. In general, it doesn't even mandate a predefined compression ratio per compression level. Therefore the
compressed size recorded in a `ZipEntry` read from a zip file might differ from the new compressed size produced by the
receiving `ZipOutputStream`. Such a difference will result in a `ZipException` with the following message:
 java.util.zip.ZipException: invalid entry compressed size (expected 12 but got 7 bytes)
 
The correct way of copying all entries from one zip file into another requires the creation of a new `ZipEntry` or at
least resetting of the compressed size field. E.g.:
 while((entry = zis.getNextEntry()) != null) {
     ZipEntry newEntry = new ZipEntry(entry.getName());
     zos.putNextEntry(newEntry);
     zis.transferTo(zos);
 }
or:
 while((entry = zis.getNextEntry()) != null) {
     entry.setCompressedSize(-1);
     zos.putNextEntry(entry);
     zis.transferTo(zos);
 }
Unfortunately, there's a lot of user code out there which gets this wrong and uses the bad coding pattern described
before. Searching for `"java.util.zip.ZipException: invalid entry compressed size (expected 12 but got 7 bytes)"` gives
~2500 hits (~100 on StackOverflow). It's also no hard to find plenty of instances of this anti-pattern on GitHub when
doing a code search for `ZipEntry` and `putNextEntry()`. E.g. [Gradle 4.x wrapper task][1] is affected as well as the
latest version of the [mockableAndroidJar task][2]. I've recently fixed two occurrences of this pattern in OpenJDK (see
[JDK-8240333][3] and [JDK-8240235][4]) but there still exist more of them (e.g.
[`test/jdk/java/util/zip/ZipFile/CopyJar.java`][5] which is there since 1999 :).

### Description

So while this has clearly been a problem before, it apparently wasn't painful enough to trigger any action from the
side of the JDK. However, recently quite some zlib forks with [superior deflate/inflate performance have evolved][6].
Using them with OpenJDK is quite straight-forward: one just has to configure the alternative implementations by setting
`LD_LIBRARY_PATH` or `LD_PRELOAD` correspondingly. We've seen big saving by using these new zlib implementations for
selected services in production and the only reason why we haven't enabled them by default until now is the problem
I've just described. The reason why these new libraries uncover the described anti-pattern much more often is because
their compression ratio is slightly different from that of the default zlib library. This can easily trigger a
`ZipException` even if an application is not using a different compression levels but just a zip file created with
another zlib version.

I'd therefore like to propose the following workaround for the wrong `ZipOutputStream.putNextEntry()` usage in user
code:

-  ignore the compressed size if it was implicitly determined from the zip file and not explicitly set by calling
   `ZipEntry.setCompressedSize()`.

- Change the API-documentation of `ZipOutputStream.putNextEntry()` and `JarOutputStream.putNextEntry()` to explain the
  problem and why `putNextEntry()` will ignore the compressed size of a `ZipEntry` if that was set implicitely when
  reading that entry from a `ZipFile` or `ZipInputStream`.


### Technical Details

A zip file consists of a stream of File Entries followed by a Central Directory (see [here for a more detailed
specification][7]). Each File Entry is composed of a Local File Header (LFH) followed by the compressed Data and an
optional Data Descriptor. The LFH contains the File Name and among other attributes the Compressed and Uncompressed
size and CRC of the Data. In the case where the latter three attributes are not available at the time when the LFH is
created, this fact will be recorded in a flag of the LFH and will trigger the creation of a Data Descriptor with the
corresponding information right after the Data section. Finally, the Central Directory contains one Central Directory
File Header (CDFH) for each entry of the  zip archive. The CDFH is an extended version of the LFH and the ultimate
reference for the contents of the zip archive. The redundancy between LFH and CDFH is a tribute to zip's long history
when it was used to store archives on multiple floppy discs and the CDFH allowed to update the archive by only writing
to the last disc which contained the Central Directory.

`ZipEntries` read with `ZipInputStream.getNextEntry()` will initially only contain the information from the LFH. Only
after the next entry was read (or after `ZipInputStream.closeEntry()` was called explicitly), will the previously read
entry be updated with the data from the Data Descriptor. `ZipInputStream` doesn't inspect the Central Directory at all.

On the other hand, `ZipFile` only queries the Central Directory for `ZipEntry` information so all `ZipEntries` returned
by `ZipFile.entries()`, `ZipFile.getEntry()` and `ZipFile.stream()` will always instantly contain the full Compressed
and Uncompressed Size and CRC information for each entry independently of the LFH contents.

### Risks and Assumptions

If we choose to ignore the implicitly recorded compressed size in a `ZipEntry` read from a zip file when writing it to
a `ZipOutputStream`, this will lead to zip files with incomplete information in the LFH and an additional Data
Descriptor as described before. However, the result is still fully compatible to the zip file specification. It's also
not unusual, because by default all new zip files created with `ZipOutputStream` will contain LFHs without Compressed
and Uncompressed Size and CRC information and an additional Data Descriptor. Theoretically it is possible to create new
zip files with `ZipOutputStream` class and Compressed and Uncompressed Size and CRC information in the LFH but that's
complex and inefficient because it requires two steps. A first step to determine the crc and compressed size of the
data and a second step to actually write the data to the `ZipOutputStream` (which will compress it a second time). This
is because the current API offers no possibility to write already compressed data to a `ZipOutputStream`.

Consequently, the only straight-forward way of creating zip files from Java which have all the data in the LFH and no
Data Descriptor is by copying `ZipEntries` from an existing zip file with the buggy method described before. This
incidentally worked more or less reliable for a long time but breaks miserably when using different zlib
implementations. Ignoring the implicitly set compressed size of `ZipEntries` can easily fix this problem.

I'm not aware of any tool which can not handle such files and if it exists it would have problems with the majority of
Java created zip files anyway (e.g. all jar-files created with the jar tool have zip entries with incomplete LFH data
and additional Data Descriptor).

Ignoring the implicitly set compressed size of `ZipEntries` has no measurable performance impact and will increase the
size of zip archives which used to have the complete file information in the LFH before by 16 bytes per entry. On the
other hand it will give us the freedom to use whatever zip implementation we like :)


[1]:
https://github.com/gradle/gradle/blob/e76905e3a/subprojects/build-init/src/main/java/org/gradle/api/tasks/wrapper/Wrapper.java#L152-L158
[2]:
https://android.googlesource.com/platform/tools/base/+/refs/heads/master/build-system/builder/src/main/java/com/android/builder/testing/MockableJarGenerator.java#86
[3]: https://bugs.openjdk.java.net/browse/JDK-8240333 [4]: https://bugs.openjdk.java.net/browse/JDK-8240235 [5]:
https://github.com/openjdk/jdk/blob/master/test/jdk/java/util/zip/ZipFile/CopyJar.java [6]:
https://github.com/simonis/zlib-bench/blob/master/Results.md [7]: https://en.wikipedia.org/wiki/Zip_(file_format)

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

Commit messages:
 - 8253952: Work around wrong usage of ZipOutputStream.putNextEntry() in user code

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

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

From volker.simonis at gmail.com  Tue Oct  6 13:56:51 2020
From: volker.simonis at gmail.com (Volker Simonis)
Date: Tue, 6 Oct 2020 15:56:51 +0200
Subject: Request for Discussion: 8253952: Work around wrong usage of
 ZipOutputStream.putNextEntry() in user code
In-Reply-To: <266D112B-3883-4B6D-886E-1F4CE7641A34@ORACLE.COM>
References: <CA+3eh12_-fNxf_KFK68WEqVoD_n6CD7RCbe=LoKCyCeUQ3w0oQ@mail.gmail.com>
 <4658d3a6-3360-fb84-e5ff-20dc6cc61b92@oracle.com>
 <CA+3eh10vr3vs92UPu7PwiaofZpf46QuzsuFf4bvf26gbYKF3-g@mail.gmail.com>
 <99e80b7e-7702-338d-cd92-c9d1a396dfa5@oracle.com>
 <DCBE7C9D-A8CB-4A14-8B79-DEA3BE4B2CA8@ORACLE.COM>
 <CA+3eh125PAxoOAWd+nde4oCnYPOptr=y7arxfRLmy5o0mHpo5g@mail.gmail.com>
 <266D112B-3883-4B6D-886E-1F4CE7641A34@ORACLE.COM>
Message-ID: <CA+3eh10Tr8NnFaZDfxwq+Pc79AA4XkNOkZpy7epgkExEHw1M5A@mail.gmail.com>

On Tue, Oct 6, 2020 at 1:21 PM Lance Andersen <LANCE.ANDERSEN at oracle.com> wrote:
>
> Hi Volker
>
> On Oct 6, 2020, at 6:08 AM, Volker Simonis <volker.simonis at gmail.com> wrote:
>
> On Mon, Oct 5, 2020 at 9:53 PM Lance Andersen <LANCE.ANDERSEN at oracle.com> wrote:
>
>
> Hi Volker,
>
> Thank you for looking into this and creating a draft PR.
>
> On the surface, I don?t see a reason to introduce a  System property.  What challenges do you see  if you used the DataDescriptor unless ZipEntry::setCompressedSize is called?  That seems to address the issue that you discovered without having to introduce a new System property. Or is there an additional concern that is not obvious?  This seems like it would address the problem for existing code that is not well behaved.
>
>
> Sure. That's obviously the simplest and best solution and I'd be
> totally happy with it. I just thought there might be a need for
> somehow preserving the old and buggy behaviour, that's why I added the
> system property.
>
> I've created a simpler version of the fix without property and
> adjusted the @apiNote accordingly:
>
>
> Thank you for updating your proposal.  We will need to update the javadoc so that the  description of the change is normative and not part of the API note itself.

Changing the updated doc to be normativ instead of just an @apiNote
will make it impossible to downport this change but if you think it is
really necessary I will accept that. I've removed the @apiNote tag
from the java doc and changed the draft PR into a real PR.

Without the @apiNote tag I also had to copy the extra documentation
verbatim to JarOutputStream.putNextEntry() which is not very elegant
but inheriting the whole api doc from ZipOutputStream didn't seem
right either. Please let me know if you have a better idea.

I'll open a CSR once we've agreed on the exact text for the java doc change.

Please let's continue the discussion on the PR or the new mail that
was created for it.

Best regards,
Volker

> We will also need to create a CSR for the proposed change in the spec and functionality.  I believe we should also create a release note for this change
>
> Best
> Lance
>
>
> https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/520__;!!GqivPVa7Brio!O7epzMWqwxuS6aPQIllYZLdRTncNGXj5ioqVYY72igGBVGZgUGAHlQnCJ8mhzRoAvw$
>
> Would you be fine with such a solution?
>
> Thank you and best regards,
> Volker
>
> The other option is to add an additional method to ZipOutputStream or ZipEntry to address the issue.
>
> Thoughts?
>
> Best
> Lance
>
> On Oct 5, 2020, at 2:13 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>
> On 05/10/2020 11:04, Volker Simonis wrote:
>
> :
>
> I don't
> think the proposal to add a system property to change the behavior is
> feasible, at least not without changing the spec but even then it would
> be very icky.
>
> Why do you think so? The answer to this question is especially
> important to me because we are considering doing this in our internal
> version independently of upstream OpenJKD (and potentially also in 8 &
> 11).
>
> Introducing system properties to change the behavior of APIs and "fix" existing code is really icky. For the main line, then I think it would be good to explore the impact of changing the existing putNextEntry or introducing a new API. The compatibility impact of the former may not be significant but I would expect the spec would be clarified as part of this (that is what I was trying to say above). Exploring new APIs would be good and a method on ZipEntry may not be too bad (you have a reference to the target ZOS in the implementation).
>
> :
>
> And just as a side note, we also use the "jdk.util.zip.inhibitZip64"
> property in ZipOutputStream for a similar reason. I just wonder how
> that could pass the CCC process as I couldn't even find any
> documentation for it :)
>
> ZIP64 was very problematic at the time as it wasn't supported by several tools. The system property was introduced to disable the feature/support so that Java applications didn't create ZIP files that other tools couldn't consume. It would be good to get an up to date picture on ZIP64 support as it might be that this switch can be removed. It pre-dates the CSR  process but there was a CCC at the time.
>
> -Alan
>
>
>
> Best
> Lance
> ------------------
>
>
>
> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering
> 1 Network Drive
> Burlington, MA 01803
> Lance.Andersen at oracle.com
>
>
>
> Best
> Lance
> ------------------
>
>
>
> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering
> 1 Network Drive
> Burlington, MA 01803
> Lance.Andersen at oracle.com
>
>
>
>

From rriggs at openjdk.java.net  Tue Oct  6 13:59:10 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 6 Oct 2020 13:59:10 GMT
Subject: RFR: 8253459: Formatter treats index,
 width and precision > Integer.MAX_VALUE incorrectly
In-Reply-To: <3aYgWcp1IVMM0vQT5UMLSnc2JA1uK9cbtRe283RF37g=.fc2049ef-cdbe-4948-a24b-fdb88cc87a1c@github.com>
References: <3aYgWcp1IVMM0vQT5UMLSnc2JA1uK9cbtRe283RF37g=.fc2049ef-cdbe-4948-a24b-fdb88cc87a1c@github.com>
Message-ID: <gg0s8jJxwD602qg5kVnZ2KUmJb84vaks1WKh7-zyA1I=.8614d28b-e1e4-4d81-82ad-eba620a4516c@github.com>

On Mon, 5 Oct 2020 22:23:56 GMT, Ian Graves <igraves at openjdk.org> wrote:

> The `java.util.Formatter` format specifies support for field widths, argument indexes, or precision lengths of a field
> that relate to the variadic arguments supplied to the formatter. These numbers are specified by integers, sometimes
> negative. For argument index, it's specified in the documentation that the highest allowed argument is limited by the
> largest possible index of an array (ie the largest possible variadic index), but for the other two it's not defined.
> Moreover, what happens when a number field in a string is too large or too small to be represented by a 32-bit integer
> type is not defined.  This fix adds documentation to specify what error behavior occurs during these cases.
> Additionally it adds an additional exception type to throw when an invalid argument index is observed.  A CSR will be
> required for this PR.

Is the new exception type useful?  yes, it matches the previous pattern.
But it (and none of the IllegalFormatException subclasses) produce a readable message with the offending value. So the
developer will not see anything useful. The fine grained exceptions provide little value.

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

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

From rrich at openjdk.java.net  Tue Oct  6 14:09:13 2020
From: rrich at openjdk.java.net (Richard Reingruber)
Date: Tue, 6 Oct 2020 14:09:13 GMT
Subject: RFR: 8227745: Enable Escape Analysis for Better Performance in
 the Presence of JVMTI Agents [v3]
In-Reply-To: <ayyzITSxaqlsU0Ch0uLnooOLlr_Xn8dXRQHGLY3Qy40=.b2589ff3-a00f-44ed-973b-2087a35b542c@github.com>
References: <Ll2RereRbuQLgFtIjv9pS92kPvCVuo-BI0cP1zGjVbo=.dad3a33c-0fc3-44fd-810a-f01448cf564c@github.com>
 <D80z7im-ptE_UXYRfivkezq-W4ZuWkPwKOoT0MW1mxA=.676cae36-4e0f-473d-b577-21317f3c3ab3@github.com>
 <Pz8cdgFTXmF954txrAnk3whnhkeR2y6gTNiSTRC_CrY=.e3460eb4-d1dc-4621-b056-b0a46f4f6569@github.com>
 <i5Y6k8vBZUKKUCrUkaR8ux26ZBgy80UziZj0p2lYUuo=.e368568c-bbc8-4c63-bd23-847e7e008946@github.com>
 <ayyzITSxaqlsU0Ch0uLnooOLlr_Xn8dXRQHGLY3Qy40=.b2589ff3-a00f-44ed-973b-2087a35b542c@github.com>
Message-ID: <HYavlFjjBvmmW2N-aWpAUX10tS-cnZrjLhPccnWfQ7w=.9e7ad979-7b1c-43db-943d-f273c747ab8f@github.com>

On Tue, 29 Sep 2020 13:57:26 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>>> 
>>> 
>>> The minor updates in response to my comments are fine.
>>> 
>>> The more major updates ... I can't really comment on.
>> 
>> Thanks for looking at the changes and for giving feedback.
>
> Hi Serguei,
> 
> thanks for providing feedback! I've pushed the changes based on it now but I
> have not yet merged master again. This needs a little work...
> 
> Please find my replies to your comments below.
> 
> Thanks, Richard.
> 
>> Could you consider to place the classes EscapeBarrier and JvmtiDeferredUpdates
>> into theyr own .hpp/.cpp files? The class JvmtiDeferredUpdates would be better
>> to put into the folder 'prims' then.
> 
> Done. In addition I moved preexisting class jvmtiDeferredLocalVariableSet and
> class jvmtiDeferredLocalVariable from runtime/vframe_hp.hpp to
> prims/jvmtiDeferredUpdates.hpp. Please let me know if not ok.
> 
>> src/hotspot/share/opto/macro.cpp:
>> 
>> ```
>> @@ -1091,11 +1091,11 @@
>>  bool PhaseMacroExpand::eliminate_allocate_node(AllocateNode *alloc) {
>>    // Don't do scalar replacement if the frame can be popped by JVMTI:
>>    // if reallocation fails during deoptimization we'll pop all
>>    // interpreter frames for this compiled frame and that won't play
>>    // nice with JVMTI popframe.
>> -  if (!EliminateAllocations || JvmtiExport::can_pop_frame() || !alloc->_is_non_escaping) {
>> +  if (!EliminateAllocations || !alloc->_is_non_escaping) {
>>      return false;
>>    }
>> ```
>> 
>> I wonder if the comment is still correct after you removed the check for JvmtiExport::can_pop_frame().
> 
> Good catch. I fixed it previously with
> https://github.com/openjdk/jdk/pull/119/commits/18dd54b4e6f17ca723e4ae1a1e8dc57e81878dd3
> 
>> src/hotspot/share/runtime/deoptimization.hpp:
>> 
>> ```
>> +  EscapeBarrier(JavaThread* calling_thread, JavaThread* deoptee_thread, bool barrier_active)
>> +    : _calling_thread(calling_thread), _deoptee_thread(deoptee_thread),
>> +      _barrier_active(barrier_active && (JVMCI_ONLY(UseJVMCICompiler) NOT_JVMCI(false)
>> +                      COMPILER2_PRESENT(|| DoEscapeAnalysis)))
>> . . . . . . . . .
>> +
>> +  // Revert ea based optimizations for all java threads
>> +  EscapeBarrier(JavaThread* calling_thread, bool barrier_active)
>> +    : _calling_thread(calling_thread), _deoptee_thread(NULL),
>> ```
>> 
>> Nit: would better to make the parameter deoptee_thread to be the 3rd to better mach the seconf constructor.
> 
> I have shuffled the parameters and moved barrier_active at first position. Would
> that be ok?
> 
>> 
>> ```
>> +  bool all_threads()    const { return _deoptee_thread == NULL; }            // Should revert optimizations for all
>> threads. +  bool self_deopt()     const { return _calling_thread == _deoptee_thread; } // Current thread deoptimizes
>> its own objects. +  bool barrier_active() const { return _barrier_active; }                    // Inactive barriers are
>> created if no local objects can escape. ```
>> 
>> I'd suggest to put comments in a line before function definitions as it is done for other declarations/definitions.
> 
> Done. // Note that there are quite a few locations with the comment on the same line ;)
> 
>> src/hotspot/share/runtime/deoptimization.cpp:
>> 
>> ```
>>  @@ -349,12 +408,12 @@
>>  
>>    // Now that the vframeArray has been created if we have any deferred local writes
>>    // added by jvmti then we can free up that structure as the data is now in the
>>    // vframeArray
>>  
>> -  if (thread->deferred_locals() != NULL) {
>> -    GrowableArray<jvmtiDeferredLocalVariableSet*>* list = thread->deferred_locals();
>> +  if (JvmtiDeferredUpdates::deferred_locals(thread) != NULL) {
>> +    GrowableArray<jvmtiDeferredLocalVariableSet*>* list = JvmtiDeferredUpdates::deferred_locals(thread);
>>      int i = 0;
>>      do {
>>        // Because of inlining we could have multiple vframes for a single frame
>>        // and several of the vframes could have deferred writes. Find them all.
>>        if (list->at(i)->id() == array->original().id()) {
>> 
>> @@ -365,13 +424,14 @@
>>        } else {
>>          i++;
>>        }
>>      } while ( i < list->length() );
>>      if (list->length() == 0) {
>> -      thread->set_deferred_locals(NULL);
>> -      // free the list and elements back to C heap.
>> -      delete list;
>> +      JvmtiDeferredUpdates* updates = thread->deferred_updates();
>> +      thread->set_deferred_updates(NULL);
>> +      // free deferred updates.
>> +      delete updates;
>>      }
>> ```
>> 
>> It is not clear why the 'list' is not deleted anymore. If it is intentional then could you, please, add a comment with
>> an explanation?
> 
> 'list' is now embedded in JvmtiDeferredUpdates. It es deleted as part of the
> JvmtiDeferredUpdates instance when there are no more deferred updates.
> 
> class JvmtiDeferredUpdates : public CHeapObj<mtCompiler> {
> 
>   [...]
> 
>   // Deferred updates of locals, expressions, and monitors
>   GrowableArray<jvmtiDeferredLocalVariableSet*> _deferred_locals_updates;
> 
>   [...]
> 
> };
> 
> I introduced JvmtiDeferredUpdates because this patch introduces a new type of
> deferred update: _relock_count_after_wait.
> 
> I tried to improve the encapsulation of class JvmtiDeferredUpdates and
> simplified the location you are referring to.
> 
> So when is memory for deferred updates freed?
> 
> (A) Deferred local variable updates are deleted when the compiled target frame is
>     replaced with corresponding interpreter frames.
>     See JvmtiDeferredUpdates::delete_updates_for_frame().
> 
> (B) A thread's JvmtiDeferredUpdates instance is deleted if all updates where
>     delivered. All updates where delivered when JvmtiDeferredUpdates::count()
>     returns 0. This is checked whenever updates are delivered. See call sites in
>     JvmtiDeferredUpdates::delete_updates_for_frame() and
>     JvmtiDeferredUpdates::get_and_reset_relock_count_after_wait().
> 
> (C) Besides (B) a thread's JvmtiDeferredUpdates instance is also deleted when
>     the thread is destroyed. All not yet delivered updates are deleted then
>     too. See JavaThread::~JavaThread() and JvmtiDeferredUpdates::~JvmtiDeferredUpdates().
> 
>> If you are okay to separate the EscapeBarrier class into its own hpp/cpp files
>> then the class EscapeBarrierSuspendHandshake is better to be colocated with
>> it.
> 
> Done.
> 
>> The below functions EscapeBarrier::sync_and_suspend_one() and do_thread() make a call to the set_obj_deopt_flag() which
>> seems to be a duplication. At least, it is not clear why this duplication exist and so, needs to be explained in a
>> comment.  ```
>> +void EscapeBarrier::sync_and_suspend_one() {
>> +  assert(_calling_thread != NULL, "calling thread must not be NULL");
>> +  assert(_deoptee_thread != NULL, "deoptee thread must not be NULL");
>> +  assert(barrier_active(), "should not call");
>> +
>> +  // Sync with other threads that might be doing deoptimizations
>> +  {
>> +    // Need to switch to _thread_blocked for the wait() call
>> +    ThreadBlockInVM tbivm(_calling_thread);
>> +    MonitorLocker ml(_calling_thread, EscapeBarrier_lock, Mutex::_no_safepoint_check_flag);
>> +    while (_self_deoptimization_in_progress || _deoptee_thread->is_obj_deopt_suspend()) {
>> +      ml.wait();
>> +    }
>> +
>> +    if (self_deopt()) {
>> +      _self_deoptimization_in_progress = true;
>> +      return;
>> +    }
>> +
>> +    // set suspend flag for target thread
>> +    _deoptee_thread->set_obj_deopt_flag();
>> +  }
>> +
>> +  // suspend target thread
>> +  EscapeBarrierSuspendHandshake sh(NULL, "EscapeBarrierSuspendOne");
>> +  Handshake::execute_direct(&sh, _deoptee_thread);
>> +  assert(!_deoptee_thread->has_last_Java_frame() || _deoptee_thread->frame_anchor()->walkable(),
>> +         "stack should be walkable now");
>> +}
>> . . . . .
>> +class EscapeBarrierSuspendHandshake : public HandshakeClosure {
>> +  JavaThread* _excluded_thread;
>> + public:
>> +  EscapeBarrierSuspendHandshake(JavaThread* excluded_thread, const char* name) :
>> +    HandshakeClosure(name),
>> +    _excluded_thread(excluded_thread) {}
>> +  void do_thread(Thread* th) {
>> +    if (th->is_Java_thread() && !th->is_hidden_from_external_view() && (th != _excluded_thread)) {
>> +      th->set_obj_deopt_flag();
>> +    }
>> +  }
>> +};
>> ```
> 
> I previously removed the set_obj_deopt_flag() call from
> EscapeBarrierSuspendHandshake::do_thread() in [1]. For synchronization it is
> better to set_obj_deopt_flag() before the handshake (see comment in
> EscapeBarrier::sync_and_suspend_all()).
> 
> [1] https://github.com/openjdk/jdk/pull/119/commits/18dd54b4e6f17ca723e4ae1a1e8dc57e81878dd3
> 
>> /src/hotspot/share/prims/jvmtiImpl.cpp:
>> 
>> ```
>> 421 // Constructor for non-object getter
>>  422 VM_GetOrSetLocal::VM_GetOrSetLocal(JavaThread* thread, jint depth, jint index, BasicType type)
>>  423   : _thread(thread)
>>  424   , _calling_thread(NULL)
>>  425   , _depth(depth)
>>  426   , _index(index)
>>  427   , _type(type)
>>  428   , _jvf(NULL)
>>  429   , _set(false)
>>  430   , _eb(NULL, NULL, type == T_OBJECT)
>>  431   , _result(JVMTI_ERROR_NONE)
>>  432 {
>>  433 }
>>  434
>>  435 // Constructor for object or non-object setter
>>  436 VM_GetOrSetLocal::VM_GetOrSetLocal(JavaThread* thread, jint depth, jint index, BasicType type, jvalue value)
>>  437   : _thread(thread)
>>  438   , _calling_thread(NULL)
>>  439   , _depth(depth)
>>  440   , _index(index)
>>  441   , _type(type)
>>  442   , _value(value)
>>  443   , _jvf(NULL)
>>  444   , _set(true)
>>  445   , _eb(JavaThread::current(), thread, type == T_OBJECT)
>>  446   , _result(JVMTI_ERROR_NONE)
>>  447 {
>>  448 }
>>  449
>>  450 // Constructor for object getter
>>  451 VM_GetOrSetLocal::VM_GetOrSetLocal(JavaThread* thread, JavaThread* calling_thread, jint depth, int index)
>>  452   : _thread(thread)
>>  453   , _calling_thread(calling_thread)
>>  454   , _depth(depth)
>>  455   , _index(index)
>>  456   , _type(T_OBJECT)
>>  457   , _jvf(NULL)
>>  458   , _set(false)
>>  459   , _eb(calling_thread, thread, true)
>>  460   , _result(JVMTI_ERROR_NONE)
>>  461 {
>>  462 }
>> ```
>> 
>> I think, false has to be passed to the constructors of non-object getters instead of expression:
>> "type == T_OBJECT".
>> The type can not be T_OBJECT for non-object getters.
> 
> I used to do that. Then I changed it because the c++ compiler can fold the
> comparison to "false" and if somebody changes the non-object getter to get
> objects too then it would still be correct.
> 
> Let me know if you still think it is better to pass false. Maybe add an
> assertion type == T_OBJECT then?
> 
>> Q: Is an EscapeBarrier useful if false is passed as the barrier_active parameter?
> 
> The EscapeBarrier is not needed then. In the case of the non-object getter above
> I'd hope that most of the constructor/desctructor of EscapeBarrier is eliminated
> by the c++ compiler then.
> 
> Besides the changes you suggested I have made a bugfix in
> test/jdk/com/sun/jdi/EATests.java to prevent ObjectCollectedException.
> 
> Thanks, Richard.

Hi Serguei
(@sspitsyn)

are you ok with the changes I made based on your comments?
Will you further review the change?

Thanks, Richard.

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

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

From WEIJUN.WANG at ORACLE.COM  Tue Oct  6 14:21:45 2020
From: WEIJUN.WANG at ORACLE.COM (Weijun Wang)
Date: Tue, 6 Oct 2020 10:21:45 -0400
Subject: Request for Discussion: 8253952: Work around wrong usage of
 ZipOutputStream.putNextEntry() in user code
In-Reply-To: <CA+3eh10Tr8NnFaZDfxwq+Pc79AA4XkNOkZpy7epgkExEHw1M5A@mail.gmail.com>
References: <CA+3eh12_-fNxf_KFK68WEqVoD_n6CD7RCbe=LoKCyCeUQ3w0oQ@mail.gmail.com>
 <4658d3a6-3360-fb84-e5ff-20dc6cc61b92@oracle.com>
 <CA+3eh10vr3vs92UPu7PwiaofZpf46QuzsuFf4bvf26gbYKF3-g@mail.gmail.com>
 <99e80b7e-7702-338d-cd92-c9d1a396dfa5@oracle.com>
 <DCBE7C9D-A8CB-4A14-8B79-DEA3BE4B2CA8@ORACLE.COM>
 <CA+3eh125PAxoOAWd+nde4oCnYPOptr=y7arxfRLmy5o0mHpo5g@mail.gmail.com>
 <266D112B-3883-4B6D-886E-1F4CE7641A34@ORACLE.COM>
 <CA+3eh10Tr8NnFaZDfxwq+Pc79AA4XkNOkZpy7epgkExEHw1M5A@mail.gmail.com>
Message-ID: <0DF68377-AD12-423C-AA29-71B0F20F4D25@ORACLE.COM>

Hi Volker,

The size unmatch could throw an exception, but writing an existing ZipEntry into a new ZipOutputStream could have other side effects, including time, comment, and other things we added recently, like POSIX permissions and file type flag (is it a symlink?). Do you meant to copy all these things to the new entry automatically?

Thanks,
Max

> On Oct 6, 2020, at 9:56 AM, Volker Simonis <volker.simonis at gmail.com> wrote:
> 
> On Tue, Oct 6, 2020 at 1:21 PM Lance Andersen <LANCE.ANDERSEN at oracle.com> wrote:
>> 
>> Hi Volker
>> 
>> On Oct 6, 2020, at 6:08 AM, Volker Simonis <volker.simonis at gmail.com> wrote:
>> 
>> On Mon, Oct 5, 2020 at 9:53 PM Lance Andersen <LANCE.ANDERSEN at oracle.com> wrote:
>> 
>> 
>> Hi Volker,
>> 
>> Thank you for looking into this and creating a draft PR.
>> 
>> On the surface, I don?t see a reason to introduce a  System property.  What challenges do you see  if you used the DataDescriptor unless ZipEntry::setCompressedSize is called?  That seems to address the issue that you discovered without having to introduce a new System property. Or is there an additional concern that is not obvious?  This seems like it would address the problem for existing code that is not well behaved.
>> 
>> 
>> Sure. That's obviously the simplest and best solution and I'd be
>> totally happy with it. I just thought there might be a need for
>> somehow preserving the old and buggy behaviour, that's why I added the
>> system property.
>> 
>> I've created a simpler version of the fix without property and
>> adjusted the @apiNote accordingly:
>> 
>> 
>> Thank you for updating your proposal.  We will need to update the javadoc so that the  description of the change is normative and not part of the API note itself.
> 
> Changing the updated doc to be normativ instead of just an @apiNote
> will make it impossible to downport this change but if you think it is
> really necessary I will accept that. I've removed the @apiNote tag
> from the java doc and changed the draft PR into a real PR.
> 
> Without the @apiNote tag I also had to copy the extra documentation
> verbatim to JarOutputStream.putNextEntry() which is not very elegant
> but inheriting the whole api doc from ZipOutputStream didn't seem
> right either. Please let me know if you have a better idea.
> 
> I'll open a CSR once we've agreed on the exact text for the java doc change.
> 
> Please let's continue the discussion on the PR or the new mail that
> was created for it.
> 
> Best regards,
> Volker
> 
>> We will also need to create a CSR for the proposed change in the spec and functionality.  I believe we should also create a release note for this change
>> 
>> Best
>> Lance
>> 
>> 
>> https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/520__;!!GqivPVa7Brio!O7epzMWqwxuS6aPQIllYZLdRTncNGXj5ioqVYY72igGBVGZgUGAHlQnCJ8mhzRoAvw$
>> 
>> Would you be fine with such a solution?
>> 
>> Thank you and best regards,
>> Volker
>> 
>> The other option is to add an additional method to ZipOutputStream or ZipEntry to address the issue.
>> 
>> Thoughts?
>> 
>> Best
>> Lance
>> 
>> On Oct 5, 2020, at 2:13 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>> 
>> On 05/10/2020 11:04, Volker Simonis wrote:
>> 
>> :
>> 
>> I don't
>> think the proposal to add a system property to change the behavior is
>> feasible, at least not without changing the spec but even then it would
>> be very icky.
>> 
>> Why do you think so? The answer to this question is especially
>> important to me because we are considering doing this in our internal
>> version independently of upstream OpenJKD (and potentially also in 8 &
>> 11).
>> 
>> Introducing system properties to change the behavior of APIs and "fix" existing code is really icky. For the main line, then I think it would be good to explore the impact of changing the existing putNextEntry or introducing a new API. The compatibility impact of the former may not be significant but I would expect the spec would be clarified as part of this (that is what I was trying to say above). Exploring new APIs would be good and a method on ZipEntry may not be too bad (you have a reference to the target ZOS in the implementation).
>> 
>> :
>> 
>> And just as a side note, we also use the "jdk.util.zip.inhibitZip64"
>> property in ZipOutputStream for a similar reason. I just wonder how
>> that could pass the CCC process as I couldn't even find any
>> documentation for it :)
>> 
>> ZIP64 was very problematic at the time as it wasn't supported by several tools. The system property was introduced to disable the feature/support so that Java applications didn't create ZIP files that other tools couldn't consume. It would be good to get an up to date picture on ZIP64 support as it might be that this switch can be removed. It pre-dates the CSR  process but there was a CCC at the time.
>> 
>> -Alan
>> 
>> 
>> 
>> Best
>> Lance
>> ------------------
>> 
>> 
>> 
>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
>> Oracle Java Engineering
>> 1 Network Drive
>> Burlington, MA 01803
>> Lance.Andersen at oracle.com
>> 
>> 
>> 
>> Best
>> Lance
>> ------------------
>> 
>> 
>> 
>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
>> Oracle Java Engineering
>> 1 Network Drive
>> Burlington, MA 01803
>> Lance.Andersen at oracle.com
>> 
>> 
>> 
>> 


From volker.simonis at gmail.com  Tue Oct  6 14:44:59 2020
From: volker.simonis at gmail.com (Volker Simonis)
Date: Tue, 6 Oct 2020 16:44:59 +0200
Subject: Request for Discussion: 8253952: Work around wrong usage of
 ZipOutputStream.putNextEntry() in user code
In-Reply-To: <99e80b7e-7702-338d-cd92-c9d1a396dfa5@oracle.com>
References: <CA+3eh12_-fNxf_KFK68WEqVoD_n6CD7RCbe=LoKCyCeUQ3w0oQ@mail.gmail.com>
 <4658d3a6-3360-fb84-e5ff-20dc6cc61b92@oracle.com>
 <CA+3eh10vr3vs92UPu7PwiaofZpf46QuzsuFf4bvf26gbYKF3-g@mail.gmail.com>
 <99e80b7e-7702-338d-cd92-c9d1a396dfa5@oracle.com>
Message-ID: <CA+3eh11g+Pj9pVVLYGF3afgmtDx5qdS3m8D5KGwKWfP8VXO1aQ@mail.gmail.com>

On Mon, Oct 5, 2020 at 8:13 PM Alan Bateman <Alan.Bateman at oracle.com> wrote:
>
> On 05/10/2020 11:04, Volker Simonis wrote:
> > :
> >> I don't
> >> think the proposal to add a system property to change the behavior is
> >> feasible, at least not without changing the spec but even then it would
> >> be very icky.
> > Why do you think so? The answer to this question is especially
> > important to me because we are considering doing this in our internal
> > version independently of upstream OpenJKD (and potentially also in 8 &
> > 11).
> Introducing system properties to change the behavior of APIs and "fix"
> existing code is really icky. For the main line, then I think it would
> be good to explore the impact of changing the existing putNextEntry or
> introducing a new API. The compatibility impact of the former may not be
> significant but I would expect the spec would be clarified as part of
> this (that is what I was trying to say above). Exploring new APIs would
> be good and a method on ZipEntry may not be too bad (you have a
> reference to the target ZOS in the implementation).

Sorry, maybe I'm missing something, but I can't find a single
reference to neither ZipOutput- nor ZipInputStream in the ZipEntry
class.

>
> > :
> >
> > And just as a side note, we also use the "jdk.util.zip.inhibitZip64"
> > property in ZipOutputStream for a similar reason. I just wonder how
> > that could pass the CCC process as I couldn't even find any
> > documentation for it :)
> ZIP64 was very problematic at the time as it wasn't supported by several
> tools. The system property was introduced to disable the feature/support
> so that Java applications didn't create ZIP files that other tools
> couldn't consume. It would be good to get an up to date picture on ZIP64
> support as it might be that this switch can be removed. It pre-dates the
> CSR  process but there was a CCC at the time.
>
> -Alan

From volker.simonis at gmail.com  Tue Oct  6 14:48:23 2020
From: volker.simonis at gmail.com (Volker Simonis)
Date: Tue, 6 Oct 2020 16:48:23 +0200
Subject: Request for Discussion: 8253952: Work around wrong usage of
 ZipOutputStream.putNextEntry() in user code
In-Reply-To: <0DF68377-AD12-423C-AA29-71B0F20F4D25@ORACLE.COM>
References: <CA+3eh12_-fNxf_KFK68WEqVoD_n6CD7RCbe=LoKCyCeUQ3w0oQ@mail.gmail.com>
 <4658d3a6-3360-fb84-e5ff-20dc6cc61b92@oracle.com>
 <CA+3eh10vr3vs92UPu7PwiaofZpf46QuzsuFf4bvf26gbYKF3-g@mail.gmail.com>
 <99e80b7e-7702-338d-cd92-c9d1a396dfa5@oracle.com>
 <DCBE7C9D-A8CB-4A14-8B79-DEA3BE4B2CA8@ORACLE.COM>
 <CA+3eh125PAxoOAWd+nde4oCnYPOptr=y7arxfRLmy5o0mHpo5g@mail.gmail.com>
 <266D112B-3883-4B6D-886E-1F4CE7641A34@ORACLE.COM>
 <CA+3eh10Tr8NnFaZDfxwq+Pc79AA4XkNOkZpy7epgkExEHw1M5A@mail.gmail.com>
 <0DF68377-AD12-423C-AA29-71B0F20F4D25@ORACLE.COM>
Message-ID: <CA+3eh12doGmUHU3=uKrm_U+6ahcBNLQVig9bpPJChDcrd1-b=g@mail.gmail.com>

On Tue, Oct 6, 2020 at 4:21 PM Weijun Wang <WEIJUN.WANG at oracle.com> wrote:
>
> Hi Volker,
>
> The size unmatch could throw an exception, but writing an existing ZipEntry into a new ZipOutputStream could have other side effects, including time, comment, and other things we added recently, like POSIX permissions and file type flag (is it a symlink?). Do you meant to copy all these things to the new entry automatically?
>

Hi Max,

this proposed change is just about fixing the unmatch for the
compressed size attribute. All the other fields will be left
untouched.

Do you see similar problems with other fields which should be
addressed in a similar way or do you just want to make sure that all
the other fields are passed and processed correctly?

Regards,
Volker

> Thanks,
> Max
>
> > On Oct 6, 2020, at 9:56 AM, Volker Simonis <volker.simonis at gmail.com> wrote:
> >
> > On Tue, Oct 6, 2020 at 1:21 PM Lance Andersen <LANCE.ANDERSEN at oracle.com> wrote:
> >>
> >> Hi Volker
> >>
> >> On Oct 6, 2020, at 6:08 AM, Volker Simonis <volker.simonis at gmail.com> wrote:
> >>
> >> On Mon, Oct 5, 2020 at 9:53 PM Lance Andersen <LANCE.ANDERSEN at oracle.com> wrote:
> >>
> >>
> >> Hi Volker,
> >>
> >> Thank you for looking into this and creating a draft PR.
> >>
> >> On the surface, I don?t see a reason to introduce a  System property.  What challenges do you see  if you used the DataDescriptor unless ZipEntry::setCompressedSize is called?  That seems to address the issue that you discovered without having to introduce a new System property. Or is there an additional concern that is not obvious?  This seems like it would address the problem for existing code that is not well behaved.
> >>
> >>
> >> Sure. That's obviously the simplest and best solution and I'd be
> >> totally happy with it. I just thought there might be a need for
> >> somehow preserving the old and buggy behaviour, that's why I added the
> >> system property.
> >>
> >> I've created a simpler version of the fix without property and
> >> adjusted the @apiNote accordingly:
> >>
> >>
> >> Thank you for updating your proposal.  We will need to update the javadoc so that the  description of the change is normative and not part of the API note itself.
> >
> > Changing the updated doc to be normativ instead of just an @apiNote
> > will make it impossible to downport this change but if you think it is
> > really necessary I will accept that. I've removed the @apiNote tag
> > from the java doc and changed the draft PR into a real PR.
> >
> > Without the @apiNote tag I also had to copy the extra documentation
> > verbatim to JarOutputStream.putNextEntry() which is not very elegant
> > but inheriting the whole api doc from ZipOutputStream didn't seem
> > right either. Please let me know if you have a better idea.
> >
> > I'll open a CSR once we've agreed on the exact text for the java doc change.
> >
> > Please let's continue the discussion on the PR or the new mail that
> > was created for it.
> >
> > Best regards,
> > Volker
> >
> >> We will also need to create a CSR for the proposed change in the spec and functionality.  I believe we should also create a release note for this change
> >>
> >> Best
> >> Lance
> >>
> >>
> >> https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/520__;!!GqivPVa7Brio!O7epzMWqwxuS6aPQIllYZLdRTncNGXj5ioqVYY72igGBVGZgUGAHlQnCJ8mhzRoAvw$
> >>
> >> Would you be fine with such a solution?
> >>
> >> Thank you and best regards,
> >> Volker
> >>
> >> The other option is to add an additional method to ZipOutputStream or ZipEntry to address the issue.
> >>
> >> Thoughts?
> >>
> >> Best
> >> Lance
> >>
> >> On Oct 5, 2020, at 2:13 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> >>
> >> On 05/10/2020 11:04, Volker Simonis wrote:
> >>
> >> :
> >>
> >> I don't
> >> think the proposal to add a system property to change the behavior is
> >> feasible, at least not without changing the spec but even then it would
> >> be very icky.
> >>
> >> Why do you think so? The answer to this question is especially
> >> important to me because we are considering doing this in our internal
> >> version independently of upstream OpenJKD (and potentially also in 8 &
> >> 11).
> >>
> >> Introducing system properties to change the behavior of APIs and "fix" existing code is really icky. For the main line, then I think it would be good to explore the impact of changing the existing putNextEntry or introducing a new API. The compatibility impact of the former may not be significant but I would expect the spec would be clarified as part of this (that is what I was trying to say above). Exploring new APIs would be good and a method on ZipEntry may not be too bad (you have a reference to the target ZOS in the implementation).
> >>
> >> :
> >>
> >> And just as a side note, we also use the "jdk.util.zip.inhibitZip64"
> >> property in ZipOutputStream for a similar reason. I just wonder how
> >> that could pass the CCC process as I couldn't even find any
> >> documentation for it :)
> >>
> >> ZIP64 was very problematic at the time as it wasn't supported by several tools. The system property was introduced to disable the feature/support so that Java applications didn't create ZIP files that other tools couldn't consume. It would be good to get an up to date picture on ZIP64 support as it might be that this switch can be removed. It pre-dates the CSR  process but there was a CCC at the time.
> >>
> >> -Alan
> >>
> >>
> >>
> >> Best
> >> Lance
> >> ------------------
> >>
> >>
> >>
> >> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
> >> Oracle Java Engineering
> >> 1 Network Drive
> >> Burlington, MA 01803
> >> Lance.Andersen at oracle.com
> >>
> >>
> >>
> >> Best
> >> Lance
> >> ------------------
> >>
> >>
> >>
> >> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
> >> Oracle Java Engineering
> >> 1 Network Drive
> >> Burlington, MA 01803
> >> Lance.Andersen at oracle.com
> >>
> >>
> >>
> >>
>

From Roger.Riggs at oracle.com  Tue Oct  6 15:01:22 2020
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Tue, 6 Oct 2020 11:01:22 -0400
Subject: [PATCH] AbstractStringBuilder.insert(int dstOffset, CharSequence
 s, int start, int end) is missing fast-path for String
In-Reply-To: <279111601034428@mail.yandex.ru>
References: <279111601034428@mail.yandex.ru>
Message-ID: <dc74598f-43d2-10a4-76e6-3dfd4f2db52a@oracle.com>

Hi Sergey,

Your request can be tracked with the Jira issue:
 ?? https://bugs.openjdk.java.net/browse/JDK-8254082

Please follow the directions for How to Contribute under "Become a 
Contributor".
 ?? https://openjdk.java.net/contribute/

When you get to creating the PR, please include the JMH 
test/micro/org/openjdk/bench/java/lang.

Regards, Roger


On 9/25/20 10:08 AM, ?????? ??????? wrote:
> Hello,
>
> while working with StringBuilder.insert() I've spotted that its delegate AbstractStringBuilder.insert() is missing
> a fast-path for the most frequent case when its argument is String.
>
> Previously they did similart optimization for StirngBuilder.append(CharSequence, int, int),
> see https://bugs.openjdk.java.net/browse/JDK-8224986
>
> I'd like to contribute a trivial patch that brings improvement for the case when SB's content is Latin1
> and inserted String is Latin1 as well. I cannot file the issue for that so can I create a PR on GitHub without issue number?
> If not please create one (if the change is relevant of course).
>
> To measure improvement I've used simple benchmark:
>
> @BenchmarkMode(Mode.AverageTime)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"})
> public class StringBuilderInsertBenchmark {
>
>    @Benchmark
>    public StringBuilder insert(Data data) {
>      String string = data.string;
>      return new StringBuilder().append("ABC").insert(1, string, 1, data.length + 1);
>    }
>
>    @State(Scope.Thread)
>    public static class Data {
>      String string;
>
>      @Param({"true", "false"})
>      private boolean latin;
>
>      @Param({"8", "64", "128", "1024"})
>      private int length;
>
>      @Setup
>      public void setup() {
>        String alphabet = latin
>          ? "abcdefghijklmnopqrstuvwxyz"        // English
>          : "????????????????????????????????"; // Russian
>
>        string = new RandomStringGenerator().randomString(alphabet, length + 2);
>      }
>    }
> }
>
> Which gives
>
>              (latin)  (length)       original       patched    Units
>
> insert         true         8    24.2 ?  0.1   22.2 ?  0.0    ns/op
> insert         true        64    53.8 ?  0.2   36.1 ?  0.1    ns/op
> insert         true       128    80.9 ?  0.2   44.6 ?  0.0    ns/op
> insert         true      1024   365.4 ?  0.5  109.8 ?  3.9    ns/op
>
> insert        false         8    33.5 ?  0.5   32.3 ?  0.2    ns/op
> insert        false        64    73.2 ?  0.3   73.2 ?  0.2    ns/op
> insert        false       128   103.9 ?  0.6  103.3 ?  0.1    ns/op
> insert        false      1024   576.5 ?  4.8  569.5 ?  2.0    ns/op
>
> Patch is attached. As of tests tier1 and tier2 are ok
>
> With best regards,
> Sergey Tsypanov


From igraves at openjdk.java.net  Tue Oct  6 15:09:15 2020
From: igraves at openjdk.java.net (Ian Graves)
Date: Tue, 6 Oct 2020 15:09:15 GMT
Subject: RFR: 8254080: fix for JDK-8204256 causes jlink test failures
Message-ID: <aw25t8lnWxxPxewmSMcGMyHQPSPgRJ42kg5RRcXrc7A=.94861fd7-a582-4cae-bfe7-c56e01e8f93d@github.com>

This commit fixes an incorrect resource name from the fix for JDK-8204256

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

Commit messages:
 - Fixing incorrect resource name

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

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

From rriggs at openjdk.java.net  Tue Oct  6 15:16:11 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 6 Oct 2020 15:16:11 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v2]
In-Reply-To: <jUYJaiGKl3ktWaYGsPH8p_Nd38t8I5AtdKtaVaDJcR0=.e8417e8d-91b5-41f3-af81-6e485167bd44@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <6P-wrlA7c9wlXEhcoAYW5J9W2jwTmTTj3PkDObPh0LA=.c11aa048-8853-4e1c-a689-c34b89c15f12@github.com>
 <T48t-_XIiM_NlSZau6pj9hjSxp--n9pktxI6XCZ-W8k=.54c779af-e1af-4e62-9e4f-48ed7145bfc9@github.com>
 <jUYJaiGKl3ktWaYGsPH8p_Nd38t8I5AtdKtaVaDJcR0=.e8417e8d-91b5-41f3-af81-6e485167bd44@github.com>
Message-ID: <qv0XG1izvRxgj90kajyp1XhQvt7gIuPtZdrbTVkAeLY=.6daf3496-e70e-47a7-a6d0-61127b9ec649@github.com>

On Mon, 5 Oct 2020 21:45:06 GMT, CoreyAshford <github.com+51754783+CoreyAshford at openjdk.org> wrote:

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

fyi, there is no need to do a rebase.  The preferred way is to do a merge.
When the changes are integrated, all of the individual commits are squashed to create a single commit.

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

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

From alanb at openjdk.java.net  Tue Oct  6 15:17:07 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 6 Oct 2020 15:17:07 GMT
Subject: RFR: 8254080: fix for JDK-8204256 causes jlink test failures
In-Reply-To: <aw25t8lnWxxPxewmSMcGMyHQPSPgRJ42kg5RRcXrc7A=.94861fd7-a582-4cae-bfe7-c56e01e8f93d@github.com>
References: <aw25t8lnWxxPxewmSMcGMyHQPSPgRJ42kg5RRcXrc7A=.94861fd7-a582-4cae-bfe7-c56e01e8f93d@github.com>
Message-ID: <kSwHz7KGz30SBkiaAAGAUoZbtPmX3mymGIbC-gs5ZlY=.862fca66-e15c-4be4-973a-03235aed488a@github.com>

On Tue, 6 Oct 2020 15:04:48 GMT, Ian Graves <igraves at openjdk.org> wrote:

> This commit fixes an incorrect resource name from the fix for JDK-8204256

Marked as reviewed by alanb (Reviewer).

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

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

From igraves at openjdk.java.net  Tue Oct  6 15:26:12 2020
From: igraves at openjdk.java.net (Ian Graves)
Date: Tue, 6 Oct 2020 15:26:12 GMT
Subject: Integrated: 8254080: fix for JDK-8204256 causes jlink test failures
In-Reply-To: <aw25t8lnWxxPxewmSMcGMyHQPSPgRJ42kg5RRcXrc7A=.94861fd7-a582-4cae-bfe7-c56e01e8f93d@github.com>
References: <aw25t8lnWxxPxewmSMcGMyHQPSPgRJ42kg5RRcXrc7A=.94861fd7-a582-4cae-bfe7-c56e01e8f93d@github.com>
Message-ID: <ao_DuGtDe9O4pmAoH9u0DbPXPiomvX7GjyH3Np2SmF4=.a360b0d0-1d6e-4f41-8f7b-37420720a311@github.com>

On Tue, 6 Oct 2020 15:04:48 GMT, Ian Graves <igraves at openjdk.org> wrote:

> This commit fixes an incorrect resource name from the fix for JDK-8204256

This pull request has now been integrated.

Changeset: 77921b97
Author:    Ian Graves <igraves at openjdk.org>
Committer: Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/77921b97
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8254080: fix for JDK-8204256 causes jlink test failures

Reviewed-by: alanb

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

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

From minqi at openjdk.java.net  Tue Oct  6 15:32:23 2020
From: minqi at openjdk.java.net (Yumin Qi)
Date: Tue, 6 Oct 2020 15:32:23 GMT
Subject: RFR: 8247536: Support for pre-generated java.lang.invoke classes
 in CDS static archive [v10]
In-Reply-To: <Y_Bas-poGnDtvcJbqbmeIAPQRNxzvarBToQWALn9TTE=.e846cd3c-0e7b-48d3-8ffa-be3c03acffb0@github.com>
References: <Y_Bas-poGnDtvcJbqbmeIAPQRNxzvarBToQWALn9TTE=.e846cd3c-0e7b-48d3-8ffa-be3c03acffb0@github.com>
Message-ID: <2MoJTYvZmY9SqzULTgd67lvOwsUoGKp7AuK7hkx6_T4=.998d347b-c887-4f86-93f3-cd36a84088dc@github.com>

> This patch is reorganized after 8252725, which is separated from this patch to refactor jlink glugin code. The previous
> webrev with hg can be found at: http://cr.openjdk.java.net/~minqi/2020/8247536/webrev-05. With 8252725 integrated, the
> regeneration of holder classes is simply to call the new added GenerateJLIClassesHelper.cdsGenerateHolderClasses
> function.  Tests: tier1-4

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

  Fixed comments with correct class and method name in CDS, removed unused variables after last change.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/193/files
  - new: https://git.openjdk.java.net/jdk/pull/193/files/52764a6e..686e211b

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

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

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

From WEIJUN.WANG at ORACLE.COM  Tue Oct  6 15:42:14 2020
From: WEIJUN.WANG at ORACLE.COM (Weijun Wang)
Date: Tue, 6 Oct 2020 11:42:14 -0400
Subject: Request for Discussion: 8253952: Work around wrong usage of
 ZipOutputStream.putNextEntry() in user code
In-Reply-To: <CA+3eh12doGmUHU3=uKrm_U+6ahcBNLQVig9bpPJChDcrd1-b=g@mail.gmail.com>
References: <CA+3eh12_-fNxf_KFK68WEqVoD_n6CD7RCbe=LoKCyCeUQ3w0oQ@mail.gmail.com>
 <4658d3a6-3360-fb84-e5ff-20dc6cc61b92@oracle.com>
 <CA+3eh10vr3vs92UPu7PwiaofZpf46QuzsuFf4bvf26gbYKF3-g@mail.gmail.com>
 <99e80b7e-7702-338d-cd92-c9d1a396dfa5@oracle.com>
 <DCBE7C9D-A8CB-4A14-8B79-DEA3BE4B2CA8@ORACLE.COM>
 <CA+3eh125PAxoOAWd+nde4oCnYPOptr=y7arxfRLmy5o0mHpo5g@mail.gmail.com>
 <266D112B-3883-4B6D-886E-1F4CE7641A34@ORACLE.COM>
 <CA+3eh10Tr8NnFaZDfxwq+Pc79AA4XkNOkZpy7epgkExEHw1M5A@mail.gmail.com>
 <0DF68377-AD12-423C-AA29-71B0F20F4D25@ORACLE.COM>
 <CA+3eh12doGmUHU3=uKrm_U+6ahcBNLQVig9bpPJChDcrd1-b=g@mail.gmail.com>
Message-ID: <078C7AC7-7B93-4ACF-A6ED-80087CB0E18E@ORACLE.COM>



> On Oct 6, 2020, at 10:48 AM, Volker Simonis <volker.simonis at gmail.com> wrote:
> 
> On Tue, Oct 6, 2020 at 4:21 PM Weijun Wang <WEIJUN.WANG at oracle.com> wrote:
>> 
>> Hi Volker,
>> 
>> The size unmatch could throw an exception, but writing an existing ZipEntry into a new ZipOutputStream could have other side effects, including time, comment, and other things we added recently, like POSIX permissions and file type flag (is it a symlink?). Do you meant to copy all these things to the new entry automatically?
>> 
> 
> Hi Max,
> 
> this proposed change is just about fixing the unmatch for the
> compressed size attribute. All the other fields will be left
> untouched.
> 
> Do you see similar problems with other fields which should be
> addressed in a similar way or do you just want to make sure that all
> the other fields are passed and processed correctly?

No.

I was just saying your code change could encourage more people to use the bad code pattern and it might have other unexpected behaviors. Even the zip command requires this or that option to copy certain attributes. For example, should symlinks always be copied as symlinks?

Thanks,
Max

> 
> Regards,
> Volker
> 
>> Thanks,
>> Max
>> 
>>> On Oct 6, 2020, at 9:56 AM, Volker Simonis <volker.simonis at gmail.com> wrote:
>>> 
>>> On Tue, Oct 6, 2020 at 1:21 PM Lance Andersen <LANCE.ANDERSEN at oracle.com> wrote:
>>>> 
>>>> Hi Volker
>>>> 
>>>> On Oct 6, 2020, at 6:08 AM, Volker Simonis <volker.simonis at gmail.com> wrote:
>>>> 
>>>> On Mon, Oct 5, 2020 at 9:53 PM Lance Andersen <LANCE.ANDERSEN at oracle.com> wrote:
>>>> 
>>>> 
>>>> Hi Volker,
>>>> 
>>>> Thank you for looking into this and creating a draft PR.
>>>> 
>>>> On the surface, I don?t see a reason to introduce a  System property.  What challenges do you see  if you used the DataDescriptor unless ZipEntry::setCompressedSize is called?  That seems to address the issue that you discovered without having to introduce a new System property. Or is there an additional concern that is not obvious?  This seems like it would address the problem for existing code that is not well behaved.
>>>> 
>>>> 
>>>> Sure. That's obviously the simplest and best solution and I'd be
>>>> totally happy with it. I just thought there might be a need for
>>>> somehow preserving the old and buggy behaviour, that's why I added the
>>>> system property.
>>>> 
>>>> I've created a simpler version of the fix without property and
>>>> adjusted the @apiNote accordingly:
>>>> 
>>>> 
>>>> Thank you for updating your proposal.  We will need to update the javadoc so that the  description of the change is normative and not part of the API note itself.
>>> 
>>> Changing the updated doc to be normativ instead of just an @apiNote
>>> will make it impossible to downport this change but if you think it is
>>> really necessary I will accept that. I've removed the @apiNote tag
>>> from the java doc and changed the draft PR into a real PR.
>>> 
>>> Without the @apiNote tag I also had to copy the extra documentation
>>> verbatim to JarOutputStream.putNextEntry() which is not very elegant
>>> but inheriting the whole api doc from ZipOutputStream didn't seem
>>> right either. Please let me know if you have a better idea.
>>> 
>>> I'll open a CSR once we've agreed on the exact text for the java doc change.
>>> 
>>> Please let's continue the discussion on the PR or the new mail that
>>> was created for it.
>>> 
>>> Best regards,
>>> Volker
>>> 
>>>> We will also need to create a CSR for the proposed change in the spec and functionality.  I believe we should also create a release note for this change
>>>> 
>>>> Best
>>>> Lance
>>>> 
>>>> 
>>>> https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/520__;!!GqivPVa7Brio!O7epzMWqwxuS6aPQIllYZLdRTncNGXj5ioqVYY72igGBVGZgUGAHlQnCJ8mhzRoAvw$
>>>> 
>>>> Would you be fine with such a solution?
>>>> 
>>>> Thank you and best regards,
>>>> Volker
>>>> 
>>>> The other option is to add an additional method to ZipOutputStream or ZipEntry to address the issue.
>>>> 
>>>> Thoughts?
>>>> 
>>>> Best
>>>> Lance
>>>> 
>>>> On Oct 5, 2020, at 2:13 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>>>> 
>>>> On 05/10/2020 11:04, Volker Simonis wrote:
>>>> 
>>>> :
>>>> 
>>>> I don't
>>>> think the proposal to add a system property to change the behavior is
>>>> feasible, at least not without changing the spec but even then it would
>>>> be very icky.
>>>> 
>>>> Why do you think so? The answer to this question is especially
>>>> important to me because we are considering doing this in our internal
>>>> version independently of upstream OpenJKD (and potentially also in 8 &
>>>> 11).
>>>> 
>>>> Introducing system properties to change the behavior of APIs and "fix" existing code is really icky. For the main line, then I think it would be good to explore the impact of changing the existing putNextEntry or introducing a new API. The compatibility impact of the former may not be significant but I would expect the spec would be clarified as part of this (that is what I was trying to say above). Exploring new APIs would be good and a method on ZipEntry may not be too bad (you have a reference to the target ZOS in the implementation).
>>>> 
>>>> :
>>>> 
>>>> And just as a side note, we also use the "jdk.util.zip.inhibitZip64"
>>>> property in ZipOutputStream for a similar reason. I just wonder how
>>>> that could pass the CCC process as I couldn't even find any
>>>> documentation for it :)
>>>> 
>>>> ZIP64 was very problematic at the time as it wasn't supported by several tools. The system property was introduced to disable the feature/support so that Java applications didn't create ZIP files that other tools couldn't consume. It would be good to get an up to date picture on ZIP64 support as it might be that this switch can be removed. It pre-dates the CSR  process but there was a CCC at the time.
>>>> 
>>>> -Alan
>>>> 
>>>> 
>>>> 
>>>> Best
>>>> Lance
>>>> ------------------
>>>> 
>>>> 
>>>> 
>>>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
>>>> Oracle Java Engineering
>>>> 1 Network Drive
>>>> Burlington, MA 01803
>>>> Lance.Andersen at oracle.com
>>>> 
>>>> 
>>>> 
>>>> Best
>>>> Lance
>>>> ------------------
>>>> 
>>>> 
>>>> 
>>>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
>>>> Oracle Java Engineering
>>>> 1 Network Drive
>>>> Burlington, MA 01803
>>>> Lance.Andersen at oracle.com
>>>> 
>>>> 
>>>> 
>>>> 
>> 


From github.com+70893615+jasontatton-aws at openjdk.java.net  Tue Oct  6 15:46:12 2020
From: github.com+70893615+jasontatton-aws at openjdk.java.net (Jason Tatton)
Date: Tue, 6 Oct 2020 15:46:12 GMT
Subject: RFR: 8173585: Intrinsify StringLatin1.indexOf(char) [v2]
In-Reply-To: <ek__ufm173KBifOKT3E9NbWnO52ln-Gw2H4AtARIBno=.0eff465e-63db-4644-acb1-b6d6645ecfed@github.com>
References: <_T0873dC5tfUtGn9r1_Y21JkPKRt-za3MM9hPN2GQKQ=.b865fe53-5417-424f-81b6-1566a330640e@github.com>
 <-DRWR4_f5u6DsSGHAuPnpHrhaG8Una8BXf4zDekQjLM=.469b08b6-a8b2-4a6b-8ab8-1a40810aede0@github.com>
 <qoapFFx0wHJf23lRFgOirJacVFNjLIEaMK04qDMq4lE=.1fc3c70d-0fb1-4133-8965-5a517ba39f9e@github.com>
 <ek__ufm173KBifOKT3E9NbWnO52ln-Gw2H4AtARIBno=.0eff465e-63db-4644-acb1-b6d6645ecfed@github.com>
Message-ID: <plPokgNN9W9Q1jP659Cc0MnzadETTZPiEP28uv9AIMw=.001a59cd-da6d-47f8-8697-bea15f3af2cb@github.com>

On Fri, 2 Oct 2020 08:44:48 GMT, Jason Tatton <github.com+70893615+jasontatton-aws at openjdk.org> wrote:

>> Hi Jason,
>> 
>> thanks for bringing String.indexOf() for latin strings up to date with the Unicode version.
>> 
>> Your changes look good except a few minor issues I've commented on right in the code.
>> 
>> I'd only like to ask you if you could possibly improve your test a little bit. As far as I understand, your search text
>> is a consecutive sequence of "abc" characters, so you'll always find the character your searching for within the next
>> three characters of the source text. This won't exercise the loops of your intrinsic. Maybe you can also add some test
>> versions where the search character will be found beyond the first 32/64 characters after "fromIndex"?
>
> @simonis Thank you for the corrections, I have ammended them in the latest comit as follows:
> 
> Changes to unit test:
> - main test adjusted such that Strings gennerated are much longer (up to 2048 characters) and of the form: `azaza`,
>   `aazaazaa`, `aaazaaazaaa`, etc with `'z'` being the search character searched for. Multiple instances of the search
>   character are included in the String in order to validate that the starting offset is correctly handleded. Results are
>   compared to non intrinsified version of the code. Longer strings means that the looping functionality of the various
>   paths is entered into.
> - Run configurations introduced such that it checks behaviour where use of SSE and AVX instructions are restricted.
> - Tier4InvocationThreshold adjusted so as to ensure C2 code iis invoked.
> 
> Other changes:
> - newlines added at end of files
> 
> @vnkozlov here are the performance numbers as requested. I have included performance of the UTF16 version of the
> intrinsic for reference:
> | UseAVX= | UseSSE= | Benchmark                         | Mode | Cnt | Score       | Error       | Units |
> |---------|---------|-----------------------------------|------|-----|-------------|-------------|-------|
> |         | 0       | IndexOfBenchmark.latin1_long_char | avgt | 5   | **447,493.398** | ? 4,666.386 | ns/op |
> | 0       |         | IndexOfBenchmark.latin1_long_char | avgt | 5   | **104,735.941** | ? 2,484.403 | ns/op |
> | 1       |         | IndexOfBenchmark.latin1_long_char | avgt | 5   | **104,342.844** | ? 2,656.343 | ns/op |
> | 2       |         | IndexOfBenchmark.latin1_long_char | avgt | 5   | **61,000.418**  | ? 1,543.951 | ns/op |
> | 3       |         | IndexOfBenchmark.latin1_long_char | avgt | 5   | **60,607.988**  | ? 1,466.354 | ns/op |
> |         | 0       | IndexOfBenchmark.utf16_long_char  | avgt | 5   | 672,475.302 | ? 4,998.596 | ns/op |
> | 0       |         | IndexOfBenchmark.utf16_long_char  | avgt | 5   | 175,521.654 | ? 7,549.094 | ns/op |
> | 1       |         | IndexOfBenchmark.utf16_long_char  | avgt | 5   | 172,514.981 | ? 3,561.040 | ns/op |
> | 2       |         | IndexOfBenchmark.utf16_long_char  | avgt | 5   | 120,725.748 | ? 2,004.400 | ns/op |
> | 3       |         | IndexOfBenchmark.utf16_long_char  | avgt | 5   | 120,664.623 | ? 1,988.419 | ns/op |
> 
> I think the results are as expected, we see improvements in performance as the range of SSE and AVX instructions which
> can be used is expanded upon. Note that no improvement is observed with UseAVX=3 because there is no AVX-512 code in
> these intrinsics.

Hi All,

Just wondering if there is anything you'd like me to do in order to assist with moving this patch forward?

Thanks,
Jason

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

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

From WEIJUN.WANG at ORACLE.COM  Tue Oct  6 16:00:41 2020
From: WEIJUN.WANG at ORACLE.COM (Weijun Wang)
Date: Tue, 6 Oct 2020 12:00:41 -0400
Subject: Request for Discussion: 8253952: Work around wrong usage of
 ZipOutputStream.putNextEntry() in user code
In-Reply-To: <078C7AC7-7B93-4ACF-A6ED-80087CB0E18E@ORACLE.COM>
References: <CA+3eh12_-fNxf_KFK68WEqVoD_n6CD7RCbe=LoKCyCeUQ3w0oQ@mail.gmail.com>
 <4658d3a6-3360-fb84-e5ff-20dc6cc61b92@oracle.com>
 <CA+3eh10vr3vs92UPu7PwiaofZpf46QuzsuFf4bvf26gbYKF3-g@mail.gmail.com>
 <99e80b7e-7702-338d-cd92-c9d1a396dfa5@oracle.com>
 <DCBE7C9D-A8CB-4A14-8B79-DEA3BE4B2CA8@ORACLE.COM>
 <CA+3eh125PAxoOAWd+nde4oCnYPOptr=y7arxfRLmy5o0mHpo5g@mail.gmail.com>
 <266D112B-3883-4B6D-886E-1F4CE7641A34@ORACLE.COM>
 <CA+3eh10Tr8NnFaZDfxwq+Pc79AA4XkNOkZpy7epgkExEHw1M5A@mail.gmail.com>
 <0DF68377-AD12-423C-AA29-71B0F20F4D25@ORACLE.COM>
 <CA+3eh12doGmUHU3=uKrm_U+6ahcBNLQVig9bpPJChDcrd1-b=g@mail.gmail.com>
 <078C7AC7-7B93-4ACF-A6ED-80087CB0E18E@ORACLE.COM>
Message-ID: <BD045667-852F-4CC0-9B1B-0CCDA856B63B@ORACLE.COM>



> On Oct 6, 2020, at 11:42 AM, Weijun Wang <WEIJUN.WANG at ORACLE.COM> wrote:
> 
> 
> 
>> On Oct 6, 2020, at 10:48 AM, Volker Simonis <volker.simonis at gmail.com> wrote:
>> 
>> On Tue, Oct 6, 2020 at 4:21 PM Weijun Wang <WEIJUN.WANG at oracle.com> wrote:
>>> 
>>> Hi Volker,
>>> 
>>> The size unmatch could throw an exception, but writing an existing ZipEntry into a new ZipOutputStream could have other side effects, including time, comment, and other things we added recently, like POSIX permissions and file type flag (is it a symlink?). Do you meant to copy all these things to the new entry automatically?
>>> 
>> 
>> Hi Max,
>> 
>> this proposed change is just about fixing the unmatch for the
>> compressed size attribute. All the other fields will be left
>> untouched.
>> 
>> Do you see similar problems with other fields which should be
>> addressed in a similar way or do you just want to make sure that all
>> the other fields are passed and processed correctly?
> 
> No.
> 
> I was just saying your code change could encourage more people to use the bad code pattern and it might have other unexpected behaviors. Even the zip command requires this or that option to copy certain attributes. For example, should symlinks always be copied as symlinks?

Sorry, my comparison is not precise. The zip tool is adding files to a zip but your code change is about copying existing zip entries.

Still, I wish people are aware that other attributes are copied as well, and they could be different from version to vesion.

Thanks,
Max

> 
> Thanks,
> Max
> 
>> 
>> Regards,
>> Volker
>> 
>>> Thanks,
>>> Max
>>> 
>>>> On Oct 6, 2020, at 9:56 AM, Volker Simonis <volker.simonis at gmail.com> wrote:
>>>> 
>>>> On Tue, Oct 6, 2020 at 1:21 PM Lance Andersen <LANCE.ANDERSEN at oracle.com> wrote:
>>>>> 
>>>>> Hi Volker
>>>>> 
>>>>> On Oct 6, 2020, at 6:08 AM, Volker Simonis <volker.simonis at gmail.com> wrote:
>>>>> 
>>>>> On Mon, Oct 5, 2020 at 9:53 PM Lance Andersen <LANCE.ANDERSEN at oracle.com> wrote:
>>>>> 
>>>>> 
>>>>> Hi Volker,
>>>>> 
>>>>> Thank you for looking into this and creating a draft PR.
>>>>> 
>>>>> On the surface, I don?t see a reason to introduce a  System property.  What challenges do you see  if you used the DataDescriptor unless ZipEntry::setCompressedSize is called?  That seems to address the issue that you discovered without having to introduce a new System property. Or is there an additional concern that is not obvious?  This seems like it would address the problem for existing code that is not well behaved.
>>>>> 
>>>>> 
>>>>> Sure. That's obviously the simplest and best solution and I'd be
>>>>> totally happy with it. I just thought there might be a need for
>>>>> somehow preserving the old and buggy behaviour, that's why I added the
>>>>> system property.
>>>>> 
>>>>> I've created a simpler version of the fix without property and
>>>>> adjusted the @apiNote accordingly:
>>>>> 
>>>>> 
>>>>> Thank you for updating your proposal.  We will need to update the javadoc so that the  description of the change is normative and not part of the API note itself.
>>>> 
>>>> Changing the updated doc to be normativ instead of just an @apiNote
>>>> will make it impossible to downport this change but if you think it is
>>>> really necessary I will accept that. I've removed the @apiNote tag
>>>> from the java doc and changed the draft PR into a real PR.
>>>> 
>>>> Without the @apiNote tag I also had to copy the extra documentation
>>>> verbatim to JarOutputStream.putNextEntry() which is not very elegant
>>>> but inheriting the whole api doc from ZipOutputStream didn't seem
>>>> right either. Please let me know if you have a better idea.
>>>> 
>>>> I'll open a CSR once we've agreed on the exact text for the java doc change.
>>>> 
>>>> Please let's continue the discussion on the PR or the new mail that
>>>> was created for it.
>>>> 
>>>> Best regards,
>>>> Volker
>>>> 
>>>>> We will also need to create a CSR for the proposed change in the spec and functionality.  I believe we should also create a release note for this change
>>>>> 
>>>>> Best
>>>>> Lance
>>>>> 
>>>>> 
>>>>> https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/520__;!!GqivPVa7Brio!O7epzMWqwxuS6aPQIllYZLdRTncNGXj5ioqVYY72igGBVGZgUGAHlQnCJ8mhzRoAvw$
>>>>> 
>>>>> Would you be fine with such a solution?
>>>>> 
>>>>> Thank you and best regards,
>>>>> Volker
>>>>> 
>>>>> The other option is to add an additional method to ZipOutputStream or ZipEntry to address the issue.
>>>>> 
>>>>> Thoughts?
>>>>> 
>>>>> Best
>>>>> Lance
>>>>> 
>>>>> On Oct 5, 2020, at 2:13 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>>>>> 
>>>>> On 05/10/2020 11:04, Volker Simonis wrote:
>>>>> 
>>>>> :
>>>>> 
>>>>> I don't
>>>>> think the proposal to add a system property to change the behavior is
>>>>> feasible, at least not without changing the spec but even then it would
>>>>> be very icky.
>>>>> 
>>>>> Why do you think so? The answer to this question is especially
>>>>> important to me because we are considering doing this in our internal
>>>>> version independently of upstream OpenJKD (and potentially also in 8 &
>>>>> 11).
>>>>> 
>>>>> Introducing system properties to change the behavior of APIs and "fix" existing code is really icky. For the main line, then I think it would be good to explore the impact of changing the existing putNextEntry or introducing a new API. The compatibility impact of the former may not be significant but I would expect the spec would be clarified as part of this (that is what I was trying to say above). Exploring new APIs would be good and a method on ZipEntry may not be too bad (you have a reference to the target ZOS in the implementation).
>>>>> 
>>>>> :
>>>>> 
>>>>> And just as a side note, we also use the "jdk.util.zip.inhibitZip64"
>>>>> property in ZipOutputStream for a similar reason. I just wonder how
>>>>> that could pass the CCC process as I couldn't even find any
>>>>> documentation for it :)
>>>>> 
>>>>> ZIP64 was very problematic at the time as it wasn't supported by several tools. The system property was introduced to disable the feature/support so that Java applications didn't create ZIP files that other tools couldn't consume. It would be good to get an up to date picture on ZIP64 support as it might be that this switch can be removed. It pre-dates the CSR  process but there was a CCC at the time.
>>>>> 
>>>>> -Alan
>>>>> 
>>>>> 
>>>>> 
>>>>> Best
>>>>> Lance
>>>>> ------------------
>>>>> 
>>>>> 
>>>>> 
>>>>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
>>>>> Oracle Java Engineering
>>>>> 1 Network Drive
>>>>> Burlington, MA 01803
>>>>> Lance.Andersen at oracle.com
>>>>> 
>>>>> 
>>>>> 
>>>>> Best
>>>>> Lance
>>>>> ------------------
>>>>> 
>>>>> 
>>>>> 
>>>>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
>>>>> Oracle Java Engineering
>>>>> 1 Network Drive
>>>>> Burlington, MA 01803
>>>>> Lance.Andersen at oracle.com


From minqi at openjdk.java.net  Tue Oct  6 17:35:18 2020
From: minqi at openjdk.java.net (Yumin Qi)
Date: Tue, 6 Oct 2020 17:35:18 GMT
Subject: RFR: 8247536: Support for pre-generated java.lang.invoke classes
 in CDS static archive [v11]
In-Reply-To: <Y_Bas-poGnDtvcJbqbmeIAPQRNxzvarBToQWALn9TTE=.e846cd3c-0e7b-48d3-8ffa-be3c03acffb0@github.com>
References: <Y_Bas-poGnDtvcJbqbmeIAPQRNxzvarBToQWALn9TTE=.e846cd3c-0e7b-48d3-8ffa-be3c03acffb0@github.com>
Message-ID: <fnlaWkwge3SaOu_A427Z-rRlIwxo4n90jXaZan089Hk=.3821150a-9608-4dcf-8284-aa951eed1077@github.com>

> This patch is reorganized after 8252725, which is separated from this patch to refactor jlink glugin code. The previous
> webrev with hg can be found at: http://cr.openjdk.java.net/~minqi/2020/8247536/webrev-05. With 8252725 integrated, the
> regeneration of holder classes is simply to call the new added GenerateJLIClassesHelper.cdsGenerateHolderClasses
> function.  Tests: tier1-4

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

  Removed unused imports.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/193/files
  - new: https://git.openjdk.java.net/jdk/pull/193/files/686e211b..5d32a547

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

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

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

From github.com+51754783+coreyashford at openjdk.java.net  Tue Oct  6 17:45:08 2020
From: github.com+51754783+coreyashford at openjdk.java.net (CoreyAshford)
Date: Tue, 6 Oct 2020 17:45:08 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v2]
In-Reply-To: <qv0XG1izvRxgj90kajyp1XhQvt7gIuPtZdrbTVkAeLY=.6daf3496-e70e-47a7-a6d0-61127b9ec649@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <6P-wrlA7c9wlXEhcoAYW5J9W2jwTmTTj3PkDObPh0LA=.c11aa048-8853-4e1c-a689-c34b89c15f12@github.com>
 <T48t-_XIiM_NlSZau6pj9hjSxp--n9pktxI6XCZ-W8k=.54c779af-e1af-4e62-9e4f-48ed7145bfc9@github.com>
 <jUYJaiGKl3ktWaYGsPH8p_Nd38t8I5AtdKtaVaDJcR0=.e8417e8d-91b5-41f3-af81-6e485167bd44@github.com>
 <qv0XG1izvRxgj90kajyp1XhQvt7gIuPtZdrbTVkAeLY=.6daf3496-e70e-47a7-a6d0-61127b9ec649@github.com>
Message-ID: <FV7h5HwbFiCoB7MEZnSRxCL_DmFMjCAjVXJ8aQm82O8=.d29f5506-3cbc-427d-a854-838688b154b5@github.com>

On Tue, 6 Oct 2020 15:13:46 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> fyi, there is no need to do a rebase. The preferred way is to do a merge.
> When the changes are integrated, all of the individual commits are squashed to create a single commit.

Good to know, thanks.

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

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

From smarks at openjdk.java.net  Tue Oct  6 17:48:09 2020
From: smarks at openjdk.java.net (Stuart Marks)
Date: Tue, 6 Oct 2020 17:48:09 GMT
Subject: RFR: 8156071: List.of: reduce array copying during creation
In-Reply-To: <cimIDzR9PlwqdQue24nmLeIKKpcyCLBjOwaZwZxeBa8=.3e25a254-ebb7-4c1f-94d7-131556cac4f1@github.com>
References: <-pkG69_yCpZxK0LBMz3Dw_m2VkTK6BhhWBY02UkidfQ=.c1f424e8-5716-4858-aaa0-488a9e553107@github.com>
 <wgUqYY_pcHsD2y5zL7eSmlQubVzCxw7MjOKoQia1Cf4=.b2f66e7b-4c61-49f7-a036-e5b9b0ab562d@github.com>
 <D_N7RiGqEUDfK62HZE2O9rLUM__Uy46r9BgdtnfGyUs=.68fe00a8-7434-45a8-be36-814866aae992@github.com>
 <cimIDzR9PlwqdQue24nmLeIKKpcyCLBjOwaZwZxeBa8=.3e25a254-ebb7-4c1f-94d7-131556cac4f1@github.com>
Message-ID: <XaSiMhSTsQ0dycWiyKOT5WEiDAgGn6TrFs6vmiFnntE=.826b0955-d75d-4c14-a804-49e4b90afe18@github.com>

On Tue, 6 Oct 2020 05:07:37 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

>> Sorry to be late to the party. I thought that all reviews labeled with core-libs should be mirrored to core-libs-dev
>> mailing list but I haven't seen it there :(
>> Please note that the integrated implementation exposes listFromTrustedArray to everybody. No dirty unsafe reflection is
>> necessary, only single unchecked cast:
>>   static <T> List<T> untrustedArrayToList(T[] array) {
>>     @SuppressWarnings("unchecked")
>>     Function<List<T>, List<T>> finisher =
>>         (Function<List<T>, List<T>>) Collectors.<T>toUnmodifiableList().finisher();
>>     ArrayList<T> list = new ArrayList<>() {
>>       @Override
>>       public Object[] toArray() {
>>         return array;
>>       }
>>     };
>>     return finisher.apply(list);
>>   }
>> 
>> This might be qualified as a security issue.
>
> This could be fixed by adding a classword check to the finisher, like this:
> 
>                                    list -> {
>                                         if (list.getClass() != ArrayList.class) {
>                                             throw new IllegalArgumentException();
>                                         }
>                                         return (List<T>) SharedSecrets.getJavaUtilCollectionAccess()
>                                            .listFromTrustedArray(list.toArray());
>                                    },

Thanks for pointing this out. I've filed bug [JDK-8254090](https://bugs.openjdk.java.net/browse/JDK-8254090). I think
we're ok as long as this gets fixed before JDK 16 ships.

I think the notification messages for this did end up on core-libs-dev, but perhaps there were some email delays over
the weekend.

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

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

From volker.simonis at gmail.com  Tue Oct  6 17:50:11 2020
From: volker.simonis at gmail.com (Volker Simonis)
Date: Tue, 6 Oct 2020 19:50:11 +0200
Subject: Request for Discussion: 8253952: Work around wrong usage of
 ZipOutputStream.putNextEntry() in user code
In-Reply-To: <BD045667-852F-4CC0-9B1B-0CCDA856B63B@ORACLE.COM>
References: <CA+3eh12_-fNxf_KFK68WEqVoD_n6CD7RCbe=LoKCyCeUQ3w0oQ@mail.gmail.com>
 <4658d3a6-3360-fb84-e5ff-20dc6cc61b92@oracle.com>
 <CA+3eh10vr3vs92UPu7PwiaofZpf46QuzsuFf4bvf26gbYKF3-g@mail.gmail.com>
 <99e80b7e-7702-338d-cd92-c9d1a396dfa5@oracle.com>
 <DCBE7C9D-A8CB-4A14-8B79-DEA3BE4B2CA8@ORACLE.COM>
 <CA+3eh125PAxoOAWd+nde4oCnYPOptr=y7arxfRLmy5o0mHpo5g@mail.gmail.com>
 <266D112B-3883-4B6D-886E-1F4CE7641A34@ORACLE.COM>
 <CA+3eh10Tr8NnFaZDfxwq+Pc79AA4XkNOkZpy7epgkExEHw1M5A@mail.gmail.com>
 <0DF68377-AD12-423C-AA29-71B0F20F4D25@ORACLE.COM>
 <CA+3eh12doGmUHU3=uKrm_U+6ahcBNLQVig9bpPJChDcrd1-b=g@mail.gmail.com>
 <078C7AC7-7B93-4ACF-A6ED-80087CB0E18E@ORACLE.COM>
 <BD045667-852F-4CC0-9B1B-0CCDA856B63B@ORACLE.COM>
Message-ID: <CA+3eh117LtyddnhWJEhoYCPLXH=9uWAv5GoTOTEXOo+OX=GeJw@mail.gmail.com>

On Tue, Oct 6, 2020 at 6:00 PM Weijun Wang <WEIJUN.WANG at oracle.com> wrote:
>
>
>
> > On Oct 6, 2020, at 11:42 AM, Weijun Wang <WEIJUN.WANG at ORACLE.COM> wrote:
> >
> >
> >
> >> On Oct 6, 2020, at 10:48 AM, Volker Simonis <volker.simonis at gmail.com> wrote:
> >>
> >> On Tue, Oct 6, 2020 at 4:21 PM Weijun Wang <WEIJUN.WANG at oracle.com> wrote:
> >>>
> >>> Hi Volker,
> >>>
> >>> The size unmatch could throw an exception, but writing an existing ZipEntry into a new ZipOutputStream could have other side effects, including time, comment, and other things we added recently, like POSIX permissions and file type flag (is it a symlink?). Do you meant to copy all these things to the new entry automatically?
> >>>
> >>
> >> Hi Max,
> >>
> >> this proposed change is just about fixing the unmatch for the
> >> compressed size attribute. All the other fields will be left
> >> untouched.
> >>
> >> Do you see similar problems with other fields which should be
> >> addressed in a similar way or do you just want to make sure that all
> >> the other fields are passed and processed correctly?
> >
> > No.
> >
> > I was just saying your code change could encourage more people to use the bad code pattern and it might have other unexpected behaviors. Even the zip command requires this or that option to copy certain attributes. For example, should symlinks always be copied as symlinks?
>
> Sorry, my comparison is not precise. The zip tool is adding files to a zip but your code change is about copying existing zip entries.
>
> Still, I wish people are aware that other attributes are copied as well, and they could be different from version to vesion.
>

As described in the java.util.zp package documentation [1]
ZipOutputStream is aiming to create zip files according to the
"Info-ZIP Application Note 970311" [2] with "ZIP64 format extensions"
[3]. Are you aware of any ZipEntry attributes which won't be valid in
the target zip file after they have been read from a source zip file.
I'd be happy to add a warning for them when changing the api
documentation.

Best regards,
Volker

[1] http://www.pkware.com/documents/casestudies/APPNOTE.TXT
[2] https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/zip/package-summary.html
[3] http://www.info-zip.org/doc/appnote-19970311-iz.zip

> Thanks,
> Max
>
> >
> > Thanks,
> > Max
> >
> >>
> >> Regards,
> >> Volker
> >>
> >>> Thanks,
> >>> Max
> >>>
> >>>> On Oct 6, 2020, at 9:56 AM, Volker Simonis <volker.simonis at gmail.com> wrote:
> >>>>
> >>>> On Tue, Oct 6, 2020 at 1:21 PM Lance Andersen <LANCE.ANDERSEN at oracle.com> wrote:
> >>>>>
> >>>>> Hi Volker
> >>>>>
> >>>>> On Oct 6, 2020, at 6:08 AM, Volker Simonis <volker.simonis at gmail.com> wrote:
> >>>>>
> >>>>> On Mon, Oct 5, 2020 at 9:53 PM Lance Andersen <LANCE.ANDERSEN at oracle.com> wrote:
> >>>>>
> >>>>>
> >>>>> Hi Volker,
> >>>>>
> >>>>> Thank you for looking into this and creating a draft PR.
> >>>>>
> >>>>> On the surface, I don?t see a reason to introduce a  System property.  What challenges do you see  if you used the DataDescriptor unless ZipEntry::setCompressedSize is called?  That seems to address the issue that you discovered without having to introduce a new System property. Or is there an additional concern that is not obvious?  This seems like it would address the problem for existing code that is not well behaved.
> >>>>>
> >>>>>
> >>>>> Sure. That's obviously the simplest and best solution and I'd be
> >>>>> totally happy with it. I just thought there might be a need for
> >>>>> somehow preserving the old and buggy behaviour, that's why I added the
> >>>>> system property.
> >>>>>
> >>>>> I've created a simpler version of the fix without property and
> >>>>> adjusted the @apiNote accordingly:
> >>>>>
> >>>>>
> >>>>> Thank you for updating your proposal.  We will need to update the javadoc so that the  description of the change is normative and not part of the API note itself.
> >>>>
> >>>> Changing the updated doc to be normativ instead of just an @apiNote
> >>>> will make it impossible to downport this change but if you think it is
> >>>> really necessary I will accept that. I've removed the @apiNote tag
> >>>> from the java doc and changed the draft PR into a real PR.
> >>>>
> >>>> Without the @apiNote tag I also had to copy the extra documentation
> >>>> verbatim to JarOutputStream.putNextEntry() which is not very elegant
> >>>> but inheriting the whole api doc from ZipOutputStream didn't seem
> >>>> right either. Please let me know if you have a better idea.
> >>>>
> >>>> I'll open a CSR once we've agreed on the exact text for the java doc change.
> >>>>
> >>>> Please let's continue the discussion on the PR or the new mail that
> >>>> was created for it.
> >>>>
> >>>> Best regards,
> >>>> Volker
> >>>>
> >>>>> We will also need to create a CSR for the proposed change in the spec and functionality.  I believe we should also create a release note for this change
> >>>>>
> >>>>> Best
> >>>>> Lance
> >>>>>
> >>>>>
> >>>>> https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/520__;!!GqivPVa7Brio!O7epzMWqwxuS6aPQIllYZLdRTncNGXj5ioqVYY72igGBVGZgUGAHlQnCJ8mhzRoAvw$
> >>>>>
> >>>>> Would you be fine with such a solution?
> >>>>>
> >>>>> Thank you and best regards,
> >>>>> Volker
> >>>>>
> >>>>> The other option is to add an additional method to ZipOutputStream or ZipEntry to address the issue.
> >>>>>
> >>>>> Thoughts?
> >>>>>
> >>>>> Best
> >>>>> Lance
> >>>>>
> >>>>> On Oct 5, 2020, at 2:13 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> >>>>>
> >>>>> On 05/10/2020 11:04, Volker Simonis wrote:
> >>>>>
> >>>>> :
> >>>>>
> >>>>> I don't
> >>>>> think the proposal to add a system property to change the behavior is
> >>>>> feasible, at least not without changing the spec but even then it would
> >>>>> be very icky.
> >>>>>
> >>>>> Why do you think so? The answer to this question is especially
> >>>>> important to me because we are considering doing this in our internal
> >>>>> version independently of upstream OpenJKD (and potentially also in 8 &
> >>>>> 11).
> >>>>>
> >>>>> Introducing system properties to change the behavior of APIs and "fix" existing code is really icky. For the main line, then I think it would be good to explore the impact of changing the existing putNextEntry or introducing a new API. The compatibility impact of the former may not be significant but I would expect the spec would be clarified as part of this (that is what I was trying to say above). Exploring new APIs would be good and a method on ZipEntry may not be too bad (you have a reference to the target ZOS in the implementation).
> >>>>>
> >>>>> :
> >>>>>
> >>>>> And just as a side note, we also use the "jdk.util.zip.inhibitZip64"
> >>>>> property in ZipOutputStream for a similar reason. I just wonder how
> >>>>> that could pass the CCC process as I couldn't even find any
> >>>>> documentation for it :)
> >>>>>
> >>>>> ZIP64 was very problematic at the time as it wasn't supported by several tools. The system property was introduced to disable the feature/support so that Java applications didn't create ZIP files that other tools couldn't consume. It would be good to get an up to date picture on ZIP64 support as it might be that this switch can be removed. It pre-dates the CSR  process but there was a CCC at the time.
> >>>>>
> >>>>> -Alan
> >>>>>
> >>>>>
> >>>>>
> >>>>> Best
> >>>>> Lance
> >>>>> ------------------
> >>>>>
> >>>>>
> >>>>>
> >>>>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
> >>>>> Oracle Java Engineering
> >>>>> 1 Network Drive
> >>>>> Burlington, MA 01803
> >>>>> Lance.Andersen at oracle.com
> >>>>>
> >>>>>
> >>>>>
> >>>>> Best
> >>>>> Lance
> >>>>> ------------------
> >>>>>
> >>>>>
> >>>>>
> >>>>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
> >>>>> Oracle Java Engineering
> >>>>> 1 Network Drive
> >>>>> Burlington, MA 01803
> >>>>> Lance.Andersen at oracle.com
>

From joe.darcy at oracle.com  Tue Oct  6 18:06:29 2020
From: joe.darcy at oracle.com (Joe Darcy)
Date: Tue, 6 Oct 2020 11:06:29 -0700
Subject: Request for Discussion: 8253952: Work around wrong usage of
 ZipOutputStream.putNextEntry() in user code
In-Reply-To: <CA+3eh10Tr8NnFaZDfxwq+Pc79AA4XkNOkZpy7epgkExEHw1M5A@mail.gmail.com>
References: <CA+3eh12_-fNxf_KFK68WEqVoD_n6CD7RCbe=LoKCyCeUQ3w0oQ@mail.gmail.com>
 <4658d3a6-3360-fb84-e5ff-20dc6cc61b92@oracle.com>
 <CA+3eh10vr3vs92UPu7PwiaofZpf46QuzsuFf4bvf26gbYKF3-g@mail.gmail.com>
 <99e80b7e-7702-338d-cd92-c9d1a396dfa5@oracle.com>
 <DCBE7C9D-A8CB-4A14-8B79-DEA3BE4B2CA8@ORACLE.COM>
 <CA+3eh125PAxoOAWd+nde4oCnYPOptr=y7arxfRLmy5o0mHpo5g@mail.gmail.com>
 <266D112B-3883-4B6D-886E-1F4CE7641A34@ORACLE.COM>
 <CA+3eh10Tr8NnFaZDfxwq+Pc79AA4XkNOkZpy7epgkExEHw1M5A@mail.gmail.com>
Message-ID: <34d6b82e-0952-3bc4-2c11-137085858299@oracle.com>

On 10/6/2020 6:56 AM, Volker Simonis wrote:
> On Tue, Oct 6, 2020 at 1:21 PM Lance Andersen <LANCE.ANDERSEN at oracle.com> wrote:
>> Hi Volker
>>
>> On Oct 6, 2020, at 6:08 AM, Volker Simonis <volker.simonis at gmail.com> wrote:
>>
>> On Mon, Oct 5, 2020 at 9:53 PM Lance Andersen <LANCE.ANDERSEN at oracle.com> wrote:
>>
>>
>> Hi Volker,
>>
>> Thank you for looking into this and creating a draft PR.
>>
>> On the surface, I don?t see a reason to introduce a  System property.  What challenges do you see  if you used the DataDescriptor unless ZipEntry::setCompressedSize is called?  That seems to address the issue that you discovered without having to introduce a new System property. Or is there an additional concern that is not obvious?  This seems like it would address the problem for existing code that is not well behaved.
>>
>>
>> Sure. That's obviously the simplest and best solution and I'd be
>> totally happy with it. I just thought there might be a need for
>> somehow preserving the old and buggy behaviour, that's why I added the
>> system property.
>>
>> I've created a simpler version of the fix without property and
>> adjusted the @apiNote accordingly:
>>
>>
>> Thank you for updating your proposal.  We will need to update the javadoc so that the  description of the change is normative and not part of the API note itself.
> Changing the updated doc to be normativ instead of just an @apiNote
> will make it impossible to downport this change but if you think it is
> really necessary I will accept that. I've removed the @apiNote tag
> from the java doc and changed the draft PR into a real PR.
>
> Without the @apiNote tag I also had to copy the extra documentation
> verbatim to JarOutputStream.putNextEntry() which is not very elegant
> but inheriting the whole api doc from ZipOutputStream didn't seem
> right either. Please let me know if you have a better idea.
>
> I'll open a CSR once we've agreed on the exact text for the java doc change.
>
Note that a backport doesn't necessarily need to be "the same" as the 
original change, although it preferable when it can be of course.

In other words, I would not constrain the change in the feature release 
train by what can be directly backported.

Cheers,

-Joe


From rriggs at openjdk.java.net  Tue Oct  6 18:17:17 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 6 Oct 2020 18:17:17 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v2]
In-Reply-To: <FV7h5HwbFiCoB7MEZnSRxCL_DmFMjCAjVXJ8aQm82O8=.d29f5506-3cbc-427d-a854-838688b154b5@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <6P-wrlA7c9wlXEhcoAYW5J9W2jwTmTTj3PkDObPh0LA=.c11aa048-8853-4e1c-a689-c34b89c15f12@github.com>
 <T48t-_XIiM_NlSZau6pj9hjSxp--n9pktxI6XCZ-W8k=.54c779af-e1af-4e62-9e4f-48ed7145bfc9@github.com>
 <jUYJaiGKl3ktWaYGsPH8p_Nd38t8I5AtdKtaVaDJcR0=.e8417e8d-91b5-41f3-af81-6e485167bd44@github.com>
 <qv0XG1izvRxgj90kajyp1XhQvt7gIuPtZdrbTVkAeLY=.6daf3496-e70e-47a7-a6d0-61127b9ec649@github.com>
 <FV7h5HwbFiCoB7MEZnSRxCL_DmFMjCAjVXJ8aQm82O8=.d29f5506-3cbc-427d-a854-838688b154b5@github.com>
Message-ID: <ElVpGg2aHJTZc-BVvK-lMglFshCqE1qgozUDE5JRyc0=.37d1c5d4-656b-4e46-b549-09bb7e1a26d5@github.com>

On Tue, 6 Oct 2020 17:42:36 GMT, CoreyAshford <github.com+51754783+CoreyAshford at openjdk.org> wrote:

>> fyi, there is no need to do a rebase.  The preferred way is to do a merge.
>> When the changes are integrated, all of the individual commits are squashed to create a single commit.
>
>> fyi, there is no need to do a rebase. The preferred way is to do a merge.
>> When the changes are integrated, all of the individual commits are squashed to create a single commit.
> 
> Good to know, thanks.

We'll need a HotSpot Reviewer to approve too.

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

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

From mchung at openjdk.java.net  Tue Oct  6 18:18:11 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 6 Oct 2020 18:18:11 GMT
Subject: RFR: 8247536: Support for pre-generated java.lang.invoke classes
 in CDS static archive [v11]
In-Reply-To: <fnlaWkwge3SaOu_A427Z-rRlIwxo4n90jXaZan089Hk=.3821150a-9608-4dcf-8284-aa951eed1077@github.com>
References: <Y_Bas-poGnDtvcJbqbmeIAPQRNxzvarBToQWALn9TTE=.e846cd3c-0e7b-48d3-8ffa-be3c03acffb0@github.com>
 <fnlaWkwge3SaOu_A427Z-rRlIwxo4n90jXaZan089Hk=.3821150a-9608-4dcf-8284-aa951eed1077@github.com>
Message-ID: <MVSv0qdA1fDvK_Jh6uLdP7cZbIwGGqD1fy_Ms8_hZ0o=.3a4caea1-52e5-4485-b98a-86408bc41aa3@github.com>

On Tue, 6 Oct 2020 17:35:18 GMT, Yumin Qi <minqi at openjdk.org> wrote:

>> This patch is reorganized after 8252725, which is separated from this patch to refactor jlink glugin code. The previous
>> webrev with hg can be found at: http://cr.openjdk.java.net/~minqi/2020/8247536/webrev-05. With 8252725 integrated, the
>> regeneration of holder classes is simply to call the new added GenerateJLIClassesHelper.cdsGenerateHolderClasses
>> function.  Tests: tier1-4
>
> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed unused imports.

src/java.base/share/classes/java/lang/invoke/GenerateJLIClassesHelper.java line 63:

> 61:             if (TRACE_RESOLVE) {
> 62:                 System.out.println(traceLF + (resolvedMember != null ? " (success)" : " (fail)"));
> 63:             }

I suggest not to change the existing code.  Instead, have `CDS::traceLambdaFormInvoker`
to take individual parameters `Class<?> holder, String name, String shortenSignature`
(rather than the formatted string).   Something like:

    if (CDS.isDumpLoadedClassList()) {
          CDS.traceLambdaFormInvoker(holder, name, shortenSignature(basicTypeSignature(type));
    }

This also gives flexibility to CDS to decide on what format to write to the class list (like this case, you drop the
text "success/fail")

In addition, the conditional check on `CDS.isDumpLoadedClassList()` is hard to relate to why CDS traces these events.
I see Ioi's comment on this method name too.   I agree with Ioi that `isDumpingClassList` makes more sense.

src/java.base/share/classes/java/lang/invoke/GenerateJLIClassesHelper.java line 74:

> 72:                 System.out.println(traceSP + (salvage != null ? " (salvaged)" : " (generated)"));
> 73:             }
> 74:             CDS.traceLambdaFormInvoker(traceSP);

I suggest leaving the existing code unchanged.  Instead, add the following:
    if (CDS.isDumpingClassList()) {
         CDS.traceSpeciesType(cn);
    }

The above uses Ioi's suggested method name which reads better.

src/java.base/share/classes/jdk/internal/misc/CDS.java line 83:

> 81:      * check if -XX:+DumpLoadedClassList and given file is open
> 82:      */
> 83:     public static boolean isDumpLoadedClassList() {

I agree with Ioi's suggestion to rename this to `isDumpingClassList` which describes what the VM is doing.

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

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

From github.com+51754783+coreyashford at openjdk.java.net  Tue Oct  6 18:22:07 2020
From: github.com+51754783+coreyashford at openjdk.java.net (CoreyAshford)
Date: Tue, 6 Oct 2020 18:22:07 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v2]
In-Reply-To: <ElVpGg2aHJTZc-BVvK-lMglFshCqE1qgozUDE5JRyc0=.37d1c5d4-656b-4e46-b549-09bb7e1a26d5@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <6P-wrlA7c9wlXEhcoAYW5J9W2jwTmTTj3PkDObPh0LA=.c11aa048-8853-4e1c-a689-c34b89c15f12@github.com>
 <T48t-_XIiM_NlSZau6pj9hjSxp--n9pktxI6XCZ-W8k=.54c779af-e1af-4e62-9e4f-48ed7145bfc9@github.com>
 <jUYJaiGKl3ktWaYGsPH8p_Nd38t8I5AtdKtaVaDJcR0=.e8417e8d-91b5-41f3-af81-6e485167bd44@github.com>
 <qv0XG1izvRxgj90kajyp1XhQvt7gIuPtZdrbTVkAeLY=.6daf3496-e70e-47a7-a6d0-61127b9ec649@github.com>
 <FV7h5HwbFiCoB7MEZnSRxCL_DmFMjCAjVXJ8aQm82O8=.d29f5506-3cbc-427d-a854-838688b154b5@github.com>
 <ElVpGg2aHJTZc-BVvK-lMglFshCqE1qgozUDE5JRyc0=.37d1c5d4-656b-4e46-b549-09bb7e1a26d5@github.com>
Message-ID: <5HeCT4pIrQCiAKTemQtl9pu8IDADDLgsQZ2eoDeSbhw=.d6a76689-97ca-4a0e-9ac7-5398b3774de4@github.com>

On Tue, 6 Oct 2020 18:13:05 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> We'll need a HotSpot Reviewer to approve too.

I have requested help from the team here.

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

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

From bpb at openjdk.java.net  Tue Oct  6 18:25:06 2020
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Tue, 6 Oct 2020 18:25:06 GMT
Subject: RFR: 8067127: Tags cleanup
In-Reply-To: <dMAmqJXQfWiKQzoO2323FybqqdQ4MNBPFcY78bo-fLs=.34972cc7-b182-4191-bfe7-872c29cff1c2@github.com>
References: <8YR2pzHDTetS1LChJUDvPtgo_LdMBZggFfmkdLl-HO4=.8016f8e2-aa1f-429f-a744-798807c7964e@github.com>
 <dMAmqJXQfWiKQzoO2323FybqqdQ4MNBPFcY78bo-fLs=.34972cc7-b182-4191-bfe7-872c29cff1c2@github.com>
Message-ID: <NodgHL7WqrvyeBQNNaReVa6vXexVvxoAATTqcKp7U3w=.aa888bd4-0beb-4dc9-9e9f-29e041249a2b@github.com>

On Mon, 5 Oct 2020 20:45:54 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Please review this change to update some javadoc tags in the java.io package. The changes are to replace some
>> occurrences of <code>some_code</code> with {@code some_code}. Not all such constructs were replaced as being
>> infeasible, e.g., tag contains an entity such as <code>*&#47;</code> (DataOutput, Serial), or multiple {@code} tags
>> would be needed or the result would be ugly (File). It is unclear whether some of the changes which remove the
>> non-breaking space entity (&nbsp;) are desirable.  Thanks,  Brian
>
> src/java.base/share/classes/java/io/PipedReader.java line 62:
> 
>> 60:      * next character of data will be stored when received from the connected
>> 61:      * piped writer. {@code in < 0} implies the buffer is empty,
>> 62:      * {@code in==out} implies the buffer is full
> 
> Add spaces around ==?

Will change before integrating.

> src/java.base/share/classes/java/io/FileFilter.java line 33:
> 
>> 31:  *
>> 32:  * <p> Instances of this interface may be passed to the {@link
>> 33:  * File#listFiles(java.io.FileFilter) listFiles(FileFilter)} method
> 
> I would tend to keep {@link on the same line with the rest of the link.

Will change before integrating.

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

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

From dfuchs at openjdk.java.net  Tue Oct  6 18:48:08 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Tue, 6 Oct 2020 18:48:08 GMT
Subject: RFR: 8067127: Tags cleanup
In-Reply-To: <8YR2pzHDTetS1LChJUDvPtgo_LdMBZggFfmkdLl-HO4=.8016f8e2-aa1f-429f-a744-798807c7964e@github.com>
References: <8YR2pzHDTetS1LChJUDvPtgo_LdMBZggFfmkdLl-HO4=.8016f8e2-aa1f-429f-a744-798807c7964e@github.com>
Message-ID: <zXh1GpZsGYJ374IEDgpWm2kjs5lR9SLXuQVWVJiDDLM=.a5c4cfec-d367-43fa-af2d-953e5473f372@github.com>

On Mon, 5 Oct 2020 18:59:00 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Please review this change to update some javadoc tags in the java.io package. The changes are to replace some
> occurrences of <code>some_code</code> with {@code some_code}. Not all such constructs were replaced as being
> infeasible, e.g., tag contains an entity such as <code>*&#47;</code> (DataOutput, Serial), or multiple {@code} tags
> would be needed or the result would be ugly (File). It is unclear whether some of the changes which remove the
> non-breaking space entity (&nbsp;) are desirable.  Thanks,  Brian

src/java.base/share/classes/java/io/BufferedInputStream.java line 398:

> 396:      * This method returns the sum of the number of bytes remaining to be read in
> 397:      * the buffer ({@code count - pos}) and the result of calling the
> 398:      * {@link java.io.FilterInputStream#in in}.available().

I believe this should probably preferably be:

` * {@link java.io.FilterInputStream#in in}{@code .available()}.`

since `.available()` is obviously code.

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

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

From bpb at openjdk.java.net  Tue Oct  6 18:53:09 2020
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Tue, 6 Oct 2020 18:53:09 GMT
Subject: RFR: 8067127: Tags cleanup
In-Reply-To: <zXh1GpZsGYJ374IEDgpWm2kjs5lR9SLXuQVWVJiDDLM=.a5c4cfec-d367-43fa-af2d-953e5473f372@github.com>
References: <8YR2pzHDTetS1LChJUDvPtgo_LdMBZggFfmkdLl-HO4=.8016f8e2-aa1f-429f-a744-798807c7964e@github.com>
 <zXh1GpZsGYJ374IEDgpWm2kjs5lR9SLXuQVWVJiDDLM=.a5c4cfec-d367-43fa-af2d-953e5473f372@github.com>
Message-ID: <6tsPd2YOvIiQ_QBN7NfN6it496JJST7dmFlhDidemUE=.d9b41cdc-b79b-4fc8-96a6-b8484aa534b5@github.com>

On Tue, 6 Oct 2020 18:41:23 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Please review this change to update some javadoc tags in the java.io package. The changes are to replace some
>> occurrences of <code>some_code</code> with {@code some_code}. Not all such constructs were replaced as being
>> infeasible, e.g., tag contains an entity such as <code>*&#47;</code> (DataOutput, Serial), or multiple {@code} tags
>> would be needed or the result would be ugly (File). It is unclear whether some of the changes which remove the
>> non-breaking space entity (&nbsp;) are desirable.  Thanks,  Brian
>
> src/java.base/share/classes/java/io/BufferedInputStream.java line 398:
> 
>> 396:      * This method returns the sum of the number of bytes remaining to be read in
>> 397:      * the buffer ({@code count - pos}) and the result of calling the
>> 398:      * {@link java.io.FilterInputStream#in in}.available().
> 
> I believe this should probably preferably be:
> 
> ` * {@link java.io.FilterInputStream#in in}{@code .available()}.`
> 
> since `.available()` is obviously code.

I agree that would probably be better. Will change before integrating.

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

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

From neliasso at openjdk.java.net  Tue Oct  6 18:55:11 2020
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Tue, 6 Oct 2020 18:55:11 GMT
Subject: RFR: 8252847: Optimize primitive arrayCopy stubs using AVX-512
 masked instructions [v5]
In-Reply-To: <sQHZ77hHmnwfonjb7qvDT6-rL3luDvk57q36Sjmb_Lo=.12a2e731-cedf-48c5-80be-bd832dcb6cd2@github.com>
References: <s3XJ1KwOB0mtBpkLYMuA7J8ftplOmHLqr8IwSeXrCg4=.4fe22fd0-8780-4d1e-a628-465e314ac31d@github.com>
 <XR9RmuktREfMNaYp0MC6cwLVUAm1_MzdewUA00Inp58=.372fb1e3-50bc-41f3-883b-dcc36cc605d5@github.com>
 <sQHZ77hHmnwfonjb7qvDT6-rL3luDvk57q36Sjmb_Lo=.12a2e731-cedf-48c5-80be-bd832dcb6cd2@github.com>
Message-ID: <g4qVQGfRPkX7sflq7ETQdWpEL9fXsUoixmu2xKgahvw=.e9b3ed3a-a192-42cc-ac18-97456dfbf6c3@github.com>

On Fri, 25 Sep 2020 20:48:10 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8252847 : Modifying file permission to resolve jcheck failure.
>
> src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 1264:
> 
>> 1262:   }
>> 1263:
>> 1264: #ifndef PRODUCT
> 
> macroAssembler_x86.hpp become big. May be we should start thing about splitting arraycopy stubs into separate file.

But lets do that in a another change. It is good that the AVX3 case is separated out in this change - makes it easy to
follow.

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

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

From igraves at openjdk.java.net  Tue Oct  6 19:13:07 2020
From: igraves at openjdk.java.net (Ian Graves)
Date: Tue, 6 Oct 2020 19:13:07 GMT
Subject: RFR: 8253459: Formatter treats index,
 width and precision > Integer.MAX_VALUE incorrectly
In-Reply-To: <gg0s8jJxwD602qg5kVnZ2KUmJb84vaks1WKh7-zyA1I=.8614d28b-e1e4-4d81-82ad-eba620a4516c@github.com>
References: <3aYgWcp1IVMM0vQT5UMLSnc2JA1uK9cbtRe283RF37g=.fc2049ef-cdbe-4948-a24b-fdb88cc87a1c@github.com>
 <gg0s8jJxwD602qg5kVnZ2KUmJb84vaks1WKh7-zyA1I=.8614d28b-e1e4-4d81-82ad-eba620a4516c@github.com>
Message-ID: <rWfrZZY9p0Y97KCo6tSmK0vYrHrzqTWAAn4NzLtY8L8=.9ccce67d-a400-4fbc-b7d6-b2cb78f8d014@github.com>

On Tue, 6 Oct 2020 13:55:55 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> The `java.util.Formatter` format specifies support for field widths, argument indexes, or precision lengths of a field
>> that relate to the variadic arguments supplied to the formatter. These numbers are specified by integers, sometimes
>> negative. For argument index, it's specified in the documentation that the highest allowed argument is limited by the
>> largest possible index of an array (ie the largest possible variadic index), but for the other two it's not defined.
>> Moreover, what happens when a number field in a string is too large or too small to be represented by a 32-bit integer
>> type is not defined.  This fix adds documentation to specify what error behavior occurs during these cases.
>> Additionally it adds an additional exception type to throw when an invalid argument index is observed.  A CSR will be
>> required for this PR.
>
> Is the new exception type useful?  yes, it matches the previous pattern.
> But it does not (and none of the IllegalFormatException subclasses) produce a readable message with the offending
> value. So the developer will not see anything useful. The fine grained exceptions provide little value.

I've been on the fence about this, personally. The Formatter uses pretty fine-grained exception types for error
conditions. I'd be okay discontinuing this practice here, but am not sure what to replace this with. Perhaps we enable
`IllegalFormatException` to be, itself, public and instantiable ?

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

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

From michaelm at openjdk.java.net  Tue Oct  6 19:53:18 2020
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Tue, 6 Oct 2020 19:53:18 GMT
Subject: RFR: 8245194: Unix domain socket channel implementation [v17]
In-Reply-To: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
References: <UaVQaKMbkF5vfzXARfvcoB_nx-ee7cAv78z-ibxmc_I=.4b1830aa-0fb8-489d-a2df-555fd8699022@github.com>
Message-ID: <cHLt3KxXbRfBSo7EX--jOzxQWLj7Afp-1l9tWg7rwMw=.2e9e408d-05c8-4c9d-aaf2-5027ff7e6d81@github.com>

> Continuing this review as a PR on github with the comments below incorporated. I expect there will be a few more
> iterations before integrating.
> On 06/09/2020 19:47, Alan Bateman wrote:
>> On 26/08/2020 15:24, Michael McMahon wrote:
>>>
>>> As I mentioned the other day, I wasn't able to use the suggested method on Windows which returns an absolute path. So,
>>> I added a method to WindowsPath which returns the path in the expected UTF-8 encoding as a byte[]. Let me know what you
>>> think of that.
>>>
>>> There is a fair bit of other refactoring and simplification done also. Next version is at:
>>>
>>> http://cr.openjdk.java.net/~michaelm/8245194/impl.webrev/webrev.9/
>>>
>> Adding a method to WindowsPath to encode the path using UTF-8 is okay but I don't think we should be caching it as the
>> encoding for sun_path is an outlier on Windows. I'm also a bit dubious about encoding a relative path when the resolved
>> path (before encoding) is > 247 chars. The documentation on the MS site isn't very completely and I think there are a
>> number points that require clarification to fully understand how this will work with relative, directly relative and
>> drive relative paths.
>>
> 
> Maybe it would be better to just use the path returned from toString() and do the conversion to UTF-8 externally. That
> would leave WindowsPath unchanged.
>> In the same area, the new PathUtil is a bit inconsistent with the existing provider code. One suggestion is to add a
>> method to AbstractFileSystemProvider instead. That is the base class the platform providers and would be a better place
>> to get the file path in bytes.
>>
> 
> Okay, I gave the method a name that is specific to Unix domain sockets because this UTF-8 strangeness is not likely to
> be useful by other components.
>> One other comment on the changes to the file system provider it should be okay to change UnixUserPrinipals ad its
>> fromUid and fromGid method to be public. This would mean that the patch shouldn't need to add UnixUserGroup (the main
>> issue is that class is that it means we end up with two classes with static factory methods doing the same thing).
> 
> Okay, that does simplify it a bit.
> 
> Thanks,
> Michael.
> 
>> -Alan.
>>
>>
>>
>>
>>
>>

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

  unixdomainchannels:
  - updated property name
  - added JFR unit test

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/52/files
  - new: https://git.openjdk.java.net/jdk/pull/52/files/36efb46c..0e8e527f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=52&range=16
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=52&range=15-16

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

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

From neliasso at openjdk.java.net  Tue Oct  6 20:21:09 2020
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Tue, 6 Oct 2020 20:21:09 GMT
Subject: RFR: 8173585: Intrinsify StringLatin1.indexOf(char) [v4]
In-Reply-To: <Zw-pc6-7I0QmKg9KVIDxG3CKtK4ZRGrgID0J0UsNHoc=.b0cfcc25-801c-4611-b501-f3d67c5ef347@github.com>
References: <_T0873dC5tfUtGn9r1_Y21JkPKRt-za3MM9hPN2GQKQ=.b865fe53-5417-424f-81b6-1566a330640e@github.com>
 <Zw-pc6-7I0QmKg9KVIDxG3CKtK4ZRGrgID0J0UsNHoc=.b0cfcc25-801c-4611-b501-f3d67c5ef347@github.com>
Message-ID: <X8Hfl3jQXkQM5Bi61VHw1HDfba-FqXcyjPh_r0LZwSA=.b4aaf2ff-a969-4fd0-9e05-cd7708fc0b1e@github.com>

On Fri, 2 Oct 2020 08:40:58 GMT, Jason Tatton <github.com+70893615+jasontatton-aws at openjdk.org> wrote:

>> This is an implementation of the indexOf(char) intrinsic for StringLatin1 (1 byte encoded Strings). It is provided for
>> x86 and ARM64. The implementation is greatly inspired by the indexOf(char) intrinsic for StringUTF16. To incorporate it
>> I had to make a small change to StringLatin1.java (refactor of functionality to intrisified private method) as well as
>> code for C2.  Submitted to: hotspot-compiler-dev and core-libs-dev as this patch contains a change to hotspot and
>> java/lang/StringLatin1.java  https://bugs.openjdk.java.net/browse/JDK-8173585
>> 
>> Details of testing:
>> ============
>> I have created a jtreg test ?compiler/intrinsics/string/TestStringLatin1IndexOfChar? to cover this new intrinsic. Note
>> that, particularly for the x86 implementation of the intrinsic, the code path taken is dependent upon the length of the
>> input String. Hence the test has been designed to cover all these cases. In summary they are:
>> - A ?short? string of < 16 characters.
>> - A SIMD String of 16 ? 31 characters.
>> - A AVX2 SIMD String of 32 characters+.
>> 
>> Hardware used for testing:
>> -----------------------------
>> 
>> - Intel Xeon CPU E5-2680 (JVM did not recognize this as having AVX2 support) ? Intel i7 processor (with AVX2 support).
>> - AWS Graviton 2 (ARM 64 processor).
>> 
>> I also ran; ?run-test-tier1? and ?run-test-tier2? for: x86_64 and aarch64.
>> 
>> Possible future enhancements:
>> ====================
>> For the x86 implementation there may be two further improvements we can make in order to improve performance of both
>> the StringUTF16 and StringLatin1 indexOf(char) intrinsics:
>> 1. Make use of AVX-512 instructions.
>> 2. For ?short? Strings (see below), I think it may be possible to modify the existing algorithm to still use SSE SIMD
>> instructions instead of a loop.
>> Benchmark results:
>> ============
>> **Without** the new StringLatin1 indexOf(char) intrinsic:
>> 
>> | Benchmark  | Mode | Cnt | Score | Error | Units |
>> | ------------- | ------------- |------------- |------------- |------------- |------------- |
>> | IndexOfBenchmark.latin1_mixed_char | avgt | 5 | **26,389.129** | ? 182.581 | ns/op |
>> | IndexOfBenchmark.utf16_mixed_char | avgt | 5 | 17,885.383 | ? 435.933  | ns/op |
>> 
>> 
>> **With** the new StringLatin1 indexOf(char) intrinsic:
>> 
>> | Benchmark  | Mode | Cnt | Score | Error | Units |
>> | ------------- | ------------- |------------- |------------- |------------- |------------- |
>> | IndexOfBenchmark.latin1_mixed_char | avgt | 5 | **17,875.185** | ? 407.716  | ns/op |
>> | IndexOfBenchmark.utf16_mixed_char | avgt | 5 | 18,292.802 | ? 167.306  | ns/op |
>> 
>> 
>> The objective of the patch is to bring the performance of StringLatin1 indexOf(char) in line with StringUTF16
>> indexOf(char) for x86 and ARM64. We can see above that this has been achieved. Similar results were obtained when
>> running on ARM.
>
> Jason Tatton has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8173585: Intrinsify StringLatin1.indexOf(char)
>   
>   Rewrite of unit test and newlines added to end of files
>   
>   Changes to unit test:
>   - main test adjusted such that Strings gennerated are much longer (up to
>   2048 characters) and of the form: azaza, aazaazaa, aaazaaazaaa, etc with
>   'z' being the search character searched for. Multiple instances of the
>   search character are included in the String in order to validate that
>   the starting offset is correctly handleded. Results are compared to non
>   intrinsified version of the code. Longer strings means that the looping
>   functionality of the various paths is entered into.
>   - Run configurations introduced such that it checks behaviour where use
>   of SSE and AVX instructions are restricted.
>   - Tier4InvocationThreshold adjusted so as to ensure C2 code iis invoked.
>   
>   Other changes:
>   - newlines added at end of files

test/hotspot/jtreg/compiler/intrinsics/string/TestStringLatin1IndexOfChar.java line 25:

> 23: import jdk.test.lib.Asserts;
> 24:
> 25: public class TestStringLatin1IndexOfChar{

Can you please add testing for these edge cases:
- when the search char is the first char
- when the search char is the last char
- when the string has length 1

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

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

From iignatyev at openjdk.java.net  Tue Oct  6 20:38:08 2020
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Tue, 6 Oct 2020 20:38:08 GMT
Subject: RFR: 8253750: use build-stable default seed for
 Utils.RANDOM_GENERATOR [v3]
In-Reply-To: <S0aS_QQOXwZtGw3IWuaf5AAC47l717QHLPFOyKra8NY=.38275d3c-5bb1-4d51-8c83-5f6439747344@github.com>
References: <RQa3EOXeDAni1G-mu_jM-I9mosypb0gnuLUmFCtGhGo=.92a4f06b-60df-49b6-b6e3-bcf11e7530ab@github.com>
 <AIFV5ZwLYCPyA9X3Ezvb0ZRUSmdAPRAnzdkTd3aaBjo=.95bd0e9e-93e9-4211-892d-43fc473fc695@github.com>
 <S0aS_QQOXwZtGw3IWuaf5AAC47l717QHLPFOyKra8NY=.38275d3c-5bb1-4d51-8c83-5f6439747344@github.com>
Message-ID: <AWG-QwXwf2Xgn88foQgWvm8WAPfTgVvGO6l1K-pY1Xw=.f6786e16-0bdb-4d7e-baa6-b46efca59eb4@github.com>

On Tue, 6 Oct 2020 13:35:14 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Igor Ignatyev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   use random seed for personal/internal builds
>
> Marked as reviewed by rriggs (Reviewer).

Thanks, Roger.

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

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

From iignatyev at openjdk.java.net  Tue Oct  6 20:38:09 2020
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Tue, 6 Oct 2020 20:38:09 GMT
Subject: Integrated: 8253750: use build-stable default seed for
 Utils.RANDOM_GENERATOR
In-Reply-To: <RQa3EOXeDAni1G-mu_jM-I9mosypb0gnuLUmFCtGhGo=.92a4f06b-60df-49b6-b6e3-bcf11e7530ab@github.com>
References: <RQa3EOXeDAni1G-mu_jM-I9mosypb0gnuLUmFCtGhGo=.92a4f06b-60df-49b6-b6e3-bcf11e7530ab@github.com>
Message-ID: <cfmA9lj43qMJSFtNdu21qdvwhWRECIB7zb8nymMqvNE=.e1aab5c4-178a-409c-8751-9955ebf65779@github.com>

On Tue, 29 Sep 2020 00:06:02 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review the patch which updates `jdk.test.lib.Utils` to use md5 hash-sum of `java.vm.version` property
> as default seed for `Utils.RANDOM_GENERATOR`?
> from JBS:
>> using the same seed for all runs of a build will make it possible (easier) to compare results from different test runs
>> (e.g. on different platforms, w/ different flags) and consequently will make test results analysis easier. the proposed
>> solution is to use the seed based on Runtime.version() / "java.vm.version", which are different from build to build, if
>> there is no seed specified by "jdk.test.lib.random.seed" property.
> 
> the patch also updates `RandomGeneratorTest` test, so it expects now that the same values are generated if no seed is
> provided.
> testing:
> ? tier1
> ? `test/lib-test/jdk/test/lib/` against personal build on linux,windows,macos-x64
> ? `test/lib-test/jdk/test/lib/` against CI build on linux,windows,macos-x64

This pull request has now been integrated.

Changeset: ac772cd9
Author:    Igor Ignatyev <iignatyev at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ac772cd9
Stats:     58 lines in 2 files changed: 44 ins; 5 del; 9 mod

8253750: use build-stable default seed for Utils.RANDOM_GENERATOR

Reviewed-by: rriggs

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

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

From minqi at openjdk.java.net  Tue Oct  6 20:46:17 2020
From: minqi at openjdk.java.net (Yumin Qi)
Date: Tue, 6 Oct 2020 20:46:17 GMT
Subject: RFR: 8247536: Support for pre-generated java.lang.invoke classes
 in CDS static archive [v12]
In-Reply-To: <Y_Bas-poGnDtvcJbqbmeIAPQRNxzvarBToQWALn9TTE=.e846cd3c-0e7b-48d3-8ffa-be3c03acffb0@github.com>
References: <Y_Bas-poGnDtvcJbqbmeIAPQRNxzvarBToQWALn9TTE=.e846cd3c-0e7b-48d3-8ffa-be3c03acffb0@github.com>
Message-ID: <9emWKl6fr-GA5LN0uHhuEd5D123QcoCiHQR1M9bAbag=.cc4b6129-8b33-47e4-a421-9e6b4817933b@github.com>

> This patch is reorganized after 8252725, which is separated from this patch to refactor jlink glugin code. The previous
> webrev with hg can be found at: http://cr.openjdk.java.net/~minqi/2020/8247536/webrev-05. With 8252725 integrated, the
> regeneration of holder classes is simply to call the new added GenerateJLIClassesHelper.cdsGenerateHolderClasses
> function.  Tests: tier1-4

Yumin Qi has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains
23 commits:

 - Added new separate function to CDS for logging species and modified the existing function to log lambda form invokers.
   Changed isDumpLoadedClassList to a reasonable name isDumpingClassList as read only in CDS.
 - Merge branch 'master' of https://github.com/openjdk/jdk into jdk-8247536
 - Removed unused imports.
 - Fixed comments with correct class and method name in CDS, removed unused variables after last change.
 - Moved and renamed cdsGenerateHolderClasses from GenerateJLIClassesHelp to CDS as generateLambdaFormHolderClasses. Added
   input verification function in CDS before class generation. Added more test scenarios. Removed trailing unused ending
   words for output of lambda form trace line in case of DumpLoadedClassList.
 - Move the check work to java, restore code in VM. Modified test code according to the changes. The invoke name
   verififcation is not implemented since not all the holder class are processed, not all the functions of processed
   holder classes are added. For holder class with DirectMethodHandle in its name, only the name in the
   DMH_METHOD_TYPE_MAP keyset is added, ithe line with other names just gets skipped silently. This makes the verification
   on invoke names difficul, a name not in the keyset should not fail the test. Also add a boolean to
   cdsGenerateHolderClasses to indicate call path.
 - Remove trailing word of line which is not used in holder class regeneration. There is a trailing LF (Line Feed) so trim
   white spaces from both front and end of the line or it will fail method type validation.
 - In case of exception happens during reloading class, CHECK will return without free the allocated buffer for class
   bytes so moved the buffer allocation and freeing to caller. Also removed test 6 since there is not guarantee that we
   can give a signature which will always fail. Additional changes to GenerateJLIClassesHelper according to review
   suggestion.
 - Merge branch 'master' of https://github.com/openjdk/jdk into jdk-8247536
 - Merge branch 'master' of https://git.openjdk.java.net/jdk into jdk-8247536
 - ... and 13 more: https://git.openjdk.java.net/jdk/compare/82fe023b...f5584dcf

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

Changes: https://git.openjdk.java.net/jdk/pull/193/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=193&range=11
  Stats: 567 lines in 21 files changed: 545 ins; 14 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/193.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/193/head:pull/193

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

From iignatyev at openjdk.java.net  Tue Oct  6 20:53:12 2020
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Tue, 6 Oct 2020 20:53:12 GMT
Subject: RFR: 8254095: remove jdk.test.lib.Utils::distro() method
Message-ID: <JmMVhacA8DG5S5MpveRfq6DBOg8WcyDHbKTbMR1AXc4=.6ea99fb5-0f72-4d83-aba7-634825c1a380@github.com>

Hi all,

could you please review this trivial cleanup? from JBS:
> jdk.test.lib.Utils::distro() is not used by any of the tests and can be removed.

Thanks,
-- Igor

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

Commit messages:
 - 8254095: remove jdk.test.lib.Utils::distro() method

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

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

From lance.andersen at oracle.com  Tue Oct  6 21:00:58 2020
From: lance.andersen at oracle.com (Lance Andersen)
Date: Tue, 6 Oct 2020 17:00:58 -0400
Subject: Request for Discussion: 8253952: Work around wrong usage of
 ZipOutputStream.putNextEntry() in user code
In-Reply-To: <CA+3eh117LtyddnhWJEhoYCPLXH=9uWAv5GoTOTEXOo+OX=GeJw@mail.gmail.com>
References: <CA+3eh12_-fNxf_KFK68WEqVoD_n6CD7RCbe=LoKCyCeUQ3w0oQ@mail.gmail.com>
 <4658d3a6-3360-fb84-e5ff-20dc6cc61b92@oracle.com>
 <CA+3eh10vr3vs92UPu7PwiaofZpf46QuzsuFf4bvf26gbYKF3-g@mail.gmail.com>
 <99e80b7e-7702-338d-cd92-c9d1a396dfa5@oracle.com>
 <DCBE7C9D-A8CB-4A14-8B79-DEA3BE4B2CA8@ORACLE.COM>
 <CA+3eh125PAxoOAWd+nde4oCnYPOptr=y7arxfRLmy5o0mHpo5g@mail.gmail.com>
 <266D112B-3883-4B6D-886E-1F4CE7641A34@ORACLE.COM>
 <CA+3eh10Tr8NnFaZDfxwq+Pc79AA4XkNOkZpy7epgkExEHw1M5A@mail.gmail.com>
 <0DF68377-AD12-423C-AA29-71B0F20F4D25@ORACLE.COM>
 <CA+3eh12doGmUHU3=uKrm_U+6ahcBNLQVig9bpPJChDcrd1-b=g@mail.gmail.com>
 <078C7AC7-7B93-4ACF-A6ED-80087CB0E18E@ORACLE.COM>
 <BD045667-852F-4CC0-9B1B-0CCDA856B63B@ORACLE.COM>
 <CA+3eh117LtyddnhWJEhoYCPLXH=9uWAv5GoTOTEXOo+OX=GeJw@mail.gmail.com>
Message-ID: <BFA1F5D3-4A15-47DD-8EE4-9D958B75131E@oracle.com>

Hi Volker, Max,

Perhaps as part of the clarification and the example of the proper way to copy a ZipEntry, used with putNextEntry, it might be worth clarifying that any values that are needed from the ZipEntry returned from ZipInputStream::getNextEntry should be set(copied) in the new ZipEntry prior to passing the ZipEntry to putNextEntry?   

> On Oct 6, 2020, at 1:50 PM, Volker Simonis <volker.simonis at gmail.com> wrote:
> 
> On Tue, Oct 6, 2020 at 6:00 PM Weijun Wang <WEIJUN.WANG at oracle.com <mailto:WEIJUN.WANG at oracle.com>> wrote:
>> 
>> 
>> 
>>> On Oct 6, 2020, at 11:42 AM, Weijun Wang <WEIJUN.WANG at ORACLE.COM> wrote:
>>> 
>>> 
>>> 
>>>> On Oct 6, 2020, at 10:48 AM, Volker Simonis <volker.simonis at gmail.com> wrote:
>>>> 
>>>> On Tue, Oct 6, 2020 at 4:21 PM Weijun Wang <WEIJUN.WANG at oracle.com> wrote:
>>>>> 
>>>>> Hi Volker,
>>>>> 
>>>>> The size unmatch could throw an exception, but writing an existing ZipEntry into a new ZipOutputStream could have other side effects, including time, comment, and other things we added recently, like POSIX permissions and file type flag (is it a symlink?). Do you meant to copy all these things to the new entry automatically?
>>>>> 
>>>> 
>>>> Hi Max,
>>>> 
>>>> this proposed change is just about fixing the unmatch for the
>>>> compressed size attribute. All the other fields will be left
>>>> untouched.
>>>> 
>>>> Do you see similar problems with other fields which should be
>>>> addressed in a similar way or do you just want to make sure that all
>>>> the other fields are passed and processed correctly?
>>> 
>>> No.
>>> 
>>> I was just saying your code change could encourage more people to use the bad code pattern and it might have other unexpected behaviors. Even the zip command requires this or that option to copy certain attributes. For example, should symlinks always be copied as symlinks?
>> 
>> Sorry, my comparison is not precise. The zip tool is adding files to a zip but your code change is about copying existing zip entries.
>> 
>> Still, I wish people are aware that other attributes are copied as well, and they could be different from version to vesion.
>> 
> 
> As described in the java.util.zp package documentation [1]
> ZipOutputStream is aiming to create zip files according to the
> "Info-ZIP Application Note 970311" [2] with "ZIP64 format extensions"
> [3]. Are you aware of any ZipEntry attributes which won't be valid in
> the target zip file after they have been read from a source zip file.
> I'd be happy to add a warning for them when changing the api
> documentation.
> 
> Best regards,
> Volker
> 
> [1] https://urldefense.com/v3/__http://www.pkware.com/documents/casestudies/APPNOTE.TXT__;!!GqivPVa7Brio!OJfXNZ7-9LMuBGhCX4FjlUeEXLO5uWvKxwcNJXQYhTe4Y9W1-VzQH2Yr4YAGVXwtDA$ <https://urldefense.com/v3/__http://www.pkware.com/documents/casestudies/APPNOTE.TXT__;!!GqivPVa7Brio!OJfXNZ7-9LMuBGhCX4FjlUeEXLO5uWvKxwcNJXQYhTe4Y9W1-VzQH2Yr4YAGVXwtDA$> 
> [2] https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/zip/package-summary.html <https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/zip/package-summary.html>
> [3] https://urldefense.com/v3/__http://www.info-zip.org/doc/appnote-19970311-iz.zip__;!!GqivPVa7Brio!OJfXNZ7-9LMuBGhCX4FjlUeEXLO5uWvKxwcNJXQYhTe4Y9W1-VzQH2Yr4YCEIfG0JQ$ <https://urldefense.com/v3/__http://www.info-zip.org/doc/appnote-19970311-iz.zip__;!!GqivPVa7Brio!OJfXNZ7-9LMuBGhCX4FjlUeEXLO5uWvKxwcNJXQYhTe4Y9W1-VzQH2Yr4YCEIfG0JQ$> 
> 
>> Thanks,
>> Max
>> 
>>> 
>>> Thanks,
>>> Max
>>> 
>>>> 
>>>> Regards,
>>>> Volker
>>>> 
>>>>> Thanks,
>>>>> Max
>>>>> 
>>>>>> On Oct 6, 2020, at 9:56 AM, Volker Simonis <volker.simonis at gmail.com> wrote:
>>>>>> 
>>>>>> On Tue, Oct 6, 2020 at 1:21 PM Lance Andersen <LANCE.ANDERSEN at oracle.com> wrote:
>>>>>>> 
>>>>>>> Hi Volker
>>>>>>> 
>>>>>>> On Oct 6, 2020, at 6:08 AM, Volker Simonis <volker.simonis at gmail.com> wrote:
>>>>>>> 
>>>>>>> On Mon, Oct 5, 2020 at 9:53 PM Lance Andersen <LANCE.ANDERSEN at oracle.com> wrote:
>>>>>>> 
>>>>>>> 
>>>>>>> Hi Volker,
>>>>>>> 
>>>>>>> Thank you for looking into this and creating a draft PR.
>>>>>>> 
>>>>>>> On the surface, I don?t see a reason to introduce a  System property.  What challenges do you see if you used the DataDescriptor unless ZipEntry::setCompressedSize is called?  That seems to address the issue that you discovered without having to introduce a new System property. Or is there an additional concern that is not obvious?  This seems like it would address the problem for existing code that is not well behaved.
>>>>>>> 
>>>>>>> 
>>>>>>> Sure. That's obviously the simplest and best solution and I'd be
>>>>>>> totally happy with it. I just thought there might be a need for
>>>>>>> somehow preserving the old and buggy behaviour, that's why I added the
>>>>>>> system property.
>>>>>>> 
>>>>>>> I've created a simpler version of the fix without property and
>>>>>>> adjusted the @apiNote accordingly:
>>>>>>> 
>>>>>>> 
>>>>>>> Thank you for updating your proposal.  We will need to update the javadoc so that the  description of the change is normative and not part of the API note itself.
>>>>>> 
>>>>>> Changing the updated doc to be normativ instead of just an @apiNote
>>>>>> will make it impossible to downport this change but if you think it is
>>>>>> really necessary I will accept that. I've removed the @apiNote tag
>>>>>> from the java doc and changed the draft PR into a real PR.
>>>>>> 
>>>>>> Without the @apiNote tag I also had to copy the extra documentation
>>>>>> verbatim to JarOutputStream.putNextEntry() which is not very elegant
>>>>>> but inheriting the whole api doc from ZipOutputStream didn't seem
>>>>>> right either. Please let me know if you have a better idea.
>>>>>> 
>>>>>> I'll open a CSR once we've agreed on the exact text for the java doc change.
>>>>>> 
>>>>>> Please let's continue the discussion on the PR or the new mail that
>>>>>> was created for it.
>>>>>> 
>>>>>> Best regards,
>>>>>> Volker
>>>>>> 
>>>>>>> We will also need to create a CSR for the proposed change in the spec and functionality.  I believe we should also create a release note for this change
>>>>>>> 
>>>>>>> Best
>>>>>>> Lance
>>>>>>> 
>>>>>>> 
>>>>>>> https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/520__;!!GqivPVa7Brio!O7epzMWqwxuS6aPQIllYZLdRTncNGXj5ioqVYY72igGBVGZgUGAHlQnCJ8mhzRoAvw$
>>>>>>> 
>>>>>>> Would you be fine with such a solution?
>>>>>>> 
>>>>>>> Thank you and best regards,
>>>>>>> Volker
>>>>>>> 
>>>>>>> The other option is to add an additional method to ZipOutputStream or ZipEntry to address the issue.
>>>>>>> 
>>>>>>> Thoughts?
>>>>>>> 
>>>>>>> Best
>>>>>>> Lance
>>>>>>> 
>>>>>>> On Oct 5, 2020, at 2:13 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>>>>>>> 
>>>>>>> On 05/10/2020 11:04, Volker Simonis wrote:
>>>>>>> 
>>>>>>> :
>>>>>>> 
>>>>>>> I don't
>>>>>>> think the proposal to add a system property to change the behavior is
>>>>>>> feasible, at least not without changing the spec but even then it would
>>>>>>> be very icky.
>>>>>>> 
>>>>>>> Why do you think so? The answer to this question is especially
>>>>>>> important to me because we are considering doing this in our internal
>>>>>>> version independently of upstream OpenJKD (and potentially also in 8 &
>>>>>>> 11).
>>>>>>> 
>>>>>>> Introducing system properties to change the behavior of APIs and "fix" existing code is really icky. For the main line, then I think it would be good to explore the impact of changing the existing putNextEntry or introducing a new API. The compatibility impact of the former may not be significant but I would expect the spec would be clarified as part of this (that is what I was trying to say above). Exploring new APIs would be good and a method on ZipEntry may not be too bad (you have a reference to the target ZOS in the implementation).
>>>>>>> 
>>>>>>> :
>>>>>>> 
>>>>>>> And just as a side note, we also use the "jdk.util.zip.inhibitZip64"
>>>>>>> property in ZipOutputStream for a similar reason. I just wonder how
>>>>>>> that could pass the CCC process as I couldn't even find any
>>>>>>> documentation for it :)
>>>>>>> 
>>>>>>> ZIP64 was very problematic at the time as it wasn't supported by several tools. The system property was introduced to disable the feature/support so that Java applications didn't create ZIP files that other tools couldn't consume. It would be good to get an up to date picture on ZIP64 support as it might be that this switch can be removed. It pre-dates the CSR  process but there was a CCC at the time.
>>>>>>> 
>>>>>>> -Alan
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> Best
>>>>>>> Lance
>>>>>>> ------------------
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
>>>>>>> Oracle Java Engineering
>>>>>>> 1 Network Drive
>>>>>>> Burlington, MA 01803
>>>>>>> Lance.Andersen at oracle.com
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> Best
>>>>>>> Lance
>>>>>>> ------------------
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
>>>>>>> Oracle Java Engineering
>>>>>>> 1 Network Drive
>>>>>>> Burlington, MA 01803
>>>>>>> Lance.Andersen at oracle.com





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





From WEIJUN.WANG at ORACLE.COM  Tue Oct  6 21:46:34 2020
From: WEIJUN.WANG at ORACLE.COM (Weijun Wang)
Date: Tue, 6 Oct 2020 17:46:34 -0400
Subject: Request for Discussion: 8253952: Work around wrong usage of
 ZipOutputStream.putNextEntry() in user code
In-Reply-To: <CA+3eh117LtyddnhWJEhoYCPLXH=9uWAv5GoTOTEXOo+OX=GeJw@mail.gmail.com>
References: <CA+3eh12_-fNxf_KFK68WEqVoD_n6CD7RCbe=LoKCyCeUQ3w0oQ@mail.gmail.com>
 <4658d3a6-3360-fb84-e5ff-20dc6cc61b92@oracle.com>
 <CA+3eh10vr3vs92UPu7PwiaofZpf46QuzsuFf4bvf26gbYKF3-g@mail.gmail.com>
 <99e80b7e-7702-338d-cd92-c9d1a396dfa5@oracle.com>
 <DCBE7C9D-A8CB-4A14-8B79-DEA3BE4B2CA8@ORACLE.COM>
 <CA+3eh125PAxoOAWd+nde4oCnYPOptr=y7arxfRLmy5o0mHpo5g@mail.gmail.com>
 <266D112B-3883-4B6D-886E-1F4CE7641A34@ORACLE.COM>
 <CA+3eh10Tr8NnFaZDfxwq+Pc79AA4XkNOkZpy7epgkExEHw1M5A@mail.gmail.com>
 <0DF68377-AD12-423C-AA29-71B0F20F4D25@ORACLE.COM>
 <CA+3eh12doGmUHU3=uKrm_U+6ahcBNLQVig9bpPJChDcrd1-b=g@mail.gmail.com>
 <078C7AC7-7B93-4ACF-A6ED-80087CB0E18E@ORACLE.COM>
 <BD045667-852F-4CC0-9B1B-0CCDA856B63B@ORACLE.COM>
 <CA+3eh117LtyddnhWJEhoYCPLXH=9uWAv5GoTOTEXOo+OX=GeJw@mail.gmail.com>
Message-ID: <B3917EB8-1775-4CC2-A014-7FFC8C70CB63@ORACLE.COM>



> On Oct 6, 2020, at 1:50 PM, Volker Simonis <volker.simonis at gmail.com> wrote:
> 
> On Tue, Oct 6, 2020 at 6:00 PM Weijun Wang <WEIJUN.WANG at oracle.com> wrote:
>> 
>> 
>> 
>>> On Oct 6, 2020, at 11:42 AM, Weijun Wang <WEIJUN.WANG at ORACLE.COM> wrote:
>>> 
>>> 
>>> 
>>>> On Oct 6, 2020, at 10:48 AM, Volker Simonis <volker.simonis at gmail.com> wrote:
>>>> 
>>>> On Tue, Oct 6, 2020 at 4:21 PM Weijun Wang <WEIJUN.WANG at oracle.com> wrote:
>>>>> 
>>>>> Hi Volker,
>>>>> 
>>>>> The size unmatch could throw an exception, but writing an existing ZipEntry into a new ZipOutputStream could have other side effects, including time, comment, and other things we added recently, like POSIX permissions and file type flag (is it a symlink?). Do you meant to copy all these things to the new entry automatically?
>>>>> 
>>>> 
>>>> Hi Max,
>>>> 
>>>> this proposed change is just about fixing the unmatch for the
>>>> compressed size attribute. All the other fields will be left
>>>> untouched.
>>>> 
>>>> Do you see similar problems with other fields which should be
>>>> addressed in a similar way or do you just want to make sure that all
>>>> the other fields are passed and processed correctly?
>>> 
>>> No.
>>> 
>>> I was just saying your code change could encourage more people to use the bad code pattern and it might have other unexpected behaviors. Even the zip command requires this or that option to copy certain attributes. For example, should symlinks always be copied as symlinks?
>> 
>> Sorry, my comparison is not precise. The zip tool is adding files to a zip but your code change is about copying existing zip entries.
>> 
>> Still, I wish people are aware that other attributes are copied as well, and they could be different from version to vesion.
>> 
> 
> As described in the java.util.zp package documentation [1]
> ZipOutputStream is aiming to create zip files according to the
> "Info-ZIP Application Note 970311" [2] with "ZIP64 format extensions"
> [3]. Are you aware of any ZipEntry attributes which won't be valid in
> the target zip file after they have been read from a source zip file.

No.

Maybe it?s just that we have being doing this with the ?correct way? too long (in jar ?update and jarsigner), and I cannot help worrying what problem it might cause.

With this problem resolved, do you still think this is a ?bad coding pattern??

Thanks,
Max

> I'd be happy to add a warning for them when changing the api
> documentation.
> 
> Best regards,
> Volker
> 
> [1] https://urldefense.com/v3/__http://www.pkware.com/documents/casestudies/APPNOTE.TXT__;!!GqivPVa7Brio!MApVADAAXvhn79VDKgHNs4bAGksVrN6zvPNYQ3YkeSP9exgdNXwBtda7c6Fsuup9_A$ 
> [2] https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/zip/package-summary.html
> [3] https://urldefense.com/v3/__http://www.info-zip.org/doc/appnote-19970311-iz.zip__;!!GqivPVa7Brio!MApVADAAXvhn79VDKgHNs4bAGksVrN6zvPNYQ3YkeSP9exgdNXwBtda7c6GMEWjHoQ$ 
> 
>> Thanks,
>> Max
>> 
>>> 
>>> Thanks,
>>> Max
>>> 
>>>> 
>>>> Regards,
>>>> Volker
>>>> 
>>>>> Thanks,
>>>>> Max
>>>>> 
>>>>>> On Oct 6, 2020, at 9:56 AM, Volker Simonis <volker.simonis at gmail.com> wrote:
>>>>>> 
>>>>>> On Tue, Oct 6, 2020 at 1:21 PM Lance Andersen <LANCE.ANDERSEN at oracle.com> wrote:
>>>>>>> 
>>>>>>> Hi Volker
>>>>>>> 
>>>>>>> On Oct 6, 2020, at 6:08 AM, Volker Simonis <volker.simonis at gmail.com> wrote:
>>>>>>> 
>>>>>>> On Mon, Oct 5, 2020 at 9:53 PM Lance Andersen <LANCE.ANDERSEN at oracle.com> wrote:
>>>>>>> 
>>>>>>> 
>>>>>>> Hi Volker,
>>>>>>> 
>>>>>>> Thank you for looking into this and creating a draft PR.
>>>>>>> 
>>>>>>> On the surface, I don?t see a reason to introduce a  System property.  What challenges do you see  if you used the DataDescriptor unless ZipEntry::setCompressedSize is called?  That seems to address the issue that you discovered without having to introduce a new System property. Or is there an additional concern that is not obvious?  This seems like it would address the problem for existing code that is not well behaved.
>>>>>>> 
>>>>>>> 
>>>>>>> Sure. That's obviously the simplest and best solution and I'd be
>>>>>>> totally happy with it. I just thought there might be a need for
>>>>>>> somehow preserving the old and buggy behaviour, that's why I added the
>>>>>>> system property.
>>>>>>> 
>>>>>>> I've created a simpler version of the fix without property and
>>>>>>> adjusted the @apiNote accordingly:
>>>>>>> 
>>>>>>> 
>>>>>>> Thank you for updating your proposal.  We will need to update the javadoc so that the  description of the change is normative and not part of the API note itself.
>>>>>> 
>>>>>> Changing the updated doc to be normativ instead of just an @apiNote
>>>>>> will make it impossible to downport this change but if you think it is
>>>>>> really necessary I will accept that. I've removed the @apiNote tag
>>>>>> from the java doc and changed the draft PR into a real PR.
>>>>>> 
>>>>>> Without the @apiNote tag I also had to copy the extra documentation
>>>>>> verbatim to JarOutputStream.putNextEntry() which is not very elegant
>>>>>> but inheriting the whole api doc from ZipOutputStream didn't seem
>>>>>> right either. Please let me know if you have a better idea.
>>>>>> 
>>>>>> I'll open a CSR once we've agreed on the exact text for the java doc change.
>>>>>> 
>>>>>> Please let's continue the discussion on the PR or the new mail that
>>>>>> was created for it.
>>>>>> 
>>>>>> Best regards,
>>>>>> Volker
>>>>>> 
>>>>>>> We will also need to create a CSR for the proposed change in the spec and functionality.  I believe we should also create a release note for this change
>>>>>>> 
>>>>>>> Best
>>>>>>> Lance
>>>>>>> 
>>>>>>> 
>>>>>>> https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/520__;!!GqivPVa7Brio!O7epzMWqwxuS6aPQIllYZLdRTncNGXj5ioqVYY72igGBVGZgUGAHlQnCJ8mhzRoAvw$
>>>>>>> 
>>>>>>> Would you be fine with such a solution?
>>>>>>> 
>>>>>>> Thank you and best regards,
>>>>>>> Volker
>>>>>>> 
>>>>>>> The other option is to add an additional method to ZipOutputStream or ZipEntry to address the issue.
>>>>>>> 
>>>>>>> Thoughts?
>>>>>>> 
>>>>>>> Best
>>>>>>> Lance
>>>>>>> 
>>>>>>> On Oct 5, 2020, at 2:13 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>>>>>>> 
>>>>>>> On 05/10/2020 11:04, Volker Simonis wrote:
>>>>>>> 
>>>>>>> :
>>>>>>> 
>>>>>>> I don't
>>>>>>> think the proposal to add a system property to change the behavior is
>>>>>>> feasible, at least not without changing the spec but even then it would
>>>>>>> be very icky.
>>>>>>> 
>>>>>>> Why do you think so? The answer to this question is especially
>>>>>>> important to me because we are considering doing this in our internal
>>>>>>> version independently of upstream OpenJKD (and potentially also in 8 &
>>>>>>> 11).
>>>>>>> 
>>>>>>> Introducing system properties to change the behavior of APIs and "fix" existing code is really icky. For the main line, then I think it would be good to explore the impact of changing the existing putNextEntry or introducing a new API. The compatibility impact of the former may not be significant but I would expect the spec would be clarified as part of this (that is what I was trying to say above). Exploring new APIs would be good and a method on ZipEntry may not be too bad (you have a reference to the target ZOS in the implementation).
>>>>>>> 
>>>>>>> :
>>>>>>> 
>>>>>>> And just as a side note, we also use the "jdk.util.zip.inhibitZip64"
>>>>>>> property in ZipOutputStream for a similar reason. I just wonder how
>>>>>>> that could pass the CCC process as I couldn't even find any
>>>>>>> documentation for it :)
>>>>>>> 
>>>>>>> ZIP64 was very problematic at the time as it wasn't supported by several tools. The system property was introduced to disable the feature/support so that Java applications didn't create ZIP files that other tools couldn't consume. It would be good to get an up to date picture on ZIP64 support as it might be that this switch can be removed. It pre-dates the CSR  process but there was a CCC at the time.
>>>>>>> 
>>>>>>> -Alan
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> Best
>>>>>>> Lance
>>>>>>> ------------------
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
>>>>>>> Oracle Java Engineering
>>>>>>> 1 Network Drive
>>>>>>> Burlington, MA 01803
>>>>>>> Lance.Andersen at oracle.com
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> Best
>>>>>>> Lance
>>>>>>> ------------------
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
>>>>>>> Oracle Java Engineering
>>>>>>> 1 Network Drive
>>>>>>> Burlington, MA 01803
>>>>>>> Lance.Andersen at oracle.com


From bchristi at openjdk.java.net  Tue Oct  6 22:51:06 2020
From: bchristi at openjdk.java.net (Brent Christian)
Date: Tue, 6 Oct 2020 22:51:06 GMT
Subject: RFR: 8254095: remove jdk.test.lib.Utils::distro() method
In-Reply-To: <JmMVhacA8DG5S5MpveRfq6DBOg8WcyDHbKTbMR1AXc4=.6ea99fb5-0f72-4d83-aba7-634825c1a380@github.com>
References: <JmMVhacA8DG5S5MpveRfq6DBOg8WcyDHbKTbMR1AXc4=.6ea99fb5-0f72-4d83-aba7-634825c1a380@github.com>
Message-ID: <EsooPp6Ay6Ktax3A59ntLyQCMM2gYiF2ExW6jJEKLRg=.9346aee9-8579-4414-a336-d1360b5db2d4@github.com>

On Tue, 6 Oct 2020 20:47:10 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this trivial cleanup? from JBS:
>> jdk.test.lib.Utils::distro() is not used by any of the tests and can be removed.
> 
> Thanks,
> -- Igor

Looks good to me.

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

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

From bchristi at openjdk.java.net  Tue Oct  6 23:01:06 2020
From: bchristi at openjdk.java.net (Brent Christian)
Date: Tue, 6 Oct 2020 23:01:06 GMT
Subject: RFR: 8254095: remove jdk.test.lib.Utils::distro() method
In-Reply-To: <JmMVhacA8DG5S5MpveRfq6DBOg8WcyDHbKTbMR1AXc4=.6ea99fb5-0f72-4d83-aba7-634825c1a380@github.com>
References: <JmMVhacA8DG5S5MpveRfq6DBOg8WcyDHbKTbMR1AXc4=.6ea99fb5-0f72-4d83-aba7-634825c1a380@github.com>
Message-ID: <_vHhJCsLIGcTr4cEV7zZ-F54HCPs_dApITgRI0SphH8=.ab94bb15-1534-4cfc-8fad-60b2db81ee03@github.com>

On Tue, 6 Oct 2020 20:47:10 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this trivial cleanup? from JBS:
>> jdk.test.lib.Utils::distro() is not used by any of the tests and can be removed.
> 
> Thanks,
> -- Igor

Marked as reviewed by bchristi (Reviewer).

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

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

From iignatyev at openjdk.java.net  Tue Oct  6 23:01:06 2020
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Tue, 6 Oct 2020 23:01:06 GMT
Subject: RFR: 8254095: remove jdk.test.lib.Utils::distro() method
In-Reply-To: <_vHhJCsLIGcTr4cEV7zZ-F54HCPs_dApITgRI0SphH8=.ab94bb15-1534-4cfc-8fad-60b2db81ee03@github.com>
References: <JmMVhacA8DG5S5MpveRfq6DBOg8WcyDHbKTbMR1AXc4=.6ea99fb5-0f72-4d83-aba7-634825c1a380@github.com>
 <_vHhJCsLIGcTr4cEV7zZ-F54HCPs_dApITgRI0SphH8=.ab94bb15-1534-4cfc-8fad-60b2db81ee03@github.com>
Message-ID: <nZKR9QA47iTzsST-qh2oXrtZHmJvM1A5WRopWLHv28o=.9c1aa6e2-5e3c-4a11-a091-95f43341bbe0@github.com>

On Tue, 6 Oct 2020 22:56:03 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Hi all,
>> 
>> could you please review this trivial cleanup? from JBS:
>>> jdk.test.lib.Utils::distro() is not used by any of the tests and can be removed.
>> 
>> Thanks,
>> -- Igor
>
> Marked as reviewed by bchristi (Reviewer).

Thanks, Brent.

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

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

From iignatyev at openjdk.java.net  Tue Oct  6 23:01:07 2020
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Tue, 6 Oct 2020 23:01:07 GMT
Subject: Integrated: 8254095: remove jdk.test.lib.Utils::distro() method
In-Reply-To: <JmMVhacA8DG5S5MpveRfq6DBOg8WcyDHbKTbMR1AXc4=.6ea99fb5-0f72-4d83-aba7-634825c1a380@github.com>
References: <JmMVhacA8DG5S5MpveRfq6DBOg8WcyDHbKTbMR1AXc4=.6ea99fb5-0f72-4d83-aba7-634825c1a380@github.com>
Message-ID: <qJGdp6Rren9yb5L3XBALkVXOnHfvL5rNiQNZFrZTx84=.0496192f-dbc0-4041-a514-0c1a838e6797@github.com>

On Tue, 6 Oct 2020 20:47:10 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this trivial cleanup? from JBS:
>> jdk.test.lib.Utils::distro() is not used by any of the tests and can be removed.
> 
> Thanks,
> -- Igor

This pull request has now been integrated.

Changeset: 2a0389a8
Author:    Igor Ignatyev <iignatyev at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/2a0389a8
Stats:     11 lines in 1 file changed: 0 ins; 11 del; 0 mod

8254095: remove jdk.test.lib.Utils::distro() method

Reviewed-by: bchristi

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

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

From iignatyev at openjdk.java.net  Tue Oct  6 23:23:11 2020
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Tue, 6 Oct 2020 23:23:11 GMT
Subject: RFR: 8254102: use ProcessHandle::pid instead of
 ManagementFactory::getRuntimeMXBean to get pid in tests
Message-ID: <aQOzr1zN3WrL11gTkWFkGrkDVRxwQOrM8XbsMk6_0Cc=.42c65bd7-68bd-4bbb-9b30-ecbf01982332@github.com>

Hi all,

could you please review this small cleanup which replaces
`ManagementFactory.getRuntimeMXBean().getName().split("@")[0]` w/ `ProcessHandle.current().pid()` to get current
process pid?

Thanks,
-- Igor

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

Commit messages:
 - update copyright
 - use ProcessHandle::pid instead of ManagementFactory::getRuntimeMXBean to get pid

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

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

From mchung at openjdk.java.net  Tue Oct  6 23:42:14 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 6 Oct 2020 23:42:14 GMT
Subject: RFR: 8159746: (proxy) Support for default methods
In-Reply-To: <GSeWP29fAIUFSk0CYsC557w52CuLqeUWwHNK9maltwI=.3d5f002e-6b74-4a57-a5d8-244d27da9dde@github.com>
References: <kw2VXh3vTFf1zgfd4biXA41OKffZ5oU7KT23tXAxgUA=.bcf14ffc-4dba-4c9c-8754-184172c5acbd@github.com>
 <U-6RiCpFVIrhLztPN6opiPcpFtxValDzU-K7WWFZM-4=.6bc8aaa4-636a-4664-b380-4c4af00513bd@github.com>
 <-cLIJ8pFHtnNoJMHV3aXI7XMJWp4Jrutc8Xn5PG0OK8=.d2cd87ab-3592-4524-ad85-05444c43689b@github.com>
 <r0UK2qjnmgeTNDDSWaSLPAj3QRgx_4YB82ielllO7jM=.fa615bc0-db49-4a74-b842-793f8f5209bb@github.com>
 <1T8kXDZN1bhHr4c8v4SQsImeBySCqTfX-u3_jzvyocA=.b4957400-9a33-4b6e-8475-329642a5888c@github.com>
 <XIux-dY0JXHRafHk48kVNXId9r-HSceNSytBojDxelY=.872e74cb-b064-406e-b71f-13c90ec7fbbc@github.com>
 <j4t2vT0SnwnU7lhKRlXtk967d-K6nA0EqHrqNbba7W0=.dc05dba6-bf7e-4606-8a02-9c2bad4b3b58@github.com>
 <fmVtPcBdgMuZOPm2qx3Q3znVZM7JgQPkhPAVLtwkOhE=.2d8b8447-cfae-4cb3-9a7c-6567a881231f@github.com>
 <GSeWP29fAIUFSk0CYsC557w52CuLqeUWwHNK9maltwI=.3d5f002e-6b74-4a57-a5d8-244d27da9dde@github.com>
Message-ID: <GF8iEOkMUEL2dYB0HytFIc9gyeeUJ_KP0ImlqFsul2Y=.894afc05-9310-43e1-a308-8f7d71dc572b@github.com>

On Wed, 30 Sep 2020 19:11:37 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> The https://github.com/mlchung/jdk/pull/1 has been updated.
>
> @plevart  I have merged your PR and made minor tweak.
> 
> Please review CSR:  https://bugs.openjdk.java.net/browse/JDK-8253870

Joe has given some feedback in the CSR review.
> should this functionality be housed in the InvocationHandler interface rather than the Proxy class? If I understand the
> intended usage of the new method, it should only be done in an InvocationHandler.

The primary usage of this new method is `InvocationHandler`.  I agree that the new API should be defined in
`InvocationHandler`.

@plevart @AlanBateman any feedback or thought on moving the new API to `InvocationHandler`?

> Does the current spec handle a case like interface A declares a default method m, interface B extends A and separately
> interface B declare a default method m.

Yes

> Would invokeDefaultMethod on A::m do-what-is-wanted by call the default method inherited from A? Indirectly, this is
> also a question if the operation that are binary compatible with respect to moving around default methods and
> behaviorally compatible with the semantics of the new method.

If a proxy instance implements both A and B, `invokeDefaultMethod(o, A.class.getMethod("m"), params)` will invoke
`A::m`.

If a proxy instance implements B only, `invokeDefaultMethod(o, A.class.getMethod("m"), params)` will get IAE thrown.
This is consistent with a concrete class implements B that can only call `B.super::m` but not `A::m`.

I update the javadoc to clarify this.

> Any special cases for hidden classes?

No because proxy cannot implement a hidden proxy interface as specified in `Proxy::newProxyInstance`

IllegalArgumentException will be thrown if any of the following restrictions is violated:

- All of Class objects in the given interfaces array must represent non-hidden interfaces, not classes or primitive types.

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

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

From bpb at openjdk.java.net  Wed Oct  7 00:00:21 2020
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 7 Oct 2020 00:00:21 GMT
Subject: RFR: 8067127: Tags cleanup [v2]
In-Reply-To: <8YR2pzHDTetS1LChJUDvPtgo_LdMBZggFfmkdLl-HO4=.8016f8e2-aa1f-429f-a744-798807c7964e@github.com>
References: <8YR2pzHDTetS1LChJUDvPtgo_LdMBZggFfmkdLl-HO4=.8016f8e2-aa1f-429f-a744-798807c7964e@github.com>
Message-ID: <Pl9pN_PNxl_5U5YiuUeieWEBeSzbgKZe6BgJbeFcd78=.83ac1dcd-34fd-4202-b017-77c130fce15d@github.com>

> Please review this change to update some javadoc tags in the java.io package. The changes are to replace some
> occurrences of <code>some_code</code> with {@code some_code}. Not all such constructs were replaced as being
> infeasible, e.g., tag contains an entity such as <code>*&#47;</code> (DataOutput, Serial), or multiple {@code} tags
> would be needed or the result would be ugly (File). It is unclear whether some of the changes which remove the
> non-breaking space entity (&nbsp;) are desirable.  Thanks,  Brian

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

 - Merge branch 'JDK-8067127-java-io-tags-cleanup' of https://github.com/bplb/jdk into JDK-8067127-java-io-tags-cleanup
 - 8067127: Tags cleanup

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/513/files
  - new: https://git.openjdk.java.net/jdk/pull/513/files/2e9b0770..3cbb98d4

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

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

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

From rriggs at openjdk.java.net  Wed Oct  7 02:02:05 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 7 Oct 2020 02:02:05 GMT
Subject: RFR: 8254102: use ProcessHandle::pid instead of
 ManagementFactory::getRuntimeMXBean to get pid in tests
In-Reply-To: <aQOzr1zN3WrL11gTkWFkGrkDVRxwQOrM8XbsMk6_0Cc=.42c65bd7-68bd-4bbb-9b30-ecbf01982332@github.com>
References: <aQOzr1zN3WrL11gTkWFkGrkDVRxwQOrM8XbsMk6_0Cc=.42c65bd7-68bd-4bbb-9b30-ecbf01982332@github.com>
Message-ID: <5OaD6gBX9nmmX_N690gLnHefPo4bk9z3D-WqGwD3kXA=.32b936f9-c795-49c6-b158-90845eadcd45@github.com>

On Tue, 6 Oct 2020 23:08:40 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small cleanup which replaces
> `ManagementFactory.getRuntimeMXBean().getName().split("@")[0]` w/ `ProcessHandle.current().pid()` to get current
> process pid?  Thanks,
> -- Igor

All of these changes can call `ProcessHandle.current().toString()` to return pid of the current process.

test/failure_handler/test/sanity/Suicide.java line 36:

> 34:             String osName = System.getProperty("os.name");
> 35:             if (osName.contains("Windows")) {
> 36:                 cmd = "taskkill.exe /F /PID " + pidStr;

This can be simplified to ProcessHandle.current().toString().  It returns the pid of the process as a string.

Explicitly converting it to a string is not necessary.  The "+" concatenation would convert the number to a string.

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

Changes requested by rriggs (Reviewer).

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

From sspitsyn at openjdk.java.net  Wed Oct  7 04:31:16 2020
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Wed, 7 Oct 2020 04:31:16 GMT
Subject: RFR: 8227745: Enable Escape Analysis for Better Performance in
 the Presence of JVMTI Agents [v3]
In-Reply-To: <HYavlFjjBvmmW2N-aWpAUX10tS-cnZrjLhPccnWfQ7w=.9e7ad979-7b1c-43db-943d-f273c747ab8f@github.com>
References: <Ll2RereRbuQLgFtIjv9pS92kPvCVuo-BI0cP1zGjVbo=.dad3a33c-0fc3-44fd-810a-f01448cf564c@github.com>
 <D80z7im-ptE_UXYRfivkezq-W4ZuWkPwKOoT0MW1mxA=.676cae36-4e0f-473d-b577-21317f3c3ab3@github.com>
 <Pz8cdgFTXmF954txrAnk3whnhkeR2y6gTNiSTRC_CrY=.e3460eb4-d1dc-4621-b056-b0a46f4f6569@github.com>
 <i5Y6k8vBZUKKUCrUkaR8ux26ZBgy80UziZj0p2lYUuo=.e368568c-bbc8-4c63-bd23-847e7e008946@github.com>
 <ayyzITSxaqlsU0Ch0uLnooOLlr_Xn8dXRQHGLY3Qy40=.b2589ff3-a00f-44ed-973b-2087a35b542c@github.com>
 <HYavlFjjBvmmW2N-aWpAUX10tS-cnZrjLhPccnWfQ7w=.9e7ad979-7b1c-43db-943d-f273c747ab8f@github.com>
Message-ID: <ku12sbw0RalOiY9-0UzhjsM97LFWLyW13GecYR0p1fc=.81bbd251-a72f-45e6-9adb-aba6e6d2fa05@github.com>

On Tue, 6 Oct 2020 14:06:35 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> Hi Serguei,
>> 
>> thanks for providing feedback! I've pushed the changes based on it now but I
>> have not yet merged master again. This needs a little work...
>> 
>> Please find my replies to your comments below.
>> 
>> Thanks, Richard.
>> 
>>> Could you consider to place the classes EscapeBarrier and JvmtiDeferredUpdates
>>> into theyr own .hpp/.cpp files? The class JvmtiDeferredUpdates would be better
>>> to put into the folder 'prims' then.
>> 
>> Done. In addition I moved preexisting class jvmtiDeferredLocalVariableSet and
>> class jvmtiDeferredLocalVariable from runtime/vframe_hp.hpp to
>> prims/jvmtiDeferredUpdates.hpp. Please let me know if not ok.
>> 
>>> src/hotspot/share/opto/macro.cpp:
>>> 
>>> ```
>>> @@ -1091,11 +1091,11 @@
>>>  bool PhaseMacroExpand::eliminate_allocate_node(AllocateNode *alloc) {
>>>    // Don't do scalar replacement if the frame can be popped by JVMTI:
>>>    // if reallocation fails during deoptimization we'll pop all
>>>    // interpreter frames for this compiled frame and that won't play
>>>    // nice with JVMTI popframe.
>>> -  if (!EliminateAllocations || JvmtiExport::can_pop_frame() || !alloc->_is_non_escaping) {
>>> +  if (!EliminateAllocations || !alloc->_is_non_escaping) {
>>>      return false;
>>>    }
>>> ```
>>> 
>>> I wonder if the comment is still correct after you removed the check for JvmtiExport::can_pop_frame().
>> 
>> Good catch. I fixed it previously with
>> https://github.com/openjdk/jdk/pull/119/commits/18dd54b4e6f17ca723e4ae1a1e8dc57e81878dd3
>> 
>>> src/hotspot/share/runtime/deoptimization.hpp:
>>> 
>>> ```
>>> +  EscapeBarrier(JavaThread* calling_thread, JavaThread* deoptee_thread, bool barrier_active)
>>> +    : _calling_thread(calling_thread), _deoptee_thread(deoptee_thread),
>>> +      _barrier_active(barrier_active && (JVMCI_ONLY(UseJVMCICompiler) NOT_JVMCI(false)
>>> +                      COMPILER2_PRESENT(|| DoEscapeAnalysis)))
>>> . . . . . . . . .
>>> +
>>> +  // Revert ea based optimizations for all java threads
>>> +  EscapeBarrier(JavaThread* calling_thread, bool barrier_active)
>>> +    : _calling_thread(calling_thread), _deoptee_thread(NULL),
>>> ```
>>> 
>>> Nit: would better to make the parameter deoptee_thread to be the 3rd to better mach the seconf constructor.
>> 
>> I have shuffled the parameters and moved barrier_active at first position. Would
>> that be ok?
>> 
>>> 
>>> ```
>>> +  bool all_threads()    const { return _deoptee_thread == NULL; }            // Should revert optimizations for all
>>> threads. +  bool self_deopt()     const { return _calling_thread == _deoptee_thread; } // Current thread deoptimizes
>>> its own objects. +  bool barrier_active() const { return _barrier_active; }                    // Inactive barriers are
>>> created if no local objects can escape. ```
>>> 
>>> I'd suggest to put comments in a line before function definitions as it is done for other declarations/definitions.
>> 
>> Done. // Note that there are quite a few locations with the comment on the same line ;)
>> 
>>> src/hotspot/share/runtime/deoptimization.cpp:
>>> 
>>> ```
>>>  @@ -349,12 +408,12 @@
>>>  
>>>    // Now that the vframeArray has been created if we have any deferred local writes
>>>    // added by jvmti then we can free up that structure as the data is now in the
>>>    // vframeArray
>>>  
>>> -  if (thread->deferred_locals() != NULL) {
>>> -    GrowableArray<jvmtiDeferredLocalVariableSet*>* list = thread->deferred_locals();
>>> +  if (JvmtiDeferredUpdates::deferred_locals(thread) != NULL) {
>>> +    GrowableArray<jvmtiDeferredLocalVariableSet*>* list = JvmtiDeferredUpdates::deferred_locals(thread);
>>>      int i = 0;
>>>      do {
>>>        // Because of inlining we could have multiple vframes for a single frame
>>>        // and several of the vframes could have deferred writes. Find them all.
>>>        if (list->at(i)->id() == array->original().id()) {
>>> 
>>> @@ -365,13 +424,14 @@
>>>        } else {
>>>          i++;
>>>        }
>>>      } while ( i < list->length() );
>>>      if (list->length() == 0) {
>>> -      thread->set_deferred_locals(NULL);
>>> -      // free the list and elements back to C heap.
>>> -      delete list;
>>> +      JvmtiDeferredUpdates* updates = thread->deferred_updates();
>>> +      thread->set_deferred_updates(NULL);
>>> +      // free deferred updates.
>>> +      delete updates;
>>>      }
>>> ```
>>> 
>>> It is not clear why the 'list' is not deleted anymore. If it is intentional then could you, please, add a comment with
>>> an explanation?
>> 
>> 'list' is now embedded in JvmtiDeferredUpdates. It es deleted as part of the
>> JvmtiDeferredUpdates instance when there are no more deferred updates.
>> 
>> class JvmtiDeferredUpdates : public CHeapObj<mtCompiler> {
>> 
>>   [...]
>> 
>>   // Deferred updates of locals, expressions, and monitors
>>   GrowableArray<jvmtiDeferredLocalVariableSet*> _deferred_locals_updates;
>> 
>>   [...]
>> 
>> };
>> 
>> I introduced JvmtiDeferredUpdates because this patch introduces a new type of
>> deferred update: _relock_count_after_wait.
>> 
>> I tried to improve the encapsulation of class JvmtiDeferredUpdates and
>> simplified the location you are referring to.
>> 
>> So when is memory for deferred updates freed?
>> 
>> (A) Deferred local variable updates are deleted when the compiled target frame is
>>     replaced with corresponding interpreter frames.
>>     See JvmtiDeferredUpdates::delete_updates_for_frame().
>> 
>> (B) A thread's JvmtiDeferredUpdates instance is deleted if all updates where
>>     delivered. All updates where delivered when JvmtiDeferredUpdates::count()
>>     returns 0. This is checked whenever updates are delivered. See call sites in
>>     JvmtiDeferredUpdates::delete_updates_for_frame() and
>>     JvmtiDeferredUpdates::get_and_reset_relock_count_after_wait().
>> 
>> (C) Besides (B) a thread's JvmtiDeferredUpdates instance is also deleted when
>>     the thread is destroyed. All not yet delivered updates are deleted then
>>     too. See JavaThread::~JavaThread() and JvmtiDeferredUpdates::~JvmtiDeferredUpdates().
>> 
>>> If you are okay to separate the EscapeBarrier class into its own hpp/cpp files
>>> then the class EscapeBarrierSuspendHandshake is better to be colocated with
>>> it.
>> 
>> Done.
>> 
>>> The below functions EscapeBarrier::sync_and_suspend_one() and do_thread() make a call to the set_obj_deopt_flag() which
>>> seems to be a duplication. At least, it is not clear why this duplication exist and so, needs to be explained in a
>>> comment.  ```
>>> +void EscapeBarrier::sync_and_suspend_one() {
>>> +  assert(_calling_thread != NULL, "calling thread must not be NULL");
>>> +  assert(_deoptee_thread != NULL, "deoptee thread must not be NULL");
>>> +  assert(barrier_active(), "should not call");
>>> +
>>> +  // Sync with other threads that might be doing deoptimizations
>>> +  {
>>> +    // Need to switch to _thread_blocked for the wait() call
>>> +    ThreadBlockInVM tbivm(_calling_thread);
>>> +    MonitorLocker ml(_calling_thread, EscapeBarrier_lock, Mutex::_no_safepoint_check_flag);
>>> +    while (_self_deoptimization_in_progress || _deoptee_thread->is_obj_deopt_suspend()) {
>>> +      ml.wait();
>>> +    }
>>> +
>>> +    if (self_deopt()) {
>>> +      _self_deoptimization_in_progress = true;
>>> +      return;
>>> +    }
>>> +
>>> +    // set suspend flag for target thread
>>> +    _deoptee_thread->set_obj_deopt_flag();
>>> +  }
>>> +
>>> +  // suspend target thread
>>> +  EscapeBarrierSuspendHandshake sh(NULL, "EscapeBarrierSuspendOne");
>>> +  Handshake::execute_direct(&sh, _deoptee_thread);
>>> +  assert(!_deoptee_thread->has_last_Java_frame() || _deoptee_thread->frame_anchor()->walkable(),
>>> +         "stack should be walkable now");
>>> +}
>>> . . . . .
>>> +class EscapeBarrierSuspendHandshake : public HandshakeClosure {
>>> +  JavaThread* _excluded_thread;
>>> + public:
>>> +  EscapeBarrierSuspendHandshake(JavaThread* excluded_thread, const char* name) :
>>> +    HandshakeClosure(name),
>>> +    _excluded_thread(excluded_thread) {}
>>> +  void do_thread(Thread* th) {
>>> +    if (th->is_Java_thread() && !th->is_hidden_from_external_view() && (th != _excluded_thread)) {
>>> +      th->set_obj_deopt_flag();
>>> +    }
>>> +  }
>>> +};
>>> ```
>> 
>> I previously removed the set_obj_deopt_flag() call from
>> EscapeBarrierSuspendHandshake::do_thread() in [1]. For synchronization it is
>> better to set_obj_deopt_flag() before the handshake (see comment in
>> EscapeBarrier::sync_and_suspend_all()).
>> 
>> [1] https://github.com/openjdk/jdk/pull/119/commits/18dd54b4e6f17ca723e4ae1a1e8dc57e81878dd3
>> 
>>> /src/hotspot/share/prims/jvmtiImpl.cpp:
>>> 
>>> ```
>>> 421 // Constructor for non-object getter
>>>  422 VM_GetOrSetLocal::VM_GetOrSetLocal(JavaThread* thread, jint depth, jint index, BasicType type)
>>>  423   : _thread(thread)
>>>  424   , _calling_thread(NULL)
>>>  425   , _depth(depth)
>>>  426   , _index(index)
>>>  427   , _type(type)
>>>  428   , _jvf(NULL)
>>>  429   , _set(false)
>>>  430   , _eb(NULL, NULL, type == T_OBJECT)
>>>  431   , _result(JVMTI_ERROR_NONE)
>>>  432 {
>>>  433 }
>>>  434
>>>  435 // Constructor for object or non-object setter
>>>  436 VM_GetOrSetLocal::VM_GetOrSetLocal(JavaThread* thread, jint depth, jint index, BasicType type, jvalue value)
>>>  437   : _thread(thread)
>>>  438   , _calling_thread(NULL)
>>>  439   , _depth(depth)
>>>  440   , _index(index)
>>>  441   , _type(type)
>>>  442   , _value(value)
>>>  443   , _jvf(NULL)
>>>  444   , _set(true)
>>>  445   , _eb(JavaThread::current(), thread, type == T_OBJECT)
>>>  446   , _result(JVMTI_ERROR_NONE)
>>>  447 {
>>>  448 }
>>>  449
>>>  450 // Constructor for object getter
>>>  451 VM_GetOrSetLocal::VM_GetOrSetLocal(JavaThread* thread, JavaThread* calling_thread, jint depth, int index)
>>>  452   : _thread(thread)
>>>  453   , _calling_thread(calling_thread)
>>>  454   , _depth(depth)
>>>  455   , _index(index)
>>>  456   , _type(T_OBJECT)
>>>  457   , _jvf(NULL)
>>>  458   , _set(false)
>>>  459   , _eb(calling_thread, thread, true)
>>>  460   , _result(JVMTI_ERROR_NONE)
>>>  461 {
>>>  462 }
>>> ```
>>> 
>>> I think, false has to be passed to the constructors of non-object getters instead of expression:
>>> "type == T_OBJECT".
>>> The type can not be T_OBJECT for non-object getters.
>> 
>> I used to do that. Then I changed it because the c++ compiler can fold the
>> comparison to "false" and if somebody changes the non-object getter to get
>> objects too then it would still be correct.
>> 
>> Let me know if you still think it is better to pass false. Maybe add an
>> assertion type == T_OBJECT then?
>> 
>>> Q: Is an EscapeBarrier useful if false is passed as the barrier_active parameter?
>> 
>> The EscapeBarrier is not needed then. In the case of the non-object getter above
>> I'd hope that most of the constructor/desctructor of EscapeBarrier is eliminated
>> by the c++ compiler then.
>> 
>> Besides the changes you suggested I have made a bugfix in
>> test/jdk/com/sun/jdi/EATests.java to prevent ObjectCollectedException.
>> 
>> Thanks, Richard.
>
> Hi Serguei
> (@sspitsyn)
> 
> are you ok with the changes I made based on your comments?
> Will you further review the change?
> 
> Thanks, Richard.

Hi Richard,

Thank you for making the refactoring. I like it more now. :)
So, the fix looks good to me in general.

But could I ask you, to adjust some formatting, please?
There are several things that can be done to improve the code readability.

src/hotspot/share/prims/jvmtiDeferredUpdates.hpp:

I'd suggest to add an empty line before lines 40, 71, 73, 93, 95, 109 to make class definitions and function
declarations/definitions with comments more catchable by eyes. The following lines can be removed: 81, 82, 103

Also, there is inconsistency in function definitions formatting:
 - some functions have big indent between the type and name
 - some functions have no indent between the type and name but a big indent between name and body
I'd suggest to either to remove all indents or make it reasonably smaller but consistent.

It seems, there is no reason to keep these class declarations:
 38 class jvmtiDeferredLocalVariable;
108 class jvmtiDeferredLocalVariableSet;

src/hotspot/share/prims/jvmtiDeferredUpdates.cpp:

 82       // Free deferred updates.
 83       // (Note the 'list' of local variable updates is embedded in 'updates')

A suggestion to change the line 83 as follows:
` 83       // Note, the 'list' of local variable updates is embedded in 'updates'.`

src/hotspot/share/runtime/escapeBarrier.hpp:

Add dots at the end of comments at lines 97, 99, 103.
I'd suggest to add an empty line before lines 39, 40, 80, 81, 93, 94, 99, 119, 121.

src/hotspot/share/runtime/escapeBarrier.cpp:

The following class declaration is not needed:
` 49 class jvmtiDeferredLocalVariableSet;`

because you already added this line:
` 29 #include "prims/jvmtiDeferredUpdates.hpp"`

The lines below deserve a refactoring. It can be separate functions for locals, expressions and monitors, or just one
function for the whole fragment:

345         GrowableArray* scopeLocals = cvf->scope()->locals();
346         StackValueCollection* locals = cvf->locals();
347         if (locals != NULL) {
348           for (int i2 = 0; i2 < locals->size(); i2++) {
349             StackValue* var = locals->at(i2);
350             if (var->type() == T_OBJECT && scopeLocals->at(i2)->is_object()) {
351               jvalue val;
352               val.l = cast_from_oop(locals->at(i2)->get_obj()());
353               cvf->update_local(T_OBJECT, i2, val);
354             }
355           }
356         }
357
358         // expressions
359         GrowableArray* scopeExpressions = cvf->scope()->expressions();
360         StackValueCollection* expressions = cvf->expressions();
361         if (expressions != NULL) {
362           for (int i2 = 0; i2 < expressions->size(); i2++) {
363             StackValue* var = expressions->at(i2);
364             if (var->type() == T_OBJECT && scopeExpressions->at(i2)->is_object()) {
365               jvalue val;
366               val.l = cast_from_oop(expressions->at(i2)->get_obj()());
367               cvf->update_stack(T_OBJECT, i2, val);
368             }
369           }
370         }
371
372         // monitors
373         GrowableArray* monitors = cvf->monitors();
374         if (monitors != NULL) {
375           for (int i2 = 0; i2 < monitors->length(); i2++) {
376             if (monitors->at(i2)->eliminated()) {
377               assert(!monitors->at(i2)->owner_is_scalar_replaced(),
378                      "reallocation failure, should not update");
379               cvf->update_monitor(i2, monitors->at(i2));
380             }
381           }
382         }


src/hotspot/share/prims/jvmtiImpl.cpp:

 420 // Constructor for non-object getter
 421 VM_GetOrSetLocal::VM_GetOrSetLocal(JavaThread* thread, jint depth, jint index, BasicType type)
 422   : _thread(thread)
 423   , _calling_thread(NULL)
 424   , _depth(depth)
 425   , _index(index)
 426   , _type(type)
 427   , _jvf(NULL)
 428   , _set(false)
 429   , _eb(type == T_OBJECT, NULL, NULL)
 430   , _result(JVMTI_ERROR_NONE)
 431 {
 432 }

I still think, that the line 429 is going to cause confusions.
It is a non-object getter, so the type should never be T_OBJECT.
It won't change in the future to allow the T_OBJECT types.
The only way to allow it is to merge the constructors for object and non-object getters.
So, I'm suggesting to replace this line with:
` 429   , _eb(false, NULL, NULL)`

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

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

From shade at openjdk.java.net  Wed Oct  7 06:40:10 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 7 Oct 2020 06:40:10 GMT
Subject: RFR: 8254102: use ProcessHandle::pid instead of
 ManagementFactory::getRuntimeMXBean to get pid in tests
In-Reply-To: <aQOzr1zN3WrL11gTkWFkGrkDVRxwQOrM8XbsMk6_0Cc=.42c65bd7-68bd-4bbb-9b30-ecbf01982332@github.com>
References: <aQOzr1zN3WrL11gTkWFkGrkDVRxwQOrM8XbsMk6_0Cc=.42c65bd7-68bd-4bbb-9b30-ecbf01982332@github.com>
Message-ID: <1vxFjySSXroErkRB9oePKlg09vRS5iKeuGjU5bLlvV0=.95760bdb-865f-4a50-8186-c95073ecec48@github.com>

On Tue, 6 Oct 2020 23:08:40 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small cleanup which replaces
> `ManagementFactory.getRuntimeMXBean().getName().split("@")[0]` w/ `ProcessHandle.current().pid()` to get current
> process pid?  Thanks,
> -- Igor

I think this is fine, but you might consider a little improvement below.

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

Marked as reviewed by shade (Reviewer).

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

From shade at openjdk.java.net  Wed Oct  7 06:40:11 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 7 Oct 2020 06:40:11 GMT
Subject: RFR: 8254102: use ProcessHandle::pid instead of
 ManagementFactory::getRuntimeMXBean to get pid in tests
In-Reply-To: <5OaD6gBX9nmmX_N690gLnHefPo4bk9z3D-WqGwD3kXA=.32b936f9-c795-49c6-b158-90845eadcd45@github.com>
References: <aQOzr1zN3WrL11gTkWFkGrkDVRxwQOrM8XbsMk6_0Cc=.42c65bd7-68bd-4bbb-9b30-ecbf01982332@github.com>
 <5OaD6gBX9nmmX_N690gLnHefPo4bk9z3D-WqGwD3kXA=.32b936f9-c795-49c6-b158-90845eadcd45@github.com>
Message-ID: <aB8KNnFjtgaK8E-VF81brsQTMAE3G7FQFL-MJ8QcA8M=.87340971-3090-4577-801b-e69b80750149@github.com>

On Wed, 7 Oct 2020 01:47:23 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Hi all,
>> 
>> could you please review this small cleanup which replaces
>> `ManagementFactory.getRuntimeMXBean().getName().split("@")[0]` w/ `ProcessHandle.current().pid()` to get current
>> process pid?  Thanks,
>> -- Igor
>
> test/failure_handler/test/sanity/Suicide.java line 36:
> 
>> 34:             String osName = System.getProperty("os.name");
>> 35:             if (osName.contains("Windows")) {
>> 36:                 cmd = "taskkill.exe /F /PID " + pidStr;
> 
> This can be simplified to ProcessHandle.current().toString().  It returns the pid of the process as a string.
> 
> Explicitly converting it to a string is not necessary.  The "+" concatenation would convert the number to a string.

Yes, can just have `long pid` in this case.

I don't see that `ProcessHandle.toString` is *specified* to return the string with pid, so relying on that is brittle.
We might call `Long.toString` here directly, to avoid jumping through a few calls. But seeing how all this is a test
code, that does not seem necessary.

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

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

From shade at openjdk.java.net  Wed Oct  7 07:28:08 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 7 Oct 2020 07:28:08 GMT
Subject: RFR: 8253876: jdk/test/lib/hexdump/ASN1FormatterTest.java fails
 with "AssertionError: Lines expected [126] but found [202]"
In-Reply-To: <ASCOaOEaKxCTMEzRTADTMkIxJZ3y5fTD1D2bC_Zyi7k=.de0aea66-338c-46be-9fa5-89a52dd4b119@github.com>
References: <ASCOaOEaKxCTMEzRTADTMkIxJZ3y5fTD1D2bC_Zyi7k=.de0aea66-338c-46be-9fa5-89a52dd4b119@github.com>
Message-ID: <FibEiwl2qn2Xr8I9NfJWCDQoCUZOYYaHbjoS8ZqYBh8=.23b5f932-d752-4464-bca1-20d2e207ecae@github.com>

On Fri, 2 Oct 2020 17:36:59 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The HexPrinter test utility should be ignoring \r characters from the formatter.
> It looks for \n and generates System.lineSeparator() at the end of each line.
> 
> With this fix, the ASN1FormatterTest can be removed from the ProblemList.

I am puzzled about this change. I feels weird to drop proper line separator from `ASN1Formatter` to please the test.
And it does not even look complete, because `ASN1Formatter` still uses `String.format("...%n", ...)` sometimes, that
still uses system line separator.

Can the test be made resilient by watching out for `lineSeparator()`, instead of just `\n`?

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

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

From plevart at openjdk.java.net  Wed Oct  7 07:32:09 2020
From: plevart at openjdk.java.net (Peter Levart)
Date: Wed, 7 Oct 2020 07:32:09 GMT
Subject: RFR: 8159746: (proxy) Support for default methods
In-Reply-To: <GF8iEOkMUEL2dYB0HytFIc9gyeeUJ_KP0ImlqFsul2Y=.894afc05-9310-43e1-a308-8f7d71dc572b@github.com>
References: <kw2VXh3vTFf1zgfd4biXA41OKffZ5oU7KT23tXAxgUA=.bcf14ffc-4dba-4c9c-8754-184172c5acbd@github.com>
 <U-6RiCpFVIrhLztPN6opiPcpFtxValDzU-K7WWFZM-4=.6bc8aaa4-636a-4664-b380-4c4af00513bd@github.com>
 <-cLIJ8pFHtnNoJMHV3aXI7XMJWp4Jrutc8Xn5PG0OK8=.d2cd87ab-3592-4524-ad85-05444c43689b@github.com>
 <r0UK2qjnmgeTNDDSWaSLPAj3QRgx_4YB82ielllO7jM=.fa615bc0-db49-4a74-b842-793f8f5209bb@github.com>
 <1T8kXDZN1bhHr4c8v4SQsImeBySCqTfX-u3_jzvyocA=.b4957400-9a33-4b6e-8475-329642a5888c@github.com>
 <XIux-dY0JXHRafHk48kVNXId9r-HSceNSytBojDxelY=.872e74cb-b064-406e-b71f-13c90ec7fbbc@github.com>
 <j4t2vT0SnwnU7lhKRlXtk967d-K6nA0EqHrqNbba7W0=.dc05dba6-bf7e-4606-8a02-9c2bad4b3b58@github.com>
 <fmVtPcBdgMuZOPm2qx3Q3znVZM7JgQPkhPAVLtwkOhE=.2d8b8447-cfae-4cb3-9a7c-6567a881231f@github.com>
 <GSeWP29fAIUFSk0CYsC557w52CuLqeUWwHNK9maltwI=.3d5f002e-6b74-4a57-a5d8-244d27da9dde@github.com>
 <GF8iEOkMUEL2dYB0HytFIc9gyeeUJ_KP0ImlqFsul2Y=.894afc05-9310-43e1-a308-8f7d71dc572b@github.com>
Message-ID: <HvtDex3cmiv7XeTMITOroYfu74amSGQavQ_BAmVzmXw=.223be989-7c20-4ba4-ac0d-013d2b75a8cb@github.com>

On Tue, 6 Oct 2020 23:39:16 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> Joe has given some feedback in the CSR review.
> 
> >    should this functionality be housed in the InvocationHandler interface rather than the Proxy class? If I understand the
> >    intended usage of the new method, it should only be done in an InvocationHandler.
> 
> The primary usage of this new method is InvocationHandler. I agree that the new API should be defined in
> InvocationHandler.

If it is a public static method, then Proxy or InvocationHandler are just a namespace for it. From discoverability
perspective, either one is a good place I think. If interfaces supported protected default methods, then it would make
sense to be a protected default method in InvocationHandler. Such instance method could additionally enforce two things:
- that it is called from code comprising InvocationHandler
- that the proxy instance passed to that method is in fact backed by the invocation handler instance that is the target
  of that call by checking that in the method.

But we don't have protected default methods in interfaces (yet). So a static method it must be.

I was thinking about what such public static method allows and whether that presents a problem (perhaps security
related) and came to the conclusion that it does not allow anything that normal Java code would not allow except for
one thing (see below). From the 1st glance it would seem that it allows any code to call super default method on any
Proxy instance, but what does that mean exactly? The same effect can be achieved by creating a special hand-made proxy
class implementing all the interfaces that the dynamic Proxy class implements:

class HandmadeProxy implements I1, I2, ... {
    private final Proxy targetProxy;
    HandmadeProxy(Proxy targetProxy) { this.targetProxy = targetProxy }
    // implement all non-default methods of I1, I2, ... by delegating to targetProxy
    // example for I1.m()
    public void m() {
        ((I1)targetProxy).m();
    }
}

...and then using such class to invoke some default method on an instance of the Proxy:

Proxy proxy = ...
new HandmadeProxy(proxy).someDefaultMethod();

So such apparently powerful capability does not represent a problem. One additional thing is possible though:

>> Does the current spec handle a case like interface A declares a default method m, interface B extends A and separately
>> interface B declare a default method m.
>
> If a proxy instance implements both A and B, `invokeDefaultMethod(o, A.class.getMethod("m"), params)` will invoke
> `A::m`.

This is true since lookup.findSpecial() allows such thing (and I assume equivalent bytecode does too). The Java
language (compiler) OTOH does not allow calling A.super.m() from a class implementing both A and B when B extends A and
both A and B declare default method m():

    interface A {
        default void m() { }
    }

    interface B extends A {
        default void m() { }
    }

    static class C implements A, B {
        public void m() {
            A.super.m();
        }
    }

java: bad type qualifier A in default super call
  redundant interface A is extended by B

I'm in favour of following the bytecode (method handles) behaviour here even though it allows more than Java language
allows.

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

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

From sgehwolf at openjdk.java.net  Wed Oct  7 08:11:25 2020
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Wed, 7 Oct 2020 08:11:25 GMT
Subject: RFR: 8245543: Cgroups: Incorrect detection logic on some systems
 (still reproducible) [v4]
In-Reply-To: <CWATRi437QpkCA1sx-EsHFqVlSCV-G8EgkEoGdJgPHc=.a743be7e-8a00-4d91-866d-86ccf3fe714f@github.com>
References: <CWATRi437QpkCA1sx-EsHFqVlSCV-G8EgkEoGdJgPHc=.a743be7e-8a00-4d91-866d-86ccf3fe714f@github.com>
Message-ID: <mH_WSoigRKjJsTg_yuTI_YP0rN72-u4WrjHs-tIsH2M=.4353aec1-dece-4e7a-a085-71511785147c@github.com>

> An issue similar to [JDK-8239559](https://bugs.openjdk.java.net/browse/JDK-8239559) has been discovered. On the
> affected system, `/proc/self/mountinfo` contains a line such as this one:
> 
> 35 26 0:26 / /sys/fs/cgroup/systemd rw,nosuid,nodev,noexec,relatime - cgroup systemd rw,name=systemd
>  
> 
> Note that `/proc/cgroups` looks like this:
> 
> #subsys_name	hierarchy	num_cgroups	enabled
> cpuset	0	1	1
> cpu	0	1	1
> cpuacct	0	1	1
> blkio	0	1	1
> memory	0	1	1
> devices	0	1	1
> freezer	0	1	1
> net_cls	0	1	1
> perf_event	0	1	1
> net_prio	0	1	1
> hugetlb	0	1	1
> pids	0	1	1
> 
> This is in fact a cgroups v1 system with systemd put into a separate namespace via FS type `cgroup`. That mountinfo
> line confuses the cgroups version detection heuristic. It only looked whether or not there is **any** entry in
> mountinfo of FS-type `cgroup` . That's wrong. A better heuristic would be looking at controllers we care about: `cpu`,
> `cpuacct`, `memory`, `cpuset` for hotspot and some more for the Java side. The proposed fix on the hotspot side is to
> set `any_cgroup_mounts_found` to true only if one of those controllers show up in mountinfo. Otherwise, we know it's
> cgroup v2 due to the zero hierarchy ids.  For the Java side the proposal is to add some parsing for mountinfo lines and
> look for `cgroup` FS-type lines which aren't also mounted purely for systemd.
> **Testing**
> 
>  - [x] Linux x86_64 container tests on cgroup v1 (fastdebug)
>  - [x] Linux x86_64 container tests on cgroup v2 (fastdebug)
>  - [x] Added regression test which fails prior the patch and passes after
>  - [x] Submit testing

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

  8245543: Cgroups: Incorrect detection logic on some systems (still reproducible)

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/485/files
  - new: https://git.openjdk.java.net/jdk/pull/485/files/d334ac60..5e2ca2dc

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

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

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

From sgehwolf at openjdk.java.net  Wed Oct  7 08:11:25 2020
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Wed, 7 Oct 2020 08:11:25 GMT
Subject: RFR: 8245543: Cgroups: Incorrect detection logic on some systems
 (still reproducible) [v3]
In-Reply-To: <5dgnZpaXKV-Q6poVXgt0B0t3P06bGWT8D9JlcJIAtnw=.621aadd7-460f-438b-b46e-925098607bf3@github.com>
References: <CWATRi437QpkCA1sx-EsHFqVlSCV-G8EgkEoGdJgPHc=.a743be7e-8a00-4d91-866d-86ccf3fe714f@github.com>
 <9Y61ZqGTPrr7PY1UjY55Y3UdjZHu08tfn0iE6AhUb9Q=.2da3dbc9-55c2-48ac-b087-a2b26f0c6378@github.com>
 <znRYI56jaD-sNQpLDloBsjebFtbuhtk5nx7AUZEsOus=.00600298-0e40-4be3-b3c6-2953db69ad07@github.com>
 <5dgnZpaXKV-Q6poVXgt0B0t3P06bGWT8D9JlcJIAtnw=.621aadd7-460f-438b-b46e-925098607bf3@github.com>
Message-ID: <hvNp_VNZZhh-1-i7ihsTS9f3m-BJz9GwZmn0tsPF6kQ=.6d64a962-3bc5-41bf-940f-074f5be3009f@github.com>

On Tue, 6 Oct 2020 08:32:25 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemFactory.java line 150:
>> 
>>> 148:         // find anyway in that case.
>>> 149:         try (Stream<String> mntInfo = CgroupUtil.readFilePrivileged(Paths.get(mountInfo))) {
>>> 150:             boolean anyCgroupMounted = mntInfo.anyMatch(CgroupSubsystemFactory::noSystemdCgroupLine);
>> 
>> I'd prefer a similar approach to the hotspot side where you do a positive check for controllers we are interested in
>> rather than a negative check for systemd.
>
> OK. I'll probably fold JDK-8254001 into this one then.

@bobvandette Done in the latest version. Thoughts?

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

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

From sgehwolf at openjdk.java.net  Wed Oct  7 08:11:26 2020
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Wed, 7 Oct 2020 08:11:26 GMT
Subject: RFR: 8245543: Cgroups: Incorrect detection logic on some systems
 (still reproducible) [v4]
In-Reply-To: <aYRHT6XXDenNo-3JQTyshrni0Itt8dJeU4j30fv64Rk=.85f8b9ae-4ac1-4488-b1b3-82c1001fb8f4@github.com>
References: <CWATRi437QpkCA1sx-EsHFqVlSCV-G8EgkEoGdJgPHc=.a743be7e-8a00-4d91-866d-86ccf3fe714f@github.com>
 <5PIk4w58jDVRPA8DTWjVRBzuVxRH5HxxYM_cb8bc-jg=.a715f356-856a-430d-b641-98345ca5ad62@github.com>
 <aYRHT6XXDenNo-3JQTyshrni0Itt8dJeU4j30fv64Rk=.85f8b9ae-4ac1-4488-b1b3-82c1001fb8f4@github.com>
Message-ID: <E8cdHr3mikUv5CZnLl-GWQ82Vmn8pECyS6S35NI60Es=.2ac32c3b-1740-455c-bcad-51181d05749e@github.com>

On Mon, 5 Oct 2020 08:59:34 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemFactory.java line 80:
>> 
>>> 78:      */
>>> 79:     private static final Pattern MOUNTINFO_PATTERN =
>>> 80:
>>> Pattern.compile("^[^\\s]+\\s+[^\\s]+\\s+[^\\s]+\\s+([^\\s]+)\\s+([^\\s]+)\\s+[^-]+-\\s+([^\\s]+)\\s+.*$");
>> 
>> Only group_3 = fstype is used in the pattern, right?
>
> Yes. I've removed unused groups now, though.
> 
> Originally, my thinking was that `mount root` and `mount path` would be useful too so I kept it in. It would certainly
> be useful for getting rid of reading `/proc/self/mountinfo` twice on the Java side. As a future enhancement we could do
> away with double parsing of mount info by keeping track of relevant cgroup controller info. I've filed
> [JDK-8254001](https://bugs.openjdk.java.net/browse/JDK-8254001) to track this.

The latest version goes back to using all three as it's beneficial to track that info and use it later on for
instantiating the version specific objects.

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

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

From christoph.dreis at freenet.de  Wed Oct  7 08:32:13 2020
From: christoph.dreis at freenet.de (Christoph Dreis)
Date: Wed, 07 Oct 2020 10:32:13 +0200
Subject: Avoid unnecessary volatile write on new AtomicBoolean(false)
Message-ID: <37910BE0-317D-46B3-A92D-B8B3375D2C12@freenet.de>

Hi,

forgive me if this is not the right approach after the move to GitHub, but apparently there was no mail sent to the mailing list with this one.
I?ve opened https://github.com/openjdk/jdk/pull/510  to improve the performance of calls to new AtomicBoolean(false).

The mentioned PR would need sponsoring from someone, which I would highly appreciate.
If there's any change to the sponsoring process, please let me know as well.

Cheers,
Christoph



From claes.redestad at oracle.com  Wed Oct  7 09:27:22 2020
From: claes.redestad at oracle.com (Claes Redestad)
Date: Wed, 7 Oct 2020 11:27:22 +0200
Subject: Avoid unnecessary volatile write on new AtomicBoolean(false)
In-Reply-To: <37910BE0-317D-46B3-A92D-B8B3375D2C12@freenet.de>
References: <37910BE0-317D-46B3-A92D-B8B3375D2C12@freenet.de>
Message-ID: <eb0ca492-f236-cd21-e926-c01aec204265@oracle.com>

Hi Christoph,

the bots probably don't send out the RFR because it has no linked issue.

I've created an RFR for you: 
https://bugs.openjdk.java.net/browse/JDK-8254146

Update the subject of the PR to "8254146: Avoid unnecessary volatile 
write on new AtomicBoolean(false)" and it should clear all checks.

/Claes

On 2020-10-07 10:32, Christoph Dreis wrote:
> Hi,
> 
> forgive me if this is not the right approach after the move to GitHub, but apparently there was no mail sent to the mailing list with this one.
> I?ve opened https://github.com/openjdk/jdk/pull/510  to improve the performance of calls to new AtomicBoolean(false).
> 
> The mentioned PR would need sponsoring from someone, which I would highly appreciate.
> If there's any change to the sponsoring process, please let me know as well.
> 
> Cheers,
> Christoph
> 
> 

From github.com+6304496+dreis2211 at openjdk.java.net  Wed Oct  7 10:08:26 2020
From: github.com+6304496+dreis2211 at openjdk.java.net (Christoph Dreis)
Date: Wed, 7 Oct 2020 10:08:26 GMT
Subject: RFR: 8254146: Avoid unnecessary volatile write on new
 AtomicBoolean(false)
Message-ID: <AzWKluHZjvFYm2wUanwYfn91iKKMacpk_qSsje3tXWk=.ba873b46-4e12-4415-8832-fa314d6759a3@github.com>

Hi,

the following PR optimizes `new AtomicBoolean(boolean)` by avoiding the volatile write in case `false` is passed.
Essentially, it changes the ternary operator to a simple `if` without the `else` that would cause the volatile write.

The resulting bytecode seems to also benefit from the change:
    Code:
       0: aload_0
       1: invokespecial #1                  // Method java/lang/Object."<init>":()V
       4: aload_0
       5: iload_1
       6: ifeq          13
       9: iconst_1
      10: goto          14
      13: iconst_0
      14: putfield      #7                  // Field value:I
      17: return

After:
    Code:
       0: aload_0
       1: invokespecial #1                  // Method java/lang/Object."<init>":()V
       4: iload_1
       5: ifeq          13
       8: aload_0
       9: iconst_1
      10: putfield      #7                  // Field value:I
      13: return

A simple benchmark that returns `new AtomicBoolean(false)` shows the following results, that brings it on par to `new
AtomicBoolean()`: MyBenchmark.empty                                         avgt   10     3,103 ?   0,246   ns/op
MyBenchmark.explicitNew                                   avgt   10     2,966 ?   0,071   ns/op
MyBenchmark.explicitOld                                   avgt   10     7,738 ?   0,321   ns/op

In case you think this is worthwhile I'd be happy if this is sponsored.
Cheers,
Christoph

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

Commit messages:
 - Avoid unnecessary volatile write on new AtomicBoolean(false)

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

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

From github.com+6304496+dreis2211 at openjdk.java.net  Wed Oct  7 10:08:26 2020
From: github.com+6304496+dreis2211 at openjdk.java.net (Christoph Dreis)
Date: Wed, 7 Oct 2020 10:08:26 GMT
Subject: RFR: 8254146: Avoid unnecessary volatile write on new
 AtomicBoolean(false)
In-Reply-To: <AzWKluHZjvFYm2wUanwYfn91iKKMacpk_qSsje3tXWk=.ba873b46-4e12-4415-8832-fa314d6759a3@github.com>
References: <AzWKluHZjvFYm2wUanwYfn91iKKMacpk_qSsje3tXWk=.ba873b46-4e12-4415-8832-fa314d6759a3@github.com>
Message-ID: <809Kp1_vUvRvqc7DmJZhKSSFjJeB97gJwzxhw6THEh4=.60bed7f1-c9f2-40e9-bae5-a079e54e0456@github.com>

On Mon, 5 Oct 2020 17:25:28 GMT, Christoph Dreis <github.com+6304496+dreis2211 at openjdk.org> wrote:

> Hi,
> 
> the following PR optimizes `new AtomicBoolean(boolean)` by avoiding the volatile write in case `false` is passed.
> Essentially, it changes the ternary operator to a simple `if` without the `else` that would cause the volatile write.
> The resulting bytecode seems to also benefit from the change:
>     Code:
>        0: aload_0
>        1: invokespecial #1                  // Method java/lang/Object."<init>":()V
>        4: aload_0
>        5: iload_1
>        6: ifeq          13
>        9: iconst_1
>       10: goto          14
>       13: iconst_0
>       14: putfield      #7                  // Field value:I
>       17: return
> 
> After:
>     Code:
>        0: aload_0
>        1: invokespecial #1                  // Method java/lang/Object."<init>":()V
>        4: iload_1
>        5: ifeq          13
>        8: aload_0
>        9: iconst_1
>       10: putfield      #7                  // Field value:I
>       13: return
> 
> A simple benchmark that returns `new AtomicBoolean(false)` shows the following results, that brings it on par to `new
> AtomicBoolean()`: MyBenchmark.empty                                         avgt   10     3,103 ?   0,246   ns/op
> MyBenchmark.explicitNew                                   avgt   10     2,966 ?   0,071   ns/op
> MyBenchmark.explicitOld                                   avgt   10     7,738 ?   0,321   ns/op
> 
> In case you think this is worthwhile I'd be happy if this is sponsored.
> Cheers,
> Christoph

I have contributed before the move to GitHub and signed the OCA there. Can anybody tell me what the process is for this
case?

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

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

From github.com+6304496+dreis2211 at openjdk.java.net  Wed Oct  7 10:08:27 2020
From: github.com+6304496+dreis2211 at openjdk.java.net (Christoph Dreis)
Date: Wed, 7 Oct 2020 10:08:27 GMT
Subject: RFR: 8254146: Avoid unnecessary volatile write on new
 AtomicBoolean(false)
In-Reply-To: <fkTKjkCKlf2ishwU5W9SSp52sfVUWDrlQJg3cKC9BXk=.ac458b10-33c5-45dc-beb1-afad4c84dab1@github.com>
References: <AzWKluHZjvFYm2wUanwYfn91iKKMacpk_qSsje3tXWk=.ba873b46-4e12-4415-8832-fa314d6759a3@github.com>
 <809Kp1_vUvRvqc7DmJZhKSSFjJeB97gJwzxhw6THEh4=.60bed7f1-c9f2-40e9-bae5-a079e54e0456@github.com>
 <fkTKjkCKlf2ishwU5W9SSp52sfVUWDrlQJg3cKC9BXk=.ac458b10-33c5-45dc-beb1-afad4c84dab1@github.com>
Message-ID: <UmXGJyib5mvRGB1_mb2lDZIe94tLbpsUXoeokU9nIWE=.99865f96-c6a4-47a5-97f1-18fe6434e665@github.com>

On Tue, 6 Oct 2020 12:12:56 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> I have contributed before the move to GitHub and signed the OCA there. Can anybody tell me what the process is for this
>> case?
>
> @dreis2211 Have you tried what the bot suggested?
> 
> Once you have signed the OCA, please let us know by writing /signed in a comment in this pull request.

@jerboaa Since I have signed the OCA before the move to GitHub there is no connection to my GitHub handle, so I was
confused by that if that means I have to completely sign the OCA again.

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

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

From sgehwolf at openjdk.java.net  Wed Oct  7 10:08:26 2020
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Wed, 7 Oct 2020 10:08:26 GMT
Subject: RFR: 8254146: Avoid unnecessary volatile write on new
 AtomicBoolean(false)
In-Reply-To: <809Kp1_vUvRvqc7DmJZhKSSFjJeB97gJwzxhw6THEh4=.60bed7f1-c9f2-40e9-bae5-a079e54e0456@github.com>
References: <AzWKluHZjvFYm2wUanwYfn91iKKMacpk_qSsje3tXWk=.ba873b46-4e12-4415-8832-fa314d6759a3@github.com>
 <809Kp1_vUvRvqc7DmJZhKSSFjJeB97gJwzxhw6THEh4=.60bed7f1-c9f2-40e9-bae5-a079e54e0456@github.com>
Message-ID: <fkTKjkCKlf2ishwU5W9SSp52sfVUWDrlQJg3cKC9BXk=.ac458b10-33c5-45dc-beb1-afad4c84dab1@github.com>

On Mon, 5 Oct 2020 17:29:02 GMT, Christoph Dreis <github.com+6304496+dreis2211 at openjdk.org> wrote:

>> Hi,
>> 
>> the following PR optimizes `new AtomicBoolean(boolean)` by avoiding the volatile write in case `false` is passed.
>> Essentially, it changes the ternary operator to a simple `if` without the `else` that would cause the volatile write.
>> The resulting bytecode seems to also benefit from the change:
>>     Code:
>>        0: aload_0
>>        1: invokespecial #1                  // Method java/lang/Object."<init>":()V
>>        4: aload_0
>>        5: iload_1
>>        6: ifeq          13
>>        9: iconst_1
>>       10: goto          14
>>       13: iconst_0
>>       14: putfield      #7                  // Field value:I
>>       17: return
>> 
>> After:
>>     Code:
>>        0: aload_0
>>        1: invokespecial #1                  // Method java/lang/Object."<init>":()V
>>        4: iload_1
>>        5: ifeq          13
>>        8: aload_0
>>        9: iconst_1
>>       10: putfield      #7                  // Field value:I
>>       13: return
>> 
>> A simple benchmark that returns `new AtomicBoolean(false)` shows the following results, that brings it on par to `new
>> AtomicBoolean()`: MyBenchmark.empty                                         avgt   10     3,103 ?   0,246   ns/op
>> MyBenchmark.explicitNew                                   avgt   10     2,966 ?   0,071   ns/op
>> MyBenchmark.explicitOld                                   avgt   10     7,738 ?   0,321   ns/op
>> 
>> In case you think this is worthwhile I'd be happy if this is sponsored.
>> Cheers,
>> Christoph
>
> I have contributed before the move to GitHub and signed the OCA there. Can anybody tell me what the process is for this
> case?

@dreis2211 Have you tried what the bot suggested?

Once you have signed the OCA, please let us know by writing /signed in a comment in this pull request.

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

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

From dfuchs at openjdk.java.net  Wed Oct  7 10:41:07 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 7 Oct 2020 10:41:07 GMT
Subject: RFR: 8067127: Tags cleanup [v2]
In-Reply-To: <Pl9pN_PNxl_5U5YiuUeieWEBeSzbgKZe6BgJbeFcd78=.83ac1dcd-34fd-4202-b017-77c130fce15d@github.com>
References: <8YR2pzHDTetS1LChJUDvPtgo_LdMBZggFfmkdLl-HO4=.8016f8e2-aa1f-429f-a744-798807c7964e@github.com>
 <Pl9pN_PNxl_5U5YiuUeieWEBeSzbgKZe6BgJbeFcd78=.83ac1dcd-34fd-4202-b017-77c130fce15d@github.com>
Message-ID: <p85gUw0xnr6a1zxNG-Hlb_DyZcmTg8xstw6YxYwkOEk=.09a08fe4-7519-48f2-afeb-66bf7cf71d0b@github.com>

On Wed, 7 Oct 2020 00:00:21 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Please review this change to update some javadoc tags in the java.io package. The changes are to replace some
>> occurrences of <code>some_code</code> with {@code some_code}. Not all such constructs were replaced as being
>> infeasible, e.g., tag contains an entity such as <code>*&#47;</code> (DataOutput, Serial), or multiple {@code} tags
>> would be needed or the result would be ugly (File). It is unclear whether some of the changes which remove the
>> non-breaking space entity (&nbsp;) are desirable.  Thanks,  Brian
>
> Brian Burkhalter has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge branch 'JDK-8067127-java-io-tags-cleanup' of https://github.com/bplb/jdk into JDK-8067127-java-io-tags-cleanup
>  - 8067127: Tags cleanup

New changes LGTM!

best regards,

-- daniel

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

Marked as reviewed by dfuchs (Reviewer).

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

From lancea at openjdk.java.net  Wed Oct  7 10:46:13 2020
From: lancea at openjdk.java.net (Lance Andersen)
Date: Wed, 7 Oct 2020 10:46:13 GMT
Subject: RFR: 8067127: Tags cleanup [v2]
In-Reply-To: <Pl9pN_PNxl_5U5YiuUeieWEBeSzbgKZe6BgJbeFcd78=.83ac1dcd-34fd-4202-b017-77c130fce15d@github.com>
References: <8YR2pzHDTetS1LChJUDvPtgo_LdMBZggFfmkdLl-HO4=.8016f8e2-aa1f-429f-a744-798807c7964e@github.com>
 <Pl9pN_PNxl_5U5YiuUeieWEBeSzbgKZe6BgJbeFcd78=.83ac1dcd-34fd-4202-b017-77c130fce15d@github.com>
Message-ID: <td1i2W-_eialBWszpNBpQAJSbh7TE432uA1v-a46358=.32897bdf-96aa-4d8c-b993-35f17f27efca@github.com>

On Wed, 7 Oct 2020 00:00:21 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Please review this change to update some javadoc tags in the java.io package. The changes are to replace some
>> occurrences of <code>some_code</code> with {@code some_code}. Not all such constructs were replaced as being
>> infeasible, e.g., tag contains an entity such as <code>*&#47;</code> (DataOutput, Serial), or multiple {@code} tags
>> would be needed or the result would be ugly (File). It is unclear whether some of the changes which remove the
>> non-breaking space entity (&nbsp;) are desirable.  Thanks,  Brian
>
> Brian Burkhalter has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge branch 'JDK-8067127-java-io-tags-cleanup' of https://github.com/bplb/jdk into JDK-8067127-java-io-tags-cleanup
>  - 8067127: Tags cleanup

Marked as reviewed by lancea (Reviewer).

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

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

From christoph.dreis at freenet.de  Wed Oct  7 10:49:13 2020
From: christoph.dreis at freenet.de (Christoph Dreis)
Date: Wed, 07 Oct 2020 12:49:13 +0200
Subject: Avoid unnecessary volatile write on new AtomicBoolean(false)
In-Reply-To: <eb0ca492-f236-cd21-e926-c01aec204265@oracle.com>
References: <37910BE0-317D-46B3-A92D-B8B3375D2C12@freenet.de>
 <eb0ca492-f236-cd21-e926-c01aec204265@oracle.com>
Message-ID: <ACB1DE63-4825-4D08-90AA-230389745F87@freenet.de>

Hi Claes,

> the bots probably don't send out the RFR because it has no linked issue.
> I've created an RFR for you: 
> https://bugs.openjdk.java.net/browse/JDK-8254146

Thanks for your help!
I've updated the PR title, but apparently still no email sent to core-libs. 
At least the checks are green. Maybe there is some greater delay here!?

Cheers,
Christoph

On 2020-10-07 10:32, Christoph Dreis wrote:
> Hi,
> 
> forgive me if this is not the right approach after the move to GitHub, but apparently there was no mail sent to the mailing list with this one.
> I?ve opened https://github.com/openjdk/jdk/pull/510  to improve the performance of calls to new AtomicBoolean(false).
> 
> The mentioned PR would need sponsoring from someone, which I would highly appreciate.
> If there's any change to the sponsoring process, please let me know as well.
> 
> Cheers,
> Christoph
> 
> 



From redestad at openjdk.java.net  Wed Oct  7 11:05:12 2020
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 7 Oct 2020 11:05:12 GMT
Subject: RFR: 8254146: Avoid unnecessary volatile write on new
 AtomicBoolean(false)
In-Reply-To: <AzWKluHZjvFYm2wUanwYfn91iKKMacpk_qSsje3tXWk=.ba873b46-4e12-4415-8832-fa314d6759a3@github.com>
References: <AzWKluHZjvFYm2wUanwYfn91iKKMacpk_qSsje3tXWk=.ba873b46-4e12-4415-8832-fa314d6759a3@github.com>
Message-ID: <O_XHSooYuXvFznPHmvRU3MSq2EPpJh9E-BecPi7S-uM=.e9048a94-d298-4f2d-83b1-5385efe32000@github.com>

On Mon, 5 Oct 2020 17:25:28 GMT, Christoph Dreis <github.com+6304496+dreis2211 at openjdk.org> wrote:

> Hi,
> 
> the following PR optimizes `new AtomicBoolean(boolean)` by avoiding the volatile write in case `false` is passed.
> Essentially, it changes the ternary operator to a simple `if` without the `else` that would cause the volatile write.
> The resulting bytecode seems to also benefit from the change:
>     Code:
>        0: aload_0
>        1: invokespecial #1                  // Method java/lang/Object."<init>":()V
>        4: aload_0
>        5: iload_1
>        6: ifeq          13
>        9: iconst_1
>       10: goto          14
>       13: iconst_0
>       14: putfield      #7                  // Field value:I
>       17: return
> 
> After:
>     Code:
>        0: aload_0
>        1: invokespecial #1                  // Method java/lang/Object."<init>":()V
>        4: iload_1
>        5: ifeq          13
>        8: aload_0
>        9: iconst_1
>       10: putfield      #7                  // Field value:I
>       13: return
> 
> A simple benchmark that returns `new AtomicBoolean(false)` shows the following results, that brings it on par to `new
> AtomicBoolean()`: MyBenchmark.empty                                         avgt   10     3,103 ?   0,246   ns/op
> MyBenchmark.explicitNew                                   avgt   10     2,966 ?   0,071   ns/op
> MyBenchmark.explicitOld                                   avgt   10     7,738 ?   0,321   ns/op
> 
> In case you think this is worthwhile I'd be happy if this is sponsored.
> Cheers,
> Christoph

Marked as reviewed by redestad (Reviewer).

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

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

From alanb at openjdk.java.net  Wed Oct  7 11:26:07 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 7 Oct 2020 11:26:07 GMT
Subject: RFR: 8254146: Avoid unnecessary volatile write on new
 AtomicBoolean(false)
In-Reply-To: <O_XHSooYuXvFznPHmvRU3MSq2EPpJh9E-BecPi7S-uM=.e9048a94-d298-4f2d-83b1-5385efe32000@github.com>
References: <AzWKluHZjvFYm2wUanwYfn91iKKMacpk_qSsje3tXWk=.ba873b46-4e12-4415-8832-fa314d6759a3@github.com>
 <O_XHSooYuXvFznPHmvRU3MSq2EPpJh9E-BecPi7S-uM=.e9048a94-d298-4f2d-83b1-5385efe32000@github.com>
Message-ID: <9_-SxkchF_bPITYzE8yzxtMNzsVJDe5SI9gOEb04Jnw=.4cf006aa-20c5-43f6-9a0b-fed7c5c1cb2e@github.com>

On Wed, 7 Oct 2020 11:02:00 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Hi,
>> 
>> the following PR optimizes `new AtomicBoolean(boolean)` by avoiding the volatile write in case `false` is passed.
>> Essentially, it changes the ternary operator to a simple `if` without the `else` that would cause the volatile write.
>> The resulting bytecode seems to also benefit from the change:
>>     Code:
>>        0: aload_0
>>        1: invokespecial #1                  // Method java/lang/Object."<init>":()V
>>        4: aload_0
>>        5: iload_1
>>        6: ifeq          13
>>        9: iconst_1
>>       10: goto          14
>>       13: iconst_0
>>       14: putfield      #7                  // Field value:I
>>       17: return
>> 
>> After:
>>     Code:
>>        0: aload_0
>>        1: invokespecial #1                  // Method java/lang/Object."<init>":()V
>>        4: iload_1
>>        5: ifeq          13
>>        8: aload_0
>>        9: iconst_1
>>       10: putfield      #7                  // Field value:I
>>       13: return
>> 
>> A simple benchmark that returns `new AtomicBoolean(false)` shows the following results, that brings it on par to `new
>> AtomicBoolean()`: MyBenchmark.empty                                         avgt   10     3,103 ?   0,246   ns/op
>> MyBenchmark.explicitNew                                   avgt   10     2,966 ?   0,071   ns/op
>> MyBenchmark.explicitOld                                   avgt   10     7,738 ?   0,321   ns/op
>> 
>> In case you think this is worthwhile I'd be happy if this is sponsored.
>> Cheers,
>> Christoph
>
> Marked as reviewed by redestad (Reviewer).

I assume this should be coordinated with an update to the jsr166 CVS too.

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

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

From github.com+6304496+dreis2211 at openjdk.java.net  Wed Oct  7 11:54:12 2020
From: github.com+6304496+dreis2211 at openjdk.java.net (Christoph Dreis)
Date: Wed, 7 Oct 2020 11:54:12 GMT
Subject: RFR: 8254146: Avoid unnecessary volatile write on new
 AtomicBoolean(false)
In-Reply-To: <9_-SxkchF_bPITYzE8yzxtMNzsVJDe5SI9gOEb04Jnw=.4cf006aa-20c5-43f6-9a0b-fed7c5c1cb2e@github.com>
References: <AzWKluHZjvFYm2wUanwYfn91iKKMacpk_qSsje3tXWk=.ba873b46-4e12-4415-8832-fa314d6759a3@github.com>
 <O_XHSooYuXvFznPHmvRU3MSq2EPpJh9E-BecPi7S-uM=.e9048a94-d298-4f2d-83b1-5385efe32000@github.com>
 <9_-SxkchF_bPITYzE8yzxtMNzsVJDe5SI9gOEb04Jnw=.4cf006aa-20c5-43f6-9a0b-fed7c5c1cb2e@github.com>
Message-ID: <IMGVdGX3ry6lj1xsfbw8rSL83HdXgIRdo6RrYDJ-RnA=.0f056f4b-888e-4a61-9e6e-02acee357d8d@github.com>

On Wed, 7 Oct 2020 11:23:12 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Marked as reviewed by redestad (Reviewer).
>
> I assume this should be coordinated with an update to the jsr166 CVS too.

@AlanBateman What would be the label (or workflow) for that now?

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

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

From bulasevich at openjdk.java.net  Wed Oct  7 11:59:14 2020
From: bulasevich at openjdk.java.net (Boris Ulasevich)
Date: Wed, 7 Oct 2020 11:59:14 GMT
Subject: RFR: 8245543: Cgroups: Incorrect detection logic on some systems
 (still reproducible) [v4]
In-Reply-To: <E8cdHr3mikUv5CZnLl-GWQ82Vmn8pECyS6S35NI60Es=.2ac32c3b-1740-455c-bcad-51181d05749e@github.com>
References: <CWATRi437QpkCA1sx-EsHFqVlSCV-G8EgkEoGdJgPHc=.a743be7e-8a00-4d91-866d-86ccf3fe714f@github.com>
 <5PIk4w58jDVRPA8DTWjVRBzuVxRH5HxxYM_cb8bc-jg=.a715f356-856a-430d-b641-98345ca5ad62@github.com>
 <aYRHT6XXDenNo-3JQTyshrni0Itt8dJeU4j30fv64Rk=.85f8b9ae-4ac1-4488-b1b3-82c1001fb8f4@github.com>
 <E8cdHr3mikUv5CZnLl-GWQ82Vmn8pECyS6S35NI60Es=.2ac32c3b-1740-455c-bcad-51181d05749e@github.com>
Message-ID: <GcpAi1PJOLuNKCy0vX4rxIJSHNQtycgiMnlK-Rna3w4=.f89321e4-5fea-48d6-81be-5ad15f3cdb42@github.com>

On Wed, 7 Oct 2020 08:08:13 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Yes. I've removed unused groups now, though.
>> 
>> Originally, my thinking was that `mount root` and `mount path` would be useful too so I kept it in. It would certainly
>> be useful for getting rid of reading `/proc/self/mountinfo` twice on the Java side. As a future enhancement we could do
>> away with double parsing of mount info by keeping track of relevant cgroup controller info. I've filed
>> [JDK-8254001](https://bugs.openjdk.java.net/browse/JDK-8254001) to track this.
>
> The latest version goes back to using all three as it's beneficial to track that info and use it later on for
> instantiating the version specific objects.

ok!

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

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

From volker.simonis at gmail.com  Wed Oct  7 12:19:48 2020
From: volker.simonis at gmail.com (Volker Simonis)
Date: Wed, 7 Oct 2020 14:19:48 +0200
Subject: Request for Discussion: 8253952: Work around wrong usage of
 ZipOutputStream.putNextEntry() in user code
In-Reply-To: <B3917EB8-1775-4CC2-A014-7FFC8C70CB63@ORACLE.COM>
References: <CA+3eh12_-fNxf_KFK68WEqVoD_n6CD7RCbe=LoKCyCeUQ3w0oQ@mail.gmail.com>
 <4658d3a6-3360-fb84-e5ff-20dc6cc61b92@oracle.com>
 <CA+3eh10vr3vs92UPu7PwiaofZpf46QuzsuFf4bvf26gbYKF3-g@mail.gmail.com>
 <99e80b7e-7702-338d-cd92-c9d1a396dfa5@oracle.com>
 <DCBE7C9D-A8CB-4A14-8B79-DEA3BE4B2CA8@ORACLE.COM>
 <CA+3eh125PAxoOAWd+nde4oCnYPOptr=y7arxfRLmy5o0mHpo5g@mail.gmail.com>
 <266D112B-3883-4B6D-886E-1F4CE7641A34@ORACLE.COM>
 <CA+3eh10Tr8NnFaZDfxwq+Pc79AA4XkNOkZpy7epgkExEHw1M5A@mail.gmail.com>
 <0DF68377-AD12-423C-AA29-71B0F20F4D25@ORACLE.COM>
 <CA+3eh12doGmUHU3=uKrm_U+6ahcBNLQVig9bpPJChDcrd1-b=g@mail.gmail.com>
 <078C7AC7-7B93-4ACF-A6ED-80087CB0E18E@ORACLE.COM>
 <BD045667-852F-4CC0-9B1B-0CCDA856B63B@ORACLE.COM>
 <CA+3eh117LtyddnhWJEhoYCPLXH=9uWAv5GoTOTEXOo+OX=GeJw@mail.gmail.com>
 <B3917EB8-1775-4CC2-A014-7FFC8C70CB63@ORACLE.COM>
Message-ID: <CA+3eh12+grEDnFn5O3cQZiZLaM4SiGks07CdGtcZsnQ6QEekFg@mail.gmail.com>

On Tue, Oct 6, 2020 at 11:46 PM Weijun Wang <WEIJUN.WANG at oracle.com> wrote:
>
>
>
> > On Oct 6, 2020, at 1:50 PM, Volker Simonis <volker.simonis at gmail.com> wrote:
> >
> > On Tue, Oct 6, 2020 at 6:00 PM Weijun Wang <WEIJUN.WANG at oracle.com> wrote:
> >>
> >>
> >>
> >>> On Oct 6, 2020, at 11:42 AM, Weijun Wang <WEIJUN.WANG at ORACLE.COM> wrote:
> >>>
> >>>
> >>>
> >>>> On Oct 6, 2020, at 10:48 AM, Volker Simonis <volker.simonis at gmail.com> wrote:
> >>>>
> >>>> On Tue, Oct 6, 2020 at 4:21 PM Weijun Wang <WEIJUN.WANG at oracle.com> wrote:
> >>>>>
> >>>>> Hi Volker,
> >>>>>
> >>>>> The size unmatch could throw an exception, but writing an existing ZipEntry into a new ZipOutputStream could have other side effects, including time, comment, and other things we added recently, like POSIX permissions and file type flag (is it a symlink?). Do you meant to copy all these things to the new entry automatically?
> >>>>>
> >>>>
> >>>> Hi Max,
> >>>>
> >>>> this proposed change is just about fixing the unmatch for the
> >>>> compressed size attribute. All the other fields will be left
> >>>> untouched.
> >>>>
> >>>> Do you see similar problems with other fields which should be
> >>>> addressed in a similar way or do you just want to make sure that all
> >>>> the other fields are passed and processed correctly?
> >>>
> >>> No.
> >>>
> >>> I was just saying your code change could encourage more people to use the bad code pattern and it might have other unexpected behaviors. Even the zip command requires this or that option to copy certain attributes. For example, should symlinks always be copied as symlinks?
> >>
> >> Sorry, my comparison is not precise. The zip tool is adding files to a zip but your code change is about copying existing zip entries.
> >>
> >> Still, I wish people are aware that other attributes are copied as well, and they could be different from version to vesion.
> >>
> >
> > As described in the java.util.zp package documentation [1]
> > ZipOutputStream is aiming to create zip files according to the
> > "Info-ZIP Application Note 970311" [2] with "ZIP64 format extensions"
> > [3]. Are you aware of any ZipEntry attributes which won't be valid in
> > the target zip file after they have been read from a source zip file.
>
> No.
>
> Maybe it?s just that we have being doing this with the ?correct way? too long (in jar ?update and jarsigner), and I cannot help worrying what problem it might cause.
>

ZipEntry has the following attributes:

String name;        // entry name
long xdostime = -1; // last modification time (in extended DOS time,
FileTime mtime;     // last modification time, from extra field data
FileTime atime;     // last access time, from extra field data
FileTime ctime;     // creation time, from extra field data
long crc = -1;      // crc-32 of entry data
long size = -1;     // uncompressed size of entry data
long csize = -1;    // compressed size of entry data
int method = -1;    // compression method
int flag = 0;       // general purpose flag
byte[] extra;       // optional extra field data for entry
String comment;     // optional comment string for entry
int extraAttributes = -1; // e.g. POSIX permissions, sym links.

which can be read with:

String        getComment()
long          getCompressedSize()
long          getCrc()
FileTime      getCreationTime()
byte[]        getExtra()
FileTime      getLastAccessTime()
FileTime      getLastModifiedTime()
int           getMethod()
String        getName()
long          getSize()
long          getTime()
LocalDateTime getTimeLocal()

and set with (the name attribute can only be set in the constructor):

void     setComment(String comment)
void     setCompressedSize(long csize)
void     setCrc(long crc)
ZipEntry setCreationTime(FileTime time)
void     setExtra(byte[] extra)
ZipEntry setLastAccessTime(FileTime time)
ZipEntry setLastModifiedTime(FileTime time)
void     setMethod(int method)
void     setSize(long size)
void     setTime(long time)
void     setTimeLocal(LocalDateTime time)

I think all the attributes except "csize" (i.e the compressed size)
can be safely copied to a new zip file and will be valid there as
well.

@Lance: I therefore don't think it will be required to mention any
other attribute in the updated api documentation because none of them
requires special handling. Users who want to copy zip entries from one
zip file into another can now safely do so and will by default keep
all the original attributes. I think this is the behaviour most people
expect and intend to have.

> With this problem resolved, do you still think this is a ?bad coding pattern??

I think if we solve the problem with the compressed size the coding
pattern I denoted as "bad" will become valid and behave "as expected".

@Lance @Max: can we please continue the discussion and review on the
new PR at https://github.com/openjdk/jdk/pull/520 (or the
corresponding new mail thread)?

Thank you and best regards,
Volker

>
> Thanks,
> Max
>
> > I'd be happy to add a warning for them when changing the api
> > documentation.
> >
> > Best regards,
> > Volker
> >
> > [1] https://urldefense.com/v3/__http://www.pkware.com/documents/casestudies/APPNOTE.TXT__;!!GqivPVa7Brio!MApVADAAXvhn79VDKgHNs4bAGksVrN6zvPNYQ3YkeSP9exgdNXwBtda7c6Fsuup9_A$
> > [2] https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/zip/package-summary.html
> > [3] https://urldefense.com/v3/__http://www.info-zip.org/doc/appnote-19970311-iz.zip__;!!GqivPVa7Brio!MApVADAAXvhn79VDKgHNs4bAGksVrN6zvPNYQ3YkeSP9exgdNXwBtda7c6GMEWjHoQ$
> >
> >> Thanks,
> >> Max
> >>
> >>>
> >>> Thanks,
> >>> Max
> >>>
> >>>>
> >>>> Regards,
> >>>> Volker
> >>>>
> >>>>> Thanks,
> >>>>> Max
> >>>>>
> >>>>>> On Oct 6, 2020, at 9:56 AM, Volker Simonis <volker.simonis at gmail.com> wrote:
> >>>>>>
> >>>>>> On Tue, Oct 6, 2020 at 1:21 PM Lance Andersen <LANCE.ANDERSEN at oracle.com> wrote:
> >>>>>>>
> >>>>>>> Hi Volker
> >>>>>>>
> >>>>>>> On Oct 6, 2020, at 6:08 AM, Volker Simonis <volker.simonis at gmail.com> wrote:
> >>>>>>>
> >>>>>>> On Mon, Oct 5, 2020 at 9:53 PM Lance Andersen <LANCE.ANDERSEN at oracle.com> wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>> Hi Volker,
> >>>>>>>
> >>>>>>> Thank you for looking into this and creating a draft PR.
> >>>>>>>
> >>>>>>> On the surface, I don?t see a reason to introduce a  System property.  What challenges do you see  if you used the DataDescriptor unless ZipEntry::setCompressedSize is called?  That seems to address the issue that you discovered without having to introduce a new System property. Or is there an additional concern that is not obvious?  This seems like it would address the problem for existing code that is not well behaved.
> >>>>>>>
> >>>>>>>
> >>>>>>> Sure. That's obviously the simplest and best solution and I'd be
> >>>>>>> totally happy with it. I just thought there might be a need for
> >>>>>>> somehow preserving the old and buggy behaviour, that's why I added the
> >>>>>>> system property.
> >>>>>>>
> >>>>>>> I've created a simpler version of the fix without property and
> >>>>>>> adjusted the @apiNote accordingly:
> >>>>>>>
> >>>>>>>
> >>>>>>> Thank you for updating your proposal.  We will need to update the javadoc so that the  description of the change is normative and not part of the API note itself.
> >>>>>>
> >>>>>> Changing the updated doc to be normativ instead of just an @apiNote
> >>>>>> will make it impossible to downport this change but if you think it is
> >>>>>> really necessary I will accept that. I've removed the @apiNote tag
> >>>>>> from the java doc and changed the draft PR into a real PR.
> >>>>>>
> >>>>>> Without the @apiNote tag I also had to copy the extra documentation
> >>>>>> verbatim to JarOutputStream.putNextEntry() which is not very elegant
> >>>>>> but inheriting the whole api doc from ZipOutputStream didn't seem
> >>>>>> right either. Please let me know if you have a better idea.
> >>>>>>
> >>>>>> I'll open a CSR once we've agreed on the exact text for the java doc change.
> >>>>>>
> >>>>>> Please let's continue the discussion on the PR or the new mail that
> >>>>>> was created for it.
> >>>>>>
> >>>>>> Best regards,
> >>>>>> Volker
> >>>>>>
> >>>>>>> We will also need to create a CSR for the proposed change in the spec and functionality.  I believe we should also create a release note for this change
> >>>>>>>
> >>>>>>> Best
> >>>>>>> Lance
> >>>>>>>
> >>>>>>>
> >>>>>>> https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/520__;!!GqivPVa7Brio!O7epzMWqwxuS6aPQIllYZLdRTncNGXj5ioqVYY72igGBVGZgUGAHlQnCJ8mhzRoAvw$
> >>>>>>>
> >>>>>>> Would you be fine with such a solution?
> >>>>>>>
> >>>>>>> Thank you and best regards,
> >>>>>>> Volker
> >>>>>>>
> >>>>>>> The other option is to add an additional method to ZipOutputStream or ZipEntry to address the issue.
> >>>>>>>
> >>>>>>> Thoughts?
> >>>>>>>
> >>>>>>> Best
> >>>>>>> Lance
> >>>>>>>
> >>>>>>> On Oct 5, 2020, at 2:13 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> >>>>>>>
> >>>>>>> On 05/10/2020 11:04, Volker Simonis wrote:
> >>>>>>>
> >>>>>>> :
> >>>>>>>
> >>>>>>> I don't
> >>>>>>> think the proposal to add a system property to change the behavior is
> >>>>>>> feasible, at least not without changing the spec but even then it would
> >>>>>>> be very icky.
> >>>>>>>
> >>>>>>> Why do you think so? The answer to this question is especially
> >>>>>>> important to me because we are considering doing this in our internal
> >>>>>>> version independently of upstream OpenJKD (and potentially also in 8 &
> >>>>>>> 11).
> >>>>>>>
> >>>>>>> Introducing system properties to change the behavior of APIs and "fix" existing code is really icky. For the main line, then I think it would be good to explore the impact of changing the existing putNextEntry or introducing a new API. The compatibility impact of the former may not be significant but I would expect the spec would be clarified as part of this (that is what I was trying to say above). Exploring new APIs would be good and a method on ZipEntry may not be too bad (you have a reference to the target ZOS in the implementation).
> >>>>>>>
> >>>>>>> :
> >>>>>>>
> >>>>>>> And just as a side note, we also use the "jdk.util.zip.inhibitZip64"
> >>>>>>> property in ZipOutputStream for a similar reason. I just wonder how
> >>>>>>> that could pass the CCC process as I couldn't even find any
> >>>>>>> documentation for it :)
> >>>>>>>
> >>>>>>> ZIP64 was very problematic at the time as it wasn't supported by several tools. The system property was introduced to disable the feature/support so that Java applications didn't create ZIP files that other tools couldn't consume. It would be good to get an up to date picture on ZIP64 support as it might be that this switch can be removed. It pre-dates the CSR  process but there was a CCC at the time.
> >>>>>>>
> >>>>>>> -Alan
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> Best
> >>>>>>> Lance
> >>>>>>> ------------------
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
> >>>>>>> Oracle Java Engineering
> >>>>>>> 1 Network Drive
> >>>>>>> Burlington, MA 01803
> >>>>>>> Lance.Andersen at oracle.com
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> Best
> >>>>>>> Lance
> >>>>>>> ------------------
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
> >>>>>>> Oracle Java Engineering
> >>>>>>> 1 Network Drive
> >>>>>>> Burlington, MA 01803
> >>>>>>> Lance.Andersen at oracle.com
>

From hannesw at openjdk.java.net  Wed Oct  7 12:42:32 2020
From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Wed, 7 Oct 2020 12:42:32 GMT
Subject: RFR: 8216497: javadoc should auto-link to platform classes [v4]
In-Reply-To: <62DL75qa6dIrTFckM3XBcHtQS7tFo3hgL1wmwTIK9qQ=.7d06bb31-be18-438d-acdd-b98b32646190@github.com>
References: <62DL75qa6dIrTFckM3XBcHtQS7tFo3hgL1wmwTIK9qQ=.7d06bb31-be18-438d-acdd-b98b32646190@github.com>
Message-ID: <AO2Acg1Hp5F5taKitzy976h3Xiy-KeC9db4S9FyH7bg=.d8f0613a-e424-4f3f-a51e-5f6191efad86@github.com>

> This pull request is identical with the RFR previously sent for the Mercurial repository:
> 
> https://mail.openjdk.java.net/pipermail/javadoc-dev/2020-August/001796.html
> 
> I'm copy-pasting the comments from the original RFR below.
> 
> Most of the new code is added to the Extern class where it fits in quite nicely and can use the existing supporting
> code for setting up external links.
> The default behaviour is to generate links to docs.oracle.com for released versions and download.java.net for
> prereleases. Platform documentation URLs can be configured using the new --link-platform-properties <url> option to
> provide a properties file with URLs pointing to to alternative locations. See the CSR linked above for more details on
> the new options.  The feature can be disabled using the --no-platform-link option, generating the same output as
> previously.   One problem I had to solve was how to handle the transition from prerelease versions to final releases,
> since the location of the documentation changes in this transition. For obvious reasons we don?t want to make that
> switch via code change at a time shortly before release.  The way it is done is that we determine if the current
> javadoc instance is a prerelease version as indicated by the Version returned by BaseConfiguration#getDocletVersion(),
> and then check whether the release/source version of the current javadoc execution uses the same (latest) version. This
> means that that only the latest version will ever generate prerelease links (e.g. running current javadoc 16 with
> source version 15 will generate links to the final release documentation) but I think this is acceptable.  Another
> issue I spent some time getting right was tests. New releases require a new element-list resource*), so tests have to
> pick up new releases. On the other hand, we don?t want hundreds of tests to fail when a new release is added, ideally
> there should be one test  with a clear message. Because of this, when a release is encountered for which no
> element-list is available a warning is generated instead of an error, and the documentation is generated without
> platform links as if running with --no-platform-link option. This allows most existing tests to pass and just the new
> test to fail with a relatively clear message of what is wrong.
> *) I also thought about generating the element-list for the current release at build time. It?s quite involved, and we
>  still need to maintain element-lists for older versions, so I?m not sure it?s worth it.
> 
> For existing tests that check output affected by the new option I added  the --no-platform-link option to disable the
> feature. Otherwise we?d have to update those tests with each new release (or else freeze the tests to use some static
> release or source version, which we don?t want either).  I updated the CSR to the new code. It also needs to be
> reviewed: https://bugs.openjdk.java.net/browse/JDK-8251181
> 
> Thanks,
> Hannes

Hannes Walln?fer has updated the pull request with a new target base 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:

 - Fix test failure
 - Merge branch 'master' into JDK-8216497
 - Rename --no-platform-link option plus minor cleanup
 - Merge pull request #1 from lahodaj/JDK-8216497
   
   Automatically generate the elements-list data from the ct.sym for releases 11+, including the current release under
   development
 - Generating current release list for javadoc; using hardcoded lists for versions < 11
 - Attempting to (mostly) generate the javadoc release manifests from ct.sym historical data.
 - 8216497: javadoc should auto-link to platform classes

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/171/files
  - new: https://git.openjdk.java.net/jdk/pull/171/files/6009dd70..991daef5

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

  Stats: 69874 lines in 2995 files changed: 23958 ins; 34697 del; 11219 mod
  Patch: https://git.openjdk.java.net/jdk/pull/171.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/171/head:pull/171

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

From hannesw at openjdk.java.net  Wed Oct  7 13:12:13 2020
From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Wed, 7 Oct 2020 13:12:13 GMT
Subject: Integrated: 8216497: javadoc should auto-link to platform classes
In-Reply-To: <62DL75qa6dIrTFckM3XBcHtQS7tFo3hgL1wmwTIK9qQ=.7d06bb31-be18-438d-acdd-b98b32646190@github.com>
References: <62DL75qa6dIrTFckM3XBcHtQS7tFo3hgL1wmwTIK9qQ=.7d06bb31-be18-438d-acdd-b98b32646190@github.com>
Message-ID: <JzoaXvPUinaQ-gK6SfeXMS6Svv8UXIUqRVenZ51Q-D0=.96ec30ee-bfd4-42be-95e3-41660a86c0df@github.com>

On Tue, 15 Sep 2020 09:10:54 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> This pull request is identical with the RFR previously sent for the Mercurial repository:
> 
> https://mail.openjdk.java.net/pipermail/javadoc-dev/2020-August/001796.html
> 
> I'm copy-pasting the comments from the original RFR below.
> 
> Most of the new code is added to the Extern class where it fits in quite nicely and can use the existing supporting
> code for setting up external links.
> The default behaviour is to generate links to docs.oracle.com for released versions and download.java.net for
> prereleases. Platform documentation URLs can be configured using the new --link-platform-properties <url> option to
> provide a properties file with URLs pointing to to alternative locations. See the CSR linked above for more details on
> the new options.  The feature can be disabled using the --no-platform-link option, generating the same output as
> previously.   One problem I had to solve was how to handle the transition from prerelease versions to final releases,
> since the location of the documentation changes in this transition. For obvious reasons we don?t want to make that
> switch via code change at a time shortly before release.  The way it is done is that we determine if the current
> javadoc instance is a prerelease version as indicated by the Version returned by BaseConfiguration#getDocletVersion(),
> and then check whether the release/source version of the current javadoc execution uses the same (latest) version. This
> means that that only the latest version will ever generate prerelease links (e.g. running current javadoc 16 with
> source version 15 will generate links to the final release documentation) but I think this is acceptable.  Another
> issue I spent some time getting right was tests. New releases require a new element-list resource*), so tests have to
> pick up new releases. On the other hand, we don?t want hundreds of tests to fail when a new release is added, ideally
> there should be one test  with a clear message. Because of this, when a release is encountered for which no
> element-list is available a warning is generated instead of an error, and the documentation is generated without
> platform links as if running with --no-platform-link option. This allows most existing tests to pass and just the new
> test to fail with a relatively clear message of what is wrong.
> *) I also thought about generating the element-list for the current release at build time. It?s quite involved, and we
>  still need to maintain element-lists for older versions, so I?m not sure it?s worth it.
> 
> For existing tests that check output affected by the new option I added  the --no-platform-link option to disable the
> feature. Otherwise we?d have to update those tests with each new release (or else freeze the tests to use some static
> release or source version, which we don?t want either).  I updated the CSR to the new code. It also needs to be
> reviewed: https://bugs.openjdk.java.net/browse/JDK-8251181
> 
> Thanks,
> Hannes

This pull request has now been integrated.

Changeset: 1e8e543b
Author:    Hannes Walln?fer <hannesw at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/1e8e543b
Stats:     1844 lines in 51 files changed: 1831 ins; 4 del; 9 mod

8216497: javadoc should auto-link to platform classes

Co-authored-by: Jan Lahoda <jlahoda at openjdk.org>
Reviewed-by: erikj, jjg

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

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

From vromero at openjdk.java.net  Wed Oct  7 13:36:29 2020
From: vromero at openjdk.java.net (Vicente Romero)
Date: Wed, 7 Oct 2020 13:36:29 GMT
Subject: RFR: 8246774: implementing Record Classes as a standard feature
 in Java [v10]
In-Reply-To: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com>
References: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com>
Message-ID: <Yvd3k6HncIXeh535xSfkxXdZdgrrRWN0w1w8Ke0c36k=.2bc490b7-72de-4f06-8580-798c02c8ad2a@github.com>

> 8246774: implementing Record Classes as a standard feature in Java

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

  removing unused jcod file

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/290/files
  - new: https://git.openjdk.java.net/jdk/pull/290/files/7501148d..1bcda595

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

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

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

From rriggs at openjdk.java.net  Wed Oct  7 13:38:21 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 7 Oct 2020 13:38:21 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v2]
In-Reply-To: <6P-wrlA7c9wlXEhcoAYW5J9W2jwTmTTj3PkDObPh0LA=.c11aa048-8853-4e1c-a689-c34b89c15f12@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <6P-wrlA7c9wlXEhcoAYW5J9W2jwTmTTj3PkDObPh0LA=.c11aa048-8853-4e1c-a689-c34b89c15f12@github.com>
Message-ID: <HOu6omKjwLS5JBVS4sq0mjt1ZZwxvbH597cmwwG7QQs=.6d5549e6-5459-43b2-9bc4-e108cd852f25@github.com>

On Mon, 5 Oct 2020 18:29:58 GMT, CoreyAshford <github.com+51754783+CoreyAshford at openjdk.org> wrote:

>> This patch set encompasses the following commits:
>> 
>> - Adds a new HotSpot intrinsic candidate to the java.lang.Base64 class - decodeBlock(), and provides a flexible API for
>>   the intrinsic.  The API is similar to the existing encodeBlock intrinsic.
>> - Adds the code in HotSpot to check and martial the new intrinsic's arguments to the arch-specific intrinsic
>>   implementation
>> - Adds a Power64LE-specific implementation of the decodeBlock intrinsic.
>> - Adds a JMH microbenchmark for both Base64 encoding and encoding.
>> - Enhances the JTReg hotspot intrinsic "TestBase64.java" regression test to more fully test both decoding and encoding.
>
> CoreyAshford has updated the pull request with a new target base due to a merge or a rebase. The pull request now
> contains ten commits:
>  - AOT: Revert change to aotCodeHeap.cpp for decodeBlock
>    
>    Don't add the SET_AOT_GLOBAL_SYMBOL_VALUE macro for decode block until all
>    arches that implement AOT, implement the decodeBlock intrinsic.
>  - Base64.java decodeBlock: Changes from PR review
>    
>     * Make comparison safer and consistent with the while loop
>     * Update comment about the decodeBlock intrinsic so that it matches the new structure
>     * Add comment about the lack of a length check on the destination buffer
>     * As per issue 8138732, change HotSpotIntrinsicCandidate to IntrinsicCandidate
>  - stubGenerator_ppc.cpp: Changes from PR review
>    
>     * Fix clearing of upper bits to clear 32 bits instead of 31 (due to misreading of clrldi instruction)
>     * change and document loop_unrolls setting from 8 to 2 after re-running the benchmark
>     * align unrolled loop on a 32-byte boundary
>     * replace instruction used for checking isURL from a double word to single
>       word instruction since the register is effectively 32 bits wide
>     * cosmetic change to realign register comments.
>  - TestBase64.java: Changes from PR review
>    
>     * Use Utils.toByteArrays() method instead of a locally-defined method
>     * Generate the two non-Base64 tables dynamically rather than use static initialization
>     * Added comments describing the two above-mentioned arrays
>  - Expand the Base64 intrinsic regression test to cover decodeBlock
>    
>    This patch makes four significant changes:
>    
>    1) The Power implementation of the decodeBlock intrinsic, at least,
>    requires a decode length of at least 128 bytes, but the existing test cases
>    are much shorter, maxing out at 111 bytes.  So the patch adds a new input
>    data file which has longer test cases in it.
>    
>    2) The original test cases only covers the encoding of just the printable
>    subset of the 7-bit ASCII characters.  However, Base64 encoding requires
>    being able to encode arbitrary binary data, i.e. it must handle all 256
>    8-bit byte encodings.  To remedy this, but keep the original line-oriented
>    style of the input data, I added another input file type that uses a simple
>    ASCII hexadecimal encoding - two ASCII hex characters per 8-bit byte.  When
>    test0 is called, a new parameter is passed that specifies the type of the
>    input file, which is either the original ASCII type or the hexadecimal
>    format.  So to test both longer input data and arbitrary 8-bit data, the
>    newly added input test file has test cases which are both longer and
>    encoded in ASCII hex so as to give full 8-bit capability.  When reading
>    this type of file, test0 calls a newly-added function to translate the
>    ASCII hex to binary data.  Except for the first line of input data, which
>    contains all possible 8-bit values sequentially, the input data was
>    generated using a random length (between 111 and 520 bytes) buffer filled
>    with random 8-bit data, which should give adequate coverage.
>    
>    3) The original test did not test that the decoder detects illegal Base64
>    bytes.  This change chooses a random location in the encoded data to
>    corrupt with a randomly-chosen byte which is illegal for the specific
>    Base64 encoding that is chosen (i.e. standard or URLsafe).  It then calls
>    the decode function to verify that the illegal byte is detected and the
>    proper exception is thrown.
>    
>    4) The test iteration count was originally 100K, but that is far more than
>    enough iterations to test the intrinsic.  It takes 20K iterations on each
>    instrinsic for HotSpot C2 to begin calling it.  The test originally had
>    three types of encodings to test and called the encode intrinsic four times
>    for each iteration, which works out to 100K * 3 * 4 = 1.2M calls just to
>    encode.  Decode was called four times as well (now five because of the
>    illegal byte test).  I believe this is excessive and with the extra test
>    data I have added, the test was timing out after ten minutes of execution.
>    It appears that it is timing out, not because the intrinsics take a long
>    time to run, but because test0 generates an enormous number of discarded
>    data buffers for the GC system to recover (the test runs at about 39GB of
>    virtual memory on my test machine).  To remedy the timeout problem, I have
>    changed the code so that a warmup function of 20K repetitions is performed
>    on a fixed buffer, to activate the instrinsic(s).  After the warmup, I have
>    reduced the number of iterations to 5K on each test0 call.  This should
>    give adequate coverage.
>  - Add JMH benchmark for Base64 variable length buffer decoding
>  - Add Power9+ intrinsic implementation for Base64 decoding
>  - Add HotSpot code to implement Base64 decodeBlock API
>  - Add HotSpotIntrinsicCandidate and API for Base64 decoding

src/java.base/share/classes/java/util/Base64.java line 776:

> 774:          * @param  sl
> 775:          *         the total length of source array
> 776:          * @param  dst

Please update the comment for `sl`.  sl is the offset (exclusive) past the last byte to be converted.

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

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

From aph at openjdk.java.net  Wed Oct  7 13:40:16 2020
From: aph at openjdk.java.net (Andrew Haley)
Date: Wed, 7 Oct 2020 13:40:16 GMT
Subject: RFR: 8254078: DataOutputStream is very slow post-disabling of Biased
 Locking
Message-ID: <lLg_yNI_6LvUZTlM4PyN5ra6AaUZZeT35QzYzV_0CpI=.f2d3cb9e-be30-40dc-922c-dad5bef7feea@github.com>

DataOutputStream is very slow post-disabling of Biased Locking. This
was discovered when benchmarking a transaction library, which showed
significant performance loss when moving to JDK 15. WIth some small
changes to DataOutputStream we can get the performance back. There's a
JMH benchmark at
http://cr.openjdk.java.net/~aph/JDK-8254078/jmh-tests.tar

Some Stream classes use very fine-grained locking.

In particular, writeInt is defined like this:

        out.write((v >>> 24) & 0xFF);
        out.write((v >>> 16) & 0xFF);
        out.write((v >>> 8) & 0xFF);
        out.write((v >>> 0) & 0xFF);
        incCount(4);

Unfortunately, ByteArrayOutputStream.write(byte) is defined like this:

    public synchronized void write(int b) {
        ensureCapacity(count + 1);
        buf[count] = (byte) b;
        count += 1;
    }

so we acquire and release a lock for every byte that is output.

 For example, writing 4kb of ints goes from 17.3 us/op to 53.9 us/op when biased locking is disabled:


+UseBiasedLocking DataOutputStreamTest.dataOutputStreamOverByteArray avgt 6 53.895 ? 5.126 us/op
-UseBiasedLocking DataOutputStreamTest.dataOutputStreamOverByteArray avgt 6 17.291 ? 4.430 us/op

There are refactorings of DataOutputStream we can do to mitigate this.

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

Commit messages:
 - JDK-8254078: DataOutputStream is very slow post-disabling of Biased Locking

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

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

From aph at openjdk.java.net  Wed Oct  7 13:40:16 2020
From: aph at openjdk.java.net (Andrew Haley)
Date: Wed, 7 Oct 2020 13:40:16 GMT
Subject: RFR: 8254078: DataOutputStream is very slow post-disabling of
 Biased Locking
In-Reply-To: <lLg_yNI_6LvUZTlM4PyN5ra6AaUZZeT35QzYzV_0CpI=.f2d3cb9e-be30-40dc-922c-dad5bef7feea@github.com>
References: <lLg_yNI_6LvUZTlM4PyN5ra6AaUZZeT35QzYzV_0CpI=.f2d3cb9e-be30-40dc-922c-dad5bef7feea@github.com>
Message-ID: <k0tiIR7y2yVpP5ZvUee0mfCl3aVzWTi2i0WVuU3HOjM=.0014de14-ab2f-483c-9ebd-688242aa9fde@github.com>

On Wed, 7 Oct 2020 13:30:14 GMT, Andrew Haley <aph at openjdk.org> wrote:

> DataOutputStream is very slow post-disabling of Biased Locking. This
> was discovered when benchmarking a transaction library, which showed
> significant performance loss when moving to JDK 15. WIth some small
> changes to DataOutputStream we can get the performance back. There's a
> JMH benchmark at
> http://cr.openjdk.java.net/~aph/JDK-8254078/jmh-tests.tar
> 
> Some Stream classes use very fine-grained locking.
> 
> In particular, writeInt is defined like this:
> 
>         out.write((v >>> 24) & 0xFF);
>         out.write((v >>> 16) & 0xFF);
>         out.write((v >>> 8) & 0xFF);
>         out.write((v >>> 0) & 0xFF);
>         incCount(4);
> 
> Unfortunately, ByteArrayOutputStream.write(byte) is defined like this:
> 
>     public synchronized void write(int b) {
>         ensureCapacity(count + 1);
>         buf[count] = (byte) b;
>         count += 1;
>     }
> 
> so we acquire and release a lock for every byte that is output.
> 
>  For example, writing 4kb of ints goes from 17.3 us/op to 53.9 us/op when biased locking is disabled:
> 
> 
> +UseBiasedLocking DataOutputStreamTest.dataOutputStreamOverByteArray avgt 6 53.895 ? 5.126 us/op
> -UseBiasedLocking DataOutputStreamTest.dataOutputStreamOverByteArray avgt 6 17.291 ? 4.430 us/op
> 
> There are refactorings of DataOutputStream we can do to mitigate this.

, with option +UseBiasedLocking:

Benchmark                                                    (BASIC_TYPE)  (KIND)  (SIZE)  Mode  Cnt     Score
Error  Units DataOutputStreamTest.dataOutputStreamOverBufferedFileStream          char     old    4096  avgt    6
45.145 ? 38.769  us/op DataOutputStreamTest.dataOutputStreamOverBufferedFileStream         short     old    4096
avgt    6    54.226 ?  0.872  us/op DataOutputStreamTest.dataOutputStreamOverBufferedFileStream           int
old    4096  avgt    6    56.863 ?  1.264  us/op DataOutputStreamTest.dataOutputStreamOverByteArray
char     old    4096  avgt    6    20.369 ?  0.462  us/op
DataOutputStreamTest.dataOutputStreamOverByteArray                  short     old    4096  avgt    6    20.272 ?
0.214  us/op DataOutputStreamTest.dataOutputStreamOverByteArray                    int     old    4096  avgt    6
17.625 ?  0.142  us/op DataOutputStreamTest.dataOutputStreamOverRawFileStream               char     old    4096
avgt    6  3045.074 ? 79.539  us/op DataOutputStreamTest.dataOutputStreamOverRawFileStream              short
old    4096  avgt    6  3133.192 ? 74.831  us/op DataOutputStreamTest.dataOutputStreamOverRawFileStream
int     old    4096  avgt    6  2988.553 ? 29.789  us/op

jdk, default -UseBiasedLocking:

DataOutputStreamTest.dataOutputStreamOverBufferedFileStream          char     old    4096  avgt    6    58.267 ?
1.070  us/op DataOutputStreamTest.dataOutputStreamOverBufferedFileStream         short     old    4096  avgt    6
57.875 ?  2.386  us/op DataOutputStreamTest.dataOutputStreamOverBufferedFileStream           int     old    4096
avgt    6    58.393 ?  0.405  us/op DataOutputStreamTest.dataOutputStreamOverByteArray                   char
old    4096  avgt    6    50.269 ? 14.233  us/op DataOutputStreamTest.dataOutputStreamOverByteArray
short     old    4096  avgt    6    49.006 ? 11.184  us/op
DataOutputStreamTest.dataOutputStreamOverByteArray                    int     old    4096  avgt    6    52.905 ?
5.153  us/op DataOutputStreamTest.dataOutputStreamOverRawFileStream               char     old    4096  avgt    6
3053.183 ? 89.999  us/op DataOutputStreamTest.dataOutputStreamOverRawFileStream              short     old    4096
avgt    6  2986.694 ? 57.205  us/op DataOutputStreamTest.dataOutputStreamOverRawFileStream                int
old    4096  avgt    6  3061.812 ? 57.636  us/op

jdk, default -UseBiasedLocking, patched:

Benchmark                                                    (BASIC_TYPE)  (KIND)  (SIZE)  Mode  Cnt     Score
Error  Units DataOutputStreamTest.dataOutputStreamOverBufferedFileStream          char     old    4096  avgt    6
28.911 ?  0.529  us/op DataOutputStreamTest.dataOutputStreamOverBufferedFileStream         short     old    4096
avgt    6    28.895 ?  0.286  us/op DataOutputStreamTest.dataOutputStreamOverBufferedFileStream           int
old    4096  avgt    6    15.157 ?  2.870  us/op DataOutputStreamTest.dataOutputStreamOverByteArray
char     old    4096  avgt    6    29.251 ?  0.291  us/op
DataOutputStreamTest.dataOutputStreamOverByteArray                  short     old    4096  avgt    6    29.712 ?
0.230  us/op DataOutputStreamTest.dataOutputStreamOverByteArray                    int     old    4096  avgt    6
15.703 ?  0.265  us/op DataOutputStreamTest.dataOutputStreamOverRawFileStream               char     old    4096
avgt    6  1704.795 ? 36.028  us/op DataOutputStreamTest.dataOutputStreamOverRawFileStream              short
old    4096  avgt    6  1731.482 ? 21.304  us/op DataOutputStreamTest.dataOutputStreamOverRawFileStream
int     old    4096  avgt    6   861.758 ? 18.296  us/op```

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

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

From rriggs at openjdk.java.net  Wed Oct  7 13:41:09 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 7 Oct 2020 13:41:09 GMT
Subject: RFR: 8254146: Avoid unnecessary volatile write on new
 AtomicBoolean(false)
In-Reply-To: <AzWKluHZjvFYm2wUanwYfn91iKKMacpk_qSsje3tXWk=.ba873b46-4e12-4415-8832-fa314d6759a3@github.com>
References: <AzWKluHZjvFYm2wUanwYfn91iKKMacpk_qSsje3tXWk=.ba873b46-4e12-4415-8832-fa314d6759a3@github.com>
Message-ID: <yNUBzMyHr1Asbrtyt2sHQnGcJOxdfP8umMyRPC863Rw=.5c18ea25-bcf8-473b-a86a-fe764b8684d6@github.com>

On Mon, 5 Oct 2020 17:25:28 GMT, Christoph Dreis <github.com+6304496+dreis2211 at openjdk.org> wrote:

> Hi,
> 
> the following PR optimizes `new AtomicBoolean(boolean)` by avoiding the volatile write in case `false` is passed.
> Essentially, it changes the ternary operator to a simple `if` without the `else` that would cause the volatile write.
> The resulting bytecode seems to also benefit from the change:
>     Code:
>        0: aload_0
>        1: invokespecial #1                  // Method java/lang/Object."<init>":()V
>        4: aload_0
>        5: iload_1
>        6: ifeq          13
>        9: iconst_1
>       10: goto          14
>       13: iconst_0
>       14: putfield      #7                  // Field value:I
>       17: return
> 
> After:
>     Code:
>        0: aload_0
>        1: invokespecial #1                  // Method java/lang/Object."<init>":()V
>        4: iload_1
>        5: ifeq          13
>        8: aload_0
>        9: iconst_1
>       10: putfield      #7                  // Field value:I
>       13: return
> 
> A simple benchmark that returns `new AtomicBoolean(false)` shows the following results, that brings it on par to `new
> AtomicBoolean()`: MyBenchmark.empty                                         avgt   10     3,103 ?   0,246   ns/op
> MyBenchmark.explicitNew                                   avgt   10     2,966 ?   0,071   ns/op
> MyBenchmark.explicitOld                                   avgt   10     7,738 ?   0,321   ns/op
> 
> In case you think this is worthwhile I'd be happy if this is sponsored.
> Cheers,
> Christoph

Marked as reviewed by rriggs (Reviewer).

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

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

From rriggs at openjdk.java.net  Wed Oct  7 13:53:08 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 7 Oct 2020 13:53:08 GMT
Subject: RFR: 8253876: jdk/test/lib/hexdump/ASN1FormatterTest.java fails
 with "AssertionError: Lines expected [126] but found [202]"
In-Reply-To: <FibEiwl2qn2Xr8I9NfJWCDQoCUZOYYaHbjoS8ZqYBh8=.23b5f932-d752-4464-bca1-20d2e207ecae@github.com>
References: <ASCOaOEaKxCTMEzRTADTMkIxJZ3y5fTD1D2bC_Zyi7k=.de0aea66-338c-46be-9fa5-89a52dd4b119@github.com>
 <FibEiwl2qn2Xr8I9NfJWCDQoCUZOYYaHbjoS8ZqYBh8=.23b5f932-d752-4464-bca1-20d2e207ecae@github.com>
Message-ID: <wJRPFNP81r6HC6OxYtvuIeNKAbQtwEB_Xd2Ehc-fG0o=.77900eec-87fe-4c37-ae99-32d52f800e71@github.com>

On Wed, 7 Oct 2020 07:25:40 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> The HexPrinter test utility should be ignoring \r characters from the formatter.
>> It looks for \n and generates System.lineSeparator() at the end of each line.
>> 
>> With this fix, the ASN1FormatterTest can be removed from the ProblemList.
>
> I am puzzled about this change. I feels weird to drop proper line separator from `ASN1Formatter` to please the test.
> And it does not even look complete, because `ASN1Formatter` still uses `String.format("...%n", ...)` sometimes, that
> still uses system line separator.  Can the test be made resilient by watching out for `lineSeparator()`, instead of
> just `\n`?

The real fix for the test failing was the change in HexPrinter to ignore the <CR> when it is breaking lines from the
formatter. HexPrinter expected only /n from the formatter.

However, since the formatters can be used independently of HexPrinter, they should use System.lineSeparator() to work
consistently.  I'll put back the System.lineSepartor() use and re-test.

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

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

From mdoerr at openjdk.java.net  Wed Oct  7 14:06:20 2020
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Wed, 7 Oct 2020 14:06:20 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v2]
In-Reply-To: <6P-wrlA7c9wlXEhcoAYW5J9W2jwTmTTj3PkDObPh0LA=.c11aa048-8853-4e1c-a689-c34b89c15f12@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <6P-wrlA7c9wlXEhcoAYW5J9W2jwTmTTj3PkDObPh0LA=.c11aa048-8853-4e1c-a689-c34b89c15f12@github.com>
Message-ID: <r5FtoUonRPCmhZ7ueswqkgh9pTwoA4rYrrpfVIO1zBE=.2917dc6c-d288-4ea4-b958-e6021025b9e5@github.com>

On Mon, 5 Oct 2020 18:29:58 GMT, CoreyAshford <github.com+51754783+CoreyAshford at openjdk.org> wrote:

>> This patch set encompasses the following commits:
>> 
>> - Adds a new HotSpot intrinsic candidate to the java.lang.Base64 class - decodeBlock(), and provides a flexible API for
>>   the intrinsic.  The API is similar to the existing encodeBlock intrinsic.
>> - Adds the code in HotSpot to check and martial the new intrinsic's arguments to the arch-specific intrinsic
>>   implementation
>> - Adds a Power64LE-specific implementation of the decodeBlock intrinsic.
>> - Adds a JMH microbenchmark for both Base64 encoding and encoding.
>> - Enhances the JTReg hotspot intrinsic "TestBase64.java" regression test to more fully test both decoding and encoding.
>
> CoreyAshford has updated the pull request with a new target base due to a merge or a rebase. The pull request now
> contains ten commits:
>  - AOT: Revert change to aotCodeHeap.cpp for decodeBlock
>    
>    Don't add the SET_AOT_GLOBAL_SYMBOL_VALUE macro for decode block until all
>    arches that implement AOT, implement the decodeBlock intrinsic.
>  - Base64.java decodeBlock: Changes from PR review
>    
>     * Make comparison safer and consistent with the while loop
>     * Update comment about the decodeBlock intrinsic so that it matches the new structure
>     * Add comment about the lack of a length check on the destination buffer
>     * As per issue 8138732, change HotSpotIntrinsicCandidate to IntrinsicCandidate
>  - stubGenerator_ppc.cpp: Changes from PR review
>    
>     * Fix clearing of upper bits to clear 32 bits instead of 31 (due to misreading of clrldi instruction)
>     * change and document loop_unrolls setting from 8 to 2 after re-running the benchmark
>     * align unrolled loop on a 32-byte boundary
>     * replace instruction used for checking isURL from a double word to single
>       word instruction since the register is effectively 32 bits wide
>     * cosmetic change to realign register comments.
>  - TestBase64.java: Changes from PR review
>    
>     * Use Utils.toByteArrays() method instead of a locally-defined method
>     * Generate the two non-Base64 tables dynamically rather than use static initialization
>     * Added comments describing the two above-mentioned arrays
>  - Expand the Base64 intrinsic regression test to cover decodeBlock
>    
>    This patch makes four significant changes:
>    
>    1) The Power implementation of the decodeBlock intrinsic, at least,
>    requires a decode length of at least 128 bytes, but the existing test cases
>    are much shorter, maxing out at 111 bytes.  So the patch adds a new input
>    data file which has longer test cases in it.
>    
>    2) The original test cases only covers the encoding of just the printable
>    subset of the 7-bit ASCII characters.  However, Base64 encoding requires
>    being able to encode arbitrary binary data, i.e. it must handle all 256
>    8-bit byte encodings.  To remedy this, but keep the original line-oriented
>    style of the input data, I added another input file type that uses a simple
>    ASCII hexadecimal encoding - two ASCII hex characters per 8-bit byte.  When
>    test0 is called, a new parameter is passed that specifies the type of the
>    input file, which is either the original ASCII type or the hexadecimal
>    format.  So to test both longer input data and arbitrary 8-bit data, the
>    newly added input test file has test cases which are both longer and
>    encoded in ASCII hex so as to give full 8-bit capability.  When reading
>    this type of file, test0 calls a newly-added function to translate the
>    ASCII hex to binary data.  Except for the first line of input data, which
>    contains all possible 8-bit values sequentially, the input data was
>    generated using a random length (between 111 and 520 bytes) buffer filled
>    with random 8-bit data, which should give adequate coverage.
>    
>    3) The original test did not test that the decoder detects illegal Base64
>    bytes.  This change chooses a random location in the encoded data to
>    corrupt with a randomly-chosen byte which is illegal for the specific
>    Base64 encoding that is chosen (i.e. standard or URLsafe).  It then calls
>    the decode function to verify that the illegal byte is detected and the
>    proper exception is thrown.
>    
>    4) The test iteration count was originally 100K, but that is far more than
>    enough iterations to test the intrinsic.  It takes 20K iterations on each
>    instrinsic for HotSpot C2 to begin calling it.  The test originally had
>    three types of encodings to test and called the encode intrinsic four times
>    for each iteration, which works out to 100K * 3 * 4 = 1.2M calls just to
>    encode.  Decode was called four times as well (now five because of the
>    illegal byte test).  I believe this is excessive and with the extra test
>    data I have added, the test was timing out after ten minutes of execution.
>    It appears that it is timing out, not because the intrinsics take a long
>    time to run, but because test0 generates an enormous number of discarded
>    data buffers for the GC system to recover (the test runs at about 39GB of
>    virtual memory on my test machine).  To remedy the timeout problem, I have
>    changed the code so that a warmup function of 20K repetitions is performed
>    on a fixed buffer, to activate the instrinsic(s).  After the warmup, I have
>    reduced the number of iterations to 5K on each test0 call.  This should
>    give adequate coverage.
>  - Add JMH benchmark for Base64 variable length buffer decoding
>  - Add Power9+ intrinsic implementation for Base64 decoding
>  - Add HotSpot code to implement Base64 decodeBlock API
>  - Add HotSpotIntrinsicCandidate and API for Base64 decoding

src/java.base/share/classes/java/util/Base64.java line 812:

> 810:
> 811:             while (sp < sl) {
> 812:                 if (shiftto == 18 && sp + 4 < sl) {       // fast path

Please change to sp < s1 - 4. Current version is sensitive to integer overflow. That's not a real problem in the
current code, because the next check catches that, but we should better avoid this with the new intrinsics.

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

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

From rriggs at openjdk.java.net  Wed Oct  7 14:09:10 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 7 Oct 2020 14:09:10 GMT
Subject: RFR: 8254078: DataOutputStream is very slow post-disabling of
 Biased Locking
In-Reply-To: <lLg_yNI_6LvUZTlM4PyN5ra6AaUZZeT35QzYzV_0CpI=.f2d3cb9e-be30-40dc-922c-dad5bef7feea@github.com>
References: <lLg_yNI_6LvUZTlM4PyN5ra6AaUZZeT35QzYzV_0CpI=.f2d3cb9e-be30-40dc-922c-dad5bef7feea@github.com>
Message-ID: <EJKoky6UZ4pMtxqQvIQJe7PmczwtTPcKY0wU0nX96aQ=.0bcda955-9e05-4d4a-9fcc-88b49aa7482f@github.com>

On Wed, 7 Oct 2020 13:30:14 GMT, Andrew Haley <aph at openjdk.org> wrote:

> DataOutputStream is very slow post-disabling of Biased Locking. This
> was discovered when benchmarking a transaction library, which showed
> significant performance loss when moving to JDK 15. WIth some small
> changes to DataOutputStream we can get the performance back. There's a
> JMH benchmark at
> http://cr.openjdk.java.net/~aph/JDK-8254078/jmh-tests.tar
> 
> Some Stream classes use very fine-grained locking.
> 
> In particular, writeInt is defined like this:
> 
>         out.write((v >>> 24) & 0xFF);
>         out.write((v >>> 16) & 0xFF);
>         out.write((v >>> 8) & 0xFF);
>         out.write((v >>> 0) & 0xFF);
>         incCount(4);
> 
> Unfortunately, ByteArrayOutputStream.write(byte) is defined like this:
> 
>     public synchronized void write(int b) {
>         ensureCapacity(count + 1);
>         buf[count] = (byte) b;
>         count += 1;
>     }
> 
> so we acquire and release a lock for every byte that is output.
> 
>  For example, writing 4kb of ints goes from 17.3 us/op to 53.9 us/op when biased locking is disabled:
> 
> 
> +UseBiasedLocking DataOutputStreamTest.dataOutputStreamOverByteArray avgt 6 53.895 ? 5.126 us/op
> -UseBiasedLocking DataOutputStreamTest.dataOutputStreamOverByteArray avgt 6 17.291 ? 4.430 us/op
> 
> There are refactorings of DataOutputStream we can do to mitigate this.

There is a pre-existing race condition on use of the writeBuffer.
It is allocated per DataOutputStream but is unsynchronized.
Only the write(byte) and write(byte[], off, len) methods are synchronized.
Will that be/become a problem?

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

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

From aph at openjdk.java.net  Wed Oct  7 14:13:10 2020
From: aph at openjdk.java.net (Andrew Haley)
Date: Wed, 7 Oct 2020 14:13:10 GMT
Subject: RFR: 8254078: DataOutputStream is very slow post-disabling of
 Biased Locking
In-Reply-To: <EJKoky6UZ4pMtxqQvIQJe7PmczwtTPcKY0wU0nX96aQ=.0bcda955-9e05-4d4a-9fcc-88b49aa7482f@github.com>
References: <lLg_yNI_6LvUZTlM4PyN5ra6AaUZZeT35QzYzV_0CpI=.f2d3cb9e-be30-40dc-922c-dad5bef7feea@github.com>
 <EJKoky6UZ4pMtxqQvIQJe7PmczwtTPcKY0wU0nX96aQ=.0bcda955-9e05-4d4a-9fcc-88b49aa7482f@github.com>
Message-ID: <_FCkRwF2zWuesLEx-i6wMCS2QLqI-u_eL9gL8rw_Dl0=.bfcda732-80e4-4bc8-ab41-d31a7a26e538@github.com>

On Wed, 7 Oct 2020 14:06:27 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> There is a pre-existing race condition on use of the writeBuffer.
> It is allocated per DataOutputStream but is unsynchronized.
> Only the write(byte) and write(byte[], off, len) methods are synchronized.
> Will that be/become a problem?

Hard to say. There isn't a guarantee in the specification. After my patch, writeInt is

    public final void writeInt(int v) throws IOException {
        writeBuffer[0] = (byte)(v >>> 24);
        writeBuffer[1] = (byte)(v >>> 16);
        writeBuffer[2] = (byte)(v >>>  8);
        writeBuffer[3] = (byte)(v >>>  0);
        out.write(writeBuffer, 0, 4);
        incCount(4);
    }

whereas writeLong() is
    public final void writeLong(long v) throws IOException {
        writeBuffer[0] = (byte)(v >>> 56);
        writeBuffer[1] = (byte)(v >>> 48);
        writeBuffer[2] = (byte)(v >>> 40);
        writeBuffer[3] = (byte)(v >>> 32);
        writeBuffer[4] = (byte)(v >>> 24);
        writeBuffer[5] = (byte)(v >>> 16);
        writeBuffer[6] = (byte)(v >>>  8);
        writeBuffer[7] = (byte)(v >>>  0);
        out.write(writeBuffer, 0, 8);
        incCount(8);
    }

I know there's a history of Java programmers writing to the implementation, not the specification, but ISTM that if
writeLong() can be written this way so can writeInt().

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

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

From alanb at openjdk.java.net  Wed Oct  7 14:27:15 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 7 Oct 2020 14:27:15 GMT
Subject: RFR: 8254078: DataOutputStream is very slow post-disabling of
 Biased Locking
In-Reply-To: <_FCkRwF2zWuesLEx-i6wMCS2QLqI-u_eL9gL8rw_Dl0=.bfcda732-80e4-4bc8-ab41-d31a7a26e538@github.com>
References: <lLg_yNI_6LvUZTlM4PyN5ra6AaUZZeT35QzYzV_0CpI=.f2d3cb9e-be30-40dc-922c-dad5bef7feea@github.com>
 <EJKoky6UZ4pMtxqQvIQJe7PmczwtTPcKY0wU0nX96aQ=.0bcda955-9e05-4d4a-9fcc-88b49aa7482f@github.com>
 <_FCkRwF2zWuesLEx-i6wMCS2QLqI-u_eL9gL8rw_Dl0=.bfcda732-80e4-4bc8-ab41-d31a7a26e538@github.com>
Message-ID: <VBOCfFp_FB3lUbo5Hdr_Ax_vOoiFaV8GsEbfcTOSYtw=.a6d0d2c8-8ab0-4d4e-9c37-f9249188e288@github.com>

On Wed, 7 Oct 2020 14:09:46 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> There is a pre-existing race condition on use of the writeBuffer.
>> It is allocated per DataOutputStream but is unsynchronized.
>> Only the write(byte) and write(byte[], off, len) methods are synchronized.
>> Will that be/become a problem?
>
>> There is a pre-existing race condition on use of the writeBuffer.
>> It is allocated per DataOutputStream but is unsynchronized.
>> Only the write(byte) and write(byte[], off, len) methods are synchronized.
>> Will that be/become a problem?
> 
> Hard to say. There isn't a guarantee in the specification. After my patch, writeInt is
> 
>     public final void writeInt(int v) throws IOException {
>         writeBuffer[0] = (byte)(v >>> 24);
>         writeBuffer[1] = (byte)(v >>> 16);
>         writeBuffer[2] = (byte)(v >>>  8);
>         writeBuffer[3] = (byte)(v >>>  0);
>         out.write(writeBuffer, 0, 4);
>         incCount(4);
>     }
> 
> whereas writeLong() is
>     public final void writeLong(long v) throws IOException {
>         writeBuffer[0] = (byte)(v >>> 56);
>         writeBuffer[1] = (byte)(v >>> 48);
>         writeBuffer[2] = (byte)(v >>> 40);
>         writeBuffer[3] = (byte)(v >>> 32);
>         writeBuffer[4] = (byte)(v >>> 24);
>         writeBuffer[5] = (byte)(v >>> 16);
>         writeBuffer[6] = (byte)(v >>>  8);
>         writeBuffer[7] = (byte)(v >>>  0);
>         out.write(writeBuffer, 0, 8);
>         incCount(8);
>     }
> 
> I know there's a history of Java programmers writing to the implementation, not the specification, but ISTM that if
> writeLong() can be written this way so can writeInt().

DataOutputStream is a JDK 1.0 era class that doesn't specify whether it is safe for use by multiple threads or not.
Some methods are synchronized, some are not. The writeBuffer used by writeLong means it is not thread safe. The
writeShort and writeInt methods aren't thread safe so changing them to use the writeBuffer doesn't make things any
worse. Other examples are the "bytearr" used by writeUTF, the writeChars and writeBytes methods, and the protected
"written" field that sub-classes can use to monitor the number of bytes written.

It might be helpful to add a statement to the DataOutputStream class description to say that it not safe for by
concurrent threads and it needs appropriate synchronization to coordinate multiple writers. This issue or another issue
doesn't matter.

Can the benchmark be turned into a microbenchmark for test/micro?

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

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

From mdoerr at openjdk.java.net  Wed Oct  7 14:31:18 2020
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Wed, 7 Oct 2020 14:31:18 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v2]
In-Reply-To: <6P-wrlA7c9wlXEhcoAYW5J9W2jwTmTTj3PkDObPh0LA=.c11aa048-8853-4e1c-a689-c34b89c15f12@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <6P-wrlA7c9wlXEhcoAYW5J9W2jwTmTTj3PkDObPh0LA=.c11aa048-8853-4e1c-a689-c34b89c15f12@github.com>
Message-ID: <M1zvEmLqLC0oKqzSfjyEag5zxGLyml-YUHq1T1EjwYM=.21d8f1bc-da68-4a46-9ca9-6c36ab79cf81@github.com>

On Mon, 5 Oct 2020 18:29:58 GMT, CoreyAshford <github.com+51754783+CoreyAshford at openjdk.org> wrote:

>> This patch set encompasses the following commits:
>> 
>> - Adds a new HotSpot intrinsic candidate to the java.lang.Base64 class - decodeBlock(), and provides a flexible API for
>>   the intrinsic.  The API is similar to the existing encodeBlock intrinsic.
>> - Adds the code in HotSpot to check and martial the new intrinsic's arguments to the arch-specific intrinsic
>>   implementation
>> - Adds a Power64LE-specific implementation of the decodeBlock intrinsic.
>> - Adds a JMH microbenchmark for both Base64 encoding and encoding.
>> - Enhances the JTReg hotspot intrinsic "TestBase64.java" regression test to more fully test both decoding and encoding.
>
> CoreyAshford has updated the pull request with a new target base due to a merge or a rebase. The pull request now
> contains ten commits:
>  - AOT: Revert change to aotCodeHeap.cpp for decodeBlock
>    
>    Don't add the SET_AOT_GLOBAL_SYMBOL_VALUE macro for decode block until all
>    arches that implement AOT, implement the decodeBlock intrinsic.
>  - Base64.java decodeBlock: Changes from PR review
>    
>     * Make comparison safer and consistent with the while loop
>     * Update comment about the decodeBlock intrinsic so that it matches the new structure
>     * Add comment about the lack of a length check on the destination buffer
>     * As per issue 8138732, change HotSpotIntrinsicCandidate to IntrinsicCandidate
>  - stubGenerator_ppc.cpp: Changes from PR review
>    
>     * Fix clearing of upper bits to clear 32 bits instead of 31 (due to misreading of clrldi instruction)
>     * change and document loop_unrolls setting from 8 to 2 after re-running the benchmark
>     * align unrolled loop on a 32-byte boundary
>     * replace instruction used for checking isURL from a double word to single
>       word instruction since the register is effectively 32 bits wide
>     * cosmetic change to realign register comments.
>  - TestBase64.java: Changes from PR review
>    
>     * Use Utils.toByteArrays() method instead of a locally-defined method
>     * Generate the two non-Base64 tables dynamically rather than use static initialization
>     * Added comments describing the two above-mentioned arrays
>  - Expand the Base64 intrinsic regression test to cover decodeBlock
>    
>    This patch makes four significant changes:
>    
>    1) The Power implementation of the decodeBlock intrinsic, at least,
>    requires a decode length of at least 128 bytes, but the existing test cases
>    are much shorter, maxing out at 111 bytes.  So the patch adds a new input
>    data file which has longer test cases in it.
>    
>    2) The original test cases only covers the encoding of just the printable
>    subset of the 7-bit ASCII characters.  However, Base64 encoding requires
>    being able to encode arbitrary binary data, i.e. it must handle all 256
>    8-bit byte encodings.  To remedy this, but keep the original line-oriented
>    style of the input data, I added another input file type that uses a simple
>    ASCII hexadecimal encoding - two ASCII hex characters per 8-bit byte.  When
>    test0 is called, a new parameter is passed that specifies the type of the
>    input file, which is either the original ASCII type or the hexadecimal
>    format.  So to test both longer input data and arbitrary 8-bit data, the
>    newly added input test file has test cases which are both longer and
>    encoded in ASCII hex so as to give full 8-bit capability.  When reading
>    this type of file, test0 calls a newly-added function to translate the
>    ASCII hex to binary data.  Except for the first line of input data, which
>    contains all possible 8-bit values sequentially, the input data was
>    generated using a random length (between 111 and 520 bytes) buffer filled
>    with random 8-bit data, which should give adequate coverage.
>    
>    3) The original test did not test that the decoder detects illegal Base64
>    bytes.  This change chooses a random location in the encoded data to
>    corrupt with a randomly-chosen byte which is illegal for the specific
>    Base64 encoding that is chosen (i.e. standard or URLsafe).  It then calls
>    the decode function to verify that the illegal byte is detected and the
>    proper exception is thrown.
>    
>    4) The test iteration count was originally 100K, but that is far more than
>    enough iterations to test the intrinsic.  It takes 20K iterations on each
>    instrinsic for HotSpot C2 to begin calling it.  The test originally had
>    three types of encodings to test and called the encode intrinsic four times
>    for each iteration, which works out to 100K * 3 * 4 = 1.2M calls just to
>    encode.  Decode was called four times as well (now five because of the
>    illegal byte test).  I believe this is excessive and with the extra test
>    data I have added, the test was timing out after ten minutes of execution.
>    It appears that it is timing out, not because the intrinsics take a long
>    time to run, but because test0 generates an enormous number of discarded
>    data buffers for the GC system to recover (the test runs at about 39GB of
>    virtual memory on my test machine).  To remedy the timeout problem, I have
>    changed the code so that a warmup function of 20K repetitions is performed
>    on a fixed buffer, to activate the instrinsic(s).  After the warmup, I have
>    reduced the number of iterations to 5K on each test0 call.  This should
>    give adequate coverage.
>  - Add JMH benchmark for Base64 variable length buffer decoding
>  - Add Power9+ intrinsic implementation for Base64 decoding
>  - Add HotSpot code to implement Base64 decodeBlock API
>  - Add HotSpotIntrinsicCandidate and API for Base64 decoding

src/hotspot/cpu/ppc/stubGenerator_ppc.cpp line 3818:

> 3816:     __ cmpd(CCR0, end, in);
> 3817:     __ blt_predict_not_taken(CCR0, unrolled_loop_exit);
> 3818:     __ align(32);

align should be before bind(unrolled_loop_start)

src/hotspot/cpu/ppc/stubGenerator_ppc.cpp line 3:

> 1: /*
> 2:  * Copyright (c) 1997, 2020, Oracle and/or its affiliates. All rights reserved.
> 3:  * Copyright (c) 2012, 2020, SAP SE. All rights reserved.

No comma before SAP SE, please! (See https://bugs.openjdk.java.net/browse/JDK-8252837)

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

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

From aph at openjdk.java.net  Wed Oct  7 14:34:08 2020
From: aph at openjdk.java.net (Andrew Haley)
Date: Wed, 7 Oct 2020 14:34:08 GMT
Subject: RFR: 8254078: DataOutputStream is very slow post-disabling of
 Biased Locking
In-Reply-To: <VBOCfFp_FB3lUbo5Hdr_Ax_vOoiFaV8GsEbfcTOSYtw=.a6d0d2c8-8ab0-4d4e-9c37-f9249188e288@github.com>
References: <lLg_yNI_6LvUZTlM4PyN5ra6AaUZZeT35QzYzV_0CpI=.f2d3cb9e-be30-40dc-922c-dad5bef7feea@github.com>
 <EJKoky6UZ4pMtxqQvIQJe7PmczwtTPcKY0wU0nX96aQ=.0bcda955-9e05-4d4a-9fcc-88b49aa7482f@github.com>
 <_FCkRwF2zWuesLEx-i6wMCS2QLqI-u_eL9gL8rw_Dl0=.bfcda732-80e4-4bc8-ab41-d31a7a26e538@github.com>
 <VBOCfFp_FB3lUbo5Hdr_Ax_vOoiFaV8GsEbfcTOSYtw=.a6d0d2c8-8ab0-4d4e-9c37-f9249188e288@github.com>
Message-ID: <6jvxOF9XtUANIvKjvwm1ITdmpZc9XKO0xtxDsdcxrdc=.308f5106-cc24-4823-a284-4b3ba7563fc5@github.com>

On Wed, 7 Oct 2020 14:24:24 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> It might be helpful to add a statement to the DataOutputStream class description to say that it not safe for by
> concurrent threads and it needs appropriate synchronization to coordinate multiple writers. This issue or another issue
> doesn't matter.

I see.

> Can the benchmark be turned into a microbenchmark for test/micro?

Now there's an interesting question. I can tweak the benchmark (which at present contains a modified version of
DataOutputSteam, so can compare and contrast) so that it measures only the performance of the core library's
implementation. Does that make sense? If so, I can add it to this PR.

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

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

From Alan.Bateman at oracle.com  Wed Oct  7 14:36:46 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 7 Oct 2020 15:36:46 +0100
Subject: RFR: 8159746: (proxy) Support for default methods
In-Reply-To: <GF8iEOkMUEL2dYB0HytFIc9gyeeUJ_KP0ImlqFsul2Y=.894afc05-9310-43e1-a308-8f7d71dc572b@github.com>
References: <kw2VXh3vTFf1zgfd4biXA41OKffZ5oU7KT23tXAxgUA=.bcf14ffc-4dba-4c9c-8754-184172c5acbd@github.com>
 <U-6RiCpFVIrhLztPN6opiPcpFtxValDzU-K7WWFZM-4=.6bc8aaa4-636a-4664-b380-4c4af00513bd@github.com>
 <-cLIJ8pFHtnNoJMHV3aXI7XMJWp4Jrutc8Xn5PG0OK8=.d2cd87ab-3592-4524-ad85-05444c43689b@github.com>
 <r0UK2qjnmgeTNDDSWaSLPAj3QRgx_4YB82ielllO7jM=.fa615bc0-db49-4a74-b842-793f8f5209bb@github.com>
 <1T8kXDZN1bhHr4c8v4SQsImeBySCqTfX-u3_jzvyocA=.b4957400-9a33-4b6e-8475-329642a5888c@github.com>
 <XIux-dY0JXHRafHk48kVNXId9r-HSceNSytBojDxelY=.872e74cb-b064-406e-b71f-13c90ec7fbbc@github.com>
 <j4t2vT0SnwnU7lhKRlXtk967d-K6nA0EqHrqNbba7W0=.dc05dba6-bf7e-4606-8a02-9c2bad4b3b58@github.com>
 <fmVtPcBdgMuZOPm2qx3Q3znVZM7JgQPkhPAVLtwkOhE=.2d8b8447-cfae-4cb3-9a7c-6567a881231f@github.com>
 <GSeWP29fAIUFSk0CYsC557w52CuLqeUWwHNK9maltwI=.3d5f002e-6b74-4a57-a5d8-244d27da9dde@github.com>
 <GF8iEOkMUEL2dYB0HytFIc9gyeeUJ_KP0ImlqFsul2Y=.894afc05-9310-43e1-a308-8f7d71dc572b@github.com>
Message-ID: <97e11695-454a-0d8a-231b-ddc8506c1628@oracle.com>

On 07/10/2020 00:42, Mandy Chung wrote:
> On Wed, 30 Sep 2020 19:11:37 GMT, Mandy Chung <mchung at openjdk.org> wrote:
>
>>> The https://github.com/mlchung/jdk/pull/1 has been updated.
>> @plevart  I have merged your PR and made minor tweak.
>>
>> Please review CSR:  https://bugs.openjdk.java.net/browse/JDK-8253870
> Joe has given some feedback in the CSR review.
>> should this functionality be housed in the InvocationHandler interface rather than the Proxy class? If I understand the
>> intended usage of the new method, it should only be done in an InvocationHandler.
> The primary usage of this new method is `InvocationHandler`.  I agree that the new API should be defined in
> `InvocationHandler`.
>
> @plevart @AlanBateman any feedback or thought on moving the new API to `InvocationHandler`?
>
>
Are you thinking of a static method or a default method that throws and 
is overridden in the generated proxy class?

-Alan.

From mdoerr at openjdk.java.net  Wed Oct  7 14:47:20 2020
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Wed, 7 Oct 2020 14:47:20 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v2]
In-Reply-To: <6P-wrlA7c9wlXEhcoAYW5J9W2jwTmTTj3PkDObPh0LA=.c11aa048-8853-4e1c-a689-c34b89c15f12@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <6P-wrlA7c9wlXEhcoAYW5J9W2jwTmTTj3PkDObPh0LA=.c11aa048-8853-4e1c-a689-c34b89c15f12@github.com>
Message-ID: <EBJOWz3mKQcINbANH02rbc8XpGSBron9k6ifJ6dWt8E=.6578bcd3-6fed-4b6b-92ab-b6d590ce3fa0@github.com>

On Mon, 5 Oct 2020 18:29:58 GMT, CoreyAshford <github.com+51754783+CoreyAshford at openjdk.org> wrote:

>> This patch set encompasses the following commits:
>> 
>> - Adds a new HotSpot intrinsic candidate to the java.lang.Base64 class - decodeBlock(), and provides a flexible API for
>>   the intrinsic.  The API is similar to the existing encodeBlock intrinsic.
>> - Adds the code in HotSpot to check and martial the new intrinsic's arguments to the arch-specific intrinsic
>>   implementation
>> - Adds a Power64LE-specific implementation of the decodeBlock intrinsic.
>> - Adds a JMH microbenchmark for both Base64 encoding and encoding.
>> - Enhances the JTReg hotspot intrinsic "TestBase64.java" regression test to more fully test both decoding and encoding.
>
> CoreyAshford has updated the pull request with a new target base due to a merge or a rebase. The pull request now
> contains ten commits:
>  - AOT: Revert change to aotCodeHeap.cpp for decodeBlock
>    
>    Don't add the SET_AOT_GLOBAL_SYMBOL_VALUE macro for decode block until all
>    arches that implement AOT, implement the decodeBlock intrinsic.
>  - Base64.java decodeBlock: Changes from PR review
>    
>     * Make comparison safer and consistent with the while loop
>     * Update comment about the decodeBlock intrinsic so that it matches the new structure
>     * Add comment about the lack of a length check on the destination buffer
>     * As per issue 8138732, change HotSpotIntrinsicCandidate to IntrinsicCandidate
>  - stubGenerator_ppc.cpp: Changes from PR review
>    
>     * Fix clearing of upper bits to clear 32 bits instead of 31 (due to misreading of clrldi instruction)
>     * change and document loop_unrolls setting from 8 to 2 after re-running the benchmark
>     * align unrolled loop on a 32-byte boundary
>     * replace instruction used for checking isURL from a double word to single
>       word instruction since the register is effectively 32 bits wide
>     * cosmetic change to realign register comments.
>  - TestBase64.java: Changes from PR review
>    
>     * Use Utils.toByteArrays() method instead of a locally-defined method
>     * Generate the two non-Base64 tables dynamically rather than use static initialization
>     * Added comments describing the two above-mentioned arrays
>  - Expand the Base64 intrinsic regression test to cover decodeBlock
>    
>    This patch makes four significant changes:
>    
>    1) The Power implementation of the decodeBlock intrinsic, at least,
>    requires a decode length of at least 128 bytes, but the existing test cases
>    are much shorter, maxing out at 111 bytes.  So the patch adds a new input
>    data file which has longer test cases in it.
>    
>    2) The original test cases only covers the encoding of just the printable
>    subset of the 7-bit ASCII characters.  However, Base64 encoding requires
>    being able to encode arbitrary binary data, i.e. it must handle all 256
>    8-bit byte encodings.  To remedy this, but keep the original line-oriented
>    style of the input data, I added another input file type that uses a simple
>    ASCII hexadecimal encoding - two ASCII hex characters per 8-bit byte.  When
>    test0 is called, a new parameter is passed that specifies the type of the
>    input file, which is either the original ASCII type or the hexadecimal
>    format.  So to test both longer input data and arbitrary 8-bit data, the
>    newly added input test file has test cases which are both longer and
>    encoded in ASCII hex so as to give full 8-bit capability.  When reading
>    this type of file, test0 calls a newly-added function to translate the
>    ASCII hex to binary data.  Except for the first line of input data, which
>    contains all possible 8-bit values sequentially, the input data was
>    generated using a random length (between 111 and 520 bytes) buffer filled
>    with random 8-bit data, which should give adequate coverage.
>    
>    3) The original test did not test that the decoder detects illegal Base64
>    bytes.  This change chooses a random location in the encoded data to
>    corrupt with a randomly-chosen byte which is illegal for the specific
>    Base64 encoding that is chosen (i.e. standard or URLsafe).  It then calls
>    the decode function to verify that the illegal byte is detected and the
>    proper exception is thrown.
>    
>    4) The test iteration count was originally 100K, but that is far more than
>    enough iterations to test the intrinsic.  It takes 20K iterations on each
>    instrinsic for HotSpot C2 to begin calling it.  The test originally had
>    three types of encodings to test and called the encode intrinsic four times
>    for each iteration, which works out to 100K * 3 * 4 = 1.2M calls just to
>    encode.  Decode was called four times as well (now five because of the
>    illegal byte test).  I believe this is excessive and with the extra test
>    data I have added, the test was timing out after ten minutes of execution.
>    It appears that it is timing out, not because the intrinsics take a long
>    time to run, but because test0 generates an enormous number of discarded
>    data buffers for the GC system to recover (the test runs at about 39GB of
>    virtual memory on my test machine).  To remedy the timeout problem, I have
>    changed the code so that a warmup function of 20K repetitions is performed
>    on a fixed buffer, to activate the instrinsic(s).  After the warmup, I have
>    reduced the number of iterations to 5K on each test0 call.  This should
>    give adequate coverage.
>  - Add JMH benchmark for Base64 variable length buffer decoding
>  - Add Power9+ intrinsic implementation for Base64 decoding
>  - Add HotSpot code to implement Base64 decodeBlock API
>  - Add HotSpotIntrinsicCandidate and API for Base64 decoding

src/hotspot/cpu/ppc/stubGenerator_ppc.cpp line 3812:

> 3810:     // Address of the last byte of the source is (in + sl - 1)
> 3811:     __ add(end, in, sl);
> 3812:     __ subi(end, end, 1);

Looks a bit complicated, but ok. I'd have loaded the number of iterations into ctr and used bdnz instruction for the
loop.

src/hotspot/cpu/ppc/stubGenerator_ppc.cpp line 3671:

> 3669:     // an advantage to keeping loop_unrolls small (to be able to process
> 3670:     // smaller buffers), 2 is clearly the best choice.
> 3671:     const unsigned loop_unrolls = 2;

Unrolling should be re-evaluated after alignment is fixed. align(32) is currently at the wrong place (see my comment
below).

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

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

From lancea at openjdk.java.net  Wed Oct  7 14:48:25 2020
From: lancea at openjdk.java.net (Lance Andersen)
Date: Wed, 7 Oct 2020 14:48:25 GMT
Subject: RFR: 8253952: Work around wrong usage of
 ZipOutputStream.putNextEntry() in user code
In-Reply-To: <0nq5oFKOj6AZqCW6jF268-6oKRI6UkS6TRIHo-_5vKw=.d13c7016-4473-4b20-9117-100b368d3716@github.com>
References: <0nq5oFKOj6AZqCW6jF268-6oKRI6UkS6TRIHo-_5vKw=.d13c7016-4473-4b20-9117-100b368d3716@github.com>
Message-ID: <p2UvJrkjaGP8kJkMr6vxN5VDj5qsjhhQZP__SHJdJD8=.aabadbcf-d6c4-48c3-82a4-0fe5d18b23de@github.com>

On Tue, 6 Oct 2020 10:02:09 GMT, Volker Simonis <simonis at openjdk.org> wrote:

> ### Summary
> 
> Work around wrong usage of `ZipOutputStream.putNextEntry()` in user code which can lead to the `ZipException "invalid
> entry compressed size"`.
> ### Motivation
> 
> In general it is not safe to directly write a ZipEntry obtained from `ZipInputStream.getNextEntry()`,
> `ZipFile.entries()`, `ZipFile.getEntry()` or `ZipFile.stream()` with `ZipOutputStream.putNextEntry()` to a
> `ZipOutputStream` and then read the entries data from the `ZipInputStream` and write it to the `ZipOutputStream` as
> follows:
>  ZipEntry entry;
>  ZipInputStream zis = new ZipInputStream(...);
>  ZipOutputStream zos = new ZipOutputStream(...);
>  while((entry = zis.getNextEntry()) != null) {
>      zos.putNextEntry(entry);
>      zis.transferTo(zos);
>  }
> The problem with this code is that the zip file format does not record the compression level used for deflation in its
> entries. In general, it doesn't even mandate a predefined compression ratio per compression level. Therefore the
> compressed size recorded in a `ZipEntry` read from a zip file might differ from the new compressed size produced by the
> receiving `ZipOutputStream`. Such a difference will result in a `ZipException` with the following message:
>  java.util.zip.ZipException: invalid entry compressed size (expected 12 but got 7 bytes)
>  
> The correct way of copying all entries from one zip file into another requires the creation of a new `ZipEntry` or at
> least resetting of the compressed size field. E.g.:
>  while((entry = zis.getNextEntry()) != null) {
>      ZipEntry newEntry = new ZipEntry(entry.getName());
>      zos.putNextEntry(newEntry);
>      zis.transferTo(zos);
>  }
> or:
>  while((entry = zis.getNextEntry()) != null) {
>      entry.setCompressedSize(-1);
>      zos.putNextEntry(entry);
>      zis.transferTo(zos);
>  }
> Unfortunately, there's a lot of user code out there which gets this wrong and uses the bad coding pattern described
> before. Searching for `"java.util.zip.ZipException: invalid entry compressed size (expected 12 but got 7 bytes)"` gives
> ~2500 hits (~100 on StackOverflow). It's also no hard to find plenty of instances of this anti-pattern on GitHub when
> doing a code search for `ZipEntry` and `putNextEntry()`. E.g. [Gradle 4.x wrapper task][1] is affected as well as the
> latest version of the [mockableAndroidJar task][2]. I've recently fixed two occurrences of this pattern in OpenJDK (see
> [JDK-8240333][3] and [JDK-8240235][4]) but there still exist more of them (e.g.
> [`test/jdk/java/util/zip/ZipFile/CopyJar.java`][5] which is there since 1999 :).  ### Description  So while this has
> clearly been a problem before, it apparently wasn't painful enough to trigger any action from the side of the JDK.
> However, recently quite some zlib forks with [superior deflate/inflate performance have evolved][6]. Using them with
> OpenJDK is quite straight-forward: one just has to configure the alternative implementations by setting
> `LD_LIBRARY_PATH` or `LD_PRELOAD` correspondingly. We've seen big saving by using these new zlib implementations for
> selected services in production and the only reason why we haven't enabled them by default until now is the problem
> I've just described. The reason why these new libraries uncover the described anti-pattern much more often is because
> their compression ratio is slightly different from that of the default zlib library. This can easily trigger a
> `ZipException` even if an application is not using a different compression levels but just a zip file created with
> another zlib version.  I'd therefore like to propose the following workaround for the wrong
> `ZipOutputStream.putNextEntry()` usage in user code:
> -  ignore the compressed size if it was implicitly determined from the zip file and not explicitly set by calling
>    `ZipEntry.setCompressedSize()`.
> 
> - Change the API-documentation of `ZipOutputStream.putNextEntry()` and `JarOutputStream.putNextEntry()` to explain the
>   problem and why `putNextEntry()` will ignore the compressed size of a `ZipEntry` if that was set implicitely when
>   reading that entry from a `ZipFile` or `ZipInputStream`.
> 
> 
> ### Technical Details
> 
> A zip file consists of a stream of File Entries followed by a Central Directory (see [here for a more detailed
> specification][7]). Each File Entry is composed of a Local File Header (LFH) followed by the compressed Data and an
> optional Data Descriptor. The LFH contains the File Name and among other attributes the Compressed and Uncompressed
> size and CRC of the Data. In the case where the latter three attributes are not available at the time when the LFH is
> created, this fact will be recorded in a flag of the LFH and will trigger the creation of a Data Descriptor with the
> corresponding information right after the Data section. Finally, the Central Directory contains one Central Directory
> File Header (CDFH) for each entry of the  zip archive. The CDFH is an extended version of the LFH and the ultimate
> reference for the contents of the zip archive. The redundancy between LFH and CDFH is a tribute to zip's long history
> when it was used to store archives on multiple floppy discs and the CDFH allowed to update the archive by only writing
> to the last disc which contained the Central Directory.  `ZipEntries` read with `ZipInputStream.getNextEntry()` will
> initially only contain the information from the LFH. Only after the next entry was read (or after
> `ZipInputStream.closeEntry()` was called explicitly), will the previously read entry be updated with the data from the
> Data Descriptor. `ZipInputStream` doesn't inspect the Central Directory at all.  On the other hand, `ZipFile` only
> queries the Central Directory for `ZipEntry` information so all `ZipEntries` returned by `ZipFile.entries()`,
> `ZipFile.getEntry()` and `ZipFile.stream()` will always instantly contain the full Compressed and Uncompressed Size and
> CRC information for each entry independently of the LFH contents.  ### Risks and Assumptions  If we choose to ignore
> the implicitly recorded compressed size in a `ZipEntry` read from a zip file when writing it to a `ZipOutputStream`,
> this will lead to zip files with incomplete information in the LFH and an additional Data Descriptor as described
> before. However, the result is still fully compatible to the zip file specification. It's also not unusual, because by
> default all new zip files created with `ZipOutputStream` will contain LFHs without Compressed and Uncompressed Size and
> CRC information and an additional Data Descriptor. Theoretically it is possible to create new zip files with
> `ZipOutputStream` class and Compressed and Uncompressed Size and CRC information in the LFH but that's complex and
> inefficient because it requires two steps. A first step to determine the crc and compressed size of the data and a
> second step to actually write the data to the `ZipOutputStream` (which will compress it a second time). This is because
> the current API offers no possibility to write already compressed data to a `ZipOutputStream`.  Consequently, the only
> straight-forward way of creating zip files from Java which have all the data in the LFH and no Data Descriptor is by
> copying `ZipEntries` from an existing zip file with the buggy method described before. This incidentally worked more or
> less reliable for a long time but breaks miserably when using different zlib implementations. Ignoring the implicitly
> set compressed size of `ZipEntries` can easily fix this problem.  I'm not aware of any tool which can not handle such
> files and if it exists it would have problems with the majority of Java created zip files anyway (e.g. all jar-files
> created with the jar tool have zip entries with incomplete LFH data and additional Data Descriptor).  Ignoring the
> implicitly set compressed size of `ZipEntries` has no measurable performance impact and will increase the size of zip
> archives which used to have the complete file information in the LFH before by 16 bytes per entry. On the other hand it
> will give us the freedom to use whatever zip implementation we like :)   [1]:
> https://github.com/gradle/gradle/blob/e76905e3a/subprojects/build-init/src/main/java/org/gradle/api/tasks/wrapper/Wrapper.java#L152-L158
> [2]:
> https://android.googlesource.com/platform/tools/base/+/refs/heads/master/build-system/builder/src/main/java/com/android/builder/testing/MockableJarGenerator.java#86
> [3]: https://bugs.openjdk.java.net/browse/JDK-8240333 [4]: https://bugs.openjdk.java.net/browse/JDK-8240235 [5]:
> https://github.com/openjdk/jdk/blob/master/test/jdk/java/util/zip/ZipFile/CopyJar.java [6]:
> https://github.com/simonis/zlib-bench/blob/master/Results.md [7]: https://en.wikipedia.org/wiki/Zip_(file_format)

src/java.base/share/classes/java/util/zip/ZipOutputStream.java line 197:

> 195:      * Unless explictely set by calling {@link ZipEntry#setCompressedSize(long)}
> 196:      * this output stream will ignore the compressed size of a {@code ZipEntry}
> 197:      * and re-compute its value automatically after the associted data has been

typo "associated" -> "associated"

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

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

From herrick at openjdk.java.net  Wed Oct  7 14:54:24 2020
From: herrick at openjdk.java.net (Andy Herrick)
Date: Wed, 7 Oct 2020 14:54:24 GMT
Subject: RFR: 8253379: [windows] Several jpackage tests failed with error
 code 1638 [v2]
In-Reply-To: <LpRaGB39y6sd9g4cO4JZRPWsYl0oUtSO0l6Smv2xgbo=.992f6c8e-c478-4c3c-bf1e-5f43191336cd@github.com>
References: <LpRaGB39y6sd9g4cO4JZRPWsYl0oUtSO0l6Smv2xgbo=.992f6c8e-c478-4c3c-bf1e-5f43191336cd@github.com>
Message-ID: <vmagsVYNx5Y_-SlWwrEAkeDRNPpWCTSxlXpJCOdTrco=.d367241d-8f75-4f68-9357-7b76fc72f476@github.com>

> 8253379: [windows] Several jpackage tests failed with error code 1638
> two windows specific test fixes in WindowsHelper:
> 1.) do not test that the parent directory of a windows menu shortcut is empty after shortcut is uninstalled (there may
> be other shortcuts using that directory) 2.) do not programmatically install windows exe installers (since we have no
> way of programmatically uninstalling them)

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

  8253379: [windows] Several jpackage tests failed with error code 1638

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/337/files
  - new: https://git.openjdk.java.net/jdk/pull/337/files/1e20f1c7..3765ec29

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

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

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

From lancea at openjdk.java.net  Wed Oct  7 14:56:16 2020
From: lancea at openjdk.java.net (Lance Andersen)
Date: Wed, 7 Oct 2020 14:56:16 GMT
Subject: RFR: 8253952: Work around wrong usage of
 ZipOutputStream.putNextEntry() in user code
In-Reply-To: <0nq5oFKOj6AZqCW6jF268-6oKRI6UkS6TRIHo-_5vKw=.d13c7016-4473-4b20-9117-100b368d3716@github.com>
References: <0nq5oFKOj6AZqCW6jF268-6oKRI6UkS6TRIHo-_5vKw=.d13c7016-4473-4b20-9117-100b368d3716@github.com>
Message-ID: <_jTazFtrOPacCLAjyCVNmkt6qZffvqOKLdasvvKYJP0=.d558846b-05ce-4444-a435-6bc9cd166a39@github.com>

On Tue, 6 Oct 2020 10:02:09 GMT, Volker Simonis <simonis at openjdk.org> wrote:

> ### Summary
> 
> Work around wrong usage of `ZipOutputStream.putNextEntry()` in user code which can lead to the `ZipException "invalid
> entry compressed size"`.
> ### Motivation
> 
> In general it is not safe to directly write a ZipEntry obtained from `ZipInputStream.getNextEntry()`,
> `ZipFile.entries()`, `ZipFile.getEntry()` or `ZipFile.stream()` with `ZipOutputStream.putNextEntry()` to a
> `ZipOutputStream` and then read the entries data from the `ZipInputStream` and write it to the `ZipOutputStream` as
> follows:
>  ZipEntry entry;
>  ZipInputStream zis = new ZipInputStream(...);
>  ZipOutputStream zos = new ZipOutputStream(...);
>  while((entry = zis.getNextEntry()) != null) {
>      zos.putNextEntry(entry);
>      zis.transferTo(zos);
>  }
> The problem with this code is that the zip file format does not record the compression level used for deflation in its
> entries. In general, it doesn't even mandate a predefined compression ratio per compression level. Therefore the
> compressed size recorded in a `ZipEntry` read from a zip file might differ from the new compressed size produced by the
> receiving `ZipOutputStream`. Such a difference will result in a `ZipException` with the following message:
>  java.util.zip.ZipException: invalid entry compressed size (expected 12 but got 7 bytes)
>  
> The correct way of copying all entries from one zip file into another requires the creation of a new `ZipEntry` or at
> least resetting of the compressed size field. E.g.:
>  while((entry = zis.getNextEntry()) != null) {
>      ZipEntry newEntry = new ZipEntry(entry.getName());
>      zos.putNextEntry(newEntry);
>      zis.transferTo(zos);
>  }
> or:
>  while((entry = zis.getNextEntry()) != null) {
>      entry.setCompressedSize(-1);
>      zos.putNextEntry(entry);
>      zis.transferTo(zos);
>  }
> Unfortunately, there's a lot of user code out there which gets this wrong and uses the bad coding pattern described
> before. Searching for `"java.util.zip.ZipException: invalid entry compressed size (expected 12 but got 7 bytes)"` gives
> ~2500 hits (~100 on StackOverflow). It's also no hard to find plenty of instances of this anti-pattern on GitHub when
> doing a code search for `ZipEntry` and `putNextEntry()`. E.g. [Gradle 4.x wrapper task][1] is affected as well as the
> latest version of the [mockableAndroidJar task][2]. I've recently fixed two occurrences of this pattern in OpenJDK (see
> [JDK-8240333][3] and [JDK-8240235][4]) but there still exist more of them (e.g.
> [`test/jdk/java/util/zip/ZipFile/CopyJar.java`][5] which is there since 1999 :).  ### Description  So while this has
> clearly been a problem before, it apparently wasn't painful enough to trigger any action from the side of the JDK.
> However, recently quite some zlib forks with [superior deflate/inflate performance have evolved][6]. Using them with
> OpenJDK is quite straight-forward: one just has to configure the alternative implementations by setting
> `LD_LIBRARY_PATH` or `LD_PRELOAD` correspondingly. We've seen big saving by using these new zlib implementations for
> selected services in production and the only reason why we haven't enabled them by default until now is the problem
> I've just described. The reason why these new libraries uncover the described anti-pattern much more often is because
> their compression ratio is slightly different from that of the default zlib library. This can easily trigger a
> `ZipException` even if an application is not using a different compression levels but just a zip file created with
> another zlib version.  I'd therefore like to propose the following workaround for the wrong
> `ZipOutputStream.putNextEntry()` usage in user code:
> -  ignore the compressed size if it was implicitly determined from the zip file and not explicitly set by calling
>    `ZipEntry.setCompressedSize()`.
> 
> - Change the API-documentation of `ZipOutputStream.putNextEntry()` and `JarOutputStream.putNextEntry()` to explain the
>   problem and why `putNextEntry()` will ignore the compressed size of a `ZipEntry` if that was set implicitely when
>   reading that entry from a `ZipFile` or `ZipInputStream`.
> 
> 
> ### Technical Details
> 
> A zip file consists of a stream of File Entries followed by a Central Directory (see [here for a more detailed
> specification][7]). Each File Entry is composed of a Local File Header (LFH) followed by the compressed Data and an
> optional Data Descriptor. The LFH contains the File Name and among other attributes the Compressed and Uncompressed
> size and CRC of the Data. In the case where the latter three attributes are not available at the time when the LFH is
> created, this fact will be recorded in a flag of the LFH and will trigger the creation of a Data Descriptor with the
> corresponding information right after the Data section. Finally, the Central Directory contains one Central Directory
> File Header (CDFH) for each entry of the  zip archive. The CDFH is an extended version of the LFH and the ultimate
> reference for the contents of the zip archive. The redundancy between LFH and CDFH is a tribute to zip's long history
> when it was used to store archives on multiple floppy discs and the CDFH allowed to update the archive by only writing
> to the last disc which contained the Central Directory.  `ZipEntries` read with `ZipInputStream.getNextEntry()` will
> initially only contain the information from the LFH. Only after the next entry was read (or after
> `ZipInputStream.closeEntry()` was called explicitly), will the previously read entry be updated with the data from the
> Data Descriptor. `ZipInputStream` doesn't inspect the Central Directory at all.  On the other hand, `ZipFile` only
> queries the Central Directory for `ZipEntry` information so all `ZipEntries` returned by `ZipFile.entries()`,
> `ZipFile.getEntry()` and `ZipFile.stream()` will always instantly contain the full Compressed and Uncompressed Size and
> CRC information for each entry independently of the LFH contents.  ### Risks and Assumptions  If we choose to ignore
> the implicitly recorded compressed size in a `ZipEntry` read from a zip file when writing it to a `ZipOutputStream`,
> this will lead to zip files with incomplete information in the LFH and an additional Data Descriptor as described
> before. However, the result is still fully compatible to the zip file specification. It's also not unusual, because by
> default all new zip files created with `ZipOutputStream` will contain LFHs without Compressed and Uncompressed Size and
> CRC information and an additional Data Descriptor. Theoretically it is possible to create new zip files with
> `ZipOutputStream` class and Compressed and Uncompressed Size and CRC information in the LFH but that's complex and
> inefficient because it requires two steps. A first step to determine the crc and compressed size of the data and a
> second step to actually write the data to the `ZipOutputStream` (which will compress it a second time). This is because
> the current API offers no possibility to write already compressed data to a `ZipOutputStream`.  Consequently, the only
> straight-forward way of creating zip files from Java which have all the data in the LFH and no Data Descriptor is by
> copying `ZipEntries` from an existing zip file with the buggy method described before. This incidentally worked more or
> less reliable for a long time but breaks miserably when using different zlib implementations. Ignoring the implicitly
> set compressed size of `ZipEntries` can easily fix this problem.  I'm not aware of any tool which can not handle such
> files and if it exists it would have problems with the majority of Java created zip files anyway (e.g. all jar-files
> created with the jar tool have zip entries with incomplete LFH data and additional Data Descriptor).  Ignoring the
> implicitly set compressed size of `ZipEntries` has no measurable performance impact and will increase the size of zip
> archives which used to have the complete file information in the LFH before by 16 bytes per entry. On the other hand it
> will give us the freedom to use whatever zip implementation we like :)   [1]:
> https://github.com/gradle/gradle/blob/e76905e3a/subprojects/build-init/src/main/java/org/gradle/api/tasks/wrapper/Wrapper.java#L152-L158
> [2]:
> https://android.googlesource.com/platform/tools/base/+/refs/heads/master/build-system/builder/src/main/java/com/android/builder/testing/MockableJarGenerator.java#86
> [3]: https://bugs.openjdk.java.net/browse/JDK-8240333 [4]: https://bugs.openjdk.java.net/browse/JDK-8240235 [5]:
> https://github.com/openjdk/jdk/blob/master/test/jdk/java/util/zip/ZipFile/CopyJar.java [6]:
> https://github.com/simonis/zlib-bench/blob/master/Results.md [7]: https://en.wikipedia.org/wiki/Zip_(file_format)

src/java.base/share/classes/java/util/zip/ZipOutputStream.java line 186:

> 184:      * the entry has no set modification time.
> 185:      *
> 186:      * The zip file format does not record the compression level used for the

"zip" ->"ZIP" for consistency'

Should this refer to the Zip File Format specification?

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

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

From redestad at openjdk.java.net  Wed Oct  7 15:01:16 2020
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 7 Oct 2020 15:01:16 GMT
Subject: RFR: 8254146: Avoid unnecessary volatile write on new
 AtomicBoolean(false)
In-Reply-To: <yNUBzMyHr1Asbrtyt2sHQnGcJOxdfP8umMyRPC863Rw=.5c18ea25-bcf8-473b-a86a-fe764b8684d6@github.com>
References: <AzWKluHZjvFYm2wUanwYfn91iKKMacpk_qSsje3tXWk=.ba873b46-4e12-4415-8832-fa314d6759a3@github.com>
 <yNUBzMyHr1Asbrtyt2sHQnGcJOxdfP8umMyRPC863Rw=.5c18ea25-bcf8-473b-a86a-fe764b8684d6@github.com>
Message-ID: <P4lM3Rv3CAm7OqpNbLH3mvmgpVv0nVY1TeDw0VFy7jY=.54c361de-0133-4e10-ae04-12c79686e16a@github.com>

On Wed, 7 Oct 2020 13:38:36 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Hi,
>> 
>> the following PR optimizes `new AtomicBoolean(boolean)` by avoiding the volatile write in case `false` is passed.
>> Essentially, it changes the ternary operator to a simple `if` without the `else` that would cause the volatile write.
>> The resulting bytecode seems to also benefit from the change:
>>     Code:
>>        0: aload_0
>>        1: invokespecial #1                  // Method java/lang/Object."<init>":()V
>>        4: aload_0
>>        5: iload_1
>>        6: ifeq          13
>>        9: iconst_1
>>       10: goto          14
>>       13: iconst_0
>>       14: putfield      #7                  // Field value:I
>>       17: return
>> 
>> After:
>>     Code:
>>        0: aload_0
>>        1: invokespecial #1                  // Method java/lang/Object."<init>":()V
>>        4: iload_1
>>        5: ifeq          13
>>        8: aload_0
>>        9: iconst_1
>>       10: putfield      #7                  // Field value:I
>>       13: return
>> 
>> A simple benchmark that returns `new AtomicBoolean(false)` shows the following results, that brings it on par to `new
>> AtomicBoolean()`: MyBenchmark.empty                                         avgt   10     3,103 ?   0,246   ns/op
>> MyBenchmark.explicitNew                                   avgt   10     2,966 ?   0,071   ns/op
>> MyBenchmark.explicitOld                                   avgt   10     7,738 ?   0,321   ns/op
>> 
>> In case you think this is worthwhile I'd be happy if this is sponsored.
>> Cheers,
>> Christoph
>
> Marked as reviewed by rriggs (Reviewer).

> @AlanBateman What would be the label (or workflow) for that now?

@dreis2211 what Alan reminded us of here is that all of j.u.concurrent is maintained upstream from the OpenJDK, and
that this change needs to be coordinated with the maintainers there. Either by getting an OK to go ahead and push this
as-is, or by contributing this patch to the JSR166 repo directly (which will then be integrated back into the OpenJDK
at some point). See http://gee.cs.oswego.edu/dl/concurrency-interest/

This isn't anything new since the GitHub migration: Various bits and pieces of the OpenJDK sources are maintained
upstream, and it's not always easy to igure out exactly where or how to go about upstreaming a change.

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

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

From herrick at openjdk.java.net  Wed Oct  7 15:08:31 2020
From: herrick at openjdk.java.net (Andy Herrick)
Date: Wed, 7 Oct 2020 15:08:31 GMT
Subject: RFR: 8253379: [windows] Several jpackage tests failed with error
 code 1638 [v3]
In-Reply-To: <LpRaGB39y6sd9g4cO4JZRPWsYl0oUtSO0l6Smv2xgbo=.992f6c8e-c478-4c3c-bf1e-5f43191336cd@github.com>
References: <LpRaGB39y6sd9g4cO4JZRPWsYl0oUtSO0l6Smv2xgbo=.992f6c8e-c478-4c3c-bf1e-5f43191336cd@github.com>
Message-ID: <p_OjRcLzDzBVDoQeNkQeS6T2KHzt3CN34Dz8caoxx84=.8d0722fd-0215-4d46-8f0a-b62d48335b01@github.com>

> 8253379: [windows] Several jpackage tests failed with error code 1638
> two windows specific test fixes in WindowsHelper:
> 1.) do not test that the parent directory of a windows menu shortcut is empty after shortcut is uninstalled (there may
> be other shortcuts using that directory) 2.) do not programmatically install windows exe installers (since we have no
> way of programmatically uninstalling them)

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

  8253379: [windows] Several jpackage tests failed with error code 1638

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/337/files
  - new: https://git.openjdk.java.net/jdk/pull/337/files/3765ec29..7250aae9

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

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

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

From Alan.Bateman at oracle.com  Wed Oct  7 15:11:53 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 7 Oct 2020 16:11:53 +0100
Subject: Request for Discussion: 8253952: Work around wrong usage of
 ZipOutputStream.putNextEntry() in user code
In-Reply-To: <CA+3eh11g+Pj9pVVLYGF3afgmtDx5qdS3m8D5KGwKWfP8VXO1aQ@mail.gmail.com>
References: <CA+3eh12_-fNxf_KFK68WEqVoD_n6CD7RCbe=LoKCyCeUQ3w0oQ@mail.gmail.com>
 <4658d3a6-3360-fb84-e5ff-20dc6cc61b92@oracle.com>
 <CA+3eh10vr3vs92UPu7PwiaofZpf46QuzsuFf4bvf26gbYKF3-g@mail.gmail.com>
 <99e80b7e-7702-338d-cd92-c9d1a396dfa5@oracle.com>
 <CA+3eh11g+Pj9pVVLYGF3afgmtDx5qdS3m8D5KGwKWfP8VXO1aQ@mail.gmail.com>
Message-ID: <809e78ae-0060-f9b8-531d-d4c5cc3c70b7@oracle.com>

On 06/10/2020 15:44, Volker Simonis wrote:
> :
> Sorry, maybe I'm missing something, but I can't find a single
> reference to neither ZipOutput- nor ZipInputStream in the ZipEntry
> class.
>
I should have been clearer. If the method is on ZOS then you have the 
receiver and the ZipEntry parameter. If you are exploring methods on 
ZipEntry then you have the receiver and the ZOS parameter.

-Alan

From alanb at openjdk.java.net  Wed Oct  7 15:13:11 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 7 Oct 2020 15:13:11 GMT
Subject: RFR: 8253952: Work around wrong usage of
 ZipOutputStream.putNextEntry() in user code
In-Reply-To: <0nq5oFKOj6AZqCW6jF268-6oKRI6UkS6TRIHo-_5vKw=.d13c7016-4473-4b20-9117-100b368d3716@github.com>
References: <0nq5oFKOj6AZqCW6jF268-6oKRI6UkS6TRIHo-_5vKw=.d13c7016-4473-4b20-9117-100b368d3716@github.com>
Message-ID: <c12QhQcAA4YctkyHYdULM9mSQ6KI9iqZM5MAuLJroGE=.a84fc8f5-411c-4ec0-b421-c3cf62c849c7@github.com>

On Tue, 6 Oct 2020 10:02:09 GMT, Volker Simonis <simonis at openjdk.org> wrote:

> ### Summary
> 
> Work around wrong usage of `ZipOutputStream.putNextEntry()` in user code which can lead to the `ZipException "invalid
> entry compressed size"`.
> ### Motivation
> 
> In general it is not safe to directly write a ZipEntry obtained from `ZipInputStream.getNextEntry()`,
> `ZipFile.entries()`, `ZipFile.getEntry()` or `ZipFile.stream()` with `ZipOutputStream.putNextEntry()` to a
> `ZipOutputStream` and then read the entries data from the `ZipInputStream` and write it to the `ZipOutputStream` as
> follows:
>  ZipEntry entry;
>  ZipInputStream zis = new ZipInputStream(...);
>  ZipOutputStream zos = new ZipOutputStream(...);
>  while((entry = zis.getNextEntry()) != null) {
>      zos.putNextEntry(entry);
>      zis.transferTo(zos);
>  }
> The problem with this code is that the zip file format does not record the compression level used for deflation in its
> entries. In general, it doesn't even mandate a predefined compression ratio per compression level. Therefore the
> compressed size recorded in a `ZipEntry` read from a zip file might differ from the new compressed size produced by the
> receiving `ZipOutputStream`. Such a difference will result in a `ZipException` with the following message:
>  java.util.zip.ZipException: invalid entry compressed size (expected 12 but got 7 bytes)
>  
> The correct way of copying all entries from one zip file into another requires the creation of a new `ZipEntry` or at
> least resetting of the compressed size field. E.g.:
>  while((entry = zis.getNextEntry()) != null) {
>      ZipEntry newEntry = new ZipEntry(entry.getName());
>      zos.putNextEntry(newEntry);
>      zis.transferTo(zos);
>  }
> or:
>  while((entry = zis.getNextEntry()) != null) {
>      entry.setCompressedSize(-1);
>      zos.putNextEntry(entry);
>      zis.transferTo(zos);
>  }
> Unfortunately, there's a lot of user code out there which gets this wrong and uses the bad coding pattern described
> before. Searching for `"java.util.zip.ZipException: invalid entry compressed size (expected 12 but got 7 bytes)"` gives
> ~2500 hits (~100 on StackOverflow). It's also no hard to find plenty of instances of this anti-pattern on GitHub when
> doing a code search for `ZipEntry` and `putNextEntry()`. E.g. [Gradle 4.x wrapper task][1] is affected as well as the
> latest version of the [mockableAndroidJar task][2]. I've recently fixed two occurrences of this pattern in OpenJDK (see
> [JDK-8240333][3] and [JDK-8240235][4]) but there still exist more of them (e.g.
> [`test/jdk/java/util/zip/ZipFile/CopyJar.java`][5] which is there since 1999 :).  ### Description  So while this has
> clearly been a problem before, it apparently wasn't painful enough to trigger any action from the side of the JDK.
> However, recently quite some zlib forks with [superior deflate/inflate performance have evolved][6]. Using them with
> OpenJDK is quite straight-forward: one just has to configure the alternative implementations by setting
> `LD_LIBRARY_PATH` or `LD_PRELOAD` correspondingly. We've seen big saving by using these new zlib implementations for
> selected services in production and the only reason why we haven't enabled them by default until now is the problem
> I've just described. The reason why these new libraries uncover the described anti-pattern much more often is because
> their compression ratio is slightly different from that of the default zlib library. This can easily trigger a
> `ZipException` even if an application is not using a different compression levels but just a zip file created with
> another zlib version.  I'd therefore like to propose the following workaround for the wrong
> `ZipOutputStream.putNextEntry()` usage in user code:
> -  ignore the compressed size if it was implicitly determined from the zip file and not explicitly set by calling
>    `ZipEntry.setCompressedSize()`.
> 
> - Change the API-documentation of `ZipOutputStream.putNextEntry()` and `JarOutputStream.putNextEntry()` to explain the
>   problem and why `putNextEntry()` will ignore the compressed size of a `ZipEntry` if that was set implicitely when
>   reading that entry from a `ZipFile` or `ZipInputStream`.
> 
> 
> ### Technical Details
> 
> A zip file consists of a stream of File Entries followed by a Central Directory (see [here for a more detailed
> specification][7]). Each File Entry is composed of a Local File Header (LFH) followed by the compressed Data and an
> optional Data Descriptor. The LFH contains the File Name and among other attributes the Compressed and Uncompressed
> size and CRC of the Data. In the case where the latter three attributes are not available at the time when the LFH is
> created, this fact will be recorded in a flag of the LFH and will trigger the creation of a Data Descriptor with the
> corresponding information right after the Data section. Finally, the Central Directory contains one Central Directory
> File Header (CDFH) for each entry of the  zip archive. The CDFH is an extended version of the LFH and the ultimate
> reference for the contents of the zip archive. The redundancy between LFH and CDFH is a tribute to zip's long history
> when it was used to store archives on multiple floppy discs and the CDFH allowed to update the archive by only writing
> to the last disc which contained the Central Directory.  `ZipEntries` read with `ZipInputStream.getNextEntry()` will
> initially only contain the information from the LFH. Only after the next entry was read (or after
> `ZipInputStream.closeEntry()` was called explicitly), will the previously read entry be updated with the data from the
> Data Descriptor. `ZipInputStream` doesn't inspect the Central Directory at all.  On the other hand, `ZipFile` only
> queries the Central Directory for `ZipEntry` information so all `ZipEntries` returned by `ZipFile.entries()`,
> `ZipFile.getEntry()` and `ZipFile.stream()` will always instantly contain the full Compressed and Uncompressed Size and
> CRC information for each entry independently of the LFH contents.  ### Risks and Assumptions  If we choose to ignore
> the implicitly recorded compressed size in a `ZipEntry` read from a zip file when writing it to a `ZipOutputStream`,
> this will lead to zip files with incomplete information in the LFH and an additional Data Descriptor as described
> before. However, the result is still fully compatible to the zip file specification. It's also not unusual, because by
> default all new zip files created with `ZipOutputStream` will contain LFHs without Compressed and Uncompressed Size and
> CRC information and an additional Data Descriptor. Theoretically it is possible to create new zip files with
> `ZipOutputStream` class and Compressed and Uncompressed Size and CRC information in the LFH but that's complex and
> inefficient because it requires two steps. A first step to determine the crc and compressed size of the data and a
> second step to actually write the data to the `ZipOutputStream` (which will compress it a second time). This is because
> the current API offers no possibility to write already compressed data to a `ZipOutputStream`.  Consequently, the only
> straight-forward way of creating zip files from Java which have all the data in the LFH and no Data Descriptor is by
> copying `ZipEntries` from an existing zip file with the buggy method described before. This incidentally worked more or
> less reliable for a long time but breaks miserably when using different zlib implementations. Ignoring the implicitly
> set compressed size of `ZipEntries` can easily fix this problem.  I'm not aware of any tool which can not handle such
> files and if it exists it would have problems with the majority of Java created zip files anyway (e.g. all jar-files
> created with the jar tool have zip entries with incomplete LFH data and additional Data Descriptor).  Ignoring the
> implicitly set compressed size of `ZipEntries` has no measurable performance impact and will increase the size of zip
> archives which used to have the complete file information in the LFH before by 16 bytes per entry. On the other hand it
> will give us the freedom to use whatever zip implementation we like :)   [1]:
> https://github.com/gradle/gradle/blob/e76905e3a/subprojects/build-init/src/main/java/org/gradle/api/tasks/wrapper/Wrapper.java#L152-L158
> [2]:
> https://android.googlesource.com/platform/tools/base/+/refs/heads/master/build-system/builder/src/main/java/com/android/builder/testing/MockableJarGenerator.java#86
> [3]: https://bugs.openjdk.java.net/browse/JDK-8240333 [4]: https://bugs.openjdk.java.net/browse/JDK-8240235 [5]:
> https://github.com/openjdk/jdk/blob/master/test/jdk/java/util/zip/ZipFile/CopyJar.java [6]:
> https://github.com/simonis/zlib-bench/blob/master/Results.md [7]: https://en.wikipedia.org/wiki/Zip_(file_format)

src/java.base/share/classes/java/util/jar/JarOutputStream.java line 97:

> 95:      * and re-compute its value automatically after the associted data has been
> 96:      * completely deflated.
> 97:      *

We probably need to do a bit wordsmithing here.

I think I'd drop the first two sentences and instead start a new paragraph here (<p> tag) with "Unless explicitly set,
the output stream will ignore ..." and see how that looks.

Probably should be "the ZipEntry" rather than "a ZipEntry" to be consistent with the parameter description.

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

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

From mdoerr at openjdk.java.net  Wed Oct  7 15:18:30 2020
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Wed, 7 Oct 2020 15:18:30 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v2]
In-Reply-To: <6P-wrlA7c9wlXEhcoAYW5J9W2jwTmTTj3PkDObPh0LA=.c11aa048-8853-4e1c-a689-c34b89c15f12@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <6P-wrlA7c9wlXEhcoAYW5J9W2jwTmTTj3PkDObPh0LA=.c11aa048-8853-4e1c-a689-c34b89c15f12@github.com>
Message-ID: <rnI7hCJFNObraJ1fywhxrbQ8jqPbAtPtyxMN85xTD4I=.b9ec9107-b1e2-4d4e-bf0e-aa07bfd3ee64@github.com>

On Mon, 5 Oct 2020 18:29:58 GMT, CoreyAshford <github.com+51754783+CoreyAshford at openjdk.org> wrote:

>> This patch set encompasses the following commits:
>> 
>> - Adds a new HotSpot intrinsic candidate to the java.lang.Base64 class - decodeBlock(), and provides a flexible API for
>>   the intrinsic.  The API is similar to the existing encodeBlock intrinsic.
>> - Adds the code in HotSpot to check and martial the new intrinsic's arguments to the arch-specific intrinsic
>>   implementation
>> - Adds a Power64LE-specific implementation of the decodeBlock intrinsic.
>> - Adds a JMH microbenchmark for both Base64 encoding and encoding.
>> - Enhances the JTReg hotspot intrinsic "TestBase64.java" regression test to more fully test both decoding and encoding.
>
> CoreyAshford has updated the pull request with a new target base due to a merge or a rebase. The pull request now
> contains ten commits:
>  - AOT: Revert change to aotCodeHeap.cpp for decodeBlock
>    
>    Don't add the SET_AOT_GLOBAL_SYMBOL_VALUE macro for decode block until all
>    arches that implement AOT, implement the decodeBlock intrinsic.
>  - Base64.java decodeBlock: Changes from PR review
>    
>     * Make comparison safer and consistent with the while loop
>     * Update comment about the decodeBlock intrinsic so that it matches the new structure
>     * Add comment about the lack of a length check on the destination buffer
>     * As per issue 8138732, change HotSpotIntrinsicCandidate to IntrinsicCandidate
>  - stubGenerator_ppc.cpp: Changes from PR review
>    
>     * Fix clearing of upper bits to clear 32 bits instead of 31 (due to misreading of clrldi instruction)
>     * change and document loop_unrolls setting from 8 to 2 after re-running the benchmark
>     * align unrolled loop on a 32-byte boundary
>     * replace instruction used for checking isURL from a double word to single
>       word instruction since the register is effectively 32 bits wide
>     * cosmetic change to realign register comments.
>  - TestBase64.java: Changes from PR review
>    
>     * Use Utils.toByteArrays() method instead of a locally-defined method
>     * Generate the two non-Base64 tables dynamically rather than use static initialization
>     * Added comments describing the two above-mentioned arrays
>  - Expand the Base64 intrinsic regression test to cover decodeBlock
>    
>    This patch makes four significant changes:
>    
>    1) The Power implementation of the decodeBlock intrinsic, at least,
>    requires a decode length of at least 128 bytes, but the existing test cases
>    are much shorter, maxing out at 111 bytes.  So the patch adds a new input
>    data file which has longer test cases in it.
>    
>    2) The original test cases only covers the encoding of just the printable
>    subset of the 7-bit ASCII characters.  However, Base64 encoding requires
>    being able to encode arbitrary binary data, i.e. it must handle all 256
>    8-bit byte encodings.  To remedy this, but keep the original line-oriented
>    style of the input data, I added another input file type that uses a simple
>    ASCII hexadecimal encoding - two ASCII hex characters per 8-bit byte.  When
>    test0 is called, a new parameter is passed that specifies the type of the
>    input file, which is either the original ASCII type or the hexadecimal
>    format.  So to test both longer input data and arbitrary 8-bit data, the
>    newly added input test file has test cases which are both longer and
>    encoded in ASCII hex so as to give full 8-bit capability.  When reading
>    this type of file, test0 calls a newly-added function to translate the
>    ASCII hex to binary data.  Except for the first line of input data, which
>    contains all possible 8-bit values sequentially, the input data was
>    generated using a random length (between 111 and 520 bytes) buffer filled
>    with random 8-bit data, which should give adequate coverage.
>    
>    3) The original test did not test that the decoder detects illegal Base64
>    bytes.  This change chooses a random location in the encoded data to
>    corrupt with a randomly-chosen byte which is illegal for the specific
>    Base64 encoding that is chosen (i.e. standard or URLsafe).  It then calls
>    the decode function to verify that the illegal byte is detected and the
>    proper exception is thrown.
>    
>    4) The test iteration count was originally 100K, but that is far more than
>    enough iterations to test the intrinsic.  It takes 20K iterations on each
>    instrinsic for HotSpot C2 to begin calling it.  The test originally had
>    three types of encodings to test and called the encode intrinsic four times
>    for each iteration, which works out to 100K * 3 * 4 = 1.2M calls just to
>    encode.  Decode was called four times as well (now five because of the
>    illegal byte test).  I believe this is excessive and with the extra test
>    data I have added, the test was timing out after ten minutes of execution.
>    It appears that it is timing out, not because the intrinsics take a long
>    time to run, but because test0 generates an enormous number of discarded
>    data buffers for the GC system to recover (the test runs at about 39GB of
>    virtual memory on my test machine).  To remedy the timeout problem, I have
>    changed the code so that a warmup function of 20K repetitions is performed
>    on a fixed buffer, to activate the instrinsic(s).  After the warmup, I have
>    reduced the number of iterations to 5K on each test0 call.  This should
>    give adequate coverage.
>  - Add JMH benchmark for Base64 variable length buffer decoding
>  - Add Power9+ intrinsic implementation for Base64 decoding
>  - Add HotSpot code to implement Base64 decodeBlock API
>  - Add HotSpotIntrinsicCandidate and API for Base64 decoding

src/hotspot/cpu/ppc/vm_version_ppc.cpp line 160:

> 158:     if (UseBASE64Intrinsics) {
> 159:       warning("UseBASE64Intrinsics specified, but needs at least Power9.");
> 160:       FLAG_SET_DEFAULT(UseCharacterCompareIntrinsics, false);

Copy & paste bug.

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

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

From mdoerr at openjdk.java.net  Wed Oct  7 15:21:11 2020
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Wed, 7 Oct 2020 15:21:11 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v2]
In-Reply-To: <6P-wrlA7c9wlXEhcoAYW5J9W2jwTmTTj3PkDObPh0LA=.c11aa048-8853-4e1c-a689-c34b89c15f12@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <6P-wrlA7c9wlXEhcoAYW5J9W2jwTmTTj3PkDObPh0LA=.c11aa048-8853-4e1c-a689-c34b89c15f12@github.com>
Message-ID: <hgCh4kI6MtKoOIrxQny7QnEv2qwS6KuLrezICPMviHw=.53ec3cf5-92ce-4a01-b9ae-5536a7944128@github.com>

On Mon, 5 Oct 2020 18:29:58 GMT, CoreyAshford <github.com+51754783+CoreyAshford at openjdk.org> wrote:

>> This patch set encompasses the following commits:
>> 
>> - Adds a new HotSpot intrinsic candidate to the java.lang.Base64 class - decodeBlock(), and provides a flexible API for
>>   the intrinsic.  The API is similar to the existing encodeBlock intrinsic.
>> - Adds the code in HotSpot to check and martial the new intrinsic's arguments to the arch-specific intrinsic
>>   implementation
>> - Adds a Power64LE-specific implementation of the decodeBlock intrinsic.
>> - Adds a JMH microbenchmark for both Base64 encoding and encoding.
>> - Enhances the JTReg hotspot intrinsic "TestBase64.java" regression test to more fully test both decoding and encoding.
>
> CoreyAshford has updated the pull request with a new target base due to a merge or a rebase. The pull request now
> contains ten commits:
>  - AOT: Revert change to aotCodeHeap.cpp for decodeBlock
>    
>    Don't add the SET_AOT_GLOBAL_SYMBOL_VALUE macro for decode block until all
>    arches that implement AOT, implement the decodeBlock intrinsic.
>  - Base64.java decodeBlock: Changes from PR review
>    
>     * Make comparison safer and consistent with the while loop
>     * Update comment about the decodeBlock intrinsic so that it matches the new structure
>     * Add comment about the lack of a length check on the destination buffer
>     * As per issue 8138732, change HotSpotIntrinsicCandidate to IntrinsicCandidate
>  - stubGenerator_ppc.cpp: Changes from PR review
>    
>     * Fix clearing of upper bits to clear 32 bits instead of 31 (due to misreading of clrldi instruction)
>     * change and document loop_unrolls setting from 8 to 2 after re-running the benchmark
>     * align unrolled loop on a 32-byte boundary
>     * replace instruction used for checking isURL from a double word to single
>       word instruction since the register is effectively 32 bits wide
>     * cosmetic change to realign register comments.
>  - TestBase64.java: Changes from PR review
>    
>     * Use Utils.toByteArrays() method instead of a locally-defined method
>     * Generate the two non-Base64 tables dynamically rather than use static initialization
>     * Added comments describing the two above-mentioned arrays
>  - Expand the Base64 intrinsic regression test to cover decodeBlock
>    
>    This patch makes four significant changes:
>    
>    1) The Power implementation of the decodeBlock intrinsic, at least,
>    requires a decode length of at least 128 bytes, but the existing test cases
>    are much shorter, maxing out at 111 bytes.  So the patch adds a new input
>    data file which has longer test cases in it.
>    
>    2) The original test cases only covers the encoding of just the printable
>    subset of the 7-bit ASCII characters.  However, Base64 encoding requires
>    being able to encode arbitrary binary data, i.e. it must handle all 256
>    8-bit byte encodings.  To remedy this, but keep the original line-oriented
>    style of the input data, I added another input file type that uses a simple
>    ASCII hexadecimal encoding - two ASCII hex characters per 8-bit byte.  When
>    test0 is called, a new parameter is passed that specifies the type of the
>    input file, which is either the original ASCII type or the hexadecimal
>    format.  So to test both longer input data and arbitrary 8-bit data, the
>    newly added input test file has test cases which are both longer and
>    encoded in ASCII hex so as to give full 8-bit capability.  When reading
>    this type of file, test0 calls a newly-added function to translate the
>    ASCII hex to binary data.  Except for the first line of input data, which
>    contains all possible 8-bit values sequentially, the input data was
>    generated using a random length (between 111 and 520 bytes) buffer filled
>    with random 8-bit data, which should give adequate coverage.
>    
>    3) The original test did not test that the decoder detects illegal Base64
>    bytes.  This change chooses a random location in the encoded data to
>    corrupt with a randomly-chosen byte which is illegal for the specific
>    Base64 encoding that is chosen (i.e. standard or URLsafe).  It then calls
>    the decode function to verify that the illegal byte is detected and the
>    proper exception is thrown.
>    
>    4) The test iteration count was originally 100K, but that is far more than
>    enough iterations to test the intrinsic.  It takes 20K iterations on each
>    instrinsic for HotSpot C2 to begin calling it.  The test originally had
>    three types of encodings to test and called the encode intrinsic four times
>    for each iteration, which works out to 100K * 3 * 4 = 1.2M calls just to
>    encode.  Decode was called four times as well (now five because of the
>    illegal byte test).  I believe this is excessive and with the extra test
>    data I have added, the test was timing out after ten minutes of execution.
>    It appears that it is timing out, not because the intrinsics take a long
>    time to run, but because test0 generates an enormous number of discarded
>    data buffers for the GC system to recover (the test runs at about 39GB of
>    virtual memory on my test machine).  To remedy the timeout problem, I have
>    changed the code so that a warmup function of 20K repetitions is performed
>    on a fixed buffer, to activate the instrinsic(s).  After the warmup, I have
>    reduced the number of iterations to 5K on each test0 call.  This should
>    give adequate coverage.
>  - Add JMH benchmark for Base64 variable length buffer decoding
>  - Add Power9+ intrinsic implementation for Base64 decoding
>  - Add HotSpot code to implement Base64 decodeBlock API
>  - Add HotSpotIntrinsicCandidate and API for Base64 decoding

src/hotspot/share/classfile/vmIntrinsics.cpp line 491:

> 489:     if (!UseGHASHIntrinsics) return true;
> 490:     break;
> 491:   case vmIntrinsics::_base64_decodeBlock:

I'd prefer to use consistent order. You have inserted decode after encode at other places.

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

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

From mdoerr at openjdk.java.net  Wed Oct  7 15:27:09 2020
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Wed, 7 Oct 2020 15:27:09 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v2]
In-Reply-To: <6P-wrlA7c9wlXEhcoAYW5J9W2jwTmTTj3PkDObPh0LA=.c11aa048-8853-4e1c-a689-c34b89c15f12@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <6P-wrlA7c9wlXEhcoAYW5J9W2jwTmTTj3PkDObPh0LA=.c11aa048-8853-4e1c-a689-c34b89c15f12@github.com>
Message-ID: <W3jA3X5aarlR1-7K9M4Xj99SJYshONXNMrP0p8hp9gU=.16257956-a74f-41f6-81ae-47a0ea65ad14@github.com>

On Mon, 5 Oct 2020 18:29:58 GMT, CoreyAshford <github.com+51754783+CoreyAshford at openjdk.org> wrote:

>> This patch set encompasses the following commits:
>> 
>> - Adds a new HotSpot intrinsic candidate to the java.lang.Base64 class - decodeBlock(), and provides a flexible API for
>>   the intrinsic.  The API is similar to the existing encodeBlock intrinsic.
>> - Adds the code in HotSpot to check and martial the new intrinsic's arguments to the arch-specific intrinsic
>>   implementation
>> - Adds a Power64LE-specific implementation of the decodeBlock intrinsic.
>> - Adds a JMH microbenchmark for both Base64 encoding and encoding.
>> - Enhances the JTReg hotspot intrinsic "TestBase64.java" regression test to more fully test both decoding and encoding.
>
> CoreyAshford has updated the pull request with a new target base due to a merge or a rebase. The pull request now
> contains ten commits:
>  - AOT: Revert change to aotCodeHeap.cpp for decodeBlock
>    
>    Don't add the SET_AOT_GLOBAL_SYMBOL_VALUE macro for decode block until all
>    arches that implement AOT, implement the decodeBlock intrinsic.
>  - Base64.java decodeBlock: Changes from PR review
>    
>     * Make comparison safer and consistent with the while loop
>     * Update comment about the decodeBlock intrinsic so that it matches the new structure
>     * Add comment about the lack of a length check on the destination buffer
>     * As per issue 8138732, change HotSpotIntrinsicCandidate to IntrinsicCandidate
>  - stubGenerator_ppc.cpp: Changes from PR review
>    
>     * Fix clearing of upper bits to clear 32 bits instead of 31 (due to misreading of clrldi instruction)
>     * change and document loop_unrolls setting from 8 to 2 after re-running the benchmark
>     * align unrolled loop on a 32-byte boundary
>     * replace instruction used for checking isURL from a double word to single
>       word instruction since the register is effectively 32 bits wide
>     * cosmetic change to realign register comments.
>  - TestBase64.java: Changes from PR review
>    
>     * Use Utils.toByteArrays() method instead of a locally-defined method
>     * Generate the two non-Base64 tables dynamically rather than use static initialization
>     * Added comments describing the two above-mentioned arrays
>  - Expand the Base64 intrinsic regression test to cover decodeBlock
>    
>    This patch makes four significant changes:
>    
>    1) The Power implementation of the decodeBlock intrinsic, at least,
>    requires a decode length of at least 128 bytes, but the existing test cases
>    are much shorter, maxing out at 111 bytes.  So the patch adds a new input
>    data file which has longer test cases in it.
>    
>    2) The original test cases only covers the encoding of just the printable
>    subset of the 7-bit ASCII characters.  However, Base64 encoding requires
>    being able to encode arbitrary binary data, i.e. it must handle all 256
>    8-bit byte encodings.  To remedy this, but keep the original line-oriented
>    style of the input data, I added another input file type that uses a simple
>    ASCII hexadecimal encoding - two ASCII hex characters per 8-bit byte.  When
>    test0 is called, a new parameter is passed that specifies the type of the
>    input file, which is either the original ASCII type or the hexadecimal
>    format.  So to test both longer input data and arbitrary 8-bit data, the
>    newly added input test file has test cases which are both longer and
>    encoded in ASCII hex so as to give full 8-bit capability.  When reading
>    this type of file, test0 calls a newly-added function to translate the
>    ASCII hex to binary data.  Except for the first line of input data, which
>    contains all possible 8-bit values sequentially, the input data was
>    generated using a random length (between 111 and 520 bytes) buffer filled
>    with random 8-bit data, which should give adequate coverage.
>    
>    3) The original test did not test that the decoder detects illegal Base64
>    bytes.  This change chooses a random location in the encoded data to
>    corrupt with a randomly-chosen byte which is illegal for the specific
>    Base64 encoding that is chosen (i.e. standard or URLsafe).  It then calls
>    the decode function to verify that the illegal byte is detected and the
>    proper exception is thrown.
>    
>    4) The test iteration count was originally 100K, but that is far more than
>    enough iterations to test the intrinsic.  It takes 20K iterations on each
>    instrinsic for HotSpot C2 to begin calling it.  The test originally had
>    three types of encodings to test and called the encode intrinsic four times
>    for each iteration, which works out to 100K * 3 * 4 = 1.2M calls just to
>    encode.  Decode was called four times as well (now five because of the
>    illegal byte test).  I believe this is excessive and with the extra test
>    data I have added, the test was timing out after ten minutes of execution.
>    It appears that it is timing out, not because the intrinsics take a long
>    time to run, but because test0 generates an enormous number of discarded
>    data buffers for the GC system to recover (the test runs at about 39GB of
>    virtual memory on my test machine).  To remedy the timeout problem, I have
>    changed the code so that a warmup function of 20K repetitions is performed
>    on a fixed buffer, to activate the instrinsic(s).  After the warmup, I have
>    reduced the number of iterations to 5K on each test0 call.  This should
>    give adequate coverage.
>  - Add JMH benchmark for Base64 variable length buffer decoding
>  - Add Power9+ intrinsic implementation for Base64 decoding
>  - Add HotSpot code to implement Base64 decodeBlock API
>  - Add HotSpotIntrinsicCandidate and API for Base64 decoding

src/hotspot/share/opto/library_call.cpp line 310:

> 308:   bool inline_base64_decodeBlock();
> 309:   bool inline_digestBase_implCompress(vmIntrinsics::ID id);
> 310:   bool inline_sha_implCompress(vmIntrinsics::ID id);

Why is that in this change?

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

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

From rriggs at openjdk.java.net  Wed Oct  7 15:30:07 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 7 Oct 2020 15:30:07 GMT
Subject: RFR: 8254078: DataOutputStream is very slow post-disabling of
 Biased Locking
In-Reply-To: <6jvxOF9XtUANIvKjvwm1ITdmpZc9XKO0xtxDsdcxrdc=.308f5106-cc24-4823-a284-4b3ba7563fc5@github.com>
References: <lLg_yNI_6LvUZTlM4PyN5ra6AaUZZeT35QzYzV_0CpI=.f2d3cb9e-be30-40dc-922c-dad5bef7feea@github.com>
 <EJKoky6UZ4pMtxqQvIQJe7PmczwtTPcKY0wU0nX96aQ=.0bcda955-9e05-4d4a-9fcc-88b49aa7482f@github.com>
 <_FCkRwF2zWuesLEx-i6wMCS2QLqI-u_eL9gL8rw_Dl0=.bfcda732-80e4-4bc8-ab41-d31a7a26e538@github.com>
 <VBOCfFp_FB3lUbo5Hdr_Ax_vOoiFaV8GsEbfcTOSYtw=.a6d0d2c8-8ab0-4d4e-9c37-f9249188e288@github.com>
 <6jvxOF9XtUANIvKjvwm1ITdmpZc9XKO0xtxDsdcxrdc=.308f5106-cc24-4823-a284-4b3ba7563fc5@github.com>
Message-ID: <d6QrBzqY9nhrw2And1H0tXeLuEqfubKjj1a3cf3WU04=.4521e9b5-8bc8-4d3e-909a-423f698dd2f2@github.com>

On Wed, 7 Oct 2020 14:31:45 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> DataOutputStream is a JDK 1.0 era class that doesn't specify whether it is safe for use by multiple threads or not.
>> Some methods are synchronized, some are not. The writeBuffer used by writeLong means it is not thread safe. The
>> writeShort and writeInt methods aren't thread safe so changing them to use the writeBuffer doesn't make things any
>> worse. Other examples are the "bytearr" used by writeUTF, the writeChars and writeBytes methods, and the protected
>> "written" field that sub-classes can use to monitor the number of bytes written.  It might be helpful to add a
>> statement to the DataOutputStream class description to say that it not safe for by concurrent threads and it needs
>> appropriate synchronization to coordinate multiple writers. This issue or another issue doesn't matter.  Can the
>> benchmark be turned into a microbenchmark for test/micro?
>
>> It might be helpful to add a statement to the DataOutputStream class description to say that it not safe for by
>> concurrent threads and it needs appropriate synchronization to coordinate multiple writers. This issue or another issue
>> doesn't matter.
> 
> I see.
> 
>> Can the benchmark be turned into a microbenchmark for test/micro?
> 
> Now there's an interesting question. I can tweak the benchmark (which at present contains a modified version of
> DataOutputSteam, so can compare and contrast) so that it measures only the performance of the core library's
> implementation. Does that make sense? If so, I can add it to this PR.

The benchmark can be run with different JDKs, so the modified DOS can be omitted.

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

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

From github.com+6304496+dreis2211 at openjdk.java.net  Wed Oct  7 15:31:10 2020
From: github.com+6304496+dreis2211 at openjdk.java.net (Christoph Dreis)
Date: Wed, 7 Oct 2020 15:31:10 GMT
Subject: RFR: 8254146: Avoid unnecessary volatile write on new
 AtomicBoolean(false)
In-Reply-To: <P4lM3Rv3CAm7OqpNbLH3mvmgpVv0nVY1TeDw0VFy7jY=.54c361de-0133-4e10-ae04-12c79686e16a@github.com>
References: <AzWKluHZjvFYm2wUanwYfn91iKKMacpk_qSsje3tXWk=.ba873b46-4e12-4415-8832-fa314d6759a3@github.com>
 <yNUBzMyHr1Asbrtyt2sHQnGcJOxdfP8umMyRPC863Rw=.5c18ea25-bcf8-473b-a86a-fe764b8684d6@github.com>
 <P4lM3Rv3CAm7OqpNbLH3mvmgpVv0nVY1TeDw0VFy7jY=.54c361de-0133-4e10-ae04-12c79686e16a@github.com>
Message-ID: <YCAn0HKEP0_EZcQUQLL1Xo3Ghw54zKq8ZGDT_A5daUo=.33924e26-7ef1-4395-95e3-9efa4005ca77@github.com>

On Wed, 7 Oct 2020 14:58:10 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Marked as reviewed by rriggs (Reviewer).
>
>> @AlanBateman What would be the label (or workflow) for that now?
> 
> @dreis2211 what Alan reminded us of here is that all of j.u.concurrent is maintained upstream from the OpenJDK, and
> that this change needs to be coordinated with the maintainers there. Either by getting an OK to go ahead and push this
> as-is, or by contributing this patch to the JSR166 repo directly (which will then be integrated back into the OpenJDK
> at some point). See http://gee.cs.oswego.edu/dl/concurrency-interest/   This isn't anything new since the GitHub
> migration: Various bits and pieces of the OpenJDK sources are maintained upstream, and it's not always easy to igure
> out exactly where or how to go about upstreaming a change.

@cl4es Thanks. My question was more referring to how the PR tooling should be used these days to notify the
maintainers. As JSR166 is a crucial piece of the JDK I was wondering if there might be a way already via a label or
something. Or if this needs some good old mail (to concurrency-interest at cs.oswego.edu I suppose?)

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

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

From asemenyuk at openjdk.java.net  Wed Oct  7 15:34:20 2020
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Wed, 7 Oct 2020 15:34:20 GMT
Subject: RFR: 8253379: [windows] Several jpackage tests failed with error
 code 1638 [v3]
In-Reply-To: <p_OjRcLzDzBVDoQeNkQeS6T2KHzt3CN34Dz8caoxx84=.8d0722fd-0215-4d46-8f0a-b62d48335b01@github.com>
References: <LpRaGB39y6sd9g4cO4JZRPWsYl0oUtSO0l6Smv2xgbo=.992f6c8e-c478-4c3c-bf1e-5f43191336cd@github.com>
 <p_OjRcLzDzBVDoQeNkQeS6T2KHzt3CN34Dz8caoxx84=.8d0722fd-0215-4d46-8f0a-b62d48335b01@github.com>
Message-ID: <F79rScC8BMwwl5LhZwIwf_Iq8QIeyG1jczmJJVWDGtY=.797350b1-6156-4e4b-b589-bde1b0e48d1f@github.com>

On Wed, 7 Oct 2020 15:08:31 GMT, Andy Herrick <herrick at openjdk.org> wrote:

>> 8253379: [windows] Several jpackage tests failed with error code 1638
>> two windows specific test fixes in WindowsHelper:
>> 1.) do not test that the parent directory of a windows menu shortcut is empty after shortcut is uninstalled (there may
>> be other shortcuts using that directory) 2.) do not programmatically install windows exe installers (since we have no
>> way of programmatically uninstalling them)
>
> Andy Herrick has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8253379: [windows] Several jpackage tests failed with error code 1638

Marked as reviewed by asemenyuk (Committer).

test/jdk/tools/jpackage/helpers/jdk/jpackage/test/WindowsHelper.java line 211:

> 209:             if (!exists) {
> 210:                 TKit.assertPathExists(shortcutPath.getParent(), false);
> 211:             }

How this is related to disabling of running exe installers?

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

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

From lancea at openjdk.java.net  Wed Oct  7 15:37:06 2020
From: lancea at openjdk.java.net (Lance Andersen)
Date: Wed, 7 Oct 2020 15:37:06 GMT
Subject: RFR: 8253952: Work around wrong usage of
 ZipOutputStream.putNextEntry() in user code
In-Reply-To: <c12QhQcAA4YctkyHYdULM9mSQ6KI9iqZM5MAuLJroGE=.a84fc8f5-411c-4ec0-b421-c3cf62c849c7@github.com>
References: <0nq5oFKOj6AZqCW6jF268-6oKRI6UkS6TRIHo-_5vKw=.d13c7016-4473-4b20-9117-100b368d3716@github.com>
 <c12QhQcAA4YctkyHYdULM9mSQ6KI9iqZM5MAuLJroGE=.a84fc8f5-411c-4ec0-b421-c3cf62c849c7@github.com>
Message-ID: <sCZNDJVA17V3tGPsCYV88AODMtfrhTfLlii5q0Qz4u8=.531888c3-19a9-4572-acda-81183a81e08f@github.com>

On Wed, 7 Oct 2020 15:10:06 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> ### Summary
>> 
>> Work around wrong usage of `ZipOutputStream.putNextEntry()` in user code which can lead to the `ZipException "invalid
>> entry compressed size"`.
>> ### Motivation
>> 
>> In general it is not safe to directly write a ZipEntry obtained from `ZipInputStream.getNextEntry()`,
>> `ZipFile.entries()`, `ZipFile.getEntry()` or `ZipFile.stream()` with `ZipOutputStream.putNextEntry()` to a
>> `ZipOutputStream` and then read the entries data from the `ZipInputStream` and write it to the `ZipOutputStream` as
>> follows:
>>  ZipEntry entry;
>>  ZipInputStream zis = new ZipInputStream(...);
>>  ZipOutputStream zos = new ZipOutputStream(...);
>>  while((entry = zis.getNextEntry()) != null) {
>>      zos.putNextEntry(entry);
>>      zis.transferTo(zos);
>>  }
>> The problem with this code is that the zip file format does not record the compression level used for deflation in its
>> entries. In general, it doesn't even mandate a predefined compression ratio per compression level. Therefore the
>> compressed size recorded in a `ZipEntry` read from a zip file might differ from the new compressed size produced by the
>> receiving `ZipOutputStream`. Such a difference will result in a `ZipException` with the following message:
>>  java.util.zip.ZipException: invalid entry compressed size (expected 12 but got 7 bytes)
>>  
>> The correct way of copying all entries from one zip file into another requires the creation of a new `ZipEntry` or at
>> least resetting of the compressed size field. E.g.:
>>  while((entry = zis.getNextEntry()) != null) {
>>      ZipEntry newEntry = new ZipEntry(entry.getName());
>>      zos.putNextEntry(newEntry);
>>      zis.transferTo(zos);
>>  }
>> or:
>>  while((entry = zis.getNextEntry()) != null) {
>>      entry.setCompressedSize(-1);
>>      zos.putNextEntry(entry);
>>      zis.transferTo(zos);
>>  }
>> Unfortunately, there's a lot of user code out there which gets this wrong and uses the bad coding pattern described
>> before. Searching for `"java.util.zip.ZipException: invalid entry compressed size (expected 12 but got 7 bytes)"` gives
>> ~2500 hits (~100 on StackOverflow). It's also no hard to find plenty of instances of this anti-pattern on GitHub when
>> doing a code search for `ZipEntry` and `putNextEntry()`. E.g. [Gradle 4.x wrapper task][1] is affected as well as the
>> latest version of the [mockableAndroidJar task][2]. I've recently fixed two occurrences of this pattern in OpenJDK (see
>> [JDK-8240333][3] and [JDK-8240235][4]) but there still exist more of them (e.g.
>> [`test/jdk/java/util/zip/ZipFile/CopyJar.java`][5] which is there since 1999 :).  ### Description  So while this has
>> clearly been a problem before, it apparently wasn't painful enough to trigger any action from the side of the JDK.
>> However, recently quite some zlib forks with [superior deflate/inflate performance have evolved][6]. Using them with
>> OpenJDK is quite straight-forward: one just has to configure the alternative implementations by setting
>> `LD_LIBRARY_PATH` or `LD_PRELOAD` correspondingly. We've seen big saving by using these new zlib implementations for
>> selected services in production and the only reason why we haven't enabled them by default until now is the problem
>> I've just described. The reason why these new libraries uncover the described anti-pattern much more often is because
>> their compression ratio is slightly different from that of the default zlib library. This can easily trigger a
>> `ZipException` even if an application is not using a different compression levels but just a zip file created with
>> another zlib version.  I'd therefore like to propose the following workaround for the wrong
>> `ZipOutputStream.putNextEntry()` usage in user code:
>> -  ignore the compressed size if it was implicitly determined from the zip file and not explicitly set by calling
>>    `ZipEntry.setCompressedSize()`.
>> 
>> - Change the API-documentation of `ZipOutputStream.putNextEntry()` and `JarOutputStream.putNextEntry()` to explain the
>>   problem and why `putNextEntry()` will ignore the compressed size of a `ZipEntry` if that was set implicitely when
>>   reading that entry from a `ZipFile` or `ZipInputStream`.
>> 
>> 
>> ### Technical Details
>> 
>> A zip file consists of a stream of File Entries followed by a Central Directory (see [here for a more detailed
>> specification][7]). Each File Entry is composed of a Local File Header (LFH) followed by the compressed Data and an
>> optional Data Descriptor. The LFH contains the File Name and among other attributes the Compressed and Uncompressed
>> size and CRC of the Data. In the case where the latter three attributes are not available at the time when the LFH is
>> created, this fact will be recorded in a flag of the LFH and will trigger the creation of a Data Descriptor with the
>> corresponding information right after the Data section. Finally, the Central Directory contains one Central Directory
>> File Header (CDFH) for each entry of the  zip archive. The CDFH is an extended version of the LFH and the ultimate
>> reference for the contents of the zip archive. The redundancy between LFH and CDFH is a tribute to zip's long history
>> when it was used to store archives on multiple floppy discs and the CDFH allowed to update the archive by only writing
>> to the last disc which contained the Central Directory.  `ZipEntries` read with `ZipInputStream.getNextEntry()` will
>> initially only contain the information from the LFH. Only after the next entry was read (or after
>> `ZipInputStream.closeEntry()` was called explicitly), will the previously read entry be updated with the data from the
>> Data Descriptor. `ZipInputStream` doesn't inspect the Central Directory at all.  On the other hand, `ZipFile` only
>> queries the Central Directory for `ZipEntry` information so all `ZipEntries` returned by `ZipFile.entries()`,
>> `ZipFile.getEntry()` and `ZipFile.stream()` will always instantly contain the full Compressed and Uncompressed Size and
>> CRC information for each entry independently of the LFH contents.  ### Risks and Assumptions  If we choose to ignore
>> the implicitly recorded compressed size in a `ZipEntry` read from a zip file when writing it to a `ZipOutputStream`,
>> this will lead to zip files with incomplete information in the LFH and an additional Data Descriptor as described
>> before. However, the result is still fully compatible to the zip file specification. It's also not unusual, because by
>> default all new zip files created with `ZipOutputStream` will contain LFHs without Compressed and Uncompressed Size and
>> CRC information and an additional Data Descriptor. Theoretically it is possible to create new zip files with
>> `ZipOutputStream` class and Compressed and Uncompressed Size and CRC information in the LFH but that's complex and
>> inefficient because it requires two steps. A first step to determine the crc and compressed size of the data and a
>> second step to actually write the data to the `ZipOutputStream` (which will compress it a second time). This is because
>> the current API offers no possibility to write already compressed data to a `ZipOutputStream`.  Consequently, the only
>> straight-forward way of creating zip files from Java which have all the data in the LFH and no Data Descriptor is by
>> copying `ZipEntries` from an existing zip file with the buggy method described before. This incidentally worked more or
>> less reliable for a long time but breaks miserably when using different zlib implementations. Ignoring the implicitly
>> set compressed size of `ZipEntries` can easily fix this problem.  I'm not aware of any tool which can not handle such
>> files and if it exists it would have problems with the majority of Java created zip files anyway (e.g. all jar-files
>> created with the jar tool have zip entries with incomplete LFH data and additional Data Descriptor).  Ignoring the
>> implicitly set compressed size of `ZipEntries` has no measurable performance impact and will increase the size of zip
>> archives which used to have the complete file information in the LFH before by 16 bytes per entry. On the other hand it
>> will give us the freedom to use whatever zip implementation we like :)   [1]:
>> https://github.com/gradle/gradle/blob/e76905e3a/subprojects/build-init/src/main/java/org/gradle/api/tasks/wrapper/Wrapper.java#L152-L158
>> [2]:
>> https://android.googlesource.com/platform/tools/base/+/refs/heads/master/build-system/builder/src/main/java/com/android/builder/testing/MockableJarGenerator.java#86
>> [3]: https://bugs.openjdk.java.net/browse/JDK-8240333 [4]: https://bugs.openjdk.java.net/browse/JDK-8240235 [5]:
>> https://github.com/openjdk/jdk/blob/master/test/jdk/java/util/zip/ZipFile/CopyJar.java [6]:
>> https://github.com/simonis/zlib-bench/blob/master/Results.md [7]: https://en.wikipedia.org/wiki/Zip_(file_format)
>
> src/java.base/share/classes/java/util/jar/JarOutputStream.java line 97:
> 
>> 95:      * and re-compute its value automatically after the associted data has been
>> 96:      * completely deflated.
>> 97:      *
> 
> We probably need to do a bit wordsmithing here.
> 
> I think I'd drop the first two sentences and instead start a new paragraph here (<p> tag) with "Unless explicitly set,
> the output stream will ignore ..." and see how that looks.
> Probably should be "the ZipEntry" rather than "a ZipEntry" to be consistent with the parameter description.

Alan makes a good point.  Perhaps we keep things simple and focus solely on tweaking the description of the change in
behavior which is described in your last paragraph

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

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

From mdoerr at openjdk.java.net  Wed Oct  7 15:40:15 2020
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Wed, 7 Oct 2020 15:40:15 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v2]
In-Reply-To: <6P-wrlA7c9wlXEhcoAYW5J9W2jwTmTTj3PkDObPh0LA=.c11aa048-8853-4e1c-a689-c34b89c15f12@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <6P-wrlA7c9wlXEhcoAYW5J9W2jwTmTTj3PkDObPh0LA=.c11aa048-8853-4e1c-a689-c34b89c15f12@github.com>
Message-ID: <sfzgalP37HPAIbzdPSKpTRRmIBcz2NGIgiSKT3fB2BQ=.f1bd5064-b5bd-4684-b4ab-c1131fe96793@github.com>

On Mon, 5 Oct 2020 18:29:58 GMT, CoreyAshford <github.com+51754783+CoreyAshford at openjdk.org> wrote:

>> This patch set encompasses the following commits:
>> 
>> - Adds a new HotSpot intrinsic candidate to the java.lang.Base64 class - decodeBlock(), and provides a flexible API for
>>   the intrinsic.  The API is similar to the existing encodeBlock intrinsic.
>> - Adds the code in HotSpot to check and martial the new intrinsic's arguments to the arch-specific intrinsic
>>   implementation
>> - Adds a Power64LE-specific implementation of the decodeBlock intrinsic.
>> - Adds a JMH microbenchmark for both Base64 encoding and encoding.
>> - Enhances the JTReg hotspot intrinsic "TestBase64.java" regression test to more fully test both decoding and encoding.
>
> CoreyAshford has updated the pull request with a new target base due to a merge or a rebase. The pull request now
> contains ten commits:
>  - AOT: Revert change to aotCodeHeap.cpp for decodeBlock
>    
>    Don't add the SET_AOT_GLOBAL_SYMBOL_VALUE macro for decode block until all
>    arches that implement AOT, implement the decodeBlock intrinsic.
>  - Base64.java decodeBlock: Changes from PR review
>    
>     * Make comparison safer and consistent with the while loop
>     * Update comment about the decodeBlock intrinsic so that it matches the new structure
>     * Add comment about the lack of a length check on the destination buffer
>     * As per issue 8138732, change HotSpotIntrinsicCandidate to IntrinsicCandidate
>  - stubGenerator_ppc.cpp: Changes from PR review
>    
>     * Fix clearing of upper bits to clear 32 bits instead of 31 (due to misreading of clrldi instruction)
>     * change and document loop_unrolls setting from 8 to 2 after re-running the benchmark
>     * align unrolled loop on a 32-byte boundary
>     * replace instruction used for checking isURL from a double word to single
>       word instruction since the register is effectively 32 bits wide
>     * cosmetic change to realign register comments.
>  - TestBase64.java: Changes from PR review
>    
>     * Use Utils.toByteArrays() method instead of a locally-defined method
>     * Generate the two non-Base64 tables dynamically rather than use static initialization
>     * Added comments describing the two above-mentioned arrays
>  - Expand the Base64 intrinsic regression test to cover decodeBlock
>    
>    This patch makes four significant changes:
>    
>    1) The Power implementation of the decodeBlock intrinsic, at least,
>    requires a decode length of at least 128 bytes, but the existing test cases
>    are much shorter, maxing out at 111 bytes.  So the patch adds a new input
>    data file which has longer test cases in it.
>    
>    2) The original test cases only covers the encoding of just the printable
>    subset of the 7-bit ASCII characters.  However, Base64 encoding requires
>    being able to encode arbitrary binary data, i.e. it must handle all 256
>    8-bit byte encodings.  To remedy this, but keep the original line-oriented
>    style of the input data, I added another input file type that uses a simple
>    ASCII hexadecimal encoding - two ASCII hex characters per 8-bit byte.  When
>    test0 is called, a new parameter is passed that specifies the type of the
>    input file, which is either the original ASCII type or the hexadecimal
>    format.  So to test both longer input data and arbitrary 8-bit data, the
>    newly added input test file has test cases which are both longer and
>    encoded in ASCII hex so as to give full 8-bit capability.  When reading
>    this type of file, test0 calls a newly-added function to translate the
>    ASCII hex to binary data.  Except for the first line of input data, which
>    contains all possible 8-bit values sequentially, the input data was
>    generated using a random length (between 111 and 520 bytes) buffer filled
>    with random 8-bit data, which should give adequate coverage.
>    
>    3) The original test did not test that the decoder detects illegal Base64
>    bytes.  This change chooses a random location in the encoded data to
>    corrupt with a randomly-chosen byte which is illegal for the specific
>    Base64 encoding that is chosen (i.e. standard or URLsafe).  It then calls
>    the decode function to verify that the illegal byte is detected and the
>    proper exception is thrown.
>    
>    4) The test iteration count was originally 100K, but that is far more than
>    enough iterations to test the intrinsic.  It takes 20K iterations on each
>    instrinsic for HotSpot C2 to begin calling it.  The test originally had
>    three types of encodings to test and called the encode intrinsic four times
>    for each iteration, which works out to 100K * 3 * 4 = 1.2M calls just to
>    encode.  Decode was called four times as well (now five because of the
>    illegal byte test).  I believe this is excessive and with the extra test
>    data I have added, the test was timing out after ten minutes of execution.
>    It appears that it is timing out, not because the intrinsics take a long
>    time to run, but because test0 generates an enormous number of discarded
>    data buffers for the GC system to recover (the test runs at about 39GB of
>    virtual memory on my test machine).  To remedy the timeout problem, I have
>    changed the code so that a warmup function of 20K repetitions is performed
>    on a fixed buffer, to activate the instrinsic(s).  After the warmup, I have
>    reduced the number of iterations to 5K on each test0 call.  This should
>    give adequate coverage.
>  - Add JMH benchmark for Base64 variable length buffer decoding
>  - Add Power9+ intrinsic implementation for Base64 decoding
>  - Add HotSpot code to implement Base64 decodeBlock API
>  - Add HotSpotIntrinsicCandidate and API for Base64 decoding

src/hotspot/share/opto/runtime.cpp line 1211:

> 1209:   // result type needed
> 1210:   fields = TypeTuple::fields(1);
> 1211:   fields[TypeFunc::Parms + 0] = TypeInt::INT; // dst ofs, or -1

Why "- or -1" in the comment?

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

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

From mdoerr at openjdk.java.net  Wed Oct  7 15:52:11 2020
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Wed, 7 Oct 2020 15:52:11 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v2]
In-Reply-To: <6P-wrlA7c9wlXEhcoAYW5J9W2jwTmTTj3PkDObPh0LA=.c11aa048-8853-4e1c-a689-c34b89c15f12@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <6P-wrlA7c9wlXEhcoAYW5J9W2jwTmTTj3PkDObPh0LA=.c11aa048-8853-4e1c-a689-c34b89c15f12@github.com>
Message-ID: <kTmpe-MW1ZakMcKsESnDEQoImN7wNvbMne6Z9MuIbGE=.e0546e01-0951-477f-a67c-8443fcf2997d@github.com>

On Mon, 5 Oct 2020 18:29:58 GMT, CoreyAshford <github.com+51754783+CoreyAshford at openjdk.org> wrote:

>> This patch set encompasses the following commits:
>> 
>> - Adds a new HotSpot intrinsic candidate to the java.lang.Base64 class - decodeBlock(), and provides a flexible API for
>>   the intrinsic.  The API is similar to the existing encodeBlock intrinsic.
>> - Adds the code in HotSpot to check and martial the new intrinsic's arguments to the arch-specific intrinsic
>>   implementation
>> - Adds a Power64LE-specific implementation of the decodeBlock intrinsic.
>> - Adds a JMH microbenchmark for both Base64 encoding and encoding.
>> - Enhances the JTReg hotspot intrinsic "TestBase64.java" regression test to more fully test both decoding and encoding.
>
> CoreyAshford has updated the pull request with a new target base due to a merge or a rebase. The pull request now
> contains ten commits:
>  - AOT: Revert change to aotCodeHeap.cpp for decodeBlock
>    
>    Don't add the SET_AOT_GLOBAL_SYMBOL_VALUE macro for decode block until all
>    arches that implement AOT, implement the decodeBlock intrinsic.
>  - Base64.java decodeBlock: Changes from PR review
>    
>     * Make comparison safer and consistent with the while loop
>     * Update comment about the decodeBlock intrinsic so that it matches the new structure
>     * Add comment about the lack of a length check on the destination buffer
>     * As per issue 8138732, change HotSpotIntrinsicCandidate to IntrinsicCandidate
>  - stubGenerator_ppc.cpp: Changes from PR review
>    
>     * Fix clearing of upper bits to clear 32 bits instead of 31 (due to misreading of clrldi instruction)
>     * change and document loop_unrolls setting from 8 to 2 after re-running the benchmark
>     * align unrolled loop on a 32-byte boundary
>     * replace instruction used for checking isURL from a double word to single
>       word instruction since the register is effectively 32 bits wide
>     * cosmetic change to realign register comments.
>  - TestBase64.java: Changes from PR review
>    
>     * Use Utils.toByteArrays() method instead of a locally-defined method
>     * Generate the two non-Base64 tables dynamically rather than use static initialization
>     * Added comments describing the two above-mentioned arrays
>  - Expand the Base64 intrinsic regression test to cover decodeBlock
>    
>    This patch makes four significant changes:
>    
>    1) The Power implementation of the decodeBlock intrinsic, at least,
>    requires a decode length of at least 128 bytes, but the existing test cases
>    are much shorter, maxing out at 111 bytes.  So the patch adds a new input
>    data file which has longer test cases in it.
>    
>    2) The original test cases only covers the encoding of just the printable
>    subset of the 7-bit ASCII characters.  However, Base64 encoding requires
>    being able to encode arbitrary binary data, i.e. it must handle all 256
>    8-bit byte encodings.  To remedy this, but keep the original line-oriented
>    style of the input data, I added another input file type that uses a simple
>    ASCII hexadecimal encoding - two ASCII hex characters per 8-bit byte.  When
>    test0 is called, a new parameter is passed that specifies the type of the
>    input file, which is either the original ASCII type or the hexadecimal
>    format.  So to test both longer input data and arbitrary 8-bit data, the
>    newly added input test file has test cases which are both longer and
>    encoded in ASCII hex so as to give full 8-bit capability.  When reading
>    this type of file, test0 calls a newly-added function to translate the
>    ASCII hex to binary data.  Except for the first line of input data, which
>    contains all possible 8-bit values sequentially, the input data was
>    generated using a random length (between 111 and 520 bytes) buffer filled
>    with random 8-bit data, which should give adequate coverage.
>    
>    3) The original test did not test that the decoder detects illegal Base64
>    bytes.  This change chooses a random location in the encoded data to
>    corrupt with a randomly-chosen byte which is illegal for the specific
>    Base64 encoding that is chosen (i.e. standard or URLsafe).  It then calls
>    the decode function to verify that the illegal byte is detected and the
>    proper exception is thrown.
>    
>    4) The test iteration count was originally 100K, but that is far more than
>    enough iterations to test the intrinsic.  It takes 20K iterations on each
>    instrinsic for HotSpot C2 to begin calling it.  The test originally had
>    three types of encodings to test and called the encode intrinsic four times
>    for each iteration, which works out to 100K * 3 * 4 = 1.2M calls just to
>    encode.  Decode was called four times as well (now five because of the
>    illegal byte test).  I believe this is excessive and with the extra test
>    data I have added, the test was timing out after ten minutes of execution.
>    It appears that it is timing out, not because the intrinsics take a long
>    time to run, but because test0 generates an enormous number of discarded
>    data buffers for the GC system to recover (the test runs at about 39GB of
>    virtual memory on my test machine).  To remedy the timeout problem, I have
>    changed the code so that a warmup function of 20K repetitions is performed
>    on a fixed buffer, to activate the instrinsic(s).  After the warmup, I have
>    reduced the number of iterations to 5K on each test0 call.  This should
>    give adequate coverage.
>  - Add JMH benchmark for Base64 variable length buffer decoding
>  - Add Power9+ intrinsic implementation for Base64 decoding
>  - Add HotSpot code to implement Base64 decodeBlock API
>  - Add HotSpotIntrinsicCandidate and API for Base64 decoding

test/hotspot/jtreg/compiler/intrinsics/base64/TestBase64.java line 89:

> 87:         ran.nextBytes(srcBuf);
> 88:
> 89:         // This should be enough to get both the decoder and encoder intrinsic loaded up and running.

Better: ... get encode() and decode() compiled on highest tier.

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

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

From rriggs at openjdk.java.net  Wed Oct  7 16:01:28 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 7 Oct 2020 16:01:28 GMT
Subject: RFR: 8253876: jdk/test/lib/hexdump/ASN1FormatterTest.java fails
 with "AssertionError: Lines expected [126] but found [202]" [v2]
In-Reply-To: <ASCOaOEaKxCTMEzRTADTMkIxJZ3y5fTD1D2bC_Zyi7k=.de0aea66-338c-46be-9fa5-89a52dd4b119@github.com>
References: <ASCOaOEaKxCTMEzRTADTMkIxJZ3y5fTD1D2bC_Zyi7k=.de0aea66-338c-46be-9fa5-89a52dd4b119@github.com>
Message-ID: <9FI5Qa5-j0z6qoDI81bunEoDLFpLSeVc9lHrFC89bPQ=.0eda735a-85de-48a5-a8b9-e4eb95315df2@github.com>

> The HexPrinter test utility should be ignoring \r characters from the formatter.
> It looks for \n and generates System.lineSeparator() at the end of each line.
> 
> With this fix, the ASN1FormatterTest can be removed from the ProblemList.

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

  Use System.lineSeparator for line endings

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/486/files
  - new: https://git.openjdk.java.net/jdk/pull/486/files/7b6ae596..6f1f564d

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

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

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

From shade at openjdk.java.net  Wed Oct  7 16:06:09 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 7 Oct 2020 16:06:09 GMT
Subject: RFR: 8253876: jdk/test/lib/hexdump/ASN1FormatterTest.java fails
 with "AssertionError: Lines expected [126] but found [202]" [v2]
In-Reply-To: <9FI5Qa5-j0z6qoDI81bunEoDLFpLSeVc9lHrFC89bPQ=.0eda735a-85de-48a5-a8b9-e4eb95315df2@github.com>
References: <ASCOaOEaKxCTMEzRTADTMkIxJZ3y5fTD1D2bC_Zyi7k=.de0aea66-338c-46be-9fa5-89a52dd4b119@github.com>
 <9FI5Qa5-j0z6qoDI81bunEoDLFpLSeVc9lHrFC89bPQ=.0eda735a-85de-48a5-a8b9-e4eb95315df2@github.com>
Message-ID: <kHw77mC-hc3d7hnb2uyAtkZakNwkn_3MS8VUbR1mcZY=.7ff409da-e713-44a2-9761-3d22ae41b3b0@github.com>

On Wed, 7 Oct 2020 16:01:28 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> The HexPrinter test utility should be ignoring \r characters from the formatter.
>> It looks for \n and generates System.lineSeparator() at the end of each line.
>> 
>> With this fix, the ASN1FormatterTest can be removed from the ProblemList.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use System.lineSeparator for line endings

This looks significantly better, thanks!

test/lib/jdk/test/lib/hexdump/ASN1Formatter.java line 169:

> 167:                 if (nbytes > 4) {
> 168:                     out.append("***** Tag: " + tagName(tag) +
> 169:                             ", Range of length error: " + len + " bytes");

I think you can break this line into `append`-s, while we are at it. But your choice.

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

Marked as reviewed by shade (Reviewer).

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

From volker.simonis at gmail.com  Wed Oct  7 16:09:08 2020
From: volker.simonis at gmail.com (Volker Simonis)
Date: Wed, 7 Oct 2020 18:09:08 +0200
Subject: Request for Discussion: 8253952: Work around wrong usage of
 ZipOutputStream.putNextEntry() in user code
In-Reply-To: <809e78ae-0060-f9b8-531d-d4c5cc3c70b7@oracle.com>
References: <CA+3eh12_-fNxf_KFK68WEqVoD_n6CD7RCbe=LoKCyCeUQ3w0oQ@mail.gmail.com>
 <4658d3a6-3360-fb84-e5ff-20dc6cc61b92@oracle.com>
 <CA+3eh10vr3vs92UPu7PwiaofZpf46QuzsuFf4bvf26gbYKF3-g@mail.gmail.com>
 <99e80b7e-7702-338d-cd92-c9d1a396dfa5@oracle.com>
 <CA+3eh11g+Pj9pVVLYGF3afgmtDx5qdS3m8D5KGwKWfP8VXO1aQ@mail.gmail.com>
 <809e78ae-0060-f9b8-531d-d4c5cc3c70b7@oracle.com>
Message-ID: <CA+3eh12z+U4fePNZuDTKZ+2Yo886vobu6tzoZ5ACnmC3fzZzag@mail.gmail.com>

On Wed, Oct 7, 2020 at 5:12 PM Alan Bateman <Alan.Bateman at oracle.com> wrote:
>
> On 06/10/2020 15:44, Volker Simonis wrote:
> > :
> > Sorry, maybe I'm missing something, but I can't find a single
> > reference to neither ZipOutput- nor ZipInputStream in the ZipEntry
> > class.
> >
> I should have been clearer. If the method is on ZOS then you have the
> receiver and the ZipEntry parameter. If you are exploring methods on
> ZipEntry then you have the receiver and the ZOS parameter.
>

That's true, but the problem is that there'S no reference to the
source zip file or stream. As I wrote previously (copied here for your
convenience):

If you mean that  ZipEntry.transferTo() will be intended to copy a
ZipEntry together with the associated, compressed data that will be
much harder if not impossible to implement with the current API. The
first problem is that ZipEntry has no reference to its associated
ZipFile or ZipInputStream. The much bigger problem is that
ZipInputSream is a "streaming" API. We might read from a zip file
which doesn't have the compressed size information in the LFH. In such
a case, it would be impossible to read the compressed data from the
stream because we don't know its length. We can only start to inflate
the data until inflation stops. Only at that point we know the
compressed size of the entry. But at that point we can't access the
compressed data any more because we can't reset the stream.

> -Alan

From lancea at openjdk.java.net  Wed Oct  7 16:12:12 2020
From: lancea at openjdk.java.net (Lance Andersen)
Date: Wed, 7 Oct 2020 16:12:12 GMT
Subject: RFR: 8253952: Work around wrong usage of
 ZipOutputStream.putNextEntry() in user code
In-Reply-To: <0nq5oFKOj6AZqCW6jF268-6oKRI6UkS6TRIHo-_5vKw=.d13c7016-4473-4b20-9117-100b368d3716@github.com>
References: <0nq5oFKOj6AZqCW6jF268-6oKRI6UkS6TRIHo-_5vKw=.d13c7016-4473-4b20-9117-100b368d3716@github.com>
Message-ID: <uOv0IEZBeC6bdvSTaZ2VHF6ApqwpwWGuTsKznkhzFu0=.9ad91b5b-74ce-4702-ba77-55bf6ab67189@github.com>

On Tue, 6 Oct 2020 10:02:09 GMT, Volker Simonis <simonis at openjdk.org> wrote:

> ### Summary
> 
> Work around wrong usage of `ZipOutputStream.putNextEntry()` in user code which can lead to the `ZipException "invalid
> entry compressed size"`.
> ### Motivation
> 
> In general it is not safe to directly write a ZipEntry obtained from `ZipInputStream.getNextEntry()`,
> `ZipFile.entries()`, `ZipFile.getEntry()` or `ZipFile.stream()` with `ZipOutputStream.putNextEntry()` to a
> `ZipOutputStream` and then read the entries data from the `ZipInputStream` and write it to the `ZipOutputStream` as
> follows:
>  ZipEntry entry;
>  ZipInputStream zis = new ZipInputStream(...);
>  ZipOutputStream zos = new ZipOutputStream(...);
>  while((entry = zis.getNextEntry()) != null) {
>      zos.putNextEntry(entry);
>      zis.transferTo(zos);
>  }
> The problem with this code is that the zip file format does not record the compression level used for deflation in its
> entries. In general, it doesn't even mandate a predefined compression ratio per compression level. Therefore the
> compressed size recorded in a `ZipEntry` read from a zip file might differ from the new compressed size produced by the
> receiving `ZipOutputStream`. Such a difference will result in a `ZipException` with the following message:
>  java.util.zip.ZipException: invalid entry compressed size (expected 12 but got 7 bytes)
>  
> The correct way of copying all entries from one zip file into another requires the creation of a new `ZipEntry` or at
> least resetting of the compressed size field. E.g.:
>  while((entry = zis.getNextEntry()) != null) {
>      ZipEntry newEntry = new ZipEntry(entry.getName());
>      zos.putNextEntry(newEntry);
>      zis.transferTo(zos);
>  }
> or:
>  while((entry = zis.getNextEntry()) != null) {
>      entry.setCompressedSize(-1);
>      zos.putNextEntry(entry);
>      zis.transferTo(zos);
>  }
> Unfortunately, there's a lot of user code out there which gets this wrong and uses the bad coding pattern described
> before. Searching for `"java.util.zip.ZipException: invalid entry compressed size (expected 12 but got 7 bytes)"` gives
> ~2500 hits (~100 on StackOverflow). It's also no hard to find plenty of instances of this anti-pattern on GitHub when
> doing a code search for `ZipEntry` and `putNextEntry()`. E.g. [Gradle 4.x wrapper task][1] is affected as well as the
> latest version of the [mockableAndroidJar task][2]. I've recently fixed two occurrences of this pattern in OpenJDK (see
> [JDK-8240333][3] and [JDK-8240235][4]) but there still exist more of them (e.g.
> [`test/jdk/java/util/zip/ZipFile/CopyJar.java`][5] which is there since 1999 :).  ### Description  So while this has
> clearly been a problem before, it apparently wasn't painful enough to trigger any action from the side of the JDK.
> However, recently quite some zlib forks with [superior deflate/inflate performance have evolved][6]. Using them with
> OpenJDK is quite straight-forward: one just has to configure the alternative implementations by setting
> `LD_LIBRARY_PATH` or `LD_PRELOAD` correspondingly. We've seen big saving by using these new zlib implementations for
> selected services in production and the only reason why we haven't enabled them by default until now is the problem
> I've just described. The reason why these new libraries uncover the described anti-pattern much more often is because
> their compression ratio is slightly different from that of the default zlib library. This can easily trigger a
> `ZipException` even if an application is not using a different compression levels but just a zip file created with
> another zlib version.  I'd therefore like to propose the following workaround for the wrong
> `ZipOutputStream.putNextEntry()` usage in user code:
> -  ignore the compressed size if it was implicitly determined from the zip file and not explicitly set by calling
>    `ZipEntry.setCompressedSize()`.
> 
> - Change the API-documentation of `ZipOutputStream.putNextEntry()` and `JarOutputStream.putNextEntry()` to explain the
>   problem and why `putNextEntry()` will ignore the compressed size of a `ZipEntry` if that was set implicitely when
>   reading that entry from a `ZipFile` or `ZipInputStream`.
> 
> 
> ### Technical Details
> 
> A zip file consists of a stream of File Entries followed by a Central Directory (see [here for a more detailed
> specification][7]). Each File Entry is composed of a Local File Header (LFH) followed by the compressed Data and an
> optional Data Descriptor. The LFH contains the File Name and among other attributes the Compressed and Uncompressed
> size and CRC of the Data. In the case where the latter three attributes are not available at the time when the LFH is
> created, this fact will be recorded in a flag of the LFH and will trigger the creation of a Data Descriptor with the
> corresponding information right after the Data section. Finally, the Central Directory contains one Central Directory
> File Header (CDFH) for each entry of the  zip archive. The CDFH is an extended version of the LFH and the ultimate
> reference for the contents of the zip archive. The redundancy between LFH and CDFH is a tribute to zip's long history
> when it was used to store archives on multiple floppy discs and the CDFH allowed to update the archive by only writing
> to the last disc which contained the Central Directory.  `ZipEntries` read with `ZipInputStream.getNextEntry()` will
> initially only contain the information from the LFH. Only after the next entry was read (or after
> `ZipInputStream.closeEntry()` was called explicitly), will the previously read entry be updated with the data from the
> Data Descriptor. `ZipInputStream` doesn't inspect the Central Directory at all.  On the other hand, `ZipFile` only
> queries the Central Directory for `ZipEntry` information so all `ZipEntries` returned by `ZipFile.entries()`,
> `ZipFile.getEntry()` and `ZipFile.stream()` will always instantly contain the full Compressed and Uncompressed Size and
> CRC information for each entry independently of the LFH contents.  ### Risks and Assumptions  If we choose to ignore
> the implicitly recorded compressed size in a `ZipEntry` read from a zip file when writing it to a `ZipOutputStream`,
> this will lead to zip files with incomplete information in the LFH and an additional Data Descriptor as described
> before. However, the result is still fully compatible to the zip file specification. It's also not unusual, because by
> default all new zip files created with `ZipOutputStream` will contain LFHs without Compressed and Uncompressed Size and
> CRC information and an additional Data Descriptor. Theoretically it is possible to create new zip files with
> `ZipOutputStream` class and Compressed and Uncompressed Size and CRC information in the LFH but that's complex and
> inefficient because it requires two steps. A first step to determine the crc and compressed size of the data and a
> second step to actually write the data to the `ZipOutputStream` (which will compress it a second time). This is because
> the current API offers no possibility to write already compressed data to a `ZipOutputStream`.  Consequently, the only
> straight-forward way of creating zip files from Java which have all the data in the LFH and no Data Descriptor is by
> copying `ZipEntries` from an existing zip file with the buggy method described before. This incidentally worked more or
> less reliable for a long time but breaks miserably when using different zlib implementations. Ignoring the implicitly
> set compressed size of `ZipEntries` can easily fix this problem.  I'm not aware of any tool which can not handle such
> files and if it exists it would have problems with the majority of Java created zip files anyway (e.g. all jar-files
> created with the jar tool have zip entries with incomplete LFH data and additional Data Descriptor).  Ignoring the
> implicitly set compressed size of `ZipEntries` has no measurable performance impact and will increase the size of zip
> archives which used to have the complete file information in the LFH before by 16 bytes per entry. On the other hand it
> will give us the freedom to use whatever zip implementation we like :)   [1]:
> https://github.com/gradle/gradle/blob/e76905e3a/subprojects/build-init/src/main/java/org/gradle/api/tasks/wrapper/Wrapper.java#L152-L158
> [2]:
> https://android.googlesource.com/platform/tools/base/+/refs/heads/master/build-system/builder/src/main/java/com/android/builder/testing/MockableJarGenerator.java#86
> [3]: https://bugs.openjdk.java.net/browse/JDK-8240333 [4]: https://bugs.openjdk.java.net/browse/JDK-8240235 [5]:
> https://github.com/openjdk/jdk/blob/master/test/jdk/java/util/zip/ZipFile/CopyJar.java [6]:
> https://github.com/simonis/zlib-bench/blob/master/Results.md [7]: https://en.wikipedia.org/wiki/Zip_(file_format)

I think as we start to move forward with the review and CSR, we should update the bug and PR description as the change
is not a workaround but a change in behavior of the implementation

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

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

From rriggs at openjdk.java.net  Wed Oct  7 16:25:27 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 7 Oct 2020 16:25:27 GMT
Subject: RFR: 8253876: jdk/test/lib/hexdump/ASN1FormatterTest.java fails
 with "AssertionError: Lines expected [126] but found [202]" [v3]
In-Reply-To: <ASCOaOEaKxCTMEzRTADTMkIxJZ3y5fTD1D2bC_Zyi7k=.de0aea66-338c-46be-9fa5-89a52dd4b119@github.com>
References: <ASCOaOEaKxCTMEzRTADTMkIxJZ3y5fTD1D2bC_Zyi7k=.de0aea66-338c-46be-9fa5-89a52dd4b119@github.com>
Message-ID: <tt7s8PDmJc5D-ihHauIQsAF7fHP18oEbUxD18Uq4wbQ=.dd0adf9d-6820-475d-ac2b-49ef5abbc115@github.com>

> The HexPrinter test utility should be ignoring \r characters from the formatter.
> It looks for \n and generates System.lineSeparator() at the end of each line.
> 
> With this fix, the ASN1FormatterTest can be removed from the ProblemList.

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

  Use .append instead of string concatenation for error message

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/486/files
  - new: https://git.openjdk.java.net/jdk/pull/486/files/6f1f564d..8cc42ac5

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

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

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

From mdoerr at openjdk.java.net  Wed Oct  7 16:29:13 2020
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Wed, 7 Oct 2020 16:29:13 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v2]
In-Reply-To: <6P-wrlA7c9wlXEhcoAYW5J9W2jwTmTTj3PkDObPh0LA=.c11aa048-8853-4e1c-a689-c34b89c15f12@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <6P-wrlA7c9wlXEhcoAYW5J9W2jwTmTTj3PkDObPh0LA=.c11aa048-8853-4e1c-a689-c34b89c15f12@github.com>
Message-ID: <ZqqaFPCInDiTFVub5iozxR4NOckf5yej6k7-sR3MP_s=.b1c9690b-5226-41a6-8f95-f1fa5232f757@github.com>

On Mon, 5 Oct 2020 18:29:58 GMT, CoreyAshford <github.com+51754783+CoreyAshford at openjdk.org> wrote:

>> This patch set encompasses the following commits:
>> 
>> - Adds a new HotSpot intrinsic candidate to the java.lang.Base64 class - decodeBlock(), and provides a flexible API for
>>   the intrinsic.  The API is similar to the existing encodeBlock intrinsic.
>> - Adds the code in HotSpot to check and martial the new intrinsic's arguments to the arch-specific intrinsic
>>   implementation
>> - Adds a Power64LE-specific implementation of the decodeBlock intrinsic.
>> - Adds a JMH microbenchmark for both Base64 encoding and encoding.
>> - Enhances the JTReg hotspot intrinsic "TestBase64.java" regression test to more fully test both decoding and encoding.
>
> CoreyAshford has updated the pull request with a new target base due to a merge or a rebase. The pull request now
> contains ten commits:
>  - AOT: Revert change to aotCodeHeap.cpp for decodeBlock
>    
>    Don't add the SET_AOT_GLOBAL_SYMBOL_VALUE macro for decode block until all
>    arches that implement AOT, implement the decodeBlock intrinsic.
>  - Base64.java decodeBlock: Changes from PR review
>    
>     * Make comparison safer and consistent with the while loop
>     * Update comment about the decodeBlock intrinsic so that it matches the new structure
>     * Add comment about the lack of a length check on the destination buffer
>     * As per issue 8138732, change HotSpotIntrinsicCandidate to IntrinsicCandidate
>  - stubGenerator_ppc.cpp: Changes from PR review
>    
>     * Fix clearing of upper bits to clear 32 bits instead of 31 (due to misreading of clrldi instruction)
>     * change and document loop_unrolls setting from 8 to 2 after re-running the benchmark
>     * align unrolled loop on a 32-byte boundary
>     * replace instruction used for checking isURL from a double word to single
>       word instruction since the register is effectively 32 bits wide
>     * cosmetic change to realign register comments.
>  - TestBase64.java: Changes from PR review
>    
>     * Use Utils.toByteArrays() method instead of a locally-defined method
>     * Generate the two non-Base64 tables dynamically rather than use static initialization
>     * Added comments describing the two above-mentioned arrays
>  - Expand the Base64 intrinsic regression test to cover decodeBlock
>    
>    This patch makes four significant changes:
>    
>    1) The Power implementation of the decodeBlock intrinsic, at least,
>    requires a decode length of at least 128 bytes, but the existing test cases
>    are much shorter, maxing out at 111 bytes.  So the patch adds a new input
>    data file which has longer test cases in it.
>    
>    2) The original test cases only covers the encoding of just the printable
>    subset of the 7-bit ASCII characters.  However, Base64 encoding requires
>    being able to encode arbitrary binary data, i.e. it must handle all 256
>    8-bit byte encodings.  To remedy this, but keep the original line-oriented
>    style of the input data, I added another input file type that uses a simple
>    ASCII hexadecimal encoding - two ASCII hex characters per 8-bit byte.  When
>    test0 is called, a new parameter is passed that specifies the type of the
>    input file, which is either the original ASCII type or the hexadecimal
>    format.  So to test both longer input data and arbitrary 8-bit data, the
>    newly added input test file has test cases which are both longer and
>    encoded in ASCII hex so as to give full 8-bit capability.  When reading
>    this type of file, test0 calls a newly-added function to translate the
>    ASCII hex to binary data.  Except for the first line of input data, which
>    contains all possible 8-bit values sequentially, the input data was
>    generated using a random length (between 111 and 520 bytes) buffer filled
>    with random 8-bit data, which should give adequate coverage.
>    
>    3) The original test did not test that the decoder detects illegal Base64
>    bytes.  This change chooses a random location in the encoded data to
>    corrupt with a randomly-chosen byte which is illegal for the specific
>    Base64 encoding that is chosen (i.e. standard or URLsafe).  It then calls
>    the decode function to verify that the illegal byte is detected and the
>    proper exception is thrown.
>    
>    4) The test iteration count was originally 100K, but that is far more than
>    enough iterations to test the intrinsic.  It takes 20K iterations on each
>    instrinsic for HotSpot C2 to begin calling it.  The test originally had
>    three types of encodings to test and called the encode intrinsic four times
>    for each iteration, which works out to 100K * 3 * 4 = 1.2M calls just to
>    encode.  Decode was called four times as well (now five because of the
>    illegal byte test).  I believe this is excessive and with the extra test
>    data I have added, the test was timing out after ten minutes of execution.
>    It appears that it is timing out, not because the intrinsics take a long
>    time to run, but because test0 generates an enormous number of discarded
>    data buffers for the GC system to recover (the test runs at about 39GB of
>    virtual memory on my test machine).  To remedy the timeout problem, I have
>    changed the code so that a warmup function of 20K repetitions is performed
>    on a fixed buffer, to activate the instrinsic(s).  After the warmup, I have
>    reduced the number of iterations to 5K on each test0 call.  This should
>    give adequate coverage.
>  - Add JMH benchmark for Base64 variable length buffer decoding
>  - Add Power9+ intrinsic implementation for Base64 decoding
>  - Add HotSpot code to implement Base64 decodeBlock API
>  - Add HotSpotIntrinsicCandidate and API for Base64 decoding

Hi Corey,
thanks for contributing this change. Looks basically good. Please address the inline comments from Roger and me.
Core libs part is reviewed by Roger and the whole change by me. The shared hotspot part is straight forward because
it's very similar to the encode intrinsic. So I think we only need a 2nd review for the PPC64 algorithm implementation.
I can sponsor the change when this is completed.

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

Changes requested by mdoerr (Reviewer).

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

From shade at openjdk.java.net  Wed Oct  7 16:31:09 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 7 Oct 2020 16:31:09 GMT
Subject: RFR: 8254146: Avoid unnecessary volatile write on new
 AtomicBoolean(false)
In-Reply-To: <YCAn0HKEP0_EZcQUQLL1Xo3Ghw54zKq8ZGDT_A5daUo=.33924e26-7ef1-4395-95e3-9efa4005ca77@github.com>
References: <AzWKluHZjvFYm2wUanwYfn91iKKMacpk_qSsje3tXWk=.ba873b46-4e12-4415-8832-fa314d6759a3@github.com>
 <yNUBzMyHr1Asbrtyt2sHQnGcJOxdfP8umMyRPC863Rw=.5c18ea25-bcf8-473b-a86a-fe764b8684d6@github.com>
 <P4lM3Rv3CAm7OqpNbLH3mvmgpVv0nVY1TeDw0VFy7jY=.54c361de-0133-4e10-ae04-12c79686e16a@github.com>
 <YCAn0HKEP0_EZcQUQLL1Xo3Ghw54zKq8ZGDT_A5daUo=.33924e26-7ef1-4395-95e3-9efa4005ca77@github.com>
Message-ID: <NL9WtVFpAwsc6pG273abr_0N5_xThMwK5AKUVquNMsw=.9fe705eb-5689-4da8-913c-e39567f9bc67@github.com>

On Wed, 7 Oct 2020 15:28:27 GMT, Christoph Dreis <github.com+6304496+dreis2211 at openjdk.org> wrote:

>>> @AlanBateman What would be the label (or workflow) for that now?
>> 
>> @dreis2211 what Alan reminded us of here is that all of j.u.concurrent is maintained upstream from the OpenJDK, and
>> that this change needs to be coordinated with the maintainers there. Either by getting an OK to go ahead and push this
>> as-is, or by contributing this patch to the JSR166 repo directly (which will then be integrated back into the OpenJDK
>> at some point). See http://gee.cs.oswego.edu/dl/concurrency-interest/   This isn't anything new since the GitHub
>> migration: Various bits and pieces of the OpenJDK sources are maintained upstream, and it's not always easy to igure
>> out exactly where or how to go about upstreaming a change.
>
> @cl4es Thanks. My question was more referring to how the PR tooling should be used these days to notify the
> maintainers. As JSR166 is a crucial piece of the JDK I was wondering if there might be a way already via a label or
> something. Or if this needs some good old mail (to concurrency-interest at cs.oswego.edu I suppose?)

You can probably go ahead and ping @DougLea (like this).

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

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

From lancea at openjdk.java.net  Wed Oct  7 16:32:14 2020
From: lancea at openjdk.java.net (Lance Andersen)
Date: Wed, 7 Oct 2020 16:32:14 GMT
Subject: RFR: 8253876: jdk/test/lib/hexdump/ASN1FormatterTest.java fails
 with "AssertionError: Lines expected [126] but found [202]" [v3]
In-Reply-To: <tt7s8PDmJc5D-ihHauIQsAF7fHP18oEbUxD18Uq4wbQ=.dd0adf9d-6820-475d-ac2b-49ef5abbc115@github.com>
References: <ASCOaOEaKxCTMEzRTADTMkIxJZ3y5fTD1D2bC_Zyi7k=.de0aea66-338c-46be-9fa5-89a52dd4b119@github.com>
 <tt7s8PDmJc5D-ihHauIQsAF7fHP18oEbUxD18Uq4wbQ=.dd0adf9d-6820-475d-ac2b-49ef5abbc115@github.com>
Message-ID: <jci0Kb_1BUxeY--Yel3jSfsxv1i80_r0c2Mz3Cl08L0=.cf8ec01c-ca3d-4030-abab-bf668a1e446a@github.com>

On Wed, 7 Oct 2020 16:25:27 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> The HexPrinter test utility should be ignoring \r characters from the formatter.
>> It looks for \n and generates System.lineSeparator() at the end of each line.
>> 
>> With this fix, the ASN1FormatterTest can be removed from the ProblemList.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use .append instead of string concatenation for error message

Marked as reviewed by lancea (Reviewer).

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

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

From simonis at openjdk.java.net  Wed Oct  7 16:48:13 2020
From: simonis at openjdk.java.net (Volker Simonis)
Date: Wed, 7 Oct 2020 16:48:13 GMT
Subject: RFR: 8253952: Refine ZipOutputStream.putNextEntry() to ignore
 ZipEntry's compressed size
In-Reply-To: <uOv0IEZBeC6bdvSTaZ2VHF6ApqwpwWGuTsKznkhzFu0=.9ad91b5b-74ce-4702-ba77-55bf6ab67189@github.com>
References: <0nq5oFKOj6AZqCW6jF268-6oKRI6UkS6TRIHo-_5vKw=.d13c7016-4473-4b20-9117-100b368d3716@github.com>
 <uOv0IEZBeC6bdvSTaZ2VHF6ApqwpwWGuTsKznkhzFu0=.9ad91b5b-74ce-4702-ba77-55bf6ab67189@github.com>
Message-ID: <Vr-tO554xWe5xprEnPMCwuecXrH1DlIi7ip37NMPZqs=.d7d591c5-50fc-4eaf-bac6-eae58fb32040@github.com>

On Wed, 7 Oct 2020 16:09:47 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> ### Summary
>> 
>> Work around wrong usage of `ZipOutputStream.putNextEntry()` in user code which can lead to the `ZipException "invalid
>> entry compressed size"`.
>> ### Motivation
>> 
>> In general it is not safe to directly write a ZipEntry obtained from `ZipInputStream.getNextEntry()`,
>> `ZipFile.entries()`, `ZipFile.getEntry()` or `ZipFile.stream()` with `ZipOutputStream.putNextEntry()` to a
>> `ZipOutputStream` and then read the entries data from the `ZipInputStream` and write it to the `ZipOutputStream` as
>> follows:
>>  ZipEntry entry;
>>  ZipInputStream zis = new ZipInputStream(...);
>>  ZipOutputStream zos = new ZipOutputStream(...);
>>  while((entry = zis.getNextEntry()) != null) {
>>      zos.putNextEntry(entry);
>>      zis.transferTo(zos);
>>  }
>> The problem with this code is that the zip file format does not record the compression level used for deflation in its
>> entries. In general, it doesn't even mandate a predefined compression ratio per compression level. Therefore the
>> compressed size recorded in a `ZipEntry` read from a zip file might differ from the new compressed size produced by the
>> receiving `ZipOutputStream`. Such a difference will result in a `ZipException` with the following message:
>>  java.util.zip.ZipException: invalid entry compressed size (expected 12 but got 7 bytes)
>>  
>> The correct way of copying all entries from one zip file into another requires the creation of a new `ZipEntry` or at
>> least resetting of the compressed size field. E.g.:
>>  while((entry = zis.getNextEntry()) != null) {
>>      ZipEntry newEntry = new ZipEntry(entry.getName());
>>      zos.putNextEntry(newEntry);
>>      zis.transferTo(zos);
>>  }
>> or:
>>  while((entry = zis.getNextEntry()) != null) {
>>      entry.setCompressedSize(-1);
>>      zos.putNextEntry(entry);
>>      zis.transferTo(zos);
>>  }
>> Unfortunately, there's a lot of user code out there which gets this wrong and uses the bad coding pattern described
>> before. Searching for `"java.util.zip.ZipException: invalid entry compressed size (expected 12 but got 7 bytes)"` gives
>> ~2500 hits (~100 on StackOverflow). It's also no hard to find plenty of instances of this anti-pattern on GitHub when
>> doing a code search for `ZipEntry` and `putNextEntry()`. E.g. [Gradle 4.x wrapper task][1] is affected as well as the
>> latest version of the [mockableAndroidJar task][2]. I've recently fixed two occurrences of this pattern in OpenJDK (see
>> [JDK-8240333][3] and [JDK-8240235][4]) but there still exist more of them (e.g.
>> [`test/jdk/java/util/zip/ZipFile/CopyJar.java`][5] which is there since 1999 :).  ### Description  So while this has
>> clearly been a problem before, it apparently wasn't painful enough to trigger any action from the side of the JDK.
>> However, recently quite some zlib forks with [superior deflate/inflate performance have evolved][6]. Using them with
>> OpenJDK is quite straight-forward: one just has to configure the alternative implementations by setting
>> `LD_LIBRARY_PATH` or `LD_PRELOAD` correspondingly. We've seen big saving by using these new zlib implementations for
>> selected services in production and the only reason why we haven't enabled them by default until now is the problem
>> I've just described. The reason why these new libraries uncover the described anti-pattern much more often is because
>> their compression ratio is slightly different from that of the default zlib library. This can easily trigger a
>> `ZipException` even if an application is not using a different compression levels but just a zip file created with
>> another zlib version.  I'd therefore like to propose the following workaround for the wrong
>> `ZipOutputStream.putNextEntry()` usage in user code:
>> -  ignore the compressed size if it was implicitly determined from the zip file and not explicitly set by calling
>>    `ZipEntry.setCompressedSize()`.
>> 
>> - Change the API-documentation of `ZipOutputStream.putNextEntry()` and `JarOutputStream.putNextEntry()` to explain the
>>   problem and why `putNextEntry()` will ignore the compressed size of a `ZipEntry` if that was set implicitely when
>>   reading that entry from a `ZipFile` or `ZipInputStream`.
>> 
>> 
>> ### Technical Details
>> 
>> A zip file consists of a stream of File Entries followed by a Central Directory (see [here for a more detailed
>> specification][7]). Each File Entry is composed of a Local File Header (LFH) followed by the compressed Data and an
>> optional Data Descriptor. The LFH contains the File Name and among other attributes the Compressed and Uncompressed
>> size and CRC of the Data. In the case where the latter three attributes are not available at the time when the LFH is
>> created, this fact will be recorded in a flag of the LFH and will trigger the creation of a Data Descriptor with the
>> corresponding information right after the Data section. Finally, the Central Directory contains one Central Directory
>> File Header (CDFH) for each entry of the  zip archive. The CDFH is an extended version of the LFH and the ultimate
>> reference for the contents of the zip archive. The redundancy between LFH and CDFH is a tribute to zip's long history
>> when it was used to store archives on multiple floppy discs and the CDFH allowed to update the archive by only writing
>> to the last disc which contained the Central Directory.  `ZipEntries` read with `ZipInputStream.getNextEntry()` will
>> initially only contain the information from the LFH. Only after the next entry was read (or after
>> `ZipInputStream.closeEntry()` was called explicitly), will the previously read entry be updated with the data from the
>> Data Descriptor. `ZipInputStream` doesn't inspect the Central Directory at all.  On the other hand, `ZipFile` only
>> queries the Central Directory for `ZipEntry` information so all `ZipEntries` returned by `ZipFile.entries()`,
>> `ZipFile.getEntry()` and `ZipFile.stream()` will always instantly contain the full Compressed and Uncompressed Size and
>> CRC information for each entry independently of the LFH contents.  ### Risks and Assumptions  If we choose to ignore
>> the implicitly recorded compressed size in a `ZipEntry` read from a zip file when writing it to a `ZipOutputStream`,
>> this will lead to zip files with incomplete information in the LFH and an additional Data Descriptor as described
>> before. However, the result is still fully compatible to the zip file specification. It's also not unusual, because by
>> default all new zip files created with `ZipOutputStream` will contain LFHs without Compressed and Uncompressed Size and
>> CRC information and an additional Data Descriptor. Theoretically it is possible to create new zip files with
>> `ZipOutputStream` class and Compressed and Uncompressed Size and CRC information in the LFH but that's complex and
>> inefficient because it requires two steps. A first step to determine the crc and compressed size of the data and a
>> second step to actually write the data to the `ZipOutputStream` (which will compress it a second time). This is because
>> the current API offers no possibility to write already compressed data to a `ZipOutputStream`.  Consequently, the only
>> straight-forward way of creating zip files from Java which have all the data in the LFH and no Data Descriptor is by
>> copying `ZipEntries` from an existing zip file with the buggy method described before. This incidentally worked more or
>> less reliable for a long time but breaks miserably when using different zlib implementations. Ignoring the implicitly
>> set compressed size of `ZipEntries` can easily fix this problem.  I'm not aware of any tool which can not handle such
>> files and if it exists it would have problems with the majority of Java created zip files anyway (e.g. all jar-files
>> created with the jar tool have zip entries with incomplete LFH data and additional Data Descriptor).  Ignoring the
>> implicitly set compressed size of `ZipEntries` has no measurable performance impact and will increase the size of zip
>> archives which used to have the complete file information in the LFH before by 16 bytes per entry. On the other hand it
>> will give us the freedom to use whatever zip implementation we like :)   [1]:
>> https://github.com/gradle/gradle/blob/e76905e3a/subprojects/build-init/src/main/java/org/gradle/api/tasks/wrapper/Wrapper.java#L152-L158
>> [2]:
>> https://android.googlesource.com/platform/tools/base/+/refs/heads/master/build-system/builder/src/main/java/com/android/builder/testing/MockableJarGenerator.java#86
>> [3]: https://bugs.openjdk.java.net/browse/JDK-8240333 [4]: https://bugs.openjdk.java.net/browse/JDK-8240235 [5]:
>> https://github.com/openjdk/jdk/blob/master/test/jdk/java/util/zip/ZipFile/CopyJar.java [6]:
>> https://github.com/simonis/zlib-bench/blob/master/Results.md [7]: https://en.wikipedia.org/wiki/Zip_(file_format)
>
> I think as we start to move forward with the review and CSR, we should update the bug and PR description as the change
> is not a workaround but a change in behavior of the implementation

I already changed the bug description on Alan's request and just updated the PR description to reflect that. Please
feel free to propose a better description.

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

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

From simonis at openjdk.java.net  Wed Oct  7 16:48:14 2020
From: simonis at openjdk.java.net (Volker Simonis)
Date: Wed, 7 Oct 2020 16:48:14 GMT
Subject: RFR: 8253952: Refine ZipOutputStream.putNextEntry() to ignore
 ZipEntry's compressed size
In-Reply-To: <sCZNDJVA17V3tGPsCYV88AODMtfrhTfLlii5q0Qz4u8=.531888c3-19a9-4572-acda-81183a81e08f@github.com>
References: <0nq5oFKOj6AZqCW6jF268-6oKRI6UkS6TRIHo-_5vKw=.d13c7016-4473-4b20-9117-100b368d3716@github.com>
 <c12QhQcAA4YctkyHYdULM9mSQ6KI9iqZM5MAuLJroGE=.a84fc8f5-411c-4ec0-b421-c3cf62c849c7@github.com>
 <sCZNDJVA17V3tGPsCYV88AODMtfrhTfLlii5q0Qz4u8=.531888c3-19a9-4572-acda-81183a81e08f@github.com>
Message-ID: <cCg_cQOTmL40ZA0Hta1XGqlG72Be8dFKTZOMRxIBtHc=.3fd89e55-6854-49df-a007-4e3252a92e7a@github.com>

On Wed, 7 Oct 2020 15:34:32 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/jar/JarOutputStream.java line 97:
>> 
>>> 95:      * and re-compute its value automatically after the associted data has been
>>> 96:      * completely deflated.
>>> 97:      *
>> 
>> We probably need to do a bit wordsmithing here.
>> 
>> I think I'd drop the first two sentences and instead start a new paragraph here (<p> tag) with "Unless explicitly set,
>> the output stream will ignore ..." and see how that looks.
>> Probably should be "the ZipEntry" rather than "a ZipEntry" to be consistent with the parameter description.
>
> Alan makes a good point.  Perhaps we keep things simple and focus solely on tweaking the description of the change in
> behavior which is described in your last paragraph

I totally agree. What about using just the last sentence (as you've proposed) in the spec section and add the other to
as @implNote? O you think the last sentence will be enough?

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

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

From github.com+2233919+douglea at openjdk.java.net  Wed Oct  7 16:59:10 2020
From: github.com+2233919+douglea at openjdk.java.net (DougLea)
Date: Wed, 7 Oct 2020 16:59:10 GMT
Subject: RFR: 8254146: Avoid unnecessary volatile write on new
 AtomicBoolean(false)
In-Reply-To: <NL9WtVFpAwsc6pG273abr_0N5_xThMwK5AKUVquNMsw=.9fe705eb-5689-4da8-913c-e39567f9bc67@github.com>
References: <AzWKluHZjvFYm2wUanwYfn91iKKMacpk_qSsje3tXWk=.ba873b46-4e12-4415-8832-fa314d6759a3@github.com>
 <yNUBzMyHr1Asbrtyt2sHQnGcJOxdfP8umMyRPC863Rw=.5c18ea25-bcf8-473b-a86a-fe764b8684d6@github.com>
 <P4lM3Rv3CAm7OqpNbLH3mvmgpVv0nVY1TeDw0VFy7jY=.54c361de-0133-4e10-ae04-12c79686e16a@github.com>
 <YCAn0HKEP0_EZcQUQLL1Xo3Ghw54zKq8ZGDT_A5daUo=.33924e26-7ef1-4395-95e3-9efa4005ca77@github.com>
 <NL9WtVFpAwsc6pG273abr_0N5_xThMwK5AKUVquNMsw=.9fe705eb-5689-4da8-913c-e39567f9bc67@github.com>
Message-ID: <0R_DeYk8B1ky2fjZYUpz6xEv2exb-W4BdtU_Yu2B0wI=.c3008858-4469-4d2c-913f-2902ea686503@github.com>

On Wed, 7 Oct 2020 16:28:23 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> @cl4es Thanks. My question was more referring to how the PR tooling should be used these days to notify the
>> maintainers. As JSR166 is a crucial piece of the JDK I was wondering if there might be a way already via a label or
>> something. Or if this needs some good old mail (to concurrency-interest at cs.oswego.edu I suppose?)
>
> You can probably go ahead and ping @DougLea (like this).

I'm a little hesitant about the precedent of checking for 0 in every ctor argument for a volatile field.
An alternative here worth measuring is: VALUE.setRelease(this, initialValue ? 1 : 0);

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

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

From github.com+6304496+dreis2211 at openjdk.java.net  Wed Oct  7 17:04:08 2020
From: github.com+6304496+dreis2211 at openjdk.java.net (Christoph Dreis)
Date: Wed, 7 Oct 2020 17:04:08 GMT
Subject: RFR: 8254146: Avoid unnecessary volatile write on new
 AtomicBoolean(false)
In-Reply-To: <0R_DeYk8B1ky2fjZYUpz6xEv2exb-W4BdtU_Yu2B0wI=.c3008858-4469-4d2c-913f-2902ea686503@github.com>
References: <AzWKluHZjvFYm2wUanwYfn91iKKMacpk_qSsje3tXWk=.ba873b46-4e12-4415-8832-fa314d6759a3@github.com>
 <yNUBzMyHr1Asbrtyt2sHQnGcJOxdfP8umMyRPC863Rw=.5c18ea25-bcf8-473b-a86a-fe764b8684d6@github.com>
 <P4lM3Rv3CAm7OqpNbLH3mvmgpVv0nVY1TeDw0VFy7jY=.54c361de-0133-4e10-ae04-12c79686e16a@github.com>
 <YCAn0HKEP0_EZcQUQLL1Xo3Ghw54zKq8ZGDT_A5daUo=.33924e26-7ef1-4395-95e3-9efa4005ca77@github.com>
 <NL9WtVFpAwsc6pG273abr_0N5_xThMwK5AKUVquNMsw=.9fe705eb-5689-4da8-913c-e39567f9bc67@github.com>
 <0R_DeYk8B1ky2fjZYUpz6xEv2exb-W4BdtU_Yu2B0wI=.c3008858-4469-4d2c-913f-2902ea686503@github.com>
Message-ID: <tVJPFN5AhgLiPCNQbqVZTqTIoZXv6e86IhB4k8Ow-qc=.dcb90a28-b1fc-4a23-bfee-3d1c5c4627ac@github.com>

On Wed, 7 Oct 2020 16:52:42 GMT, DougLea <github.com+2233919+DougLea at openjdk.org> wrote:

> I'm a little hesitant about the precedent of checking for 0 in every ctor argument for a volatile field.

I'm confused by this if I'm entirely honest @DougLea . Where do we check for 0 in the proposed change?

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

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

From lancea at openjdk.java.net  Wed Oct  7 17:07:08 2020
From: lancea at openjdk.java.net (Lance Andersen)
Date: Wed, 7 Oct 2020 17:07:08 GMT
Subject: RFR: 8253952: Refine ZipOutputStream.putNextEntry() to ignore
 ZipEntry's compressed size
In-Reply-To: <cCg_cQOTmL40ZA0Hta1XGqlG72Be8dFKTZOMRxIBtHc=.3fd89e55-6854-49df-a007-4e3252a92e7a@github.com>
References: <0nq5oFKOj6AZqCW6jF268-6oKRI6UkS6TRIHo-_5vKw=.d13c7016-4473-4b20-9117-100b368d3716@github.com>
 <c12QhQcAA4YctkyHYdULM9mSQ6KI9iqZM5MAuLJroGE=.a84fc8f5-411c-4ec0-b421-c3cf62c849c7@github.com>
 <sCZNDJVA17V3tGPsCYV88AODMtfrhTfLlii5q0Qz4u8=.531888c3-19a9-4572-acda-81183a81e08f@github.com>
 <cCg_cQOTmL40ZA0Hta1XGqlG72Be8dFKTZOMRxIBtHc=.3fd89e55-6854-49df-a007-4e3252a92e7a@github.com>
Message-ID: <KcBcWMkN_kJ7JZXC3yWKbF1KEYX_cd0iYofyGSRuMgk=.1a0b3b65-8aeb-4de8-b38a-cb282966f947@github.com>

On Wed, 7 Oct 2020 16:43:53 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> Alan makes a good point.  Perhaps we keep things simple and focus solely on tweaking the description of the change in
>> behavior which is described in your last paragraph
>
> I totally agree. What about using just the last sentence (as you've proposed) in the spec section and add the other to
> as @implNote? O you think the last sentence will be enough?

I think we can just go with the last sentence/paragraph.  Perhaps  we can further simplify the  paragraph/sentence with
something like:

The compressed entry size will be recalculated  for compressed (DEFLATED) entries when  ZipEntry::setCompressedSize has
not been explicitly called on the ZipEntry.

or

The compressed (DEFLATED) entry size will be recalculated when  ZipEntry::setCompressedSize has not been explicitly
called on the ZipEntry.

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

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

From bpb at openjdk.java.net  Wed Oct  7 17:20:14 2020
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 7 Oct 2020 17:20:14 GMT
Subject: Integrated: 8067127: Tags cleanup
In-Reply-To: <8YR2pzHDTetS1LChJUDvPtgo_LdMBZggFfmkdLl-HO4=.8016f8e2-aa1f-429f-a744-798807c7964e@github.com>
References: <8YR2pzHDTetS1LChJUDvPtgo_LdMBZggFfmkdLl-HO4=.8016f8e2-aa1f-429f-a744-798807c7964e@github.com>
Message-ID: <BswshraqUbV67-MVR8uT2jY62_Ohacfo1L0QYdPNaRc=.917ddb21-0c7f-47c9-a933-869eb4eceedd@github.com>

On Mon, 5 Oct 2020 18:59:00 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Please review this change to update some javadoc tags in the java.io package. The changes are to replace some
> occurrences of <code>some_code</code> with {@code some_code}. Not all such constructs were replaced as being
> infeasible, e.g., tag contains an entity such as <code>*&#47;</code> (DataOutput, Serial), or multiple {@code} tags
> would be needed or the result would be ugly (File). It is unclear whether some of the changes which remove the
> non-breaking space entity (&nbsp;) are desirable.  Thanks,  Brian

This pull request has now been integrated.

Changeset: db3053dc
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/db3053dc
Stats:     37 lines in 13 files changed: 0 ins; 0 del; 37 mod

8067127: Tags cleanup

Reviewed-by: rriggs, dfuchs, lancea

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

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

From github.com+51754783+coreyashford at openjdk.java.net  Wed Oct  7 17:24:12 2020
From: github.com+51754783+coreyashford at openjdk.java.net (CoreyAshford)
Date: Wed, 7 Oct 2020 17:24:12 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v2]
In-Reply-To: <HOu6omKjwLS5JBVS4sq0mjt1ZZwxvbH597cmwwG7QQs=.6d5549e6-5459-43b2-9bc4-e108cd852f25@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <6P-wrlA7c9wlXEhcoAYW5J9W2jwTmTTj3PkDObPh0LA=.c11aa048-8853-4e1c-a689-c34b89c15f12@github.com>
 <HOu6omKjwLS5JBVS4sq0mjt1ZZwxvbH597cmwwG7QQs=.6d5549e6-5459-43b2-9bc4-e108cd852f25@github.com>
Message-ID: <czcCaNp0j7Mu6RpBxWdaImL8cokJLll8xKm3LwU4UDA=.8f454c10-dd30-4032-8bcd-dab80dc48595@github.com>

On Wed, 7 Oct 2020 13:35:35 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> CoreyAshford has updated the pull request with a new target base due to a merge or a rebase. The pull request now
>> contains ten commits:
>>  - AOT: Revert change to aotCodeHeap.cpp for decodeBlock
>>    
>>    Don't add the SET_AOT_GLOBAL_SYMBOL_VALUE macro for decode block until all
>>    arches that implement AOT, implement the decodeBlock intrinsic.
>>  - Base64.java decodeBlock: Changes from PR review
>>    
>>     * Make comparison safer and consistent with the while loop
>>     * Update comment about the decodeBlock intrinsic so that it matches the new structure
>>     * Add comment about the lack of a length check on the destination buffer
>>     * As per issue 8138732, change HotSpotIntrinsicCandidate to IntrinsicCandidate
>>  - stubGenerator_ppc.cpp: Changes from PR review
>>    
>>     * Fix clearing of upper bits to clear 32 bits instead of 31 (due to misreading of clrldi instruction)
>>     * change and document loop_unrolls setting from 8 to 2 after re-running the benchmark
>>     * align unrolled loop on a 32-byte boundary
>>     * replace instruction used for checking isURL from a double word to single
>>       word instruction since the register is effectively 32 bits wide
>>     * cosmetic change to realign register comments.
>>  - TestBase64.java: Changes from PR review
>>    
>>     * Use Utils.toByteArrays() method instead of a locally-defined method
>>     * Generate the two non-Base64 tables dynamically rather than use static initialization
>>     * Added comments describing the two above-mentioned arrays
>>  - Expand the Base64 intrinsic regression test to cover decodeBlock
>>    
>>    This patch makes four significant changes:
>>    
>>    1) The Power implementation of the decodeBlock intrinsic, at least,
>>    requires a decode length of at least 128 bytes, but the existing test cases
>>    are much shorter, maxing out at 111 bytes.  So the patch adds a new input
>>    data file which has longer test cases in it.
>>    
>>    2) The original test cases only covers the encoding of just the printable
>>    subset of the 7-bit ASCII characters.  However, Base64 encoding requires
>>    being able to encode arbitrary binary data, i.e. it must handle all 256
>>    8-bit byte encodings.  To remedy this, but keep the original line-oriented
>>    style of the input data, I added another input file type that uses a simple
>>    ASCII hexadecimal encoding - two ASCII hex characters per 8-bit byte.  When
>>    test0 is called, a new parameter is passed that specifies the type of the
>>    input file, which is either the original ASCII type or the hexadecimal
>>    format.  So to test both longer input data and arbitrary 8-bit data, the
>>    newly added input test file has test cases which are both longer and
>>    encoded in ASCII hex so as to give full 8-bit capability.  When reading
>>    this type of file, test0 calls a newly-added function to translate the
>>    ASCII hex to binary data.  Except for the first line of input data, which
>>    contains all possible 8-bit values sequentially, the input data was
>>    generated using a random length (between 111 and 520 bytes) buffer filled
>>    with random 8-bit data, which should give adequate coverage.
>>    
>>    3) The original test did not test that the decoder detects illegal Base64
>>    bytes.  This change chooses a random location in the encoded data to
>>    corrupt with a randomly-chosen byte which is illegal for the specific
>>    Base64 encoding that is chosen (i.e. standard or URLsafe).  It then calls
>>    the decode function to verify that the illegal byte is detected and the
>>    proper exception is thrown.
>>    
>>    4) The test iteration count was originally 100K, but that is far more than
>>    enough iterations to test the intrinsic.  It takes 20K iterations on each
>>    instrinsic for HotSpot C2 to begin calling it.  The test originally had
>>    three types of encodings to test and called the encode intrinsic four times
>>    for each iteration, which works out to 100K * 3 * 4 = 1.2M calls just to
>>    encode.  Decode was called four times as well (now five because of the
>>    illegal byte test).  I believe this is excessive and with the extra test
>>    data I have added, the test was timing out after ten minutes of execution.
>>    It appears that it is timing out, not because the intrinsics take a long
>>    time to run, but because test0 generates an enormous number of discarded
>>    data buffers for the GC system to recover (the test runs at about 39GB of
>>    virtual memory on my test machine).  To remedy the timeout problem, I have
>>    changed the code so that a warmup function of 20K repetitions is performed
>>    on a fixed buffer, to activate the instrinsic(s).  After the warmup, I have
>>    reduced the number of iterations to 5K on each test0 call.  This should
>>    give adequate coverage.
>>  - Add JMH benchmark for Base64 variable length buffer decoding
>>  - Add Power9+ intrinsic implementation for Base64 decoding
>>  - Add HotSpot code to implement Base64 decodeBlock API
>>  - Add HotSpotIntrinsicCandidate and API for Base64 decoding
>
> src/java.base/share/classes/java/util/Base64.java line 776:
> 
>> 774:          * @param  sl
>> 775:          *         the total length of source array
>> 776:          * @param  dst
> 
> Please update the comment for `sl`.  sl is the offset (exclusive) past the last byte to be converted.

Ok, will change.

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

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

From github.com+51754783+coreyashford at openjdk.java.net  Wed Oct  7 17:24:17 2020
From: github.com+51754783+coreyashford at openjdk.java.net (CoreyAshford)
Date: Wed, 7 Oct 2020 17:24:17 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v2]
In-Reply-To: <r5FtoUonRPCmhZ7ueswqkgh9pTwoA4rYrrpfVIO1zBE=.2917dc6c-d288-4ea4-b958-e6021025b9e5@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <6P-wrlA7c9wlXEhcoAYW5J9W2jwTmTTj3PkDObPh0LA=.c11aa048-8853-4e1c-a689-c34b89c15f12@github.com>
 <r5FtoUonRPCmhZ7ueswqkgh9pTwoA4rYrrpfVIO1zBE=.2917dc6c-d288-4ea4-b958-e6021025b9e5@github.com>
Message-ID: <eeX_BLBKC1ubNxaDyzQ34EubuaIklTcEZ08nThdLkT8=.0c07596d-982a-4bec-bf8d-c776ecd34e93@github.com>

On Wed, 7 Oct 2020 14:03:14 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> CoreyAshford has updated the pull request with a new target base due to a merge or a rebase. The pull request now
>> contains ten commits:
>>  - AOT: Revert change to aotCodeHeap.cpp for decodeBlock
>>    
>>    Don't add the SET_AOT_GLOBAL_SYMBOL_VALUE macro for decode block until all
>>    arches that implement AOT, implement the decodeBlock intrinsic.
>>  - Base64.java decodeBlock: Changes from PR review
>>    
>>     * Make comparison safer and consistent with the while loop
>>     * Update comment about the decodeBlock intrinsic so that it matches the new structure
>>     * Add comment about the lack of a length check on the destination buffer
>>     * As per issue 8138732, change HotSpotIntrinsicCandidate to IntrinsicCandidate
>>  - stubGenerator_ppc.cpp: Changes from PR review
>>    
>>     * Fix clearing of upper bits to clear 32 bits instead of 31 (due to misreading of clrldi instruction)
>>     * change and document loop_unrolls setting from 8 to 2 after re-running the benchmark
>>     * align unrolled loop on a 32-byte boundary
>>     * replace instruction used for checking isURL from a double word to single
>>       word instruction since the register is effectively 32 bits wide
>>     * cosmetic change to realign register comments.
>>  - TestBase64.java: Changes from PR review
>>    
>>     * Use Utils.toByteArrays() method instead of a locally-defined method
>>     * Generate the two non-Base64 tables dynamically rather than use static initialization
>>     * Added comments describing the two above-mentioned arrays
>>  - Expand the Base64 intrinsic regression test to cover decodeBlock
>>    
>>    This patch makes four significant changes:
>>    
>>    1) The Power implementation of the decodeBlock intrinsic, at least,
>>    requires a decode length of at least 128 bytes, but the existing test cases
>>    are much shorter, maxing out at 111 bytes.  So the patch adds a new input
>>    data file which has longer test cases in it.
>>    
>>    2) The original test cases only covers the encoding of just the printable
>>    subset of the 7-bit ASCII characters.  However, Base64 encoding requires
>>    being able to encode arbitrary binary data, i.e. it must handle all 256
>>    8-bit byte encodings.  To remedy this, but keep the original line-oriented
>>    style of the input data, I added another input file type that uses a simple
>>    ASCII hexadecimal encoding - two ASCII hex characters per 8-bit byte.  When
>>    test0 is called, a new parameter is passed that specifies the type of the
>>    input file, which is either the original ASCII type or the hexadecimal
>>    format.  So to test both longer input data and arbitrary 8-bit data, the
>>    newly added input test file has test cases which are both longer and
>>    encoded in ASCII hex so as to give full 8-bit capability.  When reading
>>    this type of file, test0 calls a newly-added function to translate the
>>    ASCII hex to binary data.  Except for the first line of input data, which
>>    contains all possible 8-bit values sequentially, the input data was
>>    generated using a random length (between 111 and 520 bytes) buffer filled
>>    with random 8-bit data, which should give adequate coverage.
>>    
>>    3) The original test did not test that the decoder detects illegal Base64
>>    bytes.  This change chooses a random location in the encoded data to
>>    corrupt with a randomly-chosen byte which is illegal for the specific
>>    Base64 encoding that is chosen (i.e. standard or URLsafe).  It then calls
>>    the decode function to verify that the illegal byte is detected and the
>>    proper exception is thrown.
>>    
>>    4) The test iteration count was originally 100K, but that is far more than
>>    enough iterations to test the intrinsic.  It takes 20K iterations on each
>>    instrinsic for HotSpot C2 to begin calling it.  The test originally had
>>    three types of encodings to test and called the encode intrinsic four times
>>    for each iteration, which works out to 100K * 3 * 4 = 1.2M calls just to
>>    encode.  Decode was called four times as well (now five because of the
>>    illegal byte test).  I believe this is excessive and with the extra test
>>    data I have added, the test was timing out after ten minutes of execution.
>>    It appears that it is timing out, not because the intrinsics take a long
>>    time to run, but because test0 generates an enormous number of discarded
>>    data buffers for the GC system to recover (the test runs at about 39GB of
>>    virtual memory on my test machine).  To remedy the timeout problem, I have
>>    changed the code so that a warmup function of 20K repetitions is performed
>>    on a fixed buffer, to activate the instrinsic(s).  After the warmup, I have
>>    reduced the number of iterations to 5K on each test0 call.  This should
>>    give adequate coverage.
>>  - Add JMH benchmark for Base64 variable length buffer decoding
>>  - Add Power9+ intrinsic implementation for Base64 decoding
>>  - Add HotSpot code to implement Base64 decodeBlock API
>>  - Add HotSpotIntrinsicCandidate and API for Base64 decoding
>
> src/java.base/share/classes/java/util/Base64.java line 812:
> 
>> 810:
>> 811:             while (sp < sl) {
>> 812:                 if (shiftto == 18 && sp + 4 < sl) {       // fast path
> 
> Please change to sp < s1 - 4. Current version is sensitive to integer overflow. That's not a real problem in the
> current code, because the next check catches that, but we should better avoid this with the new intrinsics.

Good catch. Will fix.

> src/hotspot/cpu/ppc/stubGenerator_ppc.cpp line 3818:
> 
>> 3816:     __ cmpd(CCR0, end, in);
>> 3817:     __ blt_predict_not_taken(CCR0, unrolled_loop_exit);
>> 3818:     __ align(32);
> 
> align should be before bind(unrolled_loop_start)

oops, yes, that was dumb.  Good catch!   Will fix and re-benchmark.

> src/hotspot/cpu/ppc/stubGenerator_ppc.cpp line 3:
> 
>> 1: /*
>> 2:  * Copyright (c) 1997, 2020, Oracle and/or its affiliates. All rights reserved.
>> 3:  * Copyright (c) 2012, 2020, SAP SE. All rights reserved.
> 
> No comma before SAP SE, please! (See https://bugs.openjdk.java.net/browse/JDK-8252837)

Interesting.  I was trying to make it consistent with the Oracle copyright.  Ok, will fix.

> src/hotspot/cpu/ppc/stubGenerator_ppc.cpp line 3671:
> 
>> 3669:     // an advantage to keeping loop_unrolls small (to be able to process
>> 3670:     // smaller buffers), 2 is clearly the best choice.
>> 3671:     const unsigned loop_unrolls = 2;
> 
> Unrolling should be re-evaluated after alignment is fixed. align(32) is currently at the wrong place (see my comment
> below).

Agreed.

> src/hotspot/cpu/ppc/vm_version_ppc.cpp line 160:
> 
>> 158:     if (UseBASE64Intrinsics) {
>> 159:       warning("UseBASE64Intrinsics specified, but needs at least Power9.");
>> 160:       FLAG_SET_DEFAULT(UseCharacterCompareIntrinsics, false);
> 
> Copy & paste bug.

Oops, yes, will fix.

> src/hotspot/share/classfile/vmIntrinsics.cpp line 491:
> 
>> 489:     if (!UseGHASHIntrinsics) return true;
>> 490:     break;
>> 491:   case vmIntrinsics::_base64_decodeBlock:
> 
> I'd prefer to use consistent order. You have inserted decode after encode at other places.

I agree.  Will fix.

> src/hotspot/share/opto/library_call.cpp line 310:
> 
>> 308:   bool inline_base64_decodeBlock();
>> 309:   bool inline_digestBase_implCompress(vmIntrinsics::ID id);
>> 310:   bool inline_sha_implCompress(vmIntrinsics::ID id);
> 
> Why is that in this change?

Good catch!  I'm not sure what happened there.  Will investigate.

> src/hotspot/share/opto/runtime.cpp line 1211:
> 
>> 1209:   // result type needed
>> 1210:   fields = TypeTuple::fields(1);
>> 1211:   fields[TypeFunc::Parms + 0] = TypeInt::INT; // dst ofs, or -1
> 
> Why ", or -1" in the comment?

At one point the intrinsic would return -1 in the event of encountering a non-base64 byte.  I will update the comment
to be correct for the revised semantics.

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

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

From aph at openjdk.java.net  Wed Oct  7 17:26:26 2020
From: aph at openjdk.java.net (Andrew Haley)
Date: Wed, 7 Oct 2020 17:26:26 GMT
Subject: RFR: 8254078: DataOutputStream is very slow post-disabling of
 Biased Locking [v2]
In-Reply-To: <lLg_yNI_6LvUZTlM4PyN5ra6AaUZZeT35QzYzV_0CpI=.f2d3cb9e-be30-40dc-922c-dad5bef7feea@github.com>
References: <lLg_yNI_6LvUZTlM4PyN5ra6AaUZZeT35QzYzV_0CpI=.f2d3cb9e-be30-40dc-922c-dad5bef7feea@github.com>
Message-ID: <Tj_EYEUEPB9fZdspeeU0CtMbmLNhl7S82MNRZIZodXo=.7a17d0a2-ac4d-47f5-98fb-c451afa59374@github.com>

> DataOutputStream is very slow post-disabling of Biased Locking. This
> was discovered when benchmarking a transaction library, which showed
> significant performance loss when moving to JDK 15. WIth some small
> changes to DataOutputStream we can get the performance back. There's a
> JMH benchmark at
> http://cr.openjdk.java.net/~aph/JDK-8254078/jmh-tests.tar
> 
> Some Stream classes use very fine-grained locking.
> 
> In particular, writeInt is defined like this:
> 
>         out.write((v >>> 24) & 0xFF);
>         out.write((v >>> 16) & 0xFF);
>         out.write((v >>> 8) & 0xFF);
>         out.write((v >>> 0) & 0xFF);
>         incCount(4);
> 
> Unfortunately, ByteArrayOutputStream.write(byte) is defined like this:
> 
>     public synchronized void write(int b) {
>         ensureCapacity(count + 1);
>         buf[count] = (byte) b;
>         count += 1;
>     }
> 
> so we acquire and release a lock for every byte that is output.
> 
>  For example, writing 4kb of ints goes from 17.3 us/op to 53.9 us/op when biased locking is disabled:
> 
> 
> +UseBiasedLocking DataOutputStreamTest.dataOutputStreamOverByteArray avgt 6 53.895 ? 5.126 us/op
> -UseBiasedLocking DataOutputStreamTest.dataOutputStreamOverByteArray avgt 6 17.291 ? 4.430 us/op
> 
> There are refactorings of DataOutputStream we can do to mitigate this.

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

  8254078: DataOutputStream is very slow post-disabling of Biased Locking

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/542/files
  - new: https://git.openjdk.java.net/jdk/pull/542/files/e661c65e..8379b4f3

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

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

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

From aph at openjdk.java.net  Wed Oct  7 17:26:27 2020
From: aph at openjdk.java.net (Andrew Haley)
Date: Wed, 7 Oct 2020 17:26:27 GMT
Subject: RFR: 8254078: DataOutputStream is very slow post-disabling of
 Biased Locking [v2]
In-Reply-To: <d6QrBzqY9nhrw2And1H0tXeLuEqfubKjj1a3cf3WU04=.4521e9b5-8bc8-4d3e-909a-423f698dd2f2@github.com>
References: <lLg_yNI_6LvUZTlM4PyN5ra6AaUZZeT35QzYzV_0CpI=.f2d3cb9e-be30-40dc-922c-dad5bef7feea@github.com>
 <EJKoky6UZ4pMtxqQvIQJe7PmczwtTPcKY0wU0nX96aQ=.0bcda955-9e05-4d4a-9fcc-88b49aa7482f@github.com>
 <_FCkRwF2zWuesLEx-i6wMCS2QLqI-u_eL9gL8rw_Dl0=.bfcda732-80e4-4bc8-ab41-d31a7a26e538@github.com>
 <VBOCfFp_FB3lUbo5Hdr_Ax_vOoiFaV8GsEbfcTOSYtw=.a6d0d2c8-8ab0-4d4e-9c37-f9249188e288@github.com>
 <6jvxOF9XtUANIvKjvwm1ITdmpZc9XKO0xtxDsdcxrdc=.308f5106-cc24-4823-a284-4b3ba7563fc5@github.com>
 <d6QrBzqY9nhrw2And1H0tXeLuEqfubKjj1a3cf3WU04=.4521e9b5-8bc8-4d3e-909a-423f698dd2f2@github.com>
Message-ID: <odgiBzPvz0C0ceQqZ154Aiv8Tt45WC-SFyJl6ENDyfI=.dba9f8d9-8763-4c11-9094-0fa4cee6e89f@github.com>

On Wed, 7 Oct 2020 15:27:00 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>>> It might be helpful to add a statement to the DataOutputStream class description to say that it not safe for by
>>> concurrent threads and it needs appropriate synchronization to coordinate multiple writers. This issue or another issue
>>> doesn't matter.
>> 
>> I see.
>> 
>>> Can the benchmark be turned into a microbenchmark for test/micro?
>> 
>> Now there's an interesting question. I can tweak the benchmark (which at present contains a modified version of
>> DataOutputSteam, so can compare and contrast) so that it measures only the performance of the core library's
>> implementation. Does that make sense? If so, I can add it to this PR.
>
> The benchmark can be run with different JDKs, so the modified DOS can be omitted.

It turns out that DataInputStream already has a comment about thread safety being the user's problem, so I copied that
comment to DataOutputStream.

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

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

From mcimadamore at openjdk.java.net  Wed Oct  7 17:30:38 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 7 Oct 2020 17:30:38 GMT
Subject: RFR: 8254162: Implementation of Foreign-Memory Access API (Third
 Incubator)
Message-ID: <IngRk57F78UN3yySfo6IABbdwnMogGNdYrykh_3em-c=.b81f7478-015c-45ed-9788-58d7519a2770@github.com>

This patch contains the changes associated with the third incubation round of the foreign memory access API incubation
(see JEP 393 [1]). This iteration focus on improving the usability of the API in 3 main ways:

* first, by providing a way to obtain truly *shared* segments, which can be accessed and closed concurrently from
  multiple threads
* second, by providing a way to register a memory segment against a `Cleaner`, so as to have some (optional) guarantee
  that the memory will be deallocated, eventually
* third, by not requiring users to dive deep into var handles when they first pick up the API; a new `MemoryAccess` class
  has been added, which defines several useful dereference routines; these are really just thin wrappers around memory
  access var handles, but they make the barrier of entry for using this API somewhat lower.

A big conceptual shift that comes with this API refresh is that the role of `MemorySegment` and `MemoryAddress` is not
the same as it used to be; it used to be the case that a memory address could (sometimes, not always) have a back link
to the memory segment which originated it; additionally, memory access var handles used `MemoryAddress` as a basic unit
of dereference.

This has all changed as per this API refresh;  now a `MemoryAddress` is just a dumb carrier which wraps a pair of
object/long addressing coordinates; `MemorySegment` has become the star of the show, as far as dereferencing memory is
concerned. You cannot dereference memory if you don't have a segment. This improves usability in a number of ways -
first, it is a lot easier to wrap native addresses (`long`, essentially) into a `MemoryAddress`; secondly, it is
crystal clear what a client has to do in order to dereference memory: if a client has a segment, it can use that;
otherwise, if the client only has an address, it will have to create a segment *unsafely* (this can be done by calling
`MemoryAddress::asSegmentRestricted`).

A list of the API, implementation and test changes is provided below. If  you have any questions, or need more detailed
explanations, I (and the  rest of the Panama team) will be happy to point at existing discussions,  and/or to provide
the feedback required.

A big thank to Erik Osterlund, Vladimir Ivanov and David Holmes, without whom the work on shared memory segment would
not have been possible; also I'd like to thank Paul Sandoz, whose insights on API design have been very helpful in this
journey.

Thanks
Maurizio

Javadoc:

http://cr.openjdk.java.net/~mcimadamore/8254162_v1/javadoc/jdk/incubator/foreign/package-summary.html

Specdiff:

http://cr.openjdk.java.net/~mcimadamore/8254162_v1/specdiff/jdk/incubator/foreign/package-summary.html

CSR:

https://bugs.openjdk.java.net/browse/JDK-8254163



### API Changes

* `MemorySegment`
  * drop factory for restricted segment (this has been moved to `MemoryAddress`, see below)
  * added a no-arg factory for a native restricted segment representing entire native heap
  * rename `withOwnerThread` to `handoff`
  * add new `share` method, to create shared segments
  * add new `registerCleaner` method, to register a segment against a cleaner
  * add more helpers to create arrays from a segment e.g. `toIntArray`
  * add some `asSlice` overloads (to make up for the fact that now segments are more frequently used as cursors)
  * rename `baseAddress` to `address` (so that `MemorySegment` can implement `Addressable`)
* `MemoryAddress`
  * drop `segment` accessor
  * drop `rebase` method and replace it with `segmentOffset` which returns the offset (a `long`) of this address relative
    to a given segment
* `MemoryAccess`
  * New class supporting several static dereference helpers; the helpers are organized by carrier and access mode, where a
    carrier is one of the usual suspect (a Java primitive, minus `boolean`); the access mode can be simple (e.g. access
    base address of given segment), or indexed, in which case the accessor takes a segment and either a low-level byte
    offset,or a high level logical index. The classification is reflected in the naming scheme (e.g. `getByte` vs.
    `getByteAtOffset` vs `getByteAtIndex`).
* `MemoryHandles`
  * drop `withOffset` combinator
  * drop `withStride` combinator
  * the basic memory access handle factory now returns a var handle which takes a `MemorySegment` and a `long` - from which
    it is easy to derive all the other handles using plain var handle combinators.
* `Addressable`
  * This is a new interface which is attached to entities which can be projected to a `MemoryAddress`. For now, both
    `MemoryAddress` and `MemorySegment` implement it; we have plans, with JEP 389 [2] to add more implementations. Clients
    can largely ignore this interface, which comes in really handy when defining native bindings with tools like `jextract`.
* `MemoryLayouts`
  * A new layout, for machine addresses, has been added to the mix.



### Implementation changes

There are two main things to discuss here: support for shared segments, and the general simplification of the memory
access var handle support.

#### Shared segments

The support for shared segments cuts in pretty deep in the VM. Support for shared segments is notoriously hard to
achieve, at least in a way that guarantees optimal access performances. This is caused by the fact that, if a segment
is shared, it would be possible for a thread to close it while another is accessing it.

After considering several options (see [3]), we zeroed onto an approach which is inspired by an happy idea that Andrew
Haley had (and that he reminded me of at this year OpenJDK committer workshop - thanks!). The idea is that if we
could *freeze* the world (e.g. with a GC pause), while a segment is closed, we could then prevent segments from being
accessed concurrently to a close operation. For this to work, it  is crucial that no GC safepoints can occur between a
segment liveness check and the access itself (otherwise it would be possible for the accessing thread to stop just
right before an unsafe call). It also relies on the fact that hotspot/C2 should not be able to propagate loads across
safepoints.

Sadly, none of these conditions seems to be valid in the current implementation, so we needed to resort to a bit of
creativity. First, we noted that, if we could mark so called *scoped* method with an annotation, it would be very
simply to check as to whether a thread was in the middle of a scoped method when we stopped the world for a close
operation (btw, instead of stopping the world, we do a much more efficient, thread-local polling, thanks to JEP 312
[4]).

The question is, then, once we detect that a thread is accessing the very segment we're about to close, what should
happen? We first experimented with a solution which would install an *asynchronous* exception on the accessing thread,
thus making it fail. This solution has some desirable properties, in that a `close` operation always succeeds.
Unfortunately the machinery for async exceptions is a bit fragile (e.g. not all the code in hotspot checks for async
exceptions); to minimize risks, we decided to revert to a simpler strategy, where `close` might fail when it finds that
another thread is accessing the segment being closed.

As written in the javadoc, this doesn't mean that clients should just catch and try again; an exception on `close` is a
bug in the user code, likely arising from lack of synchronization, and should be treated as such.

In terms of gritty implementation, we needed to centralize memory access routines in a single place, so that we could
have a set of routines closely mimicking the primitives exposed by `Unsafe` but which, in addition, also provided a
liveness check. This way we could mark all these routines with the special `@Scoped` annotation, which tells the VM
that something important is going on.

To achieve this, we created a new (autogenerated) class, called `ScopedMemoryAccess`. This class contains all the main
memory access primitives (including bulk access, like `copyMemory`, or `setMemory`), and accepts, in addition to the
access coordinates, also a scope object, which is tested before access. A reachability fence is also thrown in the mix
to make sure that the scope is kept alive during access (which is important when registering segments against cleaners).

Of course, to make memory access safe, memory access var handles, byte buffer var handles, and byte buffer API should
use the new `ScopedMemoryAccess` class instead of unsafe, so that a liveness check can be triggered (in case a scope is
present).

`ScopedMemoryAccess` has a `closeScope` method, which initiates the thread-local handshakes, and returns `true` if the
handshake completed successfully.

The implementation of `MemoryScope` (now significantly simplified from what we had before), has two implementations,
one for confined segments and one for shared segments; the main difference between the two is what happens when the
scope is closed; a confined segment sets a boolean flag to false, and returns, whereas a shared segment goes into a
`CLOSING` state, then starts the handshake, and then updates the state again, to either `CLOSED` or `ALIVE` depending
on whether the handshake was successful or not. Note that when a shared segment is in the `CLOSING` state,
`MemorySegment::isAlive` will still return `true`, while the liveness check upon memory access will fail.

#### Memory access var handles overhaul

The key realization here was that if all memory access var handles took a coordinate pair of `MemorySegment` and
`long`, all other access types could be derived from this basic var handle form.

This allowed us to remove the on-the-fly var handle generation, and to simply derive structural access var handles
(such as those obtained by calling `MemoryLayout::varHandle`) using *plain* var handle combinators, so that e.g.
additional offset is injected into a base memory access var handle.

This also helped in simplifying the implementation by removing the special `withStride` and `withOffset` combinators,
which previously needed low-level access on the innards of the memory access var handle. All that code is now gone.

#### Test changes

Not much to see here - most of the tests needed to be updated because of the API changes. Some were beefed up (like the
array test, since now segments can be projected into many different kinds of arrays). A test has been added to test the
`Cleaner` functionality, and another stress test has been added for shared segments (`TestHandshake`). Some of the
microbenchmarks also needed some tweaks - and some of them were also updated to also test performance in the shared
segment case.

[1] - https://openjdk.java.net/jeps/393
[2] - https://openjdk.java.net/jeps/389
[3] - https://mail.openjdk.java.net/pipermail/panama-dev/2020-May/009004.html
[4] - https://openjdk.java.net/jeps/312

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

Commit messages:
 - Add modified files
 - RFR 8254162: Implementation of Foreign-Memory Access API (Third Incubator)

Changes: https://git.openjdk.java.net/jdk/pull/548/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=548&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8254162
  Stats: 7467 lines in 75 files changed: 5024 ins; 1373 del; 1070 mod
  Patch: https://git.openjdk.java.net/jdk/pull/548.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/548/head:pull/548

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

From github.com+51754783+coreyashford at openjdk.java.net  Wed Oct  7 17:52:16 2020
From: github.com+51754783+coreyashford at openjdk.java.net (CoreyAshford)
Date: Wed, 7 Oct 2020 17:52:16 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v2]
In-Reply-To: <kTmpe-MW1ZakMcKsESnDEQoImN7wNvbMne6Z9MuIbGE=.e0546e01-0951-477f-a67c-8443fcf2997d@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <6P-wrlA7c9wlXEhcoAYW5J9W2jwTmTTj3PkDObPh0LA=.c11aa048-8853-4e1c-a689-c34b89c15f12@github.com>
 <kTmpe-MW1ZakMcKsESnDEQoImN7wNvbMne6Z9MuIbGE=.e0546e01-0951-477f-a67c-8443fcf2997d@github.com>
Message-ID: <G3ANouwFzck1xuZZcT56qxH9fgXrJkhoGP0mr6MHNVI=.39ae1148-e607-467c-92d1-f8c96be73fdb@github.com>

On Wed, 7 Oct 2020 15:48:37 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> CoreyAshford has updated the pull request with a new target base due to a merge or a rebase. The pull request now
>> contains ten commits:
>>  - AOT: Revert change to aotCodeHeap.cpp for decodeBlock
>>    
>>    Don't add the SET_AOT_GLOBAL_SYMBOL_VALUE macro for decode block until all
>>    arches that implement AOT, implement the decodeBlock intrinsic.
>>  - Base64.java decodeBlock: Changes from PR review
>>    
>>     * Make comparison safer and consistent with the while loop
>>     * Update comment about the decodeBlock intrinsic so that it matches the new structure
>>     * Add comment about the lack of a length check on the destination buffer
>>     * As per issue 8138732, change HotSpotIntrinsicCandidate to IntrinsicCandidate
>>  - stubGenerator_ppc.cpp: Changes from PR review
>>    
>>     * Fix clearing of upper bits to clear 32 bits instead of 31 (due to misreading of clrldi instruction)
>>     * change and document loop_unrolls setting from 8 to 2 after re-running the benchmark
>>     * align unrolled loop on a 32-byte boundary
>>     * replace instruction used for checking isURL from a double word to single
>>       word instruction since the register is effectively 32 bits wide
>>     * cosmetic change to realign register comments.
>>  - TestBase64.java: Changes from PR review
>>    
>>     * Use Utils.toByteArrays() method instead of a locally-defined method
>>     * Generate the two non-Base64 tables dynamically rather than use static initialization
>>     * Added comments describing the two above-mentioned arrays
>>  - Expand the Base64 intrinsic regression test to cover decodeBlock
>>    
>>    This patch makes four significant changes:
>>    
>>    1) The Power implementation of the decodeBlock intrinsic, at least,
>>    requires a decode length of at least 128 bytes, but the existing test cases
>>    are much shorter, maxing out at 111 bytes.  So the patch adds a new input
>>    data file which has longer test cases in it.
>>    
>>    2) The original test cases only covers the encoding of just the printable
>>    subset of the 7-bit ASCII characters.  However, Base64 encoding requires
>>    being able to encode arbitrary binary data, i.e. it must handle all 256
>>    8-bit byte encodings.  To remedy this, but keep the original line-oriented
>>    style of the input data, I added another input file type that uses a simple
>>    ASCII hexadecimal encoding - two ASCII hex characters per 8-bit byte.  When
>>    test0 is called, a new parameter is passed that specifies the type of the
>>    input file, which is either the original ASCII type or the hexadecimal
>>    format.  So to test both longer input data and arbitrary 8-bit data, the
>>    newly added input test file has test cases which are both longer and
>>    encoded in ASCII hex so as to give full 8-bit capability.  When reading
>>    this type of file, test0 calls a newly-added function to translate the
>>    ASCII hex to binary data.  Except for the first line of input data, which
>>    contains all possible 8-bit values sequentially, the input data was
>>    generated using a random length (between 111 and 520 bytes) buffer filled
>>    with random 8-bit data, which should give adequate coverage.
>>    
>>    3) The original test did not test that the decoder detects illegal Base64
>>    bytes.  This change chooses a random location in the encoded data to
>>    corrupt with a randomly-chosen byte which is illegal for the specific
>>    Base64 encoding that is chosen (i.e. standard or URLsafe).  It then calls
>>    the decode function to verify that the illegal byte is detected and the
>>    proper exception is thrown.
>>    
>>    4) The test iteration count was originally 100K, but that is far more than
>>    enough iterations to test the intrinsic.  It takes 20K iterations on each
>>    instrinsic for HotSpot C2 to begin calling it.  The test originally had
>>    three types of encodings to test and called the encode intrinsic four times
>>    for each iteration, which works out to 100K * 3 * 4 = 1.2M calls just to
>>    encode.  Decode was called four times as well (now five because of the
>>    illegal byte test).  I believe this is excessive and with the extra test
>>    data I have added, the test was timing out after ten minutes of execution.
>>    It appears that it is timing out, not because the intrinsics take a long
>>    time to run, but because test0 generates an enormous number of discarded
>>    data buffers for the GC system to recover (the test runs at about 39GB of
>>    virtual memory on my test machine).  To remedy the timeout problem, I have
>>    changed the code so that a warmup function of 20K repetitions is performed
>>    on a fixed buffer, to activate the instrinsic(s).  After the warmup, I have
>>    reduced the number of iterations to 5K on each test0 call.  This should
>>    give adequate coverage.
>>  - Add JMH benchmark for Base64 variable length buffer decoding
>>  - Add Power9+ intrinsic implementation for Base64 decoding
>>  - Add HotSpot code to implement Base64 decodeBlock API
>>  - Add HotSpotIntrinsicCandidate and API for Base64 decoding
>
> test/hotspot/jtreg/compiler/intrinsics/base64/TestBase64.java line 89:
> 
>> 87:         ran.nextBytes(srcBuf);
>> 88:
>> 89:         // This should be enough to get both the decoder and encoder intrinsic loaded up and running.
> 
> Better: ... get encode() and decode() compiled on highest tier.

Thanks.  I'm still learning the lingo :)  Will fix.

> src/hotspot/cpu/ppc/stubGenerator_ppc.cpp line 3812:
> 
>> 3810:     // Address of the last byte of the source is (in + sl - 1)
>> 3811:     __ add(end, in, sl);
>> 3812:     __ subi(end, end, 1);
> 
> Looks a bit complicated, but ok. I'd have loaded the number of iterations into ctr and used bdnz instruction for the
> loop. (bdz / bdnz may also be slighly faster depending on the CPU implementation.)

I agree that a count would be preferable, because it's easier to read.  Will fix.

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

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

From github.com+51754783+coreyashford at openjdk.java.net  Wed Oct  7 17:52:16 2020
From: github.com+51754783+coreyashford at openjdk.java.net (CoreyAshford)
Date: Wed, 7 Oct 2020 17:52:16 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v2]
In-Reply-To: <eeX_BLBKC1ubNxaDyzQ34EubuaIklTcEZ08nThdLkT8=.0c07596d-982a-4bec-bf8d-c776ecd34e93@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <6P-wrlA7c9wlXEhcoAYW5J9W2jwTmTTj3PkDObPh0LA=.c11aa048-8853-4e1c-a689-c34b89c15f12@github.com>
 <r5FtoUonRPCmhZ7ueswqkgh9pTwoA4rYrrpfVIO1zBE=.2917dc6c-d288-4ea4-b958-e6021025b9e5@github.com>
 <eeX_BLBKC1ubNxaDyzQ34EubuaIklTcEZ08nThdLkT8=.0c07596d-982a-4bec-bf8d-c776ecd34e93@github.com>
Message-ID: <ZTaNq9Hg1Mqrz2DjqY7mD33YycROZDE-LOatAYClqTM=.034ba6ee-eb96-4938-a82e-500e974bcf5a@github.com>

On Wed, 7 Oct 2020 17:19:50 GMT, CoreyAshford <github.com+51754783+CoreyAshford at openjdk.org> wrote:

>> src/hotspot/share/opto/library_call.cpp line 310:
>> 
>>> 308:   bool inline_base64_decodeBlock();
>>> 309:   bool inline_digestBase_implCompress(vmIntrinsics::ID id);
>>> 310:   bool inline_sha_implCompress(vmIntrinsics::ID id);
>> 
>> Why is that in this change?
>
> Good catch!  I'm not sure what happened there.  Will investigate.

This seems to be a mistake I made during a rebase with a conflict. Will fix.

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

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

From rrich at openjdk.java.net  Wed Oct  7 17:52:27 2020
From: rrich at openjdk.java.net (Richard Reingruber)
Date: Wed, 7 Oct 2020 17:52:27 GMT
Subject: RFR: 8227745: Enable Escape Analysis for Better Performance in
 the Presence of JVMTI Agents [v7]
In-Reply-To: <Ll2RereRbuQLgFtIjv9pS92kPvCVuo-BI0cP1zGjVbo=.dad3a33c-0fc3-44fd-810a-f01448cf564c@github.com>
References: <Ll2RereRbuQLgFtIjv9pS92kPvCVuo-BI0cP1zGjVbo=.dad3a33c-0fc3-44fd-810a-f01448cf564c@github.com>
Message-ID: <6Scp6XjVCcdJN0tUKionVwGKoiBG8UeA-OpBXHrCYqk=.01170b1e-9722-4461-84e4-77e8fd447ac4@github.com>

> Hi,
> 
> this is the continuation of the review of the implementation for:
> 
> https://bugs.openjdk.java.net/browse/JDK-8227745
> https://bugs.openjdk.java.net/browse/JDK-8233915
> 
> It allows for JIT optimizations based on escape analysis even if JVMTI agents acquire capabilities to access references
> to objects that are subject to such optimizations, e.g. scalar replacement. The implementation reverts such
> optimizations just before access very much as when switching from JIT compiled execution to the interpreter, aka
> "deoptimization".  Webrev.8 was the last one before before the transition to Git/Github:
> 
> http://cr.openjdk.java.net/~rrich/webrevs/8227745/webrev.8/
> 
> Thanks, Richard.

Richard Reingruber has updated the pull request incrementally with five additional commits since the last revision:

 - Factorized fragment out of EscapeBarrier::deoptimize_objects_internal into new method in compiledVFrame.
 - More smaller changes proposed by Serguei.
 - jvmtiDeferredUpdates.hpp: remove forward declarations.
 - jvmtiDeferredLocalVariable: move member variables to the beginning of the class definition.
 - jvmtiDeferredUpdates.hpp: add/remove empty lines and improve indentation.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/119/files
  - new: https://git.openjdk.java.net/jdk/pull/119/files/1c586cfb..03f751eb

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

  Stats: 183 lines in 7 files changed: 93 ins; 66 del; 24 mod
  Patch: https://git.openjdk.java.net/jdk/pull/119.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/119/head:pull/119

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

From rrich at openjdk.java.net  Wed Oct  7 17:55:11 2020
From: rrich at openjdk.java.net (Richard Reingruber)
Date: Wed, 7 Oct 2020 17:55:11 GMT
Subject: RFR: 8227745: Enable Escape Analysis for Better Performance in
 the Presence of JVMTI Agents [v3]
In-Reply-To: <ku12sbw0RalOiY9-0UzhjsM97LFWLyW13GecYR0p1fc=.81bbd251-a72f-45e6-9adb-aba6e6d2fa05@github.com>
References: <Ll2RereRbuQLgFtIjv9pS92kPvCVuo-BI0cP1zGjVbo=.dad3a33c-0fc3-44fd-810a-f01448cf564c@github.com>
 <D80z7im-ptE_UXYRfivkezq-W4ZuWkPwKOoT0MW1mxA=.676cae36-4e0f-473d-b577-21317f3c3ab3@github.com>
 <Pz8cdgFTXmF954txrAnk3whnhkeR2y6gTNiSTRC_CrY=.e3460eb4-d1dc-4621-b056-b0a46f4f6569@github.com>
 <i5Y6k8vBZUKKUCrUkaR8ux26ZBgy80UziZj0p2lYUuo=.e368568c-bbc8-4c63-bd23-847e7e008946@github.com>
 <ayyzITSxaqlsU0Ch0uLnooOLlr_Xn8dXRQHGLY3Qy40=.b2589ff3-a00f-44ed-973b-2087a35b542c@github.com>
 <HYavlFjjBvmmW2N-aWpAUX10tS-cnZrjLhPccnWfQ7w=.9e7ad979-7b1c-43db-943d-f273c747ab8f@github.com>
 <ku12sbw0RalOiY9-0UzhjsM97LFWLyW13GecYR0p1fc=.81bbd251-a72f-45e6-9adb-aba6e6d2fa05@github.com>
Message-ID: <vCBclHZn2engXF9-okRqmR9m-AYDVvRLU5T15qgs9Ws=.0af4623e-429b-4aaa-8e80-ef7ef2de7870@github.com>

On Wed, 7 Oct 2020 04:28:16 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Hi Serguei
>> (@sspitsyn)
>> 
>> are you ok with the changes I made based on your comments?
>> Will you further review the change?
>> 
>> Thanks, Richard.
>
> Hi Richard,
> 
> Thank you for making the refactoring. I like it more now. :)
> So, the fix looks good to me in general.
> 
> But could I ask you, to adjust some formatting, please?
> There are several things that can be done to improve the code readability.
> 
> src/hotspot/share/prims/jvmtiDeferredUpdates.hpp:
> 
> I'd suggest to add an empty line before lines 40, 71, 73, 93, 95, 109 to make class definitions and function
> declarations/definitions with comments more catchable by eyes. The following lines can be removed: 81, 82, 103
> 
> Also, there is inconsistency in function definitions formatting:
>  - some functions have big indent between the type and name
>  - some functions have no indent between the type and name but a big indent between name and body
> I'd suggest to either to remove all indents or make it reasonably smaller but consistent.
> 
> It seems, there is no reason to keep these class declarations:
>  38 class jvmtiDeferredLocalVariable;
> 108 class jvmtiDeferredLocalVariableSet;
> 
> src/hotspot/share/prims/jvmtiDeferredUpdates.cpp:
> 
>  82       // Free deferred updates.
>  83       // (Note the 'list' of local variable updates is embedded in 'updates')
> 
> A suggestion to change the line 83 as follows:
> ` 83       // Note, the 'list' of local variable updates is embedded in 'updates'.`
> 
> src/hotspot/share/runtime/escapeBarrier.hpp:
> 
> Add dots at the end of comments at lines 97, 99, 103.
> I'd suggest to add an empty line before lines 39, 40, 80, 81, 93, 94, 99, 119, 121.
> 
> src/hotspot/share/runtime/escapeBarrier.cpp:
> 
> The following class declaration is not needed:
> ` 49 class jvmtiDeferredLocalVariableSet;`
> 
> because you already added this line:
> ` 29 #include "prims/jvmtiDeferredUpdates.hpp"`
> 
> The lines below deserve a refactoring. It can be separate functions for locals, expressions and monitors, or just one
> function for the whole fragment:
> 345         GrowableArray* scopeLocals = cvf->scope()->locals();
> 346         StackValueCollection* locals = cvf->locals();
> 347         if (locals != NULL) {
> 348           for (int i2 = 0; i2 < locals->size(); i2++) {
> 349             StackValue* var = locals->at(i2);
> 350             if (var->type() == T_OBJECT && scopeLocals->at(i2)->is_object()) {
> 351               jvalue val;
> 352               val.l = cast_from_oop(locals->at(i2)->get_obj()());
> 353               cvf->update_local(T_OBJECT, i2, val);
> 354             }
> 355           }
> 356         }
> 357
> 358         // expressions
> 359         GrowableArray* scopeExpressions = cvf->scope()->expressions();
> 360         StackValueCollection* expressions = cvf->expressions();
> 361         if (expressions != NULL) {
> 362           for (int i2 = 0; i2 < expressions->size(); i2++) {
> 363             StackValue* var = expressions->at(i2);
> 364             if (var->type() == T_OBJECT && scopeExpressions->at(i2)->is_object()) {
> 365               jvalue val;
> 366               val.l = cast_from_oop(expressions->at(i2)->get_obj()());
> 367               cvf->update_stack(T_OBJECT, i2, val);
> 368             }
> 369           }
> 370         }
> 371
> 372         // monitors
> 373         GrowableArray* monitors = cvf->monitors();
> 374         if (monitors != NULL) {
> 375           for (int i2 = 0; i2 < monitors->length(); i2++) {
> 376             if (monitors->at(i2)->eliminated()) {
> 377               assert(!monitors->at(i2)->owner_is_scalar_replaced(),
> 378                      "reallocation failure, should not update");
> 379               cvf->update_monitor(i2, monitors->at(i2));
> 380             }
> 381           }
> 382         }
> 
> 
> src/hotspot/share/prims/jvmtiImpl.cpp:
> 
>  420 // Constructor for non-object getter
>  421 VM_GetOrSetLocal::VM_GetOrSetLocal(JavaThread* thread, jint depth, jint index, BasicType type)
>  422   : _thread(thread)
>  423   , _calling_thread(NULL)
>  424   , _depth(depth)
>  425   , _index(index)
>  426   , _type(type)
>  427   , _jvf(NULL)
>  428   , _set(false)
>  429   , _eb(type == T_OBJECT, NULL, NULL)
>  430   , _result(JVMTI_ERROR_NONE)
>  431 {
>  432 }
> 
> I still think, that the line 429 is going to cause confusions.
> It is a non-object getter, so the type should never be T_OBJECT.
> It won't change in the future to allow the T_OBJECT types.
> The only way to allow it is to merge the constructors for object and non-object getters.
> So, I'm suggesting to replace this line with:
> ` 429   , _eb(false, NULL, NULL)`

Hi Serguei,

> Thank you for making the refactoring. I like it more now. :)
> So, the fix looks good to me in general.

Good :)

> But could I ask you, to adjust some formatting, please?
> There are several things that can be done to improve the code readability.
> 
> src/hotspot/share/prims/jvmtiDeferredUpdates.hpp:
> 
> I'd suggest to add an empty line before lines 40, 71, 73, 93, 95, 109 to make class definitions and function
> declarations/definitions with comments more catchable by eyes. The following lines can be removed: 81, 82, 103

Sure. I've made the changes.

> Also, there is inconsistency in function definitions formatting:
> 
>     * some functions have big indent between the type and name
> 
>     * some functions have no indent between the type and name but a big indent between name and body
>       I'd suggest to either to remove all indents or make it reasonably smaller but consistent.
> 

I've made the indents smaller. I also moved private members
jvmtiDeferredLocalVariable at the beginning. Looks better now.

> It seems, there is no reason to keep these class declarations:
> 
> ```
>  38 class jvmtiDeferredLocalVariable;
> 108 class jvmtiDeferredLocalVariableSet;
> ```

Removed.

> src/hotspot/share/prims/jvmtiDeferredUpdates.cpp:
> 
> ```
>  82       // Free deferred updates.
>  83       // (Note the 'list' of local variable updates is embedded in 'updates')
> ```
> 
> A suggestion to change the line 83 as follows:
> ` 83 // Note, the 'list' of local variable updates is embedded in 'updates'.`

Done.

> src/hotspot/share/runtime/escapeBarrier.hpp:
> 
> Add dots at the end of comments at lines 97, 99, 103.
> I'd suggest to add an empty line before lines 39, 40, 80, 81, 93, 94, 99, 119, 121.

Done.

> src/hotspot/share/runtime/escapeBarrier.cpp:
> 
> The following class declaration is not needed:
> ` 49 class jvmtiDeferredLocalVariableSet;`
> 
> because you already added this line:
> ` 29 #include "prims/jvmtiDeferredUpdates.hpp"`

Your right. Thanks.

> The lines below deserve a refactoring. It can be separate functions for locals, expressions and monitors, or just one
> function for the whole fragment:
> ```
> 345         GrowableArray* scopeLocals = cvf->scope()->locals();
> 346         StackValueCollection* locals = cvf->locals();
> 347         if (locals != NULL) {
> 348           for (int i2 = 0; i2 < locals->size(); i2++) {
> 349             StackValue* var = locals->at(i2);
> 350             if (var->type() == T_OBJECT && scopeLocals->at(i2)->is_object()) {
> 351               jvalue val;
> 352               val.l = cast_from_oop(locals->at(i2)->get_obj()());
> 353               cvf->update_local(T_OBJECT, i2, val);
> 354             }
> 355           }
> 356         }
> 357
> 358         // expressions
> 359         GrowableArray* scopeExpressions = cvf->scope()->expressions();
> 360         StackValueCollection* expressions = cvf->expressions();
> 361         if (expressions != NULL) {
> 362           for (int i2 = 0; i2 < expressions->size(); i2++) {
> 363             StackValue* var = expressions->at(i2);
> 364             if (var->type() == T_OBJECT && scopeExpressions->at(i2)->is_object()) {
> 365               jvalue val;
> 366               val.l = cast_from_oop(expressions->at(i2)->get_obj()());
> 367               cvf->update_stack(T_OBJECT, i2, val);
> 368             }
> 369           }
> 370         }
> 371
> 372         // monitors
> 373         GrowableArray* monitors = cvf->monitors();
> 374         if (monitors != NULL) {
> 375           for (int i2 = 0; i2 < monitors->length(); i2++) {
> 376             if (monitors->at(i2)->eliminated()) {
> 377               assert(!monitors->at(i2)->owner_is_scalar_replaced(),
> 378                      "reallocation failure, should not update");
> 379               cvf->update_monitor(i2, monitors->at(i2));
> 380             }
> 381           }
> 382         }
> ```

I moved the fragment into a new method in compiledVFrame.

Please note that an equal fragment exists here too:
https://github.com/openjdk/jdk/blob/1e8e543b264bb985bfee535fedc9ffe7db5ad482/src/hotspot/share/jvmci/jvmciCompilerToVM.cpp#L1524-L1558

Actually this location could be implemented on top of EscapeBarrier. Maybe
(maybe not?) in a follow-up...

> src/hotspot/share/prims/jvmtiImpl.cpp:
> 
> ```
>  420 // Constructor for non-object getter
>  421 VM_GetOrSetLocal::VM_GetOrSetLocal(JavaThread* thread, jint depth, jint index, BasicType type)
>  422   : _thread(thread)
>  423   , _calling_thread(NULL)
>  424   , _depth(depth)
>  425   , _index(index)
>  426   , _type(type)
>  427   , _jvf(NULL)
>  428   , _set(false)
>  429   , _eb(type == T_OBJECT, NULL, NULL)
>  430   , _result(JVMTI_ERROR_NONE)
>  431 {
>  432 }
> ```
> 
> I still think, that the line 429 is going to cause confusions.
> It is a non-object getter, so the type should never be T_OBJECT.
> It won't change in the future to allow the T_OBJECT types.
> The only way to allow it is to merge the constructors for object and non-object getters.
> So, I'm suggesting to replace this line with:
> ` 429 , _eb(false, NULL, NULL)`

Ok, done.

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

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

From iklam at openjdk.java.net  Wed Oct  7 17:56:13 2020
From: iklam at openjdk.java.net (Ioi Lam)
Date: Wed, 7 Oct 2020 17:56:13 GMT
Subject: RFR: 8247536: Support for pre-generated java.lang.invoke classes
 in CDS static archive [v12]
In-Reply-To: <9emWKl6fr-GA5LN0uHhuEd5D123QcoCiHQR1M9bAbag=.cc4b6129-8b33-47e4-a421-9e6b4817933b@github.com>
References: <Y_Bas-poGnDtvcJbqbmeIAPQRNxzvarBToQWALn9TTE=.e846cd3c-0e7b-48d3-8ffa-be3c03acffb0@github.com>
 <9emWKl6fr-GA5LN0uHhuEd5D123QcoCiHQR1M9bAbag=.cc4b6129-8b33-47e4-a421-9e6b4817933b@github.com>
Message-ID: <kz0Xu1ovkOhMDnQTsen4WORb8dAs1zi5oPnF4f_rDJE=.7c40ebbd-5230-49f9-a370-d9eeae63378c@github.com>

On Tue, 6 Oct 2020 20:46:17 GMT, Yumin Qi <minqi at openjdk.org> wrote:

>> This patch is reorganized after 8252725, which is separated from this patch to refactor jlink glugin code. The previous
>> webrev with hg can be found at: http://cr.openjdk.java.net/~minqi/2020/8247536/webrev-05. With 8252725 integrated, the
>> regeneration of holder classes is simply to call the new added GenerateJLIClassesHelper.cdsGenerateHolderClasses
>> function.  Tests: tier1-4
>
> Yumin Qi has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains
> 23 commits:
>  - Added new separate function to CDS for logging species and modified the existing function to log lambda form invokers.
>    Changed isDumpLoadedClassList to a reasonable name isDumpingClassList as read only in CDS.
>  - Merge branch 'master' of https://github.com/openjdk/jdk into jdk-8247536
>  - Removed unused imports.
>  - Fixed comments with correct class and method name in CDS, removed unused variables after last change.
>  - Moved and renamed cdsGenerateHolderClasses from GenerateJLIClassesHelp to CDS as generateLambdaFormHolderClasses. Added
>    input verification function in CDS before class generation. Added more test scenarios. Removed trailing unused ending
>    words for output of lambda form trace line in case of DumpLoadedClassList.
>  - Move the check work to java, restore code in VM. Modified test code according to the changes. The invoke name
>    verififcation is not implemented since not all the holder class are processed, not all the functions of processed
>    holder classes are added. For holder class with DirectMethodHandle in its name, only the name in the
>    DMH_METHOD_TYPE_MAP keyset is added, ithe line with other names just gets skipped silently. This makes the verification
>    on invoke names difficul, a name not in the keyset should not fail the test. Also add a boolean to
>    cdsGenerateHolderClasses to indicate call path.
>  - Remove trailing word of line which is not used in holder class regeneration. There is a trailing LF (Line Feed) so trim
>    white spaces from both front and end of the line or it will fail method type validation.
>  - In case of exception happens during reloading class, CHECK will return without free the allocated buffer for class
>    bytes so moved the buffer allocation and freeing to caller. Also removed test 6 since there is not guarantee that we
>    can give a signature which will always fail. Additional changes to GenerateJLIClassesHelper according to review
>    suggestion.
>  - Merge branch 'master' of https://github.com/openjdk/jdk into jdk-8247536
>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into jdk-8247536
>  - ... and 13 more: https://git.openjdk.java.net/jdk/compare/82fe023b...f5584dcf

Marked as reviewed by iklam (Reviewer).

src/hotspot/share/classfile/lambdaFormInvokers.cpp line 133:

> 131:     log_info(cds)("Class %s not present, skip", name);
> 132:     return;
> 133:   }

`assert(klass->is_instance_klass(), "Should be");` should be after the NULL check of `klass`

src/hotspot/share/prims/jvm.cpp line 3872:

> 3870: JVM_ENTRY(jboolean, JVM_IsDumpingClassList(JNIEnv *env))
> 3871:   JVMWrapper("JVM_IsDumpingClassList");
> 3872:   return DumpLoadedClassList != NULL && classlist_file->is_open();

For sanity, it's better to add `classlist_file != NULL`

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

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

From github.com+2233919+douglea at openjdk.java.net  Wed Oct  7 18:00:15 2020
From: github.com+2233919+douglea at openjdk.java.net (DougLea)
Date: Wed, 7 Oct 2020 18:00:15 GMT
Subject: RFR: 8254146: Avoid unnecessary volatile write on new
 AtomicBoolean(false)
In-Reply-To: <tVJPFN5AhgLiPCNQbqVZTqTIoZXv6e86IhB4k8Ow-qc=.dcb90a28-b1fc-4a23-bfee-3d1c5c4627ac@github.com>
References: <AzWKluHZjvFYm2wUanwYfn91iKKMacpk_qSsje3tXWk=.ba873b46-4e12-4415-8832-fa314d6759a3@github.com>
 <yNUBzMyHr1Asbrtyt2sHQnGcJOxdfP8umMyRPC863Rw=.5c18ea25-bcf8-473b-a86a-fe764b8684d6@github.com>
 <P4lM3Rv3CAm7OqpNbLH3mvmgpVv0nVY1TeDw0VFy7jY=.54c361de-0133-4e10-ae04-12c79686e16a@github.com>
 <YCAn0HKEP0_EZcQUQLL1Xo3Ghw54zKq8ZGDT_A5daUo=.33924e26-7ef1-4395-95e3-9efa4005ca77@github.com>
 <NL9WtVFpAwsc6pG273abr_0N5_xThMwK5AKUVquNMsw=.9fe705eb-5689-4da8-913c-e39567f9bc67@github.com>
 <0R_DeYk8B1ky2fjZYUpz6xEv2exb-W4BdtU_Yu2B0wI=.c3008858-4469-4d2c-913f-2902ea686503@github.com>
 <tVJPFN5AhgLiPCNQbqVZTqTIoZXv6e86IhB4k8Ow-qc=.dcb90a28-b1fc-4a23-bfee-3d1c5c4627ac@github.com>
Message-ID: <oA2IZElACg1-dUgoeUQb5-cAy_Oertv6KpYCtDkdSSY=.2ed13959-8f4a-44e1-ad78-c764a3a83816@github.com>

On Wed, 7 Oct 2020 17:01:27 GMT, Christoph Dreis <github.com+6304496+dreis2211 at openjdk.org> wrote:

>> I'm a little hesitant about the precedent of checking for 0 in every ctor argument for a volatile field.
>> An alternative here worth measuring is: VALUE.setRelease(this, initialValue ? 1 : 0);
>
>> I'm a little hesitant about the precedent of checking for 0 in every ctor argument for a volatile field.
> 
> I'm confused by this if I'm entirely honest @DougLea . Where do we check for 0 in the proposed change?

As in: If unnecessarily writing 0 to a voltaile field in a ctor is expensive enough for a code work-around here, don't
you think it would be better to teach a compiler to avoid it?

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

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

From shade at openjdk.java.net  Wed Oct  7 18:12:20 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 7 Oct 2020 18:12:20 GMT
Subject: RFR: 8254102: use ProcessHandle::pid instead of
 ManagementFactory::getRuntimeMXBean to get pid in tests [v2]
In-Reply-To: <vet7-yMg6VAIeRcunhRUeUpLyCMEOmf2kwfRy02TRc8=.d8ba2027-5eb2-48ee-b7c5-259004508d8f@github.com>
References: <aQOzr1zN3WrL11gTkWFkGrkDVRxwQOrM8XbsMk6_0Cc=.42c65bd7-68bd-4bbb-9b30-ecbf01982332@github.com>
 <vet7-yMg6VAIeRcunhRUeUpLyCMEOmf2kwfRy02TRc8=.d8ba2027-5eb2-48ee-b7c5-259004508d8f@github.com>
Message-ID: <Pvts3a3dRxMG3fo7EnMImqzayKvkIoC7OQzByhbYhT8=.8ef9ba66-9520-48fa-9e6a-c3fc5cd53244@github.com>

On Wed, 7 Oct 2020 18:09:28 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

>> Hi all,
>> 
>> could you please review this small cleanup which replaces
>> `ManagementFactory.getRuntimeMXBean().getName().split("@")[0]` w/ `ProcessHandle.current().pid()` to get current
>> process pid?  Thanks,
>> -- Igor
>
> Igor Ignatyev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - use Long.toString instead of String.valueOf
>  - remove explicit coversion to String in Suicide.java

Still looks good to me.

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

Marked as reviewed by shade (Reviewer).

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

From iignatyev at openjdk.java.net  Wed Oct  7 18:12:19 2020
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Wed, 7 Oct 2020 18:12:19 GMT
Subject: RFR: 8254102: use ProcessHandle::pid instead of
 ManagementFactory::getRuntimeMXBean to get pid in tests [v2]
In-Reply-To: <aQOzr1zN3WrL11gTkWFkGrkDVRxwQOrM8XbsMk6_0Cc=.42c65bd7-68bd-4bbb-9b30-ecbf01982332@github.com>
References: <aQOzr1zN3WrL11gTkWFkGrkDVRxwQOrM8XbsMk6_0Cc=.42c65bd7-68bd-4bbb-9b30-ecbf01982332@github.com>
Message-ID: <vet7-yMg6VAIeRcunhRUeUpLyCMEOmf2kwfRy02TRc8=.d8ba2027-5eb2-48ee-b7c5-259004508d8f@github.com>

> Hi all,
> 
> could you please review this small cleanup which replaces
> `ManagementFactory.getRuntimeMXBean().getName().split("@")[0]` w/ `ProcessHandle.current().pid()` to get current
> process pid?  Thanks,
> -- Igor

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

 - use Long.toString instead of String.valueOf
 - remove explicit coversion to String in Suicide.java

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/534/files
  - new: https://git.openjdk.java.net/jdk/pull/534/files/b6f4b94a..bc6e3515

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

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

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

From iignatyev at openjdk.java.net  Wed Oct  7 18:12:20 2020
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Wed, 7 Oct 2020 18:12:20 GMT
Subject: RFR: 8254102: use ProcessHandle::pid instead of
 ManagementFactory::getRuntimeMXBean to get pid in tests [v2]
In-Reply-To: <aB8KNnFjtgaK8E-VF81brsQTMAE3G7FQFL-MJ8QcA8M=.87340971-3090-4577-801b-e69b80750149@github.com>
References: <aQOzr1zN3WrL11gTkWFkGrkDVRxwQOrM8XbsMk6_0Cc=.42c65bd7-68bd-4bbb-9b30-ecbf01982332@github.com>
 <5OaD6gBX9nmmX_N690gLnHefPo4bk9z3D-WqGwD3kXA=.32b936f9-c795-49c6-b158-90845eadcd45@github.com>
 <aB8KNnFjtgaK8E-VF81brsQTMAE3G7FQFL-MJ8QcA8M=.87340971-3090-4577-801b-e69b80750149@github.com>
Message-ID: <v1o5hrg73g5RNJjFbNC9DLxydQ_UI3_i-rfinamgllE=.4a99693d-cd4e-4237-b53e-1785bb93daa0@github.com>

On Wed, 7 Oct 2020 06:30:43 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> test/failure_handler/test/sanity/Suicide.java line 36:
>> 
>>> 34:             String osName = System.getProperty("os.name");
>>> 35:             if (osName.contains("Windows")) {
>>> 36:                 cmd = "taskkill.exe /F /PID " + pidStr;
>> 
>> This can be simplified to ProcessHandle.current().toString().  It returns the pid of the process as a string.
>> 
>> Explicitly converting it to a string is not necessary.  The "+" concatenation would convert the number to a string.
>
> Yes, can just have `long pid` in this case.
> 
> I don't see that `ProcessHandle.toString` is *specified* to return the string with pid, so relying on that is brittle.
> We might call `Long.toString` here directly, to avoid jumping through a few calls. But seeing how all this is a test
> code, that does not seem necessary.

@RogerRiggs , as Aleksey pointed out `ProcessHandle::toString` isn't specified to return the string which contains only
`pid` (in fact it's not specified at all), so I don't think we should rely on the current implementation.

although it doesn't matter much, I've removed explicit conversion here and replaced `String::valueOf` with
`Long::toString` in other places.

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

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

From github.com+6304496+dreis2211 at openjdk.java.net  Wed Oct  7 18:21:17 2020
From: github.com+6304496+dreis2211 at openjdk.java.net (Christoph Dreis)
Date: Wed, 7 Oct 2020 18:21:17 GMT
Subject: RFR: 8254146: Avoid unnecessary volatile write on new
 AtomicBoolean(false)
In-Reply-To: <oA2IZElACg1-dUgoeUQb5-cAy_Oertv6KpYCtDkdSSY=.2ed13959-8f4a-44e1-ad78-c764a3a83816@github.com>
References: <AzWKluHZjvFYm2wUanwYfn91iKKMacpk_qSsje3tXWk=.ba873b46-4e12-4415-8832-fa314d6759a3@github.com>
 <yNUBzMyHr1Asbrtyt2sHQnGcJOxdfP8umMyRPC863Rw=.5c18ea25-bcf8-473b-a86a-fe764b8684d6@github.com>
 <P4lM3Rv3CAm7OqpNbLH3mvmgpVv0nVY1TeDw0VFy7jY=.54c361de-0133-4e10-ae04-12c79686e16a@github.com>
 <YCAn0HKEP0_EZcQUQLL1Xo3Ghw54zKq8ZGDT_A5daUo=.33924e26-7ef1-4395-95e3-9efa4005ca77@github.com>
 <NL9WtVFpAwsc6pG273abr_0N5_xThMwK5AKUVquNMsw=.9fe705eb-5689-4da8-913c-e39567f9bc67@github.com>
 <0R_DeYk8B1ky2fjZYUpz6xEv2exb-W4BdtU_Yu2B0wI=.c3008858-4469-4d2c-913f-2902ea686503@github.com>
 <tVJPFN5AhgLiPCNQbqVZTqTIoZXv6e86IhB4k8Ow-qc=.dcb90a28-b1fc-4a23-bfee-3d1c5c4627ac@github.com>
 <oA2IZElACg1-dUgoeUQb5-cAy_Oertv6KpYCtDkdSSY=.2ed13959-8f4a-44e1-ad78-c764a3a83816@github.com>
Message-ID: <_0ZtGUqwXqvBx8GqFa5QsIra0-Olve8eSM1S4Br25Hk=.53220aad-5407-41ce-aca5-cd8d6c391622@github.com>

On Wed, 7 Oct 2020 17:57:49 GMT, DougLea <github.com+2233919+DougLea at openjdk.org> wrote:

>>> I'm a little hesitant about the precedent of checking for 0 in every ctor argument for a volatile field.
>> 
>> I'm confused by this if I'm entirely honest @DougLea . Where do we check for 0 in the proposed change?
>
> As in: If unnecessarily writing 0 to a voltaile field in a ctor is expensive enough for a code work-around here, don't
> you think it would be better to teach a compiler to avoid it?

I see what you mean now - thanks! Given that there exists already an empty `AtomicBoolean` constructor that avoids the
volatile write, I didn't see that as a big problem to be honest. Also: The proposed "workaround" doesn't seem to be
overly complicated - personally I find the empty constructor to be the bigger workaround and less explicit.

The same argument applies to initializing volatile fields with their default value, if I'm thinking about it longer. Of
course one would wish that the compiler would be able to avoid it, but there have been examples in the past already
where the explicit volatile write was avoided (e.g. in [JDK-8145680](https://bugs.openjdk.java.net/browse/JDK-8145680)
instead of working on [JDK-8145948](https://bugs.openjdk.java.net/browse/JDK-8145948) for example).

Overall, I think it's a reasonably simple improvement with a good performance gain for relatively little cost, but
after all I'm in your hands when it comes to approving the proposed change.

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

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

From rriggs at openjdk.java.net  Wed Oct  7 18:39:11 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 7 Oct 2020 18:39:11 GMT
Subject: Integrated: 8253876: jdk/test/lib/hexdump/ASN1FormatterTest.java
 fails with "AssertionError: Lines expected [126] but found [202]"
In-Reply-To: <ASCOaOEaKxCTMEzRTADTMkIxJZ3y5fTD1D2bC_Zyi7k=.de0aea66-338c-46be-9fa5-89a52dd4b119@github.com>
References: <ASCOaOEaKxCTMEzRTADTMkIxJZ3y5fTD1D2bC_Zyi7k=.de0aea66-338c-46be-9fa5-89a52dd4b119@github.com>
Message-ID: <COW2ySmV7cmo_KK4kWliwoRJASiMOaHhx-MaW772iAA=.e9e66c27-112b-491f-90c1-8a89a2f12ea8@github.com>

On Fri, 2 Oct 2020 17:36:59 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The HexPrinter test utility should be ignoring \r characters from the formatter.
> It looks for \n and generates System.lineSeparator() at the end of each line.
> 
> With this fix, the ASN1FormatterTest can be removed from the ProblemList.

This pull request has now been integrated.

Changeset: 38159d52
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/38159d52
Stats:     18 lines in 4 files changed: 7 ins; 3 del; 8 mod

8253876: jdk/test/lib/hexdump/ASN1FormatterTest.java fails with "AssertionError: Lines expected [126] but found [202]"

Reviewed-by: shade, lancea

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

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

From rriggs at openjdk.java.net  Wed Oct  7 18:41:12 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 7 Oct 2020 18:41:12 GMT
Subject: RFR: 8254102: use ProcessHandle::pid instead of
 ManagementFactory::getRuntimeMXBean to get pid in tests [v2]
In-Reply-To: <vet7-yMg6VAIeRcunhRUeUpLyCMEOmf2kwfRy02TRc8=.d8ba2027-5eb2-48ee-b7c5-259004508d8f@github.com>
References: <aQOzr1zN3WrL11gTkWFkGrkDVRxwQOrM8XbsMk6_0Cc=.42c65bd7-68bd-4bbb-9b30-ecbf01982332@github.com>
 <vet7-yMg6VAIeRcunhRUeUpLyCMEOmf2kwfRy02TRc8=.d8ba2027-5eb2-48ee-b7c5-259004508d8f@github.com>
Message-ID: <gd-1Ve-RlyWvlhKvmc6fNWnZrPRVlkj1j6y2xPXQLAs=.4a5fc6c0-ea51-4c65-a5ce-1b2ac95ac052@github.com>

On Wed, 7 Oct 2020 18:12:19 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

>> Hi all,
>> 
>> could you please review this small cleanup which replaces
>> `ManagementFactory.getRuntimeMXBean().getName().split("@")[0]` w/ `ProcessHandle.current().pid()` to get current
>> process pid?  Thanks,
>> -- Igor
>
> Igor Ignatyev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - use Long.toString instead of String.valueOf
>  - remove explicit coversion to String in Suicide.java

Marked as reviewed by rriggs (Reviewer).

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

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

From iignatyev at openjdk.java.net  Wed Oct  7 18:55:08 2020
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Wed, 7 Oct 2020 18:55:08 GMT
Subject: Integrated: 8254102: use ProcessHandle::pid instead of
 ManagementFactory::getRuntimeMXBean to get pid in tests
In-Reply-To: <aQOzr1zN3WrL11gTkWFkGrkDVRxwQOrM8XbsMk6_0Cc=.42c65bd7-68bd-4bbb-9b30-ecbf01982332@github.com>
References: <aQOzr1zN3WrL11gTkWFkGrkDVRxwQOrM8XbsMk6_0Cc=.42c65bd7-68bd-4bbb-9b30-ecbf01982332@github.com>
Message-ID: <XhDvgD2naC9sbkJDBY4UFonkS5B04BlBx_qzuWaGh6E=.0d329def-76fc-4181-82eb-153be9150235@github.com>

On Tue, 6 Oct 2020 23:08:40 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small cleanup which replaces
> `ManagementFactory.getRuntimeMXBean().getName().split("@")[0]` w/ `ProcessHandle.current().pid()` to get current
> process pid?  Thanks,
> -- Igor

This pull request has now been integrated.

Changeset: 5a9bd41e
Author:    Igor Ignatyev <iignatyev at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/5a9bd41e
Stats:     57 lines in 8 files changed: 0 ins; 41 del; 16 mod

8254102: use ProcessHandle::pid instead of ManagementFactory::getRuntimeMXBean to get pid in tests

Reviewed-by: rriggs, shade

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

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

From iignatyev at openjdk.java.net  Wed Oct  7 18:55:07 2020
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Wed, 7 Oct 2020 18:55:07 GMT
Subject: RFR: 8254102: use ProcessHandle::pid instead of
 ManagementFactory::getRuntimeMXBean to get pid in tests [v2]
In-Reply-To: <gd-1Ve-RlyWvlhKvmc6fNWnZrPRVlkj1j6y2xPXQLAs=.4a5fc6c0-ea51-4c65-a5ce-1b2ac95ac052@github.com>
References: <aQOzr1zN3WrL11gTkWFkGrkDVRxwQOrM8XbsMk6_0Cc=.42c65bd7-68bd-4bbb-9b30-ecbf01982332@github.com>
 <vet7-yMg6VAIeRcunhRUeUpLyCMEOmf2kwfRy02TRc8=.d8ba2027-5eb2-48ee-b7c5-259004508d8f@github.com>
 <gd-1Ve-RlyWvlhKvmc6fNWnZrPRVlkj1j6y2xPXQLAs=.4a5fc6c0-ea51-4c65-a5ce-1b2ac95ac052@github.com>
Message-ID: <WMB2KyTsDlb9JZvHbfwWGIwCOBJiTAW5RankGaK5ujs=.584043b7-8549-4841-b260-b40aef3b6c6f@github.com>

On Wed, 7 Oct 2020 18:38:07 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Igor Ignatyev has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - use Long.toString instead of String.valueOf
>>  - remove explicit coversion to String in Suicide.java
>
> Marked as reviewed by rriggs (Reviewer).

Roger, Aleksey, thanks for your reviews.

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

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

From bobv at openjdk.java.net  Wed Oct  7 19:09:08 2020
From: bobv at openjdk.java.net (Bob Vandette)
Date: Wed, 7 Oct 2020 19:09:08 GMT
Subject: RFR: 8245543: Cgroups: Incorrect detection logic on some systems
 (still reproducible) [v3]
In-Reply-To: <hvNp_VNZZhh-1-i7ihsTS9f3m-BJz9GwZmn0tsPF6kQ=.6d64a962-3bc5-41bf-940f-074f5be3009f@github.com>
References: <CWATRi437QpkCA1sx-EsHFqVlSCV-G8EgkEoGdJgPHc=.a743be7e-8a00-4d91-866d-86ccf3fe714f@github.com>
 <9Y61ZqGTPrr7PY1UjY55Y3UdjZHu08tfn0iE6AhUb9Q=.2da3dbc9-55c2-48ac-b087-a2b26f0c6378@github.com>
 <znRYI56jaD-sNQpLDloBsjebFtbuhtk5nx7AUZEsOus=.00600298-0e40-4be3-b3c6-2953db69ad07@github.com>
 <5dgnZpaXKV-Q6poVXgt0B0t3P06bGWT8D9JlcJIAtnw=.621aadd7-460f-438b-b46e-925098607bf3@github.com>
 <hvNp_VNZZhh-1-i7ihsTS9f3m-BJz9GwZmn0tsPF6kQ=.6d64a962-3bc5-41bf-940f-074f5be3009f@github.com>
Message-ID: <-Ghp9lTLaabHLOEnriSryHKOCx-cgIcS1sE4B8tmrm0=.4becaccc-6cb0-480b-b975-540d24f9949c@github.com>

On Wed, 7 Oct 2020 08:06:58 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> OK. I'll probably fold JDK-8254001 into this one then.
>
> @bobvandette Done in the latest version. Thoughts?

I'm a little uncomfortable making such a dramatic change just to fix this small isolated problem.   I think about all
the churn we've had on these files and the backports to come.  Could you just add a
CgroupSubsystemFactory::isValidSubsystem function which checks for cpuset, cpuacct, memory, etc instead of the major
change?

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

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

From iignatyev at openjdk.java.net  Wed Oct  7 19:10:12 2020
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Wed, 7 Oct 2020 19:10:12 GMT
Subject: RFR: 8254182: remove Utils.tryFindJvmPid/waitForJvmPid
Message-ID: <PJ004YhperkSBd_Yv_xKVE9UEhrPC5CYqwf0P03GWSY=.9b362dec-237b-4596-8f42-dc33482859c8@github.com>

`jdk.test.lib.Utils::tryFindJvmPid` and `waitForJvmPid` methods aren't used and should be removed

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

Commit messages:
 - remove Utils.tryFindJvmPid/waitForJvmPid

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

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

From rriggs at openjdk.java.net  Wed Oct  7 19:13:15 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 7 Oct 2020 19:13:15 GMT
Subject: RFR: 8254078: DataOutputStream is very slow post-disabling of
 Biased Locking [v2]
In-Reply-To: <Tj_EYEUEPB9fZdspeeU0CtMbmLNhl7S82MNRZIZodXo=.7a17d0a2-ac4d-47f5-98fb-c451afa59374@github.com>
References: <lLg_yNI_6LvUZTlM4PyN5ra6AaUZZeT35QzYzV_0CpI=.f2d3cb9e-be30-40dc-922c-dad5bef7feea@github.com>
 <Tj_EYEUEPB9fZdspeeU0CtMbmLNhl7S82MNRZIZodXo=.7a17d0a2-ac4d-47f5-98fb-c451afa59374@github.com>
Message-ID: <DAg8ijfqluhHelYG6Nc6C1yuxI0qZean31YjTzJzAA4=.c1e4290b-9777-435f-84d9-8b24ba5d37b4@github.com>

On Wed, 7 Oct 2020 17:26:26 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> DataOutputStream is very slow post-disabling of Biased Locking. This
>> was discovered when benchmarking a transaction library, which showed
>> significant performance loss when moving to JDK 15. WIth some small
>> changes to DataOutputStream we can get the performance back. There's a
>> JMH benchmark at
>> http://cr.openjdk.java.net/~aph/JDK-8254078/jmh-tests.tar
>> 
>> Some Stream classes use very fine-grained locking.
>> 
>> In particular, writeInt is defined like this:
>> 
>>         out.write((v >>> 24) & 0xFF);
>>         out.write((v >>> 16) & 0xFF);
>>         out.write((v >>> 8) & 0xFF);
>>         out.write((v >>> 0) & 0xFF);
>>         incCount(4);
>> 
>> Unfortunately, ByteArrayOutputStream.write(byte) is defined like this:
>> 
>>     public synchronized void write(int b) {
>>         ensureCapacity(count + 1);
>>         buf[count] = (byte) b;
>>         count += 1;
>>     }
>> 
>> so we acquire and release a lock for every byte that is output.
>> 
>>  For example, writing 4kb of ints goes from 17.3 us/op to 53.9 us/op when biased locking is disabled:
>> 
>> 
>> +UseBiasedLocking DataOutputStreamTest.dataOutputStreamOverByteArray avgt 6 53.895 ? 5.126 us/op
>> -UseBiasedLocking DataOutputStreamTest.dataOutputStreamOverByteArray avgt 6 17.291 ? 4.430 us/op
>> 
>> There are refactorings of DataOutputStream we can do to mitigate this.
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8254078: DataOutputStream is very slow post-disabling of Biased Locking

src/java.base/share/classes/java/io/DataOutputStream.java line 36:

> 34:  * Thread safety is optional and is the responsibility of users of
> 35:  * methods in this class.
> 36:  *

In -> Out copy/paste

test/micro/org/openjdk/bench/java/io/DataOutputStreamTest.java line 25:

> 23:
> 24: /*
> 25:

The historical data will get stale very fast and is very hardware dependent.
It will continue to exist in the PR, so I think it should be removed from the test.

test/micro/org/openjdk/bench/java/io/DataOutputStreamTest.java line 62:

> 60:
> 61: @BenchmarkMode(Mode.AverageTime)
> 62: @OutputTimeUnit(TimeUnit.MICROSECONDS)

Most JMH tests use NANOSECOND for reporting.

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

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

From rriggs at openjdk.java.net  Wed Oct  7 19:33:08 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 7 Oct 2020 19:33:08 GMT
Subject: RFR: 8254182: remove Utils.tryFindJvmPid/waitForJvmPid
In-Reply-To: <PJ004YhperkSBd_Yv_xKVE9UEhrPC5CYqwf0P03GWSY=.9b362dec-237b-4596-8f42-dc33482859c8@github.com>
References: <PJ004YhperkSBd_Yv_xKVE9UEhrPC5CYqwf0P03GWSY=.9b362dec-237b-4596-8f42-dc33482859c8@github.com>
Message-ID: <3pli82gIvQ5koDh_kfFsD4y9UtkxFFIclt8y2kn2w5Q=.07687424-cc5f-48a8-a347-72a6051bbbcf@github.com>

On Wed, 7 Oct 2020 19:01:45 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> `jdk.test.lib.Utils::tryFindJvmPid` and `waitForJvmPid` methods aren't used and should be removed

Marked as reviewed by rriggs (Reviewer).

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

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

From sgehwolf at openjdk.java.net  Wed Oct  7 19:34:12 2020
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Wed, 7 Oct 2020 19:34:12 GMT
Subject: RFR: 8245543: Cgroups: Incorrect detection logic on some systems
 (still reproducible) [v3]
In-Reply-To: <-Ghp9lTLaabHLOEnriSryHKOCx-cgIcS1sE4B8tmrm0=.4becaccc-6cb0-480b-b975-540d24f9949c@github.com>
References: <CWATRi437QpkCA1sx-EsHFqVlSCV-G8EgkEoGdJgPHc=.a743be7e-8a00-4d91-866d-86ccf3fe714f@github.com>
 <9Y61ZqGTPrr7PY1UjY55Y3UdjZHu08tfn0iE6AhUb9Q=.2da3dbc9-55c2-48ac-b087-a2b26f0c6378@github.com>
 <znRYI56jaD-sNQpLDloBsjebFtbuhtk5nx7AUZEsOus=.00600298-0e40-4be3-b3c6-2953db69ad07@github.com>
 <5dgnZpaXKV-Q6poVXgt0B0t3P06bGWT8D9JlcJIAtnw=.621aadd7-460f-438b-b46e-925098607bf3@github.com>
 <hvNp_VNZZhh-1-i7ihsTS9f3m-BJz9GwZmn0tsPF6kQ=.6d64a962-3bc5-41bf-940f-074f5be3009f@github.com>
 <-Ghp9lTLaabHLOEnriSryHKOCx-cgIcS1sE4B8tmrm0=.4becaccc-6cb0-480b-b975-540d24f9949c@github.com>
Message-ID: <LYakHtyJRjRRqM5M_Gp9Zw6u-fiJMd3O1q_0cURVUfI=.1b9cfacd-b5e8-4b2d-a86b-732a4848f9e4@github.com>

On Wed, 7 Oct 2020 19:05:57 GMT, Bob Vandette <bobv at openjdk.org> wrote:

>> @bobvandette Done in the latest version. Thoughts?
>
> I'm a little uncomfortable making such a dramatic change just to fix this small isolated problem.   I think about all
> the churn we've had on these files and the backports to come.  Could you just add a
> CgroupSubsystemFactory::isValidSubsystem function which checks for cpuset, cpuacct, memory, etc instead of the major
> change?

Thanks for having a look! Sure, we could do that instead. I'm not sure this is the best solution going forward, though.
Thinking about JDK 17...

Anyway, I'll look into a more conservative fix.

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

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

From minqi at openjdk.java.net  Wed Oct  7 19:44:27 2020
From: minqi at openjdk.java.net (Yumin Qi)
Date: Wed, 7 Oct 2020 19:44:27 GMT
Subject: RFR: 8247536: Support for pre-generated java.lang.invoke classes
 in CDS static archive [v12]
In-Reply-To: <kz0Xu1ovkOhMDnQTsen4WORb8dAs1zi5oPnF4f_rDJE=.7c40ebbd-5230-49f9-a370-d9eeae63378c@github.com>
References: <Y_Bas-poGnDtvcJbqbmeIAPQRNxzvarBToQWALn9TTE=.e846cd3c-0e7b-48d3-8ffa-be3c03acffb0@github.com>
 <9emWKl6fr-GA5LN0uHhuEd5D123QcoCiHQR1M9bAbag=.cc4b6129-8b33-47e4-a421-9e6b4817933b@github.com>
 <kz0Xu1ovkOhMDnQTsen4WORb8dAs1zi5oPnF4f_rDJE=.7c40ebbd-5230-49f9-a370-d9eeae63378c@github.com>
Message-ID: <WQijqUURGoht2rb3bMKrId2S_XLv487HCzOLMZ44fCM=.98b18d53-3b83-47e7-9b43-1045586ab683@github.com>

On Wed, 7 Oct 2020 17:48:41 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Yumin Qi has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains
>> 23 commits:
>>  - Added new separate function to CDS for logging species and modified the existing function to log lambda form invokers.
>>    Changed isDumpLoadedClassList to a reasonable name isDumpingClassList as read only in CDS.
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into jdk-8247536
>>  - Removed unused imports.
>>  - Fixed comments with correct class and method name in CDS, removed unused variables after last change.
>>  - Moved and renamed cdsGenerateHolderClasses from GenerateJLIClassesHelp to CDS as generateLambdaFormHolderClasses. Added
>>    input verification function in CDS before class generation. Added more test scenarios. Removed trailing unused ending
>>    words for output of lambda form trace line in case of DumpLoadedClassList.
>>  - Move the check work to java, restore code in VM. Modified test code according to the changes. The invoke name
>>    verififcation is not implemented since not all the holder class are processed, not all the functions of processed
>>    holder classes are added. For holder class with DirectMethodHandle in its name, only the name in the
>>    DMH_METHOD_TYPE_MAP keyset is added, ithe line with other names just gets skipped silently. This makes the verification
>>    on invoke names difficul, a name not in the keyset should not fail the test. Also add a boolean to
>>    cdsGenerateHolderClasses to indicate call path.
>>  - Remove trailing word of line which is not used in holder class regeneration. There is a trailing LF (Line Feed) so trim
>>    white spaces from both front and end of the line or it will fail method type validation.
>>  - In case of exception happens during reloading class, CHECK will return without free the allocated buffer for class
>>    bytes so moved the buffer allocation and freeing to caller. Also removed test 6 since there is not guarantee that we
>>    can give a signature which will always fail. Additional changes to GenerateJLIClassesHelper according to review
>>    suggestion.
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into jdk-8247536
>>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into jdk-8247536
>>  - ... and 13 more: https://git.openjdk.java.net/jdk/compare/82fe023b...f5584dcf
>
> src/hotspot/share/prims/jvm.cpp line 3872:
> 
>> 3870: JVM_ENTRY(jboolean, JVM_IsDumpingClassList(JNIEnv *env))
>> 3871:   JVMWrapper("JVM_IsDumpingClassList");
>> 3872:   return DumpLoadedClassList != NULL && classlist_file->is_open();
> 
> For sanity, it's better to add `classlist_file != NULL`

done

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

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

From minqi at openjdk.java.net  Wed Oct  7 19:44:24 2020
From: minqi at openjdk.java.net (Yumin Qi)
Date: Wed, 7 Oct 2020 19:44:24 GMT
Subject: RFR: 8247536: Support for pre-generated java.lang.invoke classes
 in CDS static archive [v13]
In-Reply-To: <Y_Bas-poGnDtvcJbqbmeIAPQRNxzvarBToQWALn9TTE=.e846cd3c-0e7b-48d3-8ffa-be3c03acffb0@github.com>
References: <Y_Bas-poGnDtvcJbqbmeIAPQRNxzvarBToQWALn9TTE=.e846cd3c-0e7b-48d3-8ffa-be3c03acffb0@github.com>
Message-ID: <naZnG6cPJ9ye1flJ7sWUAER0irYFx1hY6DZ3tEKNWhE=.d4ceb038-fa77-499d-84e1-11df0f6148c1@github.com>

> This patch is reorganized after 8252725, which is separated from this patch to refactor jlink glugin code. The previous
> webrev with hg can be found at: http://cr.openjdk.java.net/~minqi/2020/8247536/webrev-05. With 8252725 integrated, the
> regeneration of holder classes is simply to call the new added GenerateJLIClassesHelper.cdsGenerateHolderClasses
> function.  Tests: tier1-4

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

  Move assert on klass is InstanceKlass after its NULL check. Added sanity check on class_list_file is not NULL before
  check on it is open.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/193/files
  - new: https://git.openjdk.java.net/jdk/pull/193/files/f5584dcf..107192f3

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

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

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

From minqi at openjdk.java.net  Wed Oct  7 19:44:29 2020
From: minqi at openjdk.java.net (Yumin Qi)
Date: Wed, 7 Oct 2020 19:44:29 GMT
Subject: RFR: 8247536: Support for pre-generated java.lang.invoke classes
 in CDS static archive [v11]
In-Reply-To: <MVSv0qdA1fDvK_Jh6uLdP7cZbIwGGqD1fy_Ms8_hZ0o=.3a4caea1-52e5-4485-b98a-86408bc41aa3@github.com>
References: <Y_Bas-poGnDtvcJbqbmeIAPQRNxzvarBToQWALn9TTE=.e846cd3c-0e7b-48d3-8ffa-be3c03acffb0@github.com>
 <fnlaWkwge3SaOu_A427Z-rRlIwxo4n90jXaZan089Hk=.3821150a-9608-4dcf-8284-aa951eed1077@github.com>
 <MVSv0qdA1fDvK_Jh6uLdP7cZbIwGGqD1fy_Ms8_hZ0o=.3a4caea1-52e5-4485-b98a-86408bc41aa3@github.com>
Message-ID: <GMLXFOhV1_ry0KCD_2KH1pmxeDrs2yzaJF43HmondLs=.6214e8f5-db3c-440c-9636-b4b749aa6ba1@github.com>

On Tue, 6 Oct 2020 18:12:50 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removed unused imports.
>
> src/java.base/share/classes/jdk/internal/misc/CDS.java line 83:
> 
>> 81:      * check if -XX:+DumpLoadedClassList and given file is open
>> 82:      */
>> 83:     public static boolean isDumpLoadedClassList() {
> 
> I agree with Ioi's suggestion to rename this to `isDumpingClassList` which describes what the VM is doing.

Done

> src/java.base/share/classes/java/lang/invoke/GenerateJLIClassesHelper.java line 74:
> 
>> 72:                 System.out.println(traceSP + (salvage != null ? " (salvaged)" : " (generated)"));
>> 73:             }
>> 74:             CDS.traceLambdaFormInvoker(traceSP);
> 
> I suggest leaving the existing code unchanged.  Instead, add the following:
>     if (CDS.isDumpingClassList()) {
>          CDS.traceSpeciesType(cn);
>     }
> 
> The above uses Ioi's suggested method name which reads better.

Done

> src/java.base/share/classes/java/lang/invoke/GenerateJLIClassesHelper.java line 63:
> 
>> 61:             if (TRACE_RESOLVE) {
>> 62:                 System.out.println(traceLF + (resolvedMember != null ? " (success)" : " (fail)"));
>> 63:             }
> 
> I suggest not to change the existing code.  Instead, have `CDS::traceLambdaFormInvoker`
> to take individual parameters `Class<?> holder, String name, String shortenSignature`
> (rather than the formatted string).   Something like:
> 
>     if (CDS.isDumpLoadedClassList()) {
>           CDS.traceLambdaFormInvoker(holder, name, shortenSignature(basicTypeSignature(type));
>     }
> 
> This also gives flexibility to CDS to decide on what format to write to the class list (like this case, you drop the
> text "success/fail")
> In addition, the conditional check on `CDS.isDumpLoadedClassList()` is hard to relate to why CDS traces these events.
> I see Ioi's comment on this method name too.   I agree with Ioi that `isDumpingClassList` makes more sense.

Done

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

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

From sspitsyn at openjdk.java.net  Wed Oct  7 19:50:11 2020
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Wed, 7 Oct 2020 19:50:11 GMT
Subject: RFR: 8227745: Enable Escape Analysis for Better Performance in
 the Presence of JVMTI Agents [v7]
In-Reply-To: <6Scp6XjVCcdJN0tUKionVwGKoiBG8UeA-OpBXHrCYqk=.01170b1e-9722-4461-84e4-77e8fd447ac4@github.com>
References: <Ll2RereRbuQLgFtIjv9pS92kPvCVuo-BI0cP1zGjVbo=.dad3a33c-0fc3-44fd-810a-f01448cf564c@github.com>
 <6Scp6XjVCcdJN0tUKionVwGKoiBG8UeA-OpBXHrCYqk=.01170b1e-9722-4461-84e4-77e8fd447ac4@github.com>
Message-ID: <AnuPI17lb0T_qmuGLTxukiAEFU1VV5SPIB7UAXIzdKg=.178e46ab-bd21-4cf2-b50f-fd8101a09dd9@github.com>

On Wed, 7 Oct 2020 17:52:27 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> Hi,
>> 
>> this is the continuation of the review of the implementation for:
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8227745
>> https://bugs.openjdk.java.net/browse/JDK-8233915
>> 
>> It allows for JIT optimizations based on escape analysis even if JVMTI agents acquire capabilities to access references
>> to objects that are subject to such optimizations, e.g. scalar replacement. The implementation reverts such
>> optimizations just before access very much as when switching from JIT compiled execution to the interpreter, aka
>> "deoptimization".  Webrev.8 was the last one before before the transition to Git/Github:
>> 
>> http://cr.openjdk.java.net/~rrich/webrevs/8227745/webrev.8/
>> 
>> Thanks, Richard.
>
> Richard Reingruber has updated the pull request incrementally with five additional commits since the last revision:
> 
>  - Factorized fragment out of EscapeBarrier::deoptimize_objects_internal into new method in compiledVFrame.
>  - More smaller changes proposed by Serguei.
>  - jvmtiDeferredUpdates.hpp: remove forward declarations.
>  - jvmtiDeferredLocalVariable: move member variables to the beginning of the class definition.
>  - jvmtiDeferredUpdates.hpp: add/remove empty lines and improve indentation.

Richard,
Thank you for the formatting and refactoring changes.
The fix looks good to me.

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

Marked as reviewed by sspitsyn (Reviewer).

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

From iignatyev at openjdk.java.net  Thu Oct  8 06:49:28 2020
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Thu, 8 Oct 2020 06:49:28 GMT
Subject: RFR: 8254182: remove Utils.tryFindJvmPid/waitForJvmPid
In-Reply-To: <3pli82gIvQ5koDh_kfFsD4y9UtkxFFIclt8y2kn2w5Q=.07687424-cc5f-48a8-a347-72a6051bbbcf@github.com>
References: <PJ004YhperkSBd_Yv_xKVE9UEhrPC5CYqwf0P03GWSY=.9b362dec-237b-4596-8f42-dc33482859c8@github.com>
 <3pli82gIvQ5koDh_kfFsD4y9UtkxFFIclt8y2kn2w5Q=.07687424-cc5f-48a8-a347-72a6051bbbcf@github.com>
Message-ID: <qNgTFYuiVZmiuVGDKXOfSomDCG5ZWbydtNUmJUo_zAU=.ff65b728-6556-4db6-9bc4-a37934dbfa40@github.com>

On Wed, 7 Oct 2020 19:30:44 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> `jdk.test.lib.Utils::tryFindJvmPid` and `waitForJvmPid` methods aren't used and should be removed
>
> Marked as reviewed by rriggs (Reviewer).

Thanks Roger!

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

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

From github.com+2233919+douglea at openjdk.java.net  Thu Oct  8 06:49:49 2020
From: github.com+2233919+douglea at openjdk.java.net (DougLea)
Date: Thu, 8 Oct 2020 06:49:49 GMT
Subject: RFR: 8254146: Avoid unnecessary volatile write on new
 AtomicBoolean(false)
In-Reply-To: <_0ZtGUqwXqvBx8GqFa5QsIra0-Olve8eSM1S4Br25Hk=.53220aad-5407-41ce-aca5-cd8d6c391622@github.com>
References: <AzWKluHZjvFYm2wUanwYfn91iKKMacpk_qSsje3tXWk=.ba873b46-4e12-4415-8832-fa314d6759a3@github.com>
 <yNUBzMyHr1Asbrtyt2sHQnGcJOxdfP8umMyRPC863Rw=.5c18ea25-bcf8-473b-a86a-fe764b8684d6@github.com>
 <P4lM3Rv3CAm7OqpNbLH3mvmgpVv0nVY1TeDw0VFy7jY=.54c361de-0133-4e10-ae04-12c79686e16a@github.com>
 <YCAn0HKEP0_EZcQUQLL1Xo3Ghw54zKq8ZGDT_A5daUo=.33924e26-7ef1-4395-95e3-9efa4005ca77@github.com>
 <NL9WtVFpAwsc6pG273abr_0N5_xThMwK5AKUVquNMsw=.9fe705eb-5689-4da8-913c-e39567f9bc67@github.com>
 <0R_DeYk8B1ky2fjZYUpz6xEv2exb-W4BdtU_Yu2B0wI=.c3008858-4469-4d2c-913f-2902ea686503@github.com>
 <tVJPFN5AhgLiPCNQbqVZTqTIoZXv6e86IhB4k8Ow-qc=.dcb90a28-b1fc-4a23-bfee-3d1c5c4627ac@github.com>
 <oA2IZElACg1-dUgoeUQb5-cAy_Oertv6KpYCtDkdSSY=.2ed13959-8f4a-44e1-ad78-c764a3a83816@github.com>
 <_0ZtGUqwXqvBx8GqFa5QsIra0-Olve8eSM1S4Br25Hk=.53220aad-5407-41ce-aca5-cd8d6c391622@github.com>
Message-ID: <vGjerpWm8xDpYgtVXRYvQ9Or7LHKHImnMXUYZ5FvCJ4=.155e2761-081e-4511-9d66-6967851b6ad2@github.com>

On Wed, 7 Oct 2020 18:18:43 GMT, Christoph Dreis <github.com+6304496+dreis2211 at openjdk.org> wrote:

>> As in: If unnecessarily writing 0 to a voltaile field in a ctor is expensive enough for a code work-around here, don't
>> you think it would be better to teach a compiler to avoid it?
>
> I see what you mean now - thanks! Given that there exists already an empty `AtomicBoolean` constructor that avoids the
> volatile write, I didn't see that as a big problem to be honest. Also: The proposed "workaround" doesn't seem to be
> overly complicated - personally I find the empty constructor to be the bigger workaround and less explicit.  The same
> argument applies to initializing volatile fields with their default value, if I'm thinking about it longer. Of course
> one would wish that the compiler would be able to avoid it, but there have been examples in the past already where the
> explicit volatile write was avoided (e.g. in [JDK-8145680](https://bugs.openjdk.java.net/browse/JDK-8145680) instead of
> working on [JDK-8145948](https://bugs.openjdk.java.net/browse/JDK-8145948) for example).  Overall, I think it's a
> reasonably simple improvement with a good performance gain for relatively little cost, but after all I'm in your hands
> when it comes to approving the proposed change.

OK. I won't resist doing this as a one-shot. We'll include in jsr166 sources, so it won't matter if done now or later
along with integration pass. (Well, except the braces, which are stylistically not used in j.u.c. code)

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

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

From erikj at openjdk.java.net  Thu Oct  8 06:50:04 2020
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Thu, 8 Oct 2020 06:50:04 GMT
Subject: RFR: 8254162: Implementation of Foreign-Memory Access API (Third
 Incubator)
In-Reply-To: <IngRk57F78UN3yySfo6IABbdwnMogGNdYrykh_3em-c=.b81f7478-015c-45ed-9788-58d7519a2770@github.com>
References: <IngRk57F78UN3yySfo6IABbdwnMogGNdYrykh_3em-c=.b81f7478-015c-45ed-9788-58d7519a2770@github.com>
Message-ID: <_GsbJIUKoZcZhBL3g5LIazayukM61sEJOqQcKpp7Hzw=.12a07196-262a-411e-bb04-70e1321564dd@github.com>

On Wed, 7 Oct 2020 17:13:22 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

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

Build changes look pretty good, just a few minor nits.

make/modules/java.base/gensrc/GensrcScopedMemoryAccess.gmk line 33:

> 31:
> 32: SCOPED_MEMORY_ACCESS_TEMPLATE :=
> $(TOPDIR)/src/java.base/share/classes/jdk/internal/misc/X-ScopedMemoryAccess.java.template 33:
> SCOPED_MEMORY_ACCESS_BIN_TEMPLATE :=
> $(TOPDIR)/src/java.base/share/classes/jdk/internal/misc/X-ScopedMemoryAccess-bin.java.template

Should these variables be defined based on SCOPED_MEMORY_ACCESS_SRC_DIR to avoid repeating that path?

make/modules/java.base/gensrc/GensrcScopedMemoryAccess.gmk line 151:

> 149: 	$(CP) $(SCOPED_MEMORY_ACCESS_TEMPLATE) $(DEST)
> 150: 	$(foreach t, $(SCOPE_MEMORY_ACCESS_TYPES), \
> 151: 		$(TOOL_SPP) -nel -K$(BIN_$t_type) -Dtype=$(BIN_$t_type) -DType=$(BIN_$t_Type) $(BIN_$t_ARGS) \

Please indent with <tab> and 2 spaces for logical indent of the foreach body.

make/modules/java.base/gensrc/GensrcScopedMemoryAccess.gmk line 155:

> 153: 	$(PRINTF) "}\n" >> $(DEST)
> 154:
> 155: TARGETS += $(DEST)

Missing newline.

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

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

From almatvee at openjdk.java.net  Thu Oct  8 06:50:41 2020
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Thu, 8 Oct 2020 06:50:41 GMT
Subject: RFR: 8253379: [windows] Several jpackage tests failed with error
 code 1638 [v3]
In-Reply-To: <p_OjRcLzDzBVDoQeNkQeS6T2KHzt3CN34Dz8caoxx84=.8d0722fd-0215-4d46-8f0a-b62d48335b01@github.com>
References: <LpRaGB39y6sd9g4cO4JZRPWsYl0oUtSO0l6Smv2xgbo=.992f6c8e-c478-4c3c-bf1e-5f43191336cd@github.com>
 <p_OjRcLzDzBVDoQeNkQeS6T2KHzt3CN34Dz8caoxx84=.8d0722fd-0215-4d46-8f0a-b62d48335b01@github.com>
Message-ID: <37oMNOujLoD47NYp-EZnSlcsWOWwLSVgCPj06ecGCGE=.ce165e9b-c8f2-47de-bef7-92f89d563d9d@github.com>

On Wed, 7 Oct 2020 15:08:31 GMT, Andy Herrick <herrick at openjdk.org> wrote:

>> 8253379: [windows] Several jpackage tests failed with error code 1638
>> two windows specific test fixes in WindowsHelper:
>> 1.) do not test that the parent directory of a windows menu shortcut is empty after shortcut is uninstalled (there may
>> be other shortcuts using that directory) 2.) do not programmatically install windows exe installers (since we have no
>> way of programmatically uninstalling them)
>
> Andy Herrick has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8253379: [windows] Several jpackage tests failed with error code 1638

Marked as reviewed by almatvee (Committer).

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

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

From mchung at openjdk.java.net  Thu Oct  8 06:52:14 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Thu, 8 Oct 2020 06:52:14 GMT
Subject: RFR: 8159746: (proxy) Support for default methods
In-Reply-To: <HvtDex3cmiv7XeTMITOroYfu74amSGQavQ_BAmVzmXw=.223be989-7c20-4ba4-ac0d-013d2b75a8cb@github.com>
References: <kw2VXh3vTFf1zgfd4biXA41OKffZ5oU7KT23tXAxgUA=.bcf14ffc-4dba-4c9c-8754-184172c5acbd@github.com>
 <U-6RiCpFVIrhLztPN6opiPcpFtxValDzU-K7WWFZM-4=.6bc8aaa4-636a-4664-b380-4c4af00513bd@github.com>
 <-cLIJ8pFHtnNoJMHV3aXI7XMJWp4Jrutc8Xn5PG0OK8=.d2cd87ab-3592-4524-ad85-05444c43689b@github.com>
 <r0UK2qjnmgeTNDDSWaSLPAj3QRgx_4YB82ielllO7jM=.fa615bc0-db49-4a74-b842-793f8f5209bb@github.com>
 <1T8kXDZN1bhHr4c8v4SQsImeBySCqTfX-u3_jzvyocA=.b4957400-9a33-4b6e-8475-329642a5888c@github.com>
 <XIux-dY0JXHRafHk48kVNXId9r-HSceNSytBojDxelY=.872e74cb-b064-406e-b71f-13c90ec7fbbc@github.com>
 <j4t2vT0SnwnU7lhKRlXtk967d-K6nA0EqHrqNbba7W0=.dc05dba6-bf7e-4606-8a02-9c2bad4b3b58@github.com>
 <fmVtPcBdgMuZOPm2qx3Q3znVZM7JgQPkhPAVLtwkOhE=.2d8b8447-cfae-4cb3-9a7c-6567a881231f@github.com>
 <GSeWP29fAIUFSk0CYsC557w52CuLqeUWwHNK9maltwI=.3d5f002e-6b74-4a57-a5d8-244d27da9dde@github.com>
 <GF8iEOkMUEL2dYB0HytFIc9gyeeUJ_KP0ImlqFsul2Y=.894afc05-9310-43e1-a308-8f7d71dc572b@github.com>
 <HvtDex3cmiv7XeTMITOroYfu74amSGQavQ_
 BAmVzmXw=.223be989-7c20-4ba4-ac0d-013d2b75a8cb@github.com>
Message-ID: <IqRiLphFPBpGiKAnMJXqxjie9YeZ03rcE-qG1s92BLw=.d4fd5e92-5067-40df-8a0b-1dfd3d6e23af@github.com>

On Wed, 7 Oct 2020 07:29:51 GMT, Peter Levart <plevart at openjdk.org> wrote:

>> Joe has given some feedback in the CSR review.
>>> should this functionality be housed in the InvocationHandler interface rather than the Proxy class? If I understand the
>>> intended usage of the new method, it should only be done in an InvocationHandler.
>> 
>> The primary usage of this new method is `InvocationHandler`.  I agree that the new API should be defined in
>> `InvocationHandler`.
>> @plevart @AlanBateman any feedback or thought on moving the new API to `InvocationHandler`?
>> 
>>> Does the current spec handle a case like interface A declares a default method m, interface B extends A and separately
>>> interface B declare a default method m.
>> 
>> Yes
>> 
>>> Would invokeDefaultMethod on A::m do-what-is-wanted by call the default method inherited from A? Indirectly, this is
>>> also a question if the operation that are binary compatible with respect to moving around default methods and
>>> behaviorally compatible with the semantics of the new method.
>> 
>> If a proxy instance implements both A and B, `invokeDefaultMethod(o, A.class.getMethod("m"), params)` will invoke
>> `A::m`.
>> If a proxy instance implements B only, `invokeDefaultMethod(o, A.class.getMethod("m"), params)` will get IAE thrown.
>> This is consistent with a concrete class implements B that can only call `B.super::m` but not `A::m`.
>> I update the javadoc to clarify this.
>> 
>>> Any special cases for hidden classes?
>> 
>> No because proxy cannot implement a hidden proxy interface as specified in `Proxy::newProxyInstance`
>> 
>> IllegalArgumentException will be thrown if any of the following restrictions is violated:
>> 
>> - All of Class objects in the given interfaces array must represent non-hidden interfaces, not classes or primitive types.
>
>> Joe has given some feedback in the CSR review.
>> 
>> >    should this functionality be housed in the InvocationHandler interface rather than the Proxy class? If I understand the
>> >    intended usage of the new method, it should only be done in an InvocationHandler.
>> 
>> The primary usage of this new method is InvocationHandler. I agree that the new API should be defined in
>> InvocationHandler.
> 
> If it is a public static method, then Proxy or InvocationHandler are just a namespace for it. From discoverability
> perspective, either one is a good place I think. One point for moving the method into the InvocationHandler is the fact
> that Proxy is a class and classes "inherit" static methods too while interfaces don't. It would be impossible to create
> a dynamic proxy for an interface with a method having the same signature as the Proxy.invokeDefaultMethod static method
> since such proxy class would need to implement an instance method having the same signature as its superclass static
> method.  If interfaces supported protected default methods, then it would make sense to be a protected default method
> in InvocationHandler. Such instance method could additionally enforce two things:
> - that it is called from code comprising InvocationHandler
> - that the proxy instance passed to that method is in fact backed by the invocation handler instance that is the target
>   of that call by checking that in the method.
> 
> But we don't have protected default methods in interfaces (yet). So a static method it must be.
> 
> I was thinking about what such public static method allows and whether that presents a problem (perhaps security
> related) and came to the conclusion that it does not allow anything that normal Java code would not allow except for
> one thing (see below). From the 1st glance it would seem that it allows any code to call super default method on any
> Proxy instance, but what does that mean exactly? The same effect can be achieved by creating a special hand-made proxy
> class implementing all the interfaces that the dynamic Proxy class implements:  class HandmadeProxy implements I1, I2,
> ... {
>     private final Proxy targetProxy;
>     HandmadeProxy(Proxy targetProxy) { this.targetProxy = targetProxy }
>     // implement all non-default methods of I1, I2, ... by delegating to targetProxy
>     // example for I1.m()
>     public void m() {
>         ((I1)targetProxy).m();
>     }
> }
> 
> ...and then using such class to invoke some default method on an instance of the Proxy:
> 
> Proxy proxy = ...
> new HandmadeProxy(proxy).someDefaultMethod();
> 
> So such apparently powerful capability does not represent a problem. One additional thing is possible though:
> 
>>> Does the current spec handle a case like interface A declares a default method m, interface B extends A and separately
>>> interface B declare a default method m.
>>
>> If a proxy instance implements both A and B, `invokeDefaultMethod(o, A.class.getMethod("m"), params)` will invoke
>> `A::m`.
> 
> This is true since lookup.findSpecial() allows such thing (and I assume equivalent bytecode does too). The Java
> language (compiler) OTOH does not allow calling A.super.m() from a class implementing both A and B when B extends A and
> both A and B declare default method m():
>     interface A {
>         default void m() { }
>     }
> 
>     interface B extends A {
>         default void m() { }
>     }
> 
>     static class C implements A, B {
>         public void m() {
>             A.super.m();
>         }
>     }
> 
> java: bad type qualifier A in default super call
>   redundant interface A is extended by B
> 
> I'm in favour of following the bytecode (method handles) behaviour here even though it allows more than Java language
> allows.

I'm thinking a static method `InvocationHandler::invokeDefaultMethod` and no new method in `Proxy` class.   Proxy class
will still have the package-private methods for `InvocationHandler::invokeDefaultMethod` implementation to use.

It may seem to be cleaner to be a default method at the use site called from InvocationHandler.  However, it's not
really a method meant to be overridden.

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

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

From mchung at openjdk.java.net  Thu Oct  8 06:52:28 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Thu, 8 Oct 2020 06:52:28 GMT
Subject: RFR: 8159746: (proxy) Support for default methods
In-Reply-To: <IqRiLphFPBpGiKAnMJXqxjie9YeZ03rcE-qG1s92BLw=.d4fd5e92-5067-40df-8a0b-1dfd3d6e23af@github.com>
References: <kw2VXh3vTFf1zgfd4biXA41OKffZ5oU7KT23tXAxgUA=.bcf14ffc-4dba-4c9c-8754-184172c5acbd@github.com>
 <U-6RiCpFVIrhLztPN6opiPcpFtxValDzU-K7WWFZM-4=.6bc8aaa4-636a-4664-b380-4c4af00513bd@github.com>
 <-cLIJ8pFHtnNoJMHV3aXI7XMJWp4Jrutc8Xn5PG0OK8=.d2cd87ab-3592-4524-ad85-05444c43689b@github.com>
 <r0UK2qjnmgeTNDDSWaSLPAj3QRgx_4YB82ielllO7jM=.fa615bc0-db49-4a74-b842-793f8f5209bb@github.com>
 <1T8kXDZN1bhHr4c8v4SQsImeBySCqTfX-u3_jzvyocA=.b4957400-9a33-4b6e-8475-329642a5888c@github.com>
 <XIux-dY0JXHRafHk48kVNXId9r-HSceNSytBojDxelY=.872e74cb-b064-406e-b71f-13c90ec7fbbc@github.com>
 <j4t2vT0SnwnU7lhKRlXtk967d-K6nA0EqHrqNbba7W0=.dc05dba6-bf7e-4606-8a02-9c2bad4b3b58@github.com>
 <fmVtPcBdgMuZOPm2qx3Q3znVZM7JgQPkhPAVLtwkOhE=.2d8b8447-cfae-4cb3-9a7c-6567a881231f@github.com>
 <GSeWP29fAIUFSk0CYsC557w52CuLqeUWwHNK9maltwI=.3d5f002e-6b74-4a57-a5d8-244d27da9dde@github.com>
 <GF8iEOkMUEL2dYB0HytFIc9gyeeUJ_KP0ImlqFsul2Y=.894afc05-9310-43e1-a308-8f7d71dc572b@github.com>
 <HvtDex3cmiv7XeTMITOroYfu74amSGQavQ_
 BAmVzmXw=.223be989-7c20-4ba4-ac0d-013d2b75a8cb@github.com>
 <IqRiLphFPBpGiKAnMJXqxjie9YeZ03rcE-qG1s92BLw=.d4fd5e92-5067-40df-8a0b-1dfd3d6e23af@github.com>
Message-ID: <Y0hE51G3YefI6NY1O_E6VoZSKwxE78S1hv6fEatmOG8=.0a2c686c-d9ad-418c-8c1b-49addb8a54b1@github.com>

On Wed, 7 Oct 2020 21:04:36 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>>> Joe has given some feedback in the CSR review.
>>> 
>>> >    should this functionality be housed in the InvocationHandler interface rather than the Proxy class? If I understand the
>>> >    intended usage of the new method, it should only be done in an InvocationHandler.
>>> 
>>> The primary usage of this new method is InvocationHandler. I agree that the new API should be defined in
>>> InvocationHandler.
>> 
>> If it is a public static method, then Proxy or InvocationHandler are just a namespace for it. From discoverability
>> perspective, either one is a good place I think. One point for moving the method into the InvocationHandler is the fact
>> that Proxy is a class and classes "inherit" static methods too while interfaces don't. It would be impossible to create
>> a dynamic proxy for an interface with a method having the same signature as the Proxy.invokeDefaultMethod static method
>> since such proxy class would need to implement an instance method having the same signature as its superclass static
>> method.  If interfaces supported protected default methods, then it would make sense to be a protected default method
>> in InvocationHandler. Such instance method could additionally enforce two things:
>> - that it is called from code comprising InvocationHandler
>> - that the proxy instance passed to that method is in fact backed by the invocation handler instance that is the target
>>   of that call by checking that in the method.
>> 
>> But we don't have protected default methods in interfaces (yet). So a static method it must be.
>> 
>> I was thinking about what such public static method allows and whether that presents a problem (perhaps security
>> related) and came to the conclusion that it does not allow anything that normal Java code would not allow except for
>> one thing (see below). From the 1st glance it would seem that it allows any code to call super default method on any
>> Proxy instance, but what does that mean exactly? The same effect can be achieved by creating a special hand-made proxy
>> class implementing all the interfaces that the dynamic Proxy class implements:  class HandmadeProxy implements I1, I2,
>> ... {
>>     private final Proxy targetProxy;
>>     HandmadeProxy(Proxy targetProxy) { this.targetProxy = targetProxy }
>>     // implement all non-default methods of I1, I2, ... by delegating to targetProxy
>>     // example for I1.m()
>>     public void m() {
>>         ((I1)targetProxy).m();
>>     }
>> }
>> 
>> ...and then using such class to invoke some default method on an instance of the Proxy:
>> 
>> Proxy proxy = ...
>> new HandmadeProxy(proxy).someDefaultMethod();
>> 
>> So such apparently powerful capability does not represent a problem. One additional thing is possible though:
>> 
>>>> Does the current spec handle a case like interface A declares a default method m, interface B extends A and separately
>>>> interface B declare a default method m.
>>>
>>> If a proxy instance implements both A and B, `invokeDefaultMethod(o, A.class.getMethod("m"), params)` will invoke
>>> `A::m`.
>> 
>> This is true since lookup.findSpecial() allows such thing (and I assume equivalent bytecode does too). The Java
>> language (compiler) OTOH does not allow calling A.super.m() from a class implementing both A and B when B extends A and
>> both A and B declare default method m():
>>     interface A {
>>         default void m() { }
>>     }
>> 
>>     interface B extends A {
>>         default void m() { }
>>     }
>> 
>>     static class C implements A, B {
>>         public void m() {
>>             A.super.m();
>>         }
>>     }
>> 
>> java: bad type qualifier A in default super call
>>   redundant interface A is extended by B
>> 
>> I'm in favour of following the bytecode (method handles) behaviour here even though it allows more than Java language
>> allows.
>
> I'm thinking a static method `InvocationHandler::invokeDefaultMethod` and no new method in `Proxy` class.   Proxy class
> will still have the package-private methods for `InvocationHandler::invokeDefaultMethod` implementation to use.
> It may seem to be cleaner to be a default method at the use site called from InvocationHandler.  However, it's not
> really a method meant to be overridden.

Thanks for the input Peter.

> I'm in favour of following the bytecode (method handles) behaviour here even though it allows more than Java language
> allows.

The proposal intends to follow the bytecode behavior.   I can clarify in the javadoc.

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

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

From github.com+51754783+coreyashford at openjdk.java.net  Thu Oct  8 06:53:42 2020
From: github.com+51754783+coreyashford at openjdk.java.net (CoreyAshford)
Date: Thu, 8 Oct 2020 06:53:42 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v2]
In-Reply-To: <ZqqaFPCInDiTFVub5iozxR4NOckf5yej6k7-sR3MP_s=.b1c9690b-5226-41a6-8f95-f1fa5232f757@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <6P-wrlA7c9wlXEhcoAYW5J9W2jwTmTTj3PkDObPh0LA=.c11aa048-8853-4e1c-a689-c34b89c15f12@github.com>
 <ZqqaFPCInDiTFVub5iozxR4NOckf5yej6k7-sR3MP_s=.b1c9690b-5226-41a6-8f95-f1fa5232f757@github.com>
Message-ID: <R06iFTJu66Y6z7eGVBuBZ71nnLxBIsMWSd8Us9veW2Q=.cbb68f9b-1a12-478f-b5dc-fb730d1c658e@github.com>

On Wed, 7 Oct 2020 16:26:04 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> CoreyAshford has updated the pull request with a new target base due to a merge or a rebase. The pull request now
>> contains ten commits:
>>  - AOT: Revert change to aotCodeHeap.cpp for decodeBlock
>>    
>>    Don't add the SET_AOT_GLOBAL_SYMBOL_VALUE macro for decode block until all
>>    arches that implement AOT, implement the decodeBlock intrinsic.
>>  - Base64.java decodeBlock: Changes from PR review
>>    
>>     * Make comparison safer and consistent with the while loop
>>     * Update comment about the decodeBlock intrinsic so that it matches the new structure
>>     * Add comment about the lack of a length check on the destination buffer
>>     * As per issue 8138732, change HotSpotIntrinsicCandidate to IntrinsicCandidate
>>  - stubGenerator_ppc.cpp: Changes from PR review
>>    
>>     * Fix clearing of upper bits to clear 32 bits instead of 31 (due to misreading of clrldi instruction)
>>     * change and document loop_unrolls setting from 8 to 2 after re-running the benchmark
>>     * align unrolled loop on a 32-byte boundary
>>     * replace instruction used for checking isURL from a double word to single
>>       word instruction since the register is effectively 32 bits wide
>>     * cosmetic change to realign register comments.
>>  - TestBase64.java: Changes from PR review
>>    
>>     * Use Utils.toByteArrays() method instead of a locally-defined method
>>     * Generate the two non-Base64 tables dynamically rather than use static initialization
>>     * Added comments describing the two above-mentioned arrays
>>  - Expand the Base64 intrinsic regression test to cover decodeBlock
>>    
>>    This patch makes four significant changes:
>>    
>>    1) The Power implementation of the decodeBlock intrinsic, at least,
>>    requires a decode length of at least 128 bytes, but the existing test cases
>>    are much shorter, maxing out at 111 bytes.  So the patch adds a new input
>>    data file which has longer test cases in it.
>>    
>>    2) The original test cases only covers the encoding of just the printable
>>    subset of the 7-bit ASCII characters.  However, Base64 encoding requires
>>    being able to encode arbitrary binary data, i.e. it must handle all 256
>>    8-bit byte encodings.  To remedy this, but keep the original line-oriented
>>    style of the input data, I added another input file type that uses a simple
>>    ASCII hexadecimal encoding - two ASCII hex characters per 8-bit byte.  When
>>    test0 is called, a new parameter is passed that specifies the type of the
>>    input file, which is either the original ASCII type or the hexadecimal
>>    format.  So to test both longer input data and arbitrary 8-bit data, the
>>    newly added input test file has test cases which are both longer and
>>    encoded in ASCII hex so as to give full 8-bit capability.  When reading
>>    this type of file, test0 calls a newly-added function to translate the
>>    ASCII hex to binary data.  Except for the first line of input data, which
>>    contains all possible 8-bit values sequentially, the input data was
>>    generated using a random length (between 111 and 520 bytes) buffer filled
>>    with random 8-bit data, which should give adequate coverage.
>>    
>>    3) The original test did not test that the decoder detects illegal Base64
>>    bytes.  This change chooses a random location in the encoded data to
>>    corrupt with a randomly-chosen byte which is illegal for the specific
>>    Base64 encoding that is chosen (i.e. standard or URLsafe).  It then calls
>>    the decode function to verify that the illegal byte is detected and the
>>    proper exception is thrown.
>>    
>>    4) The test iteration count was originally 100K, but that is far more than
>>    enough iterations to test the intrinsic.  It takes 20K iterations on each
>>    instrinsic for HotSpot C2 to begin calling it.  The test originally had
>>    three types of encodings to test and called the encode intrinsic four times
>>    for each iteration, which works out to 100K * 3 * 4 = 1.2M calls just to
>>    encode.  Decode was called four times as well (now five because of the
>>    illegal byte test).  I believe this is excessive and with the extra test
>>    data I have added, the test was timing out after ten minutes of execution.
>>    It appears that it is timing out, not because the intrinsics take a long
>>    time to run, but because test0 generates an enormous number of discarded
>>    data buffers for the GC system to recover (the test runs at about 39GB of
>>    virtual memory on my test machine).  To remedy the timeout problem, I have
>>    changed the code so that a warmup function of 20K repetitions is performed
>>    on a fixed buffer, to activate the instrinsic(s).  After the warmup, I have
>>    reduced the number of iterations to 5K on each test0 call.  This should
>>    give adequate coverage.
>>  - Add JMH benchmark for Base64 variable length buffer decoding
>>  - Add Power9+ intrinsic implementation for Base64 decoding
>>  - Add HotSpot code to implement Base64 decodeBlock API
>>  - Add HotSpotIntrinsicCandidate and API for Base64 decoding
>
> Hi Corey,
> thanks for contributing this change. Looks basically good. Please address the inline comments from Roger and me.
> Core libs part is reviewed by Roger and the whole change by me. The shared hotspot part is straight forward because
> it's very similar to the encode intrinsic. So I think we only need a 2nd review for the PPC64 algorithm implementation.
> I can sponsor the change when this is completed.

Ready for another review.  I hope I addressed all of the issues raised.

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

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

From github.com+51754783+coreyashford at openjdk.java.net  Thu Oct  8 06:53:26 2020
From: github.com+51754783+coreyashford at openjdk.java.net (CoreyAshford)
Date: Thu, 8 Oct 2020 06:53:26 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v3]
In-Reply-To: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
Message-ID: <BPUaQTDmxtonENpeoEp5xhJBjS7LB4vESLH7A8sH1-k=.755d7497-1fa1-4ca2-9d95-4477460f7626@github.com>

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

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

 - stubGenerator_ppc.cpp: Fix multiple issues as per Martin Doerr's v2 review
   
    * Remove extraneous comma from SAP copyright notice
    * Move align(32) to the head of the loop rather than the beginning of the unwound code
    * Simplified looping condition to use a loop counter instead of a final
      address.  This eliminated the need for the "end" variable, and
      essentially replaced it with CTR, which is computed using a simple
      bitwise shift of the size.
    * Re-ran benchmarks against loop_unrolls values: 1, 2, 4, 8, 16 to find
      optimal value, now 4.
    * Corrected a typo in the word "elements"
 - vm_version_ppc.cpp: per Martin Doerr's review of v2: fix copy/paste error
 - vmIntrinsics.cpp: Per Martin Doerr's v2 review: rearrange order of case statement to be consistent with others.
 - runtime.cpp: per Martin Doerr's review of v2, correct comment as per current semantics of decodeBlock()
   
     * The reference to "ofs" seems to be a copy/paste error.
     * -1 is no longer returned from decodeBlock() in the event of a
       non-base64 character being encountered; only a count of bytes written
       to dst.
 - TestBase64.java: Change comment as per Martin Doerr's v2 review
 - Base64.java: Make changes as per Roger Riggs and Martin Doerr's v2 Review
   
     * Make comment about the sl parameter more precise
     * Fix comparison to avoid possible integer overflow of sp
 - library_call.cpp: Fix rebase merge error

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/293/files
  - new: https://git.openjdk.java.net/jdk/pull/293/files/e42ac7db..8932c233

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

  Stats: 42 lines in 7 files changed: 9 ins; 11 del; 22 mod
  Patch: https://git.openjdk.java.net/jdk/pull/293.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/293/head:pull/293

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

From iignatyev at openjdk.java.net  Thu Oct  8 06:54:31 2020
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Thu, 8 Oct 2020 06:54:31 GMT
Subject: RFR: 8254096: remove
 jdk.test.lib.Utils::getMandatoryProperty(String) method
In-Reply-To: <K0-_xlLI-lhwXNABvdXgEOH1hDF7CHc2wSMf5_Fn7-k=.c14dbf9e-4f93-4f66-8e66-98c5db949c39@github.com>
References: <cJ3C3wcBvwmya8DPeOCNSnkLPiE1t2ajKgF-yG-fu_8=.ab77ef50-15b4-488f-85df-5d129ee1aa12@github.com>
 <K0-_xlLI-lhwXNABvdXgEOH1hDF7CHc2wSMf5_Fn7-k=.c14dbf9e-4f93-4f66-8e66-98c5db949c39@github.com>
Message-ID: <X4PUv9dawnVoDXgXuV8S7hmZD6057ATMH_XO9wL9W8w=.7c1d5f4e-f5b0-4e86-9263-9007536e103d@github.com>

On Thu, 8 Oct 2020 05:32:17 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Hi all,
>> 
>> could you please review this small and trivial cleanup that removes `getMandatoryProperty` method from
>> `jdk.test.lib.Utils` as it's unused?
>> Thanks,
>> -- Igor
>
> Marked as reviewed by shade (Reviewer).

Thanks Aleksey.

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

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

From shade at openjdk.java.net  Thu Oct  8 06:54:21 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 8 Oct 2020 06:54:21 GMT
Subject: RFR: 8254096: remove
 jdk.test.lib.Utils::getMandatoryProperty(String) method
In-Reply-To: <cJ3C3wcBvwmya8DPeOCNSnkLPiE1t2ajKgF-yG-fu_8=.ab77ef50-15b4-488f-85df-5d129ee1aa12@github.com>
References: <cJ3C3wcBvwmya8DPeOCNSnkLPiE1t2ajKgF-yG-fu_8=.ab77ef50-15b4-488f-85df-5d129ee1aa12@github.com>
Message-ID: <K0-_xlLI-lhwXNABvdXgEOH1hDF7CHc2wSMf5_Fn7-k=.c14dbf9e-4f93-4f66-8e66-98c5db949c39@github.com>

On Tue, 6 Oct 2020 20:54:50 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small and trivial cleanup that removes `getMandatoryProperty` method from
> `jdk.test.lib.Utils` as it's unused?
> Thanks,
> -- Igor

Marked as reviewed by shade (Reviewer).

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

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

From alanb at openjdk.java.net  Thu Oct  8 06:54:49 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 8 Oct 2020 06:54:49 GMT
Subject: RFR: 8254078: DataOutputStream is very slow post-disabling of
 Biased Locking [v2]
In-Reply-To: <DAg8ijfqluhHelYG6Nc6C1yuxI0qZean31YjTzJzAA4=.c1e4290b-9777-435f-84d9-8b24ba5d37b4@github.com>
References: <lLg_yNI_6LvUZTlM4PyN5ra6AaUZZeT35QzYzV_0CpI=.f2d3cb9e-be30-40dc-922c-dad5bef7feea@github.com>
 <Tj_EYEUEPB9fZdspeeU0CtMbmLNhl7S82MNRZIZodXo=.7a17d0a2-ac4d-47f5-98fb-c451afa59374@github.com>
 <DAg8ijfqluhHelYG6Nc6C1yuxI0qZean31YjTzJzAA4=.c1e4290b-9777-435f-84d9-8b24ba5d37b4@github.com>
Message-ID: <gqWhGgXpIm1RKM00vCit5gLC7GtMmFaa65lyJBgB6Mo=.4612a8d7-5d8d-45c3-9a69-52e4bb9fd8df@github.com>

On Wed, 7 Oct 2020 18:56:57 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8254078: DataOutputStream is very slow post-disabling of Biased Locking
>
> src/java.base/share/classes/java/io/DataOutputStream.java line 36:
> 
>> 34:  * Thread safety is optional and is the responsibility of users of
>> 35:  * methods in this class.
>> 36:  *
> 
> In -> Out copy/paste

I realise this is wording coming from DataInputStream but I don't think specifying the thread safety as optional is
useful. What would you think about using something like this (and changing DataInputStream too):

"A DataOutputStream is not safe for use by multiple concurrent threads. If a DataOutputStream is to be used by more
than one thread then access to the data output stream should be controlled by appropriate synchronization."

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

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

From jpai at openjdk.java.net  Thu Oct  8 06:54:57 2020
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Thu, 8 Oct 2020 06:54:57 GMT
Subject: RFR: 8242882: opening jar file with large manifest might throw
 NegativeArraySizeException [v3]
In-Reply-To: <-1TnPxiL-jvYX34VVaIpduNdE687CpEGm_65B4tb-P8=.e5983c5f-405a-4629-b232-a6b284d9d95a@github.com>
References: <17lthSuYGInBHE2r3hBs0yXvMIZWWQkdLhYYBfRUMfM=.b59db398-6dc4-4b34-b141-2c58f189bce8@github.com>
 <9AgaGLA8q63mDTKDeavbyfZVntagI0bd0Kb7rkQQYyg=.67d4410c-b7db-4048-87d0-4ec1f9d93cd2@github.com>
 <-1TnPxiL-jvYX34VVaIpduNdE687CpEGm_65B4tb-P8=.e5983c5f-405a-4629-b232-a6b284d9d95a@github.com>
Message-ID: <VkmRN3nnOg08RIQX7LdbDEf6PhlgXLLtfIKKclL84DU=.0bb78e20-10fd-42c4-9b00-420a2debb774@github.com>

On Wed, 7 Oct 2020 21:40:57 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Second round of review comments addressed
>
> Marked as reviewed by bchristi (Reviewer).

Hello Lance, does the latest state of this PR look fine to you? If so, shall I trigger a integrate?

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

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

From bchristi at openjdk.java.net  Thu Oct  8 06:54:40 2020
From: bchristi at openjdk.java.net (Brent Christian)
Date: Thu, 8 Oct 2020 06:54:40 GMT
Subject: RFR: 8242882: opening jar file with large manifest might throw
 NegativeArraySizeException [v3]
In-Reply-To: <9AgaGLA8q63mDTKDeavbyfZVntagI0bd0Kb7rkQQYyg=.67d4410c-b7db-4048-87d0-4ec1f9d93cd2@github.com>
References: <17lthSuYGInBHE2r3hBs0yXvMIZWWQkdLhYYBfRUMfM=.b59db398-6dc4-4b34-b141-2c58f189bce8@github.com>
 <9AgaGLA8q63mDTKDeavbyfZVntagI0bd0Kb7rkQQYyg=.67d4410c-b7db-4048-87d0-4ec1f9d93cd2@github.com>
Message-ID: <-1TnPxiL-jvYX34VVaIpduNdE687CpEGm_65B4tb-P8=.e5983c5f-405a-4629-b232-a6b284d9d95a@github.com>

On Thu, 1 Oct 2020 14:42:21 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review and a sponsor for a fix for https://bugs.openjdk.java.net/browse/JDK-8242882?
>> 
>> As noted in that JBS issue, if the size of the Manifest entry in the jar happens to be very large (such that it exceeds
>> the `Integer.MAX_VALUE`), then the current code in `JarFile#getBytes` can lead to a `NegativeArraySizeException`.  This
>> is due to the: if (len != -1 && len <= 65535)  block which evaluates to `true` when the size of the manifest entry is
>> larger than `Integer.MAX_VALUE`. As a result, this then ends up calling the code which can lead to the
>> `NegativeArraySizeException`.  The commit in this PR fixes that issue by changing those `if/else` blocks to prevent
>> this issue and instead use a code path that leads to the `InputStream#readAllBytes()` which internally has the
>> necessary checks to throw the expected `OutOfMemoryError`.  This commit also includes a jtreg test case which
>> reproduces the issue and verifies the fix.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Second round of review comments addressed

Marked as reviewed by bchristi (Reviewer).

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

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

From bchristi at openjdk.java.net  Thu Oct  8 06:55:24 2020
From: bchristi at openjdk.java.net (Brent Christian)
Date: Thu, 8 Oct 2020 06:55:24 GMT
Subject: RFR: 8242882: opening jar file with large manifest might throw
 NegativeArraySizeException [v2]
In-Reply-To: <tsp044AyIttSb2D8mVDj9VneD6nK61iEFu7Af0uvJTk=.e96dbe4a-5e2b-44ef-ad36-9df1bde90ce4@github.com>
References: <17lthSuYGInBHE2r3hBs0yXvMIZWWQkdLhYYBfRUMfM=.b59db398-6dc4-4b34-b141-2c58f189bce8@github.com>
 <Eyd8QE33uB1pr8qEtknKqPwJUXzxuvQnkb_LzUHg858=.16a8fb43-c74c-40d6-a681-ffcc4a5ac42a@github.com>
 <JSDhWxPp22Zr5vWtjs0iveljOW1Ej0WycVdbRHzqPEA=.dfa9db34-b7b2-440e-9bca-0c19dc450b48@github.com>
 <tsp044AyIttSb2D8mVDj9VneD6nK61iEFu7Af0uvJTk=.e96dbe4a-5e2b-44ef-ad36-9df1bde90ce4@github.com>
Message-ID: <Oe050_7zFhKQLYJKt5qwCCycXM_843Id3NLkVSnJ4os=.5f23a096-0b18-48bb-8ee9-69372d6407c3@github.com>

On Thu, 1 Oct 2020 14:39:50 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> test/jdk/java/util/jar/JarFile/LargeManifestOOMTest.java line 78:
>> 
>>> 76:             bw.write("OOM-Test: ");
>>> 77:             for (long i = 0; i < 2147483648L; i++) {
>>> 78:                 bw.write("a");
>> 
>> As you probably noticed, this test takes a little while to run.  One way to speed it up a little would be to write more
>> characters at a time.  While we're at it, we may as well make the Manifest well-formed by breaking it into 72-byte
>> lines.  See "Line length" under:
>> https://docs.oracle.com/en/java/javase/15/docs/specs/jar/jar.html#notes-on-manifest-and-signature-files  Just write
>> enough lines to exceed Integer.MAX_VALUE bytes.
>
> I decided to slightly change the way this large manifest file was being created. I borrowed the idea from
> `Zip64SizeTest`[1] to create the file and set its length to a large value. I hope that is OK. If not, let me know, I
> will change this part.  [1]
> https://github.com/openjdk/jdk/blob/master/test/jdk/java/util/zip/ZipFile/Zip64SizeTest.java#L121

I did some automated test runs, and the duration of this test is sufficiently improved, IMO.

While not representative of a real MANIFEST.MF file, I think it works well enough for this specific test.

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

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

From jpai at openjdk.java.net  Thu Oct  8 06:55:32 2020
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Thu, 8 Oct 2020 06:55:32 GMT
Subject: RFR: 8242882: opening jar file with large manifest might throw
 NegativeArraySizeException [v2]
In-Reply-To: <Oe050_7zFhKQLYJKt5qwCCycXM_843Id3NLkVSnJ4os=.5f23a096-0b18-48bb-8ee9-69372d6407c3@github.com>
References: <17lthSuYGInBHE2r3hBs0yXvMIZWWQkdLhYYBfRUMfM=.b59db398-6dc4-4b34-b141-2c58f189bce8@github.com>
 <Eyd8QE33uB1pr8qEtknKqPwJUXzxuvQnkb_LzUHg858=.16a8fb43-c74c-40d6-a681-ffcc4a5ac42a@github.com>
 <JSDhWxPp22Zr5vWtjs0iveljOW1Ej0WycVdbRHzqPEA=.dfa9db34-b7b2-440e-9bca-0c19dc450b48@github.com>
 <tsp044AyIttSb2D8mVDj9VneD6nK61iEFu7Af0uvJTk=.e96dbe4a-5e2b-44ef-ad36-9df1bde90ce4@github.com>
 <Oe050_7zFhKQLYJKt5qwCCycXM_843Id3NLkVSnJ4os=.5f23a096-0b18-48bb-8ee9-69372d6407c3@github.com>
Message-ID: <Ez1_RAFADLTu6srH8sRkJtfkC6hH0IOfTiTCtxNU3vI=.4df9012f-9588-46ac-a3b9-0ca48e1d5138@github.com>

On Wed, 7 Oct 2020 21:40:43 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> I decided to slightly change the way this large manifest file was being created. I borrowed the idea from
>> `Zip64SizeTest`[1] to create the file and set its length to a large value. I hope that is OK. If not, let me know, I
>> will change this part.  [1]
>> https://github.com/openjdk/jdk/blob/master/test/jdk/java/util/zip/ZipFile/Zip64SizeTest.java#L121
>
> I did some automated test runs, and the duration of this test is sufficiently improved, IMO.
> 
> While not representative of a real MANIFEST.MF file, I think it works well enough for this specific test.

Thank you for the review Brent.

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

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

From github.com+70893615+jasontatton-aws at openjdk.java.net  Thu Oct  8 06:55:15 2020
From: github.com+70893615+jasontatton-aws at openjdk.java.net (Jason Tatton)
Date: Thu, 8 Oct 2020 06:55:15 GMT
Subject: RFR: 8173585: Intrinsify StringLatin1.indexOf(char) [v5]
In-Reply-To: <_T0873dC5tfUtGn9r1_Y21JkPKRt-za3MM9hPN2GQKQ=.b865fe53-5417-424f-81b6-1566a330640e@github.com>
References: <_T0873dC5tfUtGn9r1_Y21JkPKRt-za3MM9hPN2GQKQ=.b865fe53-5417-424f-81b6-1566a330640e@github.com>
Message-ID: <sZhfgkcrUpodR1P4iAmcERpYkV2VUB89YpKSu8bd9Ag=.00039d99-18be-44c5-bca6-12ec4be12950@github.com>

> This is an implementation of the indexOf(char) intrinsic for StringLatin1 (1 byte encoded Strings). It is provided for
> x86 and ARM64. The implementation is greatly inspired by the indexOf(char) intrinsic for StringUTF16. To incorporate it
> I had to make a small change to StringLatin1.java (refactor of functionality to intrisified private method) as well as
> code for C2.  Submitted to: hotspot-compiler-dev and core-libs-dev as this patch contains a change to hotspot and
> java/lang/StringLatin1.java  https://bugs.openjdk.java.net/browse/JDK-8173585
> 
> Details of testing:
> ============
> I have created a jtreg test ?compiler/intrinsics/string/TestStringLatin1IndexOfChar? to cover this new intrinsic. Note
> that, particularly for the x86 implementation of the intrinsic, the code path taken is dependent upon the length of the
> input String. Hence the test has been designed to cover all these cases. In summary they are:
> - A ?short? string of < 16 characters.
> - A SIMD String of 16 ? 31 characters.
> - A AVX2 SIMD String of 32 characters+.
> 
> Hardware used for testing:
> -----------------------------
> 
> - Intel Xeon CPU E5-2680 (JVM did not recognize this as having AVX2 support) ? Intel i7 processor (with AVX2 support).
> - AWS Graviton 2 (ARM 64 processor).
> 
> I also ran; ?run-test-tier1? and ?run-test-tier2? for: x86_64 and aarch64.
> 
> Possible future enhancements:
> ====================
> For the x86 implementation there may be two further improvements we can make in order to improve performance of both
> the StringUTF16 and StringLatin1 indexOf(char) intrinsics:
> 1. Make use of AVX-512 instructions.
> 2. For ?short? Strings (see below), I think it may be possible to modify the existing algorithm to still use SSE SIMD
> instructions instead of a loop.
> Benchmark results:
> ============
> **Without** the new StringLatin1 indexOf(char) intrinsic:
> 
> | Benchmark  | Mode | Cnt | Score | Error | Units |
> | ------------- | ------------- |------------- |------------- |------------- |------------- |
> | IndexOfBenchmark.latin1_mixed_char | avgt | 5 | **26,389.129** | ? 182.581 | ns/op |
> | IndexOfBenchmark.utf16_mixed_char | avgt | 5 | 17,885.383 | ? 435.933  | ns/op |
> 
> 
> **With** the new StringLatin1 indexOf(char) intrinsic:
> 
> | Benchmark  | Mode | Cnt | Score | Error | Units |
> | ------------- | ------------- |------------- |------------- |------------- |------------- |
> | IndexOfBenchmark.latin1_mixed_char | avgt | 5 | **17,875.185** | ? 407.716  | ns/op |
> | IndexOfBenchmark.utf16_mixed_char | avgt | 5 | 18,292.802 | ? 167.306  | ns/op |
> 
> 
> The objective of the patch is to bring the performance of StringLatin1 indexOf(char) in line with StringUTF16
> indexOf(char) for x86 and ARM64. We can see above that this has been achieved. Similar results were obtained when
> running on ARM.

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

  8173585: Intrinsify StringLatin1.indexOf(char)
  
  Added new unit test: findOneItem. This will test strings of varying
  length ensuring that for all lengths one instance of the search char can
  be found. We check what happens when the search character is in each
  position of the search string (including first and last positions).

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/71/files
  - new: https://git.openjdk.java.net/jdk/pull/71/files/c8a2849e..8ead02ab

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

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

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

From github.com+70893615+jasontatton-aws at openjdk.java.net  Thu Oct  8 06:55:53 2020
From: github.com+70893615+jasontatton-aws at openjdk.java.net (Jason Tatton)
Date: Thu, 8 Oct 2020 06:55:53 GMT
Subject: RFR: 8173585: Intrinsify StringLatin1.indexOf(char) [v4]
In-Reply-To: <X8Hfl3jQXkQM5Bi61VHw1HDfba-FqXcyjPh_r0LZwSA=.b4aaf2ff-a969-4fd0-9e05-cd7708fc0b1e@github.com>
References: <_T0873dC5tfUtGn9r1_Y21JkPKRt-za3MM9hPN2GQKQ=.b865fe53-5417-424f-81b6-1566a330640e@github.com>
 <Zw-pc6-7I0QmKg9KVIDxG3CKtK4ZRGrgID0J0UsNHoc=.b0cfcc25-801c-4611-b501-f3d67c5ef347@github.com>
 <X8Hfl3jQXkQM5Bi61VHw1HDfba-FqXcyjPh_r0LZwSA=.b4aaf2ff-a969-4fd0-9e05-cd7708fc0b1e@github.com>
Message-ID: <uAIqz-jbivBhLHVvivlFdSH8hnnLr3GrZu7P9-RU_BI=.e13c7af7-7640-4f6b-8668-0c7e468d9e86@github.com>

On Tue, 6 Oct 2020 20:18:02 GMT, Nils Eliasson <neliasso at openjdk.org> wrote:

>> Jason Tatton has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8173585: Intrinsify StringLatin1.indexOf(char)
>>   
>>   Rewrite of unit test and newlines added to end of files
>>   
>>   Changes to unit test:
>>   - main test adjusted such that Strings gennerated are much longer (up to
>>   2048 characters) and of the form: azaza, aazaazaa, aaazaaazaaa, etc with
>>   'z' being the search character searched for. Multiple instances of the
>>   search character are included in the String in order to validate that
>>   the starting offset is correctly handleded. Results are compared to non
>>   intrinsified version of the code. Longer strings means that the looping
>>   functionality of the various paths is entered into.
>>   - Run configurations introduced such that it checks behaviour where use
>>   of SSE and AVX instructions are restricted.
>>   - Tier4InvocationThreshold adjusted so as to ensure C2 code iis invoked.
>>   
>>   Other changes:
>>   - newlines added at end of files
>
> test/hotspot/jtreg/compiler/intrinsics/string/TestStringLatin1IndexOfChar.java line 25:
> 
>> 23: import jdk.test.lib.Asserts;
>> 24:
>> 25: public class TestStringLatin1IndexOfChar{
> 
> Can you please add testing for these edge cases:
> - when the search char is the first char
> - when the search char is the last char
> - when the string has length 1

Thanks for reviewing this. I have added a new test: `findOneItem` which covers these edge cases

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

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

From iignatyev at openjdk.java.net  Thu Oct  8 06:58:42 2020
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Thu, 8 Oct 2020 06:58:42 GMT
Subject: Integrated: 8254096: remove
 jdk.test.lib.Utils::getMandatoryProperty(String) method
In-Reply-To: <cJ3C3wcBvwmya8DPeOCNSnkLPiE1t2ajKgF-yG-fu_8=.ab77ef50-15b4-488f-85df-5d129ee1aa12@github.com>
References: <cJ3C3wcBvwmya8DPeOCNSnkLPiE1t2ajKgF-yG-fu_8=.ab77ef50-15b4-488f-85df-5d129ee1aa12@github.com>
Message-ID: <UFjzF3wN6jC6AEEtNvq5hNZeQsCmzyFmKdfLuN-qmog=.6e3ce452-8eb9-472e-8860-24ad56282ab5@github.com>

On Tue, 6 Oct 2020 20:54:50 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small and trivial cleanup that removes `getMandatoryProperty` method from
> `jdk.test.lib.Utils` as it's unused?
> Thanks,
> -- Igor

This pull request has now been integrated.

Changeset: 9cdfd0fa
Author:    Igor Ignatyev <iignatyev at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/9cdfd0fa
Stats:     13 lines in 1 file changed: 0 ins; 13 del; 0 mod

8254096: remove jdk.test.lib.Utils::getMandatoryProperty(String) method

Reviewed-by: shade

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

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

From minqi at openjdk.java.net  Thu Oct  8 06:59:23 2020
From: minqi at openjdk.java.net (Yumin Qi)
Date: Thu, 8 Oct 2020 06:59:23 GMT
Subject: RFR: 8247536: Support for pre-generated java.lang.invoke classes
 in CDS static archive [v14]
In-Reply-To: <Y_Bas-poGnDtvcJbqbmeIAPQRNxzvarBToQWALn9TTE=.e846cd3c-0e7b-48d3-8ffa-be3c03acffb0@github.com>
References: <Y_Bas-poGnDtvcJbqbmeIAPQRNxzvarBToQWALn9TTE=.e846cd3c-0e7b-48d3-8ffa-be3c03acffb0@github.com>
Message-ID: <oUacrMNemRVxwjFpz3sYgbNVVI6Ycn5ee2_AaHiKCr0=.04a3942b-c0af-4266-b7b6-f8767df62296@github.com>

> This patch is reorganized after 8252725, which is separated from this patch to refactor jlink glugin code. The previous
> webrev with hg can be found at: http://cr.openjdk.java.net/~minqi/2020/8247536/webrev-05. With 8252725 integrated, the
> regeneration of holder classes is simply to call the new added GenerateJLIClassesHelper.cdsGenerateHolderClasses
> function.  Tests: tier1-4

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

  Made isDumpingClassList a private final and add a public function to access it. Changed function validateInputLines to
  isValidInputLines and return a boolean to indicate its valid. Added more comments for review concern.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/193/files
  - new: https://git.openjdk.java.net/jdk/pull/193/files/107192f3..f163fe4c

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

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

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

From mchung at openjdk.java.net  Thu Oct  8 06:59:55 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Thu, 8 Oct 2020 06:59:55 GMT
Subject: RFR: 8247536: Support for pre-generated java.lang.invoke classes
 in CDS static archive [v12]
In-Reply-To: <9emWKl6fr-GA5LN0uHhuEd5D123QcoCiHQR1M9bAbag=.cc4b6129-8b33-47e4-a421-9e6b4817933b@github.com>
References: <Y_Bas-poGnDtvcJbqbmeIAPQRNxzvarBToQWALn9TTE=.e846cd3c-0e7b-48d3-8ffa-be3c03acffb0@github.com>
 <9emWKl6fr-GA5LN0uHhuEd5D123QcoCiHQR1M9bAbag=.cc4b6129-8b33-47e4-a421-9e6b4817933b@github.com>
Message-ID: <-y8lEorT3v4i2G_yBbrmd6faeU584CXFnPEiM8GcPec=.d9e8a152-c319-43dc-a6d1-f745b7eccb20@github.com>

On Tue, 6 Oct 2020 20:46:17 GMT, Yumin Qi <minqi at openjdk.org> wrote:

>> This patch is reorganized after 8252725, which is separated from this patch to refactor jlink glugin code. The previous
>> webrev with hg can be found at: http://cr.openjdk.java.net/~minqi/2020/8247536/webrev-05. With 8252725 integrated, the
>> regeneration of holder classes is simply to call the new added GenerateJLIClassesHelper.cdsGenerateHolderClasses
>> function.  Tests: tier1-4
>
> Yumin Qi has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains
> 23 commits:
>  - Added new separate function to CDS for logging species and modified the existing function to log lambda form invokers.
>    Changed isDumpLoadedClassList to a reasonable name isDumpingClassList as read only in CDS.
>  - Merge branch 'master' of https://github.com/openjdk/jdk into jdk-8247536
>  - Removed unused imports.
>  - Fixed comments with correct class and method name in CDS, removed unused variables after last change.
>  - Moved and renamed cdsGenerateHolderClasses from GenerateJLIClassesHelp to CDS as generateLambdaFormHolderClasses. Added
>    input verification function in CDS before class generation. Added more test scenarios. Removed trailing unused ending
>    words for output of lambda form trace line in case of DumpLoadedClassList.
>  - Move the check work to java, restore code in VM. Modified test code according to the changes. The invoke name
>    verififcation is not implemented since not all the holder class are processed, not all the functions of processed
>    holder classes are added. For holder class with DirectMethodHandle in its name, only the name in the
>    DMH_METHOD_TYPE_MAP keyset is added, ithe line with other names just gets skipped silently. This makes the verification
>    on invoke names difficul, a name not in the keyset should not fail the test. Also add a boolean to
>    cdsGenerateHolderClasses to indicate call path.
>  - Remove trailing word of line which is not used in holder class regeneration. There is a trailing LF (Line Feed) so trim
>    white spaces from both front and end of the line or it will fail method type validation.
>  - In case of exception happens during reloading class, CHECK will return without free the allocated buffer for class
>    bytes so moved the buffer allocation and freeing to caller. Also removed test 6 since there is not guarantee that we
>    can give a signature which will always fail. Additional changes to GenerateJLIClassesHelper according to review
>    suggestion.
>  - Merge branch 'master' of https://github.com/openjdk/jdk into jdk-8247536
>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into jdk-8247536
>  - ... and 13 more: https://git.openjdk.java.net/jdk/compare/82fe023b...f5584dcf

src/java.base/share/classes/jdk/internal/misc/CDS.java line 40:

> 38:       * indicator for dumping class list.
> 39:       */
> 40:     static public final boolean isDumpingClassList;

what about making this a private static field and adding a public static `isDumpingClassList()` method (which was in
the previous version).

src/java.base/share/classes/jdk/internal/misc/CDS.java line 144:

> 142:             String line = s.trim();
> 143:             if (!line.startsWith("[LF_RESOLVE]") && !line.startsWith("[SPECIES_RESOLVE]")) {
> 144:                 System.out.println("Wrong prefix: " + line);

Should this throw an exception instead?

src/java.base/share/classes/jdk/internal/misc/CDS.java line 155:

> 153:                     System.out.println("Incorrecct number of items in the line: " + parts.length);
> 154:                     System.out.println("line: " + line);
> 155:                     return null;

I think these error cases should throw `IllegalArgumentException` and VM decides how to handle the exception.

src/java.base/share/classes/jdk/internal/misc/CDS.java line 140:

> 138:     // return null for invalid input
> 139:     private static Stream<String>  validateInputLines(String[] lines) {
> 140:         ArrayList<String> list = new ArrayList<String>(lines.length);

Nit: this can use diamond operatior like this: `new ArrayList<>(lines.length)`.

src/java.base/share/classes/jdk/internal/misc/CDS.java line 184:

> 182:         Objects.requireNonNull(lines);
> 183:         try {
> 184:             Stream<String> lineStream = validateInputLines(lines);

It seems clearer to have `validateInputLines` do validation only and convert this line into:

  validateInputLines(lines);
  Stream<String> lineStream = Arrays.stream(lines);

src/java.base/share/classes/jdk/internal/misc/CDS.java line 178:

> 176:     /**
> 177:      * called from vm to generate MethodHandle holder classes
> 178:      * @return @code { Object[] } if holder classes can be generated.

type: `s/@code { Object[]/{@code Object[]}`

src/java.base/share/classes/jdk/internal/misc/CDS.java line 198:

> 196:             return retArray;
> 197:         } catch (Exception e) {
> 198:             e.printStackTrace();

Is this a debugging statement?   If CDS swallows the exception thrown, I think VM should emit the warning message and
print the stack trace if appropriate.

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

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

From minqi at openjdk.java.net  Thu Oct  8 07:00:27 2020
From: minqi at openjdk.java.net (Yumin Qi)
Date: Thu, 8 Oct 2020 07:00:27 GMT
Subject: RFR: 8247536: Support for pre-generated java.lang.invoke classes
 in CDS static archive [v12]
In-Reply-To: <-y8lEorT3v4i2G_yBbrmd6faeU584CXFnPEiM8GcPec=.d9e8a152-c319-43dc-a6d1-f745b7eccb20@github.com>
References: <Y_Bas-poGnDtvcJbqbmeIAPQRNxzvarBToQWALn9TTE=.e846cd3c-0e7b-48d3-8ffa-be3c03acffb0@github.com>
 <9emWKl6fr-GA5LN0uHhuEd5D123QcoCiHQR1M9bAbag=.cc4b6129-8b33-47e4-a421-9e6b4817933b@github.com>
 <-y8lEorT3v4i2G_yBbrmd6faeU584CXFnPEiM8GcPec=.d9e8a152-c319-43dc-a6d1-f745b7eccb20@github.com>
Message-ID: <ZqLP6m_KzPnPYSUT9_q-9FjGTQseGinzIxTrAb7tEzg=.80449d75-314d-42ab-9bfb-6fe61f5eea6d@github.com>

On Wed, 7 Oct 2020 20:36:18 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Yumin Qi has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains
>> 23 commits:
>>  - Added new separate function to CDS for logging species and modified the existing function to log lambda form invokers.
>>    Changed isDumpLoadedClassList to a reasonable name isDumpingClassList as read only in CDS.
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into jdk-8247536
>>  - Removed unused imports.
>>  - Fixed comments with correct class and method name in CDS, removed unused variables after last change.
>>  - Moved and renamed cdsGenerateHolderClasses from GenerateJLIClassesHelp to CDS as generateLambdaFormHolderClasses. Added
>>    input verification function in CDS before class generation. Added more test scenarios. Removed trailing unused ending
>>    words for output of lambda form trace line in case of DumpLoadedClassList.
>>  - Move the check work to java, restore code in VM. Modified test code according to the changes. The invoke name
>>    verififcation is not implemented since not all the holder class are processed, not all the functions of processed
>>    holder classes are added. For holder class with DirectMethodHandle in its name, only the name in the
>>    DMH_METHOD_TYPE_MAP keyset is added, ithe line with other names just gets skipped silently. This makes the verification
>>    on invoke names difficul, a name not in the keyset should not fail the test. Also add a boolean to
>>    cdsGenerateHolderClasses to indicate call path.
>>  - Remove trailing word of line which is not used in holder class regeneration. There is a trailing LF (Line Feed) so trim
>>    white spaces from both front and end of the line or it will fail method type validation.
>>  - In case of exception happens during reloading class, CHECK will return without free the allocated buffer for class
>>    bytes so moved the buffer allocation and freeing to caller. Also removed test 6 since there is not guarantee that we
>>    can give a signature which will always fail. Additional changes to GenerateJLIClassesHelper according to review
>>    suggestion.
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into jdk-8247536
>>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into jdk-8247536
>>  - ... and 13 more: https://git.openjdk.java.net/jdk/compare/82fe023b...f5584dcf
>
> src/java.base/share/classes/jdk/internal/misc/CDS.java line 144:
> 
>> 142:             String line = s.trim();
>> 143:             if (!line.startsWith("[LF_RESOLVE]") && !line.startsWith("[SPECIES_RESOLVE]")) {
>> 144:                 System.out.println("Wrong prefix: " + line);
> 
> Should this throw an exception instead?

This part is for check the format only, throw exceptions will lead more objects generated which should not be archived
in shared heap. Since this is only called from VM, so decide not to throw exception here.

> src/java.base/share/classes/jdk/internal/misc/CDS.java line 40:
> 
>> 38:       * indicator for dumping class list.
>> 39:       */
>> 40:     static public final boolean isDumpingClassList;
> 
> what about making this a private static field and adding a public static `isDumpingClassList()` method (which was in
> the previous version).

That will have a name for two properties, if you that is OK, I will use the previous version.

> src/java.base/share/classes/jdk/internal/misc/CDS.java line 155:
> 
>> 153:                     System.out.println("Incorrecct number of items in the line: " + parts.length);
>> 154:                     System.out.println("line: " + line);
>> 155:                     return null;
> 
> I think these error cases should throw `IllegalArgumentException` and VM decides how to handle the exception.

Same reason as above.

> src/java.base/share/classes/jdk/internal/misc/CDS.java line 140:
> 
>> 138:     // return null for invalid input
>> 139:     private static Stream<String>  validateInputLines(String[] lines) {
>> 140:         ArrayList<String> list = new ArrayList<String>(lines.length);
> 
> Nit: this can use diamond operatior like this: `new ArrayList<>(lines.length)`.

Will update.

> src/java.base/share/classes/jdk/internal/misc/CDS.java line 184:
> 
>> 182:         Objects.requireNonNull(lines);
>> 183:         try {
>> 184:             Stream<String> lineStream = validateInputLines(lines);
> 
> It seems clearer to have `validateInputLines` do validation only and convert this line into:
> 
>   validateInputLines(lines);
>   Stream<String> lineStream = Arrays.stream(lines);

Somewhere in the testing framework, the line in ExtraClassList was added '\f' which needs trim, I did not dig into deep
the  root cause so here just return a new List with ending white spaces trimmed instead. I will file a bug for it and
when it fixed, we can do this way.

> src/java.base/share/classes/jdk/internal/misc/CDS.java line 178:
> 
>> 176:     /**
>> 177:      * called from vm to generate MethodHandle holder classes
>> 178:      * @return @code { Object[] } if holder classes can be generated.
> 
> type: `s/@code { Object[]/{@code Object[]}`

Will update

> src/java.base/share/classes/jdk/internal/misc/CDS.java line 198:
> 
>> 196:             return retArray;
>> 197:         } catch (Exception e) {
>> 198:             e.printStackTrace();
> 
> Is this a debugging statement?   If CDS swallows the exception thrown, I think VM should emit the warning message and
> print the stack trace if appropriate.

I want to print this in java since in VM it is a little complex than java. It just used to give the stack trace where
the exception happened for debug purpose. Maybe I should put comment for it.

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

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

From iignatyev at openjdk.java.net  Thu Oct  8 07:00:52 2020
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Thu, 8 Oct 2020 07:00:52 GMT
Subject: Integrated: 8254182: remove Utils.tryFindJvmPid/waitForJvmPid
In-Reply-To: <PJ004YhperkSBd_Yv_xKVE9UEhrPC5CYqwf0P03GWSY=.9b362dec-237b-4596-8f42-dc33482859c8@github.com>
References: <PJ004YhperkSBd_Yv_xKVE9UEhrPC5CYqwf0P03GWSY=.9b362dec-237b-4596-8f42-dc33482859c8@github.com>
Message-ID: <e7C1dmZzyicCjrDxbSmCl-SiSP0DiFy6ISedCzvxISs=.228621c1-9769-42c3-a404-71fe765d2ca5@github.com>

On Wed, 7 Oct 2020 19:01:45 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> `jdk.test.lib.Utils::tryFindJvmPid` and `waitForJvmPid` methods aren't used and should be removed

This pull request has now been integrated.

Changeset: 7733a0e7
Author:    Igor Ignatyev <iignatyev at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/7733a0e7
Stats:     57 lines in 1 file changed: 0 ins; 57 del; 0 mod

8254182: remove Utils.tryFindJvmPid/waitForJvmPid

Reviewed-by: rriggs

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

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

From cstein at openjdk.java.net  Thu Oct  8 07:01:00 2020
From: cstein at openjdk.java.net (Christian Stein)
Date: Thu, 8 Oct 2020 07:01:00 GMT
Subject: RFR: 8248262: Wrong link target in ModuleDescriptor#isAutomatic's API
 documentation
Message-ID: <U3wL-HedLhbvGMdMAEXGltPnkvlZ58eusHwDYy3_hA8=.4fe9f27d-3907-4f1a-8d5f-79d30fa8734a@github.com>

Fix target in `ModuleDescriptor#isAutomatic`'s API documentation to point to `Modifier.AUTOMATIC`.

https://bugs.openjdk.java.net/browse/JDK-8248262

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

Commit messages:
 - Fix link target in ModuleDescriptor#isAutomatic's API documentation

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

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

From alanb at openjdk.java.net  Thu Oct  8 07:01:01 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 8 Oct 2020 07:01:01 GMT
Subject: RFR: 8248262: Wrong link target in ModuleDescriptor#isAutomatic's
 API documentation
In-Reply-To: <U3wL-HedLhbvGMdMAEXGltPnkvlZ58eusHwDYy3_hA8=.4fe9f27d-3907-4f1a-8d5f-79d30fa8734a@github.com>
References: <U3wL-HedLhbvGMdMAEXGltPnkvlZ58eusHwDYy3_hA8=.4fe9f27d-3907-4f1a-8d5f-79d30fa8734a@github.com>
Message-ID: <DFoPe98oL6lhDHNRrWtsMpRHxO43tnMAvcGg3OopoQM=.ad33bb60-8e2f-4927-ae71-d198ab670bbf@github.com>

On Thu, 8 Oct 2020 06:33:06 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Fix target in `ModuleDescriptor#isAutomatic`'s API documentation to point to `Modifier.AUTOMATIC`.
> 
> https://bugs.openjdk.java.net/browse/JDK-8248262

Marked as reviewed by alanb (Reviewer).

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

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

From cstein at openjdk.java.net  Thu Oct  8 07:15:51 2020
From: cstein at openjdk.java.net (Christian Stein)
Date: Thu, 8 Oct 2020 07:15:51 GMT
Subject: Integrated: 8248262: Wrong link target in
 ModuleDescriptor#isAutomatic's API documentation
In-Reply-To: <U3wL-HedLhbvGMdMAEXGltPnkvlZ58eusHwDYy3_hA8=.4fe9f27d-3907-4f1a-8d5f-79d30fa8734a@github.com>
References: <U3wL-HedLhbvGMdMAEXGltPnkvlZ58eusHwDYy3_hA8=.4fe9f27d-3907-4f1a-8d5f-79d30fa8734a@github.com>
Message-ID: <FDxnLKOKMTrPneD_lpb_DA-b-ummpLkNKeR8rnxvsAI=.e6f836c2-2824-43c0-a0fe-e60289320524@github.com>

On Thu, 8 Oct 2020 06:33:06 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Fix target in `ModuleDescriptor#isAutomatic`'s API documentation to point to `Modifier.AUTOMATIC`.
> 
> https://bugs.openjdk.java.net/browse/JDK-8248262

This pull request has now been integrated.

Changeset: e1187c40
Author:    Christian Stein <cstein at openjdk.org>
Committer: Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e1187c40
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8248262: Wrong link target in ModuleDescriptor#isAutomatic's API documentation

Reviewed-by: alanb

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

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

From shade at openjdk.java.net  Thu Oct  8 07:44:43 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 8 Oct 2020 07:44:43 GMT
Subject: RFR: 8254162: Implementation of Foreign-Memory Access API (Third
 Incubator)
In-Reply-To: <IngRk57F78UN3yySfo6IABbdwnMogGNdYrykh_3em-c=.b81f7478-015c-45ed-9788-58d7519a2770@github.com>
References: <IngRk57F78UN3yySfo6IABbdwnMogGNdYrykh_3em-c=.b81f7478-015c-45ed-9788-58d7519a2770@github.com>
Message-ID: <2m-ZUtCAOMDADZVduYjzmcNHYziHMIC3axl1CNolulo=.4e19ccf9-4320-434d-b8c3-b186f74f1b5e@github.com>

On Wed, 7 Oct 2020 17:13:22 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

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

Drive-by review.

src/hotspot/share/prims/scopedMemoryAccess.cpp line 1:

> 1:

Misses copyright header.

src/hotspot/share/prims/scopedMemoryAccess.cpp line 81:

> 79:       CompiledMethod* cm = last_frame.cb()->as_compiled_method();
> 80:
> 81:       //FIXME: this doesn't work if reachability fences are violated by C2

Maybe turn this into /* */ block, so that it is obvious the whole thing relates to the `FIXME`?

src/hotspot/share/prims/scopedMemoryAccess.cpp line 96:

> 94:     int depth = 0;
> 95:     vframeStream stream(jt);
> 96:     for (; !stream.at_end(); stream.next()) {

Can move `stream` initialization right into the `for` statement?

src/hotspot/share/prims/scopedMemoryAccess.cpp line 138:

> 136: /// JVM_RegisterUnsafeMethods
> 137:
> 138: #define LANG "Ljdk/internal/misc/"

This is weirdly defined as `LANG`. I suppose this would change to `Ljava/lang` soon. But maybe `PACKAGE` is better.

src/hotspot/share/prims/scopedMemoryAccess.cpp line 130:

> 128:  * Top frames containg obj will be deoptimized.
> 129:  */
> 130: JVM_ENTRY(jboolean, ScopedMemoryAccess_closeScope(JNIEnv *env, jobject receiver, jobject deopt, jobject
> exception)) {

`JVM_ENTRY` does not require a brace, it is braced already. See existing uses of `JVM_ENTRY`.

src/hotspot/share/prims/scopedMemoryAccess.cpp line 134:

> 132:   Handshake::execute(&cl);
> 133:   return !cl._found;
> 134: } JVM_END

Ditto for `JVM_END`.

src/hotspot/share/prims/scopedMemoryAccess.cpp line 166:

> 164:   int ok = env->RegisterNatives(scopedMemoryAccessClass, jdk_internal_misc_ScopedMemoryAccess_methods,
> sizeof(jdk_internal_misc_ScopedMemoryAccess_methods)/sizeof(JNINativeMethod)); 165:   guarantee(ok == 0, "register
> jdk.internal.misc.ScopedMemoryAccess natives"); 166: } JVM_END

`JVM_ENTRY`/`JVM_END` braces again.

src/java.base/share/classes/java/lang/invoke/MemoryAccessVarHandleBase.java line 45:

> 43:     final boolean skipAlignmentMaskCheck;
> 44:
> 45:     MemoryAccessVarHandleBase(VarForm form, boolean skipOffetCheck, boolean be, long length, long alignmentMask) {

Typo: `skipOff*s*etCheck`. Should it be `skipAlignmentMaskCheck` to begin with?

test/jdk/java/foreign/TestMismatch.java line 26:

> 24: /*
> 25:  * @test
> 26:  * @run testng/othervm -XX:MaxDirectMemorySize=5000000000 TestMismatch

Whoa, allocating 5 GB? That might fail on 32-bit platforms... Anyhow, this flag accepts suffixes, so
`-XX:MaxDirectMemorySize=5g`.

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

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

From kim.barrett at oracle.com  Thu Oct  8 07:52:50 2020
From: kim.barrett at oracle.com (Kim Barrett)
Date: Thu, 8 Oct 2020 03:52:50 -0400
Subject: RFR: 8188055: (ref) Add Reference::refersTo predicate
In-Reply-To: <lNHgojO3Jrdaaq9RPiRq4IexTIjxVunPQKWg3f02m34=.d6c68bfd-b622-46b8-8737-be1cee2765f0@github.com>
References: <D4HSg8FT20Eaxk5KJkkw0GgETSxRkBn1ipS3Dt0kPto=.e4bab078-2e04-4413-90cb-9bfafb2a6831@github.com>
 <lNHgojO3Jrdaaq9RPiRq4IexTIjxVunPQKWg3f02m34=.d6c68bfd-b622-46b8-8737-be1cee2765f0@github.com>
Message-ID: <5B1C51BB-8BF4-4DC8-A714-AC087303E0C0@oracle.com>

> On Oct 5, 2020, at 7:04 AM, Per Liden <pliden at openjdk.java.net> wrote:
> test/hotspot/jtreg/gc/TestReferenceRefersTo.java line 179:
> 
>> 177:             // For some collectors, calling get() will keep testObject4 alive.
>> 178:             // For example, SATB collectors or ZGC, but not collectors using
>> 179:             // incremental update barriers like CMS.
> 
> Remove obsolete CMS comment?

I'll just delete lines 178-9.

> test/hotspot/jtreg/gc/TestReferenceRefersTo.java line 65:
> 
>> 63:
>> 64:     private static WeakReference<TestObject> testWeak2 = null;
>> 65:     private static WeakReference<TestObject> testWeak3 = null;
> 
> It looks like test*2 and test*3 test the same thing in both tests, so test*3 could be removed, and test*4 could be
> renamed test*3.

The test seems to be missing some stuff. This looks like the test from the
webrev back in April too. I looked through some backups and never published
webrevs and found some other versions, but nothing that looks like the final
version I remember. Oh well. So I'm adding some additional checks that make
the 2 & 3 cases differ as intended.

> src/hotspot/share/prims/jvm.cpp line 3446:
> 
>> 3444:   oop referent = HeapAccess<on_ref | AS_NO_KEEPALIVE>::oop_load_at(ref_oop, offset);
>> 3445:   return referent == JNIHandles::resolve(o);
>> 3446: }
> 
> How about moving the inner logic to java_lang_ref_{Reference,PhantomReference}::refers_to() functions?

I think refersTo functionality doesn't really belong in
java_lang_ref_Reference.  I would rather keep the refersTo implementation in
jvm.cpp, but change the implementation from bare Access to using something
like java_lang_ref_Reference::referent.

But it seems referent() does something rather wrong. It's doing a strong
access, and that just happens to "work" because the places calling it are
code paths that are only used when a strong access doesn't do anything
special.  I think those places ought to instead be using ON_UNKNOWN_OOP_REF
and AS_NO_KEEPALIVE.  I'm making some changes there and changing jvm.cpp
accordingly. 


From kim.barrett at oracle.com  Thu Oct  8 07:54:26 2020
From: kim.barrett at oracle.com (Kim Barrett)
Date: Thu, 8 Oct 2020 03:54:26 -0400
Subject: RFR: 8188055: (ref) Add Reference::refersTo predicate
In-Reply-To: <Y1IHoNr8vO3OkCbEKw6ywXd4adik1yKKNIS4ABzF0d0=.d21f4183-ef4e-45ed-826d-6613215b6220@github.com>
References: <D4HSg8FT20Eaxk5KJkkw0GgETSxRkBn1ipS3Dt0kPto=.e4bab078-2e04-4413-90cb-9bfafb2a6831@github.com>
 <Y1IHoNr8vO3OkCbEKw6ywXd4adik1yKKNIS4ABzF0d0=.d21f4183-ef4e-45ed-826d-6613215b6220@github.com>
Message-ID: <C7C055C1-F1DB-491D-BC63-3F14303EEF7B@oracle.com>

> On Oct 5, 2020, at 8:22 PM, Mandy Chung <mchung at openjdk.java.net> wrote:
> 
> Can you add a unit test in `test/jdk/java/lang/ref` that serves as a basic API test for this new `refersTo` API without
> depending the WhiteBox API?     test/hotspot/jtreg/gc` test serves as a more white-boxed type and comprehensive test.

Adding test/jdk/java/lang/ref/ReferenceRefersTo.java

> src/java.base/share/classes/java/lang/ref/Reference.java line 361:
> 
>> 359:
>> 360:     /* Type-erased implementation of refersTo(). */
>> 361:     native boolean refersTo0(Object o);
> 
> Is there any reason why it can't use the parameter type like `refersTo0(T o)`?  Same for `PhantomReference::refersTo0(T
> o)`

I incorrectly assumed there would be a problem with determining the type of
the C function that implements the native method, but it seems the type
parameter gets erased to Object automatically.  So the signature taking
Object is really just truth in advertising, whereas using the parameterized
type is kind of lying (even more so than is usual for Java generics).  There
is also Daniel's question to consider.  So I haven't made any change here
yet.

> src/hotspot/share/include/jvm.h line 334:
> 
>> 332:  */
>> 333: JNIEXPORT jboolean JNICALL
>> 334: JVM_PhantomReferenceRefersTo(JNIEnv *env, jobject ref, jobject o);
> 
> Instead of a separate `PhantomReference::refersTo0` native method (and new PhantomReference.c), an alternative approach
> could be to detect if `ref` is an instance of `PhantomReference`  or other `Reference` and get the referent accordingly.

See response to Roger's question about refersTo0.


From kim.barrett at oracle.com  Thu Oct  8 07:55:40 2020
From: kim.barrett at oracle.com (Kim Barrett)
Date: Thu, 8 Oct 2020 03:55:40 -0400
Subject: RFR: 8188055: (ref) Add Reference::refersTo predicate
In-Reply-To: <65nW4xib46bbLUqxAEzQh2ep0m-44hr-lTXVHaJKEAg=.f413edc7-bce7-47cb-a9eb-4fc918afb408@github.com>
References: <D4HSg8FT20Eaxk5KJkkw0GgETSxRkBn1ipS3Dt0kPto=.e4bab078-2e04-4413-90cb-9bfafb2a6831@github.com>
 <65nW4xib46bbLUqxAEzQh2ep0m-44hr-lTXVHaJKEAg=.f413edc7-bce7-47cb-a9eb-4fc918afb408@github.com>
Message-ID: <F46DE5AC-99DF-4CFA-90CB-3D402B967906@oracle.com>

> On Oct 5, 2020, at 9:15 PM, Roger Riggs <rriggs at openjdk.java.net> wrote:
> src/java.base/share/classes/java/lang/ref/PhantomReference.java line 66:
> 
>> 64:     @Override
>> 65:     native final boolean refersTo0(Object o);
>> 66:
> 
> How does the existence of this method help future intrinsification?
> If it was called somewhere it would be clearer.
> Perhaps a comment now or later would help explain its function.

public final refersTo(T o) calls refersTo0(o)

We have package private:
      native boolean Reference::refersTo0(Object)
final native boolean PhantomReference::refersTo0(Object)

The reason for this split has to do with details in the VM support, in
particular C2 intrinsification.

For the native method support we don't need this split.  The original
version from back in April just had a single native method in Reference. (It
did have native refersTo0, but that was my not realizing native methods
could have a parameterized type that would get type-erased automatically;
see response to Mandy.)  That native method performed a runtime check on the
ReferenceType of the reference's klass to determine what to do. (See below.)

Phantom references need to be treated differently from stronger "weak"
reference types, because phantom references are weaker than finalization, so
might not be cleared when a stronger reference to the same object is
cleared.  For collectors with STW reference processing this doesn't make
much difference (the referent is either cleared or not), but making this
distinction correctly is necessary for concurrent reference processing.

The Access API that provides the interface to the GC has support for
"unknown" referent accesses that perform a runtime lookup.  This is
supported in C++ code, but not in the various Java code processors
(interpreter and compilers).  We didn't previously need to support that case
for Java because the only place where it mattered was accessing the referent
of a PhantomReference, and that is blocked by PhantomReference::get that
always returns null.

For refersTo the intent is to have the interpreter and C1 use the native
method, but have C2 have special knowledge for it. We could add support for
the "unknown" reference type to C2, but that's a substantial amount of work,
and only useful for this one place.  Or we can take the same approach as for
get(), i.e. have a second method on PhantomReference so that calls that can
select the appropriate method at compile time (usually the case) can have
distinct intrinsics for the two cases.

By having these intrinsifiable native methods be package private we can have
the public refersTo API function be final, while also preventing any further
overrides by classes not in the same package.

I'll try to come up with some commentary.


From kim.barrett at oracle.com  Thu Oct  8 07:56:33 2020
From: kim.barrett at oracle.com (Kim Barrett)
Date: Thu, 8 Oct 2020 03:56:33 -0400
Subject: RFR: 8188055: (ref) Add Reference::refersTo predicate
In-Reply-To: <9x0zaxknpYXGIvHun1CkLP0lEC8NQmPTnANxQKjhHF8=.907bdb15-2e2e-4f84-8fe4-ea4ed50534cd@github.com>
References: <D4HSg8FT20Eaxk5KJkkw0GgETSxRkBn1ipS3Dt0kPto=.e4bab078-2e04-4413-90cb-9bfafb2a6831@github.com>
 <Y1IHoNr8vO3OkCbEKw6ywXd4adik1yKKNIS4ABzF0d0=.d21f4183-ef4e-45ed-826d-6613215b6220@github.com>
 <9x0zaxknpYXGIvHun1CkLP0lEC8NQmPTnANxQKjhHF8=.907bdb15-2e2e-4f84-8fe4-ea4ed50534cd@github.com>
Message-ID: <21973EE4-EBC9-4382-BCFB-2CBB100E4BAF@oracle.com>

> On Oct 6, 2020, at 5:22 AM, Daniel Fuchs <dfuchs at openjdk.java.net> wrote:
> 
> On Tue, 6 Oct 2020 00:04:11 GMT, Mandy Chung <mchung at openjdk.org> wrote:
>> src/java.base/share/classes/java/lang/ref/Reference.java line 361:
>> 
>>> 359:
>>> 360:     /* Type-erased implementation of refersTo(). */
>>> 361:     native boolean refersTo0(Object o);
>> 
>> Is there any reason why it can't use the parameter type like `refersTo0(T o)`?  Same for `PhantomReference::refersTo0(T
>> o)`
> 
> But should `refersTo` takes a `T`? I mean - if I have a `Reference<?> ref`, the compiler will not let me query
> `ref.refersTo(o)`; is this what we want?

I'm going to have to defer to the Java language experts on this question.  Mandy?  Alan?


From chegar at openjdk.java.net  Thu Oct  8 08:05:45 2020
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Thu, 8 Oct 2020 08:05:45 GMT
Subject: RFR: 8254146: Avoid unnecessary volatile write on new
 AtomicBoolean(false)
In-Reply-To: <AzWKluHZjvFYm2wUanwYfn91iKKMacpk_qSsje3tXWk=.ba873b46-4e12-4415-8832-fa314d6759a3@github.com>
References: <AzWKluHZjvFYm2wUanwYfn91iKKMacpk_qSsje3tXWk=.ba873b46-4e12-4415-8832-fa314d6759a3@github.com>
Message-ID: <RyR2m1MR6UPKbcnxdi_tHwJvQxEtMhT-o2ljRTQDcEo=.976aa7a1-6706-4502-a150-5eb25dd744d1@github.com>

On Mon, 5 Oct 2020 17:25:28 GMT, Christoph Dreis <github.com+6304496+dreis2211 at openjdk.org> wrote:

> Hi,
> 
> the following PR optimizes `new AtomicBoolean(boolean)` by avoiding the volatile write in case `false` is passed.
> Essentially, it changes the ternary operator to a simple `if` without the `else` that would cause the volatile write.
> The resulting bytecode seems to also benefit from the change:
>     Code:
>        0: aload_0
>        1: invokespecial #1                  // Method java/lang/Object."<init>":()V
>        4: aload_0
>        5: iload_1
>        6: ifeq          13
>        9: iconst_1
>       10: goto          14
>       13: iconst_0
>       14: putfield      #7                  // Field value:I
>       17: return
> 
> After:
>     Code:
>        0: aload_0
>        1: invokespecial #1                  // Method java/lang/Object."<init>":()V
>        4: iload_1
>        5: ifeq          13
>        8: aload_0
>        9: iconst_1
>       10: putfield      #7                  // Field value:I
>       13: return
> 
> A simple benchmark that returns `new AtomicBoolean(false)` shows the following results, that brings it on par to `new
> AtomicBoolean()`: MyBenchmark.empty                                         avgt   10     3,103 ?   0,246   ns/op
> MyBenchmark.explicitNew                                   avgt   10     2,966 ?   0,071   ns/op
> MyBenchmark.explicitOld                                   avgt   10     7,738 ?   0,321   ns/op
> 
> In case you think this is worthwhile I'd be happy if this is sponsored.
> Cheers,
> Christoph

Marked as reviewed by chegar (Reviewer).

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

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

From kbarrett at openjdk.java.net  Thu Oct  8 08:15:07 2020
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Thu, 8 Oct 2020 08:15:07 GMT
Subject: RFR: 8188055: (ref) Add Reference::refersTo predicate [v2]
In-Reply-To: <D4HSg8FT20Eaxk5KJkkw0GgETSxRkBn1ipS3Dt0kPto=.e4bab078-2e04-4413-90cb-9bfafb2a6831@github.com>
References: <D4HSg8FT20Eaxk5KJkkw0GgETSxRkBn1ipS3Dt0kPto=.e4bab078-2e04-4413-90cb-9bfafb2a6831@github.com>
Message-ID: <QpVGNFn7FwJVVijkSVKgUxWDLw3Y7im-mlA3yw7_crU=.1e8d22b9-29e8-4347-8790-2fe213435219@github.com>

> Finally returning to this review that was started in April 2020.  I've
> recast it as a github PR.  I think the security concern raised by Gil
> has been adequately answered.
> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-April/029203.html
> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-July/030401.html
> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-August/030677.html
> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-September/030793.html
> 
> Please review a new function: java.lang.ref.Reference.refersTo.
> 
> This function is needed to test the referent of a Reference object without
> artificially extending the lifetime of the referent object, as may happen
> when calling Reference.get.  Some garbage collectors require extending the
> lifetime of a weak referent when accessed, in order to maintain collector
> invariants.  Lifetime extension may occur with any collector when the
> Reference is a SoftReference, as calling get indicates recent access.  This
> new function also allows testing the referent of a PhantomReference, which
> can't be accessed by calling get.
> 
> The new function uses native methods whose implementations are in the VM so
> they can use the Access API.  It is the intent that these methods will be
> intrinsified by optimizing compilers like C2 or graal, but that hasn't been
> implemented yet.  Bear that in mind before rushing off to change existing
> uses of Reference.get.
> 
> There are two native methods involved, one in Reference and an override in
> PhantomReference, both package private in java.lang.ref. The reason for this
> split is to simplify the intrinsification. This is a change from the version
> from April 2020; that version had a single native method in Reference,
> implemented using the ON_UNKNOWN_OOP_REF Access reference strength category.
> However, adding support for that category in the compilers adds significant
> implementation effort and complexity. Splitting avoids that complexity.
> 
> Testing:
> mach5 tier1
> Locally (linux-x64) verified the new test passes with various garbage collectors.

Kim Barrett has updated the pull request incrementally with five additional commits since the last revision:

 - improve refersTo0 descriptions
 - basic functional test
 - change referent access
 - expand test
 - remove CMS comment

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/498/files
  - new: https://git.openjdk.java.net/jdk/pull/498/files/4226ae79..28f2d1b3

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

  Stats: 164 lines in 9 files changed: 125 ins; 10 del; 29 mod
  Patch: https://git.openjdk.java.net/jdk/pull/498.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/498/head:pull/498

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

From rrich at openjdk.java.net  Thu Oct  8 08:54:59 2020
From: rrich at openjdk.java.net (Richard Reingruber)
Date: Thu, 8 Oct 2020 08:54:59 GMT
Subject: RFR: 8227745: Enable Escape Analysis for Better Performance in
 the Presence of JVMTI Agents [v8]
In-Reply-To: <Ll2RereRbuQLgFtIjv9pS92kPvCVuo-BI0cP1zGjVbo=.dad3a33c-0fc3-44fd-810a-f01448cf564c@github.com>
References: <Ll2RereRbuQLgFtIjv9pS92kPvCVuo-BI0cP1zGjVbo=.dad3a33c-0fc3-44fd-810a-f01448cf564c@github.com>
Message-ID: <aLahe_Pq4Vh_JAbgQsLgYVqaWkW3b7RoT3O-reqthvs=.740dec36-72bc-4185-b459-bd5b5350ede6@github.com>

> Hi,
> 
> this is the continuation of the review of the implementation for:
> 
> https://bugs.openjdk.java.net/browse/JDK-8227745
> https://bugs.openjdk.java.net/browse/JDK-8233915
> 
> It allows for JIT optimizations based on escape analysis even if JVMTI agents acquire capabilities to access references
> to objects that are subject to such optimizations, e.g. scalar replacement. The implementation reverts such
> optimizations just before access very much as when switching from JIT compiled execution to the interpreter, aka
> "deoptimization".  Webrev.8 was the last one before before the transition to Git/Github:
> 
> http://cr.openjdk.java.net/~rrich/webrevs/8227745/webrev.8/
> 
> Thanks, Richard.

Richard Reingruber has updated the pull request with a new target base due to a merge or a rebase. The pull request now
contains 18 commits:

 - Merge branch 'master' into JDK-8227745
 - Factorized fragment out of EscapeBarrier::deoptimize_objects_internal into new method in compiledVFrame.
 - More smaller changes proposed by Serguei.
 - jvmtiDeferredUpdates.hpp: remove forward declarations.
 - jvmtiDeferredLocalVariable: move member variables to the beginning of the class definition.
 - jvmtiDeferredUpdates.hpp: add/remove empty lines and improve indentation.
 - Merge branch 'master' into JDK-8227745
 - Merge branch 'master' into JDK-8227745
 - Make parameter current_thread of JvmtiEnvBase::check_top_frame() a JavaThread* again.
   
   With Asynchronous handshakes the type was changed from JavaThread* to Thread*
   but this is not necessary as check_top_frame() is not executed during a handshake
   / safepoint (robehn confirmed).
 - Merge branch 'master' into JDK-8227745
 - ... and 8 more: https://git.openjdk.java.net/jdk/compare/8f9e4792...94c89691

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

Changes: https://git.openjdk.java.net/jdk/pull/119/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=119&range=07
  Stats: 5815 lines in 52 files changed: 5595 ins; 116 del; 104 mod
  Patch: https://git.openjdk.java.net/jdk/pull/119.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/119/head:pull/119

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

From rrich at openjdk.java.net  Thu Oct  8 08:55:00 2020
From: rrich at openjdk.java.net (Richard Reingruber)
Date: Thu, 8 Oct 2020 08:55:00 GMT
Subject: RFR: 8227745: Enable Escape Analysis for Better Performance in
 the Presence of JVMTI Agents [v7]
In-Reply-To: <AnuPI17lb0T_qmuGLTxukiAEFU1VV5SPIB7UAXIzdKg=.178e46ab-bd21-4cf2-b50f-fd8101a09dd9@github.com>
References: <Ll2RereRbuQLgFtIjv9pS92kPvCVuo-BI0cP1zGjVbo=.dad3a33c-0fc3-44fd-810a-f01448cf564c@github.com>
 <6Scp6XjVCcdJN0tUKionVwGKoiBG8UeA-OpBXHrCYqk=.01170b1e-9722-4461-84e4-77e8fd447ac4@github.com>
 <AnuPI17lb0T_qmuGLTxukiAEFU1VV5SPIB7UAXIzdKg=.178e46ab-bd21-4cf2-b50f-fd8101a09dd9@github.com>
Message-ID: <hlkWFpxisMil2j3k8OUbIBapFNT_Ht0ZpQtoXSXp1w0=.e6776d45-990c-41fe-a949-a5e77e030d68@github.com>

On Wed, 7 Oct 2020 19:47:07 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> 
> 
> Richard,
> Thank you for the formatting and refactoring changes.
> The fix looks good to me.

Thank you very much Serguei!

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

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

From rrich at openjdk.java.net  Thu Oct  8 09:13:45 2020
From: rrich at openjdk.java.net (Richard Reingruber)
Date: Thu, 8 Oct 2020 09:13:45 GMT
Subject: RFR: 8227745: Enable Escape Analysis for Better Performance in
 the Presence of JVMTI Agents [v7]
In-Reply-To: <hlkWFpxisMil2j3k8OUbIBapFNT_Ht0ZpQtoXSXp1w0=.e6776d45-990c-41fe-a949-a5e77e030d68@github.com>
References: <Ll2RereRbuQLgFtIjv9pS92kPvCVuo-BI0cP1zGjVbo=.dad3a33c-0fc3-44fd-810a-f01448cf564c@github.com>
 <6Scp6XjVCcdJN0tUKionVwGKoiBG8UeA-OpBXHrCYqk=.01170b1e-9722-4461-84e4-77e8fd447ac4@github.com>
 <AnuPI17lb0T_qmuGLTxukiAEFU1VV5SPIB7UAXIzdKg=.178e46ab-bd21-4cf2-b50f-fd8101a09dd9@github.com>
 <hlkWFpxisMil2j3k8OUbIBapFNT_Ht0ZpQtoXSXp1w0=.e6776d45-990c-41fe-a949-a5e77e030d68@github.com>
Message-ID: <Bsu2pnqcPk0RblzAhI3yPqRhQIneBw6YxR21J5qDGvc=.0cb6237e-c067-4767-85e5-16979a6d746b@github.com>

On Thu, 8 Oct 2020 08:50:08 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> Richard,
>> Thank you for the formatting and refactoring changes.
>> The fix looks good to me.
>
>> 
>> 
>> Richard,
>> Thank you for the formatting and refactoring changes.
>> The fix looks good to me.
> 
> Thank you very much Serguei!

I'm planning to integrate this pull request on Monday 2020-10-12.

There was one failing test on Windows x64:
[tools/javac/launcher/SourceLauncherTest.java](https://github.com/reinrich/jdk/runs/1222200722). This was most likely
caused by [JDK-8249095](https://bugs.openjdk.java.net/browse/JDK-8249095). I've merged master to verify this.

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

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

From aph at openjdk.java.net  Thu Oct  8 09:31:57 2020
From: aph at openjdk.java.net (Andrew Haley)
Date: Thu, 8 Oct 2020 09:31:57 GMT
Subject: RFR: 8254078: DataOutputStream is very slow post-disabling of
 Biased Locking [v3]
In-Reply-To: <lLg_yNI_6LvUZTlM4PyN5ra6AaUZZeT35QzYzV_0CpI=.f2d3cb9e-be30-40dc-922c-dad5bef7feea@github.com>
References: <lLg_yNI_6LvUZTlM4PyN5ra6AaUZZeT35QzYzV_0CpI=.f2d3cb9e-be30-40dc-922c-dad5bef7feea@github.com>
Message-ID: <zTG0-16wXP2YeMEmRRawbCKsF91TAY3YuvK29XAtGNA=.fb3e3475-a6ff-4e18-a2e2-700482f27c6b@github.com>

> DataOutputStream is very slow post-disabling of Biased Locking. This
> was discovered when benchmarking a transaction library, which showed
> significant performance loss when moving to JDK 15. WIth some small
> changes to DataOutputStream we can get the performance back. There's a
> JMH benchmark at
> http://cr.openjdk.java.net/~aph/JDK-8254078/jmh-tests.tar
> 
> Some Stream classes use very fine-grained locking.
> 
> In particular, writeInt is defined like this:
> 
>         out.write((v >>> 24) & 0xFF);
>         out.write((v >>> 16) & 0xFF);
>         out.write((v >>> 8) & 0xFF);
>         out.write((v >>> 0) & 0xFF);
>         incCount(4);
> 
> Unfortunately, ByteArrayOutputStream.write(byte) is defined like this:
> 
>     public synchronized void write(int b) {
>         ensureCapacity(count + 1);
>         buf[count] = (byte) b;
>         count += 1;
>     }
> 
> so we acquire and release a lock for every byte that is output.
> 
>  For example, writing 4kb of ints goes from 17.3 us/op to 53.9 us/op when biased locking is disabled:
> 
> 
> +UseBiasedLocking DataOutputStreamTest.dataOutputStreamOverByteArray avgt 6 53.895 ? 5.126 us/op
> -UseBiasedLocking DataOutputStreamTest.dataOutputStreamOverByteArray avgt 6 17.291 ? 4.430 us/op
> 
> There are refactorings of DataOutputStream we can do to mitigate this.

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

 - 8254078: DataOutputStream is very slow post-disabling of Biased Locking
 - 8254078: DataOutputStream is very slow post-disabling of Biased Locking

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/542/files
  - new: https://git.openjdk.java.net/jdk/pull/542/files/8379b4f3..20ee0e6f

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

  Stats: 39 lines in 3 files changed: 2 ins; 30 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/542.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/542/head:pull/542

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

From aph at openjdk.java.net  Thu Oct  8 09:36:01 2020
From: aph at openjdk.java.net (Andrew Haley)
Date: Thu, 8 Oct 2020 09:36:01 GMT
Subject: RFR: 8254078: DataOutputStream is very slow post-disabling of
 Biased Locking [v4]
In-Reply-To: <lLg_yNI_6LvUZTlM4PyN5ra6AaUZZeT35QzYzV_0CpI=.f2d3cb9e-be30-40dc-922c-dad5bef7feea@github.com>
References: <lLg_yNI_6LvUZTlM4PyN5ra6AaUZZeT35QzYzV_0CpI=.f2d3cb9e-be30-40dc-922c-dad5bef7feea@github.com>
Message-ID: <Gj_g60Z7fHmhYdrpnT2orSadEquafzlbswhNfbOtEf4=.54e3592b-1e86-410d-8a37-9a51337cd0c8@github.com>

> DataOutputStream is very slow post-disabling of Biased Locking. This
> was discovered when benchmarking a transaction library, which showed
> significant performance loss when moving to JDK 15. WIth some small
> changes to DataOutputStream we can get the performance back. There's a
> JMH benchmark at
> http://cr.openjdk.java.net/~aph/JDK-8254078/jmh-tests.tar
> 
> Some Stream classes use very fine-grained locking.
> 
> In particular, writeInt is defined like this:
> 
>         out.write((v >>> 24) & 0xFF);
>         out.write((v >>> 16) & 0xFF);
>         out.write((v >>> 8) & 0xFF);
>         out.write((v >>> 0) & 0xFF);
>         incCount(4);
> 
> Unfortunately, ByteArrayOutputStream.write(byte) is defined like this:
> 
>     public synchronized void write(int b) {
>         ensureCapacity(count + 1);
>         buf[count] = (byte) b;
>         count += 1;
>     }
> 
> so we acquire and release a lock for every byte that is output.
> 
>  For example, writing 4kb of ints goes from 17.3 us/op to 53.9 us/op when biased locking is disabled:
> 
> 
> +UseBiasedLocking DataOutputStreamTest.dataOutputStreamOverByteArray avgt 6 53.895 ? 5.126 us/op
> -UseBiasedLocking DataOutputStreamTest.dataOutputStreamOverByteArray avgt 6 17.291 ? 4.430 us/op
> 
> There are refactorings of DataOutputStream we can do to mitigate this.

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

  8254078: DataOutputStream is very slow post-disabling of Biased Locking

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/542/files
  - new: https://git.openjdk.java.net/jdk/pull/542/files/20ee0e6f..a776efaa

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

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

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

From alanb at openjdk.java.net  Thu Oct  8 10:10:47 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 8 Oct 2020 10:10:47 GMT
Subject: RFR: 8254078: DataOutputStream is very slow post-disabling of
 Biased Locking [v4]
In-Reply-To: <Gj_g60Z7fHmhYdrpnT2orSadEquafzlbswhNfbOtEf4=.54e3592b-1e86-410d-8a37-9a51337cd0c8@github.com>
References: <lLg_yNI_6LvUZTlM4PyN5ra6AaUZZeT35QzYzV_0CpI=.f2d3cb9e-be30-40dc-922c-dad5bef7feea@github.com>
 <Gj_g60Z7fHmhYdrpnT2orSadEquafzlbswhNfbOtEf4=.54e3592b-1e86-410d-8a37-9a51337cd0c8@github.com>
Message-ID: <ZEjmMX_JU08LeQg7auOfOe1g_8AhZrQ4Ub21nkppaRo=.31508dfd-9683-4bad-ac4a-1dd9a0f3e75f@github.com>

On Thu, 8 Oct 2020 09:36:01 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> DataOutputStream is very slow post-disabling of Biased Locking. This
>> was discovered when benchmarking a transaction library, which showed
>> significant performance loss when moving to JDK 15. WIth some small
>> changes to DataOutputStream we can get the performance back. There's a
>> JMH benchmark at
>> http://cr.openjdk.java.net/~aph/JDK-8254078/jmh-tests.tar
>> 
>> Some Stream classes use very fine-grained locking.
>> 
>> In particular, writeInt is defined like this:
>> 
>>         out.write((v >>> 24) & 0xFF);
>>         out.write((v >>> 16) & 0xFF);
>>         out.write((v >>> 8) & 0xFF);
>>         out.write((v >>> 0) & 0xFF);
>>         incCount(4);
>> 
>> Unfortunately, ByteArrayOutputStream.write(byte) is defined like this:
>> 
>>     public synchronized void write(int b) {
>>         ensureCapacity(count + 1);
>>         buf[count] = (byte) b;
>>         count += 1;
>>     }
>> 
>> so we acquire and release a lock for every byte that is output.
>> 
>>  For example, writing 4kb of ints goes from 17.3 us/op to 53.9 us/op when biased locking is disabled:
>> 
>> 
>> +UseBiasedLocking DataOutputStreamTest.dataOutputStreamOverByteArray avgt 6 53.895 ? 5.126 us/op
>> -UseBiasedLocking DataOutputStreamTest.dataOutputStreamOverByteArray avgt 6 17.291 ? 4.430 us/op
>> 
>> There are refactorings of DataOutputStream we can do to mitigate this.
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8254078: DataOutputStream is very slow post-disabling of Biased Locking

src/java.base/share/classes/java/io/DataInputStream.java line 39:

> 37:  * threads. If a DataOutputStream is to be used by more than one
> 38:  * thread then access to the data output stream should be controlled
> 39:  * by appropriate synchronization.

Thanks for the update. Looks good except the s/DataOutputStream/DataInputStream/ and s/output/input/ here.

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

PR: https://git.openjdk.java.net/jdk/pull/542

From mcimadamore at openjdk.java.net  Thu Oct  8 10:29:24 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 8 Oct 2020 10:29:24 GMT
Subject: RFR: 8254162: Implementation of Foreign-Memory Access API (Third
 Incubator) [v2]
In-Reply-To: <IngRk57F78UN3yySfo6IABbdwnMogGNdYrykh_3em-c=.b81f7478-015c-45ed-9788-58d7519a2770@github.com>
References: <IngRk57F78UN3yySfo6IABbdwnMogGNdYrykh_3em-c=.b81f7478-015c-45ed-9788-58d7519a2770@github.com>
Message-ID: <-K8a4gV16AZ7Se7-G2DWZrSEMr5FjLPzlUlo4nXnTE0=.c33f2a73-6ee1-4a9f-b992-d51fc1f2f481@github.com>

> This patch contains the changes associated with the third incubation round of the foreign memory access API incubation
> (see JEP 393 [1]). This iteration focus on improving the usability of the API in 3 main ways:
> * first, by providing a way to obtain truly *shared* segments, which can be accessed and closed concurrently from
>   multiple threads
> * second, by providing a way to register a memory segment against a `Cleaner`, so as to have some (optional) guarantee
>   that the memory will be deallocated, eventually
> * third, by not requiring users to dive deep into var handles when they first pick up the API; a new `MemoryAccess` class
>   has been added, which defines several useful dereference routines; these are really just thin wrappers around memory
>   access var handles, but they make the barrier of entry for using this API somewhat lower.
> 
> A big conceptual shift that comes with this API refresh is that the role of `MemorySegment` and `MemoryAddress` is not
> the same as it used to be; it used to be the case that a memory address could (sometimes, not always) have a back link
> to the memory segment which originated it; additionally, memory access var handles used `MemoryAddress` as a basic unit
> of dereference.  This has all changed as per this API refresh;  now a `MemoryAddress` is just a dumb carrier which
> wraps a pair of object/long addressing coordinates; `MemorySegment` has become the star of the show, as far as
> dereferencing memory is concerned. You cannot dereference memory if you don't have a segment. This improves usability
> in a number of ways - first, it is a lot easier to wrap native addresses (`long`, essentially) into a `MemoryAddress`;
> secondly, it is crystal clear what a client has to do in order to dereference memory: if a client has a segment, it can
> use that; otherwise, if the client only has an address, it will have to create a segment *unsafely* (this can be done
> by calling `MemoryAddress::asSegmentRestricted`).  A list of the API, implementation and test changes is provided
> below. If  you have any questions, or need more detailed explanations, I (and the  rest of the Panama team) will be
> happy to point at existing discussions,  and/or to provide the feedback required.   A big thank to Erik Osterlund,
> Vladimir Ivanov and David Holmes, without whom the work on shared memory segment would not have been possible; also I'd
> like to thank Paul Sandoz, whose insights on API design have been very helpful in this journey.  Thanks  Maurizio
> Javadoc:   http://cr.openjdk.java.net/~mcimadamore/8254162_v1/javadoc/jdk/incubator/foreign/package-summary.html
> Specdiff:
> 
> http://cr.openjdk.java.net/~mcimadamore/8254162_v1/specdiff/jdk/incubator/foreign/package-summary.html
> 
> CSR:
> 
> https://bugs.openjdk.java.net/browse/JDK-8254163
> 
> 
> 
> ### API Changes
> 
> * `MemorySegment`
>   * drop factory for restricted segment (this has been moved to `MemoryAddress`, see below)
>   * added a no-arg factory for a native restricted segment representing entire native heap
>   * rename `withOwnerThread` to `handoff`
>   * add new `share` method, to create shared segments
>   * add new `registerCleaner` method, to register a segment against a cleaner
>   * add more helpers to create arrays from a segment e.g. `toIntArray`
>   * add some `asSlice` overloads (to make up for the fact that now segments are more frequently used as cursors)
>   * rename `baseAddress` to `address` (so that `MemorySegment` can implement `Addressable`)
> * `MemoryAddress`
>   * drop `segment` accessor
>   * drop `rebase` method and replace it with `segmentOffset` which returns the offset (a `long`) of this address relative
>     to a given segment
> * `MemoryAccess`
>   * New class supporting several static dereference helpers; the helpers are organized by carrier and access mode, where a
>     carrier is one of the usual suspect (a Java primitive, minus `boolean`); the access mode can be simple (e.g. access
>     base address of given segment), or indexed, in which case the accessor takes a segment and either a low-level byte
>     offset,or a high level logical index. The classification is reflected in the naming scheme (e.g. `getByte` vs.
>     `getByteAtOffset` vs `getByteAtIndex`).
> * `MemoryHandles`
>   * drop `withOffset` combinator
>   * drop `withStride` combinator
>   * the basic memory access handle factory now returns a var handle which takes a `MemorySegment` and a `long` - from which
>     it is easy to derive all the other handles using plain var handle combinators.
> * `Addressable`
>   * This is a new interface which is attached to entities which can be projected to a `MemoryAddress`. For now, both
>     `MemoryAddress` and `MemorySegment` implement it; we have plans, with JEP 389 [2] to add more implementations. Clients
>     can largely ignore this interface, which comes in really handy when defining native bindings with tools like `jextract`.
> * `MemoryLayouts`
>   * A new layout, for machine addresses, has been added to the mix.
> 
> 
> 
> ### Implementation changes
> 
> There are two main things to discuss here: support for shared segments, and the general simplification of the memory
> access var handle support.
> #### Shared segments
> 
> The support for shared segments cuts in pretty deep in the VM. Support for shared segments is notoriously hard to
> achieve, at least in a way that guarantees optimal access performances. This is caused by the fact that, if a segment
> is shared, it would be possible for a thread to close it while another is accessing it.  After considering several
> options (see [3]), we zeroed onto an approach which is inspired by an happy idea that Andrew Haley had (and that he
> reminded me of at this year OpenJDK committer workshop - thanks!). The idea is that if we could *freeze* the world
> (e.g. with a GC pause), while a segment is closed, we could then prevent segments from being accessed concurrently to a
> close operation. For this to work, it  is crucial that no GC safepoints can occur between a segment liveness check and
> the access itself (otherwise it would be possible for the accessing thread to stop just right before an unsafe call).
> It also relies on the fact that hotspot/C2 should not be able to propagate loads across safepoints.  Sadly, none of
> these conditions seems to be valid in the current implementation, so we needed to resort to a bit of creativity. First,
> we noted that, if we could mark so called *scoped* method with an annotation, it would be very simply to check as to
> whether a thread was in the middle of a scoped method when we stopped the world for a close operation (btw, instead of
> stopping the world, we do a much more efficient, thread-local polling, thanks to JEP 312 [4]).  The question is, then,
> once we detect that a thread is accessing the very segment we're about to close, what should happen? We first
> experimented with a solution which would install an *asynchronous* exception on the accessing thread, thus making it
> fail. This solution has some desirable properties, in that a `close` operation always succeeds. Unfortunately the
> machinery for async exceptions is a bit fragile (e.g. not all the code in hotspot checks for async exceptions); to
> minimize risks, we decided to revert to a simpler strategy, where `close` might fail when it finds that another thread
> is accessing the segment being closed.  As written in the javadoc, this doesn't mean that clients should just catch and
> try again; an exception on `close` is a bug in the user code, likely arising from lack of synchronization, and should
> be treated as such.  In terms of gritty implementation, we needed to centralize memory access routines in a single
> place, so that we could have a set of routines closely mimicking the primitives exposed by `Unsafe` but which, in
> addition, also provided a liveness check. This way we could mark all these routines with the special `@Scoped`
> annotation, which tells the VM that something important is going on.  To achieve this, we created a new (autogenerated)
> class, called `ScopedMemoryAccess`. This class contains all the main memory access primitives (including bulk access,
> like `copyMemory`, or `setMemory`), and accepts, in addition to the access coordinates, also a scope object, which is
> tested before access. A reachability fence is also thrown in the mix to make sure that the scope is kept alive during
> access (which is important when registering segments against cleaners).  Of course, to make memory access safe, memory
> access var handles, byte buffer var handles, and byte buffer API should use the new `ScopedMemoryAccess` class instead
> of unsafe, so that a liveness check can be triggered (in case a scope is present).  `ScopedMemoryAccess` has a
> `closeScope` method, which initiates the thread-local handshakes, and returns `true` if the handshake completed
> successfully.  The implementation of `MemoryScope` (now significantly simplified from what we had before), has two
> implementations, one for confined segments and one for shared segments; the main difference between the two is what
> happens when the scope is closed; a confined segment sets a boolean flag to false, and returns, whereas a shared
> segment goes into a `CLOSING` state, then starts the handshake, and then updates the state again, to either `CLOSED` or
> `ALIVE` depending on whether the handshake was successful or not. Note that when a shared segment is in the `CLOSING`
> state, `MemorySegment::isAlive` will still return `true`, while the liveness check upon memory access will fail.  ####
> Memory access var handles overhaul  The key realization here was that if all memory access var handles took a
> coordinate pair of `MemorySegment` and `long`, all other access types could be derived from this basic var handle
> form.  This allowed us to remove the on-the-fly var handle generation, and to simply derive structural access var
> handles (such as those obtained by calling `MemoryLayout::varHandle`) using *plain* var handle combinators, so that
> e.g. additional offset is injected into a base memory access var handle.  This also helped in simplifying the
> implementation by removing the special `withStride` and `withOffset` combinators, which previously needed low-level
> access on the innards of the memory access var handle. All that code is now gone.  #### Test changes  Not much to see
> here - most of the tests needed to be updated because of the API changes. Some were beefed up (like the array test,
> since now segments can be projected into many different kinds of arrays). A test has been added to test the `Cleaner`
> functionality, and another stress test has been added for shared segments (`TestHandshake`). Some of the
> microbenchmarks also needed some tweaks - and some of them were also updated to also test performance in the shared
> segment case.  [1] - https://openjdk.java.net/jeps/393 [2] - https://openjdk.java.net/jeps/389 [3] -
> https://mail.openjdk.java.net/pipermail/panama-dev/2020-May/009004.html [4] - https://openjdk.java.net/jeps/312

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Address review comments

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/548/files
  - new: https://git.openjdk.java.net/jdk/pull/548/files/e4eb2c74..fa051abf

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=548&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=548&range=00-01

  Stats: 67 lines in 5 files changed: 33 ins; 3 del; 31 mod
  Patch: https://git.openjdk.java.net/jdk/pull/548.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/548/head:pull/548

PR: https://git.openjdk.java.net/jdk/pull/548

From mcimadamore at openjdk.java.net  Thu Oct  8 10:29:25 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 8 Oct 2020 10:29:25 GMT
Subject: RFR: 8254162: Implementation of Foreign-Memory Access API (Third
 Incubator) [v2]
In-Reply-To: <2m-ZUtCAOMDADZVduYjzmcNHYziHMIC3axl1CNolulo=.4e19ccf9-4320-434d-b8c3-b186f74f1b5e@github.com>
References: <IngRk57F78UN3yySfo6IABbdwnMogGNdYrykh_3em-c=.b81f7478-015c-45ed-9788-58d7519a2770@github.com>
 <2m-ZUtCAOMDADZVduYjzmcNHYziHMIC3axl1CNolulo=.4e19ccf9-4320-434d-b8c3-b186f74f1b5e@github.com>
Message-ID: <b1R6Xz2EfA9QVitlctl36rThW6R5Tr7JGyFL-h7HUfs=.4243f9df-241d-4890-ab63-effd23704da8@github.com>

On Thu, 8 Oct 2020 06:53:41 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review comments
>
> test/jdk/java/foreign/TestMismatch.java line 26:
> 
>> 24: /*
>> 25:  * @test
>> 26:  * @run testng/othervm -XX:MaxDirectMemorySize=5000000000 TestMismatch
> 
> Whoa, allocating 5 GB? That might fail on 32-bit platforms... Anyhow, this flag accepts suffixes, so
> `-XX:MaxDirectMemorySize=5g`.

I've done two things here:
* the limit isn't really doing much in this test, so I've removed
* I moved the limit in TestSegments; the limit is set to much lower threshold (2M) which should work regardless of 32/64
* For TestMismatch, which needs to allocate a segment bigger than 2^32 in one of the tests, I've added a guard in the
  offending test which verifies that we're indeed on a 64-bit platform

-------------

PR: https://git.openjdk.java.net/jdk/pull/548

From shade at openjdk.java.net  Thu Oct  8 10:32:49 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 8 Oct 2020 10:32:49 GMT
Subject: RFR: 8254162: Implementation of Foreign-Memory Access API (Third
 Incubator) [v2]
In-Reply-To: <-K8a4gV16AZ7Se7-G2DWZrSEMr5FjLPzlUlo4nXnTE0=.c33f2a73-6ee1-4a9f-b992-d51fc1f2f481@github.com>
References: <IngRk57F78UN3yySfo6IABbdwnMogGNdYrykh_3em-c=.b81f7478-015c-45ed-9788-58d7519a2770@github.com>
 <-K8a4gV16AZ7Se7-G2DWZrSEMr5FjLPzlUlo4nXnTE0=.c33f2a73-6ee1-4a9f-b992-d51fc1f2f481@github.com>
Message-ID: <VXUVa90LggVNUMvnu83niPgH-nhGpY35Tz2NA3Gfc7w=.f34600ba-4a62-4768-9d21-db8117bc6482@github.com>

On Thu, 8 Oct 2020 10:29:24 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This patch contains the changes associated with the third incubation round of the foreign memory access API incubation
>> (see JEP 393 [1]). This iteration focus on improving the usability of the API in 3 main ways:
>> * first, by providing a way to obtain truly *shared* segments, which can be accessed and closed concurrently from
>>   multiple threads
>> * second, by providing a way to register a memory segment against a `Cleaner`, so as to have some (optional) guarantee
>>   that the memory will be deallocated, eventually
>> * third, by not requiring users to dive deep into var handles when they first pick up the API; a new `MemoryAccess` class
>>   has been added, which defines several useful dereference routines; these are really just thin wrappers around memory
>>   access var handles, but they make the barrier of entry for using this API somewhat lower.
>> 
>> A big conceptual shift that comes with this API refresh is that the role of `MemorySegment` and `MemoryAddress` is not
>> the same as it used to be; it used to be the case that a memory address could (sometimes, not always) have a back link
>> to the memory segment which originated it; additionally, memory access var handles used `MemoryAddress` as a basic unit
>> of dereference.  This has all changed as per this API refresh;  now a `MemoryAddress` is just a dumb carrier which
>> wraps a pair of object/long addressing coordinates; `MemorySegment` has become the star of the show, as far as
>> dereferencing memory is concerned. You cannot dereference memory if you don't have a segment. This improves usability
>> in a number of ways - first, it is a lot easier to wrap native addresses (`long`, essentially) into a `MemoryAddress`;
>> secondly, it is crystal clear what a client has to do in order to dereference memory: if a client has a segment, it can
>> use that; otherwise, if the client only has an address, it will have to create a segment *unsafely* (this can be done
>> by calling `MemoryAddress::asSegmentRestricted`).  A list of the API, implementation and test changes is provided
>> below. If  you have any questions, or need more detailed explanations, I (and the  rest of the Panama team) will be
>> happy to point at existing discussions,  and/or to provide the feedback required.   A big thank to Erik Osterlund,
>> Vladimir Ivanov and David Holmes, without whom the work on shared memory segment would not have been possible; also I'd
>> like to thank Paul Sandoz, whose insights on API design have been very helpful in this journey.  Thanks  Maurizio
>> Javadoc:   http://cr.openjdk.java.net/~mcimadamore/8254162_v1/javadoc/jdk/incubator/foreign/package-summary.html
>> Specdiff:
>> 
>> http://cr.openjdk.java.net/~mcimadamore/8254162_v1/specdiff/jdk/incubator/foreign/package-summary.html
>> 
>> CSR:
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8254163
>> 
>> 
>> 
>> ### API Changes
>> 
>> * `MemorySegment`
>>   * drop factory for restricted segment (this has been moved to `MemoryAddress`, see below)
>>   * added a no-arg factory for a native restricted segment representing entire native heap
>>   * rename `withOwnerThread` to `handoff`
>>   * add new `share` method, to create shared segments
>>   * add new `registerCleaner` method, to register a segment against a cleaner
>>   * add more helpers to create arrays from a segment e.g. `toIntArray`
>>   * add some `asSlice` overloads (to make up for the fact that now segments are more frequently used as cursors)
>>   * rename `baseAddress` to `address` (so that `MemorySegment` can implement `Addressable`)
>> * `MemoryAddress`
>>   * drop `segment` accessor
>>   * drop `rebase` method and replace it with `segmentOffset` which returns the offset (a `long`) of this address relative
>>     to a given segment
>> * `MemoryAccess`
>>   * New class supporting several static dereference helpers; the helpers are organized by carrier and access mode, where a
>>     carrier is one of the usual suspect (a Java primitive, minus `boolean`); the access mode can be simple (e.g. access
>>     base address of given segment), or indexed, in which case the accessor takes a segment and either a low-level byte
>>     offset,or a high level logical index. The classification is reflected in the naming scheme (e.g. `getByte` vs.
>>     `getByteAtOffset` vs `getByteAtIndex`).
>> * `MemoryHandles`
>>   * drop `withOffset` combinator
>>   * drop `withStride` combinator
>>   * the basic memory access handle factory now returns a var handle which takes a `MemorySegment` and a `long` - from which
>>     it is easy to derive all the other handles using plain var handle combinators.
>> * `Addressable`
>>   * This is a new interface which is attached to entities which can be projected to a `MemoryAddress`. For now, both
>>     `MemoryAddress` and `MemorySegment` implement it; we have plans, with JEP 389 [2] to add more implementations. Clients
>>     can largely ignore this interface, which comes in really handy when defining native bindings with tools like `jextract`.
>> * `MemoryLayouts`
>>   * A new layout, for machine addresses, has been added to the mix.
>> 
>> 
>> 
>> ### Implementation changes
>> 
>> There are two main things to discuss here: support for shared segments, and the general simplification of the memory
>> access var handle support.
>> #### Shared segments
>> 
>> The support for shared segments cuts in pretty deep in the VM. Support for shared segments is notoriously hard to
>> achieve, at least in a way that guarantees optimal access performances. This is caused by the fact that, if a segment
>> is shared, it would be possible for a thread to close it while another is accessing it.  After considering several
>> options (see [3]), we zeroed onto an approach which is inspired by an happy idea that Andrew Haley had (and that he
>> reminded me of at this year OpenJDK committer workshop - thanks!). The idea is that if we could *freeze* the world
>> (e.g. with a GC pause), while a segment is closed, we could then prevent segments from being accessed concurrently to a
>> close operation. For this to work, it  is crucial that no GC safepoints can occur between a segment liveness check and
>> the access itself (otherwise it would be possible for the accessing thread to stop just right before an unsafe call).
>> It also relies on the fact that hotspot/C2 should not be able to propagate loads across safepoints.  Sadly, none of
>> these conditions seems to be valid in the current implementation, so we needed to resort to a bit of creativity. First,
>> we noted that, if we could mark so called *scoped* method with an annotation, it would be very simply to check as to
>> whether a thread was in the middle of a scoped method when we stopped the world for a close operation (btw, instead of
>> stopping the world, we do a much more efficient, thread-local polling, thanks to JEP 312 [4]).  The question is, then,
>> once we detect that a thread is accessing the very segment we're about to close, what should happen? We first
>> experimented with a solution which would install an *asynchronous* exception on the accessing thread, thus making it
>> fail. This solution has some desirable properties, in that a `close` operation always succeeds. Unfortunately the
>> machinery for async exceptions is a bit fragile (e.g. not all the code in hotspot checks for async exceptions); to
>> minimize risks, we decided to revert to a simpler strategy, where `close` might fail when it finds that another thread
>> is accessing the segment being closed.  As written in the javadoc, this doesn't mean that clients should just catch and
>> try again; an exception on `close` is a bug in the user code, likely arising from lack of synchronization, and should
>> be treated as such.  In terms of gritty implementation, we needed to centralize memory access routines in a single
>> place, so that we could have a set of routines closely mimicking the primitives exposed by `Unsafe` but which, in
>> addition, also provided a liveness check. This way we could mark all these routines with the special `@Scoped`
>> annotation, which tells the VM that something important is going on.  To achieve this, we created a new (autogenerated)
>> class, called `ScopedMemoryAccess`. This class contains all the main memory access primitives (including bulk access,
>> like `copyMemory`, or `setMemory`), and accepts, in addition to the access coordinates, also a scope object, which is
>> tested before access. A reachability fence is also thrown in the mix to make sure that the scope is kept alive during
>> access (which is important when registering segments against cleaners).  Of course, to make memory access safe, memory
>> access var handles, byte buffer var handles, and byte buffer API should use the new `ScopedMemoryAccess` class instead
>> of unsafe, so that a liveness check can be triggered (in case a scope is present).  `ScopedMemoryAccess` has a
>> `closeScope` method, which initiates the thread-local handshakes, and returns `true` if the handshake completed
>> successfully.  The implementation of `MemoryScope` (now significantly simplified from what we had before), has two
>> implementations, one for confined segments and one for shared segments; the main difference between the two is what
>> happens when the scope is closed; a confined segment sets a boolean flag to false, and returns, whereas a shared
>> segment goes into a `CLOSING` state, then starts the handshake, and then updates the state again, to either `CLOSED` or
>> `ALIVE` depending on whether the handshake was successful or not. Note that when a shared segment is in the `CLOSING`
>> state, `MemorySegment::isAlive` will still return `true`, while the liveness check upon memory access will fail.  ####
>> Memory access var handles overhaul  The key realization here was that if all memory access var handles took a
>> coordinate pair of `MemorySegment` and `long`, all other access types could be derived from this basic var handle
>> form.  This allowed us to remove the on-the-fly var handle generation, and to simply derive structural access var
>> handles (such as those obtained by calling `MemoryLayout::varHandle`) using *plain* var handle combinators, so that
>> e.g. additional offset is injected into a base memory access var handle.  This also helped in simplifying the
>> implementation by removing the special `withStride` and `withOffset` combinators, which previously needed low-level
>> access on the innards of the memory access var handle. All that code is now gone.  #### Test changes  Not much to see
>> here - most of the tests needed to be updated because of the API changes. Some were beefed up (like the array test,
>> since now segments can be projected into many different kinds of arrays). A test has been added to test the `Cleaner`
>> functionality, and another stress test has been added for shared segments (`TestHandshake`). Some of the
>> microbenchmarks also needed some tweaks - and some of them were also updated to also test performance in the shared
>> segment case.  [1] - https://openjdk.java.net/jeps/393 [2] - https://openjdk.java.net/jeps/389 [3] -
>> https://mail.openjdk.java.net/pipermail/panama-dev/2020-May/009004.html [4] - https://openjdk.java.net/jeps/312
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

Thanks, these changes make sense to me.

-------------

PR: https://git.openjdk.java.net/jdk/pull/548

From lancea at openjdk.java.net  Thu Oct  8 10:35:45 2020
From: lancea at openjdk.java.net (Lance Andersen)
Date: Thu, 8 Oct 2020 10:35:45 GMT
Subject: RFR: 8242882: opening jar file with large manifest might throw
 NegativeArraySizeException [v3]
In-Reply-To: <9AgaGLA8q63mDTKDeavbyfZVntagI0bd0Kb7rkQQYyg=.67d4410c-b7db-4048-87d0-4ec1f9d93cd2@github.com>
References: <17lthSuYGInBHE2r3hBs0yXvMIZWWQkdLhYYBfRUMfM=.b59db398-6dc4-4b34-b141-2c58f189bce8@github.com>
 <9AgaGLA8q63mDTKDeavbyfZVntagI0bd0Kb7rkQQYyg=.67d4410c-b7db-4048-87d0-4ec1f9d93cd2@github.com>
Message-ID: <WZp8I9B_l_5djzkSgec-HiLueSDjUJDDq-egFk3G2Bs=.959a5550-44f3-421f-b23c-40804f1cb782@github.com>

On Thu, 1 Oct 2020 14:42:21 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review and a sponsor for a fix for https://bugs.openjdk.java.net/browse/JDK-8242882?
>> 
>> As noted in that JBS issue, if the size of the Manifest entry in the jar happens to be very large (such that it exceeds
>> the `Integer.MAX_VALUE`), then the current code in `JarFile#getBytes` can lead to a `NegativeArraySizeException`.  This
>> is due to the: if (len != -1 && len <= 65535)  block which evaluates to `true` when the size of the manifest entry is
>> larger than `Integer.MAX_VALUE`. As a result, this then ends up calling the code which can lead to the
>> `NegativeArraySizeException`.  The commit in this PR fixes that issue by changing those `if/else` blocks to prevent
>> this issue and instead use a code path that leads to the `InputStream#readAllBytes()` which internally has the
>> necessary checks to throw the expected `OutOfMemoryError`.  This commit also includes a jtreg test case which
>> reproduces the issue and verifies the fix.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Second round of review comments addressed

Hi Jaikiran,

Yes I think you are OK to move forward with the integration,

-------------

Marked as reviewed by lancea (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/323

From mdoerr at openjdk.java.net  Thu Oct  8 10:46:51 2020
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Thu, 8 Oct 2020 10:46:51 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v3]
In-Reply-To: <BPUaQTDmxtonENpeoEp5xhJBjS7LB4vESLH7A8sH1-k=.755d7497-1fa1-4ca2-9d95-4477460f7626@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <BPUaQTDmxtonENpeoEp5xhJBjS7LB4vESLH7A8sH1-k=.755d7497-1fa1-4ca2-9d95-4477460f7626@github.com>
Message-ID: <BEknTe_U8l2MO30Mb5nt6Z6w87fHu4aLRZg8Xs8vbIY=.09f48a18-833a-478d-8946-fd238910e340@github.com>

On Thu, 8 Oct 2020 06:53:26 GMT, CoreyAshford <github.com+51754783+CoreyAshford at openjdk.org> wrote:

>> This patch set encompasses the following commits:
>> 
>> - Adds a new HotSpot intrinsic candidate to the java.lang.Base64 class - decodeBlock(), and provides a flexible API for
>>   the intrinsic.  The API is similar to the existing encodeBlock intrinsic.
>> - Adds the code in HotSpot to check and martial the new intrinsic's arguments to the arch-specific intrinsic
>>   implementation
>> - Adds a Power64LE-specific implementation of the decodeBlock intrinsic.
>> - Adds a JMH microbenchmark for both Base64 encoding and encoding.
>> - Enhances the JTReg hotspot intrinsic "TestBase64.java" regression test to more fully test both decoding and encoding.
>
> CoreyAshford has updated the pull request incrementally with seven additional commits since the last revision:
> 
>  - stubGenerator_ppc.cpp: Fix multiple issues as per Martin Doerr's v2 review
>    
>     * Remove extraneous comma from SAP copyright notice
>     * Move align(32) to the head of the loop rather than the beginning of the unwound code
>     * Simplified looping condition to use a loop counter instead of a final
>       address.  This eliminated the need for the "end" variable, and
>       essentially replaced it with CTR, which is computed using a simple
>       bitwise shift of the size.
>     * Re-ran benchmarks against loop_unrolls values: 1, 2, 4, 8, 16 to find
>       optimal value, now 4.
>     * Corrected a typo in the word "elements"
>  - vm_version_ppc.cpp: per Martin Doerr's review of v2: fix copy/paste error
>  - vmIntrinsics.cpp: Per Martin Doerr's v2 review: rearrange order of case statement to be consistent with others.
>  - runtime.cpp: per Martin Doerr's review of v2, correct comment as per current semantics of decodeBlock()
>    
>      * The reference to "ofs" seems to be a copy/paste error.
>      * -1 is no longer returned from decodeBlock() in the event of a
>        non-base64 character being encountered; only a count of bytes written
>        to dst.
>  - TestBase64.java: Change comment as per Martin Doerr's v2 review
>  - Base64.java: Make changes as per Roger Riggs and Martin Doerr's v2 Review
>    
>      * Make comment about the sl parameter more precise
>      * Fix comparison to avoid possible integer overflow of sp
>  - library_call.cpp: Fix rebase merge error

Changes requested by mdoerr (Reviewer).

src/hotspot/cpu/ppc/stubGenerator_ppc.cpp line 3806:

> 3804:     // Load CTR with the number of passes through the unrolled loop
> 3805:     // = sl >> block_size_shift
> 3806:     __ srawi(sl, sl, block_size_shift);

Thanks, this is more simple. Unfortunately, sl can become 0. So I think we should move these 2 lines down before the
align and use: srawi_
beq(CCR0, unrolled_loop_exit)
mtctr

test/hotspot/jtreg/compiler/intrinsics/base64/TestBase64.java line 90:

> 88:
> 89:         // This should be enough to get both encodeBlock() and
> 90:         // decodeBlock() compiled on the highest tier.

It's actually encode() and decode() which should get compiled. You should see them when testing
with -XX:+PrintCompilation. And you should see usage of the intrinsics by -XX:+PrintInlining.

-------------

PR: https://git.openjdk.java.net/jdk/pull/293

From jpai at openjdk.java.net  Thu Oct  8 10:49:51 2020
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Thu, 8 Oct 2020 10:49:51 GMT
Subject: Integrated: 8242882: opening jar file with large manifest might throw
 NegativeArraySizeException
In-Reply-To: <17lthSuYGInBHE2r3hBs0yXvMIZWWQkdLhYYBfRUMfM=.b59db398-6dc4-4b34-b141-2c58f189bce8@github.com>
References: <17lthSuYGInBHE2r3hBs0yXvMIZWWQkdLhYYBfRUMfM=.b59db398-6dc4-4b34-b141-2c58f189bce8@github.com>
Message-ID: <PozDp6bj88-WnGyYBhwGdbb9mWwfIvobx6-qvLVKax8=.e8a6765d-674f-4efa-82a7-e6c5a0d96200@github.com>

On Wed, 23 Sep 2020 15:06:55 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review and a sponsor for a fix for https://bugs.openjdk.java.net/browse/JDK-8242882?
> 
> As noted in that JBS issue, if the size of the Manifest entry in the jar happens to be very large (such that it exceeds
> the `Integer.MAX_VALUE`), then the current code in `JarFile#getBytes` can lead to a `NegativeArraySizeException`.  This
> is due to the: if (len != -1 && len <= 65535)  block which evaluates to `true` when the size of the manifest entry is
> larger than `Integer.MAX_VALUE`. As a result, this then ends up calling the code which can lead to the
> `NegativeArraySizeException`.  The commit in this PR fixes that issue by changing those `if/else` blocks to prevent
> this issue and instead use a code path that leads to the `InputStream#readAllBytes()` which internally has the
> necessary checks to throw the expected `OutOfMemoryError`.  This commit also includes a jtreg test case which
> reproduces the issue and verifies the fix.

This pull request has now been integrated.

Changeset: 782d45bd
Author:    Jaikiran Pai <jpai at openjdk.org>
Committer: Lance Andersen <lancea at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/782d45bd
Stats:     85 lines in 2 files changed: 84 ins; 0 del; 1 mod

8242882: opening jar file with large manifest might throw NegativeArraySizeException

Reviewed-by: bchristi, lancea

-------------

PR: https://git.openjdk.java.net/jdk/pull/323

From avoitylov at openjdk.java.net  Thu Oct  8 10:52:53 2020
From: avoitylov at openjdk.java.net (Aleksei Voitylov)
Date: Thu, 8 Oct 2020 10:52:53 GMT
Subject: RFR: JDK-8247589: Implementation of Alpine Linux/x64 Port [v6]
In-Reply-To: <bjBywiEZ6tEHsG5xi2185_J-tduz4ezP8r6wVKbX1lY=.f6574f6f-be11-4d7c-8ebc-50b24ad8015d@github.com>
References: <bjBywiEZ6tEHsG5xi2185_J-tduz4ezP8r6wVKbX1lY=.f6574f6f-be11-4d7c-8ebc-50b24ad8015d@github.com>
Message-ID: <c1MlKKCyF8tYh2i3go62f96qP4Ox49ocnBZgmtBHjtk=.8dd586d0-becb-405e-adfe-e56e2db0636e@github.com>

> continuing the review thread from here https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-September/068546.html
> 
>> The download side of using JNI in these tests is that it complicates the
>> setup a bit for those that run jtreg directly and/or just build the JDK
>> and not the test libraries. You could reduce this burden a bit by
>> limiting the load library/isMusl check to Linux only, meaning isMusl
>> would not be called on other platforms.
>>
>> The alternative you suggest above might indeed be better. I assume you
>> don't mean splitting the tests but rather just adding a second @test
>> description so that the vm.musl case runs the test with a system
>> property that allows the test know the expected load library path behavior.
> 
> I have updated the PR to split the two tests in multiple @test s.
> 
>> The updated comment in java_md.c in this looks good. A minor comment on
>> Platform.isBusybox is Files.isSymbolicLink returning true implies that
>> the link exists so no need to check for exists too. Also the
>> if-then-else style for the new class in ProcessBuilder/Basic.java is
>> inconsistent with the rest of the test so it stands out.
> 
> Thank you, these changes are done in the updated PR.
> 
>> Given the repo transition this weekend then I assume you'll create a PR
>> for the final review at least. Also I see JEP 386 hasn't been targeted
>> yet but I assume Boris, as owner, will propose-to-target and wait for it
>> to be targeted before it is integrated.
> 
> Yes. How can this be best accomplished with the new git workflow?
> - we can continue the review process till the end and I will request the integration to happen only after the JEP is
>   targeted. I guess this step is now done by typing "slash integrate" in a comment.
> - we can pause the review process now until the JEP is targeted.
> 
> In the first case I'm kindly asking the Reviewers who already chimed in on that to re-confirm the review here.

Aleksei Voitylov 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 JDK-8247589
 - JDK-8247589: Implementation of Alpine Linux/x64 Port
 - JDK-8247589: Implementation of Alpine Linux/x64 Port

-------------

Changes: https://git.openjdk.java.net/jdk/pull/49/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=49&range=05
  Stats: 403 lines in 30 files changed: 348 ins; 17 del; 38 mod
  Patch: https://git.openjdk.java.net/jdk/pull/49.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/49/head:pull/49

PR: https://git.openjdk.java.net/jdk/pull/49

From avoitylov at openjdk.java.net  Thu Oct  8 11:03:48 2020
From: avoitylov at openjdk.java.net (Aleksei Voitylov)
Date: Thu, 8 Oct 2020 11:03:48 GMT
Subject: RFR: JDK-8247589: Implementation of Alpine Linux/x64 Port [v2]
In-Reply-To: <iyvweqL8dNEXuXMlFXdfx03yNRGyy8WLDMkG2NCN2Bk=.9dcfe9a7-3d6e-4227-b31b-a28c8e1614e3@github.com>
References: <bjBywiEZ6tEHsG5xi2185_J-tduz4ezP8r6wVKbX1lY=.f6574f6f-be11-4d7c-8ebc-50b24ad8015d@github.com>
 <ZaC0wyl8pFXr1wCN8nuPgSA1pZOAEucaP6mkrJhZYf8=.8f81d618-31f0-4262-990a-980327739d4b@github.com>
 <PgeNNEaSfdBhf5I38_LN-SH3aFQUiFbloD6NG_bzMQA=.1178d2ca-82ca-4ca5-9e27-0bd86dcacb1a@github.com>
 <6jqlCPXe69fPRvYFrytJsECkaa9tJ1hYWISNgyPP4Eg=.40944ef5-93b0-4db4-948b-80bb7898e9e8@github.com>
 <o4Ql6TAAuuFFuwG8KTHF_bqg_ZliQfcRpuqgNsAGNPA=.2f1aa9d4-0e25-4c5d-b556-701eeba2cc81@github.com>
 <aw463dmr3OoI-xwE92WKIvGK4tY52jbMb3Bb8yKsu6c=.7fa08759-5663-4450-8576-29d43c1635c1@github.com>
 <iyvweqL8dNEXuXMlFXdfx03yNRGyy8WLDMkG2NCN2Bk=.9dcfe9a7-3d6e-4227-b31b-a28c8e1614e3@github.com>
Message-ID: <E4-ceOi1onrpKNdsorrnCtUhBi85Z5VQMjf235T8HiA=.80b5090f-7ab2-4d6c-896c-4a1c3c2a4674@github.com>

On Thu, 8 Oct 2020 10:58:56 GMT, Aleksei Voitylov <avoitylov at openjdk.org> wrote:

>> @voitylov For future reference please don't force-push commits on open PRs as it breaks the commit history. I can no
>> longer just look at the two most recent commits and see what they added relative to what I had previously reviewed.
>> Thanks.
>
> @dholmes-ora yes, sorry about that. I updated the branch to pull the recent changes to enable pre-submit tests and
> ensure everything is well before integration and though the branch looked good it confused the pull request. So I had
> to force push it back to the original state.

@iignatev I resolved the conflict in whitebox.cpp and fixed a minor style nit on the way. Could you take a look?

-------------

PR: https://git.openjdk.java.net/jdk/pull/49

From avoitylov at openjdk.java.net  Thu Oct  8 11:03:48 2020
From: avoitylov at openjdk.java.net (Aleksei Voitylov)
Date: Thu, 8 Oct 2020 11:03:48 GMT
Subject: RFR: JDK-8247589: Implementation of Alpine Linux/x64 Port [v2]
In-Reply-To: <aw463dmr3OoI-xwE92WKIvGK4tY52jbMb3Bb8yKsu6c=.7fa08759-5663-4450-8576-29d43c1635c1@github.com>
References: <bjBywiEZ6tEHsG5xi2185_J-tduz4ezP8r6wVKbX1lY=.f6574f6f-be11-4d7c-8ebc-50b24ad8015d@github.com>
 <ZaC0wyl8pFXr1wCN8nuPgSA1pZOAEucaP6mkrJhZYf8=.8f81d618-31f0-4262-990a-980327739d4b@github.com>
 <PgeNNEaSfdBhf5I38_LN-SH3aFQUiFbloD6NG_bzMQA=.1178d2ca-82ca-4ca5-9e27-0bd86dcacb1a@github.com>
 <6jqlCPXe69fPRvYFrytJsECkaa9tJ1hYWISNgyPP4Eg=.40944ef5-93b0-4db4-948b-80bb7898e9e8@github.com>
 <o4Ql6TAAuuFFuwG8KTHF_bqg_ZliQfcRpuqgNsAGNPA=.2f1aa9d4-0e25-4c5d-b556-701eeba2cc81@github.com>
 <aw463dmr3OoI-xwE92WKIvGK4tY52jbMb3Bb8yKsu6c=.7fa08759-5663-4450-8576-29d43c1635c1@github.com>
Message-ID: <iyvweqL8dNEXuXMlFXdfx03yNRGyy8WLDMkG2NCN2Bk=.9dcfe9a7-3d6e-4227-b31b-a28c8e1614e3@github.com>

On Tue, 6 Oct 2020 02:00:06 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> I added the contributors that could be found in the portola project commits. If anyone knows some other contributors I
>> missed, I'll be happy to stand corrected.
>
> @voitylov For future reference please don't force-push commits on open PRs as it breaks the commit history. I can no
> longer just look at the two most recent commits and see what they added relative to what I had previously reviewed.
> Thanks.

@dholmes-ora yes, sorry about that. I updated the branch to pull the recent changes to enable pre-submit tests and
ensure everything is well before integration and though the branch looked good it confused the pull request. So I had
to force push it back to the original state.

-------------

PR: https://git.openjdk.java.net/jdk/pull/49

From jlahoda at openjdk.java.net  Thu Oct  8 11:55:51 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Thu, 8 Oct 2020 11:55:51 GMT
Subject: RFR: 8250625: Compiler implementation of Pattern Matching for
 instanceof (Final)
Message-ID: <0uEby0-y3KVBLA1VxxdD5hCMlLhPCKB3w0mpihs9dsY=.181f22cd-7cf7-4941-b2d1-2ba4228d11d5@github.com>

This is the current proposed patch for the upcoming JEP 394, for pattern matching for instanceof.

A summary of changes:
-making the feature permanent (non-preview)
-making the binding variables non-final (as per current specification proposal)
-producing a compile-time error for the case where the expression's type is a subtype of the type test pattern's type
 (as per current specification proposal)
-changing the AST structure so that the binding variable has a VariableTree in the AST. BindingPatternTree is preserved
 and encloses the VariableTree. The reason is better consistency in the API, with nodes like CatchTree, EnhancedForLoop
 Tree, etc.

This change will not be integrated until JEP 394 is targetted.

-------------

Commit messages:
 - Fixing more tests.
 - Correcting positions.
 - Improve the AST model.
 - Merge branch 'master' into patterns-instanceof3
 - Updating @since tags.
 - Merge branch 'master' into patterns-instanceof3
 - Cleaning up preview comments in javadoc.
 - Merge branch 'master' into patterns-instanceof3
 - Updating tests.
 - Cleanup.
 - ... and 3 more: https://git.openjdk.java.net/jdk/compare/97ff38ca...69c7dce8

Changes: https://git.openjdk.java.net/jdk/pull/559/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=559&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8250625
  Stats: 655 lines in 90 files changed: 242 ins; 302 del; 111 mod
  Patch: https://git.openjdk.java.net/jdk/pull/559.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/559/head:pull/559

PR: https://git.openjdk.java.net/jdk/pull/559

From chegar at openjdk.java.net  Thu Oct  8 12:44:56 2020
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Thu, 8 Oct 2020 12:44:56 GMT
Subject: RFR: 8254234 - Add test library stream object builder
Message-ID: <YG2nA5Bzj8YkrGnsdqFnHKGl_XugrwvFX3hoGjdgo_s=.3f19ec15-fa71-4f89-bf86-59287671ffca@github.com>

It is useful to have a test library facility for building stream objects, suitable for deserialization testing. We
already have a partial implementation in one of the record serialization tests, move it to the test library for more
general use. The implementation remains partial, but can be expanded as and when needed.

-------------

Commit messages:
 - Initial changes for 8254234 - Add test library stream object builder

Changes: https://git.openjdk.java.net/jdk/pull/561/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=561&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8254234
  Stats: 409 lines in 2 files changed: 220 ins; 169 del; 20 mod
  Patch: https://git.openjdk.java.net/jdk/pull/561.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/561/head:pull/561

PR: https://git.openjdk.java.net/jdk/pull/561

From sgehwolf at openjdk.java.net  Thu Oct  8 12:51:54 2020
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Thu, 8 Oct 2020 12:51:54 GMT
Subject: RFR: 8245543: Cgroups: Incorrect detection logic on some systems
 (still reproducible) [v5]
In-Reply-To: <CWATRi437QpkCA1sx-EsHFqVlSCV-G8EgkEoGdJgPHc=.a743be7e-8a00-4d91-866d-86ccf3fe714f@github.com>
References: <CWATRi437QpkCA1sx-EsHFqVlSCV-G8EgkEoGdJgPHc=.a743be7e-8a00-4d91-866d-86ccf3fe714f@github.com>
Message-ID: <wvQfMe2TfiOHvVmWaPZ27E4oNgRw2-6y77ujrcfL2Aw=.3106a097-e60d-4974-a01d-efb45e5af32b@github.com>

> An issue similar to [JDK-8239559](https://bugs.openjdk.java.net/browse/JDK-8239559) has been discovered. On the
> affected system, `/proc/self/mountinfo` contains a line such as this one:
> 
> 35 26 0:26 / /sys/fs/cgroup/systemd rw,nosuid,nodev,noexec,relatime - cgroup systemd rw,name=systemd
>  
> 
> Note that `/proc/cgroups` looks like this:
> 
> #subsys_name	hierarchy	num_cgroups	enabled
> cpuset	0	1	1
> cpu	0	1	1
> cpuacct	0	1	1
> blkio	0	1	1
> memory	0	1	1
> devices	0	1	1
> freezer	0	1	1
> net_cls	0	1	1
> perf_event	0	1	1
> net_prio	0	1	1
> hugetlb	0	1	1
> pids	0	1	1
> 
> This is in fact a cgroups v1 system with systemd put into a separate namespace via FS type `cgroup`. That mountinfo
> line confuses the cgroups version detection heuristic. It only looked whether or not there is **any** entry in
> mountinfo of FS-type `cgroup` . That's wrong. A better heuristic would be looking at controllers we care about: `cpu`,
> `cpuacct`, `memory`, `cpuset` for hotspot and some more for the Java side. The proposed fix on the hotspot side is to
> set `any_cgroup_mounts_found` to true only if one of those controllers show up in mountinfo. Otherwise, we know it's
> cgroup v2 due to the zero hierarchy ids. The fix on the Java side is similar.  For the Java side the proposal is also
> to do the parsing of the cgroup files in the factory now (single pass of files). No longer in the version specific
> objects. In order to not regress here, I've added more tests.
> **Testing**
> 
>  - [x] Linux x86_64 container tests on cgroup v1 (fastdebug)
>  - [x] Linux x86_64 container tests on cgroup v2 (fastdebug)
>  - [x] Added regression test which fails prior the patch and passes after
>  - [x] Submit testing

Severin Gehwolf 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:

  8245543: Cgroups: Incorrect detection logic on some systems (still reproducible)

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/485/files
  - new: https://git.openjdk.java.net/jdk/pull/485/files/5e2ca2dc..e72ac219

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=485&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=485&range=03-04

  Stats: 514 lines in 5 files changed: 159 ins; 231 del; 124 mod
  Patch: https://git.openjdk.java.net/jdk/pull/485.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/485/head:pull/485

PR: https://git.openjdk.java.net/jdk/pull/485

From sgehwolf at openjdk.java.net  Thu Oct  8 12:51:54 2020
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Thu, 8 Oct 2020 12:51:54 GMT
Subject: RFR: 8245543: Cgroups: Incorrect detection logic on some systems
 (still reproducible)
In-Reply-To: <KjxtazSZzF-w2Vcm0WuTzlKGWTrRq9J8wSpnutCNADo=.72a3458f-fc7c-4090-b0f0-ead08869ebb9@github.com>
References: <CWATRi437QpkCA1sx-EsHFqVlSCV-G8EgkEoGdJgPHc=.a743be7e-8a00-4d91-866d-86ccf3fe714f@github.com>
 <GQPVanQ-V8oL4npQHUXk5xw5pxR4fF8z3C_Wj5l7uDw=.1f4b9c49-252f-47dd-a0cf-6d36794928db@github.com>
 <p3wicme6jMQZ8q_ATLI4V-qN3p0PvWL8QACK3SCpE50=.bfa7b1e4-137b-4045-95f9-cb5fa7391ce5@github.com>
 <WhAslIX2i5viA-xU-nI9nNZRV91_XmEkwozi8NkWyLs=.a8ada202-c231-4837-9ac2-0091bb1bc510@github.com>
 <KjxtazSZzF-w2Vcm0WuTzlKGWTrRq9J8wSpnutCNADo=.72a3458f-fc7c-4090-b0f0-ead08869ebb9@github.com>
Message-ID: <iBmi3O02w2jX7XRLqYibNb_Er6hJpMMoJAus6IA8QY0=.5edc9fd4-898f-47e6-bffd-06cd7129e521@github.com>

On Mon, 5 Oct 2020 10:10:23 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>>> The change looks reasonable. I checked the fail - it is gone with the change! And both jtreg tests passed.
>> 
>> Thanks for the review and for testing it!
>
> @bobvandette Could you perhaps have a look at this? Many thanks in advance!

@bobvandette How about this?

-------------

PR: https://git.openjdk.java.net/jdk/pull/485

From erikj at openjdk.java.net  Thu Oct  8 12:56:43 2020
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Thu, 8 Oct 2020 12:56:43 GMT
Subject: RFR: 8254162: Implementation of Foreign-Memory Access API (Third
 Incubator) [v2]
In-Reply-To: <-K8a4gV16AZ7Se7-G2DWZrSEMr5FjLPzlUlo4nXnTE0=.c33f2a73-6ee1-4a9f-b992-d51fc1f2f481@github.com>
References: <IngRk57F78UN3yySfo6IABbdwnMogGNdYrykh_3em-c=.b81f7478-015c-45ed-9788-58d7519a2770@github.com>
 <-K8a4gV16AZ7Se7-G2DWZrSEMr5FjLPzlUlo4nXnTE0=.c33f2a73-6ee1-4a9f-b992-d51fc1f2f481@github.com>
Message-ID: <gaKz5jNDBdlz939ZuVY-Ov4G9QpPegBDnZ8GUrWSYXc=.adf2740f-2994-477e-b5ce-8b79989fe988@github.com>

On Thu, 8 Oct 2020 10:29:24 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This patch contains the changes associated with the third incubation round of the foreign memory access API incubation
>> (see JEP 393 [1]). This iteration focus on improving the usability of the API in 3 main ways:
>> * first, by providing a way to obtain truly *shared* segments, which can be accessed and closed concurrently from
>>   multiple threads
>> * second, by providing a way to register a memory segment against a `Cleaner`, so as to have some (optional) guarantee
>>   that the memory will be deallocated, eventually
>> * third, by not requiring users to dive deep into var handles when they first pick up the API; a new `MemoryAccess` class
>>   has been added, which defines several useful dereference routines; these are really just thin wrappers around memory
>>   access var handles, but they make the barrier of entry for using this API somewhat lower.
>> 
>> A big conceptual shift that comes with this API refresh is that the role of `MemorySegment` and `MemoryAddress` is not
>> the same as it used to be; it used to be the case that a memory address could (sometimes, not always) have a back link
>> to the memory segment which originated it; additionally, memory access var handles used `MemoryAddress` as a basic unit
>> of dereference.  This has all changed as per this API refresh;  now a `MemoryAddress` is just a dumb carrier which
>> wraps a pair of object/long addressing coordinates; `MemorySegment` has become the star of the show, as far as
>> dereferencing memory is concerned. You cannot dereference memory if you don't have a segment. This improves usability
>> in a number of ways - first, it is a lot easier to wrap native addresses (`long`, essentially) into a `MemoryAddress`;
>> secondly, it is crystal clear what a client has to do in order to dereference memory: if a client has a segment, it can
>> use that; otherwise, if the client only has an address, it will have to create a segment *unsafely* (this can be done
>> by calling `MemoryAddress::asSegmentRestricted`).  A list of the API, implementation and test changes is provided
>> below. If  you have any questions, or need more detailed explanations, I (and the  rest of the Panama team) will be
>> happy to point at existing discussions,  and/or to provide the feedback required.   A big thank to Erik Osterlund,
>> Vladimir Ivanov and David Holmes, without whom the work on shared memory segment would not have been possible; also I'd
>> like to thank Paul Sandoz, whose insights on API design have been very helpful in this journey.  Thanks  Maurizio
>> Javadoc:   http://cr.openjdk.java.net/~mcimadamore/8254162_v1/javadoc/jdk/incubator/foreign/package-summary.html
>> Specdiff:
>> 
>> http://cr.openjdk.java.net/~mcimadamore/8254162_v1/specdiff/jdk/incubator/foreign/package-summary.html
>> 
>> CSR:
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8254163
>> 
>> 
>> 
>> ### API Changes
>> 
>> * `MemorySegment`
>>   * drop factory for restricted segment (this has been moved to `MemoryAddress`, see below)
>>   * added a no-arg factory for a native restricted segment representing entire native heap
>>   * rename `withOwnerThread` to `handoff`
>>   * add new `share` method, to create shared segments
>>   * add new `registerCleaner` method, to register a segment against a cleaner
>>   * add more helpers to create arrays from a segment e.g. `toIntArray`
>>   * add some `asSlice` overloads (to make up for the fact that now segments are more frequently used as cursors)
>>   * rename `baseAddress` to `address` (so that `MemorySegment` can implement `Addressable`)
>> * `MemoryAddress`
>>   * drop `segment` accessor
>>   * drop `rebase` method and replace it with `segmentOffset` which returns the offset (a `long`) of this address relative
>>     to a given segment
>> * `MemoryAccess`
>>   * New class supporting several static dereference helpers; the helpers are organized by carrier and access mode, where a
>>     carrier is one of the usual suspect (a Java primitive, minus `boolean`); the access mode can be simple (e.g. access
>>     base address of given segment), or indexed, in which case the accessor takes a segment and either a low-level byte
>>     offset,or a high level logical index. The classification is reflected in the naming scheme (e.g. `getByte` vs.
>>     `getByteAtOffset` vs `getByteAtIndex`).
>> * `MemoryHandles`
>>   * drop `withOffset` combinator
>>   * drop `withStride` combinator
>>   * the basic memory access handle factory now returns a var handle which takes a `MemorySegment` and a `long` - from which
>>     it is easy to derive all the other handles using plain var handle combinators.
>> * `Addressable`
>>   * This is a new interface which is attached to entities which can be projected to a `MemoryAddress`. For now, both
>>     `MemoryAddress` and `MemorySegment` implement it; we have plans, with JEP 389 [2] to add more implementations. Clients
>>     can largely ignore this interface, which comes in really handy when defining native bindings with tools like `jextract`.
>> * `MemoryLayouts`
>>   * A new layout, for machine addresses, has been added to the mix.
>> 
>> 
>> 
>> ### Implementation changes
>> 
>> There are two main things to discuss here: support for shared segments, and the general simplification of the memory
>> access var handle support.
>> #### Shared segments
>> 
>> The support for shared segments cuts in pretty deep in the VM. Support for shared segments is notoriously hard to
>> achieve, at least in a way that guarantees optimal access performances. This is caused by the fact that, if a segment
>> is shared, it would be possible for a thread to close it while another is accessing it.  After considering several
>> options (see [3]), we zeroed onto an approach which is inspired by an happy idea that Andrew Haley had (and that he
>> reminded me of at this year OpenJDK committer workshop - thanks!). The idea is that if we could *freeze* the world
>> (e.g. with a GC pause), while a segment is closed, we could then prevent segments from being accessed concurrently to a
>> close operation. For this to work, it  is crucial that no GC safepoints can occur between a segment liveness check and
>> the access itself (otherwise it would be possible for the accessing thread to stop just right before an unsafe call).
>> It also relies on the fact that hotspot/C2 should not be able to propagate loads across safepoints.  Sadly, none of
>> these conditions seems to be valid in the current implementation, so we needed to resort to a bit of creativity. First,
>> we noted that, if we could mark so called *scoped* method with an annotation, it would be very simply to check as to
>> whether a thread was in the middle of a scoped method when we stopped the world for a close operation (btw, instead of
>> stopping the world, we do a much more efficient, thread-local polling, thanks to JEP 312 [4]).  The question is, then,
>> once we detect that a thread is accessing the very segment we're about to close, what should happen? We first
>> experimented with a solution which would install an *asynchronous* exception on the accessing thread, thus making it
>> fail. This solution has some desirable properties, in that a `close` operation always succeeds. Unfortunately the
>> machinery for async exceptions is a bit fragile (e.g. not all the code in hotspot checks for async exceptions); to
>> minimize risks, we decided to revert to a simpler strategy, where `close` might fail when it finds that another thread
>> is accessing the segment being closed.  As written in the javadoc, this doesn't mean that clients should just catch and
>> try again; an exception on `close` is a bug in the user code, likely arising from lack of synchronization, and should
>> be treated as such.  In terms of gritty implementation, we needed to centralize memory access routines in a single
>> place, so that we could have a set of routines closely mimicking the primitives exposed by `Unsafe` but which, in
>> addition, also provided a liveness check. This way we could mark all these routines with the special `@Scoped`
>> annotation, which tells the VM that something important is going on.  To achieve this, we created a new (autogenerated)
>> class, called `ScopedMemoryAccess`. This class contains all the main memory access primitives (including bulk access,
>> like `copyMemory`, or `setMemory`), and accepts, in addition to the access coordinates, also a scope object, which is
>> tested before access. A reachability fence is also thrown in the mix to make sure that the scope is kept alive during
>> access (which is important when registering segments against cleaners).  Of course, to make memory access safe, memory
>> access var handles, byte buffer var handles, and byte buffer API should use the new `ScopedMemoryAccess` class instead
>> of unsafe, so that a liveness check can be triggered (in case a scope is present).  `ScopedMemoryAccess` has a
>> `closeScope` method, which initiates the thread-local handshakes, and returns `true` if the handshake completed
>> successfully.  The implementation of `MemoryScope` (now significantly simplified from what we had before), has two
>> implementations, one for confined segments and one for shared segments; the main difference between the two is what
>> happens when the scope is closed; a confined segment sets a boolean flag to false, and returns, whereas a shared
>> segment goes into a `CLOSING` state, then starts the handshake, and then updates the state again, to either `CLOSED` or
>> `ALIVE` depending on whether the handshake was successful or not. Note that when a shared segment is in the `CLOSING`
>> state, `MemorySegment::isAlive` will still return `true`, while the liveness check upon memory access will fail.  ####
>> Memory access var handles overhaul  The key realization here was that if all memory access var handles took a
>> coordinate pair of `MemorySegment` and `long`, all other access types could be derived from this basic var handle
>> form.  This allowed us to remove the on-the-fly var handle generation, and to simply derive structural access var
>> handles (such as those obtained by calling `MemoryLayout::varHandle`) using *plain* var handle combinators, so that
>> e.g. additional offset is injected into a base memory access var handle.  This also helped in simplifying the
>> implementation by removing the special `withStride` and `withOffset` combinators, which previously needed low-level
>> access on the innards of the memory access var handle. All that code is now gone.  #### Test changes  Not much to see
>> here - most of the tests needed to be updated because of the API changes. Some were beefed up (like the array test,
>> since now segments can be projected into many different kinds of arrays). A test has been added to test the `Cleaner`
>> functionality, and another stress test has been added for shared segments (`TestHandshake`). Some of the
>> microbenchmarks also needed some tweaks - and some of them were also updated to also test performance in the shared
>> segment case.  [1] - https://openjdk.java.net/jeps/393 [2] - https://openjdk.java.net/jeps/389 [3] -
>> https://mail.openjdk.java.net/pipermail/panama-dev/2020-May/009004.html [4] - https://openjdk.java.net/jeps/312
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

make/modules/java.base/gensrc/GensrcScopedMemoryAccess.gmk line 145:

> 143: SCOPE_MEMORY_ACCESS_TYPES := Byte Short Char Int Long Float Double
> 144: $(foreach t, $(SCOPE_MEMORY_ACCESS_TYPES), \
> 145: 	  $(eval $(call GenerateScopedOp,BIN_$t,$t)))

This indent was fine at 2 spaces.  I meant the one below inside the recipe.

-------------

PR: https://git.openjdk.java.net/jdk/pull/548

From bobv at openjdk.java.net  Thu Oct  8 13:14:46 2020
From: bobv at openjdk.java.net (Bob Vandette)
Date: Thu, 8 Oct 2020 13:14:46 GMT
Subject: RFR: 8245543: Cgroups: Incorrect detection logic on some systems
 (still reproducible) [v5]
In-Reply-To: <wvQfMe2TfiOHvVmWaPZ27E4oNgRw2-6y77ujrcfL2Aw=.3106a097-e60d-4974-a01d-efb45e5af32b@github.com>
References: <CWATRi437QpkCA1sx-EsHFqVlSCV-G8EgkEoGdJgPHc=.a743be7e-8a00-4d91-866d-86ccf3fe714f@github.com>
 <wvQfMe2TfiOHvVmWaPZ27E4oNgRw2-6y77ujrcfL2Aw=.3106a097-e60d-4974-a01d-efb45e5af32b@github.com>
Message-ID: <Ev63XskGEKdnWNtSBjRspJhY0wA0cl8ZD-KWp4KaGZY=.779d44e0-654b-4dd9-97da-69bff01ce7d8@github.com>

On Thu, 8 Oct 2020 12:51:54 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> An issue similar to [JDK-8239559](https://bugs.openjdk.java.net/browse/JDK-8239559) has been discovered. On the
>> affected system, `/proc/self/mountinfo` contains a line such as this one:
>> 
>> 35 26 0:26 / /sys/fs/cgroup/systemd rw,nosuid,nodev,noexec,relatime - cgroup systemd rw,name=systemd
>>  
>> 
>> Note that `/proc/cgroups` looks like this:
>> 
>> #subsys_name	hierarchy	num_cgroups	enabled
>> cpuset	0	1	1
>> cpu	0	1	1
>> cpuacct	0	1	1
>> blkio	0	1	1
>> memory	0	1	1
>> devices	0	1	1
>> freezer	0	1	1
>> net_cls	0	1	1
>> perf_event	0	1	1
>> net_prio	0	1	1
>> hugetlb	0	1	1
>> pids	0	1	1
>> 
>> This is in fact a cgroups v1 system with systemd put into a separate namespace via FS type `cgroup`. That mountinfo
>> line confuses the cgroups version detection heuristic. It only looked whether or not there is **any** entry in
>> mountinfo of FS-type `cgroup` . That's wrong. A better heuristic would be looking at controllers we care about: `cpu`,
>> `cpuacct`, `memory`, `cpuset` for hotspot and some more for the Java side. The proposed fix on the hotspot side is to
>> set `any_cgroup_mounts_found` to true only if one of those controllers show up in mountinfo. Otherwise, we know it's
>> cgroup v2 due to the zero hierarchy ids. The fix on the Java side is similar.  For the Java side the proposal is also
>> to do the parsing of the cgroup files in the factory now (single pass of files). No longer in the version specific
>> objects. In order to not regress here, I've added more tests.
>> **Testing**
>> 
>>  - [x] Linux x86_64 container tests on cgroup v1 (fastdebug)
>>  - [x] Linux x86_64 container tests on cgroup v2 (fastdebug)
>>  - [x] Added regression test which fails prior the patch and passes after
>>  - [x] Submit testing
>
> Severin Gehwolf 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:
>   8245543: Cgroups: Incorrect detection logic on some systems (still reproducible)

src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemFactory.java line 185:

> 183:          } else {
> 184:            // fallback to old, pre JDK-8245543, behaviour
> 185:            return line.contains("cgroup");

Why are you doing this fallback rather than returning false??

-------------

PR: https://git.openjdk.java.net/jdk/pull/485

From github.com+6304496+dreis2211 at openjdk.java.net  Thu Oct  8 13:20:46 2020
From: github.com+6304496+dreis2211 at openjdk.java.net (Christoph Dreis)
Date: Thu, 8 Oct 2020 13:20:46 GMT
Subject: Integrated: 8254146: Avoid unnecessary volatile write on new
 AtomicBoolean(false)
In-Reply-To: <AzWKluHZjvFYm2wUanwYfn91iKKMacpk_qSsje3tXWk=.ba873b46-4e12-4415-8832-fa314d6759a3@github.com>
References: <AzWKluHZjvFYm2wUanwYfn91iKKMacpk_qSsje3tXWk=.ba873b46-4e12-4415-8832-fa314d6759a3@github.com>
Message-ID: <CuoXSMmdT1n9HCvTkeiikYkJ-owveJK5kFbwAsKLndo=.aa13911c-c1ae-4d1a-bcb0-ede7671055d2@github.com>

On Mon, 5 Oct 2020 17:25:28 GMT, Christoph Dreis <github.com+6304496+dreis2211 at openjdk.org> wrote:

> Hi,
> 
> the following PR optimizes `new AtomicBoolean(boolean)` by avoiding the volatile write in case `false` is passed.
> Essentially, it changes the ternary operator to a simple `if` without the `else` that would cause the volatile write.
> The resulting bytecode seems to also benefit from the change:
>     Code:
>        0: aload_0
>        1: invokespecial #1                  // Method java/lang/Object."<init>":()V
>        4: aload_0
>        5: iload_1
>        6: ifeq          13
>        9: iconst_1
>       10: goto          14
>       13: iconst_0
>       14: putfield      #7                  // Field value:I
>       17: return
> 
> After:
>     Code:
>        0: aload_0
>        1: invokespecial #1                  // Method java/lang/Object."<init>":()V
>        4: iload_1
>        5: ifeq          13
>        8: aload_0
>        9: iconst_1
>       10: putfield      #7                  // Field value:I
>       13: return
> 
> A simple benchmark that returns `new AtomicBoolean(false)` shows the following results, that brings it on par to `new
> AtomicBoolean()`: MyBenchmark.empty                                         avgt   10     3,103 ?   0,246   ns/op
> MyBenchmark.explicitNew                                   avgt   10     2,966 ?   0,071   ns/op
> MyBenchmark.explicitOld                                   avgt   10     7,738 ?   0,321   ns/op
> 
> In case you think this is worthwhile I'd be happy if this is sponsored.
> Cheers,
> Christoph

This pull request has now been integrated.

Changeset: 7e82ba1f
Author:    Christoph Dreis <christoph.dreis at freenet.de>
Committer: Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/7e82ba1f
Stats:     3 lines in 1 file changed: 2 ins; 0 del; 1 mod

8254146: Avoid unnecessary volatile write on new AtomicBoolean(false)

Reviewed-by: redestad, rriggs, chegar

-------------

PR: https://git.openjdk.java.net/jdk/pull/510

From sgehwolf at openjdk.java.net  Thu Oct  8 13:38:59 2020
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Thu, 8 Oct 2020 13:38:59 GMT
Subject: RFR: 8245543: Cgroups: Incorrect detection logic on some systems
 (still reproducible) [v6]
In-Reply-To: <CWATRi437QpkCA1sx-EsHFqVlSCV-G8EgkEoGdJgPHc=.a743be7e-8a00-4d91-866d-86ccf3fe714f@github.com>
References: <CWATRi437QpkCA1sx-EsHFqVlSCV-G8EgkEoGdJgPHc=.a743be7e-8a00-4d91-866d-86ccf3fe714f@github.com>
Message-ID: <ib0g_wcL2UGww1rsF-zydPbVHaqKAOZbqSnYwzSFyms=.41072921-e238-41fd-b9a7-31e1c714ab92@github.com>

> An issue similar to [JDK-8239559](https://bugs.openjdk.java.net/browse/JDK-8239559) has been discovered. On the
> affected system, `/proc/self/mountinfo` contains a line such as this one:
> 
> 35 26 0:26 / /sys/fs/cgroup/systemd rw,nosuid,nodev,noexec,relatime - cgroup systemd rw,name=systemd
>  
> 
> Note that `/proc/cgroups` looks like this:
> 
> #subsys_name	hierarchy	num_cgroups	enabled
> cpuset	0	1	1
> cpu	0	1	1
> cpuacct	0	1	1
> blkio	0	1	1
> memory	0	1	1
> devices	0	1	1
> freezer	0	1	1
> net_cls	0	1	1
> perf_event	0	1	1
> net_prio	0	1	1
> hugetlb	0	1	1
> pids	0	1	1
> 
> This is in fact a cgroups v1 system with systemd put into a separate namespace via FS type `cgroup`. That mountinfo
> line confuses the cgroups version detection heuristic. It only looked whether or not there is **any** entry in
> mountinfo of FS-type `cgroup` . That's wrong. A better heuristic would be looking at controllers we care about: `cpu`,
> `cpuacct`, `memory`, `cpuset` for hotspot and some more for the Java side. The proposed fix on the hotspot side is to
> set `any_cgroup_mounts_found` to true only if one of those controllers show up in mountinfo. Otherwise, we know it's
> cgroup v2 due to the zero hierarchy ids. The fix on the Java side is similar.  For the Java side the proposal is also
> to do the parsing of the cgroup files in the factory now (single pass of files). No longer in the version specific
> objects. In order to not regress here, I've added more tests.
> **Testing**
> 
>  - [x] Linux x86_64 container tests on cgroup v1 (fastdebug)
>  - [x] Linux x86_64 container tests on cgroup v2 (fastdebug)
>  - [x] Added regression test which fails prior the patch and passes after
>  - [x] Submit testing

Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:

  Return false in case of no pattern match

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/485/files
  - new: https://git.openjdk.java.net/jdk/pull/485/files/e72ac219..37f5b093

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=485&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=485&range=04-05

  Stats: 7 lines in 1 file changed: 2 ins; 5 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/485.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/485/head:pull/485

PR: https://git.openjdk.java.net/jdk/pull/485

From sgehwolf at openjdk.java.net  Thu Oct  8 13:39:00 2020
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Thu, 8 Oct 2020 13:39:00 GMT
Subject: RFR: 8245543: Cgroups: Incorrect detection logic on some systems
 (still reproducible) [v5]
In-Reply-To: <Ev63XskGEKdnWNtSBjRspJhY0wA0cl8ZD-KWp4KaGZY=.779d44e0-654b-4dd9-97da-69bff01ce7d8@github.com>
References: <CWATRi437QpkCA1sx-EsHFqVlSCV-G8EgkEoGdJgPHc=.a743be7e-8a00-4d91-866d-86ccf3fe714f@github.com>
 <wvQfMe2TfiOHvVmWaPZ27E4oNgRw2-6y77ujrcfL2Aw=.3106a097-e60d-4974-a01d-efb45e5af32b@github.com>
 <Ev63XskGEKdnWNtSBjRspJhY0wA0cl8ZD-KWp4KaGZY=.779d44e0-654b-4dd9-97da-69bff01ce7d8@github.com>
Message-ID: <DXmPcZWwkM6ab3-4qVdoz5VcQTje_OrT3LuKqGWYRCs=.5c7dcad6-20a9-4797-93a2-1889adf564d3@github.com>

On Thu, 8 Oct 2020 13:12:02 GMT, Bob Vandette <bobv at openjdk.org> wrote:

>> Severin Gehwolf 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:
>>   8245543: Cgroups: Incorrect detection logic on some systems (still reproducible)
>
> src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemFactory.java line 185:
> 
>> 183:          } else {
>> 184:            // fallback to old, pre JDK-8245543, behaviour
>> 185:            return line.contains("cgroup");
> 
> Why are you doing this fallback rather than returning false??

The idea was to have have some basics working even though the pattern doesn't match for some reason. I guess we can
remove that as it's rather unlikely to not match.

-------------

PR: https://git.openjdk.java.net/jdk/pull/485

From rriggs at openjdk.java.net  Thu Oct  8 13:48:47 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 8 Oct 2020 13:48:47 GMT
Subject: RFR: 8254234 - Add test library stream object builder
In-Reply-To: <YG2nA5Bzj8YkrGnsdqFnHKGl_XugrwvFX3hoGjdgo_s=.3f19ec15-fa71-4f89-bf86-59287671ffca@github.com>
References: <YG2nA5Bzj8YkrGnsdqFnHKGl_XugrwvFX3hoGjdgo_s=.3f19ec15-fa71-4f89-bf86-59287671ffca@github.com>
Message-ID: <QqyKicnVcin268c1qp7GvYJWlX1uVsydx7AvOGISRh4=.722aa9b8-13af-4425-8826-e147e58e1641@github.com>

On Thu, 8 Oct 2020 12:38:42 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

> It is useful to have a test library facility for building stream objects, suitable for deserialization testing. We
> already have a partial implementation in one of the record serialization tests, move it to the test library for more
> general use. The implementation remains partial, but can be expanded as and when needed.

Changes requested by rriggs (Reviewer).

test/lib/jdk/test/lib/serial/SerialObjectBuilder.java line 93:

> 91:     }
> 92:
> 93:     private static int getPrimitiveSignature(Class<?> cl) {

The new java.lang.constant.TypeDescriptor will provide the primitive type from the Class.
Class implements TypeDescriptor including descriptorString.

This method can be replaced with clazz.descriptorString().

test/lib/jdk/test/lib/serial/SerialObjectBuilder.java line 140:

> 138:             Class<?> cl = entry.getKey().type();
> 139:             assert !cl.isPrimitive();
> 140:             // obj_typecode

Try replacing 141-150 with cl.descriptorString(). It looks like it will do all the encoding of the class.

test/lib/jdk/test/lib/serial/SerialObjectBuilder.java line 106:

> 104:
> 105:     private static void writeUTF(DataOutputStream out, String str) throws IOException {
> 106:         int utflen = str.length(); // assume ASCII

Add an assert to confirm its ASCII, or update the code to correctly estimate the number of bytes.
Possibly by using DOS to write to a temporary BAOS.

-------------

PR: https://git.openjdk.java.net/jdk/pull/561

From mcimadamore at openjdk.java.net  Thu Oct  8 13:49:47 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 8 Oct 2020 13:49:47 GMT
Subject: RFR: 8254162: Implementation of Foreign-Memory Access API (Third
 Incubator) [v2]
In-Reply-To: <gaKz5jNDBdlz939ZuVY-Ov4G9QpPegBDnZ8GUrWSYXc=.adf2740f-2994-477e-b5ce-8b79989fe988@github.com>
References: <IngRk57F78UN3yySfo6IABbdwnMogGNdYrykh_3em-c=.b81f7478-015c-45ed-9788-58d7519a2770@github.com>
 <-K8a4gV16AZ7Se7-G2DWZrSEMr5FjLPzlUlo4nXnTE0=.c33f2a73-6ee1-4a9f-b992-d51fc1f2f481@github.com>
 <gaKz5jNDBdlz939ZuVY-Ov4G9QpPegBDnZ8GUrWSYXc=.adf2740f-2994-477e-b5ce-8b79989fe988@github.com>
Message-ID: <XP-kyY-c322vvb8oDuPCKTQd0PybzedmsxJ9ym1uu5E=.a14ec02a-be93-43ab-aced-b280ef14a855@github.com>

On Thu, 8 Oct 2020 12:54:12 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review comments
>
> make/modules/java.base/gensrc/GensrcScopedMemoryAccess.gmk line 145:
> 
>> 143: SCOPE_MEMORY_ACCESS_TYPES := Byte Short Char Int Long Float Double
>> 144: $(foreach t, $(SCOPE_MEMORY_ACCESS_TYPES), \
>> 145: 	  $(eval $(call GenerateScopedOp,BIN_$t,$t)))
> 
> This indent was fine at 2 spaces.  I meant the one below inside the recipe.

Gotcha - I fixed the wrong foreach...

-------------

PR: https://git.openjdk.java.net/jdk/pull/548

From mcimadamore at openjdk.java.net  Thu Oct  8 13:59:20 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 8 Oct 2020 13:59:20 GMT
Subject: RFR: 8254162: Implementation of Foreign-Memory Access API (Third
 Incubator) [v3]
In-Reply-To: <IngRk57F78UN3yySfo6IABbdwnMogGNdYrykh_3em-c=.b81f7478-015c-45ed-9788-58d7519a2770@github.com>
References: <IngRk57F78UN3yySfo6IABbdwnMogGNdYrykh_3em-c=.b81f7478-015c-45ed-9788-58d7519a2770@github.com>
Message-ID: <lJUy8C4jwS7mc82Pt2_q4CBz3RB2LuV_gf1JG1QyqsI=.d032ebb5-0a1d-48b7-976a-0af3697671c6@github.com>

> This patch contains the changes associated with the third incubation round of the foreign memory access API incubation
> (see JEP 393 [1]). This iteration focus on improving the usability of the API in 3 main ways:
> * first, by providing a way to obtain truly *shared* segments, which can be accessed and closed concurrently from
>   multiple threads
> * second, by providing a way to register a memory segment against a `Cleaner`, so as to have some (optional) guarantee
>   that the memory will be deallocated, eventually
> * third, by not requiring users to dive deep into var handles when they first pick up the API; a new `MemoryAccess` class
>   has been added, which defines several useful dereference routines; these are really just thin wrappers around memory
>   access var handles, but they make the barrier of entry for using this API somewhat lower.
> 
> A big conceptual shift that comes with this API refresh is that the role of `MemorySegment` and `MemoryAddress` is not
> the same as it used to be; it used to be the case that a memory address could (sometimes, not always) have a back link
> to the memory segment which originated it; additionally, memory access var handles used `MemoryAddress` as a basic unit
> of dereference.  This has all changed as per this API refresh;  now a `MemoryAddress` is just a dumb carrier which
> wraps a pair of object/long addressing coordinates; `MemorySegment` has become the star of the show, as far as
> dereferencing memory is concerned. You cannot dereference memory if you don't have a segment. This improves usability
> in a number of ways - first, it is a lot easier to wrap native addresses (`long`, essentially) into a `MemoryAddress`;
> secondly, it is crystal clear what a client has to do in order to dereference memory: if a client has a segment, it can
> use that; otherwise, if the client only has an address, it will have to create a segment *unsafely* (this can be done
> by calling `MemoryAddress::asSegmentRestricted`).  A list of the API, implementation and test changes is provided
> below. If  you have any questions, or need more detailed explanations, I (and the  rest of the Panama team) will be
> happy to point at existing discussions,  and/or to provide the feedback required.   A big thank to Erik Osterlund,
> Vladimir Ivanov and David Holmes, without whom the work on shared memory segment would not have been possible; also I'd
> like to thank Paul Sandoz, whose insights on API design have been very helpful in this journey.  Thanks  Maurizio
> Javadoc:   http://cr.openjdk.java.net/~mcimadamore/8254162_v1/javadoc/jdk/incubator/foreign/package-summary.html
> Specdiff:
> 
> http://cr.openjdk.java.net/~mcimadamore/8254162_v1/specdiff/jdk/incubator/foreign/package-summary.html
> 
> CSR:
> 
> https://bugs.openjdk.java.net/browse/JDK-8254163
> 
> 
> 
> ### API Changes
> 
> * `MemorySegment`
>   * drop factory for restricted segment (this has been moved to `MemoryAddress`, see below)
>   * added a no-arg factory for a native restricted segment representing entire native heap
>   * rename `withOwnerThread` to `handoff`
>   * add new `share` method, to create shared segments
>   * add new `registerCleaner` method, to register a segment against a cleaner
>   * add more helpers to create arrays from a segment e.g. `toIntArray`
>   * add some `asSlice` overloads (to make up for the fact that now segments are more frequently used as cursors)
>   * rename `baseAddress` to `address` (so that `MemorySegment` can implement `Addressable`)
> * `MemoryAddress`
>   * drop `segment` accessor
>   * drop `rebase` method and replace it with `segmentOffset` which returns the offset (a `long`) of this address relative
>     to a given segment
> * `MemoryAccess`
>   * New class supporting several static dereference helpers; the helpers are organized by carrier and access mode, where a
>     carrier is one of the usual suspect (a Java primitive, minus `boolean`); the access mode can be simple (e.g. access
>     base address of given segment), or indexed, in which case the accessor takes a segment and either a low-level byte
>     offset,or a high level logical index. The classification is reflected in the naming scheme (e.g. `getByte` vs.
>     `getByteAtOffset` vs `getByteAtIndex`).
> * `MemoryHandles`
>   * drop `withOffset` combinator
>   * drop `withStride` combinator
>   * the basic memory access handle factory now returns a var handle which takes a `MemorySegment` and a `long` - from which
>     it is easy to derive all the other handles using plain var handle combinators.
> * `Addressable`
>   * This is a new interface which is attached to entities which can be projected to a `MemoryAddress`. For now, both
>     `MemoryAddress` and `MemorySegment` implement it; we have plans, with JEP 389 [2] to add more implementations. Clients
>     can largely ignore this interface, which comes in really handy when defining native bindings with tools like `jextract`.
> * `MemoryLayouts`
>   * A new layout, for machine addresses, has been added to the mix.
> 
> 
> 
> ### Implementation changes
> 
> There are two main things to discuss here: support for shared segments, and the general simplification of the memory
> access var handle support.
> #### Shared segments
> 
> The support for shared segments cuts in pretty deep in the VM. Support for shared segments is notoriously hard to
> achieve, at least in a way that guarantees optimal access performances. This is caused by the fact that, if a segment
> is shared, it would be possible for a thread to close it while another is accessing it.  After considering several
> options (see [3]), we zeroed onto an approach which is inspired by an happy idea that Andrew Haley had (and that he
> reminded me of at this year OpenJDK committer workshop - thanks!). The idea is that if we could *freeze* the world
> (e.g. with a GC pause), while a segment is closed, we could then prevent segments from being accessed concurrently to a
> close operation. For this to work, it  is crucial that no GC safepoints can occur between a segment liveness check and
> the access itself (otherwise it would be possible for the accessing thread to stop just right before an unsafe call).
> It also relies on the fact that hotspot/C2 should not be able to propagate loads across safepoints.  Sadly, none of
> these conditions seems to be valid in the current implementation, so we needed to resort to a bit of creativity. First,
> we noted that, if we could mark so called *scoped* method with an annotation, it would be very simply to check as to
> whether a thread was in the middle of a scoped method when we stopped the world for a close operation (btw, instead of
> stopping the world, we do a much more efficient, thread-local polling, thanks to JEP 312 [4]).  The question is, then,
> once we detect that a thread is accessing the very segment we're about to close, what should happen? We first
> experimented with a solution which would install an *asynchronous* exception on the accessing thread, thus making it
> fail. This solution has some desirable properties, in that a `close` operation always succeeds. Unfortunately the
> machinery for async exceptions is a bit fragile (e.g. not all the code in hotspot checks for async exceptions); to
> minimize risks, we decided to revert to a simpler strategy, where `close` might fail when it finds that another thread
> is accessing the segment being closed.  As written in the javadoc, this doesn't mean that clients should just catch and
> try again; an exception on `close` is a bug in the user code, likely arising from lack of synchronization, and should
> be treated as such.  In terms of gritty implementation, we needed to centralize memory access routines in a single
> place, so that we could have a set of routines closely mimicking the primitives exposed by `Unsafe` but which, in
> addition, also provided a liveness check. This way we could mark all these routines with the special `@Scoped`
> annotation, which tells the VM that something important is going on.  To achieve this, we created a new (autogenerated)
> class, called `ScopedMemoryAccess`. This class contains all the main memory access primitives (including bulk access,
> like `copyMemory`, or `setMemory`), and accepts, in addition to the access coordinates, also a scope object, which is
> tested before access. A reachability fence is also thrown in the mix to make sure that the scope is kept alive during
> access (which is important when registering segments against cleaners).  Of course, to make memory access safe, memory
> access var handles, byte buffer var handles, and byte buffer API should use the new `ScopedMemoryAccess` class instead
> of unsafe, so that a liveness check can be triggered (in case a scope is present).  `ScopedMemoryAccess` has a
> `closeScope` method, which initiates the thread-local handshakes, and returns `true` if the handshake completed
> successfully.  The implementation of `MemoryScope` (now significantly simplified from what we had before), has two
> implementations, one for confined segments and one for shared segments; the main difference between the two is what
> happens when the scope is closed; a confined segment sets a boolean flag to false, and returns, whereas a shared
> segment goes into a `CLOSING` state, then starts the handshake, and then updates the state again, to either `CLOSED` or
> `ALIVE` depending on whether the handshake was successful or not. Note that when a shared segment is in the `CLOSING`
> state, `MemorySegment::isAlive` will still return `true`, while the liveness check upon memory access will fail.  ####
> Memory access var handles overhaul  The key realization here was that if all memory access var handles took a
> coordinate pair of `MemorySegment` and `long`, all other access types could be derived from this basic var handle
> form.  This allowed us to remove the on-the-fly var handle generation, and to simply derive structural access var
> handles (such as those obtained by calling `MemoryLayout::varHandle`) using *plain* var handle combinators, so that
> e.g. additional offset is injected into a base memory access var handle.  This also helped in simplifying the
> implementation by removing the special `withStride` and `withOffset` combinators, which previously needed low-level
> access on the innards of the memory access var handle. All that code is now gone.  #### Test changes  Not much to see
> here - most of the tests needed to be updated because of the API changes. Some were beefed up (like the array test,
> since now segments can be projected into many different kinds of arrays). A test has been added to test the `Cleaner`
> functionality, and another stress test has been added for shared segments (`TestHandshake`). Some of the
> microbenchmarks also needed some tweaks - and some of them were also updated to also test performance in the shared
> segment case.  [1] - https://openjdk.java.net/jeps/393 [2] - https://openjdk.java.net/jeps/389 [3] -
> https://mail.openjdk.java.net/pipermail/panama-dev/2020-May/009004.html [4] - https://openjdk.java.net/jeps/312

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Fix indent in GensrcScopedMemoryAccess.gmk

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/548/files
  - new: https://git.openjdk.java.net/jdk/pull/548/files/fa051abf..b941c4a2

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=548&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=548&range=01-02

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/548.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/548/head:pull/548

PR: https://git.openjdk.java.net/jdk/pull/548

From rriggs at openjdk.java.net  Thu Oct  8 14:02:51 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 8 Oct 2020 14:02:51 GMT
Subject: RFR: 8188055: (ref) Add Reference::refersTo predicate [v2]
In-Reply-To: <Y1IHoNr8vO3OkCbEKw6ywXd4adik1yKKNIS4ABzF0d0=.d21f4183-ef4e-45ed-826d-6613215b6220@github.com>
References: <D4HSg8FT20Eaxk5KJkkw0GgETSxRkBn1ipS3Dt0kPto=.e4bab078-2e04-4413-90cb-9bfafb2a6831@github.com>
 <Y1IHoNr8vO3OkCbEKw6ywXd4adik1yKKNIS4ABzF0d0=.d21f4183-ef4e-45ed-826d-6613215b6220@github.com>
Message-ID: <Tb1VL1yPx2XEmwhHdZwz_NE8DiUcsAzQba9wmmDjEus=.f03ebf90-92c4-44c9-a1c4-21e16d17d262@github.com>

On Tue, 6 Oct 2020 00:19:33 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Kim Barrett has updated the pull request incrementally with five additional commits since the last revision:
>> 
>>  - improve refersTo0 descriptions
>>  - basic functional test
>>  - change referent access
>>  - expand test
>>  - remove CMS comment
>
> Can you add a unit test in `test/jdk/java/lang/ref` that serves as a basic API test for this new `refersTo` API without
> depending the WhiteBox API?     test/hotspot/jtreg/gc` test serves as a more white-boxed type and comprehensive test.

Hi Kim,

At what point would the @IntrinsicCandidate annotation be added to the
refersTo0 methods?
it would be useful documentation even if it is not needed for the mechanism.

Thanks for the explanation, Roger


On 10/8/20 3:58 AM, mlbridge[bot] wrote:
>
> /Mailing list message from Kim Barrett <mailto:kim.barrett at oracle.com>
> on hotspot-gc-dev <mailto:hotspot-gc-dev at openjdk.java.net>:/
>
>     On Oct 5, 2020, at 9:15 PM, Roger Riggs <rriggs at
>     openjdk.java.net> wrote:
>     src/java.base/share/classes/java/lang/ref/PhantomReference.java
>     line 66:
>
>         64: @override
>         <https://urldefense.com/v3/__https://github.com/override__;!!GqivPVa7Brio!MXZs7XLDGF7idnDuZ1hTIGY4LTzS5Lx_xCAlYuwDG6C1Vno9_RgMleOn8nJgqULa$>
>         65: native final boolean refersTo0(Object o);
>         66:
>
>     How does the existence of this method help future intrinsification?
>     If it was called somewhere it would be clearer.
>     Perhaps a comment now or later would help explain its function.
>
> public final refersTo(T o) calls refersTo0(o)
>
> We have package private:
> native boolean Reference::refersTo0(Object)
> final native boolean PhantomReference::refersTo0(Object)
>
> The reason for this split has to do with details in the VM support, in
> particular C2 intrinsification.
>
> For the native method support we don't need this split. The original
> version from back in April just had a single native method in
> Reference. (It
> did have native refersTo0, but that was my not realizing native methods
> could have a parameterized type that would get type-erased automatically;
> see response to Mandy.) That native method performed a runtime check
> on the
> ReferenceType of the reference's klass to determine what to do. (See
> below.)
>
> Phantom references need to be treated differently from stronger "weak"
> reference types, because phantom references are weaker than
> finalization, so
> might not be cleared when a stronger reference to the same object is
> cleared. For collectors with STW reference processing this doesn't make
> much difference (the referent is either cleared or not), but making this
> distinction correctly is necessary for concurrent reference processing.
>
> The Access API that provides the interface to the GC has support for
> "unknown" referent accesses that perform a runtime lookup. This is
> supported in C++ code, but not in the various Java code processors
> (interpreter and compilers). We didn't previously need to support that
> case
> for Java because the only place where it mattered was accessing the
> referent
> of a PhantomReference, and that is blocked by PhantomReference::get that
> always returns null.
>
> For refersTo the intent is to have the interpreter and C1 use the native
> method, but have C2 have special knowledge for it. We could add
> support for
> the "unknown" reference type to C2, but that's a substantial amount of
> work,
> and only useful for this one place. Or we can take the same approach
> as for
> get(), i.e. have a second method on PhantomReference so that calls
> that can
> select the appropriate method at compile time (usually the case) can have
> distinct intrinsics for the two cases.
>
> By having these intrinsifiable native methods be package private we
> can have
> the public refersTo API function be final, while also preventing any
> further
> overrides by classes not in the same package.
>
> I'll try to come up with some commentary.
>
> ?
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub
> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/498*issuecomment-705400053__;Iw!!GqivPVa7Brio!MXZs7XLDGF7idnDuZ1hTIGY4LTzS5Lx_xCAlYuwDG6C1Vno9_RgMleOn8m3Tmikx$>,
> or unsubscribe
> <https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/AAIRSVBIN2XWNEM3ILBOLI3SJVWI3ANCNFSM4SDN74VA__;!!GqivPVa7Brio!MXZs7XLDGF7idnDuZ1hTIGY4LTzS5Lx_xCAlYuwDG6C1Vno9_RgMleOn8skFFiqO$>.
>

-------------

PR: https://git.openjdk.java.net/jdk/pull/498

From bobv at openjdk.java.net  Thu Oct  8 14:03:48 2020
From: bobv at openjdk.java.net (Bob Vandette)
Date: Thu, 8 Oct 2020 14:03:48 GMT
Subject: RFR: 8245543: Cgroups: Incorrect detection logic on some systems
 (still reproducible) [v6]
In-Reply-To: <ib0g_wcL2UGww1rsF-zydPbVHaqKAOZbqSnYwzSFyms=.41072921-e238-41fd-b9a7-31e1c714ab92@github.com>
References: <CWATRi437QpkCA1sx-EsHFqVlSCV-G8EgkEoGdJgPHc=.a743be7e-8a00-4d91-866d-86ccf3fe714f@github.com>
 <ib0g_wcL2UGww1rsF-zydPbVHaqKAOZbqSnYwzSFyms=.41072921-e238-41fd-b9a7-31e1c714ab92@github.com>
Message-ID: <XUU07XfZZMXgjqLJlMH80N0jKlPTnyVGM3ZAWHFlxas=.701d6f5c-0a38-4612-8ef5-007aa6e7769d@github.com>

On Thu, 8 Oct 2020 13:38:59 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> An issue similar to [JDK-8239559](https://bugs.openjdk.java.net/browse/JDK-8239559) has been discovered. On the
>> affected system, `/proc/self/mountinfo` contains a line such as this one:
>> 
>> 35 26 0:26 / /sys/fs/cgroup/systemd rw,nosuid,nodev,noexec,relatime - cgroup systemd rw,name=systemd
>>  
>> 
>> Note that `/proc/cgroups` looks like this:
>> 
>> #subsys_name	hierarchy	num_cgroups	enabled
>> cpuset	0	1	1
>> cpu	0	1	1
>> cpuacct	0	1	1
>> blkio	0	1	1
>> memory	0	1	1
>> devices	0	1	1
>> freezer	0	1	1
>> net_cls	0	1	1
>> perf_event	0	1	1
>> net_prio	0	1	1
>> hugetlb	0	1	1
>> pids	0	1	1
>> 
>> This is in fact a cgroups v1 system with systemd put into a separate namespace via FS type `cgroup`. That mountinfo
>> line confuses the cgroups version detection heuristic. It only looked whether or not there is **any** entry in
>> mountinfo of FS-type `cgroup` . That's wrong. A better heuristic would be looking at controllers we care about: `cpu`,
>> `cpuacct`, `memory`, `cpuset` for hotspot and some more for the Java side. The proposed fix on the hotspot side is to
>> set `any_cgroup_mounts_found` to true only if one of those controllers show up in mountinfo. Otherwise, we know it's
>> cgroup v2 due to the zero hierarchy ids. The fix on the Java side is similar.  For the Java side the proposal is also
>> to do the parsing of the cgroup files in the factory now (single pass of files). No longer in the version specific
>> objects. In order to not regress here, I've added more tests.
>> **Testing**
>> 
>>  - [x] Linux x86_64 container tests on cgroup v1 (fastdebug)
>>  - [x] Linux x86_64 container tests on cgroup v2 (fastdebug)
>>  - [x] Added regression test which fails prior the patch and passes after
>>  - [x] Submit testing
>
> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Return false in case of no pattern match

Marked as reviewed by bobv (Committer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/485

From bobv at openjdk.java.net  Thu Oct  8 14:03:50 2020
From: bobv at openjdk.java.net (Bob Vandette)
Date: Thu, 8 Oct 2020 14:03:50 GMT
Subject: RFR: 8245543: Cgroups: Incorrect detection logic on some systems
 (still reproducible) [v5]
In-Reply-To: <DXmPcZWwkM6ab3-4qVdoz5VcQTje_OrT3LuKqGWYRCs=.5c7dcad6-20a9-4797-93a2-1889adf564d3@github.com>
References: <CWATRi437QpkCA1sx-EsHFqVlSCV-G8EgkEoGdJgPHc=.a743be7e-8a00-4d91-866d-86ccf3fe714f@github.com>
 <wvQfMe2TfiOHvVmWaPZ27E4oNgRw2-6y77ujrcfL2Aw=.3106a097-e60d-4974-a01d-efb45e5af32b@github.com>
 <Ev63XskGEKdnWNtSBjRspJhY0wA0cl8ZD-KWp4KaGZY=.779d44e0-654b-4dd9-97da-69bff01ce7d8@github.com>
 <DXmPcZWwkM6ab3-4qVdoz5VcQTje_OrT3LuKqGWYRCs=.5c7dcad6-20a9-4797-93a2-1889adf564d3@github.com>
Message-ID: <hi0ZiSwyV6REgKpNIKJwnrsyeUk28x4pSAKtfYcfn2I=.03a15f47-c163-4ace-96b7-24696197941e@github.com>

On Thu, 8 Oct 2020 13:36:20 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemFactory.java line 185:
>> 
>>> 183:          } else {
>>> 184:            // fallback to old, pre JDK-8245543, behaviour
>>> 185:            return line.contains("cgroup");
>> 
>> Why are you doing this fallback rather than returning false??
>
> The idea was to have have some basics working even though the pattern doesn't match for some reason. I guess we can
> remove that as it's rather unlikely to not match.

The change looks good.

-------------

PR: https://git.openjdk.java.net/jdk/pull/485

From sgehwolf at openjdk.java.net  Thu Oct  8 14:49:46 2020
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Thu, 8 Oct 2020 14:49:46 GMT
Subject: RFR: 8245543: Cgroups: Incorrect detection logic on some systems
 (still reproducible) [v6]
In-Reply-To: <XUU07XfZZMXgjqLJlMH80N0jKlPTnyVGM3ZAWHFlxas=.701d6f5c-0a38-4612-8ef5-007aa6e7769d@github.com>
References: <CWATRi437QpkCA1sx-EsHFqVlSCV-G8EgkEoGdJgPHc=.a743be7e-8a00-4d91-866d-86ccf3fe714f@github.com>
 <ib0g_wcL2UGww1rsF-zydPbVHaqKAOZbqSnYwzSFyms=.41072921-e238-41fd-b9a7-31e1c714ab92@github.com>
 <XUU07XfZZMXgjqLJlMH80N0jKlPTnyVGM3ZAWHFlxas=.701d6f5c-0a38-4612-8ef5-007aa6e7769d@github.com>
Message-ID: <jZ92keiTRqBIUZIGu8R-jabQ4BIy2GynkhEwKoJy-yo=.753734be-6dd4-44f0-9510-eea3f6ecb33c@github.com>

On Thu, 8 Oct 2020 14:01:26 GMT, Bob Vandette <bobv at openjdk.org> wrote:

>> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Return false in case of no pattern match
>
> Marked as reviewed by bobv (Committer).

Thanks for the review!

-------------

PR: https://git.openjdk.java.net/jdk/pull/485

From kim.barrett at oracle.com  Thu Oct  8 14:59:11 2020
From: kim.barrett at oracle.com (Kim Barrett)
Date: Thu, 8 Oct 2020 10:59:11 -0400
Subject: RFR: 8188055: (ref) Add Reference::refersTo predicate [v2]
In-Reply-To: <Tb1VL1yPx2XEmwhHdZwz_NE8DiUcsAzQba9wmmDjEus=.f03ebf90-92c4-44c9-a1c4-21e16d17d262@github.com>
References: <D4HSg8FT20Eaxk5KJkkw0GgETSxRkBn1ipS3Dt0kPto=.e4bab078-2e04-4413-90cb-9bfafb2a6831@github.com>
 <Y1IHoNr8vO3OkCbEKw6ywXd4adik1yKKNIS4ABzF0d0=.d21f4183-ef4e-45ed-826d-6613215b6220@github.com>
 <Tb1VL1yPx2XEmwhHdZwz_NE8DiUcsAzQba9wmmDjEus=.f03ebf90-92c4-44c9-a1c4-21e16d17d262@github.com>
Message-ID: <B64C8405-4E47-4BE1-8748-DED7A2441A45@oracle.com>

> On Oct 8, 2020, at 10:02 AM, Roger Riggs <rriggs at openjdk.java.net> wrote:
> At what point would the @IntrinsicCandidate annotation be added to the
> refersTo0 methods?
> it would be useful documentation even if it is not needed for the mechanism.

I now have a patch to implement the C2 intrinsic, mostly provided by eosterlund.
It is very nearly completely separate from the current PR; the only point of contact
is adding the @IntrinsicCandidate annotations.  Also, the intrinsic needs review
by pretty much a completely different set of people (compiler folks) than the
current PR.

Because of that, I decided to hold off and keep it separate, but I intend to make
a PR for it shortly after the current one is integrated.  Also, the intrinsic needs
review by pretty much a completely different set of people (compiler folks) than
the current PR.

I don?t know what happens if one annotates as an intrinsic candidate with no
intrinsic implementation.  I expect nothing much.  But I originally didn?t want to
do that because it wasn?t initially clear when someone would have time for it,
and I didn?t want to be misleading about the performance in the meantime.


From erikj at openjdk.java.net  Thu Oct  8 15:31:04 2020
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Thu, 8 Oct 2020 15:31:04 GMT
Subject: RFR: 8254162: Implementation of Foreign-Memory Access API (Third
 Incubator) [v3]
In-Reply-To: <lJUy8C4jwS7mc82Pt2_q4CBz3RB2LuV_gf1JG1QyqsI=.d032ebb5-0a1d-48b7-976a-0af3697671c6@github.com>
References: <IngRk57F78UN3yySfo6IABbdwnMogGNdYrykh_3em-c=.b81f7478-015c-45ed-9788-58d7519a2770@github.com>
 <lJUy8C4jwS7mc82Pt2_q4CBz3RB2LuV_gf1JG1QyqsI=.d032ebb5-0a1d-48b7-976a-0af3697671c6@github.com>
Message-ID: <Oh4I1Ago0eJtbY86V_Neory6ddqvD2SPkPSpfVV9dc4=.c46b6989-de10-4961-833c-0ee28fef6df9@github.com>

On Thu, 8 Oct 2020 13:59:20 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This patch contains the changes associated with the third incubation round of the foreign memory access API incubation
>> (see JEP 393 [1]). This iteration focus on improving the usability of the API in 3 main ways:
>> * first, by providing a way to obtain truly *shared* segments, which can be accessed and closed concurrently from
>>   multiple threads
>> * second, by providing a way to register a memory segment against a `Cleaner`, so as to have some (optional) guarantee
>>   that the memory will be deallocated, eventually
>> * third, by not requiring users to dive deep into var handles when they first pick up the API; a new `MemoryAccess` class
>>   has been added, which defines several useful dereference routines; these are really just thin wrappers around memory
>>   access var handles, but they make the barrier of entry for using this API somewhat lower.
>> 
>> A big conceptual shift that comes with this API refresh is that the role of `MemorySegment` and `MemoryAddress` is not
>> the same as it used to be; it used to be the case that a memory address could (sometimes, not always) have a back link
>> to the memory segment which originated it; additionally, memory access var handles used `MemoryAddress` as a basic unit
>> of dereference.  This has all changed as per this API refresh;  now a `MemoryAddress` is just a dumb carrier which
>> wraps a pair of object/long addressing coordinates; `MemorySegment` has become the star of the show, as far as
>> dereferencing memory is concerned. You cannot dereference memory if you don't have a segment. This improves usability
>> in a number of ways - first, it is a lot easier to wrap native addresses (`long`, essentially) into a `MemoryAddress`;
>> secondly, it is crystal clear what a client has to do in order to dereference memory: if a client has a segment, it can
>> use that; otherwise, if the client only has an address, it will have to create a segment *unsafely* (this can be done
>> by calling `MemoryAddress::asSegmentRestricted`).  A list of the API, implementation and test changes is provided
>> below. If  you have any questions, or need more detailed explanations, I (and the  rest of the Panama team) will be
>> happy to point at existing discussions,  and/or to provide the feedback required.   A big thank to Erik Osterlund,
>> Vladimir Ivanov and David Holmes, without whom the work on shared memory segment would not have been possible; also I'd
>> like to thank Paul Sandoz, whose insights on API design have been very helpful in this journey.  Thanks  Maurizio
>> Javadoc:   http://cr.openjdk.java.net/~mcimadamore/8254162_v1/javadoc/jdk/incubator/foreign/package-summary.html
>> Specdiff:
>> 
>> http://cr.openjdk.java.net/~mcimadamore/8254162_v1/specdiff/jdk/incubator/foreign/package-summary.html
>> 
>> CSR:
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8254163
>> 
>> 
>> 
>> ### API Changes
>> 
>> * `MemorySegment`
>>   * drop factory for restricted segment (this has been moved to `MemoryAddress`, see below)
>>   * added a no-arg factory for a native restricted segment representing entire native heap
>>   * rename `withOwnerThread` to `handoff`
>>   * add new `share` method, to create shared segments
>>   * add new `registerCleaner` method, to register a segment against a cleaner
>>   * add more helpers to create arrays from a segment e.g. `toIntArray`
>>   * add some `asSlice` overloads (to make up for the fact that now segments are more frequently used as cursors)
>>   * rename `baseAddress` to `address` (so that `MemorySegment` can implement `Addressable`)
>> * `MemoryAddress`
>>   * drop `segment` accessor
>>   * drop `rebase` method and replace it with `segmentOffset` which returns the offset (a `long`) of this address relative
>>     to a given segment
>> * `MemoryAccess`
>>   * New class supporting several static dereference helpers; the helpers are organized by carrier and access mode, where a
>>     carrier is one of the usual suspect (a Java primitive, minus `boolean`); the access mode can be simple (e.g. access
>>     base address of given segment), or indexed, in which case the accessor takes a segment and either a low-level byte
>>     offset,or a high level logical index. The classification is reflected in the naming scheme (e.g. `getByte` vs.
>>     `getByteAtOffset` vs `getByteAtIndex`).
>> * `MemoryHandles`
>>   * drop `withOffset` combinator
>>   * drop `withStride` combinator
>>   * the basic memory access handle factory now returns a var handle which takes a `MemorySegment` and a `long` - from which
>>     it is easy to derive all the other handles using plain var handle combinators.
>> * `Addressable`
>>   * This is a new interface which is attached to entities which can be projected to a `MemoryAddress`. For now, both
>>     `MemoryAddress` and `MemorySegment` implement it; we have plans, with JEP 389 [2] to add more implementations. Clients
>>     can largely ignore this interface, which comes in really handy when defining native bindings with tools like `jextract`.
>> * `MemoryLayouts`
>>   * A new layout, for machine addresses, has been added to the mix.
>> 
>> 
>> 
>> ### Implementation changes
>> 
>> There are two main things to discuss here: support for shared segments, and the general simplification of the memory
>> access var handle support.
>> #### Shared segments
>> 
>> The support for shared segments cuts in pretty deep in the VM. Support for shared segments is notoriously hard to
>> achieve, at least in a way that guarantees optimal access performances. This is caused by the fact that, if a segment
>> is shared, it would be possible for a thread to close it while another is accessing it.  After considering several
>> options (see [3]), we zeroed onto an approach which is inspired by an happy idea that Andrew Haley had (and that he
>> reminded me of at this year OpenJDK committer workshop - thanks!). The idea is that if we could *freeze* the world
>> (e.g. with a GC pause), while a segment is closed, we could then prevent segments from being accessed concurrently to a
>> close operation. For this to work, it  is crucial that no GC safepoints can occur between a segment liveness check and
>> the access itself (otherwise it would be possible for the accessing thread to stop just right before an unsafe call).
>> It also relies on the fact that hotspot/C2 should not be able to propagate loads across safepoints.  Sadly, none of
>> these conditions seems to be valid in the current implementation, so we needed to resort to a bit of creativity. First,
>> we noted that, if we could mark so called *scoped* method with an annotation, it would be very simply to check as to
>> whether a thread was in the middle of a scoped method when we stopped the world for a close operation (btw, instead of
>> stopping the world, we do a much more efficient, thread-local polling, thanks to JEP 312 [4]).  The question is, then,
>> once we detect that a thread is accessing the very segment we're about to close, what should happen? We first
>> experimented with a solution which would install an *asynchronous* exception on the accessing thread, thus making it
>> fail. This solution has some desirable properties, in that a `close` operation always succeeds. Unfortunately the
>> machinery for async exceptions is a bit fragile (e.g. not all the code in hotspot checks for async exceptions); to
>> minimize risks, we decided to revert to a simpler strategy, where `close` might fail when it finds that another thread
>> is accessing the segment being closed.  As written in the javadoc, this doesn't mean that clients should just catch and
>> try again; an exception on `close` is a bug in the user code, likely arising from lack of synchronization, and should
>> be treated as such.  In terms of gritty implementation, we needed to centralize memory access routines in a single
>> place, so that we could have a set of routines closely mimicking the primitives exposed by `Unsafe` but which, in
>> addition, also provided a liveness check. This way we could mark all these routines with the special `@Scoped`
>> annotation, which tells the VM that something important is going on.  To achieve this, we created a new (autogenerated)
>> class, called `ScopedMemoryAccess`. This class contains all the main memory access primitives (including bulk access,
>> like `copyMemory`, or `setMemory`), and accepts, in addition to the access coordinates, also a scope object, which is
>> tested before access. A reachability fence is also thrown in the mix to make sure that the scope is kept alive during
>> access (which is important when registering segments against cleaners).  Of course, to make memory access safe, memory
>> access var handles, byte buffer var handles, and byte buffer API should use the new `ScopedMemoryAccess` class instead
>> of unsafe, so that a liveness check can be triggered (in case a scope is present).  `ScopedMemoryAccess` has a
>> `closeScope` method, which initiates the thread-local handshakes, and returns `true` if the handshake completed
>> successfully.  The implementation of `MemoryScope` (now significantly simplified from what we had before), has two
>> implementations, one for confined segments and one for shared segments; the main difference between the two is what
>> happens when the scope is closed; a confined segment sets a boolean flag to false, and returns, whereas a shared
>> segment goes into a `CLOSING` state, then starts the handshake, and then updates the state again, to either `CLOSED` or
>> `ALIVE` depending on whether the handshake was successful or not. Note that when a shared segment is in the `CLOSING`
>> state, `MemorySegment::isAlive` will still return `true`, while the liveness check upon memory access will fail.  ####
>> Memory access var handles overhaul  The key realization here was that if all memory access var handles took a
>> coordinate pair of `MemorySegment` and `long`, all other access types could be derived from this basic var handle
>> form.  This allowed us to remove the on-the-fly var handle generation, and to simply derive structural access var
>> handles (such as those obtained by calling `MemoryLayout::varHandle`) using *plain* var handle combinators, so that
>> e.g. additional offset is injected into a base memory access var handle.  This also helped in simplifying the
>> implementation by removing the special `withStride` and `withOffset` combinators, which previously needed low-level
>> access on the innards of the memory access var handle. All that code is now gone.  #### Test changes  Not much to see
>> here - most of the tests needed to be updated because of the API changes. Some were beefed up (like the array test,
>> since now segments can be projected into many different kinds of arrays). A test has been added to test the `Cleaner`
>> functionality, and another stress test has been added for shared segments (`TestHandshake`). Some of the
>> microbenchmarks also needed some tweaks - and some of them were also updated to also test performance in the shared
>> segment case.  [1] - https://openjdk.java.net/jeps/393 [2] - https://openjdk.java.net/jeps/389 [3] -
>> https://mail.openjdk.java.net/pipermail/panama-dev/2020-May/009004.html [4] - https://openjdk.java.net/jeps/312
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix indent in GensrcScopedMemoryAccess.gmk

Build changes look ok.

-------------

Marked as reviewed by erikj (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/548

From rrich at openjdk.java.net  Thu Oct  8 16:55:31 2020
From: rrich at openjdk.java.net (Richard Reingruber)
Date: Thu, 8 Oct 2020 16:55:31 GMT
Subject: RFR: 8227745: Enable Escape Analysis for Better Performance in
 the Presence of JVMTI Agents [v9]
In-Reply-To: <Ll2RereRbuQLgFtIjv9pS92kPvCVuo-BI0cP1zGjVbo=.dad3a33c-0fc3-44fd-810a-f01448cf564c@github.com>
References: <Ll2RereRbuQLgFtIjv9pS92kPvCVuo-BI0cP1zGjVbo=.dad3a33c-0fc3-44fd-810a-f01448cf564c@github.com>
Message-ID: <5O9n8cKBJyjhp2cNOVD2PcpKQiXqEs5BJjkW1lH-5EM=.044a510e-6517-4564-a3db-00c7951f0b22@github.com>

> Hi,
> 
> this is the continuation of the review of the implementation for:
> 
> https://bugs.openjdk.java.net/browse/JDK-8227745
> https://bugs.openjdk.java.net/browse/JDK-8233915
> 
> It allows for JIT optimizations based on escape analysis even if JVMTI agents acquire capabilities to access references
> to objects that are subject to such optimizations, e.g. scalar replacement. The implementation reverts such
> optimizations just before access very much as when switching from JIT compiled execution to the interpreter, aka
> "deoptimization".  Webrev.8 was the last one before before the transition to Git/Github:
> 
> http://cr.openjdk.java.net/~rrich/webrevs/8227745/webrev.8/
> 
> Thanks, Richard.

Richard Reingruber has updated the pull request with a new target base due to a merge or a rebase. The pull request now
contains 19 commits:

 - Merge branch 'master' into JDK-8227745
 - Merge branch 'master' into JDK-8227745
 - Factorized fragment out of EscapeBarrier::deoptimize_objects_internal into new method in compiledVFrame.
 - More smaller changes proposed by Serguei.
 - jvmtiDeferredUpdates.hpp: remove forward declarations.
 - jvmtiDeferredLocalVariable: move member variables to the beginning of the class definition.
 - jvmtiDeferredUpdates.hpp: add/remove empty lines and improve indentation.
 - Merge branch 'master' into JDK-8227745
 - Merge branch 'master' into JDK-8227745
 - Make parameter current_thread of JvmtiEnvBase::check_top_frame() a JavaThread* again.
   
   With Asynchronous handshakes the type was changed from JavaThread* to Thread*
   but this is not necessary as check_top_frame() is not executed during a handshake
   / safepoint (robehn confirmed).
 - ... and 9 more: https://git.openjdk.java.net/jdk/compare/d036dca0...d463b4f3

-------------

Changes: https://git.openjdk.java.net/jdk/pull/119/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=119&range=08
  Stats: 5814 lines in 52 files changed: 5595 ins; 116 del; 103 mod
  Patch: https://git.openjdk.java.net/jdk/pull/119.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/119/head:pull/119

PR: https://git.openjdk.java.net/jdk/pull/119

From github.com+51754783+coreyashford at openjdk.java.net  Thu Oct  8 17:19:28 2020
From: github.com+51754783+coreyashford at openjdk.java.net (CoreyAshford)
Date: Thu, 8 Oct 2020 17:19:28 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v3]
In-Reply-To: <BEknTe_U8l2MO30Mb5nt6Z6w87fHu4aLRZg8Xs8vbIY=.09f48a18-833a-478d-8946-fd238910e340@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <BPUaQTDmxtonENpeoEp5xhJBjS7LB4vESLH7A8sH1-k=.755d7497-1fa1-4ca2-9d95-4477460f7626@github.com>
 <BEknTe_U8l2MO30Mb5nt6Z6w87fHu4aLRZg8Xs8vbIY=.09f48a18-833a-478d-8946-fd238910e340@github.com>
Message-ID: <L78lIh07xw0hwfDOsbZEs7XUuzAnuygd_Zfe9izs_H4=.2eea888a-91de-49dc-8c51-e2025559e6dd@github.com>

On Thu, 8 Oct 2020 10:41:32 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> CoreyAshford has updated the pull request incrementally with seven additional commits since the last revision:
>> 
>>  - stubGenerator_ppc.cpp: Fix multiple issues as per Martin Doerr's v2 review
>>    
>>     * Remove extraneous comma from SAP copyright notice
>>     * Move align(32) to the head of the loop rather than the beginning of the unwound code
>>     * Simplified looping condition to use a loop counter instead of a final
>>       address.  This eliminated the need for the "end" variable, and
>>       essentially replaced it with CTR, which is computed using a simple
>>       bitwise shift of the size.
>>     * Re-ran benchmarks against loop_unrolls values: 1, 2, 4, 8, 16 to find
>>       optimal value, now 4.
>>     * Corrected a typo in the word "elements"
>>  - vm_version_ppc.cpp: per Martin Doerr's review of v2: fix copy/paste error
>>  - vmIntrinsics.cpp: Per Martin Doerr's v2 review: rearrange order of case statement to be consistent with others.
>>  - runtime.cpp: per Martin Doerr's review of v2, correct comment as per current semantics of decodeBlock()
>>    
>>      * The reference to "ofs" seems to be a copy/paste error.
>>      * -1 is no longer returned from decodeBlock() in the event of a
>>        non-base64 character being encountered; only a count of bytes written
>>        to dst.
>>  - TestBase64.java: Change comment as per Martin Doerr's v2 review
>>  - Base64.java: Make changes as per Roger Riggs and Martin Doerr's v2 Review
>>    
>>      * Make comment about the sl parameter more precise
>>      * Fix comparison to avoid possible integer overflow of sp
>>  - library_call.cpp: Fix rebase merge error
>
> test/hotspot/jtreg/compiler/intrinsics/base64/TestBase64.java line 90:
> 
>> 88:
>> 89:         // This should be enough to get both encodeBlock() and
>> 90:         // decodeBlock() compiled on the highest tier.
> 
> It's actually encode() and decode() which should get compiled. You should see them when testing
> with -XX:+PrintCompilation. And you should see usage of the intrinsics by -XX:+PrintInlining.

Ah, useful tips!  Thanks!

I will make this comment change.

-------------

PR: https://git.openjdk.java.net/jdk/pull/293

From iignatyev at openjdk.java.net  Thu Oct  8 18:38:25 2020
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Thu, 8 Oct 2020 18:38:25 GMT
Subject: RFR: 8254262: jdk.test.lib.Utils::createTemp* don't pass attrs
Message-ID: <9NETUjutw3W3c0XTyqoSsC_TbHNEs1NaYrayyiuXNZk=.d583222d-cae2-4aeb-b168-f48d1eb7af61@github.com>

Hi all,

`jdk.test.lib.Utils::createTempFile` and `createTempDirectory` methods accept `attrs`, but don't pass it to
`java.nio.file.Files::createTempFile` and `createTempDirectory` methods respectively. could you please review this
trivial patch which fixes that?

Thanks,
-- Igor

-------------

Commit messages:
 - 8254262: jdk.test.lib.Utils::createTemp* don't pass attrs

Changes: https://git.openjdk.java.net/jdk/pull/567/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=567&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8254262
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/567.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/567/head:pull/567

PR: https://git.openjdk.java.net/jdk/pull/567

From iignatyev at openjdk.java.net  Thu Oct  8 18:41:23 2020
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Thu, 8 Oct 2020 18:41:23 GMT
Subject: RFR: JDK-8247589: Implementation of Alpine Linux/x64 Port [v2]
In-Reply-To: <E4-ceOi1onrpKNdsorrnCtUhBi85Z5VQMjf235T8HiA=.80b5090f-7ab2-4d6c-896c-4a1c3c2a4674@github.com>
References: <bjBywiEZ6tEHsG5xi2185_J-tduz4ezP8r6wVKbX1lY=.f6574f6f-be11-4d7c-8ebc-50b24ad8015d@github.com>
 <ZaC0wyl8pFXr1wCN8nuPgSA1pZOAEucaP6mkrJhZYf8=.8f81d618-31f0-4262-990a-980327739d4b@github.com>
 <PgeNNEaSfdBhf5I38_LN-SH3aFQUiFbloD6NG_bzMQA=.1178d2ca-82ca-4ca5-9e27-0bd86dcacb1a@github.com>
 <6jqlCPXe69fPRvYFrytJsECkaa9tJ1hYWISNgyPP4Eg=.40944ef5-93b0-4db4-948b-80bb7898e9e8@github.com>
 <o4Ql6TAAuuFFuwG8KTHF_bqg_ZliQfcRpuqgNsAGNPA=.2f1aa9d4-0e25-4c5d-b556-701eeba2cc81@github.com>
 <aw463dmr3OoI-xwE92WKIvGK4tY52jbMb3Bb8yKsu6c=.7fa08759-5663-4450-8576-29d43c1635c1@github.com>
 <iyvweqL8dNEXuXMlFXdfx03yNRGyy8WLDMkG2NCN2Bk=.9dcfe9a7-3d6e-4227-b31b-a28c8e1614e3@github.com>
 <E4-ceOi1onrpKNdsorrnCtUhBi85Z5VQMjf235T8HiA=.80b5090f-7ab2-4d6c-896c-4a1c3c2a4674@github.com>
Message-ID: <pZmn1tLTx1wkO4cYaD5CRkdtowPlaGTOQw2rRFU8lP4=.5ddd2f18-cd7c-4223-b3a8-9a951ced60c2@github.com>

On Thu, 8 Oct 2020 11:00:41 GMT, Aleksei Voitylov <avoitylov at openjdk.org> wrote:

> @iignatev I resolved the conflict in whitebox.cpp and fixed a minor style nit on the way. Could you take a look?

LGTM

-------------

PR: https://git.openjdk.java.net/jdk/pull/49

From shade at openjdk.java.net  Thu Oct  8 18:58:27 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 8 Oct 2020 18:58:27 GMT
Subject: RFR: 8254262: jdk.test.lib.Utils::createTemp* don't pass attrs
In-Reply-To: <9NETUjutw3W3c0XTyqoSsC_TbHNEs1NaYrayyiuXNZk=.d583222d-cae2-4aeb-b168-f48d1eb7af61@github.com>
References: <9NETUjutw3W3c0XTyqoSsC_TbHNEs1NaYrayyiuXNZk=.d583222d-cae2-4aeb-b168-f48d1eb7af61@github.com>
Message-ID: <3kUWPKiFahlK6wXm5PaM0Q5N4hs4btNm0_X1Bm3W4J0=.78fa431f-82a5-45f9-a9da-ce06d6e8a7f6@github.com>

On Thu, 8 Oct 2020 18:32:15 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> `jdk.test.lib.Utils::createTempFile` and `createTempDirectory` methods accept `attrs`, but don't pass it to
> `java.nio.file.Files::createTempFile` and `createTempDirectory` methods respectively. could you please review this
> trivial patch which fixes that?  Thanks,
> -- Igor

Looks fine. There seems to be no uses of `Utils.createTempFile` or `Utils.createTempDirectory` with extended
attributes, so there is no affected tests, and no further testing needed, right?

-------------

Marked as reviewed by shade (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/567

From iignatyev at openjdk.java.net  Thu Oct  8 19:12:22 2020
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Thu, 8 Oct 2020 19:12:22 GMT
Subject: RFR: 8254262: jdk.test.lib.Utils::createTemp* don't pass attrs
In-Reply-To: <3kUWPKiFahlK6wXm5PaM0Q5N4hs4btNm0_X1Bm3W4J0=.78fa431f-82a5-45f9-a9da-ce06d6e8a7f6@github.com>
References: <9NETUjutw3W3c0XTyqoSsC_TbHNEs1NaYrayyiuXNZk=.d583222d-cae2-4aeb-b168-f48d1eb7af61@github.com>
 <3kUWPKiFahlK6wXm5PaM0Q5N4hs4btNm0_X1Bm3W4J0=.78fa431f-82a5-45f9-a9da-ce06d6e8a7f6@github.com>
Message-ID: <aVj4QBRdWiAzY9HukDGVZB06i3n-Xzj1d6ytgcbcEes=.bf852e40-a789-471d-b463-983d8e8ae382@github.com>

On Thu, 8 Oct 2020 18:55:38 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Hi all,
>> 
>> `jdk.test.lib.Utils::createTempFile` and `createTempDirectory` methods accept `attrs`, but don't pass it to
>> `java.nio.file.Files::createTempFile` and `createTempDirectory` methods respectively. could you please review this
>> trivial patch which fixes that?  Thanks,
>> -- Igor
>
> Looks fine. There seems to be no uses of `Utils.createTempFile` or `Utils.createTempDirectory` with extended
> attributes, so there is no affected tests, and no further testing needed, right?

Thanks for your review, Aleksey.

> There seems to be no uses of `Utils.createTempFile` or `Utils.createTempDirectory` with extended attributes, so there
> is no affected tests, and no further testing needed, right?

correct. I should have stated that in the descriptions, there are no existing tests that specify `attrs`, hence no
affected tests, and no testing needed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/567

From iignatyev at openjdk.java.net  Thu Oct  8 19:12:24 2020
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Thu, 8 Oct 2020 19:12:24 GMT
Subject: Integrated: 8254262: jdk.test.lib.Utils::createTemp* don't pass attrs
In-Reply-To: <9NETUjutw3W3c0XTyqoSsC_TbHNEs1NaYrayyiuXNZk=.d583222d-cae2-4aeb-b168-f48d1eb7af61@github.com>
References: <9NETUjutw3W3c0XTyqoSsC_TbHNEs1NaYrayyiuXNZk=.d583222d-cae2-4aeb-b168-f48d1eb7af61@github.com>
Message-ID: <EZ3n6VbjlDpM5YbS2ePmZXjQ6Qn5oT6sja_pZC5zEN4=.a7101b80-2e7e-4430-b5a3-546dfc0024cd@github.com>

On Thu, 8 Oct 2020 18:32:15 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> `jdk.test.lib.Utils::createTempFile` and `createTempDirectory` methods accept `attrs`, but don't pass it to
> `java.nio.file.Files::createTempFile` and `createTempDirectory` methods respectively. could you please review this
> trivial patch which fixes that?  Thanks,
> -- Igor

This pull request has now been integrated.

Changeset: 5351ba6c
Author:    Igor Ignatyev <iignatyev at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/5351ba6c
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8254262: jdk.test.lib.Utils::createTemp* don't pass attrs

Reviewed-by: shade

-------------

PR: https://git.openjdk.java.net/jdk/pull/567

From shade at openjdk.java.net  Thu Oct  8 19:13:29 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 8 Oct 2020 19:13:29 GMT
Subject: RFR: 8229186: Improve error messages for TestStringIntrinsics
 failures [v6]
In-Reply-To: <9thYXJXttNl2VIj3C5eGuFwEIwgZZ-TeGbeX67LqQl0=.987baa49-c4c4-466a-b115-ca261bec62b7@github.com>
References: <Br6z5yt0kTbZwIQyTI9lz7czaYpjw5vCd5ZCbbrSIcM=.6a8096f1-91ed-4673-bab3-3bfae758ab95@github.com>
 <b3GkK3NPrSYq9sWmkUDW9mZN6kMRoGVLFNBxCMIEsPs=.6119e887-b2e1-4c94-aa52-8200faec288a@github.com>
 <9thYXJXttNl2VIj3C5eGuFwEIwgZZ-TeGbeX67LqQl0=.987baa49-c4c4-466a-b115-ca261bec62b7@github.com>
Message-ID: <mGLPHMEidj3C17Zo57UVvQgcbCbbOu6BHq-hS10yotg=.d8870cb1-6902-486d-9bdd-290105a04439@github.com>

On Thu, 1 Oct 2020 06:18:40 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

>> Evgeny Nikitin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use SB to build TestStringIntrinsics message, avoid type guessing in ArrayDiff
>
> LGTM

@iignatev, @lmesnik: would you like to sponsor this?

-------------

PR: https://git.openjdk.java.net/jdk/pull/112

From iklam at openjdk.java.net  Thu Oct  8 20:07:24 2020
From: iklam at openjdk.java.net (Ioi Lam)
Date: Thu, 8 Oct 2020 20:07:24 GMT
Subject: RFR: 8247536: Support for pre-generated java.lang.invoke classes
 in CDS static archive [v12]
In-Reply-To: <ZqLP6m_KzPnPYSUT9_q-9FjGTQseGinzIxTrAb7tEzg=.80449d75-314d-42ab-9bfb-6fe61f5eea6d@github.com>
References: <Y_Bas-poGnDtvcJbqbmeIAPQRNxzvarBToQWALn9TTE=.e846cd3c-0e7b-48d3-8ffa-be3c03acffb0@github.com>
 <9emWKl6fr-GA5LN0uHhuEd5D123QcoCiHQR1M9bAbag=.cc4b6129-8b33-47e4-a421-9e6b4817933b@github.com>
 <-y8lEorT3v4i2G_yBbrmd6faeU584CXFnPEiM8GcPec=.d9e8a152-c319-43dc-a6d1-f745b7eccb20@github.com>
 <ZqLP6m_KzPnPYSUT9_q-9FjGTQseGinzIxTrAb7tEzg=.80449d75-314d-42ab-9bfb-6fe61f5eea6d@github.com>
Message-ID: <-6SMAKzxQbKz43iXA6iLgLkDWEYfkwu-DWQbo7FAX8Q=.f3184cf8-756c-4da7-bf8e-2b2dca998922@github.com>

On Wed, 7 Oct 2020 21:49:24 GMT, Yumin Qi <minqi at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/misc/CDS.java line 144:
>> 
>>> 142:             String line = s.trim();
>>> 143:             if (!line.startsWith("[LF_RESOLVE]") && !line.startsWith("[SPECIES_RESOLVE]")) {
>>> 144:                 System.out.println("Wrong prefix: " + line);
>> 
>> Should this throw an exception instead?
>
> This part is for check the format only, throw exceptions will lead more objects generated which should not be archived
> in shared heap. Since this is only called from VM, so decide not to throw exception here.

The exception object will not be automatically added to the shared heap, so it's OK to throw exceptions here.

-------------

PR: https://git.openjdk.java.net/jdk/pull/193

From github.com+51754783+coreyashford at openjdk.java.net  Thu Oct  8 20:31:47 2020
From: github.com+51754783+coreyashford at openjdk.java.net (CoreyAshford)
Date: Thu, 8 Oct 2020 20:31:47 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v4]
In-Reply-To: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
Message-ID: <45FtTQB1m6HyZSASY42STMkQffIWlVPibWn9_r00xYs=.daad2653-2571-491f-8dd7-5954fe4ece00@github.com>

> This patch set encompasses the following commits:
> 
> - Adds a new HotSpot intrinsic candidate to the java.lang.Base64 class - decodeBlock(), and provides a flexible API for
>   the intrinsic.  The API is similar to the existing encodeBlock intrinsic.
> - Adds the code in HotSpot to check and martial the new intrinsic's arguments to the arch-specific intrinsic
>   implementation
> - Adds a Power64LE-specific implementation of the decodeBlock intrinsic.
> - Adds a JMH microbenchmark for both Base64 encoding and encoding.
> - Enhances the JTReg hotspot intrinsic "TestBase64.java" regression test to more fully test both decoding and encoding.

CoreyAshford has updated the pull request incrementally with two additional commits since the last revision:

 - TestBase64.java: fix comment to correctly reflect actual intrinsic names.
   
   The intrinsic names that are visible with -XX:+PrintCompilation are encode
   and decode, rather than encodeBlock and decodeBlock.
 - stubGenerator_ppc.cpp: fix regression caused by change to using loop counter
   
   My original fix didn't account for the case where sl < block_size.  In the
   event sl < block_size, the shifted sl will become zero, so it should
   jump to the code that computes how much data was processed - 0 - and return.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/293/files
  - new: https://git.openjdk.java.net/jdk/pull/293/files/8932c233..164fa2a9

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=293&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=293&range=02-03

  Stats: 13 lines in 2 files changed: 7 ins; 4 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/293.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/293/head:pull/293

PR: https://git.openjdk.java.net/jdk/pull/293

From mdoerr at openjdk.java.net  Thu Oct  8 20:47:23 2020
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Thu, 8 Oct 2020 20:47:23 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v4]
In-Reply-To: <45FtTQB1m6HyZSASY42STMkQffIWlVPibWn9_r00xYs=.daad2653-2571-491f-8dd7-5954fe4ece00@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <45FtTQB1m6HyZSASY42STMkQffIWlVPibWn9_r00xYs=.daad2653-2571-491f-8dd7-5954fe4ece00@github.com>
Message-ID: <b31lt6WjaR_4A-SpZgj24X3q4qjH7jnhPUtKcEjOyOk=.25704362-ae1c-4f54-9c65-b03f78008905@github.com>

On Thu, 8 Oct 2020 20:31:47 GMT, CoreyAshford <github.com+51754783+CoreyAshford at openjdk.org> wrote:

>> This patch set encompasses the following commits:
>> 
>> - Adds a new HotSpot intrinsic candidate to the java.lang.Base64 class - decodeBlock(), and provides a flexible API for
>>   the intrinsic.  The API is similar to the existing encodeBlock intrinsic.
>> - Adds the code in HotSpot to check and martial the new intrinsic's arguments to the arch-specific intrinsic
>>   implementation
>> - Adds a Power64LE-specific implementation of the decodeBlock intrinsic.
>> - Adds a JMH microbenchmark for both Base64 encoding and encoding.
>> - Enhances the JTReg hotspot intrinsic "TestBase64.java" regression test to more fully test both decoding and encoding.
>
> CoreyAshford has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - TestBase64.java: fix comment to correctly reflect actual intrinsic names.
>    
>    The intrinsic names that are visible with -XX:+PrintCompilation are encode
>    and decode, rather than encodeBlock and decodeBlock.
>  - stubGenerator_ppc.cpp: fix regression caused by change to using loop counter
>    
>    My original fix didn't account for the case where sl < block_size.  In the
>    event sl < block_size, the shifted sl will become zero, so it should
>    jump to the code that computes how much data was processed - 0 - and return.

Marked as reviewed by mdoerr (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/293

From iignatyev at openjdk.java.net  Thu Oct  8 20:48:38 2020
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Thu, 8 Oct 2020 20:48:38 GMT
Subject: RFR: 8229186: Improve error messages for TestStringIntrinsics
 failures [v9]
In-Reply-To: <8MKmW-2_q3RYbIsye58L3XfOmaLItKlb8M8WB2-1cmI=.4b5a0dc0-e379-47bf-8479-10f18f0cbf0e@github.com>
References: <Br6z5yt0kTbZwIQyTI9lz7czaYpjw5vCd5ZCbbrSIcM=.6a8096f1-91ed-4673-bab3-3bfae758ab95@github.com>
 <8MKmW-2_q3RYbIsye58L3XfOmaLItKlb8M8WB2-1cmI=.4b5a0dc0-e379-47bf-8479-10f18f0cbf0e@github.com>
Message-ID: <JaOamNkEsvcU2tZ0peQzE3-FcmmsgP2S9k5-W8FQluI=.3f5c1b2b-3357-404a-a870-c8fa8e8ceea7@github.com>

On Sat, 3 Oct 2020 19:15:00 GMT, Evgeny Nikitin <enikitin at openjdk.org> wrote:

>> pre-Skara RFR thread: [link](https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-May/038416.html)
>> 
>> Error reporting was improved by writing a C-style escaped string representations for the variables passed to the
>> methods being tested. For array comparisons, a dedicated diff-formatter was implemented.
>> Sample output for comparing byte arrays (with artificial failure):
>>  ----------System.err:(21/1553)----------
>>  Result: (false) of 'arrayEqualsB' is not equal to expected (true)
>>  Arrays differ starting from [index: 7]:
>>  ... 5, 6,   7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, ...
>>  ... 5, 6, 125, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, ...
>>            ^^^^
>>  java.lang.RuntimeException: Result: (false) of 'arrayEqualsB' is not
>>  equal to expected (true)
>>           at
>>  compiler.intrinsics.string.TestStringIntrinsics.invokeAndCheckArrays(TestStringIntrinsics.java:273)
>>            at ... stack trace continues - E.N.
>>  Sample output for comparing char arrays:
>>  ----------System.err:(21/1579)*----------
>>  Result: (false) of 'arrayEqualsC' is not equal to expected (true)
>>  Arrays differ starting from [index: 7]:
>>  ... \\u0005, \\u0006, \\u0007, \\u0008, \\u0009, \\n, ...
>>  ... \\u0005, \\u0006,      }, \\u0008, \\u0009, \\n, ...
>>                      ^^^^^^^
>>  java.lang.RuntimeException: Result: (false) of 'arrayEqualsC' is not
>>  equal to expected (true)
>>           at
>>  compiler.intrinsics.string.TestStringIntrinsics.invokeAndCheckArrays(TestStringIntrinsics.java:280)
>>            at
>>  ... and so on - E.N.
>> 
>> testing: open/test/hotspot/jtreg/compiler/intrinsics/string/TestStringIntrinsics.java on linux, windows, macosx.
>
> Evgeny Nikitin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add null values support and two-way testing

Changes requested by iignatyev (Reviewer).

test/lib/jdk/test/lib/format/ArrayDiff.java line 117:

> 115:         if (second == null) {
> 116:             throw new IllegalArgumentException("Second array argument for ArrayDiff is null");
> 117:         }

it's more common (and less surprising) to throw NPE in such cases, preferably by using `Objects::requireNonNull`

test/lib/jdk/test/lib/format/Diff.java line 37:

> 35:      * Default limits for formatters
> 36:      */
> 37:     public static class Defaults {

I'd add a no-op private no-arg ctor to show that this class isn't expected to be instantiated.

test/lib/jdk/test/lib/format/ArrayCodec.java line 325:

> 323:         }
> 324:
> 325:         return 0;

shouldn't it be -1?

-------------

PR: https://git.openjdk.java.net/jdk/pull/112

From coleenp at openjdk.java.net  Thu Oct  8 20:53:29 2020
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Thu, 8 Oct 2020 20:53:29 GMT
Subject: RFR: 8254162: Implementation of Foreign-Memory Access API (Third
 Incubator) [v3]
In-Reply-To: <lJUy8C4jwS7mc82Pt2_q4CBz3RB2LuV_gf1JG1QyqsI=.d032ebb5-0a1d-48b7-976a-0af3697671c6@github.com>
References: <IngRk57F78UN3yySfo6IABbdwnMogGNdYrykh_3em-c=.b81f7478-015c-45ed-9788-58d7519a2770@github.com>
 <lJUy8C4jwS7mc82Pt2_q4CBz3RB2LuV_gf1JG1QyqsI=.d032ebb5-0a1d-48b7-976a-0af3697671c6@github.com>
Message-ID: <04N7NDBB9K0OIRpJy4FaS7jPns7J65f5vpIPAKdLdIQ=.d72b8f73-6062-4bbf-a9c3-64d41de9165d@github.com>

On Thu, 8 Oct 2020 13:59:20 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This patch contains the changes associated with the third incubation round of the foreign memory access API incubation
>> (see JEP 393 [1]). This iteration focus on improving the usability of the API in 3 main ways:
>> * first, by providing a way to obtain truly *shared* segments, which can be accessed and closed concurrently from
>>   multiple threads
>> * second, by providing a way to register a memory segment against a `Cleaner`, so as to have some (optional) guarantee
>>   that the memory will be deallocated, eventually
>> * third, by not requiring users to dive deep into var handles when they first pick up the API; a new `MemoryAccess` class
>>   has been added, which defines several useful dereference routines; these are really just thin wrappers around memory
>>   access var handles, but they make the barrier of entry for using this API somewhat lower.
>> 
>> A big conceptual shift that comes with this API refresh is that the role of `MemorySegment` and `MemoryAddress` is not
>> the same as it used to be; it used to be the case that a memory address could (sometimes, not always) have a back link
>> to the memory segment which originated it; additionally, memory access var handles used `MemoryAddress` as a basic unit
>> of dereference.  This has all changed as per this API refresh;  now a `MemoryAddress` is just a dumb carrier which
>> wraps a pair of object/long addressing coordinates; `MemorySegment` has become the star of the show, as far as
>> dereferencing memory is concerned. You cannot dereference memory if you don't have a segment. This improves usability
>> in a number of ways - first, it is a lot easier to wrap native addresses (`long`, essentially) into a `MemoryAddress`;
>> secondly, it is crystal clear what a client has to do in order to dereference memory: if a client has a segment, it can
>> use that; otherwise, if the client only has an address, it will have to create a segment *unsafely* (this can be done
>> by calling `MemoryAddress::asSegmentRestricted`).  A list of the API, implementation and test changes is provided
>> below. If  you have any questions, or need more detailed explanations, I (and the  rest of the Panama team) will be
>> happy to point at existing discussions,  and/or to provide the feedback required.   A big thank to Erik Osterlund,
>> Vladimir Ivanov and David Holmes, without whom the work on shared memory segment would not have been possible; also I'd
>> like to thank Paul Sandoz, whose insights on API design have been very helpful in this journey.  Thanks  Maurizio
>> Javadoc:   http://cr.openjdk.java.net/~mcimadamore/8254162_v1/javadoc/jdk/incubator/foreign/package-summary.html
>> Specdiff:
>> 
>> http://cr.openjdk.java.net/~mcimadamore/8254162_v1/specdiff/jdk/incubator/foreign/package-summary.html
>> 
>> CSR:
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8254163
>> 
>> 
>> 
>> ### API Changes
>> 
>> * `MemorySegment`
>>   * drop factory for restricted segment (this has been moved to `MemoryAddress`, see below)
>>   * added a no-arg factory for a native restricted segment representing entire native heap
>>   * rename `withOwnerThread` to `handoff`
>>   * add new `share` method, to create shared segments
>>   * add new `registerCleaner` method, to register a segment against a cleaner
>>   * add more helpers to create arrays from a segment e.g. `toIntArray`
>>   * add some `asSlice` overloads (to make up for the fact that now segments are more frequently used as cursors)
>>   * rename `baseAddress` to `address` (so that `MemorySegment` can implement `Addressable`)
>> * `MemoryAddress`
>>   * drop `segment` accessor
>>   * drop `rebase` method and replace it with `segmentOffset` which returns the offset (a `long`) of this address relative
>>     to a given segment
>> * `MemoryAccess`
>>   * New class supporting several static dereference helpers; the helpers are organized by carrier and access mode, where a
>>     carrier is one of the usual suspect (a Java primitive, minus `boolean`); the access mode can be simple (e.g. access
>>     base address of given segment), or indexed, in which case the accessor takes a segment and either a low-level byte
>>     offset,or a high level logical index. The classification is reflected in the naming scheme (e.g. `getByte` vs.
>>     `getByteAtOffset` vs `getByteAtIndex`).
>> * `MemoryHandles`
>>   * drop `withOffset` combinator
>>   * drop `withStride` combinator
>>   * the basic memory access handle factory now returns a var handle which takes a `MemorySegment` and a `long` - from which
>>     it is easy to derive all the other handles using plain var handle combinators.
>> * `Addressable`
>>   * This is a new interface which is attached to entities which can be projected to a `MemoryAddress`. For now, both
>>     `MemoryAddress` and `MemorySegment` implement it; we have plans, with JEP 389 [2] to add more implementations. Clients
>>     can largely ignore this interface, which comes in really handy when defining native bindings with tools like `jextract`.
>> * `MemoryLayouts`
>>   * A new layout, for machine addresses, has been added to the mix.
>> 
>> 
>> 
>> ### Implementation changes
>> 
>> There are two main things to discuss here: support for shared segments, and the general simplification of the memory
>> access var handle support.
>> #### Shared segments
>> 
>> The support for shared segments cuts in pretty deep in the VM. Support for shared segments is notoriously hard to
>> achieve, at least in a way that guarantees optimal access performances. This is caused by the fact that, if a segment
>> is shared, it would be possible for a thread to close it while another is accessing it.  After considering several
>> options (see [3]), we zeroed onto an approach which is inspired by an happy idea that Andrew Haley had (and that he
>> reminded me of at this year OpenJDK committer workshop - thanks!). The idea is that if we could *freeze* the world
>> (e.g. with a GC pause), while a segment is closed, we could then prevent segments from being accessed concurrently to a
>> close operation. For this to work, it  is crucial that no GC safepoints can occur between a segment liveness check and
>> the access itself (otherwise it would be possible for the accessing thread to stop just right before an unsafe call).
>> It also relies on the fact that hotspot/C2 should not be able to propagate loads across safepoints.  Sadly, none of
>> these conditions seems to be valid in the current implementation, so we needed to resort to a bit of creativity. First,
>> we noted that, if we could mark so called *scoped* method with an annotation, it would be very simply to check as to
>> whether a thread was in the middle of a scoped method when we stopped the world for a close operation (btw, instead of
>> stopping the world, we do a much more efficient, thread-local polling, thanks to JEP 312 [4]).  The question is, then,
>> once we detect that a thread is accessing the very segment we're about to close, what should happen? We first
>> experimented with a solution which would install an *asynchronous* exception on the accessing thread, thus making it
>> fail. This solution has some desirable properties, in that a `close` operation always succeeds. Unfortunately the
>> machinery for async exceptions is a bit fragile (e.g. not all the code in hotspot checks for async exceptions); to
>> minimize risks, we decided to revert to a simpler strategy, where `close` might fail when it finds that another thread
>> is accessing the segment being closed.  As written in the javadoc, this doesn't mean that clients should just catch and
>> try again; an exception on `close` is a bug in the user code, likely arising from lack of synchronization, and should
>> be treated as such.  In terms of gritty implementation, we needed to centralize memory access routines in a single
>> place, so that we could have a set of routines closely mimicking the primitives exposed by `Unsafe` but which, in
>> addition, also provided a liveness check. This way we could mark all these routines with the special `@Scoped`
>> annotation, which tells the VM that something important is going on.  To achieve this, we created a new (autogenerated)
>> class, called `ScopedMemoryAccess`. This class contains all the main memory access primitives (including bulk access,
>> like `copyMemory`, or `setMemory`), and accepts, in addition to the access coordinates, also a scope object, which is
>> tested before access. A reachability fence is also thrown in the mix to make sure that the scope is kept alive during
>> access (which is important when registering segments against cleaners).  Of course, to make memory access safe, memory
>> access var handles, byte buffer var handles, and byte buffer API should use the new `ScopedMemoryAccess` class instead
>> of unsafe, so that a liveness check can be triggered (in case a scope is present).  `ScopedMemoryAccess` has a
>> `closeScope` method, which initiates the thread-local handshakes, and returns `true` if the handshake completed
>> successfully.  The implementation of `MemoryScope` (now significantly simplified from what we had before), has two
>> implementations, one for confined segments and one for shared segments; the main difference between the two is what
>> happens when the scope is closed; a confined segment sets a boolean flag to false, and returns, whereas a shared
>> segment goes into a `CLOSING` state, then starts the handshake, and then updates the state again, to either `CLOSED` or
>> `ALIVE` depending on whether the handshake was successful or not. Note that when a shared segment is in the `CLOSING`
>> state, `MemorySegment::isAlive` will still return `true`, while the liveness check upon memory access will fail.  ####
>> Memory access var handles overhaul  The key realization here was that if all memory access var handles took a
>> coordinate pair of `MemorySegment` and `long`, all other access types could be derived from this basic var handle
>> form.  This allowed us to remove the on-the-fly var handle generation, and to simply derive structural access var
>> handles (such as those obtained by calling `MemoryLayout::varHandle`) using *plain* var handle combinators, so that
>> e.g. additional offset is injected into a base memory access var handle.  This also helped in simplifying the
>> implementation by removing the special `withStride` and `withOffset` combinators, which previously needed low-level
>> access on the innards of the memory access var handle. All that code is now gone.  #### Test changes  Not much to see
>> here - most of the tests needed to be updated because of the API changes. Some were beefed up (like the array test,
>> since now segments can be projected into many different kinds of arrays). A test has been added to test the `Cleaner`
>> functionality, and another stress test has been added for shared segments (`TestHandshake`). Some of the
>> microbenchmarks also needed some tweaks - and some of them were also updated to also test performance in the shared
>> segment case.  [1] - https://openjdk.java.net/jeps/393 [2] - https://openjdk.java.net/jeps/389 [3] -
>> https://mail.openjdk.java.net/pipermail/panama-dev/2020-May/009004.html [4] - https://openjdk.java.net/jeps/312
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix indent in GensrcScopedMemoryAccess.gmk

just a drive-by comment.

src/hotspot/share/classfile/vmSymbols.hpp line 290:

> 288:   template(jdk_internal_vm_annotation_ForceInline_signature, "Ljdk/internal/vm/annotation/ForceInline;") \
> 289:   template(jdk_internal_vm_annotation_Hidden_signature,      "Ljdk/internal/vm/annotation/Hidden;") \
> 290:   template(jdk_internal_misc_Scoped_signature,    "Ljdk/internal/misc/ScopedMemoryAccess$Scoped;") \

Can you line this up?

-------------

PR: https://git.openjdk.java.net/jdk/pull/548

From smarks at openjdk.java.net  Thu Oct  8 21:00:33 2020
From: smarks at openjdk.java.net (Stuart Marks)
Date: Thu, 8 Oct 2020 21:00:33 GMT
Subject: RFR: 8254090: Collectors.toUnmodifiableList exposes shared secret
Message-ID: <8yn1ijJAow2SIaCdRYHBMG2WwH2zrji1A9EYXZZQJHU=.8e9c5af2-8162-48be-8739-92a166c19030@github.com>

Add check for ArrayList.class before passing it to the shared secret.

-------------

Commit messages:
 - update copyright on test
 - 8254090: Collectors.toUnmodifiableList exposes shared secret

Changes: https://git.openjdk.java.net/jdk/pull/569/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=569&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8254090
  Stats: 60 lines in 2 files changed: 58 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/569.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/569/head:pull/569

PR: https://git.openjdk.java.net/jdk/pull/569

From igraves at openjdk.java.net  Thu Oct  8 21:07:37 2020
From: igraves at openjdk.java.net (Ian Graves)
Date: Thu, 8 Oct 2020 21:07:37 GMT
Subject: RFR: 8253459: Formatter treats index,
 width and precision > Integer.MAX_VALUE incorrectly [v2]
In-Reply-To: <3aYgWcp1IVMM0vQT5UMLSnc2JA1uK9cbtRe283RF37g=.fc2049ef-cdbe-4948-a24b-fdb88cc87a1c@github.com>
References: <3aYgWcp1IVMM0vQT5UMLSnc2JA1uK9cbtRe283RF37g=.fc2049ef-cdbe-4948-a24b-fdb88cc87a1c@github.com>
Message-ID: <6XbJr_Xa0SBSRBnBgT92rAvtQNhESkLQkaMahhRFAiU=.fc84561e-28f2-478b-97bd-76702c999287@github.com>

> The `java.util.Formatter` format specifies support for field widths, argument indexes, or precision lengths of a field
> that relate to the variadic arguments supplied to the formatter. These numbers are specified by integers, sometimes
> negative. For argument index, it's specified in the documentation that the highest allowed argument is limited by the
> largest possible index of an array (ie the largest possible variadic index), but for the other two it's not defined.
> Moreover, what happens when a number field in a string is too large or too small to be represented by a 32-bit integer
> type is not defined.  This fix adds documentation to specify what error behavior occurs during these cases.
> Additionally it adds an additional exception type to throw when an invalid argument index is observed.  A CSR will be
> required for this PR.

Ian Graves has updated the pull request incrementally with one additional commit since the last revision:

  Updating docs

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/516/files
  - new: https://git.openjdk.java.net/jdk/pull/516/files/f2af81f6..33bf7a14

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=516&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=516&range=00-01

  Stats: 16 lines in 3 files changed: 10 ins; 0 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/516.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/516/head:pull/516

PR: https://git.openjdk.java.net/jdk/pull/516

From psandoz at openjdk.java.net  Thu Oct  8 22:29:22 2020
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Thu, 8 Oct 2020 22:29:22 GMT
Subject: RFR: 8254090: Collectors.toUnmodifiableList exposes shared secret
In-Reply-To: <8yn1ijJAow2SIaCdRYHBMG2WwH2zrji1A9EYXZZQJHU=.8e9c5af2-8162-48be-8739-92a166c19030@github.com>
References: <8yn1ijJAow2SIaCdRYHBMG2WwH2zrji1A9EYXZZQJHU=.8e9c5af2-8162-48be-8739-92a166c19030@github.com>
Message-ID: <cah8dpOdHzrBRYy_XmBmx55ihfynSBwtv8KcAfXZedA=.d8ecdbb8-a29f-43ac-bf56-40123a461028@github.com>

On Thu, 8 Oct 2020 20:52:01 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> Add check for ArrayList.class before passing it to the shared secret.

Marked as reviewed by psandoz (Reviewer).

src/java.base/share/classes/java/util/stream/Collectors.java line 303:

> 301:                                    list -> {
> 302:                                        if (list.getClass() == ArrayList.class) { // ensure it's trusted
> 303:                                            return (List<T>)SharedSecrets.getJavaUtilCollectionAccess()

While we are in this method i think it should be possible to remove the all casts and the `@SuppressWarnings` (javac's
type inference got better after this method was added?).

-------------

PR: https://git.openjdk.java.net/jdk/pull/569

From redestad at openjdk.java.net  Thu Oct  8 22:40:27 2020
From: redestad at openjdk.java.net (Claes Redestad)
Date: Thu, 8 Oct 2020 22:40:27 GMT
Subject: RFR: 8254090: Collectors.toUnmodifiableList exposes shared secret
In-Reply-To: <8yn1ijJAow2SIaCdRYHBMG2WwH2zrji1A9EYXZZQJHU=.8e9c5af2-8162-48be-8739-92a166c19030@github.com>
References: <8yn1ijJAow2SIaCdRYHBMG2WwH2zrji1A9EYXZZQJHU=.8e9c5af2-8162-48be-8739-92a166c19030@github.com>
Message-ID: <hNpeVKMNeOg-vXmUIYeemVMV2JxiJqR9kB4dKnlc7gY=.d4100a81-0f72-4388-bde7-c625bdc62505@github.com>

On Thu, 8 Oct 2020 20:52:01 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> Add check for ArrayList.class before passing it to the shared secret.

test/jdk/java/util/stream/test/org/openjdk/tests/java/util/stream/CollectorToUnmodListTest.java line 2:

> 1: /*
> 2:  * Copyright (c) 2012, 2020, Oracle and/or its affiliates. All rights reserved.

Suggestion:

 * Copyright (c) 2020, Oracle and/or its affiliates. All rights reserved.

-------------

PR: https://git.openjdk.java.net/jdk/pull/569

From psandoz at openjdk.java.net  Thu Oct  8 23:20:22 2020
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Thu, 8 Oct 2020 23:20:22 GMT
Subject: RFR: 8254162: Implementation of Foreign-Memory Access API (Third
 Incubator) [v3]
In-Reply-To: <lJUy8C4jwS7mc82Pt2_q4CBz3RB2LuV_gf1JG1QyqsI=.d032ebb5-0a1d-48b7-976a-0af3697671c6@github.com>
References: <IngRk57F78UN3yySfo6IABbdwnMogGNdYrykh_3em-c=.b81f7478-015c-45ed-9788-58d7519a2770@github.com>
 <lJUy8C4jwS7mc82Pt2_q4CBz3RB2LuV_gf1JG1QyqsI=.d032ebb5-0a1d-48b7-976a-0af3697671c6@github.com>
Message-ID: <mzFu6WSGjT8eA0i4FozznkaY1q1ebpixQC7srYAcTro=.0f152f31-e9c2-48ce-a078-a3c3864fd3b8@github.com>

On Thu, 8 Oct 2020 13:59:20 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This patch contains the changes associated with the third incubation round of the foreign memory access API incubation
>> (see JEP 393 [1]). This iteration focus on improving the usability of the API in 3 main ways:
>> * first, by providing a way to obtain truly *shared* segments, which can be accessed and closed concurrently from
>>   multiple threads
>> * second, by providing a way to register a memory segment against a `Cleaner`, so as to have some (optional) guarantee
>>   that the memory will be deallocated, eventually
>> * third, by not requiring users to dive deep into var handles when they first pick up the API; a new `MemoryAccess` class
>>   has been added, which defines several useful dereference routines; these are really just thin wrappers around memory
>>   access var handles, but they make the barrier of entry for using this API somewhat lower.
>> 
>> A big conceptual shift that comes with this API refresh is that the role of `MemorySegment` and `MemoryAddress` is not
>> the same as it used to be; it used to be the case that a memory address could (sometimes, not always) have a back link
>> to the memory segment which originated it; additionally, memory access var handles used `MemoryAddress` as a basic unit
>> of dereference.  This has all changed as per this API refresh;  now a `MemoryAddress` is just a dumb carrier which
>> wraps a pair of object/long addressing coordinates; `MemorySegment` has become the star of the show, as far as
>> dereferencing memory is concerned. You cannot dereference memory if you don't have a segment. This improves usability
>> in a number of ways - first, it is a lot easier to wrap native addresses (`long`, essentially) into a `MemoryAddress`;
>> secondly, it is crystal clear what a client has to do in order to dereference memory: if a client has a segment, it can
>> use that; otherwise, if the client only has an address, it will have to create a segment *unsafely* (this can be done
>> by calling `MemoryAddress::asSegmentRestricted`).  A list of the API, implementation and test changes is provided
>> below. If  you have any questions, or need more detailed explanations, I (and the  rest of the Panama team) will be
>> happy to point at existing discussions,  and/or to provide the feedback required.   A big thank to Erik Osterlund,
>> Vladimir Ivanov and David Holmes, without whom the work on shared memory segment would not have been possible; also I'd
>> like to thank Paul Sandoz, whose insights on API design have been very helpful in this journey.  Thanks  Maurizio
>> Javadoc:   http://cr.openjdk.java.net/~mcimadamore/8254162_v1/javadoc/jdk/incubator/foreign/package-summary.html
>> Specdiff:
>> 
>> http://cr.openjdk.java.net/~mcimadamore/8254162_v1/specdiff/jdk/incubator/foreign/package-summary.html
>> 
>> CSR:
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8254163
>> 
>> 
>> 
>> ### API Changes
>> 
>> * `MemorySegment`
>>   * drop factory for restricted segment (this has been moved to `MemoryAddress`, see below)
>>   * added a no-arg factory for a native restricted segment representing entire native heap
>>   * rename `withOwnerThread` to `handoff`
>>   * add new `share` method, to create shared segments
>>   * add new `registerCleaner` method, to register a segment against a cleaner
>>   * add more helpers to create arrays from a segment e.g. `toIntArray`
>>   * add some `asSlice` overloads (to make up for the fact that now segments are more frequently used as cursors)
>>   * rename `baseAddress` to `address` (so that `MemorySegment` can implement `Addressable`)
>> * `MemoryAddress`
>>   * drop `segment` accessor
>>   * drop `rebase` method and replace it with `segmentOffset` which returns the offset (a `long`) of this address relative
>>     to a given segment
>> * `MemoryAccess`
>>   * New class supporting several static dereference helpers; the helpers are organized by carrier and access mode, where a
>>     carrier is one of the usual suspect (a Java primitive, minus `boolean`); the access mode can be simple (e.g. access
>>     base address of given segment), or indexed, in which case the accessor takes a segment and either a low-level byte
>>     offset,or a high level logical index. The classification is reflected in the naming scheme (e.g. `getByte` vs.
>>     `getByteAtOffset` vs `getByteAtIndex`).
>> * `MemoryHandles`
>>   * drop `withOffset` combinator
>>   * drop `withStride` combinator
>>   * the basic memory access handle factory now returns a var handle which takes a `MemorySegment` and a `long` - from which
>>     it is easy to derive all the other handles using plain var handle combinators.
>> * `Addressable`
>>   * This is a new interface which is attached to entities which can be projected to a `MemoryAddress`. For now, both
>>     `MemoryAddress` and `MemorySegment` implement it; we have plans, with JEP 389 [2] to add more implementations. Clients
>>     can largely ignore this interface, which comes in really handy when defining native bindings with tools like `jextract`.
>> * `MemoryLayouts`
>>   * A new layout, for machine addresses, has been added to the mix.
>> 
>> 
>> 
>> ### Implementation changes
>> 
>> There are two main things to discuss here: support for shared segments, and the general simplification of the memory
>> access var handle support.
>> #### Shared segments
>> 
>> The support for shared segments cuts in pretty deep in the VM. Support for shared segments is notoriously hard to
>> achieve, at least in a way that guarantees optimal access performances. This is caused by the fact that, if a segment
>> is shared, it would be possible for a thread to close it while another is accessing it.  After considering several
>> options (see [3]), we zeroed onto an approach which is inspired by an happy idea that Andrew Haley had (and that he
>> reminded me of at this year OpenJDK committer workshop - thanks!). The idea is that if we could *freeze* the world
>> (e.g. with a GC pause), while a segment is closed, we could then prevent segments from being accessed concurrently to a
>> close operation. For this to work, it  is crucial that no GC safepoints can occur between a segment liveness check and
>> the access itself (otherwise it would be possible for the accessing thread to stop just right before an unsafe call).
>> It also relies on the fact that hotspot/C2 should not be able to propagate loads across safepoints.  Sadly, none of
>> these conditions seems to be valid in the current implementation, so we needed to resort to a bit of creativity. First,
>> we noted that, if we could mark so called *scoped* method with an annotation, it would be very simply to check as to
>> whether a thread was in the middle of a scoped method when we stopped the world for a close operation (btw, instead of
>> stopping the world, we do a much more efficient, thread-local polling, thanks to JEP 312 [4]).  The question is, then,
>> once we detect that a thread is accessing the very segment we're about to close, what should happen? We first
>> experimented with a solution which would install an *asynchronous* exception on the accessing thread, thus making it
>> fail. This solution has some desirable properties, in that a `close` operation always succeeds. Unfortunately the
>> machinery for async exceptions is a bit fragile (e.g. not all the code in hotspot checks for async exceptions); to
>> minimize risks, we decided to revert to a simpler strategy, where `close` might fail when it finds that another thread
>> is accessing the segment being closed.  As written in the javadoc, this doesn't mean that clients should just catch and
>> try again; an exception on `close` is a bug in the user code, likely arising from lack of synchronization, and should
>> be treated as such.  In terms of gritty implementation, we needed to centralize memory access routines in a single
>> place, so that we could have a set of routines closely mimicking the primitives exposed by `Unsafe` but which, in
>> addition, also provided a liveness check. This way we could mark all these routines with the special `@Scoped`
>> annotation, which tells the VM that something important is going on.  To achieve this, we created a new (autogenerated)
>> class, called `ScopedMemoryAccess`. This class contains all the main memory access primitives (including bulk access,
>> like `copyMemory`, or `setMemory`), and accepts, in addition to the access coordinates, also a scope object, which is
>> tested before access. A reachability fence is also thrown in the mix to make sure that the scope is kept alive during
>> access (which is important when registering segments against cleaners).  Of course, to make memory access safe, memory
>> access var handles, byte buffer var handles, and byte buffer API should use the new `ScopedMemoryAccess` class instead
>> of unsafe, so that a liveness check can be triggered (in case a scope is present).  `ScopedMemoryAccess` has a
>> `closeScope` method, which initiates the thread-local handshakes, and returns `true` if the handshake completed
>> successfully.  The implementation of `MemoryScope` (now significantly simplified from what we had before), has two
>> implementations, one for confined segments and one for shared segments; the main difference between the two is what
>> happens when the scope is closed; a confined segment sets a boolean flag to false, and returns, whereas a shared
>> segment goes into a `CLOSING` state, then starts the handshake, and then updates the state again, to either `CLOSED` or
>> `ALIVE` depending on whether the handshake was successful or not. Note that when a shared segment is in the `CLOSING`
>> state, `MemorySegment::isAlive` will still return `true`, while the liveness check upon memory access will fail.  ####
>> Memory access var handles overhaul  The key realization here was that if all memory access var handles took a
>> coordinate pair of `MemorySegment` and `long`, all other access types could be derived from this basic var handle
>> form.  This allowed us to remove the on-the-fly var handle generation, and to simply derive structural access var
>> handles (such as those obtained by calling `MemoryLayout::varHandle`) using *plain* var handle combinators, so that
>> e.g. additional offset is injected into a base memory access var handle.  This also helped in simplifying the
>> implementation by removing the special `withStride` and `withOffset` combinators, which previously needed low-level
>> access on the innards of the memory access var handle. All that code is now gone.  #### Test changes  Not much to see
>> here - most of the tests needed to be updated because of the API changes. Some were beefed up (like the array test,
>> since now segments can be projected into many different kinds of arrays). A test has been added to test the `Cleaner`
>> functionality, and another stress test has been added for shared segments (`TestHandshake`). Some of the
>> microbenchmarks also needed some tweaks - and some of them were also updated to also test performance in the shared
>> segment case.  [1] - https://openjdk.java.net/jeps/393 [2] - https://openjdk.java.net/jeps/389 [3] -
>> https://mail.openjdk.java.net/pipermail/panama-dev/2020-May/009004.html [4] - https://openjdk.java.net/jeps/312
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix indent in GensrcScopedMemoryAccess.gmk

Reviewed this when updated in [panama-foreign](https://github.com/openjdk/panama-foreign/tree/foreign-memaccess), hence
the lack of substantial comments for this PR.

src/java.base/share/classes/jdk/internal/misc/X-ScopedMemoryAccess.java.template line 50:

> 48:  * a memory region while another thread is releasing it.
> 49:  * <p>
> 50:  * This class provides tools to manages races when multiple threads are accessing and/or releasing the same memory

s/manages/manage

test/jdk/java/foreign/TestCleaner.java line 183:

> 181:             for (int cleaner = 0 ; cleaner < cleaners.length ; cleaner++) {
> 182:                 for (int segmentFunction = 0 ; segmentFunction < segmentFunctions.length ; segmentFunction++) {
> 183:                     data[kind + kinds.length * cleaner + (cleaners.length * kinds.length * segmentFunction)] =

Using an `ArrayList<Object[]>` with `list.toArray(Object[][]::new)` would make this easier to read:
List<Object[]> data = new ArrayList<>();
for (Registered kind : RegisterKind.values()) {
  for (Object cleaner : cleaners) {
    for (SegmentFunction segmentFunction : SegmentFunction.values()) {
      data.add(new Object[] {kind, cleaner, segmentFunction});
    }
  }
}
return data.toArray(Object[][]::new);

-------------

Marked as reviewed by psandoz (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/548

From vromero at openjdk.java.net  Fri Oct  9 00:10:35 2020
From: vromero at openjdk.java.net (Vicente Romero)
Date: Fri, 9 Oct 2020 00:10:35 GMT
Subject: RFR: 8254105: allow static members in inner classes,
 add binary =?UTF-8?B?Y29tcGF0aWJpbOKApg==?=
Message-ID: <2CZWK8ZFp16bbUHZJudG3L8I7415NxcKez8IsLwZCm0=.4b9f94ca-5a29-4c53-85bb-fadeb105a5f9@github.com>

Please review the fix for [JDK-8254105](https://bugs.openjdk.java.net/browse/JDK-8254105). The intention of the fix is
to allow static members to be declared inside inner classes. The spec allowing this change can be seen at [Local and
Nested Static
Declarations](http://cr.openjdk.java.net/~gbierman/8246771/8246771-20200928/specs/local-statics-jls.html). This change
is part of the [Records JEP](https://openjdk.java.net/jeps/395). The idea is to allow not only records to be defined
inside inner classes but also interfaces, enums, static classes and methods.

TIA,
Vicente

-------------

Commit messages:
 - 8254105: allow static members in inner classes, add binary compatibility tests

Changes: https://git.openjdk.java.net/jdk/pull/571/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=571&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8254105
  Stats: 664 lines in 24 files changed: 459 ins; 140 del; 65 mod
  Patch: https://git.openjdk.java.net/jdk/pull/571.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/571/head:pull/571

PR: https://git.openjdk.java.net/jdk/pull/571

From vromero at openjdk.java.net  Fri Oct  9 00:10:36 2020
From: vromero at openjdk.java.net (Vicente Romero)
Date: Fri, 9 Oct 2020 00:10:36 GMT
Subject: RFR: 8254105: allow static members in inner classes,
 add binary =?UTF-8?B?Y29tcGF0aWJpbOKApg==?=
In-Reply-To: <2CZWK8ZFp16bbUHZJudG3L8I7415NxcKez8IsLwZCm0=.4b9f94ca-5a29-4c53-85bb-fadeb105a5f9@github.com>
References: <2CZWK8ZFp16bbUHZJudG3L8I7415NxcKez8IsLwZCm0=.4b9f94ca-5a29-4c53-85bb-fadeb105a5f9@github.com>
Message-ID: <2FO64qXpIpHlQBKzDtQdQTQtdUWhZTsw--VPeSKFw3A=.19353e8e-77e1-40e0-9f72-23977455d8d6@github.com>

On Fri, 9 Oct 2020 00:01:12 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Please review the fix for [JDK-8254105](https://bugs.openjdk.java.net/browse/JDK-8254105). The intention of the fix is
> to allow static members to be declared inside inner classes. The spec allowing this change can be seen at [Local and
> Nested Static
> Declarations](http://cr.openjdk.java.net/~gbierman/8246771/8246771-20200928/specs/local-statics-jls.html). This change
> is part of the [Records JEP](https://openjdk.java.net/jeps/395). The idea is to allow not only records to be defined
> inside inner classes but also interfaces, enums, static classes and methods.  TIA, Vicente

test/langtools/tools/javac/LocalInterface.java line 6:

> 4:  * @summary test for local interfaces
> 5:  * @compile/fail/ref=LocalInterface.out -XDrawDiagnostics LocalInterface.java
> 6:  * @compile --enable-preview -source ${jdk.version} LocalInterface.java

the current patch is supposed to be applied after the code being reviewed at
[PR-290](https://github.com/openjdk/jdk/pull/290) which also modifies this particular line, once
[PR-290](https://github.com/openjdk/jdk/pull/290) has been pushed this line and others removing the --enable-preview
option from tests will change

test/langtools/tools/javac/records/RecordsBinaryCompatibilityTests.java line 2:

> 1: /*
> 2:  * Copyright (c) 2020, Oracle and/or its affiliates. All rights reserved.

this code is not strictly related to the patch but this test is just basically testing the changes Chapter 13 int the
record spec. I'm OK moving this to another PR if needed

-------------

PR: https://git.openjdk.java.net/jdk/pull/571

From smarks at openjdk.java.net  Fri Oct  9 00:57:36 2020
From: smarks at openjdk.java.net (Stuart Marks)
Date: Fri, 9 Oct 2020 00:57:36 GMT
Subject: RFR: 8254090: Collectors.toUnmodifiableList exposes shared secret
 [v2]
In-Reply-To: <8yn1ijJAow2SIaCdRYHBMG2WwH2zrji1A9EYXZZQJHU=.8e9c5af2-8162-48be-8739-92a166c19030@github.com>
References: <8yn1ijJAow2SIaCdRYHBMG2WwH2zrji1A9EYXZZQJHU=.8e9c5af2-8162-48be-8739-92a166c19030@github.com>
Message-ID: <T1ne674WnD_Vk3QoBarEPPsq15V8_i8nfFd-Z54CkJE=.33b7b596-ff55-44a8-bfc6-18abbd0807ba@github.com>

> Add check for ArrayList.class before passing it to the shared secret.

Stuart Marks has updated the pull request with a new target base 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-8254090-Collectors-toUnmodifiableList-SharedSecret
 - remove unnecessary cast and warnings suppression
 - update copyright on test
 - 8254090: Collectors.toUnmodifiableList exposes shared secret

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/569/files
  - new: https://git.openjdk.java.net/jdk/pull/569/files/b27a0ba1..4c02f271

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=569&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=569&range=00-01

  Stats: 2249 lines in 90 files changed: 1365 ins; 633 del; 251 mod
  Patch: https://git.openjdk.java.net/jdk/pull/569.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/569/head:pull/569

PR: https://git.openjdk.java.net/jdk/pull/569

From smarks at openjdk.java.net  Fri Oct  9 00:57:38 2020
From: smarks at openjdk.java.net (Stuart Marks)
Date: Fri, 9 Oct 2020 00:57:38 GMT
Subject: RFR: 8254090: Collectors.toUnmodifiableList exposes shared secret
 [v2]
In-Reply-To: <cah8dpOdHzrBRYy_XmBmx55ihfynSBwtv8KcAfXZedA=.d8ecdbb8-a29f-43ac-bf56-40123a461028@github.com>
References: <8yn1ijJAow2SIaCdRYHBMG2WwH2zrji1A9EYXZZQJHU=.8e9c5af2-8162-48be-8739-92a166c19030@github.com>
 <cah8dpOdHzrBRYy_XmBmx55ihfynSBwtv8KcAfXZedA=.d8ecdbb8-a29f-43ac-bf56-40123a461028@github.com>
Message-ID: <_HAPGGaPsVfEVs7ZXOtO5pmBeMOhIUsVcCLKWEsRUOQ=.754215bb-ac01-4d88-837f-0e129f54c211@github.com>

On Thu, 8 Oct 2020 22:26:15 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Stuart Marks has updated the pull request with a new target base 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-8254090-Collectors-toUnmodifiableList-SharedSecret
>>  - remove unnecessary cast and warnings suppression
>>  - update copyright on test
>>  - 8254090: Collectors.toUnmodifiableList exposes shared secret
>
> src/java.base/share/classes/java/util/stream/Collectors.java line 303:
> 
>> 301:                                    list -> {
>> 302:                                        if (list.getClass() == ArrayList.class) { // ensure it's trusted
>> 303:                                            return (List<T>)SharedSecrets.getJavaUtilCollectionAccess()
> 
> While we are in this method i think it should be possible to remove the all casts and the `@SuppressWarnings` (javac's
> type inference got better after this method was added?).

I've updated this PR to clean this up. Not sure where this came from in the first place. It might have been left over
from an intermediate edit.

-------------

PR: https://git.openjdk.java.net/jdk/pull/569

From david.holmes at oracle.com  Fri Oct  9 01:16:28 2020
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 9 Oct 2020 11:16:28 +1000
Subject: =?UTF-8?Q?Re=3a_RFR=3a_8254105=3a_allow_static_members_in_inner_cla?=
 =?UTF-8?Q?sses=2c_add_binary_compatibil=e2=80=a6?=
In-Reply-To: <2CZWK8ZFp16bbUHZJudG3L8I7415NxcKez8IsLwZCm0=.4b9f94ca-5a29-4c53-85bb-fadeb105a5f9@github.com>
References: <2CZWK8ZFp16bbUHZJudG3L8I7415NxcKez8IsLwZCm0=.4b9f94ca-5a29-4c53-85bb-fadeb105a5f9@github.com>
Message-ID: <a8ae815b-6d47-f1e5-45b1-9dcd51e0f109@oracle.com>

Hi Vincente,

On 9/10/2020 10:10 am, Vicente Romero wrote:
> Please review the fix for [JDK-8254105](https://bugs.openjdk.java.net/browse/JDK-8254105). The intention of the fix is
> to allow static members to be declared inside inner classes. The spec allowing this change can be seen at [Local and
> Nested Static
> Declarations](http://cr.openjdk.java.net/~gbierman/8246771/8246771-20200928/specs/local-statics-jls.html). This change
> is part of the [Records JEP](https://openjdk.java.net/jeps/395). The idea is to allow not only records to be defined
> inside inner classes but also interfaces, enums, static classes and methods.

I'm rather confused. Is this intended to be the issue under which the 
implementation of JEP 395 is done? JEP 395 is only a Candidate at the 
moment so nothing in relation to that should be getting integrated yet. 
It is also unclear how the JDK-8254105 issue relates to the JDK-8246774 
issues, which appears to be intended to be the implementation issue for 
JEP 395.

???

Thanks,
David

> TIA,
> Vicente
> 
> -------------
> 
> Commit messages:
>   - 8254105: allow static members in inner classes, add binary compatibility tests
> 
> Changes: https://git.openjdk.java.net/jdk/pull/571/files
>   Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=571&range=00
>    Issue: https://bugs.openjdk.java.net/browse/JDK-8254105
>    Stats: 664 lines in 24 files changed: 459 ins; 140 del; 65 mod
>    Patch: https://git.openjdk.java.net/jdk/pull/571.diff
>    Fetch: git fetch https://git.openjdk.java.net/jdk pull/571/head:pull/571
> 
> PR: https://git.openjdk.java.net/jdk/pull/571
> 

From smarks at openjdk.java.net  Fri Oct  9 01:37:33 2020
From: smarks at openjdk.java.net (Stuart Marks)
Date: Fri, 9 Oct 2020 01:37:33 GMT
Subject: RFR: 8254090: Collectors.toUnmodifiableList exposes shared secret
 [v3]
In-Reply-To: <8yn1ijJAow2SIaCdRYHBMG2WwH2zrji1A9EYXZZQJHU=.8e9c5af2-8162-48be-8739-92a166c19030@github.com>
References: <8yn1ijJAow2SIaCdRYHBMG2WwH2zrji1A9EYXZZQJHU=.8e9c5af2-8162-48be-8739-92a166c19030@github.com>
Message-ID: <mj36Dl9f44EcaVI4kfGUe1o5Gwsn-5yTOuqIPRujGjI=.207f72df-ea0e-4d12-9e1f-6ada225f9683@github.com>

> Add check for ArrayList.class before passing it to the shared secret.

Stuart Marks has updated the pull request incrementally with two additional commits since the last revision:

 - Update test/jdk/java/util/stream/test/org/openjdk/tests/java/util/stream/CollectorToUnmodListTest.java
   
   Fix copyright years.
   
   Co-authored-by: Claes Redestad <claes.redestad at gmail.com>
 - remove moar redundant casts

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/569/files
  - new: https://git.openjdk.java.net/jdk/pull/569/files/4c02f271..64079da9

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=569&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=569&range=01-02

  Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/569.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/569/head:pull/569

PR: https://git.openjdk.java.net/jdk/pull/569

From dholmes at openjdk.java.net  Fri Oct  9 06:04:26 2020
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 9 Oct 2020 06:04:26 GMT
Subject: RFR: JDK-8247589: Implementation of Alpine Linux/x64 Port [v6]
In-Reply-To: <c1MlKKCyF8tYh2i3go62f96qP4Ox49ocnBZgmtBHjtk=.8dd586d0-becb-405e-adfe-e56e2db0636e@github.com>
References: <bjBywiEZ6tEHsG5xi2185_J-tduz4ezP8r6wVKbX1lY=.f6574f6f-be11-4d7c-8ebc-50b24ad8015d@github.com>
 <c1MlKKCyF8tYh2i3go62f96qP4Ox49ocnBZgmtBHjtk=.8dd586d0-becb-405e-adfe-e56e2db0636e@github.com>
Message-ID: <DR0fMaPzoXlQ5R01RYiE-GqlkHTZhGGximwCU3wxeT0=.95418767-9074-483e-b2f5-b6c48b1c66c7@github.com>

On Thu, 8 Oct 2020 10:52:53 GMT, Aleksei Voitylov <avoitylov at openjdk.org> wrote:

>> continuing the review thread from here https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-September/068546.html
>> 
>>> The download side of using JNI in these tests is that it complicates the
>>> setup a bit for those that run jtreg directly and/or just build the JDK
>>> and not the test libraries. You could reduce this burden a bit by
>>> limiting the load library/isMusl check to Linux only, meaning isMusl
>>> would not be called on other platforms.
>>>
>>> The alternative you suggest above might indeed be better. I assume you
>>> don't mean splitting the tests but rather just adding a second @test
>>> description so that the vm.musl case runs the test with a system
>>> property that allows the test know the expected load library path behavior.
>> 
>> I have updated the PR to split the two tests in multiple @test s.
>> 
>>> The updated comment in java_md.c in this looks good. A minor comment on
>>> Platform.isBusybox is Files.isSymbolicLink returning true implies that
>>> the link exists so no need to check for exists too. Also the
>>> if-then-else style for the new class in ProcessBuilder/Basic.java is
>>> inconsistent with the rest of the test so it stands out.
>> 
>> Thank you, these changes are done in the updated PR.
>> 
>>> Given the repo transition this weekend then I assume you'll create a PR
>>> for the final review at least. Also I see JEP 386 hasn't been targeted
>>> yet but I assume Boris, as owner, will propose-to-target and wait for it
>>> to be targeted before it is integrated.
>> 
>> Yes. How can this be best accomplished with the new git workflow?
>> - we can continue the review process till the end and I will request the integration to happen only after the JEP is
>>   targeted. I guess this step is now done by typing "slash integrate" in a comment.
>> - we can pause the review process now until the JEP is targeted.
>> 
>> In the first case I'm kindly asking the Reviewers who already chimed in on that to re-confirm the review here.
>
> Aleksei Voitylov 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 JDK-8247589
>  - JDK-8247589: Implementation of Alpine Linux/x64 Port
>  - JDK-8247589: Implementation of Alpine Linux/x64 Port

Marked as reviewed by dholmes (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/49

From enikitin at openjdk.java.net  Fri Oct  9 07:15:45 2020
From: enikitin at openjdk.java.net (Evgeny Nikitin)
Date: Fri, 9 Oct 2020 07:15:45 GMT
Subject: RFR: 8229186: Improve error messages for TestStringIntrinsics
 failures [v10]
In-Reply-To: <Br6z5yt0kTbZwIQyTI9lz7czaYpjw5vCd5ZCbbrSIcM=.6a8096f1-91ed-4673-bab3-3bfae758ab95@github.com>
References: <Br6z5yt0kTbZwIQyTI9lz7czaYpjw5vCd5ZCbbrSIcM=.6a8096f1-91ed-4673-bab3-3bfae758ab95@github.com>
Message-ID: <kASEDNbxguDDaJVKQjX8vQmEqlcHQXDvJKlm3HfwERk=.822d1328-edc9-4853-9cbb-77e4330647be@github.com>

> pre-Skara RFR thread: [link](https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-May/038416.html)
> 
> Error reporting was improved by writing a C-style escaped string representations for the variables passed to the
> methods being tested. For array comparisons, a dedicated diff-formatter was implemented.
> Sample output for comparing byte arrays (with artificial failure):
>  ----------System.err:(21/1553)----------
>  Result: (false) of 'arrayEqualsB' is not equal to expected (true)
>  Arrays differ starting from [index: 7]:
>  ... 5, 6,   7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, ...
>  ... 5, 6, 125, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, ...
>            ^^^^
>  java.lang.RuntimeException: Result: (false) of 'arrayEqualsB' is not
>  equal to expected (true)
>           at
>  compiler.intrinsics.string.TestStringIntrinsics.invokeAndCheckArrays(TestStringIntrinsics.java:273)
>            at ... stack trace continues - E.N.
>  Sample output for comparing char arrays:
>  ----------System.err:(21/1579)*----------
>  Result: (false) of 'arrayEqualsC' is not equal to expected (true)
>  Arrays differ starting from [index: 7]:
>  ... \\u0005, \\u0006, \\u0007, \\u0008, \\u0009, \\n, ...
>  ... \\u0005, \\u0006,      }, \\u0008, \\u0009, \\n, ...
>                      ^^^^^^^
>  java.lang.RuntimeException: Result: (false) of 'arrayEqualsC' is not
>  equal to expected (true)
>           at
>  compiler.intrinsics.string.TestStringIntrinsics.invokeAndCheckArrays(TestStringIntrinsics.java:280)
>            at
>  ... and so on - E.N.
> 
> testing: open/test/hotspot/jtreg/compiler/intrinsics/string/TestStringIntrinsics.java on linux, windows, macosx.

Evgeny Nikitin has updated the pull request incrementally with one additional commit since the last revision:

  Throw NPE instead of IAE when a null source array is provided

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/112/files
  - new: https://git.openjdk.java.net/jdk/pull/112/files/39992fcb..ba6e5411

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=112&range=09
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=112&range=08-09

  Stats: 11 lines in 2 files changed: 2 ins; 5 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/112.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/112/head:pull/112

PR: https://git.openjdk.java.net/jdk/pull/112

From enikitin at openjdk.java.net  Fri Oct  9 07:15:46 2020
From: enikitin at openjdk.java.net (Evgeny Nikitin)
Date: Fri, 9 Oct 2020 07:15:46 GMT
Subject: RFR: 8229186: Improve error messages for TestStringIntrinsics
 failures [v9]
In-Reply-To: <JaOamNkEsvcU2tZ0peQzE3-FcmmsgP2S9k5-W8FQluI=.3f5c1b2b-3357-404a-a870-c8fa8e8ceea7@github.com>
References: <Br6z5yt0kTbZwIQyTI9lz7czaYpjw5vCd5ZCbbrSIcM=.6a8096f1-91ed-4673-bab3-3bfae758ab95@github.com>
 <8MKmW-2_q3RYbIsye58L3XfOmaLItKlb8M8WB2-1cmI=.4b5a0dc0-e379-47bf-8479-10f18f0cbf0e@github.com>
 <JaOamNkEsvcU2tZ0peQzE3-FcmmsgP2S9k5-W8FQluI=.3f5c1b2b-3357-404a-a870-c8fa8e8ceea7@github.com>
Message-ID: <NjAGlAWk0HOmKyt7ZX8eywLnwcRRq4mr3L1GkLtMyK0=.bf8bdbcc-a108-4fff-8392-bc2be5ed8584@github.com>

On Thu, 8 Oct 2020 20:42:12 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

>> Evgeny Nikitin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add null values support and two-way testing
>
> test/lib/jdk/test/lib/format/ArrayDiff.java line 117:
> 
>> 115:         if (second == null) {
>> 116:             throw new IllegalArgumentException("Second array argument for ArrayDiff is null");
>> 117:         }
> 
> it's more common (and less surprising) to throw NPE in such cases, preferably by using `Objects::requireNonNull`

Haven't known about the `requireNonNull`, thanks. I was thinking about the NPE myself, just wanted to show up which
array was null. Fixed in the ba6e5411b4de5cf8b9230b7cdb7a518900eadc4b.

-------------

PR: https://git.openjdk.java.net/jdk/pull/112

From enikitin at openjdk.java.net  Fri Oct  9 07:25:45 2020
From: enikitin at openjdk.java.net (Evgeny Nikitin)
Date: Fri, 9 Oct 2020 07:25:45 GMT
Subject: RFR: 8229186: Improve error messages for TestStringIntrinsics
 failures [v11]
In-Reply-To: <Br6z5yt0kTbZwIQyTI9lz7czaYpjw5vCd5ZCbbrSIcM=.6a8096f1-91ed-4673-bab3-3bfae758ab95@github.com>
References: <Br6z5yt0kTbZwIQyTI9lz7czaYpjw5vCd5ZCbbrSIcM=.6a8096f1-91ed-4673-bab3-3bfae758ab95@github.com>
Message-ID: <YKh71aF-8RokxpZ-nahqNdmBFJOPlzex-seAtkZjUgk=.57c5cfe2-d371-4f3a-b88e-92f49b8990a2@github.com>

> pre-Skara RFR thread: [link](https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-May/038416.html)
> 
> Error reporting was improved by writing a C-style escaped string representations for the variables passed to the
> methods being tested. For array comparisons, a dedicated diff-formatter was implemented.
> Sample output for comparing byte arrays (with artificial failure):
>  ----------System.err:(21/1553)----------
>  Result: (false) of 'arrayEqualsB' is not equal to expected (true)
>  Arrays differ starting from [index: 7]:
>  ... 5, 6,   7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, ...
>  ... 5, 6, 125, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, ...
>            ^^^^
>  java.lang.RuntimeException: Result: (false) of 'arrayEqualsB' is not
>  equal to expected (true)
>           at
>  compiler.intrinsics.string.TestStringIntrinsics.invokeAndCheckArrays(TestStringIntrinsics.java:273)
>            at ... stack trace continues - E.N.
>  Sample output for comparing char arrays:
>  ----------System.err:(21/1579)*----------
>  Result: (false) of 'arrayEqualsC' is not equal to expected (true)
>  Arrays differ starting from [index: 7]:
>  ... \\u0005, \\u0006, \\u0007, \\u0008, \\u0009, \\n, ...
>  ... \\u0005, \\u0006,      }, \\u0008, \\u0009, \\n, ...
>                      ^^^^^^^
>  java.lang.RuntimeException: Result: (false) of 'arrayEqualsC' is not
>  equal to expected (true)
>           at
>  compiler.intrinsics.string.TestStringIntrinsics.invokeAndCheckArrays(TestStringIntrinsics.java:280)
>            at
>  ... and so on - E.N.
> 
> testing: open/test/hotspot/jtreg/compiler/intrinsics/string/TestStringIntrinsics.java on linux, windows, macosx.

Evgeny Nikitin has updated the pull request incrementally with one additional commit since the last revision:

  Disable instantiation of format.Diff.Defaults

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/112/files
  - new: https://git.openjdk.java.net/jdk/pull/112/files/ba6e5411..78ed79f3

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=112&range=10
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=112&range=09-10

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/112.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/112/head:pull/112

PR: https://git.openjdk.java.net/jdk/pull/112

From enikitin at openjdk.java.net  Fri Oct  9 07:25:46 2020
From: enikitin at openjdk.java.net (Evgeny Nikitin)
Date: Fri, 9 Oct 2020 07:25:46 GMT
Subject: RFR: 8229186: Improve error messages for TestStringIntrinsics
 failures [v9]
In-Reply-To: <JaOamNkEsvcU2tZ0peQzE3-FcmmsgP2S9k5-W8FQluI=.3f5c1b2b-3357-404a-a870-c8fa8e8ceea7@github.com>
References: <Br6z5yt0kTbZwIQyTI9lz7czaYpjw5vCd5ZCbbrSIcM=.6a8096f1-91ed-4673-bab3-3bfae758ab95@github.com>
 <8MKmW-2_q3RYbIsye58L3XfOmaLItKlb8M8WB2-1cmI=.4b5a0dc0-e379-47bf-8479-10f18f0cbf0e@github.com>
 <JaOamNkEsvcU2tZ0peQzE3-FcmmsgP2S9k5-W8FQluI=.3f5c1b2b-3357-404a-a870-c8fa8e8ceea7@github.com>
Message-ID: <Yb73VRCyBmXUC7ZtZB412LEat6pKR9q3jLPVB3ztJw8=.9696627e-31c5-4026-9e15-6e2a7ce70c70@github.com>

On Thu, 8 Oct 2020 20:44:00 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

>> Evgeny Nikitin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add null values support and two-way testing
>
> test/lib/jdk/test/lib/format/Diff.java line 37:
> 
>> 35:      * Default limits for formatters
>> 36:      */
>> 37:     public static class Defaults {
> 
> I'd add a no-op private no-arg ctor to show that this class isn't expected to be instantiated.

Got it, fixed in the 78ed79f38262fec1df3ffb7ba407dc792666d1fd.

-------------

PR: https://git.openjdk.java.net/jdk/pull/112

From enikitin at openjdk.java.net  Fri Oct  9 08:00:52 2020
From: enikitin at openjdk.java.net (Evgeny Nikitin)
Date: Fri, 9 Oct 2020 08:00:52 GMT
Subject: RFR: 8229186: Improve error messages for TestStringIntrinsics
 failures [v12]
In-Reply-To: <Br6z5yt0kTbZwIQyTI9lz7czaYpjw5vCd5ZCbbrSIcM=.6a8096f1-91ed-4673-bab3-3bfae758ab95@github.com>
References: <Br6z5yt0kTbZwIQyTI9lz7czaYpjw5vCd5ZCbbrSIcM=.6a8096f1-91ed-4673-bab3-3bfae758ab95@github.com>
Message-ID: <B7QRwqAtrM8tf4ACnP7ycNDyh9-2h9Kju40BCHfu2ns=.e3421336-e8fa-41d3-802b-54683804f394@github.com>

> pre-Skara RFR thread: [link](https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-May/038416.html)
> 
> Error reporting was improved by writing a C-style escaped string representations for the variables passed to the
> methods being tested. For array comparisons, a dedicated diff-formatter was implemented.
> Sample output for comparing byte arrays (with artificial failure):
>  ----------System.err:(21/1553)----------
>  Result: (false) of 'arrayEqualsB' is not equal to expected (true)
>  Arrays differ starting from [index: 7]:
>  ... 5, 6,   7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, ...
>  ... 5, 6, 125, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, ...
>            ^^^^
>  java.lang.RuntimeException: Result: (false) of 'arrayEqualsB' is not
>  equal to expected (true)
>           at
>  compiler.intrinsics.string.TestStringIntrinsics.invokeAndCheckArrays(TestStringIntrinsics.java:273)
>            at ... stack trace continues - E.N.
>  Sample output for comparing char arrays:
>  ----------System.err:(21/1579)*----------
>  Result: (false) of 'arrayEqualsC' is not equal to expected (true)
>  Arrays differ starting from [index: 7]:
>  ... \\u0005, \\u0006, \\u0007, \\u0008, \\u0009, \\n, ...
>  ... \\u0005, \\u0006,      }, \\u0008, \\u0009, \\n, ...
>                      ^^^^^^^
>  java.lang.RuntimeException: Result: (false) of 'arrayEqualsC' is not
>  equal to expected (true)
>           at
>  compiler.intrinsics.string.TestStringIntrinsics.invokeAndCheckArrays(TestStringIntrinsics.java:280)
>            at
>  ... and so on - E.N.
> 
> testing: open/test/hotspot/jtreg/compiler/intrinsics/string/TestStringIntrinsics.java on linux, windows, macosx.

Evgeny Nikitin has updated the pull request incrementally with one additional commit since the last revision:

  Fix ArrayCodec's behaviour for preffix and identical arrays

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/112/files
  - new: https://git.openjdk.java.net/jdk/pull/112/files/78ed79f3..174148ab

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=112&range=11
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=112&range=10-11

  Stats: 7 lines in 1 file changed: 4 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/112.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/112/head:pull/112

PR: https://git.openjdk.java.net/jdk/pull/112

From enikitin at openjdk.java.net  Fri Oct  9 08:00:54 2020
From: enikitin at openjdk.java.net (Evgeny Nikitin)
Date: Fri, 9 Oct 2020 08:00:54 GMT
Subject: RFR: 8229186: Improve error messages for TestStringIntrinsics
 failures [v9]
In-Reply-To: <JaOamNkEsvcU2tZ0peQzE3-FcmmsgP2S9k5-W8FQluI=.3f5c1b2b-3357-404a-a870-c8fa8e8ceea7@github.com>
References: <Br6z5yt0kTbZwIQyTI9lz7czaYpjw5vCd5ZCbbrSIcM=.6a8096f1-91ed-4673-bab3-3bfae758ab95@github.com>
 <8MKmW-2_q3RYbIsye58L3XfOmaLItKlb8M8WB2-1cmI=.4b5a0dc0-e379-47bf-8479-10f18f0cbf0e@github.com>
 <JaOamNkEsvcU2tZ0peQzE3-FcmmsgP2S9k5-W8FQluI=.3f5c1b2b-3357-404a-a870-c8fa8e8ceea7@github.com>
Message-ID: <0nytWVYaAK9Jb_Nr82oNlxbz8sYBizQZ-n4aJATyPTg=.b7a0e879-86be-4584-8eef-168cb4c52abb@github.com>

On Thu, 8 Oct 2020 20:45:50 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

>> Evgeny Nikitin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add null values support and two-way testing
>
> test/lib/jdk/test/lib/format/ArrayCodec.java line 325:
> 
>> 323:         }
>> 324:
>> 325:         return 0;
> 
> shouldn't it be -1?

An interesting notice, actually. It should be either `-1` or `result` depending on whether arrays are equal, or one
array is a prefix of another. Fixed in the 174148ab41e1c03d46dbde8862865dbaf3138843.

-------------

PR: https://git.openjdk.java.net/jdk/pull/112

From shade at openjdk.java.net  Fri Oct  9 09:27:20 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 9 Oct 2020 09:27:20 GMT
Subject: RFR: 8245543: Cgroups: Incorrect detection logic on some systems
 (still reproducible) [v6]
In-Reply-To: <ib0g_wcL2UGww1rsF-zydPbVHaqKAOZbqSnYwzSFyms=.41072921-e238-41fd-b9a7-31e1c714ab92@github.com>
References: <CWATRi437QpkCA1sx-EsHFqVlSCV-G8EgkEoGdJgPHc=.a743be7e-8a00-4d91-866d-86ccf3fe714f@github.com>
 <ib0g_wcL2UGww1rsF-zydPbVHaqKAOZbqSnYwzSFyms=.41072921-e238-41fd-b9a7-31e1c714ab92@github.com>
Message-ID: <-Ll4Bwe0uyCWuyzX2zt7DYCLLYihiQUGOMrFymzEP_8=.2f70563a-6707-4c44-b258-88d068c2e21d@github.com>

On Thu, 8 Oct 2020 13:38:59 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> An issue similar to [JDK-8239559](https://bugs.openjdk.java.net/browse/JDK-8239559) has been discovered. On the
>> affected system, `/proc/self/mountinfo` contains a line such as this one:
>> 
>> 35 26 0:26 / /sys/fs/cgroup/systemd rw,nosuid,nodev,noexec,relatime - cgroup systemd rw,name=systemd
>>  
>> 
>> Note that `/proc/cgroups` looks like this:
>> 
>> #subsys_name	hierarchy	num_cgroups	enabled
>> cpuset	0	1	1
>> cpu	0	1	1
>> cpuacct	0	1	1
>> blkio	0	1	1
>> memory	0	1	1
>> devices	0	1	1
>> freezer	0	1	1
>> net_cls	0	1	1
>> perf_event	0	1	1
>> net_prio	0	1	1
>> hugetlb	0	1	1
>> pids	0	1	1
>> 
>> This is in fact a cgroups v1 system with systemd put into a separate namespace via FS type `cgroup`. That mountinfo
>> line confuses the cgroups version detection heuristic. It only looked whether or not there is **any** entry in
>> mountinfo of FS-type `cgroup` . That's wrong. A better heuristic would be looking at controllers we care about: `cpu`,
>> `cpuacct`, `memory`, `cpuset` for hotspot and some more for the Java side. The proposed fix on the hotspot side is to
>> set `any_cgroup_mounts_found` to true only if one of those controllers show up in mountinfo. Otherwise, we know it's
>> cgroup v2 due to the zero hierarchy ids. The fix on the Java side is similar.  For the Java side the proposal is also
>> to do the parsing of the cgroup files in the factory now (single pass of files). No longer in the version specific
>> objects. In order to not regress here, I've added more tests.
>> **Testing**
>> 
>>  - [x] Linux x86_64 container tests on cgroup v1 (fastdebug)
>>  - [x] Linux x86_64 container tests on cgroup v2 (fastdebug)
>>  - [x] Added regression test which fails prior the patch and passes after
>>  - [x] Submit testing
>
> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Return false in case of no pattern match

This looks fine to me. Consider a minor nit below.

src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemFactory.java line 183:

> 181:              }
> 182:          }
> 183:          return relevantControllerFound;

If I am reading the code right, then `relevantControllerFound` can be replaced with just `return true` or `return
false`?

-------------

Marked as reviewed by shade (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/485

From sgehwolf at openjdk.java.net  Fri Oct  9 09:49:19 2020
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Fri, 9 Oct 2020 09:49:19 GMT
Subject: RFR: 8245543: Cgroups: Incorrect detection logic on some systems
 (still reproducible) [v6]
In-Reply-To: <-Ll4Bwe0uyCWuyzX2zt7DYCLLYihiQUGOMrFymzEP_8=.2f70563a-6707-4c44-b258-88d068c2e21d@github.com>
References: <CWATRi437QpkCA1sx-EsHFqVlSCV-G8EgkEoGdJgPHc=.a743be7e-8a00-4d91-866d-86ccf3fe714f@github.com>
 <ib0g_wcL2UGww1rsF-zydPbVHaqKAOZbqSnYwzSFyms=.41072921-e238-41fd-b9a7-31e1c714ab92@github.com>
 <-Ll4Bwe0uyCWuyzX2zt7DYCLLYihiQUGOMrFymzEP_8=.2f70563a-6707-4c44-b258-88d068c2e21d@github.com>
Message-ID: <nHmHXguuun_UxxbFyF3ukaQh469MPG_JiumY68bXV74=.15084236-5871-4fe6-9e16-8229bbf86bb5@github.com>

On Fri, 9 Oct 2020 09:23:22 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Return false in case of no pattern match
>
> src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemFactory.java line 183:
> 
>> 181:              }
>> 182:          }
>> 183:          return relevantControllerFound;
> 
> If I am reading the code right, then `relevantControllerFound` can be replaced with just `return true` or `return
> false`?

I don't think so. It starts out as `false` and is being set to true on lines 180 and 174. So we could change it to
`return false` here iff lines 174 and 180 would `return true`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/485

From shade at openjdk.java.net  Fri Oct  9 09:54:19 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 9 Oct 2020 09:54:19 GMT
Subject: RFR: 8245543: Cgroups: Incorrect detection logic on some systems
 (still reproducible) [v6]
In-Reply-To: <nHmHXguuun_UxxbFyF3ukaQh469MPG_JiumY68bXV74=.15084236-5871-4fe6-9e16-8229bbf86bb5@github.com>
References: <CWATRi437QpkCA1sx-EsHFqVlSCV-G8EgkEoGdJgPHc=.a743be7e-8a00-4d91-866d-86ccf3fe714f@github.com>
 <ib0g_wcL2UGww1rsF-zydPbVHaqKAOZbqSnYwzSFyms=.41072921-e238-41fd-b9a7-31e1c714ab92@github.com>
 <-Ll4Bwe0uyCWuyzX2zt7DYCLLYihiQUGOMrFymzEP_8=.2f70563a-6707-4c44-b258-88d068c2e21d@github.com>
 <nHmHXguuun_UxxbFyF3ukaQh469MPG_JiumY68bXV74=.15084236-5871-4fe6-9e16-8229bbf86bb5@github.com>
Message-ID: <RBMbVAmJEZhuLLTqJJMRmkn5OIL24_oCF7Kx15OWKXA=.eb72d6a5-596b-4fae-8de4-a0d3fc12c2db@github.com>

On Fri, 9 Oct 2020 09:46:55 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemFactory.java line 183:
>> 
>>> 181:              }
>>> 182:          }
>>> 183:          return relevantControllerFound;
>> 
>> If I am reading the code right, then `relevantControllerFound` can be replaced with just `return true` or `return
>> false`?
>
> I don't think so. It starts out as `false` and is being set to true on lines 180 and 174. So we could change it to
> `return false` here iff lines 174 and 180 would `return true`.

Yes, that's what I meant: instead of dragging the boolean flag, do the early `return true`, or `return false`
otherwise. Your choice if you want to make that change.

-------------

PR: https://git.openjdk.java.net/jdk/pull/485

From sgehwolf at openjdk.java.net  Fri Oct  9 10:24:34 2020
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Fri, 9 Oct 2020 10:24:34 GMT
Subject: RFR: 8245543: Cgroups: Incorrect detection logic on some systems
 (still reproducible) [v7]
In-Reply-To: <CWATRi437QpkCA1sx-EsHFqVlSCV-G8EgkEoGdJgPHc=.a743be7e-8a00-4d91-866d-86ccf3fe714f@github.com>
References: <CWATRi437QpkCA1sx-EsHFqVlSCV-G8EgkEoGdJgPHc=.a743be7e-8a00-4d91-866d-86ccf3fe714f@github.com>
Message-ID: <OOCfwXvngoGQBATPzj-LYBGw5jJbt2E3DXJTb0XRc9Q=.5c6916d3-2574-4b48-af0b-6ae4541ccce7@github.com>

> An issue similar to [JDK-8239559](https://bugs.openjdk.java.net/browse/JDK-8239559) has been discovered. On the
> affected system, `/proc/self/mountinfo` contains a line such as this one:
> 
> 35 26 0:26 / /sys/fs/cgroup/systemd rw,nosuid,nodev,noexec,relatime - cgroup systemd rw,name=systemd
>  
> 
> Note that `/proc/cgroups` looks like this:
> 
> #subsys_name	hierarchy	num_cgroups	enabled
> cpuset	0	1	1
> cpu	0	1	1
> cpuacct	0	1	1
> blkio	0	1	1
> memory	0	1	1
> devices	0	1	1
> freezer	0	1	1
> net_cls	0	1	1
> perf_event	0	1	1
> net_prio	0	1	1
> hugetlb	0	1	1
> pids	0	1	1
> 
> This is in fact a cgroups v1 system with systemd put into a separate namespace via FS type `cgroup`. That mountinfo
> line confuses the cgroups version detection heuristic. It only looked whether or not there is **any** entry in
> mountinfo of FS-type `cgroup` . That's wrong. A better heuristic would be looking at controllers we care about: `cpu`,
> `cpuacct`, `memory`, `cpuset` for hotspot and some more for the Java side. The proposed fix on the hotspot side is to
> set `any_cgroup_mounts_found` to true only if one of those controllers show up in mountinfo. Otherwise, we know it's
> cgroup v2 due to the zero hierarchy ids. The fix on the Java side is similar.  For the Java side the proposal is also
> to do the parsing of the cgroup files in the factory now (single pass of files). No longer in the version specific
> objects. In order to not regress here, I've added more tests.
> **Testing**
> 
>  - [x] Linux x86_64 container tests on cgroup v1 (fastdebug)
>  - [x] Linux x86_64 container tests on cgroup v2 (fastdebug)
>  - [x] Added regression test which fails prior the patch and passes after
>  - [x] Submit testing

Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:

  Drop local variable

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/485/files
  - new: https://git.openjdk.java.net/jdk/pull/485/files/37f5b093..c18be739

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=485&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=485&range=05-06

  Stats: 5 lines in 1 file changed: 0 ins; 2 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/485.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/485/head:pull/485

PR: https://git.openjdk.java.net/jdk/pull/485

From sgehwolf at openjdk.java.net  Fri Oct  9 10:24:34 2020
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Fri, 9 Oct 2020 10:24:34 GMT
Subject: RFR: 8245543: Cgroups: Incorrect detection logic on some systems
 (still reproducible) [v6]
In-Reply-To: <RBMbVAmJEZhuLLTqJJMRmkn5OIL24_oCF7Kx15OWKXA=.eb72d6a5-596b-4fae-8de4-a0d3fc12c2db@github.com>
References: <CWATRi437QpkCA1sx-EsHFqVlSCV-G8EgkEoGdJgPHc=.a743be7e-8a00-4d91-866d-86ccf3fe714f@github.com>
 <ib0g_wcL2UGww1rsF-zydPbVHaqKAOZbqSnYwzSFyms=.41072921-e238-41fd-b9a7-31e1c714ab92@github.com>
 <-Ll4Bwe0uyCWuyzX2zt7DYCLLYihiQUGOMrFymzEP_8=.2f70563a-6707-4c44-b258-88d068c2e21d@github.com>
 <nHmHXguuun_UxxbFyF3ukaQh469MPG_JiumY68bXV74=.15084236-5871-4fe6-9e16-8229bbf86bb5@github.com>
 <RBMbVAmJEZhuLLTqJJMRmkn5OIL24_oCF7Kx15OWKXA=.eb72d6a5-596b-4fae-8de4-a0d3fc12c2db@github.com>
Message-ID: <ZswFcle80xj1tkvg9KMjem6M5Zidts_gUpRBfNNRUNo=.2b552b9f-37c4-48b4-b11e-062bcad616d2@github.com>

On Fri, 9 Oct 2020 09:51:29 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> I don't think so. It starts out as `false` and is being set to true on lines 180 and 174. So we could change it to
>> `return false` here iff lines 174 and 180 would `return true`.
>
> Yes, that's what I meant: instead of dragging the boolean flag, do the early `return true`, or `return false`
> otherwise. Your choice if you want to make that change.

OK, done. Thanks for the review!

-------------

PR: https://git.openjdk.java.net/jdk/pull/485

From simonis at openjdk.java.net  Fri Oct  9 10:28:34 2020
From: simonis at openjdk.java.net (Volker Simonis)
Date: Fri, 9 Oct 2020 10:28:34 GMT
Subject: RFR: 8253952: Refine ZipOutputStream.putNextEntry() to
 recalculate ZipEntry's compressed size [v2]
In-Reply-To: <0nq5oFKOj6AZqCW6jF268-6oKRI6UkS6TRIHo-_5vKw=.d13c7016-4473-4b20-9117-100b368d3716@github.com>
References: <0nq5oFKOj6AZqCW6jF268-6oKRI6UkS6TRIHo-_5vKw=.d13c7016-4473-4b20-9117-100b368d3716@github.com>
Message-ID: <hY8lfhGTXizeHqM6iWX3eKDXz5B4-WHAFaZNvHLk6qc=.d9bf046e-f493-4653-94b1-39d154a4175e@github.com>

> ### Summary
> 
> Work around wrong usage of `ZipOutputStream.putNextEntry()` in user code which can lead to the `ZipException "invalid
> entry compressed size"`.
> ### Motivation
> 
> In general it is not safe to directly write a ZipEntry obtained from `ZipInputStream.getNextEntry()`,
> `ZipFile.entries()`, `ZipFile.getEntry()` or `ZipFile.stream()` with `ZipOutputStream.putNextEntry()` to a
> `ZipOutputStream` and then read the entries data from the `ZipInputStream` and write it to the `ZipOutputStream` as
> follows:
>  ZipEntry entry;
>  ZipInputStream zis = new ZipInputStream(...);
>  ZipOutputStream zos = new ZipOutputStream(...);
>  while((entry = zis.getNextEntry()) != null) {
>      zos.putNextEntry(entry);
>      zis.transferTo(zos);
>  }
> The problem with this code is that the zip file format does not record the compression level used for deflation in its
> entries. In general, it doesn't even mandate a predefined compression ratio per compression level. Therefore the
> compressed size recorded in a `ZipEntry` read from a zip file might differ from the new compressed size produced by the
> receiving `ZipOutputStream`. Such a difference will result in a `ZipException` with the following message:
>  java.util.zip.ZipException: invalid entry compressed size (expected 12 but got 7 bytes)
>  
> The correct way of copying all entries from one zip file into another requires the creation of a new `ZipEntry` or at
> least resetting of the compressed size field. E.g.:
>  while((entry = zis.getNextEntry()) != null) {
>      ZipEntry newEntry = new ZipEntry(entry.getName());
>      zos.putNextEntry(newEntry);
>      zis.transferTo(zos);
>  }
> or:
>  while((entry = zis.getNextEntry()) != null) {
>      entry.setCompressedSize(-1);
>      zos.putNextEntry(entry);
>      zis.transferTo(zos);
>  }
> Unfortunately, there's a lot of user code out there which gets this wrong and uses the bad coding pattern described
> before. Searching for `"java.util.zip.ZipException: invalid entry compressed size (expected 12 but got 7 bytes)"` gives
> ~2500 hits (~100 on StackOverflow). It's also no hard to find plenty of instances of this anti-pattern on GitHub when
> doing a code search for `ZipEntry` and `putNextEntry()`. E.g. [Gradle 4.x wrapper task][1] is affected as well as the
> latest version of the [mockableAndroidJar task][2]. I've recently fixed two occurrences of this pattern in OpenJDK (see
> [JDK-8240333][3] and [JDK-8240235][4]) but there still exist more of them (e.g.
> [`test/jdk/java/util/zip/ZipFile/CopyJar.java`][5] which is there since 1999 :).  ### Description  So while this has
> clearly been a problem before, it apparently wasn't painful enough to trigger any action from the side of the JDK.
> However, recently quite some zlib forks with [superior deflate/inflate performance have evolved][6]. Using them with
> OpenJDK is quite straight-forward: one just has to configure the alternative implementations by setting
> `LD_LIBRARY_PATH` or `LD_PRELOAD` correspondingly. We've seen big saving by using these new zlib implementations for
> selected services in production and the only reason why we haven't enabled them by default until now is the problem
> I've just described. The reason why these new libraries uncover the described anti-pattern much more often is because
> their compression ratio is slightly different from that of the default zlib library. This can easily trigger a
> `ZipException` even if an application is not using a different compression levels but just a zip file created with
> another zlib version.  I'd therefore like to propose the following workaround for the wrong
> `ZipOutputStream.putNextEntry()` usage in user code:
> -  ignore the compressed size if it was implicitly determined from the zip file and not explicitly set by calling
>    `ZipEntry.setCompressedSize()`.
> 
> - Change the API-documentation of `ZipOutputStream.putNextEntry()` and `JarOutputStream.putNextEntry()` to explain the
>   problem and why `putNextEntry()` will ignore the compressed size of a `ZipEntry` if that was set implicitely when
>   reading that entry from a `ZipFile` or `ZipInputStream`.
> 
> 
> ### Technical Details
> 
> A zip file consists of a stream of File Entries followed by a Central Directory (see [here for a more detailed
> specification][7]). Each File Entry is composed of a Local File Header (LFH) followed by the compressed Data and an
> optional Data Descriptor. The LFH contains the File Name and among other attributes the Compressed and Uncompressed
> size and CRC of the Data. In the case where the latter three attributes are not available at the time when the LFH is
> created, this fact will be recorded in a flag of the LFH and will trigger the creation of a Data Descriptor with the
> corresponding information right after the Data section. Finally, the Central Directory contains one Central Directory
> File Header (CDFH) for each entry of the  zip archive. The CDFH is an extended version of the LFH and the ultimate
> reference for the contents of the zip archive. The redundancy between LFH and CDFH is a tribute to zip's long history
> when it was used to store archives on multiple floppy discs and the CDFH allowed to update the archive by only writing
> to the last disc which contained the Central Directory.  `ZipEntries` read with `ZipInputStream.getNextEntry()` will
> initially only contain the information from the LFH. Only after the next entry was read (or after
> `ZipInputStream.closeEntry()` was called explicitly), will the previously read entry be updated with the data from the
> Data Descriptor. `ZipInputStream` doesn't inspect the Central Directory at all.  On the other hand, `ZipFile` only
> queries the Central Directory for `ZipEntry` information so all `ZipEntries` returned by `ZipFile.entries()`,
> `ZipFile.getEntry()` and `ZipFile.stream()` will always instantly contain the full Compressed and Uncompressed Size and
> CRC information for each entry independently of the LFH contents.  ### Risks and Assumptions  If we choose to ignore
> the implicitly recorded compressed size in a `ZipEntry` read from a zip file when writing it to a `ZipOutputStream`,
> this will lead to zip files with incomplete information in the LFH and an additional Data Descriptor as described
> before. However, the result is still fully compatible to the zip file specification. It's also not unusual, because by
> default all new zip files created with `ZipOutputStream` will contain LFHs without Compressed and Uncompressed Size and
> CRC information and an additional Data Descriptor. Theoretically it is possible to create new zip files with
> `ZipOutputStream` class and Compressed and Uncompressed Size and CRC information in the LFH but that's complex and
> inefficient because it requires two steps. A first step to determine the crc and compressed size of the data and a
> second step to actually write the data to the `ZipOutputStream` (which will compress it a second time). This is because
> the current API offers no possibility to write already compressed data to a `ZipOutputStream`.  Consequently, the only
> straight-forward way of creating zip files from Java which have all the data in the LFH and no Data Descriptor is by
> copying `ZipEntries` from an existing zip file with the buggy method described before. This incidentally worked more or
> less reliable for a long time but breaks miserably when using different zlib implementations. Ignoring the implicitly
> set compressed size of `ZipEntries` can easily fix this problem.  I'm not aware of any tool which can not handle such
> files and if it exists it would have problems with the majority of Java created zip files anyway (e.g. all jar-files
> created with the jar tool have zip entries with incomplete LFH data and additional Data Descriptor).  Ignoring the
> implicitly set compressed size of `ZipEntries` has no measurable performance impact and will increase the size of zip
> archives which used to have the complete file information in the LFH before by 16 bytes per entry. On the other hand it
> will give us the freedom to use whatever zip implementation we like :)   [1]:
> https://github.com/gradle/gradle/blob/e76905e3a/subprojects/build-init/src/main/java/org/gradle/api/tasks/wrapper/Wrapper.java#L152-L158
> [2]:
> https://android.googlesource.com/platform/tools/base/+/refs/heads/master/build-system/builder/src/main/java/com/android/builder/testing/MockableJarGenerator.java#86
> [3]: https://bugs.openjdk.java.net/browse/JDK-8240333 [4]: https://bugs.openjdk.java.net/browse/JDK-8240235 [5]:
> https://github.com/openjdk/jdk/blob/master/test/jdk/java/util/zip/ZipFile/CopyJar.java [6]:
> https://github.com/simonis/zlib-bench/blob/master/Results.md [7]: https://en.wikipedia.org/wiki/Zip_(file_format)

Volker Simonis 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:

  8253952: Refine ZipOutputStream.putNextEntry() to recalculate ZipEntry's compressed size

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/520/files
  - new: https://git.openjdk.java.net/jdk/pull/520/files/149b7054..2a9427ef

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=520&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=520&range=00-01

  Stats: 26 lines in 2 files changed: 0 ins; 20 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/520.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/520/head:pull/520

PR: https://git.openjdk.java.net/jdk/pull/520

From simonis at openjdk.java.net  Fri Oct  9 10:28:34 2020
From: simonis at openjdk.java.net (Volker Simonis)
Date: Fri, 9 Oct 2020 10:28:34 GMT
Subject: RFR: 8253952: Refine ZipOutputStream.putNextEntry() to
 recalculate ZipEntry's compressed size
In-Reply-To: <Vr-tO554xWe5xprEnPMCwuecXrH1DlIi7ip37NMPZqs=.d7d591c5-50fc-4eaf-bac6-eae58fb32040@github.com>
References: <0nq5oFKOj6AZqCW6jF268-6oKRI6UkS6TRIHo-_5vKw=.d13c7016-4473-4b20-9117-100b368d3716@github.com>
 <uOv0IEZBeC6bdvSTaZ2VHF6ApqwpwWGuTsKznkhzFu0=.9ad91b5b-74ce-4702-ba77-55bf6ab67189@github.com>
 <Vr-tO554xWe5xprEnPMCwuecXrH1DlIi7ip37NMPZqs=.d7d591c5-50fc-4eaf-bac6-eae58fb32040@github.com>
Message-ID: <oixNi-7zgSzri_eIej_Yj62oGSglRq_kImHpH2a3eJE=.7313873a-d9da-4480-b396-90733edfca34@github.com>

On Wed, 7 Oct 2020 16:45:53 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> I think as we start to move forward with the review and CSR, we should update the bug and PR description as the change
>> is not a workaround but a change in behavior of the implementation
>
> I already changed the bug description on Alan's request and just updated the PR description to reflect that. Please
> feel free to propose a better description.

Thanks for your feedback. I've updated the API doc as requested and created a CSR at:

https://bugs.openjdk.java.net/browse/JDK-8254284

Can somebody please also review the CSR?

Thank you and best regards,
Volker

-------------

PR: https://git.openjdk.java.net/jdk/pull/520

From mcimadamore at openjdk.java.net  Fri Oct  9 10:39:56 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 9 Oct 2020 10:39:56 GMT
Subject: RFR: 8254162: Implementation of Foreign-Memory Access API (Third
 Incubator) [v4]
In-Reply-To: <IngRk57F78UN3yySfo6IABbdwnMogGNdYrykh_3em-c=.b81f7478-015c-45ed-9788-58d7519a2770@github.com>
References: <IngRk57F78UN3yySfo6IABbdwnMogGNdYrykh_3em-c=.b81f7478-015c-45ed-9788-58d7519a2770@github.com>
Message-ID: <4h3RYe5xrN6HpjRM1kkVgfo9yDiPoxoS312x9nYDpwA=.3260dd59-63e3-4b55-8a86-d512b1a4ee24@github.com>

> This patch contains the changes associated with the third incubation round of the foreign memory access API incubation
> (see JEP 393 [1]). This iteration focus on improving the usability of the API in 3 main ways:
> * first, by providing a way to obtain truly *shared* segments, which can be accessed and closed concurrently from
>   multiple threads
> * second, by providing a way to register a memory segment against a `Cleaner`, so as to have some (optional) guarantee
>   that the memory will be deallocated, eventually
> * third, by not requiring users to dive deep into var handles when they first pick up the API; a new `MemoryAccess` class
>   has been added, which defines several useful dereference routines; these are really just thin wrappers around memory
>   access var handles, but they make the barrier of entry for using this API somewhat lower.
> 
> A big conceptual shift that comes with this API refresh is that the role of `MemorySegment` and `MemoryAddress` is not
> the same as it used to be; it used to be the case that a memory address could (sometimes, not always) have a back link
> to the memory segment which originated it; additionally, memory access var handles used `MemoryAddress` as a basic unit
> of dereference.  This has all changed as per this API refresh;  now a `MemoryAddress` is just a dumb carrier which
> wraps a pair of object/long addressing coordinates; `MemorySegment` has become the star of the show, as far as
> dereferencing memory is concerned. You cannot dereference memory if you don't have a segment. This improves usability
> in a number of ways - first, it is a lot easier to wrap native addresses (`long`, essentially) into a `MemoryAddress`;
> secondly, it is crystal clear what a client has to do in order to dereference memory: if a client has a segment, it can
> use that; otherwise, if the client only has an address, it will have to create a segment *unsafely* (this can be done
> by calling `MemoryAddress::asSegmentRestricted`).  A list of the API, implementation and test changes is provided
> below. If  you have any questions, or need more detailed explanations, I (and the  rest of the Panama team) will be
> happy to point at existing discussions,  and/or to provide the feedback required.   A big thank to Erik Osterlund,
> Vladimir Ivanov and David Holmes, without whom the work on shared memory segment would not have been possible; also I'd
> like to thank Paul Sandoz, whose insights on API design have been very helpful in this journey.  Thanks  Maurizio
> Javadoc:   http://cr.openjdk.java.net/~mcimadamore/8254162_v1/javadoc/jdk/incubator/foreign/package-summary.html
> Specdiff:
> 
> http://cr.openjdk.java.net/~mcimadamore/8254162_v1/specdiff/jdk/incubator/foreign/package-summary.html
> 
> CSR:
> 
> https://bugs.openjdk.java.net/browse/JDK-8254163
> 
> 
> 
> ### API Changes
> 
> * `MemorySegment`
>   * drop factory for restricted segment (this has been moved to `MemoryAddress`, see below)
>   * added a no-arg factory for a native restricted segment representing entire native heap
>   * rename `withOwnerThread` to `handoff`
>   * add new `share` method, to create shared segments
>   * add new `registerCleaner` method, to register a segment against a cleaner
>   * add more helpers to create arrays from a segment e.g. `toIntArray`
>   * add some `asSlice` overloads (to make up for the fact that now segments are more frequently used as cursors)
>   * rename `baseAddress` to `address` (so that `MemorySegment` can implement `Addressable`)
> * `MemoryAddress`
>   * drop `segment` accessor
>   * drop `rebase` method and replace it with `segmentOffset` which returns the offset (a `long`) of this address relative
>     to a given segment
> * `MemoryAccess`
>   * New class supporting several static dereference helpers; the helpers are organized by carrier and access mode, where a
>     carrier is one of the usual suspect (a Java primitive, minus `boolean`); the access mode can be simple (e.g. access
>     base address of given segment), or indexed, in which case the accessor takes a segment and either a low-level byte
>     offset,or a high level logical index. The classification is reflected in the naming scheme (e.g. `getByte` vs.
>     `getByteAtOffset` vs `getByteAtIndex`).
> * `MemoryHandles`
>   * drop `withOffset` combinator
>   * drop `withStride` combinator
>   * the basic memory access handle factory now returns a var handle which takes a `MemorySegment` and a `long` - from which
>     it is easy to derive all the other handles using plain var handle combinators.
> * `Addressable`
>   * This is a new interface which is attached to entities which can be projected to a `MemoryAddress`. For now, both
>     `MemoryAddress` and `MemorySegment` implement it; we have plans, with JEP 389 [2] to add more implementations. Clients
>     can largely ignore this interface, which comes in really handy when defining native bindings with tools like `jextract`.
> * `MemoryLayouts`
>   * A new layout, for machine addresses, has been added to the mix.
> 
> 
> 
> ### Implementation changes
> 
> There are two main things to discuss here: support for shared segments, and the general simplification of the memory
> access var handle support.
> #### Shared segments
> 
> The support for shared segments cuts in pretty deep in the VM. Support for shared segments is notoriously hard to
> achieve, at least in a way that guarantees optimal access performances. This is caused by the fact that, if a segment
> is shared, it would be possible for a thread to close it while another is accessing it.  After considering several
> options (see [3]), we zeroed onto an approach which is inspired by an happy idea that Andrew Haley had (and that he
> reminded me of at this year OpenJDK committer workshop - thanks!). The idea is that if we could *freeze* the world
> (e.g. with a GC pause), while a segment is closed, we could then prevent segments from being accessed concurrently to a
> close operation. For this to work, it  is crucial that no GC safepoints can occur between a segment liveness check and
> the access itself (otherwise it would be possible for the accessing thread to stop just right before an unsafe call).
> It also relies on the fact that hotspot/C2 should not be able to propagate loads across safepoints.  Sadly, none of
> these conditions seems to be valid in the current implementation, so we needed to resort to a bit of creativity. First,
> we noted that, if we could mark so called *scoped* method with an annotation, it would be very simply to check as to
> whether a thread was in the middle of a scoped method when we stopped the world for a close operation (btw, instead of
> stopping the world, we do a much more efficient, thread-local polling, thanks to JEP 312 [4]).  The question is, then,
> once we detect that a thread is accessing the very segment we're about to close, what should happen? We first
> experimented with a solution which would install an *asynchronous* exception on the accessing thread, thus making it
> fail. This solution has some desirable properties, in that a `close` operation always succeeds. Unfortunately the
> machinery for async exceptions is a bit fragile (e.g. not all the code in hotspot checks for async exceptions); to
> minimize risks, we decided to revert to a simpler strategy, where `close` might fail when it finds that another thread
> is accessing the segment being closed.  As written in the javadoc, this doesn't mean that clients should just catch and
> try again; an exception on `close` is a bug in the user code, likely arising from lack of synchronization, and should
> be treated as such.  In terms of gritty implementation, we needed to centralize memory access routines in a single
> place, so that we could have a set of routines closely mimicking the primitives exposed by `Unsafe` but which, in
> addition, also provided a liveness check. This way we could mark all these routines with the special `@Scoped`
> annotation, which tells the VM that something important is going on.  To achieve this, we created a new (autogenerated)
> class, called `ScopedMemoryAccess`. This class contains all the main memory access primitives (including bulk access,
> like `copyMemory`, or `setMemory`), and accepts, in addition to the access coordinates, also a scope object, which is
> tested before access. A reachability fence is also thrown in the mix to make sure that the scope is kept alive during
> access (which is important when registering segments against cleaners).  Of course, to make memory access safe, memory
> access var handles, byte buffer var handles, and byte buffer API should use the new `ScopedMemoryAccess` class instead
> of unsafe, so that a liveness check can be triggered (in case a scope is present).  `ScopedMemoryAccess` has a
> `closeScope` method, which initiates the thread-local handshakes, and returns `true` if the handshake completed
> successfully.  The implementation of `MemoryScope` (now significantly simplified from what we had before), has two
> implementations, one for confined segments and one for shared segments; the main difference between the two is what
> happens when the scope is closed; a confined segment sets a boolean flag to false, and returns, whereas a shared
> segment goes into a `CLOSING` state, then starts the handshake, and then updates the state again, to either `CLOSED` or
> `ALIVE` depending on whether the handshake was successful or not. Note that when a shared segment is in the `CLOSING`
> state, `MemorySegment::isAlive` will still return `true`, while the liveness check upon memory access will fail.  ####
> Memory access var handles overhaul  The key realization here was that if all memory access var handles took a
> coordinate pair of `MemorySegment` and `long`, all other access types could be derived from this basic var handle
> form.  This allowed us to remove the on-the-fly var handle generation, and to simply derive structural access var
> handles (such as those obtained by calling `MemoryLayout::varHandle`) using *plain* var handle combinators, so that
> e.g. additional offset is injected into a base memory access var handle.  This also helped in simplifying the
> implementation by removing the special `withStride` and `withOffset` combinators, which previously needed low-level
> access on the innards of the memory access var handle. All that code is now gone.  #### Test changes  Not much to see
> here - most of the tests needed to be updated because of the API changes. Some were beefed up (like the array test,
> since now segments can be projected into many different kinds of arrays). A test has been added to test the `Cleaner`
> functionality, and another stress test has been added for shared segments (`TestHandshake`). Some of the
> microbenchmarks also needed some tweaks - and some of them were also updated to also test performance in the shared
> segment case.  [1] - https://openjdk.java.net/jeps/393 [2] - https://openjdk.java.net/jeps/389 [3] -
> https://mail.openjdk.java.net/pipermail/panama-dev/2020-May/009004.html [4] - https://openjdk.java.net/jeps/312

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Address review comments

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/548/files
  - new: https://git.openjdk.java.net/jdk/pull/548/files/b941c4a2..d96c32ac

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=548&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=548&range=02-03

  Stats: 16 lines in 3 files changed: 2 ins; 6 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/548.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/548/head:pull/548

PR: https://git.openjdk.java.net/jdk/pull/548

From mcimadamore at openjdk.java.net  Fri Oct  9 11:34:56 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 9 Oct 2020 11:34:56 GMT
Subject: RFR: 8254162: Implementation of Foreign-Memory Access API (Third
 Incubator) [v5]
In-Reply-To: <IngRk57F78UN3yySfo6IABbdwnMogGNdYrykh_3em-c=.b81f7478-015c-45ed-9788-58d7519a2770@github.com>
References: <IngRk57F78UN3yySfo6IABbdwnMogGNdYrykh_3em-c=.b81f7478-015c-45ed-9788-58d7519a2770@github.com>
Message-ID: <AxWYajmJjEPIcO9sf_JL92HEAu9p91UdTSyrOH4lj-o=.bdbe2d46-4148-4869-bbe2-c95c89042ce1@github.com>

> This patch contains the changes associated with the third incubation round of the foreign memory access API incubation
> (see JEP 393 [1]). This iteration focus on improving the usability of the API in 3 main ways:
> * first, by providing a way to obtain truly *shared* segments, which can be accessed and closed concurrently from
>   multiple threads
> * second, by providing a way to register a memory segment against a `Cleaner`, so as to have some (optional) guarantee
>   that the memory will be deallocated, eventually
> * third, by not requiring users to dive deep into var handles when they first pick up the API; a new `MemoryAccess` class
>   has been added, which defines several useful dereference routines; these are really just thin wrappers around memory
>   access var handles, but they make the barrier of entry for using this API somewhat lower.
> 
> A big conceptual shift that comes with this API refresh is that the role of `MemorySegment` and `MemoryAddress` is not
> the same as it used to be; it used to be the case that a memory address could (sometimes, not always) have a back link
> to the memory segment which originated it; additionally, memory access var handles used `MemoryAddress` as a basic unit
> of dereference.  This has all changed as per this API refresh;  now a `MemoryAddress` is just a dumb carrier which
> wraps a pair of object/long addressing coordinates; `MemorySegment` has become the star of the show, as far as
> dereferencing memory is concerned. You cannot dereference memory if you don't have a segment. This improves usability
> in a number of ways - first, it is a lot easier to wrap native addresses (`long`, essentially) into a `MemoryAddress`;
> secondly, it is crystal clear what a client has to do in order to dereference memory: if a client has a segment, it can
> use that; otherwise, if the client only has an address, it will have to create a segment *unsafely* (this can be done
> by calling `MemoryAddress::asSegmentRestricted`).  A list of the API, implementation and test changes is provided
> below. If  you have any questions, or need more detailed explanations, I (and the  rest of the Panama team) will be
> happy to point at existing discussions,  and/or to provide the feedback required.   A big thank to Erik Osterlund,
> Vladimir Ivanov and David Holmes, without whom the work on shared memory segment would not have been possible; also I'd
> like to thank Paul Sandoz, whose insights on API design have been very helpful in this journey.  Thanks  Maurizio
> Javadoc:   http://cr.openjdk.java.net/~mcimadamore/8254162_v1/javadoc/jdk/incubator/foreign/package-summary.html
> Specdiff:
> 
> http://cr.openjdk.java.net/~mcimadamore/8254162_v1/specdiff/jdk/incubator/foreign/package-summary.html
> 
> CSR:
> 
> https://bugs.openjdk.java.net/browse/JDK-8254163
> 
> 
> 
> ### API Changes
> 
> * `MemorySegment`
>   * drop factory for restricted segment (this has been moved to `MemoryAddress`, see below)
>   * added a no-arg factory for a native restricted segment representing entire native heap
>   * rename `withOwnerThread` to `handoff`
>   * add new `share` method, to create shared segments
>   * add new `registerCleaner` method, to register a segment against a cleaner
>   * add more helpers to create arrays from a segment e.g. `toIntArray`
>   * add some `asSlice` overloads (to make up for the fact that now segments are more frequently used as cursors)
>   * rename `baseAddress` to `address` (so that `MemorySegment` can implement `Addressable`)
> * `MemoryAddress`
>   * drop `segment` accessor
>   * drop `rebase` method and replace it with `segmentOffset` which returns the offset (a `long`) of this address relative
>     to a given segment
> * `MemoryAccess`
>   * New class supporting several static dereference helpers; the helpers are organized by carrier and access mode, where a
>     carrier is one of the usual suspect (a Java primitive, minus `boolean`); the access mode can be simple (e.g. access
>     base address of given segment), or indexed, in which case the accessor takes a segment and either a low-level byte
>     offset,or a high level logical index. The classification is reflected in the naming scheme (e.g. `getByte` vs.
>     `getByteAtOffset` vs `getByteAtIndex`).
> * `MemoryHandles`
>   * drop `withOffset` combinator
>   * drop `withStride` combinator
>   * the basic memory access handle factory now returns a var handle which takes a `MemorySegment` and a `long` - from which
>     it is easy to derive all the other handles using plain var handle combinators.
> * `Addressable`
>   * This is a new interface which is attached to entities which can be projected to a `MemoryAddress`. For now, both
>     `MemoryAddress` and `MemorySegment` implement it; we have plans, with JEP 389 [2] to add more implementations. Clients
>     can largely ignore this interface, which comes in really handy when defining native bindings with tools like `jextract`.
> * `MemoryLayouts`
>   * A new layout, for machine addresses, has been added to the mix.
> 
> 
> 
> ### Implementation changes
> 
> There are two main things to discuss here: support for shared segments, and the general simplification of the memory
> access var handle support.
> #### Shared segments
> 
> The support for shared segments cuts in pretty deep in the VM. Support for shared segments is notoriously hard to
> achieve, at least in a way that guarantees optimal access performances. This is caused by the fact that, if a segment
> is shared, it would be possible for a thread to close it while another is accessing it.  After considering several
> options (see [3]), we zeroed onto an approach which is inspired by an happy idea that Andrew Haley had (and that he
> reminded me of at this year OpenJDK committer workshop - thanks!). The idea is that if we could *freeze* the world
> (e.g. with a GC pause), while a segment is closed, we could then prevent segments from being accessed concurrently to a
> close operation. For this to work, it  is crucial that no GC safepoints can occur between a segment liveness check and
> the access itself (otherwise it would be possible for the accessing thread to stop just right before an unsafe call).
> It also relies on the fact that hotspot/C2 should not be able to propagate loads across safepoints.  Sadly, none of
> these conditions seems to be valid in the current implementation, so we needed to resort to a bit of creativity. First,
> we noted that, if we could mark so called *scoped* method with an annotation, it would be very simply to check as to
> whether a thread was in the middle of a scoped method when we stopped the world for a close operation (btw, instead of
> stopping the world, we do a much more efficient, thread-local polling, thanks to JEP 312 [4]).  The question is, then,
> once we detect that a thread is accessing the very segment we're about to close, what should happen? We first
> experimented with a solution which would install an *asynchronous* exception on the accessing thread, thus making it
> fail. This solution has some desirable properties, in that a `close` operation always succeeds. Unfortunately the
> machinery for async exceptions is a bit fragile (e.g. not all the code in hotspot checks for async exceptions); to
> minimize risks, we decided to revert to a simpler strategy, where `close` might fail when it finds that another thread
> is accessing the segment being closed.  As written in the javadoc, this doesn't mean that clients should just catch and
> try again; an exception on `close` is a bug in the user code, likely arising from lack of synchronization, and should
> be treated as such.  In terms of gritty implementation, we needed to centralize memory access routines in a single
> place, so that we could have a set of routines closely mimicking the primitives exposed by `Unsafe` but which, in
> addition, also provided a liveness check. This way we could mark all these routines with the special `@Scoped`
> annotation, which tells the VM that something important is going on.  To achieve this, we created a new (autogenerated)
> class, called `ScopedMemoryAccess`. This class contains all the main memory access primitives (including bulk access,
> like `copyMemory`, or `setMemory`), and accepts, in addition to the access coordinates, also a scope object, which is
> tested before access. A reachability fence is also thrown in the mix to make sure that the scope is kept alive during
> access (which is important when registering segments against cleaners).  Of course, to make memory access safe, memory
> access var handles, byte buffer var handles, and byte buffer API should use the new `ScopedMemoryAccess` class instead
> of unsafe, so that a liveness check can be triggered (in case a scope is present).  `ScopedMemoryAccess` has a
> `closeScope` method, which initiates the thread-local handshakes, and returns `true` if the handshake completed
> successfully.  The implementation of `MemoryScope` (now significantly simplified from what we had before), has two
> implementations, one for confined segments and one for shared segments; the main difference between the two is what
> happens when the scope is closed; a confined segment sets a boolean flag to false, and returns, whereas a shared
> segment goes into a `CLOSING` state, then starts the handshake, and then updates the state again, to either `CLOSED` or
> `ALIVE` depending on whether the handshake was successful or not. Note that when a shared segment is in the `CLOSING`
> state, `MemorySegment::isAlive` will still return `true`, while the liveness check upon memory access will fail.  ####
> Memory access var handles overhaul  The key realization here was that if all memory access var handles took a
> coordinate pair of `MemorySegment` and `long`, all other access types could be derived from this basic var handle
> form.  This allowed us to remove the on-the-fly var handle generation, and to simply derive structural access var
> handles (such as those obtained by calling `MemoryLayout::varHandle`) using *plain* var handle combinators, so that
> e.g. additional offset is injected into a base memory access var handle.  This also helped in simplifying the
> implementation by removing the special `withStride` and `withOffset` combinators, which previously needed low-level
> access on the innards of the memory access var handle. All that code is now gone.  #### Test changes  Not much to see
> here - most of the tests needed to be updated because of the API changes. Some were beefed up (like the array test,
> since now segments can be projected into many different kinds of arrays). A test has been added to test the `Cleaner`
> functionality, and another stress test has been added for shared segments (`TestHandshake`). Some of the
> microbenchmarks also needed some tweaks - and some of them were also updated to also test performance in the shared
> segment case.  [1] - https://openjdk.java.net/jeps/393 [2] - https://openjdk.java.net/jeps/389 [3] -
> https://mail.openjdk.java.net/pipermail/panama-dev/2020-May/009004.html [4] - https://openjdk.java.net/jeps/312

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Fix performance issue with "small" segment mismatch

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/548/files
  - new: https://git.openjdk.java.net/jdk/pull/548/files/d96c32ac..9b3fc227

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=548&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=548&range=03-04

  Stats: 7 lines in 1 file changed: 0 ins; 5 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/548.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/548/head:pull/548

PR: https://git.openjdk.java.net/jdk/pull/548

From mcimadamore at openjdk.java.net  Fri Oct  9 11:37:19 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 9 Oct 2020 11:37:19 GMT
Subject: RFR: 8254162: Implementation of Foreign-Memory Access API (Third
 Incubator) [v3]
In-Reply-To: <mzFu6WSGjT8eA0i4FozznkaY1q1ebpixQC7srYAcTro=.0f152f31-e9c2-48ce-a078-a3c3864fd3b8@github.com>
References: <IngRk57F78UN3yySfo6IABbdwnMogGNdYrykh_3em-c=.b81f7478-015c-45ed-9788-58d7519a2770@github.com>
 <lJUy8C4jwS7mc82Pt2_q4CBz3RB2LuV_gf1JG1QyqsI=.d032ebb5-0a1d-48b7-976a-0af3697671c6@github.com>
 <mzFu6WSGjT8eA0i4FozznkaY1q1ebpixQC7srYAcTro=.0f152f31-e9c2-48ce-a078-a3c3864fd3b8@github.com>
Message-ID: <t1wwCihxoSEvIY7WIGoWkgQEoXYIQsGFA-msLiqf-WI=.cdf5814e-4afb-4336-bf4e-6139bea42caf@github.com>

On Thu, 8 Oct 2020 23:17:33 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix indent in GensrcScopedMemoryAccess.gmk
>
> Reviewed this when updated in [panama-foreign](https://github.com/openjdk/panama-foreign/tree/foreign-memaccess), hence
> the lack of substantial comments for this PR.

When re-running all benchmarks, I noted an issue with the `BulkOps` microbenchmark: calling `MemorySegment::mismatch`
on a small segment (< 8 bytes) was 10x slower than with ByteBuffers. After some investigation, I realized that the
issue is caused by the fact that the `AbstractMemorySegmentImpl::mismatch` method contains inexact var handle calls,
where the segment coordinate has type `AbstractMemorySegmentImpl` instead of the expected `MemorySegment`, so we take
the slow path.

A simple solution is to avoid using var handles directly here, and use the helper functions in MemoryAccess, which
widens the type accordingly and produce an exact var handle call.

With this change, perfomance of mismatch on small segment is on par with ByteBuffer.

-------------

PR: https://git.openjdk.java.net/jdk/pull/548

From fyang at openjdk.java.net  Fri Oct  9 11:53:31 2020
From: fyang at openjdk.java.net (Fei Yang)
Date: Fri, 9 Oct 2020 11:53:31 GMT
Subject: RFR: 8252204: AArch64: Implement SHA3 accelerator/intrinsic [v5]
In-Reply-To: <PJVtIubjiGKhCK81PIMhWuYxnR84DNieMDUGHdhHYZM=.ad903c93-c5e3-4614-9af1-d36bc33f735d@github.com>
References: <PJVtIubjiGKhCK81PIMhWuYxnR84DNieMDUGHdhHYZM=.ad903c93-c5e3-4614-9af1-d36bc33f735d@github.com>
Message-ID: <nR6wQq3N8OnxHsAdAzQ2mIh6RZQ_b7H_M51Y9Eng3J4=.90d276d3-8b4b-427c-a075-bb7db96e37cb@github.com>

> Contributed-by: ard.biesheuvel at linaro.org, dongbo4 at huawei.com
> 
> This added an intrinsic for SHA3 using aarch64 v8.2 SHA3 Crypto Extensions.
> Reference implementation for core SHA-3 transform using ARMv8.2 Crypto Extensions:
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm64/crypto/sha3-ce-core.S?h=v5.4.52
> 
> Trivial adaptation in SHA3. implCompress is needed for the purpose of adding the intrinsic.
> For SHA3, we need to pass one extra parameter "digestLength" to the stub for the calculation of block size.
> "digestLength" is also used in for the EOR loop before keccak to differentiate different SHA3 variants.
> 
> We added jtreg tests for SHA3 and used QEMU system emulator which supports SHA3 instructions to test the functionality.
> Patch passed jtreg tier1-3 tests with QEMU system emulator.
> Also verified with jtreg tier1-3 tests without SHA3 instructions on aarch64-linux-gnu and x86_64-linux-gnu, to make
> sure that there's no regression.
> We used one existing JMH test for performance test: test/micro/org/openjdk/bench/java/security/MessageDigests.java
> We measured the performance benefit with an aarch64 cycle-accurate simulator.
> Patch delivers 20% - 40% performance improvement depending on specific SHA3 digest length and size of the message.
> 
> For now, this feature will not be enabled automatically for aarch64. We can auto-enable this when it is fully tested on
> real hardware.  But for the above testing purposes, this is auto-enabled when the corresponding hardware feature is
> detected.

Fei Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains
six commits:

 - Merge master
 - Add sha3 instructions to cpu/aarch64/aarch64-asmtest.py and regenerate the test in assembler_aarch64.cpp:asm_check
 - Rebase
 - Merge master
 - Fix trailing whitespace issue
 - 8252204: AArch64: Implement SHA3 accelerator/intrinsic
   Contributed-by: ard.biesheuvel at linaro.org, dongbo4 at huawei.com

-------------

Changes: https://git.openjdk.java.net/jdk/pull/207/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=207&range=04
  Stats: 1512 lines in 35 files changed: 1025 ins; 22 del; 465 mod
  Patch: https://git.openjdk.java.net/jdk/pull/207.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/207/head:pull/207

PR: https://git.openjdk.java.net/jdk/pull/207

From chegar at openjdk.java.net  Fri Oct  9 12:19:30 2020
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Fri, 9 Oct 2020 12:19:30 GMT
Subject: RFR: 8254234 - Add test library stream object builder [v2]
In-Reply-To: <YG2nA5Bzj8YkrGnsdqFnHKGl_XugrwvFX3hoGjdgo_s=.3f19ec15-fa71-4f89-bf86-59287671ffca@github.com>
References: <YG2nA5Bzj8YkrGnsdqFnHKGl_XugrwvFX3hoGjdgo_s=.3f19ec15-fa71-4f89-bf86-59287671ffca@github.com>
Message-ID: <unfBDqc8gA3agPjzEmsP5GytTr1TwLYTYCfDbqVG0xM=.08f35f8b-3c8a-4f86-bb60-be59a0c242ff@github.com>

> It is useful to have a test library facility for building stream objects, suitable for deserialization testing. We
> already have a partial implementation in one of the record serialization tests, move it to the test library for more
> general use. The implementation remains partial, but can be expanded as and when needed.

Chris Hegarty has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev
excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since
the last revision:

 - Merge branch 'master' into serial-byte-stream-builder
 - apply review comments
 - Initial changes for 8254234 - Add test library stream object builder

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/561/files
  - new: https://git.openjdk.java.net/jdk/pull/561/files/557c0a4d..e47b08aa

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=561&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=561&range=00-01

  Stats: 5499 lines in 171 files changed: 3518 ins; 1019 del; 962 mod
  Patch: https://git.openjdk.java.net/jdk/pull/561.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/561/head:pull/561

PR: https://git.openjdk.java.net/jdk/pull/561

From aph at openjdk.java.net  Fri Oct  9 12:22:15 2020
From: aph at openjdk.java.net (Andrew Haley)
Date: Fri, 9 Oct 2020 12:22:15 GMT
Subject: RFR: 8252204: AArch64: Implement SHA3 accelerator/intrinsic [v5]
In-Reply-To: <nR6wQq3N8OnxHsAdAzQ2mIh6RZQ_b7H_M51Y9Eng3J4=.90d276d3-8b4b-427c-a075-bb7db96e37cb@github.com>
References: <PJVtIubjiGKhCK81PIMhWuYxnR84DNieMDUGHdhHYZM=.ad903c93-c5e3-4614-9af1-d36bc33f735d@github.com>
 <nR6wQq3N8OnxHsAdAzQ2mIh6RZQ_b7H_M51Y9Eng3J4=.90d276d3-8b4b-427c-a075-bb7db96e37cb@github.com>
Message-ID: <A5RkMquxaW1OuuiPTpD1wz7pBMcjxU7roLU5wD3cH8E=.0211f34f-eb8b-4b93-8072-82ac1a894019@github.com>

On Fri, 9 Oct 2020 11:53:31 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Contributed-by: ard.biesheuvel at linaro.org, dongbo4 at huawei.com
>> 
>> This added an intrinsic for SHA3 using aarch64 v8.2 SHA3 Crypto Extensions.
>> Reference implementation for core SHA-3 transform using ARMv8.2 Crypto Extensions:
>> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm64/crypto/sha3-ce-core.S?h=v5.4.52
>> 
>> Trivial adaptation in SHA3. implCompress is needed for the purpose of adding the intrinsic.
>> For SHA3, we need to pass one extra parameter "digestLength" to the stub for the calculation of block size.
>> "digestLength" is also used in for the EOR loop before keccak to differentiate different SHA3 variants.
>> 
>> We added jtreg tests for SHA3 and used QEMU system emulator which supports SHA3 instructions to test the functionality.
>> Patch passed jtreg tier1-3 tests with QEMU system emulator.
>> Also verified with jtreg tier1-3 tests without SHA3 instructions on aarch64-linux-gnu and x86_64-linux-gnu, to make
>> sure that there's no regression.
>> We used one existing JMH test for performance test: test/micro/org/openjdk/bench/java/security/MessageDigests.java
>> We measured the performance benefit with an aarch64 cycle-accurate simulator.
>> Patch delivers 20% - 40% performance improvement depending on specific SHA3 digest length and size of the message.
>> 
>> For now, this feature will not be enabled automatically for aarch64. We can auto-enable this when it is fully tested on
>> real hardware.  But for the above testing purposes, this is auto-enabled when the corresponding hardware feature is
>> detected.
>
> Fei Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains
> six commits:
>  - Merge master
>  - Add sha3 instructions to cpu/aarch64/aarch64-asmtest.py and regenerate the test in assembler_aarch64.cpp:asm_check
>  - Rebase
>  - Merge master
>  - Fix trailing whitespace issue
>  - 8252204: AArch64: Implement SHA3 accelerator/intrinsic
>    Contributed-by: ard.biesheuvel at linaro.org, dongbo4 at huawei.com

Marked as reviewed by aph (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/207

From shade at openjdk.java.net  Fri Oct  9 12:45:15 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 9 Oct 2020 12:45:15 GMT
Subject: RFR: 8254078: DataOutputStream is very slow post-disabling of
 Biased Locking [v2]
In-Reply-To: <DAg8ijfqluhHelYG6Nc6C1yuxI0qZean31YjTzJzAA4=.c1e4290b-9777-435f-84d9-8b24ba5d37b4@github.com>
References: <lLg_yNI_6LvUZTlM4PyN5ra6AaUZZeT35QzYzV_0CpI=.f2d3cb9e-be30-40dc-922c-dad5bef7feea@github.com>
 <Tj_EYEUEPB9fZdspeeU0CtMbmLNhl7S82MNRZIZodXo=.7a17d0a2-ac4d-47f5-98fb-c451afa59374@github.com>
 <DAg8ijfqluhHelYG6Nc6C1yuxI0qZean31YjTzJzAA4=.c1e4290b-9777-435f-84d9-8b24ba5d37b4@github.com>
Message-ID: <ryaNJ3uxulZ5WVjloHUUS__he8RWlSStUX4I-Yo39qU=.5971e78c-719a-44fe-b8c5-a3ad6b4f3a63@github.com>

On Wed, 7 Oct 2020 19:06:16 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8254078: DataOutputStream is very slow post-disabling of Biased Locking
>
> test/micro/org/openjdk/bench/java/io/DataOutputStreamTest.java line 62:
> 
>> 60:
>> 61: @BenchmarkMode(Mode.AverageTime)
>> 62: @OutputTimeUnit(TimeUnit.MICROSECONDS)
> 
> Most JMH tests use NANOSECOND for reporting.

The style rule is to use the units that make numbers look sane: not too large (cluttering the output), not too small
(hiding problems in truncation). From the Andrew's benchmark results above, microseconds is what should be used.

-------------

PR: https://git.openjdk.java.net/jdk/pull/542

From shade at openjdk.java.net  Fri Oct  9 14:20:14 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 9 Oct 2020 14:20:14 GMT
Subject: RFR: 8254078: DataOutputStream is very slow post-disabling of
 Biased Locking [v4]
In-Reply-To: <Gj_g60Z7fHmhYdrpnT2orSadEquafzlbswhNfbOtEf4=.54e3592b-1e86-410d-8a37-9a51337cd0c8@github.com>
References: <lLg_yNI_6LvUZTlM4PyN5ra6AaUZZeT35QzYzV_0CpI=.f2d3cb9e-be30-40dc-922c-dad5bef7feea@github.com>
 <Gj_g60Z7fHmhYdrpnT2orSadEquafzlbswhNfbOtEf4=.54e3592b-1e86-410d-8a37-9a51337cd0c8@github.com>
Message-ID: <kp3-ISdeUaZnvvfIIH9Kf76K8HiLXByGqQqydyWZ8nE=.9e15c45e-7f2a-48f1-9ae2-3b777f825e36@github.com>

On Thu, 8 Oct 2020 09:36:01 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> DataOutputStream is very slow post-disabling of Biased Locking. This
>> was discovered when benchmarking a transaction library, which showed
>> significant performance loss when moving to JDK 15. WIth some small
>> changes to DataOutputStream we can get the performance back. There's a
>> JMH benchmark at
>> http://cr.openjdk.java.net/~aph/JDK-8254078/jmh-tests.tar
>> 
>> Some Stream classes use very fine-grained locking.
>> 
>> In particular, writeInt is defined like this:
>> 
>>         out.write((v >>> 24) & 0xFF);
>>         out.write((v >>> 16) & 0xFF);
>>         out.write((v >>> 8) & 0xFF);
>>         out.write((v >>> 0) & 0xFF);
>>         incCount(4);
>> 
>> Unfortunately, ByteArrayOutputStream.write(byte) is defined like this:
>> 
>>     public synchronized void write(int b) {
>>         ensureCapacity(count + 1);
>>         buf[count] = (byte) b;
>>         count += 1;
>>     }
>> 
>> so we acquire and release a lock for every byte that is output.
>> 
>>  For example, writing 4kb of ints goes from 17.3 us/op to 53.9 us/op when biased locking is disabled:
>> 
>> 
>> +UseBiasedLocking DataOutputStreamTest.dataOutputStreamOverByteArray avgt 6 53.895 ? 5.126 us/op
>> -UseBiasedLocking DataOutputStreamTest.dataOutputStreamOverByteArray avgt 6 17.291 ? 4.430 us/op
>> 
>> There are refactorings of DataOutputStream we can do to mitigate this.
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8254078: DataOutputStream is very slow post-disabling of Biased Locking

I have comments about the benchmark code style :)

test/micro/org/openjdk/bench/java/io/DataOutputStreamTest.java line 41:

> 39:
> 40:     @State(Scope.Benchmark)
> 41:     public static class BenchmarkState {

You don't need a separate nested class to carry `@State`, AFAICS. Move everything to `DataOutputStreamTest` body, and
put the `@State` annotation near other class annotations (`@Warmup` and friends).

test/micro/org/openjdk/bench/java/io/DataOutputStreamTest.java line 43:

> 41:     public static class BenchmarkState {
> 42:         @Param({"4096"}) int SIZE;
> 43:         @Param({"char", "short", "int", /*"string"*/}) String BASIC_TYPE;

- Do we use `"string"` case or not?
- Java style: all caps are reserved for `static final` fields, these should be `size` and `basicType`
- JMH supports `@Param` over `Enum`-s, so this `String` dance does not seem necessary.

test/micro/org/openjdk/bench/java/io/DataOutputStreamTest.java line 66:

> 64:                 };
> 65:                 outputString = new String(new byte[SIZE]);
> 66:             } catch (Exception e) {

`@Setup` is allowed to declare `throws Exception`, which would allow removing this `try-catch` block.

test/micro/org/openjdk/bench/java/io/DataOutputStreamTest.java line 117:

> 115:             case STRING: writeString(state, dataOutput); break;
> 116:         }
> 117:     }

So, the way I see it, this can be replaced by:

    public void write(DataOutput dataOutput) {
        switch (basicType) {
            case CHAR:
                for (int i = 0; i < SIZE; i += 2) {
                    dataOutput.writeChar(i);
                }
                break;
            case SHORT:
                for (int i = 0; i < SIZE; i += 2) {
                    dataOutput.writeShort(i);
                }
                break;
            case INT:
                for (int i = 0; i < SIZE; i += 4) {
                    dataOutput.writeInt(i);
                }
                break;
            case STRING:
                dataOutput.writeChars(state.outputString);
                break;
        }
    }

...thus keeping all the code in one place, and simplifying the benchmark.

-------------

Changes requested by shade (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/542

From iignatyev at openjdk.java.net  Fri Oct  9 14:35:15 2020
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Fri, 9 Oct 2020 14:35:15 GMT
Subject: RFR: 8229186: Improve error messages for TestStringIntrinsics
 failures [v12]
In-Reply-To: <B7QRwqAtrM8tf4ACnP7ycNDyh9-2h9Kju40BCHfu2ns=.e3421336-e8fa-41d3-802b-54683804f394@github.com>
References: <Br6z5yt0kTbZwIQyTI9lz7czaYpjw5vCd5ZCbbrSIcM=.6a8096f1-91ed-4673-bab3-3bfae758ab95@github.com>
 <B7QRwqAtrM8tf4ACnP7ycNDyh9-2h9Kju40BCHfu2ns=.e3421336-e8fa-41d3-802b-54683804f394@github.com>
Message-ID: <UEJWxBnpzhAPUY3GYHCLgTKUAXv0_-sDWU2ezU3CeMQ=.ada12f53-c070-409b-98ff-63cadeb1a416@github.com>

On Fri, 9 Oct 2020 08:00:52 GMT, Evgeny Nikitin <enikitin at openjdk.org> wrote:

>> pre-Skara RFR thread: [link](https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-May/038416.html)
>> 
>> Error reporting was improved by writing a C-style escaped string representations for the variables passed to the
>> methods being tested. For array comparisons, a dedicated diff-formatter was implemented.
>> Sample output for comparing byte arrays (with artificial failure):
>>  ----------System.err:(21/1553)----------
>>  Result: (false) of 'arrayEqualsB' is not equal to expected (true)
>>  Arrays differ starting from [index: 7]:
>>  ... 5, 6,   7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, ...
>>  ... 5, 6, 125, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, ...
>>            ^^^^
>>  java.lang.RuntimeException: Result: (false) of 'arrayEqualsB' is not
>>  equal to expected (true)
>>           at
>>  compiler.intrinsics.string.TestStringIntrinsics.invokeAndCheckArrays(TestStringIntrinsics.java:273)
>>            at ... stack trace continues - E.N.
>>  Sample output for comparing char arrays:
>>  ----------System.err:(21/1579)*----------
>>  Result: (false) of 'arrayEqualsC' is not equal to expected (true)
>>  Arrays differ starting from [index: 7]:
>>  ... \\u0005, \\u0006, \\u0007, \\u0008, \\u0009, \\n, ...
>>  ... \\u0005, \\u0006,      }, \\u0008, \\u0009, \\n, ...
>>                      ^^^^^^^
>>  java.lang.RuntimeException: Result: (false) of 'arrayEqualsC' is not
>>  equal to expected (true)
>>           at
>>  compiler.intrinsics.string.TestStringIntrinsics.invokeAndCheckArrays(TestStringIntrinsics.java:280)
>>            at
>>  ... and so on - E.N.
>> 
>> testing: open/test/hotspot/jtreg/compiler/intrinsics/string/TestStringIntrinsics.java on linux, windows, macosx.
>
> Evgeny Nikitin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix ArrayCodec's behaviour for preffix and identical arrays

Marked as reviewed by iignatyev (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/112

From iignatyev at openjdk.java.net  Fri Oct  9 14:38:20 2020
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Fri, 9 Oct 2020 14:38:20 GMT
Subject: RFR: 8254261: fix javadocs in jdk.test.lib.Utils
Message-ID: <_Kpcz6grFPqls7ipSE78giOf1U_LuZRD4mdBCPFDinc=.9f5c565b-e7f3-4be0-a1a0-923ed07ed3e1@github.com>

Hi all,

could you please review this trivial fix of javadocs in `jdk.test.lib.Utils`?

-- Igor

-------------

Commit messages:
 - 8254261: fix javadocs in jdk.test.lib.Utils

Changes: https://git.openjdk.java.net/jdk/pull/566/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=566&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8254261
  Stats: 27 lines in 1 file changed: 4 ins; 2 del; 21 mod
  Patch: https://git.openjdk.java.net/jdk/pull/566.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/566/head:pull/566

PR: https://git.openjdk.java.net/jdk/pull/566

From shade at openjdk.java.net  Fri Oct  9 14:43:14 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 9 Oct 2020 14:43:14 GMT
Subject: RFR: 8254261: fix javadocs in jdk.test.lib.Utils
In-Reply-To: <_Kpcz6grFPqls7ipSE78giOf1U_LuZRD4mdBCPFDinc=.9f5c565b-e7f3-4be0-a1a0-923ed07ed3e1@github.com>
References: <_Kpcz6grFPqls7ipSE78giOf1U_LuZRD4mdBCPFDinc=.9f5c565b-e7f3-4be0-a1a0-923ed07ed3e1@github.com>
Message-ID: <LZULi0NUDiid9Ue7NDqvFV-xUzk9FU4ZyMD-X0vhgXw=.974bb5ee-6dc2-4b11-95a3-58596e8d8932@github.com>

On Thu, 8 Oct 2020 18:27:16 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this trivial fix of javadocs in `jdk.test.lib.Utils`?
> 
> -- Igor

Looks fine to me.

-------------

Marked as reviewed by shade (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/566

From iignatyev at openjdk.java.net  Fri Oct  9 14:50:13 2020
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Fri, 9 Oct 2020 14:50:13 GMT
Subject: RFR: 8254261: fix javadocs in jdk.test.lib.Utils
In-Reply-To: <LZULi0NUDiid9Ue7NDqvFV-xUzk9FU4ZyMD-X0vhgXw=.974bb5ee-6dc2-4b11-95a3-58596e8d8932@github.com>
References: <_Kpcz6grFPqls7ipSE78giOf1U_LuZRD4mdBCPFDinc=.9f5c565b-e7f3-4be0-a1a0-923ed07ed3e1@github.com>
 <LZULi0NUDiid9Ue7NDqvFV-xUzk9FU4ZyMD-X0vhgXw=.974bb5ee-6dc2-4b11-95a3-58596e8d8932@github.com>
Message-ID: <LhUi_I40eNZJKqvR191s3FApWru5jaxQ1EbDA4Es2-E=.8af0898d-06f2-474a-bead-43dca35abf15@github.com>

On Fri, 9 Oct 2020 14:40:41 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Hi all,
>> 
>> could you please review this trivial fix of javadocs in `jdk.test.lib.Utils`?
>> 
>> -- Igor
>
> Looks fine to me.

Thanks Aleksey.

-------------

PR: https://git.openjdk.java.net/jdk/pull/566

From iignatyev at openjdk.java.net  Fri Oct  9 14:50:14 2020
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Fri, 9 Oct 2020 14:50:14 GMT
Subject: Integrated: 8254261: fix javadocs in jdk.test.lib.Utils
In-Reply-To: <_Kpcz6grFPqls7ipSE78giOf1U_LuZRD4mdBCPFDinc=.9f5c565b-e7f3-4be0-a1a0-923ed07ed3e1@github.com>
References: <_Kpcz6grFPqls7ipSE78giOf1U_LuZRD4mdBCPFDinc=.9f5c565b-e7f3-4be0-a1a0-923ed07ed3e1@github.com>
Message-ID: <VN40UGPDDVRgpT2AIqKmUm3Ig_83i9c98zXQZyFRxJA=.33ed9bb2-c94f-4c08-b12d-4c05b2d5933b@github.com>

On Thu, 8 Oct 2020 18:27:16 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this trivial fix of javadocs in `jdk.test.lib.Utils`?
> 
> -- Igor

This pull request has now been integrated.

Changeset: 7e80c989
Author:    Igor Ignatyev <iignatyev at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/7e80c989
Stats:     27 lines in 1 file changed: 4 ins; 2 del; 21 mod

8254261: fix javadocs in jdk.test.lib.Utils

Reviewed-by: shade

-------------

PR: https://git.openjdk.java.net/jdk/pull/566

From psandoz at openjdk.java.net  Fri Oct  9 15:26:11 2020
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Fri, 9 Oct 2020 15:26:11 GMT
Subject: RFR: 8254162: Implementation of Foreign-Memory Access API (Third
 Incubator) [v5]
In-Reply-To: <AxWYajmJjEPIcO9sf_JL92HEAu9p91UdTSyrOH4lj-o=.bdbe2d46-4148-4869-bbe2-c95c89042ce1@github.com>
References: <IngRk57F78UN3yySfo6IABbdwnMogGNdYrykh_3em-c=.b81f7478-015c-45ed-9788-58d7519a2770@github.com>
 <AxWYajmJjEPIcO9sf_JL92HEAu9p91UdTSyrOH4lj-o=.bdbe2d46-4148-4869-bbe2-c95c89042ce1@github.com>
Message-ID: <mNiSX-sOW-zFGAYMseidB03GBe3T_CtgWgj1IJJuW6A=.1691fe51-87a2-4f32-ad8a-f8617abaded6@github.com>

On Fri, 9 Oct 2020 11:34:56 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This patch contains the changes associated with the third incubation round of the foreign memory access API incubation
>> (see JEP 393 [1]). This iteration focus on improving the usability of the API in 3 main ways:
>> * first, by providing a way to obtain truly *shared* segments, which can be accessed and closed concurrently from
>>   multiple threads
>> * second, by providing a way to register a memory segment against a `Cleaner`, so as to have some (optional) guarantee
>>   that the memory will be deallocated, eventually
>> * third, by not requiring users to dive deep into var handles when they first pick up the API; a new `MemoryAccess` class
>>   has been added, which defines several useful dereference routines; these are really just thin wrappers around memory
>>   access var handles, but they make the barrier of entry for using this API somewhat lower.
>> 
>> A big conceptual shift that comes with this API refresh is that the role of `MemorySegment` and `MemoryAddress` is not
>> the same as it used to be; it used to be the case that a memory address could (sometimes, not always) have a back link
>> to the memory segment which originated it; additionally, memory access var handles used `MemoryAddress` as a basic unit
>> of dereference.  This has all changed as per this API refresh;  now a `MemoryAddress` is just a dumb carrier which
>> wraps a pair of object/long addressing coordinates; `MemorySegment` has become the star of the show, as far as
>> dereferencing memory is concerned. You cannot dereference memory if you don't have a segment. This improves usability
>> in a number of ways - first, it is a lot easier to wrap native addresses (`long`, essentially) into a `MemoryAddress`;
>> secondly, it is crystal clear what a client has to do in order to dereference memory: if a client has a segment, it can
>> use that; otherwise, if the client only has an address, it will have to create a segment *unsafely* (this can be done
>> by calling `MemoryAddress::asSegmentRestricted`).  A list of the API, implementation and test changes is provided
>> below. If  you have any questions, or need more detailed explanations, I (and the  rest of the Panama team) will be
>> happy to point at existing discussions,  and/or to provide the feedback required.   A big thank to Erik Osterlund,
>> Vladimir Ivanov and David Holmes, without whom the work on shared memory segment would not have been possible; also I'd
>> like to thank Paul Sandoz, whose insights on API design have been very helpful in this journey.  Thanks  Maurizio
>> Javadoc:   http://cr.openjdk.java.net/~mcimadamore/8254162_v1/javadoc/jdk/incubator/foreign/package-summary.html
>> Specdiff:
>> 
>> http://cr.openjdk.java.net/~mcimadamore/8254162_v1/specdiff/jdk/incubator/foreign/package-summary.html
>> 
>> CSR:
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8254163
>> 
>> 
>> 
>> ### API Changes
>> 
>> * `MemorySegment`
>>   * drop factory for restricted segment (this has been moved to `MemoryAddress`, see below)
>>   * added a no-arg factory for a native restricted segment representing entire native heap
>>   * rename `withOwnerThread` to `handoff`
>>   * add new `share` method, to create shared segments
>>   * add new `registerCleaner` method, to register a segment against a cleaner
>>   * add more helpers to create arrays from a segment e.g. `toIntArray`
>>   * add some `asSlice` overloads (to make up for the fact that now segments are more frequently used as cursors)
>>   * rename `baseAddress` to `address` (so that `MemorySegment` can implement `Addressable`)
>> * `MemoryAddress`
>>   * drop `segment` accessor
>>   * drop `rebase` method and replace it with `segmentOffset` which returns the offset (a `long`) of this address relative
>>     to a given segment
>> * `MemoryAccess`
>>   * New class supporting several static dereference helpers; the helpers are organized by carrier and access mode, where a
>>     carrier is one of the usual suspect (a Java primitive, minus `boolean`); the access mode can be simple (e.g. access
>>     base address of given segment), or indexed, in which case the accessor takes a segment and either a low-level byte
>>     offset,or a high level logical index. The classification is reflected in the naming scheme (e.g. `getByte` vs.
>>     `getByteAtOffset` vs `getByteAtIndex`).
>> * `MemoryHandles`
>>   * drop `withOffset` combinator
>>   * drop `withStride` combinator
>>   * the basic memory access handle factory now returns a var handle which takes a `MemorySegment` and a `long` - from which
>>     it is easy to derive all the other handles using plain var handle combinators.
>> * `Addressable`
>>   * This is a new interface which is attached to entities which can be projected to a `MemoryAddress`. For now, both
>>     `MemoryAddress` and `MemorySegment` implement it; we have plans, with JEP 389 [2] to add more implementations. Clients
>>     can largely ignore this interface, which comes in really handy when defining native bindings with tools like `jextract`.
>> * `MemoryLayouts`
>>   * A new layout, for machine addresses, has been added to the mix.
>> 
>> 
>> 
>> ### Implementation changes
>> 
>> There are two main things to discuss here: support for shared segments, and the general simplification of the memory
>> access var handle support.
>> #### Shared segments
>> 
>> The support for shared segments cuts in pretty deep in the VM. Support for shared segments is notoriously hard to
>> achieve, at least in a way that guarantees optimal access performances. This is caused by the fact that, if a segment
>> is shared, it would be possible for a thread to close it while another is accessing it.  After considering several
>> options (see [3]), we zeroed onto an approach which is inspired by an happy idea that Andrew Haley had (and that he
>> reminded me of at this year OpenJDK committer workshop - thanks!). The idea is that if we could *freeze* the world
>> (e.g. with a GC pause), while a segment is closed, we could then prevent segments from being accessed concurrently to a
>> close operation. For this to work, it  is crucial that no GC safepoints can occur between a segment liveness check and
>> the access itself (otherwise it would be possible for the accessing thread to stop just right before an unsafe call).
>> It also relies on the fact that hotspot/C2 should not be able to propagate loads across safepoints.  Sadly, none of
>> these conditions seems to be valid in the current implementation, so we needed to resort to a bit of creativity. First,
>> we noted that, if we could mark so called *scoped* method with an annotation, it would be very simply to check as to
>> whether a thread was in the middle of a scoped method when we stopped the world for a close operation (btw, instead of
>> stopping the world, we do a much more efficient, thread-local polling, thanks to JEP 312 [4]).  The question is, then,
>> once we detect that a thread is accessing the very segment we're about to close, what should happen? We first
>> experimented with a solution which would install an *asynchronous* exception on the accessing thread, thus making it
>> fail. This solution has some desirable properties, in that a `close` operation always succeeds. Unfortunately the
>> machinery for async exceptions is a bit fragile (e.g. not all the code in hotspot checks for async exceptions); to
>> minimize risks, we decided to revert to a simpler strategy, where `close` might fail when it finds that another thread
>> is accessing the segment being closed.  As written in the javadoc, this doesn't mean that clients should just catch and
>> try again; an exception on `close` is a bug in the user code, likely arising from lack of synchronization, and should
>> be treated as such.  In terms of gritty implementation, we needed to centralize memory access routines in a single
>> place, so that we could have a set of routines closely mimicking the primitives exposed by `Unsafe` but which, in
>> addition, also provided a liveness check. This way we could mark all these routines with the special `@Scoped`
>> annotation, which tells the VM that something important is going on.  To achieve this, we created a new (autogenerated)
>> class, called `ScopedMemoryAccess`. This class contains all the main memory access primitives (including bulk access,
>> like `copyMemory`, or `setMemory`), and accepts, in addition to the access coordinates, also a scope object, which is
>> tested before access. A reachability fence is also thrown in the mix to make sure that the scope is kept alive during
>> access (which is important when registering segments against cleaners).  Of course, to make memory access safe, memory
>> access var handles, byte buffer var handles, and byte buffer API should use the new `ScopedMemoryAccess` class instead
>> of unsafe, so that a liveness check can be triggered (in case a scope is present).  `ScopedMemoryAccess` has a
>> `closeScope` method, which initiates the thread-local handshakes, and returns `true` if the handshake completed
>> successfully.  The implementation of `MemoryScope` (now significantly simplified from what we had before), has two
>> implementations, one for confined segments and one for shared segments; the main difference between the two is what
>> happens when the scope is closed; a confined segment sets a boolean flag to false, and returns, whereas a shared
>> segment goes into a `CLOSING` state, then starts the handshake, and then updates the state again, to either `CLOSED` or
>> `ALIVE` depending on whether the handshake was successful or not. Note that when a shared segment is in the `CLOSING`
>> state, `MemorySegment::isAlive` will still return `true`, while the liveness check upon memory access will fail.  ####
>> Memory access var handles overhaul  The key realization here was that if all memory access var handles took a
>> coordinate pair of `MemorySegment` and `long`, all other access types could be derived from this basic var handle
>> form.  This allowed us to remove the on-the-fly var handle generation, and to simply derive structural access var
>> handles (such as those obtained by calling `MemoryLayout::varHandle`) using *plain* var handle combinators, so that
>> e.g. additional offset is injected into a base memory access var handle.  This also helped in simplifying the
>> implementation by removing the special `withStride` and `withOffset` combinators, which previously needed low-level
>> access on the innards of the memory access var handle. All that code is now gone.  #### Test changes  Not much to see
>> here - most of the tests needed to be updated because of the API changes. Some were beefed up (like the array test,
>> since now segments can be projected into many different kinds of arrays). A test has been added to test the `Cleaner`
>> functionality, and another stress test has been added for shared segments (`TestHandshake`). Some of the
>> microbenchmarks also needed some tweaks - and some of them were also updated to also test performance in the shared
>> segment case.  [1] - https://openjdk.java.net/jeps/393 [2] - https://openjdk.java.net/jeps/389 [3] -
>> https://mail.openjdk.java.net/pipermail/panama-dev/2020-May/009004.html [4] - https://openjdk.java.net/jeps/312
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix performance issue with "small" segment mismatch

src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/Utils.java line 76:

> 74:         // This adaptation is required, otherwise the memory access var handle will have type MemoryAddressProxy,
> 75:         // and not MemoryAddress (which the user expects), which causes performance issues with asType()
> adaptations. 76:         return MemoryHandles.filterCoordinates(handle, 0, ADDRESS_FILTER);

The above comment needs updating to refer to `MemorySegmentProxy` and `MemorySegment`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/548

From sgehwolf at redhat.com  Fri Oct  9 16:18:02 2020
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Fri, 09 Oct 2020 18:18:02 +0200
Subject: [11u] RFR: 8250984: Memory Docker tests fail on some Linux kernels
 w/o cgroupv1 swap limit capabilities
Message-ID: <6ee2cb0b8081e95781d324876dc0370405cc8171.camel@redhat.com>

Hi,

Please review this backport for Oracle 11.0.10 parity. The jdk-jdk
patch needs to be significantly reworked since JDK 15+ has the cgroups
v2 patches. The gist of the change is to only report memory values if
swap accounting is disabled on the system (i.e. no swap memory) for
metrics which would otherwise report values for memory + swap.

Here is the list of changes I've done as compared to the JDK 16 patch:

 * Drop ProblemList.txt hunks. The test was not problem-listed in
   OpenJDK 11u. It's not applicable.
 * Dropped hunk in test/hotspot/jtreg/containers/cgroup/PlainRead.java,
   which also is not applicable (cgroups v2 and later refactorings
   related).
 * Moved changes from?CgroupV1Subsystem.java to?cgroupv1/Metrics.java
   class. That's where the code lived prior the cgroups v2 addition.
 * Moved code changes from?CgroupV1MemorySubSystemController.java to
   MemorySubsystem in?SubSystem.java
 * test/hotspot/jtreg/containers/docker/TestMemoryAwareness.java
   adjusted since?JDK-8226575 for JDK 11 was different to JDK 15 (no
   new methods)
 * MetricsMemoryTester.java the code is again different in JDK 15+
   because of JDK-8231111. But the changes for this bug only move it
   into a conditional testing whether swap is enabled and only test if
   it is.
 * MetricsTesterCgroupV1 => MetricsTester

Bug: https://bugs.openjdk.java.net/browse/JDK-8250984
webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8250984/01/webrev/

Testing: Container tests on a system with swapaccount=0 and on a system
with it enabled on Linux x86_64. Tests mentioned in the bug failed
before, pass after.

Thoughts?

Thanks,
Severin


From sgehwolf at openjdk.java.net  Fri Oct  9 16:29:18 2020
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Fri, 9 Oct 2020 16:29:18 GMT
Subject: Integrated: 8245543: Cgroups: Incorrect detection logic on some
 systems (still reproducible)
In-Reply-To: <CWATRi437QpkCA1sx-EsHFqVlSCV-G8EgkEoGdJgPHc=.a743be7e-8a00-4d91-866d-86ccf3fe714f@github.com>
References: <CWATRi437QpkCA1sx-EsHFqVlSCV-G8EgkEoGdJgPHc=.a743be7e-8a00-4d91-866d-86ccf3fe714f@github.com>
Message-ID: <aR5x63YzY7l6QOErLsi0j7c1yqAUPhXRzCRd-kb4xjw=.bdf32bf9-edb9-4890-b4a1-3abd3b61d81c@github.com>

On Fri, 2 Oct 2020 16:34:49 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> An issue similar to [JDK-8239559](https://bugs.openjdk.java.net/browse/JDK-8239559) has been discovered. On the
> affected system, `/proc/self/mountinfo` contains a line such as this one:
> 
> 35 26 0:26 / /sys/fs/cgroup/systemd rw,nosuid,nodev,noexec,relatime - cgroup systemd rw,name=systemd
>  
> 
> Note that `/proc/cgroups` looks like this:
> 
> #subsys_name	hierarchy	num_cgroups	enabled
> cpuset	0	1	1
> cpu	0	1	1
> cpuacct	0	1	1
> blkio	0	1	1
> memory	0	1	1
> devices	0	1	1
> freezer	0	1	1
> net_cls	0	1	1
> perf_event	0	1	1
> net_prio	0	1	1
> hugetlb	0	1	1
> pids	0	1	1
> 
> This is in fact a cgroups v1 system with systemd put into a separate namespace via FS type `cgroup`. That mountinfo
> line confuses the cgroups version detection heuristic. It only looked whether or not there is **any** entry in
> mountinfo of FS-type `cgroup` . That's wrong. A better heuristic would be looking at controllers we care about: `cpu`,
> `cpuacct`, `memory`, `cpuset` for hotspot and some more for the Java side. The proposed fix on the hotspot side is to
> set `any_cgroup_mounts_found` to true only if one of those controllers show up in mountinfo. Otherwise, we know it's
> cgroup v2 due to the zero hierarchy ids. The fix on the Java side is similar.  For the Java side the proposal is also
> to do the parsing of the cgroup files in the factory now (single pass of files). No longer in the version specific
> objects. In order to not regress here, I've added more tests.
> **Testing**
> 
>  - [x] Linux x86_64 container tests on cgroup v1 (fastdebug)
>  - [x] Linux x86_64 container tests on cgroup v2 (fastdebug)
>  - [x] Added regression test which fails prior the patch and passes after
>  - [x] Submit testing

This pull request has now been integrated.

Changeset: 2bbf8a2a
Author:    Severin Gehwolf <sgehwolf at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/2bbf8a2a
Stats:     97 lines in 4 files changed: 91 ins; 1 del; 5 mod

8245543: Cgroups: Incorrect detection logic on some systems (still reproducible)

Reviewed-by: bobv, shade

-------------

PR: https://git.openjdk.java.net/jdk/pull/485

From sgehwolf at openjdk.java.net  Fri Oct  9 16:29:18 2020
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Fri, 9 Oct 2020 16:29:18 GMT
Subject: RFR: 8245543: Cgroups: Incorrect detection logic on some systems
 (still reproducible) [v8]
In-Reply-To: <CWATRi437QpkCA1sx-EsHFqVlSCV-G8EgkEoGdJgPHc=.a743be7e-8a00-4d91-866d-86ccf3fe714f@github.com>
References: <CWATRi437QpkCA1sx-EsHFqVlSCV-G8EgkEoGdJgPHc=.a743be7e-8a00-4d91-866d-86ccf3fe714f@github.com>
Message-ID: <_DreJpVrpxOcrH7gxEJKUJDhl4j1QEfaTsSSwzb2AyY=.a3befe30-3cf2-44a6-b86e-ebf108988651@github.com>

> An issue similar to [JDK-8239559](https://bugs.openjdk.java.net/browse/JDK-8239559) has been discovered. On the
> affected system, `/proc/self/mountinfo` contains a line such as this one:
> 
> 35 26 0:26 / /sys/fs/cgroup/systemd rw,nosuid,nodev,noexec,relatime - cgroup systemd rw,name=systemd
>  
> 
> Note that `/proc/cgroups` looks like this:
> 
> #subsys_name	hierarchy	num_cgroups	enabled
> cpuset	0	1	1
> cpu	0	1	1
> cpuacct	0	1	1
> blkio	0	1	1
> memory	0	1	1
> devices	0	1	1
> freezer	0	1	1
> net_cls	0	1	1
> perf_event	0	1	1
> net_prio	0	1	1
> hugetlb	0	1	1
> pids	0	1	1
> 
> This is in fact a cgroups v1 system with systemd put into a separate namespace via FS type `cgroup`. That mountinfo
> line confuses the cgroups version detection heuristic. It only looked whether or not there is **any** entry in
> mountinfo of FS-type `cgroup` . That's wrong. A better heuristic would be looking at controllers we care about: `cpu`,
> `cpuacct`, `memory`, `cpuset` for hotspot and some more for the Java side. The proposed fix on the hotspot side is to
> set `any_cgroup_mounts_found` to true only if one of those controllers show up in mountinfo. Otherwise, we know it's
> cgroup v2 due to the zero hierarchy ids. The fix on the Java side is similar.  For the Java side the proposal is also
> to do the parsing of the cgroup files in the factory now (single pass of files). No longer in the version specific
> objects. In order to not regress here, I've added more tests.
> **Testing**
> 
>  - [x] Linux x86_64 container tests on cgroup v1 (fastdebug)
>  - [x] Linux x86_64 container tests on cgroup v2 (fastdebug)
>  - [x] Added regression test which fails prior the patch and passes after
>  - [x] Submit testing

Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now
contains one commit:

  8245543: Cgroups: Incorrect detection logic on some systems (still reproducible)

-------------

Changes: https://git.openjdk.java.net/jdk/pull/485/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=485&range=07
  Stats: 97 lines in 4 files changed: 91 ins; 1 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/485.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/485/head:pull/485

PR: https://git.openjdk.java.net/jdk/pull/485

From rriggs at openjdk.java.net  Fri Oct  9 16:44:12 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 9 Oct 2020 16:44:12 GMT
Subject: RFR: 8254234 - Add test library stream object builder [v2]
In-Reply-To: <unfBDqc8gA3agPjzEmsP5GytTr1TwLYTYCfDbqVG0xM=.08f35f8b-3c8a-4f86-bb60-be59a0c242ff@github.com>
References: <YG2nA5Bzj8YkrGnsdqFnHKGl_XugrwvFX3hoGjdgo_s=.3f19ec15-fa71-4f89-bf86-59287671ffca@github.com>
 <unfBDqc8gA3agPjzEmsP5GytTr1TwLYTYCfDbqVG0xM=.08f35f8b-3c8a-4f86-bb60-be59a0c242ff@github.com>
Message-ID: <EugwoSWQwSYmkrO0sCrxnWDrQ4dL1VZyaLHboYIk9Yo=.0ffa24b2-8681-482b-8379-d8d3a3f59528@github.com>

On Fri, 9 Oct 2020 12:19:30 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

>> It is useful to have a test library facility for building stream objects, suitable for deserialization testing. We
>> already have a partial implementation in one of the record serialization tests, move it to the test library for more
>> general use. The implementation remains partial, but can be expanded as and when needed.
>
> Chris Hegarty has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev
> excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since
> the last revision:
>  - Merge branch 'master' into serial-byte-stream-builder
>  - apply review comments
>  - Initial changes for 8254234 - Add test library stream object builder

Thanks for the updates.

-------------

Marked as reviewed by rriggs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/561

From enikitin at openjdk.java.net  Fri Oct  9 16:52:18 2020
From: enikitin at openjdk.java.net (Evgeny Nikitin)
Date: Fri, 9 Oct 2020 16:52:18 GMT
Subject: Integrated: 8229186: Improve error messages for TestStringIntrinsics
 failures
In-Reply-To: <Br6z5yt0kTbZwIQyTI9lz7czaYpjw5vCd5ZCbbrSIcM=.6a8096f1-91ed-4673-bab3-3bfae758ab95@github.com>
References: <Br6z5yt0kTbZwIQyTI9lz7czaYpjw5vCd5ZCbbrSIcM=.6a8096f1-91ed-4673-bab3-3bfae758ab95@github.com>
Message-ID: <UKryENF_GYgbIL_pMHwO6YJCJxKVYKZ_r4aS-Um8i0k=.191b6a88-6335-4826-9b35-4b0ce8bbdc19@github.com>

On Thu, 10 Sep 2020 12:20:05 GMT, Evgeny Nikitin <enikitin at openjdk.org> wrote:

> pre-Skara RFR thread: [link](https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-May/038416.html)
> 
> Error reporting was improved by writing a C-style escaped string representations for the variables passed to the
> methods being tested. For array comparisons, a dedicated diff-formatter was implemented.
> Sample output for comparing byte arrays (with artificial failure):
>  ----------System.err:(21/1553)----------
>  Result: (false) of 'arrayEqualsB' is not equal to expected (true)
>  Arrays differ starting from [index: 7]:
>  ... 5, 6,   7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, ...
>  ... 5, 6, 125, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, ...
>            ^^^^
>  java.lang.RuntimeException: Result: (false) of 'arrayEqualsB' is not
>  equal to expected (true)
>           at
>  compiler.intrinsics.string.TestStringIntrinsics.invokeAndCheckArrays(TestStringIntrinsics.java:273)
>            at ... stack trace continues - E.N.
>  Sample output for comparing char arrays:
>  ----------System.err:(21/1579)*----------
>  Result: (false) of 'arrayEqualsC' is not equal to expected (true)
>  Arrays differ starting from [index: 7]:
>  ... \\u0005, \\u0006, \\u0007, \\u0008, \\u0009, \\n, ...
>  ... \\u0005, \\u0006,      }, \\u0008, \\u0009, \\n, ...
>                      ^^^^^^^
>  java.lang.RuntimeException: Result: (false) of 'arrayEqualsC' is not
>  equal to expected (true)
>           at
>  compiler.intrinsics.string.TestStringIntrinsics.invokeAndCheckArrays(TestStringIntrinsics.java:280)
>            at
>  ... and so on - E.N.
> 
> testing: open/test/hotspot/jtreg/compiler/intrinsics/string/TestStringIntrinsics.java on linux, windows, macosx.

This pull request has now been integrated.

Changeset: 52e45a36
Author:    Evgeny Nikitin <enikitin at openjdk.org>
Committer: Igor Ignatyev <iignatyev at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/52e45a36
Stats:     1191 lines in 6 files changed: 1177 ins; 1 del; 13 mod

8229186: Improve error messages for TestStringIntrinsics failures

Reviewed-by: iignatyev, lmesnik

-------------

PR: https://git.openjdk.java.net/jdk/pull/112

From kizune at openjdk.java.net  Fri Oct  9 16:56:17 2020
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Fri, 9 Oct 2020 16:56:17 GMT
Subject: RFR: 8253379: [windows] Several jpackage tests failed with error
 code 1638 [v3]
In-Reply-To: <p_OjRcLzDzBVDoQeNkQeS6T2KHzt3CN34Dz8caoxx84=.8d0722fd-0215-4d46-8f0a-b62d48335b01@github.com>
References: <LpRaGB39y6sd9g4cO4JZRPWsYl0oUtSO0l6Smv2xgbo=.992f6c8e-c478-4c3c-bf1e-5f43191336cd@github.com>
 <p_OjRcLzDzBVDoQeNkQeS6T2KHzt3CN34Dz8caoxx84=.8d0722fd-0215-4d46-8f0a-b62d48335b01@github.com>
Message-ID: <fyTNJ0Hev3nbmIFkaDZAoDhdXuHdGdZRDjcUgw9I9xA=.94c96a25-534d-4365-b2cd-ad1a25ae82df@github.com>

On Wed, 7 Oct 2020 15:08:31 GMT, Andy Herrick <herrick at openjdk.org> wrote:

>> 8253379: [windows] Several jpackage tests failed with error code 1638
>> two windows specific test fixes in WindowsHelper:
>> 1.) do not test that the parent directory of a windows menu shortcut is empty after shortcut is uninstalled (there may
>> be other shortcuts using that directory) 2.) do not programmatically install windows exe installers (since we have no
>> way of programmatically uninstalling them)
>
> Andy Herrick has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8253379: [windows] Several jpackage tests failed with error code 1638

Marked as reviewed by kizune (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/337

From aph at openjdk.java.net  Fri Oct  9 17:38:16 2020
From: aph at openjdk.java.net (Andrew Haley)
Date: Fri, 9 Oct 2020 17:38:16 GMT
Subject: RFR: 8252204: AArch64: Implement SHA3 accelerator/intrinsic [v5]
In-Reply-To: <A5RkMquxaW1OuuiPTpD1wz7pBMcjxU7roLU5wD3cH8E=.0211f34f-eb8b-4b93-8072-82ac1a894019@github.com>
References: <PJVtIubjiGKhCK81PIMhWuYxnR84DNieMDUGHdhHYZM=.ad903c93-c5e3-4614-9af1-d36bc33f735d@github.com>
 <nR6wQq3N8OnxHsAdAzQ2mIh6RZQ_b7H_M51Y9Eng3J4=.90d276d3-8b4b-427c-a075-bb7db96e37cb@github.com>
 <A5RkMquxaW1OuuiPTpD1wz7pBMcjxU7roLU5wD3cH8E=.0211f34f-eb8b-4b93-8072-82ac1a894019@github.com>
Message-ID: <4NM17B6l4GvNgCbmmQTUcnfZTA6G-IEc85O8jH_q-xA=.63b10da7-bab7-44bc-a4c8-0a675aca45c0@github.com>

On Fri, 9 Oct 2020 12:18:58 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Fei Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains
>> six commits:
>>  - Merge master
>>  - Add sha3 instructions to cpu/aarch64/aarch64-asmtest.py and regenerate the test in assembler_aarch64.cpp:asm_check
>>  - Rebase
>>  - Merge master
>>  - Fix trailing whitespace issue
>>  - 8252204: AArch64: Implement SHA3 accelerator/intrinsic
>>    Contributed-by: ard.biesheuvel at linaro.org, dongbo4 at huawei.com
>
> Marked as reviewed by aph (Reviewer).

I see Linux x64 failed. However, I don't seem to be able to withdraw my patch approval.
However, please consider it withdrawn.

-------------

PR: https://git.openjdk.java.net/jdk/pull/207

From kvn at openjdk.java.net  Fri Oct  9 17:59:12 2020
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 9 Oct 2020 17:59:12 GMT
Subject: RFR: 8252847: Optimize primitive arrayCopy stubs using AVX-512
 masked instructions [v6]
In-Reply-To: <x1vghm-llWYIn_4U0JAHmsiU553Olraptf4-w9Na4xU=.de05c602-377b-4437-ba24-406b907b6018@github.com>
References: <s3XJ1KwOB0mtBpkLYMuA7J8ftplOmHLqr8IwSeXrCg4=.4fe22fd0-8780-4d1e-a628-465e314ac31d@github.com>
 <x1vghm-llWYIn_4U0JAHmsiU553Olraptf4-w9Na4xU=.de05c602-377b-4437-ba24-406b907b6018@github.com>
Message-ID: <NFeuo1RO_aA8tv8d4wB0RxajcEWRVjHkbj7X7uDCShI=.f87ac394-7267-4123-9bed-426d27801c37@github.com>

On Mon, 28 Sep 2020 12:21:01 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Summary:
>> 
>> 1)  New AVX3 optimized stubs for both conjoint and disjoint arraycopy.
>> 2)  Special instruction sequence blocks for copy sizes b/w 32-192 bytes.
>> 3)  Block copy operation above 192 bytes is performed using destination address aligned PRE-MAIN-POST loop. Main loop
>> copies 192 byte in one iteration and tail part fall over special instruction sequence blocks. 4)  Both small copy block
>> and aligned loop use 32 byte vector register to prevent and frequency penalty for copy sizes less than AVX3Threshold.
>> 5)  For block size above AVX3Theshold both special blocks and loop operate using 64 byte register. 6)  In case user
>> sets the maximum vector size to 32 bytes, forward copy (disjoint) operations are done using efficient REP MOVS for copy
>> sizes above 4096 bytes.  JMH Results:
>>   System     :  CascadeLake Server, Intel(R) Xeon(R) Platinum 8280L CPU @ 2.70GHz
>>   Micros     :  test/micro/org/openjdk/bench/java/lang/ArrayCopy*.java
>>   Baseline   :  [http://cr.openjdk.java.net/~jbhateja/8252847/JMH_results/ArrayCopy_AVX3_Stubs_Baseline.txt]()
>>   WithOpt  :  [http://cr.openjdk.java.net/~jbhateja/8252847/JMH_results/ArrayCopy_AVX3_Stubs_WithOpts.txt]()
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8252847 : Review comments resolution

Yes, this looks better. Reviewed. Before pushing let me test it. I will let you know results.

-------------

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/61

From kvn at openjdk.java.net  Fri Oct  9 17:59:13 2020
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 9 Oct 2020 17:59:13 GMT
Subject: RFR: 8252847: Optimize primitive arrayCopy stubs using AVX-512
 masked instructions [v5]
In-Reply-To: <g4qVQGfRPkX7sflq7ETQdWpEL9fXsUoixmu2xKgahvw=.e9b3ed3a-a192-42cc-ac18-97456dfbf6c3@github.com>
References: <s3XJ1KwOB0mtBpkLYMuA7J8ftplOmHLqr8IwSeXrCg4=.4fe22fd0-8780-4d1e-a628-465e314ac31d@github.com>
 <XR9RmuktREfMNaYp0MC6cwLVUAm1_MzdewUA00Inp58=.372fb1e3-50bc-41f3-883b-dcc36cc605d5@github.com>
 <sQHZ77hHmnwfonjb7qvDT6-rL3luDvk57q36Sjmb_Lo=.12a2e731-cedf-48c5-80be-bd832dcb6cd2@github.com>
 <g4qVQGfRPkX7sflq7ETQdWpEL9fXsUoixmu2xKgahvw=.e9b3ed3a-a192-42cc-ac18-97456dfbf6c3@github.com>
Message-ID: <ajWAXG9N5yhBIIQH4LQrI3B3qV16EH_VcbqBoSNp7Aw=.ec4cff14-fa87-490a-9a69-0393e24f7089@github.com>

On Tue, 6 Oct 2020 18:51:52 GMT, Nils Eliasson <neliasso at openjdk.org> wrote:

>> src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 1264:
>> 
>>> 1262:   }
>>> 1263:
>>> 1264: #ifndef PRODUCT
>> 
>> macroAssembler_x86.hpp become big. May be we should start thing about splitting arraycopy stubs into separate file.
>
> But lets do that in a another change. It is good that the AVX3 case is separated out in this change - makes it easy to
> follow.

agree

-------------

PR: https://git.openjdk.java.net/jdk/pull/61

From herrick at openjdk.java.net  Fri Oct  9 18:21:10 2020
From: herrick at openjdk.java.net (Andy Herrick)
Date: Fri, 9 Oct 2020 18:21:10 GMT
Subject: Integrated: 8253379: [windows] Several jpackage tests failed with
 error code 1638
In-Reply-To: <LpRaGB39y6sd9g4cO4JZRPWsYl0oUtSO0l6Smv2xgbo=.992f6c8e-c478-4c3c-bf1e-5f43191336cd@github.com>
References: <LpRaGB39y6sd9g4cO4JZRPWsYl0oUtSO0l6Smv2xgbo=.992f6c8e-c478-4c3c-bf1e-5f43191336cd@github.com>
Message-ID: <l5v6GS5roBiq-SBwwW1dWCsz00QAMBeLjH1cCXfRhQg=.e939fdd2-e680-463e-b2aa-0fbcc5388e14@github.com>

On Thu, 24 Sep 2020 14:14:54 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> 8253379: [windows] Several jpackage tests failed with error code 1638
> two windows specific test fixes in WindowsHelper:
> 1.) do not test that the parent directory of a windows menu shortcut is empty after shortcut is uninstalled (there may
> be other shortcuts using that directory) 2.) do not programmatically install windows exe installers (since we have no
> way of programmatically uninstalling them)

This pull request has now been integrated.

Changeset: be269724
Author:    Andy Herrick <herrick at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/be269724
Stats:     19 lines in 2 files changed: 13 ins; 0 del; 6 mod

8253379: [windows] Several jpackage tests failed with error code 1638

Reviewed-by: asemenyuk, almatvee, kizune

-------------

PR: https://git.openjdk.java.net/jdk/pull/337

From minqi at openjdk.java.net  Fri Oct  9 19:08:27 2020
From: minqi at openjdk.java.net (Yumin Qi)
Date: Fri, 9 Oct 2020 19:08:27 GMT
Subject: RFR: 8247536: Support for pre-generated java.lang.invoke classes
 in CDS static archive [v15]
In-Reply-To: <Y_Bas-poGnDtvcJbqbmeIAPQRNxzvarBToQWALn9TTE=.e846cd3c-0e7b-48d3-8ffa-be3c03acffb0@github.com>
References: <Y_Bas-poGnDtvcJbqbmeIAPQRNxzvarBToQWALn9TTE=.e846cd3c-0e7b-48d3-8ffa-be3c03acffb0@github.com>
Message-ID: <4DdscR_ZGWXKUdu7k3df9USNXScFRqNEJhKq_8mSM3E=.5f8957ff-c209-42a0-945b-1fc30c5604ac@github.com>

> This patch is reorganized after 8252725, which is separated from this patch to refactor jlink glugin code. The previous
> webrev with hg can be found at: http://cr.openjdk.java.net/~minqi/2020/8247536/webrev-05. With 8252725 integrated, the
> regeneration of holder classes is simply to call the new added GenerateJLIClassesHelper.cdsGenerateHolderClasses
> function.  Tests: tier1-4

Yumin Qi has updated the pull request incrementally with one additional commit since the last revision:

  Changed isValidInputLines to validateInputLines and throw IAE upon wrong inputs. Fixed missed archive_mirror issue
  which could lead crash for archived heap iteration. After call generateLambdaFormHolderClasses, should check exception
  first. Added more comments why print out exception message and stacktrace in CDS.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/193/files
  - new: https://git.openjdk.java.net/jdk/pull/193/files/f163fe4c..16362e15

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=193&range=14
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=193&range=13-14

  Stats: 37 lines in 4 files changed: 7 ins; 15 del; 15 mod
  Patch: https://git.openjdk.java.net/jdk/pull/193.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/193/head:pull/193

PR: https://git.openjdk.java.net/jdk/pull/193

From lancea at openjdk.java.net  Fri Oct  9 19:15:14 2020
From: lancea at openjdk.java.net (Lance Andersen)
Date: Fri, 9 Oct 2020 19:15:14 GMT
Subject: RFR: 8253952: Refine ZipOutputStream.putNextEntry() to
 recalculate ZipEntry's compressed size [v2]
In-Reply-To: <hY8lfhGTXizeHqM6iWX3eKDXz5B4-WHAFaZNvHLk6qc=.d9bf046e-f493-4653-94b1-39d154a4175e@github.com>
References: <0nq5oFKOj6AZqCW6jF268-6oKRI6UkS6TRIHo-_5vKw=.d13c7016-4473-4b20-9117-100b368d3716@github.com>
 <hY8lfhGTXizeHqM6iWX3eKDXz5B4-WHAFaZNvHLk6qc=.d9bf046e-f493-4653-94b1-39d154a4175e@github.com>
Message-ID: <Zc5COtFjQ0pYwIhOEILKfenVMv-Jz5uFOVrt3xOt1Co=.3635f7fb-bd10-4702-84b9-9cfd6637d8a8@github.com>

On Fri, 9 Oct 2020 10:28:34 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> ### Summary
>> 
>> Work around wrong usage of `ZipOutputStream.putNextEntry()` in user code which can lead to the `ZipException "invalid
>> entry compressed size"`.
>> ### Motivation
>> 
>> In general it is not safe to directly write a ZipEntry obtained from `ZipInputStream.getNextEntry()`,
>> `ZipFile.entries()`, `ZipFile.getEntry()` or `ZipFile.stream()` with `ZipOutputStream.putNextEntry()` to a
>> `ZipOutputStream` and then read the entries data from the `ZipInputStream` and write it to the `ZipOutputStream` as
>> follows:
>>  ZipEntry entry;
>>  ZipInputStream zis = new ZipInputStream(...);
>>  ZipOutputStream zos = new ZipOutputStream(...);
>>  while((entry = zis.getNextEntry()) != null) {
>>      zos.putNextEntry(entry);
>>      zis.transferTo(zos);
>>  }
>> The problem with this code is that the zip file format does not record the compression level used for deflation in its
>> entries. In general, it doesn't even mandate a predefined compression ratio per compression level. Therefore the
>> compressed size recorded in a `ZipEntry` read from a zip file might differ from the new compressed size produced by the
>> receiving `ZipOutputStream`. Such a difference will result in a `ZipException` with the following message:
>>  java.util.zip.ZipException: invalid entry compressed size (expected 12 but got 7 bytes)
>>  
>> The correct way of copying all entries from one zip file into another requires the creation of a new `ZipEntry` or at
>> least resetting of the compressed size field. E.g.:
>>  while((entry = zis.getNextEntry()) != null) {
>>      ZipEntry newEntry = new ZipEntry(entry.getName());
>>      zos.putNextEntry(newEntry);
>>      zis.transferTo(zos);
>>  }
>> or:
>>  while((entry = zis.getNextEntry()) != null) {
>>      entry.setCompressedSize(-1);
>>      zos.putNextEntry(entry);
>>      zis.transferTo(zos);
>>  }
>> Unfortunately, there's a lot of user code out there which gets this wrong and uses the bad coding pattern described
>> before. Searching for `"java.util.zip.ZipException: invalid entry compressed size (expected 12 but got 7 bytes)"` gives
>> ~2500 hits (~100 on StackOverflow). It's also no hard to find plenty of instances of this anti-pattern on GitHub when
>> doing a code search for `ZipEntry` and `putNextEntry()`. E.g. [Gradle 4.x wrapper task][1] is affected as well as the
>> latest version of the [mockableAndroidJar task][2]. I've recently fixed two occurrences of this pattern in OpenJDK (see
>> [JDK-8240333][3] and [JDK-8240235][4]) but there still exist more of them (e.g.
>> [`test/jdk/java/util/zip/ZipFile/CopyJar.java`][5] which is there since 1999 :).  ### Description  So while this has
>> clearly been a problem before, it apparently wasn't painful enough to trigger any action from the side of the JDK.
>> However, recently quite some zlib forks with [superior deflate/inflate performance have evolved][6]. Using them with
>> OpenJDK is quite straight-forward: one just has to configure the alternative implementations by setting
>> `LD_LIBRARY_PATH` or `LD_PRELOAD` correspondingly. We've seen big saving by using these new zlib implementations for
>> selected services in production and the only reason why we haven't enabled them by default until now is the problem
>> I've just described. The reason why these new libraries uncover the described anti-pattern much more often is because
>> their compression ratio is slightly different from that of the default zlib library. This can easily trigger a
>> `ZipException` even if an application is not using a different compression levels but just a zip file created with
>> another zlib version.  I'd therefore like to propose the following workaround for the wrong
>> `ZipOutputStream.putNextEntry()` usage in user code:
>> -  ignore the compressed size if it was implicitly determined from the zip file and not explicitly set by calling
>>    `ZipEntry.setCompressedSize()`.
>> 
>> - Change the API-documentation of `ZipOutputStream.putNextEntry()` and `JarOutputStream.putNextEntry()` to explain the
>>   problem and why `putNextEntry()` will ignore the compressed size of a `ZipEntry` if that was set implicitely when
>>   reading that entry from a `ZipFile` or `ZipInputStream`.
>> 
>> 
>> ### Technical Details
>> 
>> A zip file consists of a stream of File Entries followed by a Central Directory (see [here for a more detailed
>> specification][7]). Each File Entry is composed of a Local File Header (LFH) followed by the compressed Data and an
>> optional Data Descriptor. The LFH contains the File Name and among other attributes the Compressed and Uncompressed
>> size and CRC of the Data. In the case where the latter three attributes are not available at the time when the LFH is
>> created, this fact will be recorded in a flag of the LFH and will trigger the creation of a Data Descriptor with the
>> corresponding information right after the Data section. Finally, the Central Directory contains one Central Directory
>> File Header (CDFH) for each entry of the  zip archive. The CDFH is an extended version of the LFH and the ultimate
>> reference for the contents of the zip archive. The redundancy between LFH and CDFH is a tribute to zip's long history
>> when it was used to store archives on multiple floppy discs and the CDFH allowed to update the archive by only writing
>> to the last disc which contained the Central Directory.  `ZipEntries` read with `ZipInputStream.getNextEntry()` will
>> initially only contain the information from the LFH. Only after the next entry was read (or after
>> `ZipInputStream.closeEntry()` was called explicitly), will the previously read entry be updated with the data from the
>> Data Descriptor. `ZipInputStream` doesn't inspect the Central Directory at all.  On the other hand, `ZipFile` only
>> queries the Central Directory for `ZipEntry` information so all `ZipEntries` returned by `ZipFile.entries()`,
>> `ZipFile.getEntry()` and `ZipFile.stream()` will always instantly contain the full Compressed and Uncompressed Size and
>> CRC information for each entry independently of the LFH contents.  ### Risks and Assumptions  If we choose to ignore
>> the implicitly recorded compressed size in a `ZipEntry` read from a zip file when writing it to a `ZipOutputStream`,
>> this will lead to zip files with incomplete information in the LFH and an additional Data Descriptor as described
>> before. However, the result is still fully compatible to the zip file specification. It's also not unusual, because by
>> default all new zip files created with `ZipOutputStream` will contain LFHs without Compressed and Uncompressed Size and
>> CRC information and an additional Data Descriptor. Theoretically it is possible to create new zip files with
>> `ZipOutputStream` class and Compressed and Uncompressed Size and CRC information in the LFH but that's complex and
>> inefficient because it requires two steps. A first step to determine the crc and compressed size of the data and a
>> second step to actually write the data to the `ZipOutputStream` (which will compress it a second time). This is because
>> the current API offers no possibility to write already compressed data to a `ZipOutputStream`.  Consequently, the only
>> straight-forward way of creating zip files from Java which have all the data in the LFH and no Data Descriptor is by
>> copying `ZipEntries` from an existing zip file with the buggy method described before. This incidentally worked more or
>> less reliable for a long time but breaks miserably when using different zlib implementations. Ignoring the implicitly
>> set compressed size of `ZipEntries` can easily fix this problem.  I'm not aware of any tool which can not handle such
>> files and if it exists it would have problems with the majority of Java created zip files anyway (e.g. all jar-files
>> created with the jar tool have zip entries with incomplete LFH data and additional Data Descriptor).  Ignoring the
>> implicitly set compressed size of `ZipEntries` has no measurable performance impact and will increase the size of zip
>> archives which used to have the complete file information in the LFH before by 16 bytes per entry. On the other hand it
>> will give us the freedom to use whatever zip implementation we like :)   [1]:
>> https://github.com/gradle/gradle/blob/e76905e3a/subprojects/build-init/src/main/java/org/gradle/api/tasks/wrapper/Wrapper.java#L152-L158
>> [2]:
>> https://android.googlesource.com/platform/tools/base/+/refs/heads/master/build-system/builder/src/main/java/com/android/builder/testing/MockableJarGenerator.java#86
>> [3]: https://bugs.openjdk.java.net/browse/JDK-8240333 [4]: https://bugs.openjdk.java.net/browse/JDK-8240235 [5]:
>> https://github.com/openjdk/jdk/blob/master/test/jdk/java/util/zip/ZipFile/CopyJar.java [6]:
>> https://github.com/simonis/zlib-bench/blob/master/Results.md [7]: https://en.wikipedia.org/wiki/Zip_(file_format)
>
> Volker Simonis 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:
>   8253952: Refine ZipOutputStream.putNextEntry() to recalculate ZipEntry's compressed size

src/java.base/share/classes/java/util/jar/JarOutputStream.java line 84:

> 82:      * time.
> 83:      *
> 84:      * The compressed size field will be recalculated for compressed (i.e.

I think the wording is better, but not sure we should state "compressed size field" as ZipEntry.setCompressedSize
refers to "Sets the size of the compressed entry data."   and "the compressed size to set"

I think I would omit "field" from the above so it reads  similar to "The compressed size will be..." or "The compressed
size value will be..."

-------------

PR: https://git.openjdk.java.net/jdk/pull/520

From minqi at openjdk.java.net  Fri Oct  9 19:19:14 2020
From: minqi at openjdk.java.net (Yumin Qi)
Date: Fri, 9 Oct 2020 19:19:14 GMT
Subject: RFR: 8247536: Support for pre-generated java.lang.invoke classes
 in CDS static archive [v12]
In-Reply-To: <kz0Xu1ovkOhMDnQTsen4WORb8dAs1zi5oPnF4f_rDJE=.7c40ebbd-5230-49f9-a370-d9eeae63378c@github.com>
References: <Y_Bas-poGnDtvcJbqbmeIAPQRNxzvarBToQWALn9TTE=.e846cd3c-0e7b-48d3-8ffa-be3c03acffb0@github.com>
 <9emWKl6fr-GA5LN0uHhuEd5D123QcoCiHQR1M9bAbag=.cc4b6129-8b33-47e4-a421-9e6b4817933b@github.com>
 <kz0Xu1ovkOhMDnQTsen4WORb8dAs1zi5oPnF4f_rDJE=.7c40ebbd-5230-49f9-a370-d9eeae63378c@github.com>
Message-ID: <Cx6E7Drtxu_qbOq_7Ln8J9T9TLhlMS6Its0zMl3UQWY=.805ad832-dd4f-481c-9d64-e291b6b39589@github.com>

On Wed, 7 Oct 2020 17:53:30 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Yumin Qi has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains
>> 23 commits:
>>  - Added new separate function to CDS for logging species and modified the existing function to log lambda form invokers.
>>    Changed isDumpLoadedClassList to a reasonable name isDumpingClassList as read only in CDS.
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into jdk-8247536
>>  - Removed unused imports.
>>  - Fixed comments with correct class and method name in CDS, removed unused variables after last change.
>>  - Moved and renamed cdsGenerateHolderClasses from GenerateJLIClassesHelp to CDS as generateLambdaFormHolderClasses. Added
>>    input verification function in CDS before class generation. Added more test scenarios. Removed trailing unused ending
>>    words for output of lambda form trace line in case of DumpLoadedClassList.
>>  - Move the check work to java, restore code in VM. Modified test code according to the changes. The invoke name
>>    verififcation is not implemented since not all the holder class are processed, not all the functions of processed
>>    holder classes are added. For holder class with DirectMethodHandle in its name, only the name in the
>>    DMH_METHOD_TYPE_MAP keyset is added, ithe line with other names just gets skipped silently. This makes the verification
>>    on invoke names difficul, a name not in the keyset should not fail the test. Also add a boolean to
>>    cdsGenerateHolderClasses to indicate call path.
>>  - Remove trailing word of line which is not used in holder class regeneration. There is a trailing LF (Line Feed) so trim
>>    white spaces from both front and end of the line or it will fail method type validation.
>>  - In case of exception happens during reloading class, CHECK will return without free the allocated buffer for class
>>    bytes so moved the buffer allocation and freeing to caller. Also removed test 6 since there is not guarantee that we
>>    can give a signature which will always fail. Additional changes to GenerateJLIClassesHelper according to review
>>    suggestion.
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into jdk-8247536
>>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into jdk-8247536
>>  - ... and 13 more: https://git.openjdk.java.net/jdk/compare/82fe023b...f5584dcf
>
> Marked as reviewed by iklam (Reviewer).

passed mach5 tier1-4

-------------

PR: https://git.openjdk.java.net/jdk/pull/193

From kvn at openjdk.java.net  Fri Oct  9 20:33:16 2020
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 9 Oct 2020 20:33:16 GMT
Subject: RFR: 8252847: Optimize primitive arrayCopy stubs using AVX-512
 masked instructions [v6]
In-Reply-To: <NFeuo1RO_aA8tv8d4wB0RxajcEWRVjHkbj7X7uDCShI=.f87ac394-7267-4123-9bed-426d27801c37@github.com>
References: <s3XJ1KwOB0mtBpkLYMuA7J8ftplOmHLqr8IwSeXrCg4=.4fe22fd0-8780-4d1e-a628-465e314ac31d@github.com>
 <x1vghm-llWYIn_4U0JAHmsiU553Olraptf4-w9Na4xU=.de05c602-377b-4437-ba24-406b907b6018@github.com>
 <NFeuo1RO_aA8tv8d4wB0RxajcEWRVjHkbj7X7uDCShI=.f87ac394-7267-4123-9bed-426d27801c37@github.com>
Message-ID: <UueIR0iGY_5vDBbnjP2fX1W25EA2Qm7WLWv9dVcjFKk=.e9965b9b-a0de-4f51-91e3-71e4e155e2bb@github.com>

On Fri, 9 Oct 2020 17:56:51 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8252847 : Review comments resolution
>
> Yes, this looks better. Reviewed. Before pushing let me test it. I will let you know results.

hs-tier1-3 testing passed on x86 (all OSs).

-------------

PR: https://git.openjdk.java.net/jdk/pull/61

From vromero at openjdk.java.net  Fri Oct  9 21:19:23 2020
From: vromero at openjdk.java.net (Vicente Romero)
Date: Fri, 9 Oct 2020 21:19:23 GMT
Subject: RFR: 8253455: Record Classes javax.lang.model changes
In-Reply-To: <_EiRbvHonuflkmP-H77rZp9DQCpMs74zdWG3aO0_z0U=.c3b70b2f-75f2-4638-a4b4-a911e3f0851f@github.com>
References: <_EiRbvHonuflkmP-H77rZp9DQCpMs74zdWG3aO0_z0U=.c3b70b2f-75f2-4638-a4b4-a911e3f0851f@github.com>
Message-ID: <4-RukNqR8mw_y9cNdDzi0YLj-5pai7_t9xW8by6ujsU=.630a90fb-55bd-492a-9388-9e4d7fd12ca8@github.com>

On Mon, 21 Sep 2020 23:31:51 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Please review the fix for [JDK-8253455](https://bugs.openjdk.java.net/browse/JDK-8253455) which is part of the effort
> to make records a final feature of the Java Language. The rest of the code has been published in
> [PR#290](https://github.com/openjdk/jdk/pull/290)  Thanks,
> Vicente

thanks for the comments, I have updated the PR changing `@since 14` to `@since 16`

-------------

PR: https://git.openjdk.java.net/jdk/pull/291

From vromero at openjdk.java.net  Fri Oct  9 21:19:23 2020
From: vromero at openjdk.java.net (Vicente Romero)
Date: Fri, 9 Oct 2020 21:19:23 GMT
Subject: RFR: 8253455: Record Classes javax.lang.model changes [v6]
In-Reply-To: <_EiRbvHonuflkmP-H77rZp9DQCpMs74zdWG3aO0_z0U=.c3b70b2f-75f2-4638-a4b4-a911e3f0851f@github.com>
References: <_EiRbvHonuflkmP-H77rZp9DQCpMs74zdWG3aO0_z0U=.c3b70b2f-75f2-4638-a4b4-a911e3f0851f@github.com>
Message-ID: <9n4YsX6h1Er-183zkPoyr6R4PPgswFZTCORS2K8Ky-c=.3c4dd522-de88-4428-a4d5-4e6b042d6409@github.com>

> Please review the fix for [JDK-8253455](https://bugs.openjdk.java.net/browse/JDK-8253455) which is part of the effort
> to make records a final feature of the Java Language. The rest of the code has been published in
> [PR#290](https://github.com/openjdk/jdk/pull/290)  Thanks,
> Vicente

Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:

  updating @since from 14 to 16

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/291/files
  - new: https://git.openjdk.java.net/jdk/pull/291/files/f5682fc2..cd27384d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=291&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=291&range=04-05

  Stats: 13 lines in 11 files changed: 0 ins; 0 del; 13 mod
  Patch: https://git.openjdk.java.net/jdk/pull/291.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/291/head:pull/291

PR: https://git.openjdk.java.net/jdk/pull/291

From ccheung at openjdk.java.net  Fri Oct  9 22:49:30 2020
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Fri, 9 Oct 2020 22:49:30 GMT
Subject: RFR: 8247666: Support Lambda proxy classes in static CDS archive
 [v4]
In-Reply-To: <ynh4JzHY75GjEn5_oCtmRNy9HMFsU34O2PlhSwD41tU=.1a3770f9-9091-429f-8d03-31b826f9b093@github.com>
References: <ynh4JzHY75GjEn5_oCtmRNy9HMFsU34O2PlhSwD41tU=.1a3770f9-9091-429f-8d03-31b826f9b093@github.com>
Message-ID: <ooNbs6IcVyU3E-n8PMnzLZvhYohltpQHEFNFXXZ6nGw=.658b93e0-7d6d-4beb-8565-f04a733adaf5@github.com>

> Following up on archiving lambda proxy classes in dynamic CDS archive
> ([JDK-8198698](https://bugs.openjdk.java.net/browse/JDK-8198698)), this RFE adds the functionality of archiving of
> lambda proxy classes in static CDS archive.
> When the -XX:DumpLoadedClassList is enabled, the constant pool index related to LambdaMetafactory that are resolved
> during application execution will be included in the classlist. The entry for a lambda proxy class in a class list will
> be of the following format:
> `@lambda-proxy: <classname> <cp index>`
> 
> e.g.
> `@lambda-proxy: test/java/lang/invoke/MethodHandlesGeneralTest 233`
> `@lambda-proxy: test/java/lang/invoke/MethodHandlesGeneralTest 355`
> 
> When dumping a CDS archive using the -Xshare:dump and -XX:ExtraSharedClassListFile options, when the above
> `@lambda-proxy` entry is encountered while parsing the classlist, we will resolve the corresponding constant pool
> indices (233 and 355 in the above example). As a result, lambda proxy classes will be generated for the constant pool
> entries, and will be cached using a similar mechanism to JDK-8198698.  During dumping, there is check on the cp index
> and on the created BootstrapInfo using the cp index. VM will exit with an error message if the check has failed.
> During runtime when looking up a lambda proxy class, the lookup will be perform on the static CDS archive and if not
> found, then lookup from the dynamic archive if one is specified.  (Only name change (IsDynamicDumpingEnabled ->
> IsCDSDumpingEnabled) is involved in the core-libs code.)
> Testing: tiers 1,2,3,4.
> 
> Performance results (javac on HelloWorld on linux-x64):
> Results of " perf stat -r 40 bin/javac -J-Xshare:on -J-XX:SharedArchiveFile=javac2.jsa Bench_HelloWorld.java "
>    1:   2228016795  2067752708 (-160264087)      -----    377.760   349.110 (-28.650)      -----
>    2:   2223051476  2063016483 (-160034993)      -----    374.580   350.620 (-23.960)      ----
>    3:   2225908334  2067673847 (-158234487)      -----    375.220   350.990 (-24.230)      ----
>    4:   2225835999  2064596883 (-161239116)      -----    374.670   349.840 (-24.830)      ----
>    5:   2226005510  2061694332 (-164311178)      -----    373.512   351.120 (-22.392)      ----
>    6:   2225574949  2062657482 (-162917467)      -----    374.710   348.380 (-26.330)      -----
>    7:   2224702424  2064634122 (-160068302)      -----    373.670   349.510 (-24.160)      ----
>    8:   2226662277  2066301134 (-160361143)      -----    375.350   349.790 (-25.560)      ----
>    9:   2226761470  2063162795 (-163598675)      -----    374.260   351.290 (-22.970)      ----
>   10:   2230149089  2066203307 (-163945782)      -----    374.760   350.620 (-24.140)      ----
> ============================================================
>         2226266109  2064768307 (-161497801)      -----    374.848   350.126 (-24.722)      ----
> instr delta =   -161497801    -7.2542%
> time  delta =      -24.722 ms -6.5951%

Calvin Cheung has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev
excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since
the last revision:

 - Merge branch 'master' into 8247666
 - 1. Symbolic encoding of lambda proxy resolution. An example of @lambda-proxy in the classlist:
   @lambda-proxy: LambHello run ()Ljava/lang/Runnable; ()V 6 LambHello lambdabash ()V ()V
   2. Removed BadCPIndex.java; added LambdaProxyClassList.java test.
   3. Mandy's comments.
 - Merge branch 'master' into 8247666
 - exclude archived lambda proxy classes in the classlist
 - updated systemDictionaryShared.[c|h]pp based on suggestions from Ioi
 - fix extraneous whitespace
 - 8247666 (initial commit)

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/364/files
  - new: https://git.openjdk.java.net/jdk/pull/364/files/c82b39f1..09cf61c2

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=364&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=364&range=02-03

  Stats: 24905 lines in 572 files changed: 15353 ins; 6792 del; 2760 mod
  Patch: https://git.openjdk.java.net/jdk/pull/364.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/364/head:pull/364

PR: https://git.openjdk.java.net/jdk/pull/364

From ccheung at openjdk.java.net  Fri Oct  9 23:06:12 2020
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Fri, 9 Oct 2020 23:06:12 GMT
Subject: RFR: 8247666: Support Lambda proxy classes in static CDS archive
 [v3]
In-Reply-To: <Ao0IiVWZYxqktD3M6lqoxTGlURbSnX3-vg3LKoU-mls=.13c222b0-69c4-40d7-b35e-887c934dbe77@github.com>
References: <ynh4JzHY75GjEn5_oCtmRNy9HMFsU34O2PlhSwD41tU=.1a3770f9-9091-429f-8d03-31b826f9b093@github.com>
 <pvSPAXeOsA-4mxsmAMzKbw8qeAxizhxzDrajr9p7cy4=.004ba246-f90e-4926-b4ec-19bead011c86@github.com>
 <Ao0IiVWZYxqktD3M6lqoxTGlURbSnX3-vg3LKoU-mls=.13c222b0-69c4-40d7-b35e-887c934dbe77@github.com>
Message-ID: <eraEDS7l4b3_JaTLvjtJ2W71M_rCMMQjb-9V7TmT2SI=.937fafcc-3f95-4aa7-8ad6-23bb8a925b44@github.com>

On Fri, 2 Oct 2020 22:47:43 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Calvin Cheung has updated the pull request with a new target base 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 8247666
>>  - exclude archived lambda proxy classes in the classlist
>>  - updated systemDictionaryShared.[c|h]pp based on suggestions from Ioi
>>  - fix extraneous whitespace
>>  - 8247666 (initial commit)
>
>> @lambda-proxy: test/java/lang/invoke/MethodHandlesGeneralTest 233
> @lambda-proxy: test/java/lang/invoke/MethodHandlesGeneralTest 355
> 
> It seems very fragile to require listing the CP index to `invokedynamic` entries of a class file.   Have you considered
> a simpler usage model without CP indices and default to all `invokedynamic` to `LambdaMetaFactory`?

Hi Mandy,
Thanks for your review.
We've tried the approach of archiving all the lambda proxy classes of a given class but we feel that there will be too
many unused lambda proxy classes in the archive and it will also increase the CDS archive size. So we opted for a
little more complicated approach by storing the symbolic encoding lambda proxy resolution in the classlist. During
dumping, the same info will be retrieved from the constant pool entry and compared with the one from the classlist. An
example of the entry in the classlist is: `@lambda-proxy: LambHello run ()Ljava/lang/Runnable; ()V 6 LambHello
lambda$main$0 ()V ()V` With the above approach, the number of lambda proxy classes the default CDS archive is 67. If we
archive all the lambda proxy classes of a given class, the number is 279. Webrev 03 contains the above change and also
addresses your other comments. Thanks! Calvin

> src/java.base/share/classes/jdk/internal/misc/CDS.java line 56:
> 
>> 54:      * Check if CDS dumping is enabled via the DynamicDumpSharedSpaces or the DumpSharedSpaces flag.
>> 55:      */
>> 56:     public static native boolean isCDSDumpingEnabled();
> 
> I suggest to rename `CDS::isCDSDumpingEnabled` to `CDS:isDumpingEnabled` as this method is a static method in `CDS`
> case and the word `CDS` in the method name is just noise.
> JVM entry point `JVM_IsCDSDumpingEnabled`  is good.

Fixed in webrev 03.

> src/hotspot/share/prims/jvm.cpp line 3834:
> 
>> 3832:
>> 3833: JVM_ENTRY(jboolean, JVM_IsCDSDumpingEnabled(JNIEnv* env))
>> 3834:     JVMWrapper("JVM_IsCDSDumpingEnable");
> 
> typo: missing `d` s/Enable/Enabled/

Fixed in webrev 03.

-------------

PR: https://git.openjdk.java.net/jdk/pull/364

From kvn at openjdk.java.net  Sat Oct 10 00:04:15 2020
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Sat, 10 Oct 2020 00:04:15 GMT
Subject: RFR: 8227745: Enable Escape Analysis for Better Performance in
 the Presence of JVMTI Agents [v9]
In-Reply-To: <5O9n8cKBJyjhp2cNOVD2PcpKQiXqEs5BJjkW1lH-5EM=.044a510e-6517-4564-a3db-00c7951f0b22@github.com>
References: <Ll2RereRbuQLgFtIjv9pS92kPvCVuo-BI0cP1zGjVbo=.dad3a33c-0fc3-44fd-810a-f01448cf564c@github.com>
 <5O9n8cKBJyjhp2cNOVD2PcpKQiXqEs5BJjkW1lH-5EM=.044a510e-6517-4564-a3db-00c7951f0b22@github.com>
Message-ID: <yaiYe--Do-AkvXtvTEVzj9JUbnXNaZLIonfUTfP-g1g=.05256ac4-70b2-4cbc-801b-b918191e2658@github.com>

On Thu, 8 Oct 2020 16:55:31 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> Hi,
>> 
>> this is the continuation of the review of the implementation for:
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8227745
>> https://bugs.openjdk.java.net/browse/JDK-8233915
>> 
>> It allows for JIT optimizations based on escape analysis even if JVMTI agents acquire capabilities to access references
>> to objects that are subject to such optimizations, e.g. scalar replacement. The implementation reverts such
>> optimizations just before access very much as when switching from JIT compiled execution to the interpreter, aka
>> "deoptimization".  Webrev.8 was the last one before before the transition to Git/Github:
>> 
>> http://cr.openjdk.java.net/~rrich/webrevs/8227745/webrev.8/
>> 
>> Thanks, Richard.
>
> Richard Reingruber has updated the pull request with a new target base due to a merge or a rebase. The pull request now
> contains 19 commits:
>  - Merge branch 'master' into JDK-8227745
>  - Merge branch 'master' into JDK-8227745
>  - Factorized fragment out of EscapeBarrier::deoptimize_objects_internal into new method in compiledVFrame.
>  - More smaller changes proposed by Serguei.
>  - jvmtiDeferredUpdates.hpp: remove forward declarations.
>  - jvmtiDeferredLocalVariable: move member variables to the beginning of the class definition.
>  - jvmtiDeferredUpdates.hpp: add/remove empty lines and improve indentation.
>  - Merge branch 'master' into JDK-8227745
>  - Merge branch 'master' into JDK-8227745
>  - Make parameter current_thread of JvmtiEnvBase::check_top_frame() a JavaThread* again.
>    
>    With Asynchronous handshakes the type was changed from JavaThread* to Thread*
>    but this is not necessary as check_top_frame() is not executed during a handshake
>    / safepoint (robehn confirmed).
>  - ... and 9 more: https://git.openjdk.java.net/jdk/compare/d036dca0...d463b4f3

Compiler changes seems fine.

-------------

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/119

From minqi at openjdk.java.net  Sat Oct 10 00:08:26 2020
From: minqi at openjdk.java.net (Yumin Qi)
Date: Sat, 10 Oct 2020 00:08:26 GMT
Subject: RFR: 8247536: Support for pre-generated java.lang.invoke classes
 in CDS static archive [v16]
In-Reply-To: <Y_Bas-poGnDtvcJbqbmeIAPQRNxzvarBToQWALn9TTE=.e846cd3c-0e7b-48d3-8ffa-be3c03acffb0@github.com>
References: <Y_Bas-poGnDtvcJbqbmeIAPQRNxzvarBToQWALn9TTE=.e846cd3c-0e7b-48d3-8ffa-be3c03acffb0@github.com>
Message-ID: <wirqKmwXPhh0CYqX2u48m0i_Y3gXLJ9gzGr43hRiUCA=.efc7649b-b2f2-4fdd-a471-45ffd44a2590@github.com>

> This patch is reorganized after 8252725, which is separated from this patch to refactor jlink glugin code. The previous
> webrev with hg can be found at: http://cr.openjdk.java.net/~minqi/2020/8247536/webrev-05. With 8252725 integrated, the
> regeneration of holder classes is simply to call the new added GenerateJLIClassesHelper.cdsGenerateHolderClasses
> function.  Tests: tier1-4

Yumin Qi has updated the pull request incrementally with three additional commits since the last revision:

 - Correct typo for check message
 - Removed try/catch from java side and moved output to vm.
 - Make change to original indent

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/193/files
  - new: https://git.openjdk.java.net/jdk/pull/193/files/16362e15..2184725f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=193&range=15
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=193&range=14-15

  Stats: 29 lines in 4 files changed: 1 ins; 10 del; 18 mod
  Patch: https://git.openjdk.java.net/jdk/pull/193.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/193/head:pull/193

PR: https://git.openjdk.java.net/jdk/pull/193

From kvn at openjdk.java.net  Sat Oct 10 00:15:12 2020
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Sat, 10 Oct 2020 00:15:12 GMT
Subject: RFR: 8173585: Intrinsify StringLatin1.indexOf(char) [v3]
In-Reply-To: <obcOrTC_yxKUUCjcq9pXNhowYF8mrOvCUhU6cn8J-8c=.c6f3b65e-5505-4f3c-8890-81f1655b8a38@github.com>
References: <_T0873dC5tfUtGn9r1_Y21JkPKRt-za3MM9hPN2GQKQ=.b865fe53-5417-424f-81b6-1566a330640e@github.com>
 <obcOrTC_yxKUUCjcq9pXNhowYF8mrOvCUhU6cn8J-8c=.c6f3b65e-5505-4f3c-8890-81f1655b8a38@github.com>
Message-ID: <0_4KDtvn6WhHRCxqupbUQjLauR5DMQWJluogsJ7m_KA=.697e6e15-5c91-4339-abab-1dff51871e8d@github.com>

On Mon, 21 Sep 2020 12:45:55 GMT, Jason Tatton <github.com+70893615+jasontatton-aws at openjdk.org> wrote:

>> This is an implementation of the indexOf(char) intrinsic for StringLatin1 (1 byte encoded Strings). It is provided for
>> x86 and ARM64. The implementation is greatly inspired by the indexOf(char) intrinsic for StringUTF16. To incorporate it
>> I had to make a small change to StringLatin1.java (refactor of functionality to intrisified private method) as well as
>> code for C2.  Submitted to: hotspot-compiler-dev and core-libs-dev as this patch contains a change to hotspot and
>> java/lang/StringLatin1.java  https://bugs.openjdk.java.net/browse/JDK-8173585
>> 
>> Details of testing:
>> ============
>> I have created a jtreg test ?compiler/intrinsics/string/TestStringLatin1IndexOfChar? to cover this new intrinsic. Note
>> that, particularly for the x86 implementation of the intrinsic, the code path taken is dependent upon the length of the
>> input String. Hence the test has been designed to cover all these cases. In summary they are:
>> - A ?short? string of < 16 characters.
>> - A SIMD String of 16 ? 31 characters.
>> - A AVX2 SIMD String of 32 characters+.
>> 
>> Hardware used for testing:
>> -----------------------------
>> 
>> - Intel Xeon CPU E5-2680 (JVM did not recognize this as having AVX2 support) ? Intel i7 processor (with AVX2 support).
>> - AWS Graviton 2 (ARM 64 processor).
>> 
>> I also ran; ?run-test-tier1? and ?run-test-tier2? for: x86_64 and aarch64.
>> 
>> Possible future enhancements:
>> ====================
>> For the x86 implementation there may be two further improvements we can make in order to improve performance of both
>> the StringUTF16 and StringLatin1 indexOf(char) intrinsics:
>> 1. Make use of AVX-512 instructions.
>> 2. For ?short? Strings (see below), I think it may be possible to modify the existing algorithm to still use SSE SIMD
>> instructions instead of a loop.
>> Benchmark results:
>> ============
>> **Without** the new StringLatin1 indexOf(char) intrinsic:
>> 
>> | Benchmark  | Mode | Cnt | Score | Error | Units |
>> | ------------- | ------------- |------------- |------------- |------------- |------------- |
>> | IndexOfBenchmark.latin1_mixed_char | avgt | 5 | **26,389.129** | ? 182.581 | ns/op |
>> | IndexOfBenchmark.utf16_mixed_char | avgt | 5 | 17,885.383 | ? 435.933  | ns/op |
>> 
>> 
>> **With** the new StringLatin1 indexOf(char) intrinsic:
>> 
>> | Benchmark  | Mode | Cnt | Score | Error | Units |
>> | ------------- | ------------- |------------- |------------- |------------- |------------- |
>> | IndexOfBenchmark.latin1_mixed_char | avgt | 5 | **17,875.185** | ? 407.716  | ns/op |
>> | IndexOfBenchmark.utf16_mixed_char | avgt | 5 | 18,292.802 | ? 167.306  | ns/op |
>> 
>> 
>> The objective of the patch is to bring the performance of StringLatin1 indexOf(char) in line with StringUTF16
>> indexOf(char) for x86 and ARM64. We can see above that this has been achieved. Similar results were obtained when
>> running on ARM.
>
> Jason Tatton has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add missing newline to end of vmSymbols.cpp

Changes seems fine but you missing Copyright + GPL header in new files.

test/hotspot/jtreg/compiler/intrinsics/string/TestStringLatin1IndexOfChar.java line 1:

> 1: /*

Missing copyright+GPL header in new test. See other tests fro example.

test/micro/org/openjdk/bench/java/lang/StringIndexOfChar.java line 1:

> 1: package org.openjdk.bench.java.lang;

Again missing Copyright.

-------------

Changes requested by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/71

From mchung at openjdk.java.net  Sat Oct 10 00:17:13 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Sat, 10 Oct 2020 00:17:13 GMT
Subject: RFR: 8247536: Support for pre-generated java.lang.invoke classes
 in CDS static archive [v16]
In-Reply-To: <wirqKmwXPhh0CYqX2u48m0i_Y3gXLJ9gzGr43hRiUCA=.efc7649b-b2f2-4fdd-a471-45ffd44a2590@github.com>
References: <Y_Bas-poGnDtvcJbqbmeIAPQRNxzvarBToQWALn9TTE=.e846cd3c-0e7b-48d3-8ffa-be3c03acffb0@github.com>
 <wirqKmwXPhh0CYqX2u48m0i_Y3gXLJ9gzGr43hRiUCA=.efc7649b-b2f2-4fdd-a471-45ffd44a2590@github.com>
Message-ID: <VjcHYBzSu25nUvv4I__Dhm5e-9P9FapMJEhbKgtqOuY=.f19e788c-0ad7-4145-a2a7-0383701966fc@github.com>

On Sat, 10 Oct 2020 00:08:26 GMT, Yumin Qi <minqi at openjdk.org> wrote:

>> This patch is reorganized after 8252725, which is separated from this patch to refactor jlink glugin code. The previous
>> webrev with hg can be found at: http://cr.openjdk.java.net/~minqi/2020/8247536/webrev-05. With 8252725 integrated, the
>> regeneration of holder classes is simply to call the new added GenerateJLIClassesHelper.cdsGenerateHolderClasses
>> function.  Tests: tier1-4
>
> Yumin Qi has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Correct typo for check message
>  - Removed try/catch from java side and moved output to vm.
>  - Make change to original indent

I reviewed the files under `src/java.base`.

-------------

Marked as reviewed by mchung (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/193

From kvn at openjdk.java.net  Sat Oct 10 00:28:13 2020
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Sat, 10 Oct 2020 00:28:13 GMT
Subject: RFR: 8227745: Enable Escape Analysis for Better Performance in
 the Presence of JVMTI Agents [v9]
In-Reply-To: <5O9n8cKBJyjhp2cNOVD2PcpKQiXqEs5BJjkW1lH-5EM=.044a510e-6517-4564-a3db-00c7951f0b22@github.com>
References: <Ll2RereRbuQLgFtIjv9pS92kPvCVuo-BI0cP1zGjVbo=.dad3a33c-0fc3-44fd-810a-f01448cf564c@github.com>
 <5O9n8cKBJyjhp2cNOVD2PcpKQiXqEs5BJjkW1lH-5EM=.044a510e-6517-4564-a3db-00c7951f0b22@github.com>
Message-ID: <kXS8IuV-hgsemXHvzdEUd3V5SPCzxY0ClFQQpL0aDLw=.7aef142a-acfa-4b3f-9568-5af89f7871df@github.com>

On Thu, 8 Oct 2020 16:55:31 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> Hi,
>> 
>> this is the continuation of the review of the implementation for:
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8227745
>> https://bugs.openjdk.java.net/browse/JDK-8233915
>> 
>> It allows for JIT optimizations based on escape analysis even if JVMTI agents acquire capabilities to access references
>> to objects that are subject to such optimizations, e.g. scalar replacement. The implementation reverts such
>> optimizations just before access very much as when switching from JIT compiled execution to the interpreter, aka
>> "deoptimization".  Webrev.8 was the last one before before the transition to Git/Github:
>> 
>> http://cr.openjdk.java.net/~rrich/webrevs/8227745/webrev.8/
>> 
>> Thanks, Richard.
>
> Richard Reingruber has updated the pull request with a new target base due to a merge or a rebase. The pull request now
> contains 19 commits:
>  - Merge branch 'master' into JDK-8227745
>  - Merge branch 'master' into JDK-8227745
>  - Factorized fragment out of EscapeBarrier::deoptimize_objects_internal into new method in compiledVFrame.
>  - More smaller changes proposed by Serguei.
>  - jvmtiDeferredUpdates.hpp: remove forward declarations.
>  - jvmtiDeferredLocalVariable: move member variables to the beginning of the class definition.
>  - jvmtiDeferredUpdates.hpp: add/remove empty lines and improve indentation.
>  - Merge branch 'master' into JDK-8227745
>  - Merge branch 'master' into JDK-8227745
>  - Make parameter current_thread of JvmtiEnvBase::check_top_frame() a JavaThread* again.
>    
>    With Asynchronous handshakes the type was changed from JavaThread* to Thread*
>    but this is not necessary as check_top_frame() is not executed during a handshake
>    / safepoint (robehn confirmed).
>  - ... and 9 more: https://git.openjdk.java.net/jdk/compare/d036dca0...d463b4f3

I tried to run testing with latest changes and latest JDK and build failed:
src/hotspot/share/runtime/escapeBarrier.cpp:310:35: error: no matching function for call to
'StackFrameStream::StackFrameStream(JavaThread*&)'
 310 |       StackFrameStream fst(deoptee);

-------------

Changes requested by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/119

From iklam at openjdk.java.net  Sat Oct 10 00:34:15 2020
From: iklam at openjdk.java.net (Ioi Lam)
Date: Sat, 10 Oct 2020 00:34:15 GMT
Subject: RFR: 8247536: Support for pre-generated java.lang.invoke classes
 in CDS static archive [v16]
In-Reply-To: <wirqKmwXPhh0CYqX2u48m0i_Y3gXLJ9gzGr43hRiUCA=.efc7649b-b2f2-4fdd-a471-45ffd44a2590@github.com>
References: <Y_Bas-poGnDtvcJbqbmeIAPQRNxzvarBToQWALn9TTE=.e846cd3c-0e7b-48d3-8ffa-be3c03acffb0@github.com>
 <wirqKmwXPhh0CYqX2u48m0i_Y3gXLJ9gzGr43hRiUCA=.efc7649b-b2f2-4fdd-a471-45ffd44a2590@github.com>
Message-ID: <HfpXXzGHCxhqrvktH0jbzE35JYLyjSU5t5sJlqyVFJc=.b4ee44c7-aeeb-4a3c-9a1f-078e39b50643@github.com>

On Sat, 10 Oct 2020 00:08:26 GMT, Yumin Qi <minqi at openjdk.org> wrote:

>> This patch is reorganized after 8252725, which is separated from this patch to refactor jlink glugin code. The previous
>> webrev with hg can be found at: http://cr.openjdk.java.net/~minqi/2020/8247536/webrev-05. With 8252725 integrated, the
>> regeneration of holder classes is simply to call the new added GenerateJLIClassesHelper.cdsGenerateHolderClasses
>> function.  Tests: tier1-4
>
> Yumin Qi has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Correct typo for check message
>  - Removed try/catch from java side and moved output to vm.
>  - Make change to original indent

Latest version LGTM.

-------------

Marked as reviewed by iklam (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/193

From minqi at openjdk.java.net  Sat Oct 10 02:11:12 2020
From: minqi at openjdk.java.net (Yumin Qi)
Date: Sat, 10 Oct 2020 02:11:12 GMT
Subject: Integrated: 8247536: Support for pre-generated java.lang.invoke
 classes in CDS static archive
In-Reply-To: <Y_Bas-poGnDtvcJbqbmeIAPQRNxzvarBToQWALn9TTE=.e846cd3c-0e7b-48d3-8ffa-be3c03acffb0@github.com>
References: <Y_Bas-poGnDtvcJbqbmeIAPQRNxzvarBToQWALn9TTE=.e846cd3c-0e7b-48d3-8ffa-be3c03acffb0@github.com>
Message-ID: <njqivSde9bCz5818yy5-X6QhCuIZrySbeua9tBw4OZI=.2e0187a8-273f-49b8-a553-d58765f074ee@github.com>

On Tue, 15 Sep 2020 18:57:55 GMT, Yumin Qi <minqi at openjdk.org> wrote:

> This patch is reorganized after 8252725, which is separated from this patch to refactor jlink glugin code. The previous
> webrev with hg can be found at: http://cr.openjdk.java.net/~minqi/2020/8247536/webrev-05. With 8252725 integrated, the
> regeneration of holder classes is simply to call the new added GenerateJLIClassesHelper.cdsGenerateHolderClasses
> function.  Tests: tier1-4

This pull request has now been integrated.

Changeset: e4469d2c
Author:    Yumin Qi <minqi at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e4469d2c
Stats:     551 lines in 22 files changed: 531 ins; 14 del; 6 mod

8247536: Support for pre-generated java.lang.invoke classes in CDS static archive

Reviewed-by: iklam, mchung

-------------

PR: https://git.openjdk.java.net/jdk/pull/193

From fyang at openjdk.java.net  Sat Oct 10 02:56:17 2020
From: fyang at openjdk.java.net (Fei Yang)
Date: Sat, 10 Oct 2020 02:56:17 GMT
Subject: RFR: 8252204: AArch64: Implement SHA3 accelerator/intrinsic [v6]
In-Reply-To: <PJVtIubjiGKhCK81PIMhWuYxnR84DNieMDUGHdhHYZM=.ad903c93-c5e3-4614-9af1-d36bc33f735d@github.com>
References: <PJVtIubjiGKhCK81PIMhWuYxnR84DNieMDUGHdhHYZM=.ad903c93-c5e3-4614-9af1-d36bc33f735d@github.com>
Message-ID: <EB5F888yvVUgoIhfV54T16q88GJ5aLiTVDVgnWnCwI8=.9c3e0b8d-11c6-4638-ae42-5e4656b5c57e@github.com>

> Contributed-by: ard.biesheuvel at linaro.org, dongbo4 at huawei.com
> 
> This added an intrinsic for SHA3 using aarch64 v8.2 SHA3 Crypto Extensions.
> Reference implementation for core SHA-3 transform using ARMv8.2 Crypto Extensions:
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm64/crypto/sha3-ce-core.S?h=v5.4.52
> 
> Trivial adaptation in SHA3. implCompress is needed for the purpose of adding the intrinsic.
> For SHA3, we need to pass one extra parameter "digestLength" to the stub for the calculation of block size.
> "digestLength" is also used in for the EOR loop before keccak to differentiate different SHA3 variants.
> 
> We added jtreg tests for SHA3 and used QEMU system emulator which supports SHA3 instructions to test the functionality.
> Patch passed jtreg tier1-3 tests with QEMU system emulator.
> Also verified with jtreg tier1-3 tests without SHA3 instructions on aarch64-linux-gnu and x86_64-linux-gnu, to make
> sure that there's no regression.
> We used one existing JMH test for performance test: test/micro/org/openjdk/bench/java/security/MessageDigests.java
> We measured the performance benefit with an aarch64 cycle-accurate simulator.
> Patch delivers 20% - 40% performance improvement depending on specific SHA3 digest length and size of the message.
> 
> For now, this feature will not be enabled automatically for aarch64. We can auto-enable this when it is fully tested on
> real hardware.  But for the above testing purposes, this is auto-enabled when the corresponding hardware feature is
> detected.

Fei Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains
seven commits:

 - Merge master
 - Merge master
 - Add sha3 instructions to cpu/aarch64/aarch64-asmtest.py and regenerate the test in assembler_aarch64.cpp:asm_check
 - Rebase
 - Merge master
 - Fix trailing whitespace issue
 - 8252204: AArch64: Implement SHA3 accelerator/intrinsic
   Contributed-by: ard.biesheuvel at linaro.org, dongbo4 at huawei.com

-------------

Changes: https://git.openjdk.java.net/jdk/pull/207/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=207&range=05
  Stats: 1512 lines in 35 files changed: 1025 ins; 22 del; 465 mod
  Patch: https://git.openjdk.java.net/jdk/pull/207.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/207/head:pull/207

PR: https://git.openjdk.java.net/jdk/pull/207

From fyang at openjdk.java.net  Sat Oct 10 06:16:17 2020
From: fyang at openjdk.java.net (Fei Yang)
Date: Sat, 10 Oct 2020 06:16:17 GMT
Subject: RFR: 8252204: AArch64: Implement SHA3 accelerator/intrinsic [v7]
In-Reply-To: <PJVtIubjiGKhCK81PIMhWuYxnR84DNieMDUGHdhHYZM=.ad903c93-c5e3-4614-9af1-d36bc33f735d@github.com>
References: <PJVtIubjiGKhCK81PIMhWuYxnR84DNieMDUGHdhHYZM=.ad903c93-c5e3-4614-9af1-d36bc33f735d@github.com>
Message-ID: <o4nLY_lX5GQZficBTSBKL36__mk9d_Rdftxy7KFR_IQ=.ea6bc73a-9184-48bb-be8e-cf44fd40312a@github.com>

> Contributed-by: ard.biesheuvel at linaro.org, dongbo4 at huawei.com
> 
> This added an intrinsic for SHA3 using aarch64 v8.2 SHA3 Crypto Extensions.
> Reference implementation for core SHA-3 transform using ARMv8.2 Crypto Extensions:
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm64/crypto/sha3-ce-core.S?h=v5.4.52
> 
> Trivial adaptation in SHA3. implCompress is needed for the purpose of adding the intrinsic.
> For SHA3, we need to pass one extra parameter "digestLength" to the stub for the calculation of block size.
> "digestLength" is also used in for the EOR loop before keccak to differentiate different SHA3 variants.
> 
> We added jtreg tests for SHA3 and used QEMU system emulator which supports SHA3 instructions to test the functionality.
> Patch passed jtreg tier1-3 tests with QEMU system emulator.
> Also verified with jtreg tier1-3 tests without SHA3 instructions on aarch64-linux-gnu and x86_64-linux-gnu, to make
> sure that there's no regression.
> We used one existing JMH test for performance test: test/micro/org/openjdk/bench/java/security/MessageDigests.java
> We measured the performance benefit with an aarch64 cycle-accurate simulator.
> Patch delivers 20% - 40% performance improvement depending on specific SHA3 digest length and size of the message.
> 
> For now, this feature will not be enabled automatically for aarch64. We can auto-enable this when it is fully tested on
> real hardware.  But for the above testing purposes, this is auto-enabled when the corresponding hardware feature is
> detected.

Fei Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains
eight commits:

 - Merge master
 - Merge master
 - Merge master
 - Add sha3 instructions to cpu/aarch64/aarch64-asmtest.py and regenerate the test in assembler_aarch64.cpp:asm_check
 - Rebase
 - Merge master
 - Fix trailing whitespace issue
 - 8252204: AArch64: Implement SHA3 accelerator/intrinsic
   Contributed-by: ard.biesheuvel at linaro.org, dongbo4 at huawei.com

-------------

Changes: https://git.openjdk.java.net/jdk/pull/207/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=207&range=06
  Stats: 1512 lines in 35 files changed: 1025 ins; 22 del; 465 mod
  Patch: https://git.openjdk.java.net/jdk/pull/207.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/207/head:pull/207

PR: https://git.openjdk.java.net/jdk/pull/207

From jbhateja at openjdk.java.net  Sat Oct 10 06:32:12 2020
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Sat, 10 Oct 2020 06:32:12 GMT
Subject: Integrated: 8252847: Optimize primitive arrayCopy stubs using AVX-512
 masked instructions
In-Reply-To: <s3XJ1KwOB0mtBpkLYMuA7J8ftplOmHLqr8IwSeXrCg4=.4fe22fd0-8780-4d1e-a628-465e314ac31d@github.com>
References: <s3XJ1KwOB0mtBpkLYMuA7J8ftplOmHLqr8IwSeXrCg4=.4fe22fd0-8780-4d1e-a628-465e314ac31d@github.com>
Message-ID: <_mGWUOZH852Ad58rrDEF6citxojOAY1Q-NU0BOWgVME=.2fcb9893-8f93-4f3b-a21b-f2f98069a971@github.com>

On Mon, 7 Sep 2020 14:28:18 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Summary:
> 
> 1)  New AVX3 optimized stubs for both conjoint and disjoint arraycopy.
> 2)  Special instruction sequence blocks for copy sizes b/w 32-192 bytes.
> 3)  Block copy operation above 192 bytes is performed using destination address aligned PRE-MAIN-POST loop. Main loop
> copies 192 byte in one iteration and tail part fall over special instruction sequence blocks. 4)  Both small copy block
> and aligned loop use 32 byte vector register to prevent and frequency penalty for copy sizes less than AVX3Threshold.
> 5)  For block size above AVX3Theshold both special blocks and loop operate using 64 byte register. 6)  In case user
> sets the maximum vector size to 32 bytes, forward copy (disjoint) operations are done using efficient REP MOVS for copy
> sizes above 4096 bytes.  JMH Results:
>   System     :  CascadeLake Server, Intel(R) Xeon(R) Platinum 8280L CPU @ 2.70GHz
>   Micros     :  test/micro/org/openjdk/bench/java/lang/ArrayCopy*.java
>   Baseline   :  [http://cr.openjdk.java.net/~jbhateja/8252847/JMH_results/ArrayCopy_AVX3_Stubs_Baseline.txt]()
>   WithOpt  :  [http://cr.openjdk.java.net/~jbhateja/8252847/JMH_results/ArrayCopy_AVX3_Stubs_WithOpts.txt]()

This pull request has now been integrated.

Changeset: 4b5ac3ab
Author:    Jatin Bhateja <jbhateja at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/4b5ac3ab
Stats:     1517 lines in 11 files changed: 1419 ins; 69 del; 29 mod

8252847: Optimize primitive arrayCopy stubs using AVX-512 masked instructions

Reviewed-by: neliasso, kvn

-------------

PR: https://git.openjdk.java.net/jdk/pull/61

From rrich at openjdk.java.net  Sat Oct 10 08:34:23 2020
From: rrich at openjdk.java.net (Richard Reingruber)
Date: Sat, 10 Oct 2020 08:34:23 GMT
Subject: RFR: 8227745: Enable Escape Analysis for Better Performance in
 the Presence of JVMTI Agents [v10]
In-Reply-To: <Ll2RereRbuQLgFtIjv9pS92kPvCVuo-BI0cP1zGjVbo=.dad3a33c-0fc3-44fd-810a-f01448cf564c@github.com>
References: <Ll2RereRbuQLgFtIjv9pS92kPvCVuo-BI0cP1zGjVbo=.dad3a33c-0fc3-44fd-810a-f01448cf564c@github.com>
Message-ID: <XaPrmpfi96mMRQnto6zzZlsZeDP0jMR7LAosjDmm0Zw=.12c89fb1-a267-468b-966b-065f97aa2f28@github.com>

> Hi,
> 
> this is the continuation of the review of the implementation for:
> 
> https://bugs.openjdk.java.net/browse/JDK-8227745
> https://bugs.openjdk.java.net/browse/JDK-8233915
> 
> It allows for JIT optimizations based on escape analysis even if JVMTI agents acquire capabilities to access references
> to objects that are subject to such optimizations, e.g. scalar replacement. The implementation reverts such
> optimizations just before access very much as when switching from JIT compiled execution to the interpreter, aka
> "deoptimization".  Webrev.8 was the last one before before the transition to Git/Github:
> 
> http://cr.openjdk.java.net/~rrich/webrevs/8227745/webrev.8/
> 
> Thanks, Richard.

Richard Reingruber has updated the pull request with a new target base due to a merge or a rebase. The pull request now
contains 21 commits:

 - The constructor of StackFrameStream takes more parameters after JDK-8253180
 - Merge branch 'master' into JDK-8227745
 - Merge branch 'master' into JDK-8227745
 - Merge branch 'master' into JDK-8227745
 - Factorized fragment out of EscapeBarrier::deoptimize_objects_internal into new method in compiledVFrame.
 - More smaller changes proposed by Serguei.
 - jvmtiDeferredUpdates.hpp: remove forward declarations.
 - jvmtiDeferredLocalVariable: move member variables to the beginning of the class definition.
 - jvmtiDeferredUpdates.hpp: add/remove empty lines and improve indentation.
 - Merge branch 'master' into JDK-8227745
 - ... and 11 more: https://git.openjdk.java.net/jdk/compare/aaa0a2a0...06b139a9

-------------

Changes: https://git.openjdk.java.net/jdk/pull/119/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=119&range=09
  Stats: 5814 lines in 52 files changed: 5595 ins; 116 del; 103 mod
  Patch: https://git.openjdk.java.net/jdk/pull/119.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/119/head:pull/119

PR: https://git.openjdk.java.net/jdk/pull/119

From rrich at openjdk.java.net  Sat Oct 10 08:37:12 2020
From: rrich at openjdk.java.net (Richard Reingruber)
Date: Sat, 10 Oct 2020 08:37:12 GMT
Subject: RFR: 8227745: Enable Escape Analysis for Better Performance in
 the Presence of JVMTI Agents [v9]
In-Reply-To: <yaiYe--Do-AkvXtvTEVzj9JUbnXNaZLIonfUTfP-g1g=.05256ac4-70b2-4cbc-801b-b918191e2658@github.com>
References: <Ll2RereRbuQLgFtIjv9pS92kPvCVuo-BI0cP1zGjVbo=.dad3a33c-0fc3-44fd-810a-f01448cf564c@github.com>
 <5O9n8cKBJyjhp2cNOVD2PcpKQiXqEs5BJjkW1lH-5EM=.044a510e-6517-4564-a3db-00c7951f0b22@github.com>
 <yaiYe--Do-AkvXtvTEVzj9JUbnXNaZLIonfUTfP-g1g=.05256ac4-70b2-4cbc-801b-b918191e2658@github.com>
Message-ID: <MXY--utlGLdEERjPFTJNWEYV9KDZph77IxBOYOa4crA=.81dc225f-6a7c-4512-b53e-529be60e29bc@github.com>

On Sat, 10 Oct 2020 00:01:49 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> 
> 
> Compiler changes seems fine.

Thank you for looking again at this.

-------------

PR: https://git.openjdk.java.net/jdk/pull/119

From rrich at openjdk.java.net  Sat Oct 10 09:05:11 2020
From: rrich at openjdk.java.net (Richard Reingruber)
Date: Sat, 10 Oct 2020 09:05:11 GMT
Subject: RFR: 8227745: Enable Escape Analysis for Better Performance in
 the Presence of JVMTI Agents [v9]
In-Reply-To: <kXS8IuV-hgsemXHvzdEUd3V5SPCzxY0ClFQQpL0aDLw=.7aef142a-acfa-4b3f-9568-5af89f7871df@github.com>
References: <Ll2RereRbuQLgFtIjv9pS92kPvCVuo-BI0cP1zGjVbo=.dad3a33c-0fc3-44fd-810a-f01448cf564c@github.com>
 <5O9n8cKBJyjhp2cNOVD2PcpKQiXqEs5BJjkW1lH-5EM=.044a510e-6517-4564-a3db-00c7951f0b22@github.com>
 <kXS8IuV-hgsemXHvzdEUd3V5SPCzxY0ClFQQpL0aDLw=.7aef142a-acfa-4b3f-9568-5af89f7871df@github.com>
Message-ID: <bUQfqefhgv1bsscHkiMJFA5bsVv1MELncEATFRgO_Po=.9c234693-366a-48b4-aa8c-8e1c7c476852@github.com>

On Sat, 10 Oct 2020 00:25:52 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> 
> 
> I tried to run testing with latest changes and latest JDK and build failed:
> src/hotspot/share/runtime/escapeBarrier.cpp:310:35: error: no matching function for call to
> 'StackFrameStream::StackFrameStream(JavaThread*&)' 310 | StackFrameStream fst(deoptee);

I noticed this too. I wanted to test with ZGC before pushing the small
fix. Unfortunately I get

#  Internal Error (/priv/d038402/git/reinrich/jdk_ea_new/src/hotspot/share/runtime/stackWatermark.inline.hpp:67),
pid=90890, tid=90912 #  assert(processing_started()) failed: Processing should already have started

[...]

Current thread (0x00007f749c25b1c0):  JavaThread "JDWP Transport Listener: dt_socket" daemon [_thread_in_vm, id=90912,
stack(0x00007f7474c9f000,0x00007f7474da0000)] _threads_hazard_ptr=0x00007f749c2b00c0, _nested_threads_hazard_ptr_cnt=0

Stack: [0x00007f7474c9f000,0x00007f7474da0000],  sp=0x00007f7474d9c240,  free space=1012k
Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x15b3255]  StackWatermarkSet::on_iteration(JavaThread*, frame const&)+0xa5
V  [libjvm.so+0xa1024f]  frame::sender(RegisterMap*) const+0x13f
V  [libjvm.so+0xa048f8]  frame::real_sender(RegisterMap*) const+0x18
V  [libjvm.so+0x176261b]  vframe::sender() const+0xeb
V  [libjvm.so+0x16cd56b]  JavaThread::last_java_vframe(RegisterMap*)+0x5b
V  [libjvm.so+0xfa7a56]  JvmtiEnvBase::vframeFor(JavaThread*, int)+0x46
V  [libjvm.so+0xfab8e5]  JvmtiEnvBase::check_top_frame(JavaThread*, JavaThread*, jvalue, TosState, Handle*)+0x1f5
V  [libjvm.so+0xfac13e]  JvmtiEnvBase::force_early_return(JavaThread*, jvalue, TosState)+0x15e
V  [libjvm.so+0xf36fa8]  jvmti_ForceEarlyReturnLong+0x258
C  [libjdwp.so+0xa8b3]  forceEarlyReturn+0x293
C  [libjdwp.so+0x12945]  debugLoop_run+0x1f5
C  [libjdwp.so+0x25bb3]  attachThread+0x33
V  [libjvm.so+0xfcf524]  JvmtiAgentThread::call_start_function()+0x1d4
V  [libjvm.so+0x16cc8f7]  JavaThread::thread_main_inner()+0x247
V  [libjvm.so+0x16d1ce8]  Thread::call_run()+0xf8
V  [libjvm.so+0x12dd75e]  thread_native_entry(Thread*)+0x10e

In the test case
`EAForceEarlyReturnOfInlinedMethodWithScalarReplacedObjectsReallocFailure` of the
new test `jdk/com/sun/jdi/EATests.java`

So far I do not have an indication that the failure is caused by this change but
when I run the test with -XX:-DoEscapeAnalysis then the test succeeds.

I need to look more into it. Wish I was a ZGC expert :)

Anyway I pushed the build fix. Tests succeed with default GC.

-------------

PR: https://git.openjdk.java.net/jdk/pull/119

From fyang at openjdk.java.net  Sat Oct 10 13:09:11 2020
From: fyang at openjdk.java.net (Fei Yang)
Date: Sat, 10 Oct 2020 13:09:11 GMT
Subject: RFR: 8252204: AArch64: Implement SHA3 accelerator/intrinsic [v5]
In-Reply-To: <4NM17B6l4GvNgCbmmQTUcnfZTA6G-IEc85O8jH_q-xA=.63b10da7-bab7-44bc-a4c8-0a675aca45c0@github.com>
References: <PJVtIubjiGKhCK81PIMhWuYxnR84DNieMDUGHdhHYZM=.ad903c93-c5e3-4614-9af1-d36bc33f735d@github.com>
 <nR6wQq3N8OnxHsAdAzQ2mIh6RZQ_b7H_M51Y9Eng3J4=.90d276d3-8b4b-427c-a075-bb7db96e37cb@github.com>
 <A5RkMquxaW1OuuiPTpD1wz7pBMcjxU7roLU5wD3cH8E=.0211f34f-eb8b-4b93-8072-82ac1a894019@github.com>
 <4NM17B6l4GvNgCbmmQTUcnfZTA6G-IEc85O8jH_q-xA=.63b10da7-bab7-44bc-a4c8-0a675aca45c0@github.com>
Message-ID: <7CXYOoHPTvfS6YvwFjdlO27rQKRbDu3_QSGP7vDuyDs=.41789630-e05f-4f8a-8562-ad8bb74e12aa@github.com>

On Fri, 9 Oct 2020 17:35:22 GMT, Andrew Haley <aph at openjdk.org> wrote:

> I see Linux x64 failed. However, I don't seem to be able to withdraw my patch approval.
> However, please consider it withdrawn.

Thanks for approving this patch.
I checked the error messages and I think the failures were not caused by this patch.
The failures has been fixed by the following two commits:
    commit ec41046c5ce7077eebf4a3c265f79c7fba33d916
    8254348: Build fails when cds is disabled after JDK-8247536
    commit aaa0a2a04792d7c84150e9d972790978ffcc6890
    8254297: Zero and Minimal VMs are broken with undeclared identifier 'DerivedPointerTable' after JDK-8253180

The testing was triggered again automatically after I merge master and I see it passed now.
Do you have any comments for the discussion here?
    https://github.com/openjdk/jdk/pull/207#issuecomment-701243662

Valerie Peng has checked the java security changes, i.e. src/java.base/share/classes/sun/security/provider/SHA3.java.
Do you think we need another reviewer for this patch?

-------------

PR: https://git.openjdk.java.net/jdk/pull/207

From kcr at openjdk.java.net  Sat Oct 10 13:19:09 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Sat, 10 Oct 2020 13:19:09 GMT
Subject: RFR: 8252204: AArch64: Implement SHA3 accelerator/intrinsic [v5]
In-Reply-To: <4NM17B6l4GvNgCbmmQTUcnfZTA6G-IEc85O8jH_q-xA=.63b10da7-bab7-44bc-a4c8-0a675aca45c0@github.com>
References: <PJVtIubjiGKhCK81PIMhWuYxnR84DNieMDUGHdhHYZM=.ad903c93-c5e3-4614-9af1-d36bc33f735d@github.com>
 <nR6wQq3N8OnxHsAdAzQ2mIh6RZQ_b7H_M51Y9Eng3J4=.90d276d3-8b4b-427c-a075-bb7db96e37cb@github.com>
 <A5RkMquxaW1OuuiPTpD1wz7pBMcjxU7roLU5wD3cH8E=.0211f34f-eb8b-4b93-8072-82ac1a894019@github.com>
 <4NM17B6l4GvNgCbmmQTUcnfZTA6G-IEc85O8jH_q-xA=.63b10da7-bab7-44bc-a4c8-0a675aca45c0@github.com>
Message-ID: <lcceWzrMnnFAHnmt-QcVqHWkn43cVpDDM0Q-5GuUCKk=.b0b4ea48-bdb1-4e4c-83e0-feaf5176685d@github.com>

On Fri, 9 Oct 2020 17:35:22 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Marked as reviewed by aph (Reviewer).
>
> I see Linux x64 failed. However, I don't seem to be able to withdraw my patch approval.
> However, please consider it withdrawn.

@theRealAph if you still need to, you can withdraw your approval by reviewing it again and selecting "Request changes".

-------------

PR: https://git.openjdk.java.net/jdk/pull/207

From darcy at openjdk.java.net  Sat Oct 10 16:57:09 2020
From: darcy at openjdk.java.net (Joe Darcy)
Date: Sat, 10 Oct 2020 16:57:09 GMT
Subject: RFR: 8253455: Record Classes javax.lang.model changes [v6]
In-Reply-To: <9n4YsX6h1Er-183zkPoyr6R4PPgswFZTCORS2K8Ky-c=.3c4dd522-de88-4428-a4d5-4e6b042d6409@github.com>
References: <_EiRbvHonuflkmP-H77rZp9DQCpMs74zdWG3aO0_z0U=.c3b70b2f-75f2-4638-a4b4-a911e3f0851f@github.com>
 <9n4YsX6h1Er-183zkPoyr6R4PPgswFZTCORS2K8Ky-c=.3c4dd522-de88-4428-a4d5-4e6b042d6409@github.com>
Message-ID: <MYco-KtWOjjh-5yqLUpvwQTn1TS5zPMWBYuFydtCzhU=.e8cd2d22-e73e-4661-a513-fa198bf59d7a@github.com>

On Fri, 9 Oct 2020 21:19:23 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Please review the fix for [JDK-8253455](https://bugs.openjdk.java.net/browse/JDK-8253455) which is part of the effort
>> to make records a final feature of the Java Language. The rest of the code has been published in
>> [PR#290](https://github.com/openjdk/jdk/pull/290)  Thanks,
>> Vicente
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updating @since from 14 to 16

Marked as reviewed by darcy (Reviewer).

src/java.base/share/classes/jdk/internal/PreviewFeature.java line 65:

> 63:         // necessary for PreviewFeature in JDK 15 to declare the enum constant.
> 64:         TEXT_BLOCKS,
> 65:         /*

It doesn't really matter, but it would look more consistent if TEXT_BLOCKS and RECORDS used the same kind of comment
syntax.

-------------

PR: https://git.openjdk.java.net/jdk/pull/291

From vromero at openjdk.java.net  Sat Oct 10 18:21:22 2020
From: vromero at openjdk.java.net (Vicente Romero)
Date: Sat, 10 Oct 2020 18:21:22 GMT
Subject: RFR: 8253455: Record Classes javax.lang.model changes [v7]
In-Reply-To: <_EiRbvHonuflkmP-H77rZp9DQCpMs74zdWG3aO0_z0U=.c3b70b2f-75f2-4638-a4b4-a911e3f0851f@github.com>
References: <_EiRbvHonuflkmP-H77rZp9DQCpMs74zdWG3aO0_z0U=.c3b70b2f-75f2-4638-a4b4-a911e3f0851f@github.com>
Message-ID: <UkdDSGW829ADrgKYx9l9_eYVDIHJWuJ8GOPXCNQ00oI=.e5a01fa7-faa7-4cb5-8b77-4279e463f6e2@github.com>

> Please review the fix for [JDK-8253455](https://bugs.openjdk.java.net/browse/JDK-8253455) which is part of the effort
> to make records a final feature of the Java Language. The rest of the code has been published in
> [PR#290](https://github.com/openjdk/jdk/pull/290)  Thanks,
> Vicente

Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:

  updating comment syntax for Feature.RECORDS

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/291/files
  - new: https://git.openjdk.java.net/jdk/pull/291/files/cd27384d..a0373100

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=291&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=291&range=05-06

  Stats: 7 lines in 1 file changed: 0 ins; 2 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/291.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/291/head:pull/291

PR: https://git.openjdk.java.net/jdk/pull/291

From vromero at openjdk.java.net  Sat Oct 10 18:21:23 2020
From: vromero at openjdk.java.net (Vicente Romero)
Date: Sat, 10 Oct 2020 18:21:23 GMT
Subject: RFR: 8253455: Record Classes javax.lang.model changes [v6]
In-Reply-To: <MYco-KtWOjjh-5yqLUpvwQTn1TS5zPMWBYuFydtCzhU=.e8cd2d22-e73e-4661-a513-fa198bf59d7a@github.com>
References: <_EiRbvHonuflkmP-H77rZp9DQCpMs74zdWG3aO0_z0U=.c3b70b2f-75f2-4638-a4b4-a911e3f0851f@github.com>
 <9n4YsX6h1Er-183zkPoyr6R4PPgswFZTCORS2K8Ky-c=.3c4dd522-de88-4428-a4d5-4e6b042d6409@github.com>
 <MYco-KtWOjjh-5yqLUpvwQTn1TS5zPMWBYuFydtCzhU=.e8cd2d22-e73e-4661-a513-fa198bf59d7a@github.com>
Message-ID: <yY0RQml0-xINVv6KbrvUTkG1Mfc9LhAnu1S-4s5pEN0=.2031412e-4be4-42a9-8930-e1b761128dc2@github.com>

On Sat, 10 Oct 2020 16:54:06 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   updating @since from 14 to 16
>
> src/java.base/share/classes/jdk/internal/PreviewFeature.java line 65:
> 
>> 63:         // necessary for PreviewFeature in JDK 15 to declare the enum constant.
>> 64:         TEXT_BLOCKS,
>> 65:         /*
> 
> It doesn't really matter, but it would look more consistent if TEXT_BLOCKS and RECORDS used the same kind of comment
> syntax.

thanks for the comment, I have uploaded commit
[a037310](https://github.com/openjdk/jdk/pull/291/commits/a03731005bae069a18e4ef2f0dced7019c2a4081) to fix this

-------------

PR: https://git.openjdk.java.net/jdk/pull/291

From rrich at openjdk.java.net  Sun Oct 11 07:23:15 2020
From: rrich at openjdk.java.net (Richard Reingruber)
Date: Sun, 11 Oct 2020 07:23:15 GMT
Subject: RFR: 8227745: Enable Escape Analysis for Better Performance in
 the Presence of JVMTI Agents [v9]
In-Reply-To: <bUQfqefhgv1bsscHkiMJFA5bsVv1MELncEATFRgO_Po=.9c234693-366a-48b4-aa8c-8e1c7c476852@github.com>
References: <Ll2RereRbuQLgFtIjv9pS92kPvCVuo-BI0cP1zGjVbo=.dad3a33c-0fc3-44fd-810a-f01448cf564c@github.com>
 <5O9n8cKBJyjhp2cNOVD2PcpKQiXqEs5BJjkW1lH-5EM=.044a510e-6517-4564-a3db-00c7951f0b22@github.com>
 <kXS8IuV-hgsemXHvzdEUd3V5SPCzxY0ClFQQpL0aDLw=.7aef142a-acfa-4b3f-9568-5af89f7871df@github.com>
 <bUQfqefhgv1bsscHkiMJFA5bsVv1MELncEATFRgO_Po=.9c234693-366a-48b4-aa8c-8e1c7c476852@github.com>
Message-ID: <loXsS2Do_nv5-_VbltTan-Imb1whQGFhtV26DygFkfE=.8901efc3-eaff-45e3-ae8e-7d4c1f1f7d5b@github.com>

On Sat, 10 Oct 2020 09:01:22 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> I tried to run testing with latest changes and latest JDK and build failed:
>> src/hotspot/share/runtime/escapeBarrier.cpp:310:35: error: no matching function for call to
>> 'StackFrameStream::StackFrameStream(JavaThread*&)'
>>  310 |       StackFrameStream fst(deoptee);
>
>> 
>> 
>> I tried to run testing with latest changes and latest JDK and build failed:
>> src/hotspot/share/runtime/escapeBarrier.cpp:310:35: error: no matching function for call to
>> 'StackFrameStream::StackFrameStream(JavaThread*&)' 310 | StackFrameStream fst(deoptee);
> 
> I noticed this too. I wanted to test with ZGC before pushing the small
> fix. Unfortunately I get
> 
> #  Internal Error (/priv/d038402/git/reinrich/jdk_ea_new/src/hotspot/share/runtime/stackWatermark.inline.hpp:67),
> pid=90890, tid=90912 #  assert(processing_started()) failed: Processing should already have started
> 
> [...]
> 
> Current thread (0x00007f749c25b1c0):  JavaThread "JDWP Transport Listener: dt_socket" daemon [_thread_in_vm, id=90912,
> stack(0x00007f7474c9f000,0x00007f7474da0000)] _threads_hazard_ptr=0x00007f749c2b00c0, _nested_threads_hazard_ptr_cnt=0
> Stack: [0x00007f7474c9f000,0x00007f7474da0000],  sp=0x00007f7474d9c240,  free space=1012k
> Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.so+0x15b3255]  StackWatermarkSet::on_iteration(JavaThread*, frame const&)+0xa5
> V  [libjvm.so+0xa1024f]  frame::sender(RegisterMap*) const+0x13f
> V  [libjvm.so+0xa048f8]  frame::real_sender(RegisterMap*) const+0x18
> V  [libjvm.so+0x176261b]  vframe::sender() const+0xeb
> V  [libjvm.so+0x16cd56b]  JavaThread::last_java_vframe(RegisterMap*)+0x5b
> V  [libjvm.so+0xfa7a56]  JvmtiEnvBase::vframeFor(JavaThread*, int)+0x46
> V  [libjvm.so+0xfab8e5]  JvmtiEnvBase::check_top_frame(JavaThread*, JavaThread*, jvalue, TosState, Handle*)+0x1f5
> V  [libjvm.so+0xfac13e]  JvmtiEnvBase::force_early_return(JavaThread*, jvalue, TosState)+0x15e
> V  [libjvm.so+0xf36fa8]  jvmti_ForceEarlyReturnLong+0x258
> C  [libjdwp.so+0xa8b3]  forceEarlyReturn+0x293
> C  [libjdwp.so+0x12945]  debugLoop_run+0x1f5
> C  [libjdwp.so+0x25bb3]  attachThread+0x33
> V  [libjvm.so+0xfcf524]  JvmtiAgentThread::call_start_function()+0x1d4
> V  [libjvm.so+0x16cc8f7]  JavaThread::thread_main_inner()+0x247
> V  [libjvm.so+0x16d1ce8]  Thread::call_run()+0xf8
> V  [libjvm.so+0x12dd75e]  thread_native_entry(Thread*)+0x10e
> 
> In the test case
> `EAForceEarlyReturnOfInlinedMethodWithScalarReplacedObjectsReallocFailure` of the
> new test `jdk/com/sun/jdi/EATests.java`
> 
> So far I do not have an indication that the failure is caused by this change but
> when I run the test with -XX:-DoEscapeAnalysis then the test succeeds.
> 
> I need to look more into it. Wish I was a ZGC expert :)
> 
> Anyway I pushed the build fix. Tests succeed with default GC.

The crash described above happens after JDK-8253180
(https://github.com/openjdk/jdk/commit/b9873e18330b7e43ca47bc1c0655e7ab20828f7a) when executing `EATests.java` with ZGC:

make run-test TEST=test/jdk/com/sun/jdi/EATests.java JTREG=VM_OPTIONS=-XX:+UseZGC

My understanding of JDK-8253180 (and ZGC) is rather vague. To me it looks as if stackwalks outside of a
safepoint/handshake on suspended threads are currently not supported. It would be my understanding that
`StackWatermarkSet::start_processing()` needs to be called before walking the stack of a thread. Currently this is only
done in preparation of a safepoint or handshake.

`JvmtiEnvBase::check_top_frame()` walks the stack of a suspended thread without safepoint/handshake. This triggers the
crash in my opinion. When `StackWatermarkSet::start_processing()` is called before the test succeeds.

I will ask Erik ?sterlund about this.

-------------

PR: https://git.openjdk.java.net/jdk/pull/119

From alanb at openjdk.java.net  Sun Oct 11 17:26:10 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sun, 11 Oct 2020 17:26:10 GMT
Subject: RFR: 8253952: Refine ZipOutputStream.putNextEntry() to
 recalculate ZipEntry's compressed size [v2]
In-Reply-To: <hY8lfhGTXizeHqM6iWX3eKDXz5B4-WHAFaZNvHLk6qc=.d9bf046e-f493-4653-94b1-39d154a4175e@github.com>
References: <0nq5oFKOj6AZqCW6jF268-6oKRI6UkS6TRIHo-_5vKw=.d13c7016-4473-4b20-9117-100b368d3716@github.com>
 <hY8lfhGTXizeHqM6iWX3eKDXz5B4-WHAFaZNvHLk6qc=.d9bf046e-f493-4653-94b1-39d154a4175e@github.com>
Message-ID: <Jd3oV6qV9tPRHCqKNnIjMaJx6kYi--G7oyykOL_w5qU=.8be45e77-2ea4-4e02-9a07-4f9ba53f6e59@github.com>

On Fri, 9 Oct 2020 10:28:34 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> ### Summary
>> 
>> Work around wrong usage of `ZipOutputStream.putNextEntry()` in user code which can lead to the `ZipException "invalid
>> entry compressed size"`.
>> ### Motivation
>> 
>> In general it is not safe to directly write a ZipEntry obtained from `ZipInputStream.getNextEntry()`,
>> `ZipFile.entries()`, `ZipFile.getEntry()` or `ZipFile.stream()` with `ZipOutputStream.putNextEntry()` to a
>> `ZipOutputStream` and then read the entries data from the `ZipInputStream` and write it to the `ZipOutputStream` as
>> follows:
>>  ZipEntry entry;
>>  ZipInputStream zis = new ZipInputStream(...);
>>  ZipOutputStream zos = new ZipOutputStream(...);
>>  while((entry = zis.getNextEntry()) != null) {
>>      zos.putNextEntry(entry);
>>      zis.transferTo(zos);
>>  }
>> The problem with this code is that the zip file format does not record the compression level used for deflation in its
>> entries. In general, it doesn't even mandate a predefined compression ratio per compression level. Therefore the
>> compressed size recorded in a `ZipEntry` read from a zip file might differ from the new compressed size produced by the
>> receiving `ZipOutputStream`. Such a difference will result in a `ZipException` with the following message:
>>  java.util.zip.ZipException: invalid entry compressed size (expected 12 but got 7 bytes)
>>  
>> The correct way of copying all entries from one zip file into another requires the creation of a new `ZipEntry` or at
>> least resetting of the compressed size field. E.g.:
>>  while((entry = zis.getNextEntry()) != null) {
>>      ZipEntry newEntry = new ZipEntry(entry.getName());
>>      zos.putNextEntry(newEntry);
>>      zis.transferTo(zos);
>>  }
>> or:
>>  while((entry = zis.getNextEntry()) != null) {
>>      entry.setCompressedSize(-1);
>>      zos.putNextEntry(entry);
>>      zis.transferTo(zos);
>>  }
>> Unfortunately, there's a lot of user code out there which gets this wrong and uses the bad coding pattern described
>> before. Searching for `"java.util.zip.ZipException: invalid entry compressed size (expected 12 but got 7 bytes)"` gives
>> ~2500 hits (~100 on StackOverflow). It's also no hard to find plenty of instances of this anti-pattern on GitHub when
>> doing a code search for `ZipEntry` and `putNextEntry()`. E.g. [Gradle 4.x wrapper task][1] is affected as well as the
>> latest version of the [mockableAndroidJar task][2]. I've recently fixed two occurrences of this pattern in OpenJDK (see
>> [JDK-8240333][3] and [JDK-8240235][4]) but there still exist more of them (e.g.
>> [`test/jdk/java/util/zip/ZipFile/CopyJar.java`][5] which is there since 1999 :).  ### Description  So while this has
>> clearly been a problem before, it apparently wasn't painful enough to trigger any action from the side of the JDK.
>> However, recently quite some zlib forks with [superior deflate/inflate performance have evolved][6]. Using them with
>> OpenJDK is quite straight-forward: one just has to configure the alternative implementations by setting
>> `LD_LIBRARY_PATH` or `LD_PRELOAD` correspondingly. We've seen big saving by using these new zlib implementations for
>> selected services in production and the only reason why we haven't enabled them by default until now is the problem
>> I've just described. The reason why these new libraries uncover the described anti-pattern much more often is because
>> their compression ratio is slightly different from that of the default zlib library. This can easily trigger a
>> `ZipException` even if an application is not using a different compression levels but just a zip file created with
>> another zlib version.  I'd therefore like to propose the following workaround for the wrong
>> `ZipOutputStream.putNextEntry()` usage in user code:
>> -  ignore the compressed size if it was implicitly determined from the zip file and not explicitly set by calling
>>    `ZipEntry.setCompressedSize()`.
>> 
>> - Change the API-documentation of `ZipOutputStream.putNextEntry()` and `JarOutputStream.putNextEntry()` to explain the
>>   problem and why `putNextEntry()` will ignore the compressed size of a `ZipEntry` if that was set implicitely when
>>   reading that entry from a `ZipFile` or `ZipInputStream`.
>> 
>> 
>> ### Technical Details
>> 
>> A zip file consists of a stream of File Entries followed by a Central Directory (see [here for a more detailed
>> specification][7]). Each File Entry is composed of a Local File Header (LFH) followed by the compressed Data and an
>> optional Data Descriptor. The LFH contains the File Name and among other attributes the Compressed and Uncompressed
>> size and CRC of the Data. In the case where the latter three attributes are not available at the time when the LFH is
>> created, this fact will be recorded in a flag of the LFH and will trigger the creation of a Data Descriptor with the
>> corresponding information right after the Data section. Finally, the Central Directory contains one Central Directory
>> File Header (CDFH) for each entry of the  zip archive. The CDFH is an extended version of the LFH and the ultimate
>> reference for the contents of the zip archive. The redundancy between LFH and CDFH is a tribute to zip's long history
>> when it was used to store archives on multiple floppy discs and the CDFH allowed to update the archive by only writing
>> to the last disc which contained the Central Directory.  `ZipEntries` read with `ZipInputStream.getNextEntry()` will
>> initially only contain the information from the LFH. Only after the next entry was read (or after
>> `ZipInputStream.closeEntry()` was called explicitly), will the previously read entry be updated with the data from the
>> Data Descriptor. `ZipInputStream` doesn't inspect the Central Directory at all.  On the other hand, `ZipFile` only
>> queries the Central Directory for `ZipEntry` information so all `ZipEntries` returned by `ZipFile.entries()`,
>> `ZipFile.getEntry()` and `ZipFile.stream()` will always instantly contain the full Compressed and Uncompressed Size and
>> CRC information for each entry independently of the LFH contents.  ### Risks and Assumptions  If we choose to ignore
>> the implicitly recorded compressed size in a `ZipEntry` read from a zip file when writing it to a `ZipOutputStream`,
>> this will lead to zip files with incomplete information in the LFH and an additional Data Descriptor as described
>> before. However, the result is still fully compatible to the zip file specification. It's also not unusual, because by
>> default all new zip files created with `ZipOutputStream` will contain LFHs without Compressed and Uncompressed Size and
>> CRC information and an additional Data Descriptor. Theoretically it is possible to create new zip files with
>> `ZipOutputStream` class and Compressed and Uncompressed Size and CRC information in the LFH but that's complex and
>> inefficient because it requires two steps. A first step to determine the crc and compressed size of the data and a
>> second step to actually write the data to the `ZipOutputStream` (which will compress it a second time). This is because
>> the current API offers no possibility to write already compressed data to a `ZipOutputStream`.  Consequently, the only
>> straight-forward way of creating zip files from Java which have all the data in the LFH and no Data Descriptor is by
>> copying `ZipEntries` from an existing zip file with the buggy method described before. This incidentally worked more or
>> less reliable for a long time but breaks miserably when using different zlib implementations. Ignoring the implicitly
>> set compressed size of `ZipEntries` can easily fix this problem.  I'm not aware of any tool which can not handle such
>> files and if it exists it would have problems with the majority of Java created zip files anyway (e.g. all jar-files
>> created with the jar tool have zip entries with incomplete LFH data and additional Data Descriptor).  Ignoring the
>> implicitly set compressed size of `ZipEntries` has no measurable performance impact and will increase the size of zip
>> archives which used to have the complete file information in the LFH before by 16 bytes per entry. On the other hand it
>> will give us the freedom to use whatever zip implementation we like :)   [1]:
>> https://github.com/gradle/gradle/blob/e76905e3a/subprojects/build-init/src/main/java/org/gradle/api/tasks/wrapper/Wrapper.java#L152-L158
>> [2]:
>> https://android.googlesource.com/platform/tools/base/+/refs/heads/master/build-system/builder/src/main/java/com/android/builder/testing/MockableJarGenerator.java#86
>> [3]: https://bugs.openjdk.java.net/browse/JDK-8240333 [4]: https://bugs.openjdk.java.net/browse/JDK-8240235 [5]:
>> https://github.com/openjdk/jdk/blob/master/test/jdk/java/util/zip/ZipFile/CopyJar.java [6]:
>> https://github.com/simonis/zlib-bench/blob/master/Results.md [7]: https://en.wikipedia.org/wiki/Zip_(file_format)
>
> Volker Simonis has refreshed the contents of this pull request, and previous commits have been removed. The incremental
> views will show differences compared to the previous content of the PR.

src/java.base/share/classes/java/util/zip/ZipOutputStream.java line 189:

> 187:      * {@code ZipEntry.DEFLATED}) entries when {@link ZipEntry#setCompressedSize(long)}
> 188:      * has not been explicitly called on the {@code ZipEntry}.
> 189:      *

Here's an alternative that might be a bit clearer to readers.

"When writing a compressed (deflated) entry, and the compressed size has not been explicitly set with the
setCompressedSize method, then the compressed size written to the entry's data descriptor will be its actual compressed
size."

I think we should put it after the "The default compression method .." sentence and move the sentence on the time stamp
to the end.

-------------

PR: https://git.openjdk.java.net/jdk/pull/520

From lancea at openjdk.java.net  Sun Oct 11 22:17:11 2020
From: lancea at openjdk.java.net (Lance Andersen)
Date: Sun, 11 Oct 2020 22:17:11 GMT
Subject: RFR: 8253952: Refine ZipOutputStream.putNextEntry() to
 recalculate ZipEntry's compressed size [v2]
In-Reply-To: <Jd3oV6qV9tPRHCqKNnIjMaJx6kYi--G7oyykOL_w5qU=.8be45e77-2ea4-4e02-9a07-4f9ba53f6e59@github.com>
References: <0nq5oFKOj6AZqCW6jF268-6oKRI6UkS6TRIHo-_5vKw=.d13c7016-4473-4b20-9117-100b368d3716@github.com>
 <hY8lfhGTXizeHqM6iWX3eKDXz5B4-WHAFaZNvHLk6qc=.d9bf046e-f493-4653-94b1-39d154a4175e@github.com>
 <Jd3oV6qV9tPRHCqKNnIjMaJx6kYi--G7oyykOL_w5qU=.8be45e77-2ea4-4e02-9a07-4f9ba53f6e59@github.com>
Message-ID: <6RMxyurj4wb-oTldhToZhDebkRlbFrSTPzAWnhcni0Q=.457787d6-d1fe-455d-9ade-03e01c099db9@github.com>

On Sun, 11 Oct 2020 17:22:58 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Volker Simonis has refreshed the contents of this pull request, and previous commits have been removed. The incremental
>> views will show differences compared to the previous content of the PR.
>
> src/java.base/share/classes/java/util/zip/ZipOutputStream.java line 189:
> 
>> 187:      * {@code ZipEntry.DEFLATED}) entries when {@link ZipEntry#setCompressedSize(long)}
>> 188:      * has not been explicitly called on the {@code ZipEntry}.
>> 189:      *
> 
> Here's an alternative that might be a bit clearer to readers.
> 
> "When writing a compressed (deflated) entry, and the compressed size has not been explicitly set with the
> setCompressedSize method, then the compressed size written to the entry's data descriptor will be its actual compressed
> size."  I think we should put it after the "The default compression method .." sentence and move the sentence on the
> time stamp to the end.

I don't believe we discuss/reference the data descriptor for a Zip entry (outside of the PKWare Zip specification) so I
am not sure we should reference it in the javadoc.

 Placing the sentence after "The default compression method will be used if no compression method was specified for the
 entry" makes sense

-------------

PR: https://git.openjdk.java.net/jdk/pull/520

From tvaleev at openjdk.java.net  Mon Oct 12 02:53:10 2020
From: tvaleev at openjdk.java.net (Tagir F.Valeev)
Date: Mon, 12 Oct 2020 02:53:10 GMT
Subject: RFR: 8251989: Hex formatting and parsing utility
In-Reply-To: <HSEn47GMS1K3g57mrTZeQk-WZHl3pKGHpX_OOf8VnsU=.740863c2-f9e4-43c4-b500-614aab4078b1@github.com>
References: <HSEn47GMS1K3g57mrTZeQk-WZHl3pKGHpX_OOf8VnsU=.740863c2-f9e4-43c4-b500-614aab4078b1@github.com>
Message-ID: <_TB4IMes7EDfLsmfjvEgTLuEglPW7XNWBxtM4qxouFw=.3c4d7a99-4313-4a04-a3ab-8edbae1b107c@github.com>

On Fri, 2 Oct 2020 15:18:04 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> java.util.HexFormat utility:
> 
>  - Format and parse hexadecimal strings, with parameters for delimiter, prefix, suffix and upper/lowercase
>  - Static factories and builder methods to create HexFormat copies with modified parameters.
>  - Consistent naming of methods for conversion of byte arrays to formatted strings and back: formatHex and parseHex
>  - Consistent naming of methods for conversion of primitive types: toHexDigits... and fromHexDigits...
>  - Prefix and suffixes now apply to each formatted value, not the string as a whole
>  - Using java.util.Appendable as a target for buffered conversions so output to Writers and PrintStreams
>    like System.out are supported in addition to StringBuilder. (IOExceptions are converted to unchecked exceptions)
>  - Immutable and thread safe, a "value-based" class
> 
> See the [HexFormat
> javadoc](http://cr.openjdk.java.net/~rriggs/8251989-hex-formatter/java.base/java/util/HexFormat.html) for details.
> Review comments and suggestions welcome.

src/java.base/share/classes/java/util/HexFormat.java line 108:

> 106:  * }</pre>
> 107:  * <p>
> 108:  * For a fingerprint of byte values that uses the delimiter colon ({@code ":""})

The extra quote is here: `{@code ":""}` (should be `{@code ":"}`)

-------------

PR: https://git.openjdk.java.net/jdk/pull/482

From darcy at openjdk.java.net  Mon Oct 12 03:00:14 2020
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 12 Oct 2020 03:00:14 GMT
Subject: RFR: 8223347: Integration of Vector API (Incubator)
In-Reply-To: <-PE4TwXgvq2bemAn_8csjn4_j7zoAolnQz6QQt3z0Wk=.eaa9999f-0713-4349-b31d-934717aa37a1@github.com>
References: <-PE4TwXgvq2bemAn_8csjn4_j7zoAolnQz6QQt3z0Wk=.eaa9999f-0713-4349-b31d-934717aa37a1@github.com>
Message-ID: <utkmWug4WO629_sgaE_narH0FADWXZ5TDsHNp72x0Ec=.8bd58cf1-468f-40dc-abec-3c82965d001e@github.com>

On Fri, 25 Sep 2020 20:14:29 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> This pull request is for integration of the Vector API. It was previously reviewed under conditions when mercurial was
> used for the source code control system. Review threads can be found here (searching for issue number 8223347 in the
> title):  https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-April/thread.html
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-May/thread.html
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-July/thread.html
> 
> If mercurial was still being used the code would be pushed directly, once the CSR is approved. However, in this case a
> pull request is required and needs explicit reviewer approval. Between the final review and this pull request no code
> has changed, except for that related to merging.

Marked as reviewed by darcy (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/367

From fyang at openjdk.java.net  Mon Oct 12 07:05:16 2020
From: fyang at openjdk.java.net (Fei Yang)
Date: Mon, 12 Oct 2020 07:05:16 GMT
Subject: RFR: 8252204: AArch64: Implement SHA3 accelerator/intrinsic [v5]
In-Reply-To: <lcceWzrMnnFAHnmt-QcVqHWkn43cVpDDM0Q-5GuUCKk=.b0b4ea48-bdb1-4e4c-83e0-feaf5176685d@github.com>
References: <PJVtIubjiGKhCK81PIMhWuYxnR84DNieMDUGHdhHYZM=.ad903c93-c5e3-4614-9af1-d36bc33f735d@github.com>
 <nR6wQq3N8OnxHsAdAzQ2mIh6RZQ_b7H_M51Y9Eng3J4=.90d276d3-8b4b-427c-a075-bb7db96e37cb@github.com>
 <A5RkMquxaW1OuuiPTpD1wz7pBMcjxU7roLU5wD3cH8E=.0211f34f-eb8b-4b93-8072-82ac1a894019@github.com>
 <4NM17B6l4GvNgCbmmQTUcnfZTA6G-IEc85O8jH_q-xA=.63b10da7-bab7-44bc-a4c8-0a675aca45c0@github.com>
 <lcceWzrMnnFAHnmt-QcVqHWkn43cVpDDM0Q-5GuUCKk=.b0b4ea48-bdb1-4e4c-83e0-feaf5176685d@github.com>
Message-ID: <xrytoJAOW673RPJmBM3ksB4CUliXJKtlnGKm_RaJ8hw=.ac80c083-a8b6-4f63-aead-503ad616d210@github.com>

On Sat, 10 Oct 2020 13:15:51 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> I see Linux x64 failed. However, I don't seem to be able to withdraw my patch approval.
>> However, please consider it withdrawn.
>
> @theRealAph if you still need to, you can withdraw your approval by reviewing it again and selecting "Request changes".

> I have looked at the java security changes, i.e. src/java.base/share/classes/sun/security/provider/SHA3.java. It looks
> fine.

@valeriepeng : I see you are not listed under "Reviewers" commit message part, could you please press the magic
button(s)(approve?) so you get the credit? Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/207

From tvaleev at openjdk.java.net  Mon Oct 12 09:57:11 2020
From: tvaleev at openjdk.java.net (Tagir F.Valeev)
Date: Mon, 12 Oct 2020 09:57:11 GMT
Subject: RFR: 8251989: Hex formatting and parsing utility
In-Reply-To: <HSEn47GMS1K3g57mrTZeQk-WZHl3pKGHpX_OOf8VnsU=.740863c2-f9e4-43c4-b500-614aab4078b1@github.com>
References: <HSEn47GMS1K3g57mrTZeQk-WZHl3pKGHpX_OOf8VnsU=.740863c2-f9e4-43c4-b500-614aab4078b1@github.com>
Message-ID: <IzdrgYz6XDIwUmzESDCHyF9F-PRS3Vn43Car1cAkH5E=.fcb83a00-17db-49e5-97ab-f742510e7aaa@github.com>

On Fri, 2 Oct 2020 15:18:04 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> java.util.HexFormat utility:
> 
>  - Format and parse hexadecimal strings, with parameters for delimiter, prefix, suffix and upper/lowercase
>  - Static factories and builder methods to create HexFormat copies with modified parameters.
>  - Consistent naming of methods for conversion of byte arrays to formatted strings and back: formatHex and parseHex
>  - Consistent naming of methods for conversion of primitive types: toHexDigits... and fromHexDigits...
>  - Prefix and suffixes now apply to each formatted value, not the string as a whole
>  - Using java.util.Appendable as a target for buffered conversions so output to Writers and PrintStreams
>    like System.out are supported in addition to StringBuilder. (IOExceptions are converted to unchecked exceptions)
>  - Immutable and thread safe, a "value-based" class
> 
> See the [HexFormat
> javadoc](http://cr.openjdk.java.net/~rriggs/8251989-hex-formatter/java.base/java/util/HexFormat.html) for details.
> Review comments and suggestions welcome.

src/java.base/share/classes/java/util/HexFormat.java line 1012:

> 1010:      * {@code delimiter}, {@code prefix}, and {@code suffix}.
> 1011:      *
> 1012:      * @return return a description of this {@code Formatter}

Should be `return a description of this {@code HexFormat}`?

src/java.base/share/classes/java/util/HexFormat.java line 203:

> 201:      *
> 202:      * @param delimiter a {@code delimiter}, non-null, may be empty
> 203:      * @return a {@link Formatter} with the {@code delimiter} and lowercase letters

Should be `@return a {@link HexFormat} with...`? Or `@return a hex formatter with...`?

-------------

PR: https://git.openjdk.java.net/jdk/pull/482

From kravikumar at openjdk.java.net  Mon Oct 12 10:06:17 2020
From: kravikumar at openjdk.java.net (Kiran Sidhartha Ravikumar)
Date: Mon, 12 Oct 2020 10:06:17 GMT
Subject: RFR: 8254177: (tz) Upgrade time-zone data to tzdata2020b
In-Reply-To: <KvYfzEHlUV_cV29YAN2i2uXph2lldf0GGz_9TE5O0Iw=.c2d0262d-50d8-49fc-9815-1482616d1a3c@github.com>
References: <KvYfzEHlUV_cV29YAN2i2uXph2lldf0GGz_9TE5O0Iw=.c2d0262d-50d8-49fc-9815-1482616d1a3c@github.com>
Message-ID: <22YmDaNpCLPodEMwzylAkKsF41pIePBAvkpQcyTH-6g=.12bffcc4-05f9-40e0-b454-75e5bb8713ce@github.com>

On Mon, 12 Oct 2020 09:32:38 GMT, Kiran Sidhartha Ravikumar <kravikumar at openjdk.org> wrote:

> Hi Guys,
> 
> Please review the patch for tzdata2020b integration into JDK.
> 
> Release details can be found here:
> 
> https://mm.icann.org/pipermail/tz-announce/2020-October/000059.html
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8254177
> 
> I had the pacificnew, systemv files removed from JDK repo and so TimeZoneName classes, make file and few test files
> need to be updated to incorporate the change.
> The patch has passed all the related testing including JCK.
> 
> Thanks,
> Kiran

test/jdk/sun/util/calendar/zi/TestZoneInfo310.java line 221:

> 219:         zids_old = ZoneInfoOld.getAvailableIDs(-8 * 60 * 60 * 1000);
> 220: 	Arrays.sort(zids_old);
> 221: 	System.out.println("new and old length = " + zids_new.length + " " + zids_old.length);

Missed to remove the instrumentation.

-------------

PR: https://git.openjdk.java.net/jdk/pull/602

From kravikumar at openjdk.java.net  Mon Oct 12 10:06:16 2020
From: kravikumar at openjdk.java.net (Kiran Sidhartha Ravikumar)
Date: Mon, 12 Oct 2020 10:06:16 GMT
Subject: RFR: 8254177: (tz) Upgrade time-zone data to tzdata2020b
Message-ID: <KvYfzEHlUV_cV29YAN2i2uXph2lldf0GGz_9TE5O0Iw=.c2d0262d-50d8-49fc-9815-1482616d1a3c@github.com>

Hi Guys,

Please review the patch for tzdata2020b integration into JDK.

Release details can be found here:

https://mm.icann.org/pipermail/tz-announce/2020-October/000059.html

Bug: https://bugs.openjdk.java.net/browse/JDK-8254177

I had the pacificnew, systemv files removed from JDK repo and so TimeZoneName classes, make file and few test files
need to be updated to incorporate the change.

The patch has passed all the related testing including JCK.

Thanks,
Kiran

-------------

Commit messages:
 - Merge remote-tracking branch 'origin/master' into JDK-8254177
 - 8254177: Resolving whitespaces in TestZoneInfo310.java
 - 8254177: (tz) Upgrade time-zone data to tzdata2020b

Changes: https://git.openjdk.java.net/jdk/pull/602/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=602&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8254177
  Stats: 480 lines in 27 files changed: 138 ins; 133 del; 209 mod
  Patch: https://git.openjdk.java.net/jdk/pull/602.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/602/head:pull/602

PR: https://git.openjdk.java.net/jdk/pull/602

From mcimadamore at openjdk.java.net  Mon Oct 12 10:50:48 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 12 Oct 2020 10:50:48 GMT
Subject: RFR: 8254162: Implementation of Foreign-Memory Access API (Third
 Incubator) [v6]
In-Reply-To: <IngRk57F78UN3yySfo6IABbdwnMogGNdYrykh_3em-c=.b81f7478-015c-45ed-9788-58d7519a2770@github.com>
References: <IngRk57F78UN3yySfo6IABbdwnMogGNdYrykh_3em-c=.b81f7478-015c-45ed-9788-58d7519a2770@github.com>
Message-ID: <yxFQpOG6cF_COlU-m2KJvS_6BRzRcv1ZiBSGGYNsmbA=.031c9e97-b423-4f8d-b848-b0e03f0866df@github.com>

> This patch contains the changes associated with the third incubation round of the foreign memory access API incubation
> (see JEP 393 [1]). This iteration focus on improving the usability of the API in 3 main ways:
> * first, by providing a way to obtain truly *shared* segments, which can be accessed and closed concurrently from
>   multiple threads
> * second, by providing a way to register a memory segment against a `Cleaner`, so as to have some (optional) guarantee
>   that the memory will be deallocated, eventually
> * third, by not requiring users to dive deep into var handles when they first pick up the API; a new `MemoryAccess` class
>   has been added, which defines several useful dereference routines; these are really just thin wrappers around memory
>   access var handles, but they make the barrier of entry for using this API somewhat lower.
> 
> A big conceptual shift that comes with this API refresh is that the role of `MemorySegment` and `MemoryAddress` is not
> the same as it used to be; it used to be the case that a memory address could (sometimes, not always) have a back link
> to the memory segment which originated it; additionally, memory access var handles used `MemoryAddress` as a basic unit
> of dereference.  This has all changed as per this API refresh;  now a `MemoryAddress` is just a dumb carrier which
> wraps a pair of object/long addressing coordinates; `MemorySegment` has become the star of the show, as far as
> dereferencing memory is concerned. You cannot dereference memory if you don't have a segment. This improves usability
> in a number of ways - first, it is a lot easier to wrap native addresses (`long`, essentially) into a `MemoryAddress`;
> secondly, it is crystal clear what a client has to do in order to dereference memory: if a client has a segment, it can
> use that; otherwise, if the client only has an address, it will have to create a segment *unsafely* (this can be done
> by calling `MemoryAddress::asSegmentRestricted`).  A list of the API, implementation and test changes is provided
> below. If  you have any questions, or need more detailed explanations, I (and the  rest of the Panama team) will be
> happy to point at existing discussions,  and/or to provide the feedback required.   A big thank to Erik Osterlund,
> Vladimir Ivanov and David Holmes, without whom the work on shared memory segment would not have been possible; also I'd
> like to thank Paul Sandoz, whose insights on API design have been very helpful in this journey.  Thanks  Maurizio
> Javadoc:   http://cr.openjdk.java.net/~mcimadamore/8254162_v1/javadoc/jdk/incubator/foreign/package-summary.html
> Specdiff:
> 
> http://cr.openjdk.java.net/~mcimadamore/8254162_v1/specdiff/jdk/incubator/foreign/package-summary.html
> 
> CSR:
> 
> https://bugs.openjdk.java.net/browse/JDK-8254163
> 
> 
> 
> ### API Changes
> 
> * `MemorySegment`
>   * drop factory for restricted segment (this has been moved to `MemoryAddress`, see below)
>   * added a no-arg factory for a native restricted segment representing entire native heap
>   * rename `withOwnerThread` to `handoff`
>   * add new `share` method, to create shared segments
>   * add new `registerCleaner` method, to register a segment against a cleaner
>   * add more helpers to create arrays from a segment e.g. `toIntArray`
>   * add some `asSlice` overloads (to make up for the fact that now segments are more frequently used as cursors)
>   * rename `baseAddress` to `address` (so that `MemorySegment` can implement `Addressable`)
> * `MemoryAddress`
>   * drop `segment` accessor
>   * drop `rebase` method and replace it with `segmentOffset` which returns the offset (a `long`) of this address relative
>     to a given segment
> * `MemoryAccess`
>   * New class supporting several static dereference helpers; the helpers are organized by carrier and access mode, where a
>     carrier is one of the usual suspect (a Java primitive, minus `boolean`); the access mode can be simple (e.g. access
>     base address of given segment), or indexed, in which case the accessor takes a segment and either a low-level byte
>     offset,or a high level logical index. The classification is reflected in the naming scheme (e.g. `getByte` vs.
>     `getByteAtOffset` vs `getByteAtIndex`).
> * `MemoryHandles`
>   * drop `withOffset` combinator
>   * drop `withStride` combinator
>   * the basic memory access handle factory now returns a var handle which takes a `MemorySegment` and a `long` - from which
>     it is easy to derive all the other handles using plain var handle combinators.
> * `Addressable`
>   * This is a new interface which is attached to entities which can be projected to a `MemoryAddress`. For now, both
>     `MemoryAddress` and `MemorySegment` implement it; we have plans, with JEP 389 [2] to add more implementations. Clients
>     can largely ignore this interface, which comes in really handy when defining native bindings with tools like `jextract`.
> * `MemoryLayouts`
>   * A new layout, for machine addresses, has been added to the mix.
> 
> 
> 
> ### Implementation changes
> 
> There are two main things to discuss here: support for shared segments, and the general simplification of the memory
> access var handle support.
> #### Shared segments
> 
> The support for shared segments cuts in pretty deep in the VM. Support for shared segments is notoriously hard to
> achieve, at least in a way that guarantees optimal access performances. This is caused by the fact that, if a segment
> is shared, it would be possible for a thread to close it while another is accessing it.  After considering several
> options (see [3]), we zeroed onto an approach which is inspired by an happy idea that Andrew Haley had (and that he
> reminded me of at this year OpenJDK committer workshop - thanks!). The idea is that if we could *freeze* the world
> (e.g. with a GC pause), while a segment is closed, we could then prevent segments from being accessed concurrently to a
> close operation. For this to work, it  is crucial that no GC safepoints can occur between a segment liveness check and
> the access itself (otherwise it would be possible for the accessing thread to stop just right before an unsafe call).
> It also relies on the fact that hotspot/C2 should not be able to propagate loads across safepoints.  Sadly, none of
> these conditions seems to be valid in the current implementation, so we needed to resort to a bit of creativity. First,
> we noted that, if we could mark so called *scoped* method with an annotation, it would be very simply to check as to
> whether a thread was in the middle of a scoped method when we stopped the world for a close operation (btw, instead of
> stopping the world, we do a much more efficient, thread-local polling, thanks to JEP 312 [4]).  The question is, then,
> once we detect that a thread is accessing the very segment we're about to close, what should happen? We first
> experimented with a solution which would install an *asynchronous* exception on the accessing thread, thus making it
> fail. This solution has some desirable properties, in that a `close` operation always succeeds. Unfortunately the
> machinery for async exceptions is a bit fragile (e.g. not all the code in hotspot checks for async exceptions); to
> minimize risks, we decided to revert to a simpler strategy, where `close` might fail when it finds that another thread
> is accessing the segment being closed.  As written in the javadoc, this doesn't mean that clients should just catch and
> try again; an exception on `close` is a bug in the user code, likely arising from lack of synchronization, and should
> be treated as such.  In terms of gritty implementation, we needed to centralize memory access routines in a single
> place, so that we could have a set of routines closely mimicking the primitives exposed by `Unsafe` but which, in
> addition, also provided a liveness check. This way we could mark all these routines with the special `@Scoped`
> annotation, which tells the VM that something important is going on.  To achieve this, we created a new (autogenerated)
> class, called `ScopedMemoryAccess`. This class contains all the main memory access primitives (including bulk access,
> like `copyMemory`, or `setMemory`), and accepts, in addition to the access coordinates, also a scope object, which is
> tested before access. A reachability fence is also thrown in the mix to make sure that the scope is kept alive during
> access (which is important when registering segments against cleaners).  Of course, to make memory access safe, memory
> access var handles, byte buffer var handles, and byte buffer API should use the new `ScopedMemoryAccess` class instead
> of unsafe, so that a liveness check can be triggered (in case a scope is present).  `ScopedMemoryAccess` has a
> `closeScope` method, which initiates the thread-local handshakes, and returns `true` if the handshake completed
> successfully.  The implementation of `MemoryScope` (now significantly simplified from what we had before), has two
> implementations, one for confined segments and one for shared segments; the main difference between the two is what
> happens when the scope is closed; a confined segment sets a boolean flag to false, and returns, whereas a shared
> segment goes into a `CLOSING` state, then starts the handshake, and then updates the state again, to either `CLOSED` or
> `ALIVE` depending on whether the handshake was successful or not. Note that when a shared segment is in the `CLOSING`
> state, `MemorySegment::isAlive` will still return `true`, while the liveness check upon memory access will fail.  ####
> Memory access var handles overhaul  The key realization here was that if all memory access var handles took a
> coordinate pair of `MemorySegment` and `long`, all other access types could be derived from this basic var handle
> form.  This allowed us to remove the on-the-fly var handle generation, and to simply derive structural access var
> handles (such as those obtained by calling `MemoryLayout::varHandle`) using *plain* var handle combinators, so that
> e.g. additional offset is injected into a base memory access var handle.  This also helped in simplifying the
> implementation by removing the special `withStride` and `withOffset` combinators, which previously needed low-level
> access on the innards of the memory access var handle. All that code is now gone.  #### Test changes  Not much to see
> here - most of the tests needed to be updated because of the API changes. Some were beefed up (like the array test,
> since now segments can be projected into many different kinds of arrays). A test has been added to test the `Cleaner`
> functionality, and another stress test has been added for shared segments (`TestHandshake`). Some of the
> microbenchmarks also needed some tweaks - and some of them were also updated to also test performance in the shared
> segment case.  [1] - https://openjdk.java.net/jeps/393 [2] - https://openjdk.java.net/jeps/389 [3] -
> https://mail.openjdk.java.net/pipermail/panama-dev/2020-May/009004.html [4] - https://openjdk.java.net/jeps/312

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Tweak referenced to MemoryAddressProxy in Utils.java

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/548/files
  - new: https://git.openjdk.java.net/jdk/pull/548/files/9b3fc227..770b1e9c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=548&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=548&range=04-05

  Stats: 6 lines in 1 file changed: 0 ins; 1 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/548.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/548/head:pull/548

PR: https://git.openjdk.java.net/jdk/pull/548

From mdoerr at openjdk.java.net  Mon Oct 12 11:09:15 2020
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Mon, 12 Oct 2020 11:09:15 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v4]
In-Reply-To: <45FtTQB1m6HyZSASY42STMkQffIWlVPibWn9_r00xYs=.daad2653-2571-491f-8dd7-5954fe4ece00@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <45FtTQB1m6HyZSASY42STMkQffIWlVPibWn9_r00xYs=.daad2653-2571-491f-8dd7-5954fe4ece00@github.com>
Message-ID: <u6HLR2PyvWgYbA58W3bCF4n38tpwQu2-ujPMvGpyyuo=.5a80f17c-83d5-4dc9-bad0-00e679fdd4be@github.com>

On Thu, 8 Oct 2020 20:31:47 GMT, CoreyAshford <github.com+51754783+CoreyAshford at openjdk.org> wrote:

>> This patch set encompasses the following commits:
>> 
>> - Adds a new HotSpot intrinsic candidate to the java.lang.Base64 class - decodeBlock(), and provides a flexible API for
>>   the intrinsic.  The API is similar to the existing encodeBlock intrinsic.
>> - Adds the code in HotSpot to check and martial the new intrinsic's arguments to the arch-specific intrinsic
>>   implementation
>> - Adds a Power64LE-specific implementation of the decodeBlock intrinsic.
>> - Adds a JMH microbenchmark for both Base64 encoding and encoding.
>> - Enhances the JTReg hotspot intrinsic "TestBase64.java" regression test to more fully test both decoding and encoding.
>
> CoreyAshford has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - TestBase64.java: fix comment to correctly reflect actual intrinsic names.
>    
>    The intrinsic names that are visible with -XX:+PrintCompilation are encode
>    and decode, rather than encodeBlock and decodeBlock.
>  - stubGenerator_ppc.cpp: fix regression caused by change to using loop counter
>    
>    My original fix didn't account for the case where sl < block_size.  In the
>    event sl < block_size, the shifted sl will become zero, so it should
>    jump to the code that computes how much data was processed - 0 - and return.

Test java/util/Base64/TestBase64.java failed on Power9:
Seed from RandomFactory = -8714459054005749075L

-------------

Changes requested by mdoerr (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/293

From github.com+70893615+jasontatton-aws at openjdk.java.net  Mon Oct 12 11:17:25 2020
From: github.com+70893615+jasontatton-aws at openjdk.java.net (Jason Tatton)
Date: Mon, 12 Oct 2020 11:17:25 GMT
Subject: RFR: 8173585: Intrinsify StringLatin1.indexOf(char) [v6]
In-Reply-To: <_T0873dC5tfUtGn9r1_Y21JkPKRt-za3MM9hPN2GQKQ=.b865fe53-5417-424f-81b6-1566a330640e@github.com>
References: <_T0873dC5tfUtGn9r1_Y21JkPKRt-za3MM9hPN2GQKQ=.b865fe53-5417-424f-81b6-1566a330640e@github.com>
Message-ID: <PuKDnAd5G6rpb3scQynqFMBf8zU37yVP_Qmp3SxmfyU=.06c27943-ea4d-4e3d-a4aa-a12a8033c35a@github.com>

> This is an implementation of the indexOf(char) intrinsic for StringLatin1 (1 byte encoded Strings). It is provided for
> x86 and ARM64. The implementation is greatly inspired by the indexOf(char) intrinsic for StringUTF16. To incorporate it
> I had to make a small change to StringLatin1.java (refactor of functionality to intrisified private method) as well as
> code for C2.  Submitted to: hotspot-compiler-dev and core-libs-dev as this patch contains a change to hotspot and
> java/lang/StringLatin1.java  https://bugs.openjdk.java.net/browse/JDK-8173585
> 
> Details of testing:
> ============
> I have created a jtreg test ?compiler/intrinsics/string/TestStringLatin1IndexOfChar? to cover this new intrinsic. Note
> that, particularly for the x86 implementation of the intrinsic, the code path taken is dependent upon the length of the
> input String. Hence the test has been designed to cover all these cases. In summary they are:
> - A ?short? string of < 16 characters.
> - A SIMD String of 16 ? 31 characters.
> - A AVX2 SIMD String of 32 characters+.
> 
> Hardware used for testing:
> -----------------------------
> 
> - Intel Xeon CPU E5-2680 (JVM did not recognize this as having AVX2 support) ? Intel i7 processor (with AVX2 support).
> - AWS Graviton 2 (ARM 64 processor).
> 
> I also ran; ?run-test-tier1? and ?run-test-tier2? for: x86_64 and aarch64.
> 
> Possible future enhancements:
> ====================
> For the x86 implementation there may be two further improvements we can make in order to improve performance of both
> the StringUTF16 and StringLatin1 indexOf(char) intrinsics:
> 1. Make use of AVX-512 instructions.
> 2. For ?short? Strings (see below), I think it may be possible to modify the existing algorithm to still use SSE SIMD
> instructions instead of a loop.
> Benchmark results:
> ============
> **Without** the new StringLatin1 indexOf(char) intrinsic:
> 
> | Benchmark  | Mode | Cnt | Score | Error | Units |
> | ------------- | ------------- |------------- |------------- |------------- |------------- |
> | IndexOfBenchmark.latin1_mixed_char | avgt | 5 | **26,389.129** | ? 182.581 | ns/op |
> | IndexOfBenchmark.utf16_mixed_char | avgt | 5 | 17,885.383 | ? 435.933  | ns/op |
> 
> 
> **With** the new StringLatin1 indexOf(char) intrinsic:
> 
> | Benchmark  | Mode | Cnt | Score | Error | Units |
> | ------------- | ------------- |------------- |------------- |------------- |------------- |
> | IndexOfBenchmark.latin1_mixed_char | avgt | 5 | **17,875.185** | ? 407.716  | ns/op |
> | IndexOfBenchmark.utf16_mixed_char | avgt | 5 | 18,292.802 | ? 167.306  | ns/op |
> 
> 
> The objective of the patch is to bring the performance of StringLatin1 indexOf(char) in line with StringUTF16
> indexOf(char) for x86 and ARM64. We can see above that this has been achieved. Similar results were obtained when
> running on ARM.

Jason Tatton has updated the pull request incrementally with one additional commit since the last revision:

  Added missing copyright notices

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/71/files
  - new: https://git.openjdk.java.net/jdk/pull/71/files/8ead02ab..3ae1d92d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=71&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=71&range=04-05

  Stats: 45 lines in 2 files changed: 45 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/71.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/71/head:pull/71

PR: https://git.openjdk.java.net/jdk/pull/71

From github.com+70893615+jasontatton-aws at openjdk.java.net  Mon Oct 12 11:17:27 2020
From: github.com+70893615+jasontatton-aws at openjdk.java.net (Jason Tatton)
Date: Mon, 12 Oct 2020 11:17:27 GMT
Subject: RFR: 8173585: Intrinsify StringLatin1.indexOf(char) [v3]
In-Reply-To: <0_4KDtvn6WhHRCxqupbUQjLauR5DMQWJluogsJ7m_KA=.697e6e15-5c91-4339-abab-1dff51871e8d@github.com>
References: <_T0873dC5tfUtGn9r1_Y21JkPKRt-za3MM9hPN2GQKQ=.b865fe53-5417-424f-81b6-1566a330640e@github.com>
 <obcOrTC_yxKUUCjcq9pXNhowYF8mrOvCUhU6cn8J-8c=.c6f3b65e-5505-4f3c-8890-81f1655b8a38@github.com>
 <0_4KDtvn6WhHRCxqupbUQjLauR5DMQWJluogsJ7m_KA=.697e6e15-5c91-4339-abab-1dff51871e8d@github.com>
Message-ID: <5sQCV-tDrsi1Ivud3DaxJq5vfJMQDJoZ4tPfKj_JI60=.82ae2d6d-c9b1-46e3-ac2b-284d6ea8878e@github.com>

On Sat, 10 Oct 2020 00:10:54 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Jason Tatton has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add missing newline to end of vmSymbols.cpp
>
> test/hotspot/jtreg/compiler/intrinsics/string/TestStringLatin1IndexOfChar.java line 1:
> 
>> 1: /*
> 
> Missing copyright+GPL header in new test. See other tests fro example.

Thanks I have added this now

> test/micro/org/openjdk/bench/java/lang/StringIndexOfChar.java line 1:
> 
>> 1: package org.openjdk.bench.java.lang;
> 
> Again missing Copyright.

Thanks I have added this now

-------------

PR: https://git.openjdk.java.net/jdk/pull/71

From pliden at openjdk.java.net  Mon Oct 12 11:20:16 2020
From: pliden at openjdk.java.net (Per Liden)
Date: Mon, 12 Oct 2020 11:20:16 GMT
Subject: RFR: 8188055: (ref) Add Reference::refersTo predicate [v2]
In-Reply-To: <QpVGNFn7FwJVVijkSVKgUxWDLw3Y7im-mlA3yw7_crU=.1e8d22b9-29e8-4347-8790-2fe213435219@github.com>
References: <D4HSg8FT20Eaxk5KJkkw0GgETSxRkBn1ipS3Dt0kPto=.e4bab078-2e04-4413-90cb-9bfafb2a6831@github.com>
 <QpVGNFn7FwJVVijkSVKgUxWDLw3Y7im-mlA3yw7_crU=.1e8d22b9-29e8-4347-8790-2fe213435219@github.com>
Message-ID: <fdRw8XxvrIGJI35awI_IOOg2tucC2JpjupFaVJ1lMvI=.b0b42966-48b0-4915-a9c0-b61866cb9276@github.com>

On Thu, 8 Oct 2020 08:15:07 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Finally returning to this review that was started in April 2020.  I've
>> recast it as a github PR.  I think the security concern raised by Gil
>> has been adequately answered.
>> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-April/029203.html
>> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-July/030401.html
>> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-August/030677.html
>> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-September/030793.html
>> 
>> Please review a new function: java.lang.ref.Reference.refersTo.
>> 
>> This function is needed to test the referent of a Reference object without
>> artificially extending the lifetime of the referent object, as may happen
>> when calling Reference.get.  Some garbage collectors require extending the
>> lifetime of a weak referent when accessed, in order to maintain collector
>> invariants.  Lifetime extension may occur with any collector when the
>> Reference is a SoftReference, as calling get indicates recent access.  This
>> new function also allows testing the referent of a PhantomReference, which
>> can't be accessed by calling get.
>> 
>> The new function uses native methods whose implementations are in the VM so
>> they can use the Access API.  It is the intent that these methods will be
>> intrinsified by optimizing compilers like C2 or graal, but that hasn't been
>> implemented yet.  Bear that in mind before rushing off to change existing
>> uses of Reference.get.
>> 
>> There are two native methods involved, one in Reference and an override in
>> PhantomReference, both package private in java.lang.ref. The reason for this
>> split is to simplify the intrinsification. This is a change from the version
>> from April 2020; that version had a single native method in Reference,
>> implemented using the ON_UNKNOWN_OOP_REF Access reference strength category.
>> However, adding support for that category in the compilers adds significant
>> implementation effort and complexity. Splitting avoids that complexity.
>> 
>> Testing:
>> mach5 tier1
>> Locally (linux-x64) verified the new test passes with various garbage collectors.
>
> Kim Barrett has updated the pull request incrementally with five additional commits since the last revision:
> 
>  - improve refersTo0 descriptions
>  - basic functional test
>  - change referent access
>  - expand test
>  - remove CMS comment

test/jdk/java/lang/ref/ReferenceRefersTo.java line 58:

> 56:             fail(kind + " doesn't refer to expected value");
> 57:         } else if (ref.refersTo(unexpectedValue)) {
> 58:             fail(kind + " refers to unexpected value");

This part, and the use of obj3, below seems odd and unnecessary. If the Reference doesn't have the expected value
there's no special reason to think it has obj3 as value (as opposed to something else). I don't think this check will
help debugging if this test fails.

test/jdk/java/lang/ref/ReferenceRefersTo.java line 42:

> 40:             this.value = value;
> 41:         }
> 42:     }

Introducing this class seems unnecessary, since its `value` is never used. So all instances of `TestObject` could just
be `Object`.

test/hotspot/jtreg/gc/TestReferenceRefersTo.java line 186:

> 184:
> 185:             expectNotValue(testWeak2, testObject3, "testWeak2");
> 186:             expectValue(testWeak3, testObject3, "testWeak3");

It looks to me like the `expectNotCleared()` and `expectNotValue()` methods can be removed. All expect-tests can be
done with just `expectCleared()` and `expectValue()`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/498

From simonis at openjdk.java.net  Mon Oct 12 11:44:28 2020
From: simonis at openjdk.java.net (Volker Simonis)
Date: Mon, 12 Oct 2020 11:44:28 GMT
Subject: RFR: 8253952: Refine ZipOutputStream.putNextEntry() to
 recalculate ZipEntry's compressed size [v3]
In-Reply-To: <0nq5oFKOj6AZqCW6jF268-6oKRI6UkS6TRIHo-_5vKw=.d13c7016-4473-4b20-9117-100b368d3716@github.com>
References: <0nq5oFKOj6AZqCW6jF268-6oKRI6UkS6TRIHo-_5vKw=.d13c7016-4473-4b20-9117-100b368d3716@github.com>
Message-ID: <iMuYmEv-fCgpaIueHT5E_f28siuhzUjohwreSCZT8Dc=.d765890e-dea1-4207-83be-18d1726262bc@github.com>

> ### Summary
> 
> Work around wrong usage of `ZipOutputStream.putNextEntry()` in user code which can lead to the `ZipException "invalid
> entry compressed size"`.
> ### Motivation
> 
> In general it is not safe to directly write a ZipEntry obtained from `ZipInputStream.getNextEntry()`,
> `ZipFile.entries()`, `ZipFile.getEntry()` or `ZipFile.stream()` with `ZipOutputStream.putNextEntry()` to a
> `ZipOutputStream` and then read the entries data from the `ZipInputStream` and write it to the `ZipOutputStream` as
> follows:
>  ZipEntry entry;
>  ZipInputStream zis = new ZipInputStream(...);
>  ZipOutputStream zos = new ZipOutputStream(...);
>  while((entry = zis.getNextEntry()) != null) {
>      zos.putNextEntry(entry);
>      zis.transferTo(zos);
>  }
> The problem with this code is that the zip file format does not record the compression level used for deflation in its
> entries. In general, it doesn't even mandate a predefined compression ratio per compression level. Therefore the
> compressed size recorded in a `ZipEntry` read from a zip file might differ from the new compressed size produced by the
> receiving `ZipOutputStream`. Such a difference will result in a `ZipException` with the following message:
>  java.util.zip.ZipException: invalid entry compressed size (expected 12 but got 7 bytes)
>  
> The correct way of copying all entries from one zip file into another requires the creation of a new `ZipEntry` or at
> least resetting of the compressed size field. E.g.:
>  while((entry = zis.getNextEntry()) != null) {
>      ZipEntry newEntry = new ZipEntry(entry.getName());
>      zos.putNextEntry(newEntry);
>      zis.transferTo(zos);
>  }
> or:
>  while((entry = zis.getNextEntry()) != null) {
>      entry.setCompressedSize(-1);
>      zos.putNextEntry(entry);
>      zis.transferTo(zos);
>  }
> Unfortunately, there's a lot of user code out there which gets this wrong and uses the bad coding pattern described
> before. Searching for `"java.util.zip.ZipException: invalid entry compressed size (expected 12 but got 7 bytes)"` gives
> ~2500 hits (~100 on StackOverflow). It's also no hard to find plenty of instances of this anti-pattern on GitHub when
> doing a code search for `ZipEntry` and `putNextEntry()`. E.g. [Gradle 4.x wrapper task][1] is affected as well as the
> latest version of the [mockableAndroidJar task][2]. I've recently fixed two occurrences of this pattern in OpenJDK (see
> [JDK-8240333][3] and [JDK-8240235][4]) but there still exist more of them (e.g.
> [`test/jdk/java/util/zip/ZipFile/CopyJar.java`][5] which is there since 1999 :).  ### Description  So while this has
> clearly been a problem before, it apparently wasn't painful enough to trigger any action from the side of the JDK.
> However, recently quite some zlib forks with [superior deflate/inflate performance have evolved][6]. Using them with
> OpenJDK is quite straight-forward: one just has to configure the alternative implementations by setting
> `LD_LIBRARY_PATH` or `LD_PRELOAD` correspondingly. We've seen big saving by using these new zlib implementations for
> selected services in production and the only reason why we haven't enabled them by default until now is the problem
> I've just described. The reason why these new libraries uncover the described anti-pattern much more often is because
> their compression ratio is slightly different from that of the default zlib library. This can easily trigger a
> `ZipException` even if an application is not using a different compression levels but just a zip file created with
> another zlib version.  I'd therefore like to propose the following workaround for the wrong
> `ZipOutputStream.putNextEntry()` usage in user code:
> -  ignore the compressed size if it was implicitly determined from the zip file and not explicitly set by calling
>    `ZipEntry.setCompressedSize()`.
> 
> - Change the API-documentation of `ZipOutputStream.putNextEntry()` and `JarOutputStream.putNextEntry()` to explain the
>   problem and why `putNextEntry()` will ignore the compressed size of a `ZipEntry` if that was set implicitely when
>   reading that entry from a `ZipFile` or `ZipInputStream`.
> 
> 
> ### Technical Details
> 
> A zip file consists of a stream of File Entries followed by a Central Directory (see [here for a more detailed
> specification][7]). Each File Entry is composed of a Local File Header (LFH) followed by the compressed Data and an
> optional Data Descriptor. The LFH contains the File Name and among other attributes the Compressed and Uncompressed
> size and CRC of the Data. In the case where the latter three attributes are not available at the time when the LFH is
> created, this fact will be recorded in a flag of the LFH and will trigger the creation of a Data Descriptor with the
> corresponding information right after the Data section. Finally, the Central Directory contains one Central Directory
> File Header (CDFH) for each entry of the  zip archive. The CDFH is an extended version of the LFH and the ultimate
> reference for the contents of the zip archive. The redundancy between LFH and CDFH is a tribute to zip's long history
> when it was used to store archives on multiple floppy discs and the CDFH allowed to update the archive by only writing
> to the last disc which contained the Central Directory.  `ZipEntries` read with `ZipInputStream.getNextEntry()` will
> initially only contain the information from the LFH. Only after the next entry was read (or after
> `ZipInputStream.closeEntry()` was called explicitly), will the previously read entry be updated with the data from the
> Data Descriptor. `ZipInputStream` doesn't inspect the Central Directory at all.  On the other hand, `ZipFile` only
> queries the Central Directory for `ZipEntry` information so all `ZipEntries` returned by `ZipFile.entries()`,
> `ZipFile.getEntry()` and `ZipFile.stream()` will always instantly contain the full Compressed and Uncompressed Size and
> CRC information for each entry independently of the LFH contents.  ### Risks and Assumptions  If we choose to ignore
> the implicitly recorded compressed size in a `ZipEntry` read from a zip file when writing it to a `ZipOutputStream`,
> this will lead to zip files with incomplete information in the LFH and an additional Data Descriptor as described
> before. However, the result is still fully compatible to the zip file specification. It's also not unusual, because by
> default all new zip files created with `ZipOutputStream` will contain LFHs without Compressed and Uncompressed Size and
> CRC information and an additional Data Descriptor. Theoretically it is possible to create new zip files with
> `ZipOutputStream` class and Compressed and Uncompressed Size and CRC information in the LFH but that's complex and
> inefficient because it requires two steps. A first step to determine the crc and compressed size of the data and a
> second step to actually write the data to the `ZipOutputStream` (which will compress it a second time). This is because
> the current API offers no possibility to write already compressed data to a `ZipOutputStream`.  Consequently, the only
> straight-forward way of creating zip files from Java which have all the data in the LFH and no Data Descriptor is by
> copying `ZipEntries` from an existing zip file with the buggy method described before. This incidentally worked more or
> less reliable for a long time but breaks miserably when using different zlib implementations. Ignoring the implicitly
> set compressed size of `ZipEntries` can easily fix this problem.  I'm not aware of any tool which can not handle such
> files and if it exists it would have problems with the majority of Java created zip files anyway (e.g. all jar-files
> created with the jar tool have zip entries with incomplete LFH data and additional Data Descriptor).  Ignoring the
> implicitly set compressed size of `ZipEntries` has no measurable performance impact and will increase the size of zip
> archives which used to have the complete file information in the LFH before by 16 bytes per entry. On the other hand it
> will give us the freedom to use whatever zip implementation we like :)   [1]:
> https://github.com/gradle/gradle/blob/e76905e3a/subprojects/build-init/src/main/java/org/gradle/api/tasks/wrapper/Wrapper.java#L152-L158
> [2]:
> https://android.googlesource.com/platform/tools/base/+/refs/heads/master/build-system/builder/src/main/java/com/android/builder/testing/MockableJarGenerator.java#86
> [3]: https://bugs.openjdk.java.net/browse/JDK-8240333 [4]: https://bugs.openjdk.java.net/browse/JDK-8240235 [5]:
> https://github.com/openjdk/jdk/blob/master/test/jdk/java/util/zip/ZipFile/CopyJar.java [6]:
> https://github.com/simonis/zlib-bench/blob/master/Results.md [7]: https://en.wikipedia.org/wiki/Zip_(file_format)

Volker Simonis 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:

  8253952: Refine ZipOutputStream.putNextEntry() to recalculate ZipEntry's compressed size

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/520/files
  - new: https://git.openjdk.java.net/jdk/pull/520/files/2a9427ef..988f3ef9

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=520&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=520&range=01-02

  Stats: 12 lines in 2 files changed: 0 ins; 0 del; 12 mod
  Patch: https://git.openjdk.java.net/jdk/pull/520.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/520/head:pull/520

PR: https://git.openjdk.java.net/jdk/pull/520

From ihse at openjdk.java.net  Mon Oct 12 11:45:15 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Mon, 12 Oct 2020 11:45:15 GMT
Subject: RFR: 8254162: Implementation of Foreign-Memory Access API (Third
 Incubator) [v6]
In-Reply-To: <yxFQpOG6cF_COlU-m2KJvS_6BRzRcv1ZiBSGGYNsmbA=.031c9e97-b423-4f8d-b848-b0e03f0866df@github.com>
References: <IngRk57F78UN3yySfo6IABbdwnMogGNdYrykh_3em-c=.b81f7478-015c-45ed-9788-58d7519a2770@github.com>
 <yxFQpOG6cF_COlU-m2KJvS_6BRzRcv1ZiBSGGYNsmbA=.031c9e97-b423-4f8d-b848-b0e03f0866df@github.com>
Message-ID: <pqHBaSZ3wkaJWqdEZ_cVc8iWbhRjdb8z2kLHzy9k7Aw=.e4af889e-1c9b-4a68-b11c-faa43d9ecd8d@github.com>

On Mon, 12 Oct 2020 10:50:48 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This patch contains the changes associated with the third incubation round of the foreign memory access API incubation
>> (see JEP 393 [1]). This iteration focus on improving the usability of the API in 3 main ways:
>> * first, by providing a way to obtain truly *shared* segments, which can be accessed and closed concurrently from
>>   multiple threads
>> * second, by providing a way to register a memory segment against a `Cleaner`, so as to have some (optional) guarantee
>>   that the memory will be deallocated, eventually
>> * third, by not requiring users to dive deep into var handles when they first pick up the API; a new `MemoryAccess` class
>>   has been added, which defines several useful dereference routines; these are really just thin wrappers around memory
>>   access var handles, but they make the barrier of entry for using this API somewhat lower.
>> 
>> A big conceptual shift that comes with this API refresh is that the role of `MemorySegment` and `MemoryAddress` is not
>> the same as it used to be; it used to be the case that a memory address could (sometimes, not always) have a back link
>> to the memory segment which originated it; additionally, memory access var handles used `MemoryAddress` as a basic unit
>> of dereference.  This has all changed as per this API refresh;  now a `MemoryAddress` is just a dumb carrier which
>> wraps a pair of object/long addressing coordinates; `MemorySegment` has become the star of the show, as far as
>> dereferencing memory is concerned. You cannot dereference memory if you don't have a segment. This improves usability
>> in a number of ways - first, it is a lot easier to wrap native addresses (`long`, essentially) into a `MemoryAddress`;
>> secondly, it is crystal clear what a client has to do in order to dereference memory: if a client has a segment, it can
>> use that; otherwise, if the client only has an address, it will have to create a segment *unsafely* (this can be done
>> by calling `MemoryAddress::asSegmentRestricted`).  A list of the API, implementation and test changes is provided
>> below. If  you have any questions, or need more detailed explanations, I (and the  rest of the Panama team) will be
>> happy to point at existing discussions,  and/or to provide the feedback required.   A big thank to Erik Osterlund,
>> Vladimir Ivanov and David Holmes, without whom the work on shared memory segment would not have been possible; also I'd
>> like to thank Paul Sandoz, whose insights on API design have been very helpful in this journey.  Thanks  Maurizio
>> Javadoc:   http://cr.openjdk.java.net/~mcimadamore/8254162_v1/javadoc/jdk/incubator/foreign/package-summary.html
>> Specdiff:
>> 
>> http://cr.openjdk.java.net/~mcimadamore/8254162_v1/specdiff/jdk/incubator/foreign/package-summary.html
>> 
>> CSR:
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8254163
>> 
>> 
>> 
>> ### API Changes
>> 
>> * `MemorySegment`
>>   * drop factory for restricted segment (this has been moved to `MemoryAddress`, see below)
>>   * added a no-arg factory for a native restricted segment representing entire native heap
>>   * rename `withOwnerThread` to `handoff`
>>   * add new `share` method, to create shared segments
>>   * add new `registerCleaner` method, to register a segment against a cleaner
>>   * add more helpers to create arrays from a segment e.g. `toIntArray`
>>   * add some `asSlice` overloads (to make up for the fact that now segments are more frequently used as cursors)
>>   * rename `baseAddress` to `address` (so that `MemorySegment` can implement `Addressable`)
>> * `MemoryAddress`
>>   * drop `segment` accessor
>>   * drop `rebase` method and replace it with `segmentOffset` which returns the offset (a `long`) of this address relative
>>     to a given segment
>> * `MemoryAccess`
>>   * New class supporting several static dereference helpers; the helpers are organized by carrier and access mode, where a
>>     carrier is one of the usual suspect (a Java primitive, minus `boolean`); the access mode can be simple (e.g. access
>>     base address of given segment), or indexed, in which case the accessor takes a segment and either a low-level byte
>>     offset,or a high level logical index. The classification is reflected in the naming scheme (e.g. `getByte` vs.
>>     `getByteAtOffset` vs `getByteAtIndex`).
>> * `MemoryHandles`
>>   * drop `withOffset` combinator
>>   * drop `withStride` combinator
>>   * the basic memory access handle factory now returns a var handle which takes a `MemorySegment` and a `long` - from which
>>     it is easy to derive all the other handles using plain var handle combinators.
>> * `Addressable`
>>   * This is a new interface which is attached to entities which can be projected to a `MemoryAddress`. For now, both
>>     `MemoryAddress` and `MemorySegment` implement it; we have plans, with JEP 389 [2] to add more implementations. Clients
>>     can largely ignore this interface, which comes in really handy when defining native bindings with tools like `jextract`.
>> * `MemoryLayouts`
>>   * A new layout, for machine addresses, has been added to the mix.
>> 
>> 
>> 
>> ### Implementation changes
>> 
>> There are two main things to discuss here: support for shared segments, and the general simplification of the memory
>> access var handle support.
>> #### Shared segments
>> 
>> The support for shared segments cuts in pretty deep in the VM. Support for shared segments is notoriously hard to
>> achieve, at least in a way that guarantees optimal access performances. This is caused by the fact that, if a segment
>> is shared, it would be possible for a thread to close it while another is accessing it.  After considering several
>> options (see [3]), we zeroed onto an approach which is inspired by an happy idea that Andrew Haley had (and that he
>> reminded me of at this year OpenJDK committer workshop - thanks!). The idea is that if we could *freeze* the world
>> (e.g. with a GC pause), while a segment is closed, we could then prevent segments from being accessed concurrently to a
>> close operation. For this to work, it  is crucial that no GC safepoints can occur between a segment liveness check and
>> the access itself (otherwise it would be possible for the accessing thread to stop just right before an unsafe call).
>> It also relies on the fact that hotspot/C2 should not be able to propagate loads across safepoints.  Sadly, none of
>> these conditions seems to be valid in the current implementation, so we needed to resort to a bit of creativity. First,
>> we noted that, if we could mark so called *scoped* method with an annotation, it would be very simply to check as to
>> whether a thread was in the middle of a scoped method when we stopped the world for a close operation (btw, instead of
>> stopping the world, we do a much more efficient, thread-local polling, thanks to JEP 312 [4]).  The question is, then,
>> once we detect that a thread is accessing the very segment we're about to close, what should happen? We first
>> experimented with a solution which would install an *asynchronous* exception on the accessing thread, thus making it
>> fail. This solution has some desirable properties, in that a `close` operation always succeeds. Unfortunately the
>> machinery for async exceptions is a bit fragile (e.g. not all the code in hotspot checks for async exceptions); to
>> minimize risks, we decided to revert to a simpler strategy, where `close` might fail when it finds that another thread
>> is accessing the segment being closed.  As written in the javadoc, this doesn't mean that clients should just catch and
>> try again; an exception on `close` is a bug in the user code, likely arising from lack of synchronization, and should
>> be treated as such.  In terms of gritty implementation, we needed to centralize memory access routines in a single
>> place, so that we could have a set of routines closely mimicking the primitives exposed by `Unsafe` but which, in
>> addition, also provided a liveness check. This way we could mark all these routines with the special `@Scoped`
>> annotation, which tells the VM that something important is going on.  To achieve this, we created a new (autogenerated)
>> class, called `ScopedMemoryAccess`. This class contains all the main memory access primitives (including bulk access,
>> like `copyMemory`, or `setMemory`), and accepts, in addition to the access coordinates, also a scope object, which is
>> tested before access. A reachability fence is also thrown in the mix to make sure that the scope is kept alive during
>> access (which is important when registering segments against cleaners).  Of course, to make memory access safe, memory
>> access var handles, byte buffer var handles, and byte buffer API should use the new `ScopedMemoryAccess` class instead
>> of unsafe, so that a liveness check can be triggered (in case a scope is present).  `ScopedMemoryAccess` has a
>> `closeScope` method, which initiates the thread-local handshakes, and returns `true` if the handshake completed
>> successfully.  The implementation of `MemoryScope` (now significantly simplified from what we had before), has two
>> implementations, one for confined segments and one for shared segments; the main difference between the two is what
>> happens when the scope is closed; a confined segment sets a boolean flag to false, and returns, whereas a shared
>> segment goes into a `CLOSING` state, then starts the handshake, and then updates the state again, to either `CLOSED` or
>> `ALIVE` depending on whether the handshake was successful or not. Note that when a shared segment is in the `CLOSING`
>> state, `MemorySegment::isAlive` will still return `true`, while the liveness check upon memory access will fail.  ####
>> Memory access var handles overhaul  The key realization here was that if all memory access var handles took a
>> coordinate pair of `MemorySegment` and `long`, all other access types could be derived from this basic var handle
>> form.  This allowed us to remove the on-the-fly var handle generation, and to simply derive structural access var
>> handles (such as those obtained by calling `MemoryLayout::varHandle`) using *plain* var handle combinators, so that
>> e.g. additional offset is injected into a base memory access var handle.  This also helped in simplifying the
>> implementation by removing the special `withStride` and `withOffset` combinators, which previously needed low-level
>> access on the innards of the memory access var handle. All that code is now gone.  #### Test changes  Not much to see
>> here - most of the tests needed to be updated because of the API changes. Some were beefed up (like the array test,
>> since now segments can be projected into many different kinds of arrays). A test has been added to test the `Cleaner`
>> functionality, and another stress test has been added for shared segments (`TestHandshake`). Some of the
>> microbenchmarks also needed some tweaks - and some of them were also updated to also test performance in the shared
>> segment case.  [1] - https://openjdk.java.net/jeps/393 [2] - https://openjdk.java.net/jeps/389 [3] -
>> https://mail.openjdk.java.net/pipermail/panama-dev/2020-May/009004.html [4] - https://openjdk.java.net/jeps/312
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Tweak referenced to MemoryAddressProxy in Utils.java

Build changes look good.

-------------

Marked as reviewed by ihse (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/548

From simonis at openjdk.java.net  Mon Oct 12 11:49:12 2020
From: simonis at openjdk.java.net (Volker Simonis)
Date: Mon, 12 Oct 2020 11:49:12 GMT
Subject: RFR: 8253952: Refine ZipOutputStream.putNextEntry() to
 recalculate ZipEntry's compressed size [v2]
In-Reply-To: <6RMxyurj4wb-oTldhToZhDebkRlbFrSTPzAWnhcni0Q=.457787d6-d1fe-455d-9ade-03e01c099db9@github.com>
References: <0nq5oFKOj6AZqCW6jF268-6oKRI6UkS6TRIHo-_5vKw=.d13c7016-4473-4b20-9117-100b368d3716@github.com>
 <hY8lfhGTXizeHqM6iWX3eKDXz5B4-WHAFaZNvHLk6qc=.d9bf046e-f493-4653-94b1-39d154a4175e@github.com>
 <Jd3oV6qV9tPRHCqKNnIjMaJx6kYi--G7oyykOL_w5qU=.8be45e77-2ea4-4e02-9a07-4f9ba53f6e59@github.com>
 <6RMxyurj4wb-oTldhToZhDebkRlbFrSTPzAWnhcni0Q=.457787d6-d1fe-455d-9ade-03e01c099db9@github.com>
Message-ID: <fXfRwQU9AkSALTw37EQ6DNA_CinRUq4qBy3ECh1hhrU=.a9e49e85-b4e1-4cb1-8e19-72a646429334@github.com>

On Sun, 11 Oct 2020 22:14:18 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/zip/ZipOutputStream.java line 189:
>> 
>>> 187:      * {@code ZipEntry.DEFLATED}) entries when {@link ZipEntry#setCompressedSize(long)}
>>> 188:      * has not been explicitly called on the {@code ZipEntry}.
>>> 189:      *
>> 
>> Here's an alternative that might be a bit clearer to readers.
>> 
>> "When writing a compressed (deflated) entry, and the compressed size has not been explicitly set with the
>> setCompressedSize method, then the compressed size written to the entry's data descriptor will be its actual compressed
>> size."  I think we should put it after the "The default compression method .." sentence and move the sentence on the
>> time stamp to the end.
>
> I don't believe we discuss/reference the data descriptor for a Zip entry (outside of the PKWare Zip specification) so I
> am not sure we should reference it in the javadoc.
>  Placing the sentence after "The default compression method will be used if no compression method was specified for the
>  entry" makes sense

Thanks for your input. I've tried to somehow merge both suggestions :)

Did you had a chance to look at the CSR? I think somebody has to review it before I can move it to "Finalized".

Thank you and best regards,
Volker

-------------

PR: https://git.openjdk.java.net/jdk/pull/520

From mdoerr at openjdk.java.net  Mon Oct 12 12:39:19 2020
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Mon, 12 Oct 2020 12:39:19 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v4]
In-Reply-To: <45FtTQB1m6HyZSASY42STMkQffIWlVPibWn9_r00xYs=.daad2653-2571-491f-8dd7-5954fe4ece00@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <45FtTQB1m6HyZSASY42STMkQffIWlVPibWn9_r00xYs=.daad2653-2571-491f-8dd7-5954fe4ece00@github.com>
Message-ID: <HTj0hHy0DzhPqNbzthiCu5OsKGR2lxmwdGd9n63zJO8=.17f53ab3-3f9b-439a-a1a0-eb7c02cbbe99@github.com>

On Thu, 8 Oct 2020 20:31:47 GMT, CoreyAshford <github.com+51754783+CoreyAshford at openjdk.org> wrote:

>> This patch set encompasses the following commits:
>> 
>> - Adds a new HotSpot intrinsic candidate to the java.lang.Base64 class - decodeBlock(), and provides a flexible API for
>>   the intrinsic.  The API is similar to the existing encodeBlock intrinsic.
>> - Adds the code in HotSpot to check and martial the new intrinsic's arguments to the arch-specific intrinsic
>>   implementation
>> - Adds a Power64LE-specific implementation of the decodeBlock intrinsic.
>> - Adds a JMH microbenchmark for both Base64 encoding and encoding.
>> - Enhances the JTReg hotspot intrinsic "TestBase64.java" regression test to more fully test both decoding and encoding.
>
> CoreyAshford has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - TestBase64.java: fix comment to correctly reflect actual intrinsic names.
>    
>    The intrinsic names that are visible with -XX:+PrintCompilation are encode
>    and decode, rather than encodeBlock and decodeBlock.
>  - stubGenerator_ppc.cpp: fix regression caused by change to using loop counter
>    
>    My original fix didn't account for the case where sl < block_size.  In the
>    event sl < block_size, the shifted sl will become zero, so it should
>    jump to the code that computes how much data was processed - 0 - and return.

src/hotspot/cpu/ppc/stubGenerator_ppc.cpp line 3803:

> 3801:     // Base64 class will be used to process the last 12 characters.
> 3802:     __ sub(sl, sl, sp);
> 3803:     __ subi(sl, sl, 12);

I think we should subtract 4, now. srawi will round it down below. We have no guarantee that we can subract more than 4
without getting negative value.

-------------

PR: https://git.openjdk.java.net/jdk/pull/293

From alanb at openjdk.java.net  Mon Oct 12 12:51:14 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 12 Oct 2020 12:51:14 GMT
Subject: RFR: 8253952: Refine ZipOutputStream.putNextEntry() to
 recalculate ZipEntry's compressed size [v3]
In-Reply-To: <iMuYmEv-fCgpaIueHT5E_f28siuhzUjohwreSCZT8Dc=.d765890e-dea1-4207-83be-18d1726262bc@github.com>
References: <0nq5oFKOj6AZqCW6jF268-6oKRI6UkS6TRIHo-_5vKw=.d13c7016-4473-4b20-9117-100b368d3716@github.com>
 <iMuYmEv-fCgpaIueHT5E_f28siuhzUjohwreSCZT8Dc=.d765890e-dea1-4207-83be-18d1726262bc@github.com>
Message-ID: <v6PoI2e4H4_pziBlLxQxagD-FGuDyBcugNZq1KYjRB0=.4a4197c6-f28b-4b84-a792-21f06dd8d992@github.com>

On Mon, 12 Oct 2020 11:44:28 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> ### Summary
>> 
>> Work around wrong usage of `ZipOutputStream.putNextEntry()` in user code which can lead to the `ZipException "invalid
>> entry compressed size"`.
>> ### Motivation
>> 
>> In general it is not safe to directly write a ZipEntry obtained from `ZipInputStream.getNextEntry()`,
>> `ZipFile.entries()`, `ZipFile.getEntry()` or `ZipFile.stream()` with `ZipOutputStream.putNextEntry()` to a
>> `ZipOutputStream` and then read the entries data from the `ZipInputStream` and write it to the `ZipOutputStream` as
>> follows:
>>  ZipEntry entry;
>>  ZipInputStream zis = new ZipInputStream(...);
>>  ZipOutputStream zos = new ZipOutputStream(...);
>>  while((entry = zis.getNextEntry()) != null) {
>>      zos.putNextEntry(entry);
>>      zis.transferTo(zos);
>>  }
>> The problem with this code is that the zip file format does not record the compression level used for deflation in its
>> entries. In general, it doesn't even mandate a predefined compression ratio per compression level. Therefore the
>> compressed size recorded in a `ZipEntry` read from a zip file might differ from the new compressed size produced by the
>> receiving `ZipOutputStream`. Such a difference will result in a `ZipException` with the following message:
>>  java.util.zip.ZipException: invalid entry compressed size (expected 12 but got 7 bytes)
>>  
>> The correct way of copying all entries from one zip file into another requires the creation of a new `ZipEntry` or at
>> least resetting of the compressed size field. E.g.:
>>  while((entry = zis.getNextEntry()) != null) {
>>      ZipEntry newEntry = new ZipEntry(entry.getName());
>>      zos.putNextEntry(newEntry);
>>      zis.transferTo(zos);
>>  }
>> or:
>>  while((entry = zis.getNextEntry()) != null) {
>>      entry.setCompressedSize(-1);
>>      zos.putNextEntry(entry);
>>      zis.transferTo(zos);
>>  }
>> Unfortunately, there's a lot of user code out there which gets this wrong and uses the bad coding pattern described
>> before. Searching for `"java.util.zip.ZipException: invalid entry compressed size (expected 12 but got 7 bytes)"` gives
>> ~2500 hits (~100 on StackOverflow). It's also no hard to find plenty of instances of this anti-pattern on GitHub when
>> doing a code search for `ZipEntry` and `putNextEntry()`. E.g. [Gradle 4.x wrapper task][1] is affected as well as the
>> latest version of the [mockableAndroidJar task][2]. I've recently fixed two occurrences of this pattern in OpenJDK (see
>> [JDK-8240333][3] and [JDK-8240235][4]) but there still exist more of them (e.g.
>> [`test/jdk/java/util/zip/ZipFile/CopyJar.java`][5] which is there since 1999 :).  ### Description  So while this has
>> clearly been a problem before, it apparently wasn't painful enough to trigger any action from the side of the JDK.
>> However, recently quite some zlib forks with [superior deflate/inflate performance have evolved][6]. Using them with
>> OpenJDK is quite straight-forward: one just has to configure the alternative implementations by setting
>> `LD_LIBRARY_PATH` or `LD_PRELOAD` correspondingly. We've seen big saving by using these new zlib implementations for
>> selected services in production and the only reason why we haven't enabled them by default until now is the problem
>> I've just described. The reason why these new libraries uncover the described anti-pattern much more often is because
>> their compression ratio is slightly different from that of the default zlib library. This can easily trigger a
>> `ZipException` even if an application is not using a different compression levels but just a zip file created with
>> another zlib version.  I'd therefore like to propose the following workaround for the wrong
>> `ZipOutputStream.putNextEntry()` usage in user code:
>> -  ignore the compressed size if it was implicitly determined from the zip file and not explicitly set by calling
>>    `ZipEntry.setCompressedSize()`.
>> 
>> - Change the API-documentation of `ZipOutputStream.putNextEntry()` and `JarOutputStream.putNextEntry()` to explain the
>>   problem and why `putNextEntry()` will ignore the compressed size of a `ZipEntry` if that was set implicitely when
>>   reading that entry from a `ZipFile` or `ZipInputStream`.
>> 
>> 
>> ### Technical Details
>> 
>> A zip file consists of a stream of File Entries followed by a Central Directory (see [here for a more detailed
>> specification][7]). Each File Entry is composed of a Local File Header (LFH) followed by the compressed Data and an
>> optional Data Descriptor. The LFH contains the File Name and among other attributes the Compressed and Uncompressed
>> size and CRC of the Data. In the case where the latter three attributes are not available at the time when the LFH is
>> created, this fact will be recorded in a flag of the LFH and will trigger the creation of a Data Descriptor with the
>> corresponding information right after the Data section. Finally, the Central Directory contains one Central Directory
>> File Header (CDFH) for each entry of the  zip archive. The CDFH is an extended version of the LFH and the ultimate
>> reference for the contents of the zip archive. The redundancy between LFH and CDFH is a tribute to zip's long history
>> when it was used to store archives on multiple floppy discs and the CDFH allowed to update the archive by only writing
>> to the last disc which contained the Central Directory.  `ZipEntries` read with `ZipInputStream.getNextEntry()` will
>> initially only contain the information from the LFH. Only after the next entry was read (or after
>> `ZipInputStream.closeEntry()` was called explicitly), will the previously read entry be updated with the data from the
>> Data Descriptor. `ZipInputStream` doesn't inspect the Central Directory at all.  On the other hand, `ZipFile` only
>> queries the Central Directory for `ZipEntry` information so all `ZipEntries` returned by `ZipFile.entries()`,
>> `ZipFile.getEntry()` and `ZipFile.stream()` will always instantly contain the full Compressed and Uncompressed Size and
>> CRC information for each entry independently of the LFH contents.  ### Risks and Assumptions  If we choose to ignore
>> the implicitly recorded compressed size in a `ZipEntry` read from a zip file when writing it to a `ZipOutputStream`,
>> this will lead to zip files with incomplete information in the LFH and an additional Data Descriptor as described
>> before. However, the result is still fully compatible to the zip file specification. It's also not unusual, because by
>> default all new zip files created with `ZipOutputStream` will contain LFHs without Compressed and Uncompressed Size and
>> CRC information and an additional Data Descriptor. Theoretically it is possible to create new zip files with
>> `ZipOutputStream` class and Compressed and Uncompressed Size and CRC information in the LFH but that's complex and
>> inefficient because it requires two steps. A first step to determine the crc and compressed size of the data and a
>> second step to actually write the data to the `ZipOutputStream` (which will compress it a second time). This is because
>> the current API offers no possibility to write already compressed data to a `ZipOutputStream`.  Consequently, the only
>> straight-forward way of creating zip files from Java which have all the data in the LFH and no Data Descriptor is by
>> copying `ZipEntries` from an existing zip file with the buggy method described before. This incidentally worked more or
>> less reliable for a long time but breaks miserably when using different zlib implementations. Ignoring the implicitly
>> set compressed size of `ZipEntries` can easily fix this problem.  I'm not aware of any tool which can not handle such
>> files and if it exists it would have problems with the majority of Java created zip files anyway (e.g. all jar-files
>> created with the jar tool have zip entries with incomplete LFH data and additional Data Descriptor).  Ignoring the
>> implicitly set compressed size of `ZipEntries` has no measurable performance impact and will increase the size of zip
>> archives which used to have the complete file information in the LFH before by 16 bytes per entry. On the other hand it
>> will give us the freedom to use whatever zip implementation we like :)   [1]:
>> https://github.com/gradle/gradle/blob/e76905e3a/subprojects/build-init/src/main/java/org/gradle/api/tasks/wrapper/Wrapper.java#L152-L158
>> [2]:
>> https://android.googlesource.com/platform/tools/base/+/refs/heads/master/build-system/builder/src/main/java/com/android/builder/testing/MockableJarGenerator.java#86
>> [3]: https://bugs.openjdk.java.net/browse/JDK-8240333 [4]: https://bugs.openjdk.java.net/browse/JDK-8240235 [5]:
>> https://github.com/openjdk/jdk/blob/master/test/jdk/java/util/zip/ZipFile/CopyJar.java [6]:
>> https://github.com/simonis/zlib-bench/blob/master/Results.md [7]: https://en.wikipedia.org/wiki/Zip_(file_format)
>
> Volker Simonis 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:
>   8253952: Refine ZipOutputStream.putNextEntry() to recalculate ZipEntry's compressed size

src/java.base/share/classes/java/util/jar/JarOutputStream.java line 86:

> 84:      * compressed size will be set to the actual compressed size after
> 85:      * deflation. The current time will be used if the entry has no set
> 86:      * modification time.

Thanks for combining the wording, I think this looks good. I'd probably drop "i.e." so that it's just "DEFLATED"
parentheses.

-------------

PR: https://git.openjdk.java.net/jdk/pull/520

From alanb at openjdk.java.net  Mon Oct 12 12:57:29 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 12 Oct 2020 12:57:29 GMT
Subject: RFR: 8253952: Refine ZipOutputStream.putNextEntry() to
 recalculate ZipEntry's compressed size [v3]
In-Reply-To: <iMuYmEv-fCgpaIueHT5E_f28siuhzUjohwreSCZT8Dc=.d765890e-dea1-4207-83be-18d1726262bc@github.com>
References: <0nq5oFKOj6AZqCW6jF268-6oKRI6UkS6TRIHo-_5vKw=.d13c7016-4473-4b20-9117-100b368d3716@github.com>
 <iMuYmEv-fCgpaIueHT5E_f28siuhzUjohwreSCZT8Dc=.d765890e-dea1-4207-83be-18d1726262bc@github.com>
Message-ID: <iVdPtq6ltRQMqi6FE_z_KMqTP1M035QPDutEfikUseI=.876c7d62-e338-4675-972b-14a10728a2b7@github.com>

On Mon, 12 Oct 2020 11:44:28 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> ### Summary
>> 
>> Work around wrong usage of `ZipOutputStream.putNextEntry()` in user code which can lead to the `ZipException "invalid
>> entry compressed size"`.
>> ### Motivation
>> 
>> In general it is not safe to directly write a ZipEntry obtained from `ZipInputStream.getNextEntry()`,
>> `ZipFile.entries()`, `ZipFile.getEntry()` or `ZipFile.stream()` with `ZipOutputStream.putNextEntry()` to a
>> `ZipOutputStream` and then read the entries data from the `ZipInputStream` and write it to the `ZipOutputStream` as
>> follows:
>>  ZipEntry entry;
>>  ZipInputStream zis = new ZipInputStream(...);
>>  ZipOutputStream zos = new ZipOutputStream(...);
>>  while((entry = zis.getNextEntry()) != null) {
>>      zos.putNextEntry(entry);
>>      zis.transferTo(zos);
>>  }
>> The problem with this code is that the zip file format does not record the compression level used for deflation in its
>> entries. In general, it doesn't even mandate a predefined compression ratio per compression level. Therefore the
>> compressed size recorded in a `ZipEntry` read from a zip file might differ from the new compressed size produced by the
>> receiving `ZipOutputStream`. Such a difference will result in a `ZipException` with the following message:
>>  java.util.zip.ZipException: invalid entry compressed size (expected 12 but got 7 bytes)
>>  
>> The correct way of copying all entries from one zip file into another requires the creation of a new `ZipEntry` or at
>> least resetting of the compressed size field. E.g.:
>>  while((entry = zis.getNextEntry()) != null) {
>>      ZipEntry newEntry = new ZipEntry(entry.getName());
>>      zos.putNextEntry(newEntry);
>>      zis.transferTo(zos);
>>  }
>> or:
>>  while((entry = zis.getNextEntry()) != null) {
>>      entry.setCompressedSize(-1);
>>      zos.putNextEntry(entry);
>>      zis.transferTo(zos);
>>  }
>> Unfortunately, there's a lot of user code out there which gets this wrong and uses the bad coding pattern described
>> before. Searching for `"java.util.zip.ZipException: invalid entry compressed size (expected 12 but got 7 bytes)"` gives
>> ~2500 hits (~100 on StackOverflow). It's also no hard to find plenty of instances of this anti-pattern on GitHub when
>> doing a code search for `ZipEntry` and `putNextEntry()`. E.g. [Gradle 4.x wrapper task][1] is affected as well as the
>> latest version of the [mockableAndroidJar task][2]. I've recently fixed two occurrences of this pattern in OpenJDK (see
>> [JDK-8240333][3] and [JDK-8240235][4]) but there still exist more of them (e.g.
>> [`test/jdk/java/util/zip/ZipFile/CopyJar.java`][5] which is there since 1999 :).  ### Description  So while this has
>> clearly been a problem before, it apparently wasn't painful enough to trigger any action from the side of the JDK.
>> However, recently quite some zlib forks with [superior deflate/inflate performance have evolved][6]. Using them with
>> OpenJDK is quite straight-forward: one just has to configure the alternative implementations by setting
>> `LD_LIBRARY_PATH` or `LD_PRELOAD` correspondingly. We've seen big saving by using these new zlib implementations for
>> selected services in production and the only reason why we haven't enabled them by default until now is the problem
>> I've just described. The reason why these new libraries uncover the described anti-pattern much more often is because
>> their compression ratio is slightly different from that of the default zlib library. This can easily trigger a
>> `ZipException` even if an application is not using a different compression levels but just a zip file created with
>> another zlib version.  I'd therefore like to propose the following workaround for the wrong
>> `ZipOutputStream.putNextEntry()` usage in user code:
>> -  ignore the compressed size if it was implicitly determined from the zip file and not explicitly set by calling
>>    `ZipEntry.setCompressedSize()`.
>> 
>> - Change the API-documentation of `ZipOutputStream.putNextEntry()` and `JarOutputStream.putNextEntry()` to explain the
>>   problem and why `putNextEntry()` will ignore the compressed size of a `ZipEntry` if that was set implicitely when
>>   reading that entry from a `ZipFile` or `ZipInputStream`.
>> 
>> 
>> ### Technical Details
>> 
>> A zip file consists of a stream of File Entries followed by a Central Directory (see [here for a more detailed
>> specification][7]). Each File Entry is composed of a Local File Header (LFH) followed by the compressed Data and an
>> optional Data Descriptor. The LFH contains the File Name and among other attributes the Compressed and Uncompressed
>> size and CRC of the Data. In the case where the latter three attributes are not available at the time when the LFH is
>> created, this fact will be recorded in a flag of the LFH and will trigger the creation of a Data Descriptor with the
>> corresponding information right after the Data section. Finally, the Central Directory contains one Central Directory
>> File Header (CDFH) for each entry of the  zip archive. The CDFH is an extended version of the LFH and the ultimate
>> reference for the contents of the zip archive. The redundancy between LFH and CDFH is a tribute to zip's long history
>> when it was used to store archives on multiple floppy discs and the CDFH allowed to update the archive by only writing
>> to the last disc which contained the Central Directory.  `ZipEntries` read with `ZipInputStream.getNextEntry()` will
>> initially only contain the information from the LFH. Only after the next entry was read (or after
>> `ZipInputStream.closeEntry()` was called explicitly), will the previously read entry be updated with the data from the
>> Data Descriptor. `ZipInputStream` doesn't inspect the Central Directory at all.  On the other hand, `ZipFile` only
>> queries the Central Directory for `ZipEntry` information so all `ZipEntries` returned by `ZipFile.entries()`,
>> `ZipFile.getEntry()` and `ZipFile.stream()` will always instantly contain the full Compressed and Uncompressed Size and
>> CRC information for each entry independently of the LFH contents.  ### Risks and Assumptions  If we choose to ignore
>> the implicitly recorded compressed size in a `ZipEntry` read from a zip file when writing it to a `ZipOutputStream`,
>> this will lead to zip files with incomplete information in the LFH and an additional Data Descriptor as described
>> before. However, the result is still fully compatible to the zip file specification. It's also not unusual, because by
>> default all new zip files created with `ZipOutputStream` will contain LFHs without Compressed and Uncompressed Size and
>> CRC information and an additional Data Descriptor. Theoretically it is possible to create new zip files with
>> `ZipOutputStream` class and Compressed and Uncompressed Size and CRC information in the LFH but that's complex and
>> inefficient because it requires two steps. A first step to determine the crc and compressed size of the data and a
>> second step to actually write the data to the `ZipOutputStream` (which will compress it a second time). This is because
>> the current API offers no possibility to write already compressed data to a `ZipOutputStream`.  Consequently, the only
>> straight-forward way of creating zip files from Java which have all the data in the LFH and no Data Descriptor is by
>> copying `ZipEntries` from an existing zip file with the buggy method described before. This incidentally worked more or
>> less reliable for a long time but breaks miserably when using different zlib implementations. Ignoring the implicitly
>> set compressed size of `ZipEntries` can easily fix this problem.  I'm not aware of any tool which can not handle such
>> files and if it exists it would have problems with the majority of Java created zip files anyway (e.g. all jar-files
>> created with the jar tool have zip entries with incomplete LFH data and additional Data Descriptor).  Ignoring the
>> implicitly set compressed size of `ZipEntries` has no measurable performance impact and will increase the size of zip
>> archives which used to have the complete file information in the LFH before by 16 bytes per entry. On the other hand it
>> will give us the freedom to use whatever zip implementation we like :)   [1]:
>> https://github.com/gradle/gradle/blob/e76905e3a/subprojects/build-init/src/main/java/org/gradle/api/tasks/wrapper/Wrapper.java#L152-L158
>> [2]:
>> https://android.googlesource.com/platform/tools/base/+/refs/heads/master/build-system/builder/src/main/java/com/android/builder/testing/MockableJarGenerator.java#86
>> [3]: https://bugs.openjdk.java.net/browse/JDK-8240333 [4]: https://bugs.openjdk.java.net/browse/JDK-8240235 [5]:
>> https://github.com/openjdk/jdk/blob/master/test/jdk/java/util/zip/ZipFile/CopyJar.java [6]:
>> https://github.com/simonis/zlib-bench/blob/master/Results.md [7]: https://en.wikipedia.org/wiki/Zip_(file_format)
>
> Volker Simonis 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:
>   8253952: Refine ZipOutputStream.putNextEntry() to recalculate ZipEntry's compressed size

src/java.base/share/classes/java/util/zip/ZipEntry.java line 56:

> 54:     long size = -1;     // uncompressed size of entry data
> 55:     long csize = -1;    // compressed size of entry data
> 56:     boolean manual_csize = false; // Only true if csize was explicitely set by a call to setCompressedSize()

Minor nit but this should probably be "csizeSet" as it's not too common to have underscore in field names.

src/java.base/share/classes/java/util/zip/ZipOutputStream.java line 216:

> 214:                 e.flag = 8;
> 215:             }
> 216:             else if (!e.manual_csize) {

I assume the existing expression that set if csize has been set so that we don't set the flag to 8 in two branches.

test/jdk/java/util/zip/CopyZipFile.java line 55:

> 53:         File f = new File(zipFile);
> 54:         f.deleteOnExit();
> 55:         OutputStream os = new FileOutputStream(f);

Can you use try-with-resources here so that a test failure will close the file.

-------------

PR: https://git.openjdk.java.net/jdk/pull/520

From erikj at openjdk.java.net  Mon Oct 12 12:59:23 2020
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Mon, 12 Oct 2020 12:59:23 GMT
Subject: RFR: 8223347: Integration of Vector API (Incubator)
In-Reply-To: <-PE4TwXgvq2bemAn_8csjn4_j7zoAolnQz6QQt3z0Wk=.eaa9999f-0713-4349-b31d-934717aa37a1@github.com>
References: <-PE4TwXgvq2bemAn_8csjn4_j7zoAolnQz6QQt3z0Wk=.eaa9999f-0713-4349-b31d-934717aa37a1@github.com>
Message-ID: <QnkhIpPfeKo5Deg7nEaCsA6r7zhyO_SGRueXfq9naQU=.191a4912-1895-4dae-927d-2550181c06da@github.com>

On Fri, 25 Sep 2020 20:14:29 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> This pull request is for integration of the Vector API. It was previously reviewed under conditions when mercurial was
> used for the source code control system. Review threads can be found here (searching for issue number 8223347 in the
> title):  https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-April/thread.html
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-May/thread.html
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-July/thread.html
> 
> If mercurial was still being used the code would be pushed directly, once the CSR is approved. However, in this case a
> pull request is required and needs explicit reviewer approval. Between the final review and this pull request no code
> has changed, except for that related to merging.

Build changes look good.

-------------

Marked as reviewed by erikj (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/367

From erikj at openjdk.java.net  Mon Oct 12 13:00:18 2020
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Mon, 12 Oct 2020 13:00:18 GMT
Subject: RFR: 8254177: (tz) Upgrade time-zone data to tzdata2020b
In-Reply-To: <KvYfzEHlUV_cV29YAN2i2uXph2lldf0GGz_9TE5O0Iw=.c2d0262d-50d8-49fc-9815-1482616d1a3c@github.com>
References: <KvYfzEHlUV_cV29YAN2i2uXph2lldf0GGz_9TE5O0Iw=.c2d0262d-50d8-49fc-9815-1482616d1a3c@github.com>
Message-ID: <cYLhMc2BMeJ4FiHxtK8uQcsPf5cFJ1aPNmy3JjkBpok=.84957f0b-7483-4d03-bbcc-9cb6337c2169@github.com>

On Mon, 12 Oct 2020 09:32:38 GMT, Kiran Sidhartha Ravikumar <kravikumar at openjdk.org> wrote:

> Hi Guys,
> 
> Please review the patch for tzdata2020b integration into JDK.
> 
> Release details can be found here:
> 
> https://mm.icann.org/pipermail/tz-announce/2020-October/000059.html
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8254177
> 
> I had the pacificnew, systemv files removed from JDK repo and so TimeZoneName classes, make file and few test files
> need to be updated to incorporate the change.
> The patch has passed all the related testing including JCK.
> 
> Thanks,
> Kiran

Build changes look good.

-------------

Marked as reviewed by erikj (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/602

From mdoerr at openjdk.java.net  Mon Oct 12 13:00:25 2020
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Mon, 12 Oct 2020 13:00:25 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v4]
In-Reply-To: <45FtTQB1m6HyZSASY42STMkQffIWlVPibWn9_r00xYs=.daad2653-2571-491f-8dd7-5954fe4ece00@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <45FtTQB1m6HyZSASY42STMkQffIWlVPibWn9_r00xYs=.daad2653-2571-491f-8dd7-5954fe4ece00@github.com>
Message-ID: <2zhMnWcr1cuE5sxUyCvU9bN5HP_ph_1xQEV3wdx_7dg=.3d509c17-db83-432c-a983-79137d12a827@github.com>

On Thu, 8 Oct 2020 20:31:47 GMT, CoreyAshford <github.com+51754783+CoreyAshford at openjdk.org> wrote:

>> This patch set encompasses the following commits:
>> 
>> - Adds a new HotSpot intrinsic candidate to the java.lang.Base64 class - decodeBlock(), and provides a flexible API for
>>   the intrinsic.  The API is similar to the existing encodeBlock intrinsic.
>> - Adds the code in HotSpot to check and martial the new intrinsic's arguments to the arch-specific intrinsic
>>   implementation
>> - Adds a Power64LE-specific implementation of the decodeBlock intrinsic.
>> - Adds a JMH microbenchmark for both Base64 encoding and encoding.
>> - Enhances the JTReg hotspot intrinsic "TestBase64.java" regression test to more fully test both decoding and encoding.
>
> CoreyAshford has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - TestBase64.java: fix comment to correctly reflect actual intrinsic names.
>    
>    The intrinsic names that are visible with -XX:+PrintCompilation are encode
>    and decode, rather than encodeBlock and decodeBlock.
>  - stubGenerator_ppc.cpp: fix regression caused by change to using loop counter
>    
>    My original fix didn't account for the case where sl < block_size.  In the
>    event sl < block_size, the shifted sl will become zero, so it should
>    jump to the code that computes how much data was processed - 0 - and return.

src/hotspot/cpu/ppc/stubGenerator_ppc.cpp line 3745:

> 3743:     __ clrldi(isURL, isURL, 32);
> 3744:
> 3745:     // Load constant vec registers that need to be loaded from memory

With larger unroll factor we run through this code more often without making any progress, because only the Java part
does all the work for the remaining bytes. Would be nice to move unnecessary parts for that between mtctr and align.

-------------

PR: https://git.openjdk.java.net/jdk/pull/293

From chegar at openjdk.java.net  Mon Oct 12 13:09:17 2020
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Mon, 12 Oct 2020 13:09:17 GMT
Subject: Integrated: 8254234 - Add test library stream object builder
In-Reply-To: <YG2nA5Bzj8YkrGnsdqFnHKGl_XugrwvFX3hoGjdgo_s=.3f19ec15-fa71-4f89-bf86-59287671ffca@github.com>
References: <YG2nA5Bzj8YkrGnsdqFnHKGl_XugrwvFX3hoGjdgo_s=.3f19ec15-fa71-4f89-bf86-59287671ffca@github.com>
Message-ID: <3bJ7vW1z8OUk5lqhOBRDQvFfCKZAFoHdMs1Xa5tlE5Y=.002281f6-ca64-42e5-b870-edd344f05ae5@github.com>

On Thu, 8 Oct 2020 12:38:42 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

> It is useful to have a test library facility for building stream objects, suitable for deserialization testing. We
> already have a partial implementation in one of the record serialization tests, move it to the test library for more
> general use. The implementation remains partial, but can be expanded as and when needed.

This pull request has now been integrated.

Changeset: aad3cf4d
Author:    Chris Hegarty <chegar at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/aad3cf4d
Stats:     398 lines in 2 files changed: 209 ins; 169 del; 20 mod

8254234: Add test library stream object builder

Reviewed-by: rriggs

-------------

PR: https://git.openjdk.java.net/jdk/pull/561

From sgehwolf at openjdk.java.net  Mon Oct 12 13:29:20 2020
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Mon, 12 Oct 2020 13:29:20 GMT
Subject: RFR: 8253939: [TESTBUG] Increase coverage of the cgroups detection
 code for Java
Message-ID: <4G2YAmtWb3u1gyPsKK9lK5X06dKN93_zCqJvsZmjzxE=.1e754307-4dfa-417b-98e5-3af55a441145@github.com>

Test only change. With [JDK-8253435](https://bugs.openjdk.java.net/browse/JDK-8253435) a test has been added on the
hotspot side, but nothing for the Java Metrics code. Same for
[JDK-8252359](https://bugs.openjdk.java.net/browse/JDK-8252359). This patch alleviates that.

Thoughts?

-------------

Commit messages:
 - 8253939: [TESTBUG] Increase coverage of the cgroups detection code for Java

Changes: https://git.openjdk.java.net/jdk/pull/609/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=609&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8253939
  Stats: 40 lines in 1 file changed: 27 ins; 0 del; 13 mod
  Patch: https://git.openjdk.java.net/jdk/pull/609.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/609/head:pull/609

PR: https://git.openjdk.java.net/jdk/pull/609

From Alan.Bateman at oracle.com  Mon Oct 12 13:41:13 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 12 Oct 2020 14:41:13 +0100
Subject: RFR: 8253952: Refine ZipOutputStream.putNextEntry() to
 recalculate ZipEntry's compressed size [v2]
In-Reply-To: <fXfRwQU9AkSALTw37EQ6DNA_CinRUq4qBy3ECh1hhrU=.a9e49e85-b4e1-4cb1-8e19-72a646429334@github.com>
References: <0nq5oFKOj6AZqCW6jF268-6oKRI6UkS6TRIHo-_5vKw=.d13c7016-4473-4b20-9117-100b368d3716@github.com>
 <hY8lfhGTXizeHqM6iWX3eKDXz5B4-WHAFaZNvHLk6qc=.d9bf046e-f493-4653-94b1-39d154a4175e@github.com>
 <Jd3oV6qV9tPRHCqKNnIjMaJx6kYi--G7oyykOL_w5qU=.8be45e77-2ea4-4e02-9a07-4f9ba53f6e59@github.com>
 <6RMxyurj4wb-oTldhToZhDebkRlbFrSTPzAWnhcni0Q=.457787d6-d1fe-455d-9ade-03e01c099db9@github.com>
 <fXfRwQU9AkSALTw37EQ6DNA_CinRUq4qBy3ECh1hhrU=.a9e49e85-b4e1-4cb1-8e19-72a646429334@github.com>
Message-ID: <73ae6ebc-a9fd-16d3-32a8-88877b096bd2@oracle.com>

On 12/10/2020 12:49, Volker Simonis wrote:
> :
> Did you had a chance to look at the CSR? I think somebody has to review it before I can move it to "Finalized".
>
The updated javadoc looks good. Once Lance has seen it then I think the 
CSR would be updated so that it's in sync with the proposal and then we 
add ourselves as Reviewer and finalize.

-Alan

From fyang at openjdk.java.net  Mon Oct 12 14:47:32 2020
From: fyang at openjdk.java.net (Fei Yang)
Date: Mon, 12 Oct 2020 14:47:32 GMT
Subject: RFR: 8252204: AArch64: Implement SHA3 accelerator/intrinsic [v8]
In-Reply-To: <PJVtIubjiGKhCK81PIMhWuYxnR84DNieMDUGHdhHYZM=.ad903c93-c5e3-4614-9af1-d36bc33f735d@github.com>
References: <PJVtIubjiGKhCK81PIMhWuYxnR84DNieMDUGHdhHYZM=.ad903c93-c5e3-4614-9af1-d36bc33f735d@github.com>
Message-ID: <76qazRT5aX06rurPVGQmtfH2af9_l7DEdy_mGyF7BQQ=.4dd45e3f-b7a4-44c9-9824-4daab9b7dc3b@github.com>

> Contributed-by: ard.biesheuvel at linaro.org, dongbo4 at huawei.com
> 
> This added an intrinsic for SHA3 using aarch64 v8.2 SHA3 Crypto Extensions.
> Reference implementation for core SHA-3 transform using ARMv8.2 Crypto Extensions:
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm64/crypto/sha3-ce-core.S?h=v5.4.52
> 
> Trivial adaptation in SHA3. implCompress is needed for the purpose of adding the intrinsic.
> For SHA3, we need to pass one extra parameter "digestLength" to the stub for the calculation of block size.
> "digestLength" is also used in for the EOR loop before keccak to differentiate different SHA3 variants.
> 
> We added jtreg tests for SHA3 and used QEMU system emulator which supports SHA3 instructions to test the functionality.
> Patch passed jtreg tier1-3 tests with QEMU system emulator.
> Also verified with jtreg tier1-3 tests without SHA3 instructions on aarch64-linux-gnu and x86_64-linux-gnu, to make
> sure that there's no regression.
> We used one existing JMH test for performance test: test/micro/org/openjdk/bench/java/security/MessageDigests.java
> We measured the performance benefit with an aarch64 cycle-accurate simulator.
> Patch delivers 20% - 40% performance improvement depending on specific SHA3 digest length and size of the message.
> 
> For now, this feature will not be enabled automatically for aarch64. We can auto-enable this when it is fully tested on
> real hardware.  But for the above testing purposes, this is auto-enabled when the corresponding hardware feature is
> detected.

Fei Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains
10 commits:

 - Remove unnecessary code changes in vm_version_aarch64.cpp
 - Merge master
 - Merge master
 - Merge master
 - Merge master
 - Add sha3 instructions to cpu/aarch64/aarch64-asmtest.py and regenerate the test in assembler_aarch64.cpp:asm_check
 - Rebase
 - Merge master
 - Fix trailing whitespace issue
 - 8252204: AArch64: Implement SHA3 accelerator/intrinsic
   Contributed-by: ard.biesheuvel at linaro.org, dongbo4 at huawei.com

-------------

Changes: https://git.openjdk.java.net/jdk/pull/207/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=207&range=07
  Stats: 1498 lines in 35 files changed: 1011 ins; 22 del; 465 mod
  Patch: https://git.openjdk.java.net/jdk/pull/207.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/207/head:pull/207

PR: https://git.openjdk.java.net/jdk/pull/207

From lancea at openjdk.java.net  Mon Oct 12 15:40:19 2020
From: lancea at openjdk.java.net (Lance Andersen)
Date: Mon, 12 Oct 2020 15:40:19 GMT
Subject: RFR: 8253952: Refine ZipOutputStream.putNextEntry() to
 recalculate ZipEntry's compressed size [v3]
In-Reply-To: <iMuYmEv-fCgpaIueHT5E_f28siuhzUjohwreSCZT8Dc=.d765890e-dea1-4207-83be-18d1726262bc@github.com>
References: <0nq5oFKOj6AZqCW6jF268-6oKRI6UkS6TRIHo-_5vKw=.d13c7016-4473-4b20-9117-100b368d3716@github.com>
 <iMuYmEv-fCgpaIueHT5E_f28siuhzUjohwreSCZT8Dc=.d765890e-dea1-4207-83be-18d1726262bc@github.com>
Message-ID: <n8k6JG1lOoZzHGi4lvIFDmJTNwVNvEE4B9Ks9V-1AG4=.c71684bc-e5e1-444a-9c3f-b2e1dab5e129@github.com>

On Mon, 12 Oct 2020 11:44:28 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> ### Summary
>> 
>> Work around wrong usage of `ZipOutputStream.putNextEntry()` in user code which can lead to the `ZipException "invalid
>> entry compressed size"`.
>> ### Motivation
>> 
>> In general it is not safe to directly write a ZipEntry obtained from `ZipInputStream.getNextEntry()`,
>> `ZipFile.entries()`, `ZipFile.getEntry()` or `ZipFile.stream()` with `ZipOutputStream.putNextEntry()` to a
>> `ZipOutputStream` and then read the entries data from the `ZipInputStream` and write it to the `ZipOutputStream` as
>> follows:
>>  ZipEntry entry;
>>  ZipInputStream zis = new ZipInputStream(...);
>>  ZipOutputStream zos = new ZipOutputStream(...);
>>  while((entry = zis.getNextEntry()) != null) {
>>      zos.putNextEntry(entry);
>>      zis.transferTo(zos);
>>  }
>> The problem with this code is that the zip file format does not record the compression level used for deflation in its
>> entries. In general, it doesn't even mandate a predefined compression ratio per compression level. Therefore the
>> compressed size recorded in a `ZipEntry` read from a zip file might differ from the new compressed size produced by the
>> receiving `ZipOutputStream`. Such a difference will result in a `ZipException` with the following message:
>>  java.util.zip.ZipException: invalid entry compressed size (expected 12 but got 7 bytes)
>>  
>> The correct way of copying all entries from one zip file into another requires the creation of a new `ZipEntry` or at
>> least resetting of the compressed size field. E.g.:
>>  while((entry = zis.getNextEntry()) != null) {
>>      ZipEntry newEntry = new ZipEntry(entry.getName());
>>      zos.putNextEntry(newEntry);
>>      zis.transferTo(zos);
>>  }
>> or:
>>  while((entry = zis.getNextEntry()) != null) {
>>      entry.setCompressedSize(-1);
>>      zos.putNextEntry(entry);
>>      zis.transferTo(zos);
>>  }
>> Unfortunately, there's a lot of user code out there which gets this wrong and uses the bad coding pattern described
>> before. Searching for `"java.util.zip.ZipException: invalid entry compressed size (expected 12 but got 7 bytes)"` gives
>> ~2500 hits (~100 on StackOverflow). It's also no hard to find plenty of instances of this anti-pattern on GitHub when
>> doing a code search for `ZipEntry` and `putNextEntry()`. E.g. [Gradle 4.x wrapper task][1] is affected as well as the
>> latest version of the [mockableAndroidJar task][2]. I've recently fixed two occurrences of this pattern in OpenJDK (see
>> [JDK-8240333][3] and [JDK-8240235][4]) but there still exist more of them (e.g.
>> [`test/jdk/java/util/zip/ZipFile/CopyJar.java`][5] which is there since 1999 :).  ### Description  So while this has
>> clearly been a problem before, it apparently wasn't painful enough to trigger any action from the side of the JDK.
>> However, recently quite some zlib forks with [superior deflate/inflate performance have evolved][6]. Using them with
>> OpenJDK is quite straight-forward: one just has to configure the alternative implementations by setting
>> `LD_LIBRARY_PATH` or `LD_PRELOAD` correspondingly. We've seen big saving by using these new zlib implementations for
>> selected services in production and the only reason why we haven't enabled them by default until now is the problem
>> I've just described. The reason why these new libraries uncover the described anti-pattern much more often is because
>> their compression ratio is slightly different from that of the default zlib library. This can easily trigger a
>> `ZipException` even if an application is not using a different compression levels but just a zip file created with
>> another zlib version.  I'd therefore like to propose the following workaround for the wrong
>> `ZipOutputStream.putNextEntry()` usage in user code:
>> -  ignore the compressed size if it was implicitly determined from the zip file and not explicitly set by calling
>>    `ZipEntry.setCompressedSize()`.
>> 
>> - Change the API-documentation of `ZipOutputStream.putNextEntry()` and `JarOutputStream.putNextEntry()` to explain the
>>   problem and why `putNextEntry()` will ignore the compressed size of a `ZipEntry` if that was set implicitely when
>>   reading that entry from a `ZipFile` or `ZipInputStream`.
>> 
>> 
>> ### Technical Details
>> 
>> A zip file consists of a stream of File Entries followed by a Central Directory (see [here for a more detailed
>> specification][7]). Each File Entry is composed of a Local File Header (LFH) followed by the compressed Data and an
>> optional Data Descriptor. The LFH contains the File Name and among other attributes the Compressed and Uncompressed
>> size and CRC of the Data. In the case where the latter three attributes are not available at the time when the LFH is
>> created, this fact will be recorded in a flag of the LFH and will trigger the creation of a Data Descriptor with the
>> corresponding information right after the Data section. Finally, the Central Directory contains one Central Directory
>> File Header (CDFH) for each entry of the  zip archive. The CDFH is an extended version of the LFH and the ultimate
>> reference for the contents of the zip archive. The redundancy between LFH and CDFH is a tribute to zip's long history
>> when it was used to store archives on multiple floppy discs and the CDFH allowed to update the archive by only writing
>> to the last disc which contained the Central Directory.  `ZipEntries` read with `ZipInputStream.getNextEntry()` will
>> initially only contain the information from the LFH. Only after the next entry was read (or after
>> `ZipInputStream.closeEntry()` was called explicitly), will the previously read entry be updated with the data from the
>> Data Descriptor. `ZipInputStream` doesn't inspect the Central Directory at all.  On the other hand, `ZipFile` only
>> queries the Central Directory for `ZipEntry` information so all `ZipEntries` returned by `ZipFile.entries()`,
>> `ZipFile.getEntry()` and `ZipFile.stream()` will always instantly contain the full Compressed and Uncompressed Size and
>> CRC information for each entry independently of the LFH contents.  ### Risks and Assumptions  If we choose to ignore
>> the implicitly recorded compressed size in a `ZipEntry` read from a zip file when writing it to a `ZipOutputStream`,
>> this will lead to zip files with incomplete information in the LFH and an additional Data Descriptor as described
>> before. However, the result is still fully compatible to the zip file specification. It's also not unusual, because by
>> default all new zip files created with `ZipOutputStream` will contain LFHs without Compressed and Uncompressed Size and
>> CRC information and an additional Data Descriptor. Theoretically it is possible to create new zip files with
>> `ZipOutputStream` class and Compressed and Uncompressed Size and CRC information in the LFH but that's complex and
>> inefficient because it requires two steps. A first step to determine the crc and compressed size of the data and a
>> second step to actually write the data to the `ZipOutputStream` (which will compress it a second time). This is because
>> the current API offers no possibility to write already compressed data to a `ZipOutputStream`.  Consequently, the only
>> straight-forward way of creating zip files from Java which have all the data in the LFH and no Data Descriptor is by
>> copying `ZipEntries` from an existing zip file with the buggy method described before. This incidentally worked more or
>> less reliable for a long time but breaks miserably when using different zlib implementations. Ignoring the implicitly
>> set compressed size of `ZipEntries` can easily fix this problem.  I'm not aware of any tool which can not handle such
>> files and if it exists it would have problems with the majority of Java created zip files anyway (e.g. all jar-files
>> created with the jar tool have zip entries with incomplete LFH data and additional Data Descriptor).  Ignoring the
>> implicitly set compressed size of `ZipEntries` has no measurable performance impact and will increase the size of zip
>> archives which used to have the complete file information in the LFH before by 16 bytes per entry. On the other hand it
>> will give us the freedom to use whatever zip implementation we like :)   [1]:
>> https://github.com/gradle/gradle/blob/e76905e3a/subprojects/build-init/src/main/java/org/gradle/api/tasks/wrapper/Wrapper.java#L152-L158
>> [2]:
>> https://android.googlesource.com/platform/tools/base/+/refs/heads/master/build-system/builder/src/main/java/com/android/builder/testing/MockableJarGenerator.java#86
>> [3]: https://bugs.openjdk.java.net/browse/JDK-8240333 [4]: https://bugs.openjdk.java.net/browse/JDK-8240235 [5]:
>> https://github.com/openjdk/jdk/blob/master/test/jdk/java/util/zip/ZipFile/CopyJar.java [6]:
>> https://github.com/simonis/zlib-bench/blob/master/Results.md [7]: https://en.wikipedia.org/wiki/Zip_(file_format)
>
> Volker Simonis 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:
>   8253952: Refine ZipOutputStream.putNextEntry() to recalculate ZipEntry's compressed size

src/java.base/share/classes/java/util/jar/JarOutputStream.java line 81:

> 79:      * any previous entry. The default compression method will be
> 80:      * used if no compression method was specified for the entry.
> 81:      * When writing a compressed (i.e. {@code ZipEntry.DEFLATED}))

I would leave as DEFLATED given it is used this way in other ZipOutputStream methods and I would also remove the  "i.e."

-------------

PR: https://git.openjdk.java.net/jdk/pull/520

From lancea at openjdk.java.net  Mon Oct 12 15:40:20 2020
From: lancea at openjdk.java.net (Lance Andersen)
Date: Mon, 12 Oct 2020 15:40:20 GMT
Subject: RFR: 8253952: Refine ZipOutputStream.putNextEntry() to
 recalculate ZipEntry's compressed size [v3]
In-Reply-To: <v6PoI2e4H4_pziBlLxQxagD-FGuDyBcugNZq1KYjRB0=.4a4197c6-f28b-4b84-a792-21f06dd8d992@github.com>
References: <0nq5oFKOj6AZqCW6jF268-6oKRI6UkS6TRIHo-_5vKw=.d13c7016-4473-4b20-9117-100b368d3716@github.com>
 <iMuYmEv-fCgpaIueHT5E_f28siuhzUjohwreSCZT8Dc=.d765890e-dea1-4207-83be-18d1726262bc@github.com>
 <v6PoI2e4H4_pziBlLxQxagD-FGuDyBcugNZq1KYjRB0=.4a4197c6-f28b-4b84-a792-21f06dd8d992@github.com>
Message-ID: <d0NGVAhYu4remsGA6ushF4pdCUfb84py961yl3VYF5c=.f001bf55-b557-472b-8174-8339c446c55a@github.com>

On Mon, 12 Oct 2020 12:48:36 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Volker Simonis 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:
>>   8253952: Refine ZipOutputStream.putNextEntry() to recalculate ZipEntry's compressed size
>
> src/java.base/share/classes/java/util/jar/JarOutputStream.java line 86:
> 
>> 84:      * compressed size will be set to the actual compressed size after
>> 85:      * deflation. The current time will be used if the entry has no set
>> 86:      * modification time.
> 
> Thanks for combining the wording, I think this looks good. I'd probably drop "i.e." so that it's just "DEFLATED"
> parentheses.

I might consider making "The current time..." its own paragraph separate from the compression discussion as I think it
would be clearer that way.

> src/java.base/share/classes/java/util/zip/ZipOutputStream.java line 216:
> 
>> 214:                 e.flag = 8;
>> 215:             }
>> 216:             else if (!e.manual_csize) {
> 
> I assume the existing expression that set if csize has been set so that we don't set the flag to 8 in two branches.

I was thinking about that myself

-------------

PR: https://git.openjdk.java.net/jdk/pull/520

From lancea at openjdk.java.net  Mon Oct 12 15:45:24 2020
From: lancea at openjdk.java.net (Lance Andersen)
Date: Mon, 12 Oct 2020 15:45:24 GMT
Subject: RFR: 8253952: Refine ZipOutputStream.putNextEntry() to
 recalculate ZipEntry's compressed size [v3]
In-Reply-To: <iMuYmEv-fCgpaIueHT5E_f28siuhzUjohwreSCZT8Dc=.d765890e-dea1-4207-83be-18d1726262bc@github.com>
References: <0nq5oFKOj6AZqCW6jF268-6oKRI6UkS6TRIHo-_5vKw=.d13c7016-4473-4b20-9117-100b368d3716@github.com>
 <iMuYmEv-fCgpaIueHT5E_f28siuhzUjohwreSCZT8Dc=.d765890e-dea1-4207-83be-18d1726262bc@github.com>
Message-ID: <HWODTjWT1Sk6HY5Lqr9H3qEn43VvRagGEQBUPau85KU=.3ae62bdc-123b-44d7-b799-f47e21c803bc@github.com>

On Mon, 12 Oct 2020 11:44:28 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> ### Summary
>> 
>> Work around wrong usage of `ZipOutputStream.putNextEntry()` in user code which can lead to the `ZipException "invalid
>> entry compressed size"`.
>> ### Motivation
>> 
>> In general it is not safe to directly write a ZipEntry obtained from `ZipInputStream.getNextEntry()`,
>> `ZipFile.entries()`, `ZipFile.getEntry()` or `ZipFile.stream()` with `ZipOutputStream.putNextEntry()` to a
>> `ZipOutputStream` and then read the entries data from the `ZipInputStream` and write it to the `ZipOutputStream` as
>> follows:
>>  ZipEntry entry;
>>  ZipInputStream zis = new ZipInputStream(...);
>>  ZipOutputStream zos = new ZipOutputStream(...);
>>  while((entry = zis.getNextEntry()) != null) {
>>      zos.putNextEntry(entry);
>>      zis.transferTo(zos);
>>  }
>> The problem with this code is that the zip file format does not record the compression level used for deflation in its
>> entries. In general, it doesn't even mandate a predefined compression ratio per compression level. Therefore the
>> compressed size recorded in a `ZipEntry` read from a zip file might differ from the new compressed size produced by the
>> receiving `ZipOutputStream`. Such a difference will result in a `ZipException` with the following message:
>>  java.util.zip.ZipException: invalid entry compressed size (expected 12 but got 7 bytes)
>>  
>> The correct way of copying all entries from one zip file into another requires the creation of a new `ZipEntry` or at
>> least resetting of the compressed size field. E.g.:
>>  while((entry = zis.getNextEntry()) != null) {
>>      ZipEntry newEntry = new ZipEntry(entry.getName());
>>      zos.putNextEntry(newEntry);
>>      zis.transferTo(zos);
>>  }
>> or:
>>  while((entry = zis.getNextEntry()) != null) {
>>      entry.setCompressedSize(-1);
>>      zos.putNextEntry(entry);
>>      zis.transferTo(zos);
>>  }
>> Unfortunately, there's a lot of user code out there which gets this wrong and uses the bad coding pattern described
>> before. Searching for `"java.util.zip.ZipException: invalid entry compressed size (expected 12 but got 7 bytes)"` gives
>> ~2500 hits (~100 on StackOverflow). It's also no hard to find plenty of instances of this anti-pattern on GitHub when
>> doing a code search for `ZipEntry` and `putNextEntry()`. E.g. [Gradle 4.x wrapper task][1] is affected as well as the
>> latest version of the [mockableAndroidJar task][2]. I've recently fixed two occurrences of this pattern in OpenJDK (see
>> [JDK-8240333][3] and [JDK-8240235][4]) but there still exist more of them (e.g.
>> [`test/jdk/java/util/zip/ZipFile/CopyJar.java`][5] which is there since 1999 :).  ### Description  So while this has
>> clearly been a problem before, it apparently wasn't painful enough to trigger any action from the side of the JDK.
>> However, recently quite some zlib forks with [superior deflate/inflate performance have evolved][6]. Using them with
>> OpenJDK is quite straight-forward: one just has to configure the alternative implementations by setting
>> `LD_LIBRARY_PATH` or `LD_PRELOAD` correspondingly. We've seen big saving by using these new zlib implementations for
>> selected services in production and the only reason why we haven't enabled them by default until now is the problem
>> I've just described. The reason why these new libraries uncover the described anti-pattern much more often is because
>> their compression ratio is slightly different from that of the default zlib library. This can easily trigger a
>> `ZipException` even if an application is not using a different compression levels but just a zip file created with
>> another zlib version.  I'd therefore like to propose the following workaround for the wrong
>> `ZipOutputStream.putNextEntry()` usage in user code:
>> -  ignore the compressed size if it was implicitly determined from the zip file and not explicitly set by calling
>>    `ZipEntry.setCompressedSize()`.
>> 
>> - Change the API-documentation of `ZipOutputStream.putNextEntry()` and `JarOutputStream.putNextEntry()` to explain the
>>   problem and why `putNextEntry()` will ignore the compressed size of a `ZipEntry` if that was set implicitely when
>>   reading that entry from a `ZipFile` or `ZipInputStream`.
>> 
>> 
>> ### Technical Details
>> 
>> A zip file consists of a stream of File Entries followed by a Central Directory (see [here for a more detailed
>> specification][7]). Each File Entry is composed of a Local File Header (LFH) followed by the compressed Data and an
>> optional Data Descriptor. The LFH contains the File Name and among other attributes the Compressed and Uncompressed
>> size and CRC of the Data. In the case where the latter three attributes are not available at the time when the LFH is
>> created, this fact will be recorded in a flag of the LFH and will trigger the creation of a Data Descriptor with the
>> corresponding information right after the Data section. Finally, the Central Directory contains one Central Directory
>> File Header (CDFH) for each entry of the  zip archive. The CDFH is an extended version of the LFH and the ultimate
>> reference for the contents of the zip archive. The redundancy between LFH and CDFH is a tribute to zip's long history
>> when it was used to store archives on multiple floppy discs and the CDFH allowed to update the archive by only writing
>> to the last disc which contained the Central Directory.  `ZipEntries` read with `ZipInputStream.getNextEntry()` will
>> initially only contain the information from the LFH. Only after the next entry was read (or after
>> `ZipInputStream.closeEntry()` was called explicitly), will the previously read entry be updated with the data from the
>> Data Descriptor. `ZipInputStream` doesn't inspect the Central Directory at all.  On the other hand, `ZipFile` only
>> queries the Central Directory for `ZipEntry` information so all `ZipEntries` returned by `ZipFile.entries()`,
>> `ZipFile.getEntry()` and `ZipFile.stream()` will always instantly contain the full Compressed and Uncompressed Size and
>> CRC information for each entry independently of the LFH contents.  ### Risks and Assumptions  If we choose to ignore
>> the implicitly recorded compressed size in a `ZipEntry` read from a zip file when writing it to a `ZipOutputStream`,
>> this will lead to zip files with incomplete information in the LFH and an additional Data Descriptor as described
>> before. However, the result is still fully compatible to the zip file specification. It's also not unusual, because by
>> default all new zip files created with `ZipOutputStream` will contain LFHs without Compressed and Uncompressed Size and
>> CRC information and an additional Data Descriptor. Theoretically it is possible to create new zip files with
>> `ZipOutputStream` class and Compressed and Uncompressed Size and CRC information in the LFH but that's complex and
>> inefficient because it requires two steps. A first step to determine the crc and compressed size of the data and a
>> second step to actually write the data to the `ZipOutputStream` (which will compress it a second time). This is because
>> the current API offers no possibility to write already compressed data to a `ZipOutputStream`.  Consequently, the only
>> straight-forward way of creating zip files from Java which have all the data in the LFH and no Data Descriptor is by
>> copying `ZipEntries` from an existing zip file with the buggy method described before. This incidentally worked more or
>> less reliable for a long time but breaks miserably when using different zlib implementations. Ignoring the implicitly
>> set compressed size of `ZipEntries` can easily fix this problem.  I'm not aware of any tool which can not handle such
>> files and if it exists it would have problems with the majority of Java created zip files anyway (e.g. all jar-files
>> created with the jar tool have zip entries with incomplete LFH data and additional Data Descriptor).  Ignoring the
>> implicitly set compressed size of `ZipEntries` has no measurable performance impact and will increase the size of zip
>> archives which used to have the complete file information in the LFH before by 16 bytes per entry. On the other hand it
>> will give us the freedom to use whatever zip implementation we like :)   [1]:
>> https://github.com/gradle/gradle/blob/e76905e3a/subprojects/build-init/src/main/java/org/gradle/api/tasks/wrapper/Wrapper.java#L152-L158
>> [2]:
>> https://android.googlesource.com/platform/tools/base/+/refs/heads/master/build-system/builder/src/main/java/com/android/builder/testing/MockableJarGenerator.java#86
>> [3]: https://bugs.openjdk.java.net/browse/JDK-8240333 [4]: https://bugs.openjdk.java.net/browse/JDK-8240235 [5]:
>> https://github.com/openjdk/jdk/blob/master/test/jdk/java/util/zip/ZipFile/CopyJar.java [6]:
>> https://github.com/simonis/zlib-bench/blob/master/Results.md [7]: https://en.wikipedia.org/wiki/Zip_(file_format)
>
> Volker Simonis 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:
>   8253952: Refine ZipOutputStream.putNextEntry() to recalculate ZipEntry's compressed size

I think we are getting close.    Once the javadoc is cleaned up along with the minor changes recommended  we should be
in good shape and can then review the CSR

-------------

Changes requested by lancea (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/520

From alanb at openjdk.java.net  Mon Oct 12 15:52:13 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 12 Oct 2020 15:52:13 GMT
Subject: RFR: 8253952: Refine ZipOutputStream.putNextEntry() to
 recalculate ZipEntry's compressed size [v3]
In-Reply-To: <n8k6JG1lOoZzHGi4lvIFDmJTNwVNvEE4B9Ks9V-1AG4=.c71684bc-e5e1-444a-9c3f-b2e1dab5e129@github.com>
References: <0nq5oFKOj6AZqCW6jF268-6oKRI6UkS6TRIHo-_5vKw=.d13c7016-4473-4b20-9117-100b368d3716@github.com>
 <iMuYmEv-fCgpaIueHT5E_f28siuhzUjohwreSCZT8Dc=.d765890e-dea1-4207-83be-18d1726262bc@github.com>
 <n8k6JG1lOoZzHGi4lvIFDmJTNwVNvEE4B9Ks9V-1AG4=.c71684bc-e5e1-444a-9c3f-b2e1dab5e129@github.com>
Message-ID: <aKwz_mecWOHmhw-HXvcmoXb55lWKs1cyfOyXKRo_AUc=.1260b942-c46a-422c-b817-ca3225b38118@github.com>

On Mon, 12 Oct 2020 15:35:12 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Volker Simonis 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:
>>   8253952: Refine ZipOutputStream.putNextEntry() to recalculate ZipEntry's compressed size
>
> src/java.base/share/classes/java/util/jar/JarOutputStream.java line 81:
> 
>> 79:      * any previous entry. The default compression method will be
>> 80:      * used if no compression method was specified for the entry.
>> 81:      * When writing a compressed (i.e. {@code ZipEntry.DEFLATED}))
> 
> I would leave as DEFLATED given it is used this way in other ZipOutputStream methods and I would also remove the  "i.e."

I would prefer to keep it as "When writing as compressed (DEFLATED) ..." to keep the terminology consistent when
linking to the setCompressedMethod.

-------------

PR: https://git.openjdk.java.net/jdk/pull/520

From lancea at openjdk.java.net  Mon Oct 12 15:57:15 2020
From: lancea at openjdk.java.net (Lance Andersen)
Date: Mon, 12 Oct 2020 15:57:15 GMT
Subject: RFR: 8253952: Refine ZipOutputStream.putNextEntry() to
 recalculate ZipEntry's compressed size [v3]
In-Reply-To: <aKwz_mecWOHmhw-HXvcmoXb55lWKs1cyfOyXKRo_AUc=.1260b942-c46a-422c-b817-ca3225b38118@github.com>
References: <0nq5oFKOj6AZqCW6jF268-6oKRI6UkS6TRIHo-_5vKw=.d13c7016-4473-4b20-9117-100b368d3716@github.com>
 <iMuYmEv-fCgpaIueHT5E_f28siuhzUjohwreSCZT8Dc=.d765890e-dea1-4207-83be-18d1726262bc@github.com>
 <n8k6JG1lOoZzHGi4lvIFDmJTNwVNvEE4B9Ks9V-1AG4=.c71684bc-e5e1-444a-9c3f-b2e1dab5e129@github.com>
 <aKwz_mecWOHmhw-HXvcmoXb55lWKs1cyfOyXKRo_AUc=.1260b942-c46a-422c-b817-ca3225b38118@github.com>
Message-ID: <6HxY6XtWrf29dTXOd1ptm23hMncg7AIhqLvX0xrMO4A=.a649a6a8-19ea-4c2f-968a-711a7dbfa4cd@github.com>

On Mon, 12 Oct 2020 15:49:29 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/jar/JarOutputStream.java line 81:
>> 
>>> 79:      * any previous entry. The default compression method will be
>>> 80:      * used if no compression method was specified for the entry.
>>> 81:      * When writing a compressed (i.e. {@code ZipEntry.DEFLATED}))
>> 
>> I would leave as DEFLATED given it is used this way in other ZipOutputStream methods and I would also remove the  "i.e."
>
> I would prefer to keep it as "When writing as compressed (DEFLATED) ..." to keep the terminology consistent when
> linking to the setCompressedMethod.

Agree, no need for ZipEntry.DEFLATED which is what I was trying to say (sorry if that was not clear).  Only suggesting
ZipEntry.DEFLATED -> DEFLATED and remove  the ".i.e."

-------------

PR: https://git.openjdk.java.net/jdk/pull/520

From kbarrett at openjdk.java.net  Mon Oct 12 16:00:15 2020
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Mon, 12 Oct 2020 16:00:15 GMT
Subject: RFR: 8188055: (ref) Add Reference::refersTo predicate [v2]
In-Reply-To: <fdRw8XxvrIGJI35awI_IOOg2tucC2JpjupFaVJ1lMvI=.b0b42966-48b0-4915-a9c0-b61866cb9276@github.com>
References: <D4HSg8FT20Eaxk5KJkkw0GgETSxRkBn1ipS3Dt0kPto=.e4bab078-2e04-4413-90cb-9bfafb2a6831@github.com>
 <QpVGNFn7FwJVVijkSVKgUxWDLw3Y7im-mlA3yw7_crU=.1e8d22b9-29e8-4347-8790-2fe213435219@github.com>
 <fdRw8XxvrIGJI35awI_IOOg2tucC2JpjupFaVJ1lMvI=.b0b42966-48b0-4915-a9c0-b61866cb9276@github.com>
Message-ID: <c1xBid7xMlFExHk4P43Hyf0SnYAJNPvW511XYzzy3QE=.e401cd8a-d34c-4f54-869c-43f7656b6bac@github.com>

On Mon, 12 Oct 2020 07:43:19 GMT, Per Liden <pliden at openjdk.org> wrote:

>> Kim Barrett has updated the pull request incrementally with five additional commits since the last revision:
>> 
>>  - improve refersTo0 descriptions
>>  - basic functional test
>>  - change referent access
>>  - expand test
>>  - remove CMS comment
>
> test/jdk/java/lang/ref/ReferenceRefersTo.java line 58:
> 
>> 56:             fail(kind + " doesn't refer to expected value");
>> 57:         } else if (ref.refersTo(unexpectedValue)) {
>> 58:             fail(kind + " refers to unexpected value");
> 
> This part, and the use of obj3, below seems odd and unnecessary. If the Reference doesn't have the expected value
> there's no special reason to think it has obj3 as value (as opposed to something else). I don't think this check will
> help debugging if this test fails.

A possible failure mode is to implement the predicate incorrectly, perhaps flipping the sense of the predicate. This
may help notice such. It's distinct from the null test, since null is a special value that might be handled differently.

> test/jdk/java/lang/ref/ReferenceRefersTo.java line 42:
> 
>> 40:             this.value = value;
>> 41:         }
>> 42:     }
> 
> Introducing this class seems unnecessary, since its `value` is never used. So all instances of `TestObject` could just
> be `Object`.

I'd intended to use the value field when printing failure messages, but that became a little messy and probably not
worth the trouble in the face of possible null values. So yeah, just using Object is fine; I'll make that change.

> test/hotspot/jtreg/gc/TestReferenceRefersTo.java line 186:
> 
>> 184:
>> 185:             expectNotValue(testWeak2, testObject3, "testWeak2");
>> 186:             expectValue(testWeak3, testObject3, "testWeak3");
> 
> It looks to me like the `expectNotCleared()` and `expectNotValue()` methods can be removed. All expect-tests can be
> done with just `expectCleared()` and `expectValue()`.

I don't think so.  For example,
`expectNotCleared(testWeak1, "testWeak1")`
is not testing the same thing as
`expectValue(testWeak1, testObject1, "testWeak1")`
If the implementation is correct they will indeed always be consistent. But they could be different with an incorrect
implementation.

-------------

PR: https://git.openjdk.java.net/jdk/pull/498

From chegar at openjdk.java.net  Mon Oct 12 16:08:17 2020
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Mon, 12 Oct 2020 16:08:17 GMT
Subject: RFR: 8254161: Prevent instantiation of EnumSet subclasses through
 deserialization
Message-ID: <etFbiCFeHwDnYXo3yzhQT66jXhSMbRn57DEGZz-d3V8=.55b262dd-27a1-48c2-ae9b-ce6a55f45b53@github.com>

TL;DR add EnumSet::readObjectNoData()

EnumSet is an exemplar of the Serialization Proxy Pattern. As such, it
should strictly implement that pattern and demonstrate how best to
defend against inappropriate instantiation through deserialization.

EnumSet is an extensible class. There are two subclasses in the JDK,
RegularEnumSet and JumboEnumSet. Since the serialization of an EnumSet
object writes a replacement object to the serial stream, a serial proxy
object, then stream objects of type RegularEnumSet or JumboEnumSet are
not expected in the serial stream. However, if they are present in the
serial stream, then, during deserialization, the EnumSet::readObject
method will be invoked. EnumSet::readObject unconditionally throws an
exception, thus preventing further deserialization of the stream object.
In this way, stream objects that are subclasses of EnumSet are prevented
from being instantiated through deserialization. But this is not
sufficient to prevent such in all scenarios.

A stream object whose local class equivalent of the specified stream
class descriptor is a subclasses of EnumSet, but whose specified stream
class descriptor does not list EnumSet as a superClass, may be
instantiated through deserialization. Since the stream class descriptor
does not list EnumSet as a superclass, then the defensive
EnumSet::readObject is never invoked. To prevent such objects from
being deserialized, an EnumSet::readObjectNoData() should be added -
whose implementation unconditionally throws an exception, similar to
that of the existing EnumSet::readObject.

-------------

Commit messages:
 - Initial changes for 8254161 - Prevent instantiation of EnumSet subclasses through deserialization

Changes: https://git.openjdk.java.net/jdk/pull/611/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=611&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8254161
  Stats: 11 lines in 1 file changed: 11 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/611.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/611/head:pull/611

PR: https://git.openjdk.java.net/jdk/pull/611

From dfuchs at openjdk.java.net  Mon Oct 12 16:59:14 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Mon, 12 Oct 2020 16:59:14 GMT
Subject: RFR: 8254161: Prevent instantiation of EnumSet subclasses through
 deserialization
In-Reply-To: <etFbiCFeHwDnYXo3yzhQT66jXhSMbRn57DEGZz-d3V8=.55b262dd-27a1-48c2-ae9b-ce6a55f45b53@github.com>
References: <etFbiCFeHwDnYXo3yzhQT66jXhSMbRn57DEGZz-d3V8=.55b262dd-27a1-48c2-ae9b-ce6a55f45b53@github.com>
Message-ID: <5whFN3AEXeA4rYogOUdkrwkhH0WlGM7YzfFtuA3wScw=.e07c9a49-53e4-4668-afcd-dba12d6a33f7@github.com>

On Mon, 12 Oct 2020 13:47:46 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

> TL;DR add EnumSet::readObjectNoData()
> 
> EnumSet is an exemplar of the Serialization Proxy Pattern. As such, it
> should strictly implement that pattern and demonstrate how best to
> defend against inappropriate instantiation through deserialization.
> 
> EnumSet is an extensible class. There are two subclasses in the JDK,
> RegularEnumSet and JumboEnumSet. Since the serialization of an EnumSet
> object writes a replacement object to the serial stream, a serial proxy
> object, then stream objects of type RegularEnumSet or JumboEnumSet are
> not expected in the serial stream. However, if they are present in the
> serial stream, then, during deserialization, the EnumSet::readObject
> method will be invoked. EnumSet::readObject unconditionally throws an
> exception, thus preventing further deserialization of the stream object.
> In this way, stream objects that are subclasses of EnumSet are prevented
> from being instantiated through deserialization. But this is not
> sufficient to prevent such in all scenarios.
> 
> A stream object whose local class equivalent of the specified stream
> class descriptor is a subclasses of EnumSet, but whose specified stream
> class descriptor does not list EnumSet as a superClass, may be
> instantiated through deserialization. Since the stream class descriptor
> does not list EnumSet as a superclass, then the defensive
> EnumSet::readObject is never invoked. To prevent such objects from
> being deserialized, an EnumSet::readObjectNoData() should be added -
> whose implementation unconditionally throws an exception, similar to
> that of the existing EnumSet::readObject.

Marked as reviewed by dfuchs (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/611

From alanb at openjdk.java.net  Mon Oct 12 17:07:14 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 12 Oct 2020 17:07:14 GMT
Subject: RFR: 8254161: Prevent instantiation of EnumSet subclasses through
 deserialization
In-Reply-To: <etFbiCFeHwDnYXo3yzhQT66jXhSMbRn57DEGZz-d3V8=.55b262dd-27a1-48c2-ae9b-ce6a55f45b53@github.com>
References: <etFbiCFeHwDnYXo3yzhQT66jXhSMbRn57DEGZz-d3V8=.55b262dd-27a1-48c2-ae9b-ce6a55f45b53@github.com>
Message-ID: <Ieszqi9VkS5xOstcM1NqIS_4lhoMln4knPdOU3kb6tc=.3e702447-7fb8-4725-9e5b-7f8c4c9eac26@github.com>

On Mon, 12 Oct 2020 13:47:46 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

> TL;DR add EnumSet::readObjectNoData()
> 
> EnumSet is an exemplar of the Serialization Proxy Pattern. As such, it
> should strictly implement that pattern and demonstrate how best to
> defend against inappropriate instantiation through deserialization.
> 
> EnumSet is an extensible class. There are two subclasses in the JDK,
> RegularEnumSet and JumboEnumSet. Since the serialization of an EnumSet
> object writes a replacement object to the serial stream, a serial proxy
> object, then stream objects of type RegularEnumSet or JumboEnumSet are
> not expected in the serial stream. However, if they are present in the
> serial stream, then, during deserialization, the EnumSet::readObject
> method will be invoked. EnumSet::readObject unconditionally throws an
> exception, thus preventing further deserialization of the stream object.
> In this way, stream objects that are subclasses of EnumSet are prevented
> from being instantiated through deserialization. But this is not
> sufficient to prevent such in all scenarios.
> 
> A stream object whose local class equivalent of the specified stream
> class descriptor is a subclasses of EnumSet, but whose specified stream
> class descriptor does not list EnumSet as a superClass, may be
> instantiated through deserialization. Since the stream class descriptor
> does not list EnumSet as a superclass, then the defensive
> EnumSet::readObject is never invoked. To prevent such objects from
> being deserialized, an EnumSet::readObjectNoData() should be added -
> whose implementation unconditionally throws an exception, similar to
> that of the existing EnumSet::readObject.

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/611

From naoto at openjdk.java.net  Mon Oct 12 17:08:17 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 12 Oct 2020 17:08:17 GMT
Subject: RFR: 8254177: (tz) Upgrade time-zone data to tzdata2020b
In-Reply-To: <KvYfzEHlUV_cV29YAN2i2uXph2lldf0GGz_9TE5O0Iw=.c2d0262d-50d8-49fc-9815-1482616d1a3c@github.com>
References: <KvYfzEHlUV_cV29YAN2i2uXph2lldf0GGz_9TE5O0Iw=.c2d0262d-50d8-49fc-9815-1482616d1a3c@github.com>
Message-ID: <BR57psTBXz0VHZpZvfvT3acDjupN3qxRLirR9Si3mkc=.3e0bba96-cb58-477c-9948-981ab807a4d9@github.com>

On Mon, 12 Oct 2020 09:32:38 GMT, Kiran Sidhartha Ravikumar <kravikumar at openjdk.org> wrote:

> Hi Guys,
> 
> Please review the patch for tzdata2020b integration into JDK.
> 
> Release details can be found here:
> 
> https://mm.icann.org/pipermail/tz-announce/2020-October/000059.html
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8254177
> 
> I had the pacificnew, systemv files removed from JDK repo and so TimeZoneName classes, make file and few test files
> need to be updated to incorporate the change.
> The patch has passed all the related testing including JCK.
> 
> Thanks,
> Kiran

Looks good to me.
I was wondering about the consequence of removing the "US/Pacific-New" zone names, but since the time zone should never
have been introduced in the first place (it didn't become the law), I think no real world application would have used
it.

-------------

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/602

From mchung at openjdk.java.net  Mon Oct 12 17:13:20 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Mon, 12 Oct 2020 17:13:20 GMT
Subject: RFR: 8188055: (ref) Add Reference::refersTo predicate [v2]
In-Reply-To: <QpVGNFn7FwJVVijkSVKgUxWDLw3Y7im-mlA3yw7_crU=.1e8d22b9-29e8-4347-8790-2fe213435219@github.com>
References: <D4HSg8FT20Eaxk5KJkkw0GgETSxRkBn1ipS3Dt0kPto=.e4bab078-2e04-4413-90cb-9bfafb2a6831@github.com>
 <QpVGNFn7FwJVVijkSVKgUxWDLw3Y7im-mlA3yw7_crU=.1e8d22b9-29e8-4347-8790-2fe213435219@github.com>
Message-ID: <fBZ3s-kjSkOzhmLCHcV_7JQD3DTf0LcQaBV0I7ZjZTQ=.13d78acb-8898-44f3-bef9-0628840f76c7@github.com>

On Thu, 8 Oct 2020 08:15:07 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Finally returning to this review that was started in April 2020.  I've
>> recast it as a github PR.  I think the security concern raised by Gil
>> has been adequately answered.
>> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-April/029203.html
>> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-July/030401.html
>> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-August/030677.html
>> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-September/030793.html
>> 
>> Please review a new function: java.lang.ref.Reference.refersTo.
>> 
>> This function is needed to test the referent of a Reference object without
>> artificially extending the lifetime of the referent object, as may happen
>> when calling Reference.get.  Some garbage collectors require extending the
>> lifetime of a weak referent when accessed, in order to maintain collector
>> invariants.  Lifetime extension may occur with any collector when the
>> Reference is a SoftReference, as calling get indicates recent access.  This
>> new function also allows testing the referent of a PhantomReference, which
>> can't be accessed by calling get.
>> 
>> The new function uses native methods whose implementations are in the VM so
>> they can use the Access API.  It is the intent that these methods will be
>> intrinsified by optimizing compilers like C2 or graal, but that hasn't been
>> implemented yet.  Bear that in mind before rushing off to change existing
>> uses of Reference.get.
>> 
>> There are two native methods involved, one in Reference and an override in
>> PhantomReference, both package private in java.lang.ref. The reason for this
>> split is to simplify the intrinsification. This is a change from the version
>> from April 2020; that version had a single native method in Reference,
>> implemented using the ON_UNKNOWN_OOP_REF Access reference strength category.
>> However, adding support for that category in the compilers adds significant
>> implementation effort and complexity. Splitting avoids that complexity.
>> 
>> Testing:
>> mach5 tier1
>> Locally (linux-x64) verified the new test passes with various garbage collectors.
>
> Kim Barrett has updated the pull request incrementally with five additional commits since the last revision:
> 
>  - improve refersTo0 descriptions
>  - basic functional test
>  - change referent access
>  - expand test
>  - remove CMS comment

test/jdk/java/lang/ref/ReferenceRefersTo.java line 26:

> 24: /*
> 25:  * @test
> 26:  * @summary Basic functional test of Reference.refersTo.

Thanks for adding this basic test.  Can you add `@bug 8188055`

test/jdk/java/lang/ref/ReferenceRefersTo.java line 49:

> 47:
> 48:     private static final <T extends Reference>
> 49:     void test(T ref,

Nit: I prefer this is merged with line 48 and the line is not too awfully long.

test/jdk/java/lang/ref/ReferenceRefersTo.java line 57:

> 55:         } else if (!ref.refersTo(expectedValue)) {
> 56:             fail(kind + " doesn't refer to expected value");
> 57:         } else if (ref.refersTo(unexpectedValue)) {

Nit: It seems easier to read if these are 3 separate checks, i.e. dropping `else`

-------------

PR: https://git.openjdk.java.net/jdk/pull/498

From yano-masanori at fujitsu.com  Mon Oct 12 02:53:32 2020
From: yano-masanori at fujitsu.com (yano-masanori at fujitsu.com)
Date: Mon, 12 Oct 2020 02:53:32 +0000
Subject: 8253393: Formatter does not throw exception for 0 as argument index
Message-ID: <OSBPR01MB16713F7986E88FF5D0A95E45E7070@OSBPR01MB1671.jpnprd01.prod.outlook.com>

Hello.

I would like to contribute for JDK-8253393.

'java.util.Formatter' should treat "0$" as explicit argument index and throw an 
exception according to the API specification.

> The first argument is referenced by "1$", the second by "2$", etc.

I propose the attached to fix 'java.util.Formatter' behavior properly as 
described in the API specification.

Please sponsor the following change.

diff -r bdc20ee1a68d src/java.base/share/classes/java/util/Formatter.java
--- a/src/java.base/share/classes/java/util/Formatter.java	Fri Sep 04 23:51:26 2020 -0400
+++ b/src/java.base/share/classes/java/util/Formatter.java	Mon Oct 12 11:20:15 2020 +0900
@@ -2783,6 +2783,8 @@
                 try {
                     // skip the trailing '$'
                     index = Integer.parseInt(s, start, end - 1, 10);
+                    if (index < 1)
+                        throw new MissingFormatArgumentException(s.substring(start, end));
                 } catch (NumberFormatException x) {
                     assert(false);
                 }
diff -r bdc20ee1a68d test/jdk/java/util/Formatter/Basic-X.java.template
--- a/test/jdk/java/util/Formatter/Basic-X.java.template	Fri Sep 04 23:51:26 2020 -0400
+++ b/test/jdk/java/util/Formatter/Basic-X.java.template	Mon Oct 12 11:20:15 2020 +0900
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2003, 2019, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2003, 2020, Oracle and/or its affiliates. All rights reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
@@ -420,6 +420,7 @@
         //---------------------------------------------------------------------
         tryCatch("%#b", FormatFlagsConversionMismatchException.class);
         tryCatch("%-b", MissingFormatWidthException.class);
+        tryCatch("%0$b", MissingFormatArgumentException.class);
         // correct or side-effect of implementation?
         tryCatch("%.b", UnknownFormatConversionException.class);
         tryCatch("%,b", FormatFlagsConversionMismatchException.class);
@@ -467,6 +468,7 @@
         tryCatch("%(c", FormatFlagsConversionMismatchException.class);
         tryCatch("%$c", UnknownFormatConversionException.class);
         tryCatch("%.2c", IllegalFormatPrecisionException.class);
+        tryCatch("%0$c", MissingFormatArgumentException.class);
 
         //---------------------------------------------------------------------
         // %s
@@ -494,6 +496,7 @@
         tryCatch("%#s", FormatFlagsConversionMismatchException.class, 0.5f);
         tryCatch("%#s", FormatFlagsConversionMismatchException.class, "hello");
         tryCatch("%#s", FormatFlagsConversionMismatchException.class, null);
+        tryCatch("%0$s", MissingFormatArgumentException.class);
 
         //---------------------------------------------------------------------
         // %h
@@ -628,6 +631,7 @@
         tryCatch("%0d", MissingFormatWidthException.class);
         tryCatch("%-d", MissingFormatWidthException.class);
         tryCatch("%7.3d", IllegalFormatPrecisionException.class);
+        tryCatch("%0$d", MissingFormatArgumentException.class);
 
         //---------------------------------------------------------------------
         // %o
@@ -696,6 +700,7 @@
         tryCatch("%-o", MissingFormatWidthException.class);
         tryCatch("%,o", FormatFlagsConversionMismatchException.class);
         tryCatch("%O", UnknownFormatConversionException.class);
+        tryCatch("%0$o", MissingFormatArgumentException.class);
 
         //---------------------------------------------------------------------
         // %x
@@ -773,6 +778,7 @@
         tryCatch("%,x", FormatFlagsConversionMismatchException.class);
         tryCatch("%0x", MissingFormatWidthException.class);
         tryCatch("%-x", MissingFormatWidthException.class);
+        tryCatch("%0$x", MissingFormatArgumentException.class);
 
 #end[dec]
 
@@ -1679,6 +1685,7 @@
         tryCatch("%.5tB", IllegalFormatPrecisionException.class);
         tryCatch("%#tB", FormatFlagsConversionMismatchException.class);
         tryCatch("%-tB", MissingFormatWidthException.class);
+        tryCatch("%0$t", MissingFormatArgumentException.class);
 
 #if[datetime]
         //---------------------------------------------------------------------
diff -r bdc20ee1a68d test/jdk/java/util/Formatter/BasicBigDecimal.java
--- a/test/jdk/java/util/Formatter/BasicBigDecimal.java	Fri Sep 04 23:51:26 2020 -0400
+++ b/test/jdk/java/util/Formatter/BasicBigDecimal.java	Mon Oct 12 11:20:15 2020 +0900
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2003, 2019, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2003, 2020, Oracle and/or its affiliates. All rights reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
@@ -420,6 +420,7 @@
         //---------------------------------------------------------------------
         tryCatch("%#b", FormatFlagsConversionMismatchException.class);
         tryCatch("%-b", MissingFormatWidthException.class);
+        tryCatch("%0$b", MissingFormatArgumentException.class);
         // correct or side-effect of implementation?
         tryCatch("%.b", UnknownFormatConversionException.class);
         tryCatch("%,b", FormatFlagsConversionMismatchException.class);
@@ -467,6 +468,7 @@
         tryCatch("%(c", FormatFlagsConversionMismatchException.class);
         tryCatch("%$c", UnknownFormatConversionException.class);
         tryCatch("%.2c", IllegalFormatPrecisionException.class);
+        tryCatch("%0$c", MissingFormatArgumentException.class);
 
         //---------------------------------------------------------------------
         // %s
@@ -494,6 +496,7 @@
         tryCatch("%#s", FormatFlagsConversionMismatchException.class, 0.5f);
         tryCatch("%#s", FormatFlagsConversionMismatchException.class, "hello");
         tryCatch("%#s", FormatFlagsConversionMismatchException.class, null);
+        tryCatch("%0$s", MissingFormatArgumentException.class);
 
         //---------------------------------------------------------------------
         // %h
@@ -862,6 +865,9 @@
 
 
 
+
+
+
         //---------------------------------------------------------------------
         // %s - BigDecimal
         //---------------------------------------------------------------------
@@ -1679,6 +1685,7 @@
         tryCatch("%.5tB", IllegalFormatPrecisionException.class);
         tryCatch("%#tB", FormatFlagsConversionMismatchException.class);
         tryCatch("%-tB", MissingFormatWidthException.class);
+        tryCatch("%0$t", MissingFormatArgumentException.class);
 
 
 
diff -r bdc20ee1a68d test/jdk/java/util/Formatter/BasicBigInteger.java
--- a/test/jdk/java/util/Formatter/BasicBigInteger.java	Fri Sep 04 23:51:26 2020 -0400
+++ b/test/jdk/java/util/Formatter/BasicBigInteger.java	Mon Oct 12 11:20:15 2020 +0900
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2003, 2019, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2003, 2020, Oracle and/or its affiliates. All rights reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
@@ -420,6 +420,7 @@
         //---------------------------------------------------------------------
         tryCatch("%#b", FormatFlagsConversionMismatchException.class);
         tryCatch("%-b", MissingFormatWidthException.class);
+        tryCatch("%0$b", MissingFormatArgumentException.class);
         // correct or side-effect of implementation?
         tryCatch("%.b", UnknownFormatConversionException.class);
         tryCatch("%,b", FormatFlagsConversionMismatchException.class);
@@ -467,6 +468,7 @@
         tryCatch("%(c", FormatFlagsConversionMismatchException.class);
         tryCatch("%$c", UnknownFormatConversionException.class);
         tryCatch("%.2c", IllegalFormatPrecisionException.class);
+        tryCatch("%0$c", MissingFormatArgumentException.class);
 
         //---------------------------------------------------------------------
         // %s
@@ -494,6 +496,7 @@
         tryCatch("%#s", FormatFlagsConversionMismatchException.class, 0.5f);
         tryCatch("%#s", FormatFlagsConversionMismatchException.class, "hello");
         tryCatch("%#s", FormatFlagsConversionMismatchException.class, null);
+        tryCatch("%0$s", MissingFormatArgumentException.class);
 
         //---------------------------------------------------------------------
         // %h
@@ -777,6 +780,9 @@
 
 
 
+
+
+
         //---------------------------------------------------------------------
         // BigInteger - errors
         //---------------------------------------------------------------------
@@ -1679,6 +1685,7 @@
         tryCatch("%.5tB", IllegalFormatPrecisionException.class);
         tryCatch("%#tB", FormatFlagsConversionMismatchException.class);
         tryCatch("%-tB", MissingFormatWidthException.class);
+        tryCatch("%0$t", MissingFormatArgumentException.class);
 
 
 
diff -r bdc20ee1a68d test/jdk/java/util/Formatter/BasicBoolean.java
--- a/test/jdk/java/util/Formatter/BasicBoolean.java	Fri Sep 04 23:51:26 2020 -0400
+++ b/test/jdk/java/util/Formatter/BasicBoolean.java	Mon Oct 12 11:20:15 2020 +0900
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2003, 2016, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2003, 2020, Oracle and/or its affiliates. All rights reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
@@ -420,6 +420,7 @@
         //---------------------------------------------------------------------
         tryCatch("%#b", FormatFlagsConversionMismatchException.class);
         tryCatch("%-b", MissingFormatWidthException.class);
+        tryCatch("%0$b", MissingFormatArgumentException.class);
         // correct or side-effect of implementation?
         tryCatch("%.b", UnknownFormatConversionException.class);
         tryCatch("%,b", FormatFlagsConversionMismatchException.class);
@@ -467,6 +468,7 @@
         tryCatch("%(c", FormatFlagsConversionMismatchException.class);
         tryCatch("%$c", UnknownFormatConversionException.class);
         tryCatch("%.2c", IllegalFormatPrecisionException.class);
+        tryCatch("%0$c", MissingFormatArgumentException.class);
 
         //---------------------------------------------------------------------
         // %s
@@ -494,6 +496,7 @@
         tryCatch("%#s", FormatFlagsConversionMismatchException.class, 0.5f);
         tryCatch("%#s", FormatFlagsConversionMismatchException.class, "hello");
         tryCatch("%#s", FormatFlagsConversionMismatchException.class, null);
+        tryCatch("%0$s", MissingFormatArgumentException.class);
 
         //---------------------------------------------------------------------
         // %h
@@ -1661,6 +1664,9 @@
 
 
 
+
+
+
         //---------------------------------------------------------------------
         // %t
         //
@@ -1679,6 +1685,7 @@
         tryCatch("%.5tB", IllegalFormatPrecisionException.class);
         tryCatch("%#tB", FormatFlagsConversionMismatchException.class);
         tryCatch("%-tB", MissingFormatWidthException.class);
+        tryCatch("%0$t", MissingFormatArgumentException.class);
 
 
 
diff -r bdc20ee1a68d test/jdk/java/util/Formatter/BasicBooleanObject.java
--- a/test/jdk/java/util/Formatter/BasicBooleanObject.java	Fri Sep 04 23:51:26 2020 -0400
+++ b/test/jdk/java/util/Formatter/BasicBooleanObject.java	Mon Oct 12 11:20:15 2020 +0900
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2003, 2016, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2003, 2020, Oracle and/or its affiliates. All rights reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
@@ -420,6 +420,7 @@
         //---------------------------------------------------------------------
         tryCatch("%#b", FormatFlagsConversionMismatchException.class);
         tryCatch("%-b", MissingFormatWidthException.class);
+        tryCatch("%0$b", MissingFormatArgumentException.class);
         // correct or side-effect of implementation?
         tryCatch("%.b", UnknownFormatConversionException.class);
         tryCatch("%,b", FormatFlagsConversionMismatchException.class);
@@ -467,6 +468,7 @@
         tryCatch("%(c", FormatFlagsConversionMismatchException.class);
         tryCatch("%$c", UnknownFormatConversionException.class);
         tryCatch("%.2c", IllegalFormatPrecisionException.class);
+        tryCatch("%0$c", MissingFormatArgumentException.class);
 
         //---------------------------------------------------------------------
         // %s
@@ -494,6 +496,7 @@
         tryCatch("%#s", FormatFlagsConversionMismatchException.class, 0.5f);
         tryCatch("%#s", FormatFlagsConversionMismatchException.class, "hello");
         tryCatch("%#s", FormatFlagsConversionMismatchException.class, null);
+        tryCatch("%0$s", MissingFormatArgumentException.class);
 
         //---------------------------------------------------------------------
         // %h
@@ -1661,6 +1664,9 @@
 
 
 
+
+
+
         //---------------------------------------------------------------------
         // %t
         //
@@ -1679,6 +1685,7 @@
         tryCatch("%.5tB", IllegalFormatPrecisionException.class);
         tryCatch("%#tB", FormatFlagsConversionMismatchException.class);
         tryCatch("%-tB", MissingFormatWidthException.class);
+        tryCatch("%0$t", MissingFormatArgumentException.class);
 
 
 
diff -r bdc20ee1a68d test/jdk/java/util/Formatter/BasicByte.java
--- a/test/jdk/java/util/Formatter/BasicByte.java	Fri Sep 04 23:51:26 2020 -0400
+++ b/test/jdk/java/util/Formatter/BasicByte.java	Mon Oct 12 11:20:15 2020 +0900
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2003, 2016, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2003, 2020, Oracle and/or its affiliates. All rights reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
@@ -420,6 +420,7 @@
         //---------------------------------------------------------------------
         tryCatch("%#b", FormatFlagsConversionMismatchException.class);
         tryCatch("%-b", MissingFormatWidthException.class);
+        tryCatch("%0$b", MissingFormatArgumentException.class);
         // correct or side-effect of implementation?
         tryCatch("%.b", UnknownFormatConversionException.class);
         tryCatch("%,b", FormatFlagsConversionMismatchException.class);
@@ -467,6 +468,7 @@
         tryCatch("%(c", FormatFlagsConversionMismatchException.class);
         tryCatch("%$c", UnknownFormatConversionException.class);
         tryCatch("%.2c", IllegalFormatPrecisionException.class);
+        tryCatch("%0$c", MissingFormatArgumentException.class);
 
         //---------------------------------------------------------------------
         // %s
@@ -494,6 +496,7 @@
         tryCatch("%#s", FormatFlagsConversionMismatchException.class, 0.5f);
         tryCatch("%#s", FormatFlagsConversionMismatchException.class, "hello");
         tryCatch("%#s", FormatFlagsConversionMismatchException.class, null);
+        tryCatch("%0$s", MissingFormatArgumentException.class);
 
         //---------------------------------------------------------------------
         // %h
@@ -628,6 +631,7 @@
         tryCatch("%0d", MissingFormatWidthException.class);
         tryCatch("%-d", MissingFormatWidthException.class);
         tryCatch("%7.3d", IllegalFormatPrecisionException.class);
+        tryCatch("%0$d", MissingFormatArgumentException.class);
 
         //---------------------------------------------------------------------
         // %o
@@ -696,6 +700,7 @@
         tryCatch("%-o", MissingFormatWidthException.class);
         tryCatch("%,o", FormatFlagsConversionMismatchException.class);
         tryCatch("%O", UnknownFormatConversionException.class);
+        tryCatch("%0$o", MissingFormatArgumentException.class);
 
         //---------------------------------------------------------------------
         // %x
@@ -773,6 +778,7 @@
         tryCatch("%,x", FormatFlagsConversionMismatchException.class);
         tryCatch("%0x", MissingFormatWidthException.class);
         tryCatch("%-x", MissingFormatWidthException.class);
+        tryCatch("%0$x", MissingFormatArgumentException.class);
 
 
 
@@ -1679,6 +1685,7 @@
         tryCatch("%.5tB", IllegalFormatPrecisionException.class);
         tryCatch("%#tB", FormatFlagsConversionMismatchException.class);
         tryCatch("%-tB", MissingFormatWidthException.class);
+        tryCatch("%0$t", MissingFormatArgumentException.class);
 
 
 
diff -r bdc20ee1a68d test/jdk/java/util/Formatter/BasicByteObject.java
--- a/test/jdk/java/util/Formatter/BasicByteObject.java	Fri Sep 04 23:51:26 2020 -0400
+++ b/test/jdk/java/util/Formatter/BasicByteObject.java	Mon Oct 12 11:20:15 2020 +0900
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2003, 2016, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2003, 2020, Oracle and/or its affiliates. All rights reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
@@ -420,6 +420,7 @@
         //---------------------------------------------------------------------
         tryCatch("%#b", FormatFlagsConversionMismatchException.class);
         tryCatch("%-b", MissingFormatWidthException.class);
+        tryCatch("%0$b", MissingFormatArgumentException.class);
         // correct or side-effect of implementation?
         tryCatch("%.b", UnknownFormatConversionException.class);
         tryCatch("%,b", FormatFlagsConversionMismatchException.class);
@@ -467,6 +468,7 @@
         tryCatch("%(c", FormatFlagsConversionMismatchException.class);
         tryCatch("%$c", UnknownFormatConversionException.class);
         tryCatch("%.2c", IllegalFormatPrecisionException.class);
+        tryCatch("%0$c", MissingFormatArgumentException.class);
 
         //---------------------------------------------------------------------
         // %s
@@ -494,6 +496,7 @@
         tryCatch("%#s", FormatFlagsConversionMismatchException.class, 0.5f);
         tryCatch("%#s", FormatFlagsConversionMismatchException.class, "hello");
         tryCatch("%#s", FormatFlagsConversionMismatchException.class, null);
+        tryCatch("%0$s", MissingFormatArgumentException.class);
 
         //---------------------------------------------------------------------
         // %h
@@ -628,6 +631,7 @@
         tryCatch("%0d", MissingFormatWidthException.class);
         tryCatch("%-d", MissingFormatWidthException.class);
         tryCatch("%7.3d", IllegalFormatPrecisionException.class);
+        tryCatch("%0$d", MissingFormatArgumentException.class);
 
         //---------------------------------------------------------------------
         // %o
@@ -696,6 +700,7 @@
         tryCatch("%-o", MissingFormatWidthException.class);
         tryCatch("%,o", FormatFlagsConversionMismatchException.class);
         tryCatch("%O", UnknownFormatConversionException.class);
+        tryCatch("%0$o", MissingFormatArgumentException.class);
 
         //---------------------------------------------------------------------
         // %x
@@ -773,6 +778,7 @@
         tryCatch("%,x", FormatFlagsConversionMismatchException.class);
         tryCatch("%0x", MissingFormatWidthException.class);
         tryCatch("%-x", MissingFormatWidthException.class);
+        tryCatch("%0$x", MissingFormatArgumentException.class);
 
 
 
@@ -1679,6 +1685,7 @@
         tryCatch("%.5tB", IllegalFormatPrecisionException.class);
         tryCatch("%#tB", FormatFlagsConversionMismatchException.class);
         tryCatch("%-tB", MissingFormatWidthException.class);
+        tryCatch("%0$t", MissingFormatArgumentException.class);
 
 
 
diff -r bdc20ee1a68d test/jdk/java/util/Formatter/BasicChar.java
--- a/test/jdk/java/util/Formatter/BasicChar.java	Fri Sep 04 23:51:26 2020 -0400
+++ b/test/jdk/java/util/Formatter/BasicChar.java	Mon Oct 12 11:20:15 2020 +0900
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2003, 2016, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2003, 2020, Oracle and/or its affiliates. All rights reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
@@ -420,6 +420,7 @@
         //---------------------------------------------------------------------
         tryCatch("%#b", FormatFlagsConversionMismatchException.class);
         tryCatch("%-b", MissingFormatWidthException.class);
+        tryCatch("%0$b", MissingFormatArgumentException.class);
         // correct or side-effect of implementation?
         tryCatch("%.b", UnknownFormatConversionException.class);
         tryCatch("%,b", FormatFlagsConversionMismatchException.class);
@@ -467,6 +468,7 @@
         tryCatch("%(c", FormatFlagsConversionMismatchException.class);
         tryCatch("%$c", UnknownFormatConversionException.class);
         tryCatch("%.2c", IllegalFormatPrecisionException.class);
+        tryCatch("%0$c", MissingFormatArgumentException.class);
 
         //---------------------------------------------------------------------
         // %s
@@ -494,6 +496,7 @@
         tryCatch("%#s", FormatFlagsConversionMismatchException.class, 0.5f);
         tryCatch("%#s", FormatFlagsConversionMismatchException.class, "hello");
         tryCatch("%#s", FormatFlagsConversionMismatchException.class, null);
+        tryCatch("%0$s", MissingFormatArgumentException.class);
 
         //---------------------------------------------------------------------
         // %h
@@ -1661,6 +1664,9 @@
 
 
 
+
+
+
         //---------------------------------------------------------------------
         // %t
         //
@@ -1679,6 +1685,7 @@
         tryCatch("%.5tB", IllegalFormatPrecisionException.class);
         tryCatch("%#tB", FormatFlagsConversionMismatchException.class);
         tryCatch("%-tB", MissingFormatWidthException.class);
+        tryCatch("%0$t", MissingFormatArgumentException.class);
 
 
 
diff -r bdc20ee1a68d test/jdk/java/util/Formatter/BasicCharObject.java
--- a/test/jdk/java/util/Formatter/BasicCharObject.java	Fri Sep 04 23:51:26 2020 -0400
+++ b/test/jdk/java/util/Formatter/BasicCharObject.java	Mon Oct 12 11:20:15 2020 +0900
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2003, 2016, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2003, 2020, Oracle and/or its affiliates. All rights reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
@@ -420,6 +420,7 @@
         //---------------------------------------------------------------------
         tryCatch("%#b", FormatFlagsConversionMismatchException.class);
         tryCatch("%-b", MissingFormatWidthException.class);
+        tryCatch("%0$b", MissingFormatArgumentException.class);
         // correct or side-effect of implementation?
         tryCatch("%.b", UnknownFormatConversionException.class);
         tryCatch("%,b", FormatFlagsConversionMismatchException.class);
@@ -467,6 +468,7 @@
         tryCatch("%(c", FormatFlagsConversionMismatchException.class);
         tryCatch("%$c", UnknownFormatConversionException.class);
         tryCatch("%.2c", IllegalFormatPrecisionException.class);
+        tryCatch("%0$c", MissingFormatArgumentException.class);
 
         //---------------------------------------------------------------------
         // %s
@@ -494,6 +496,7 @@
         tryCatch("%#s", FormatFlagsConversionMismatchException.class, 0.5f);
         tryCatch("%#s", FormatFlagsConversionMismatchException.class, "hello");
         tryCatch("%#s", FormatFlagsConversionMismatchException.class, null);
+        tryCatch("%0$s", MissingFormatArgumentException.class);
 
         //---------------------------------------------------------------------
         // %h
@@ -1661,6 +1664,9 @@
 
 
 
+
+
+
         //---------------------------------------------------------------------
         // %t
         //
@@ -1679,6 +1685,7 @@
         tryCatch("%.5tB", IllegalFormatPrecisionException.class);
         tryCatch("%#tB", FormatFlagsConversionMismatchException.class);
         tryCatch("%-tB", MissingFormatWidthException.class);
+        tryCatch("%0$t", MissingFormatArgumentException.class);
 
 
 
diff -r bdc20ee1a68d test/jdk/java/util/Formatter/BasicDateTime.java
--- a/test/jdk/java/util/Formatter/BasicDateTime.java	Fri Sep 04 23:51:26 2020 -0400
+++ b/test/jdk/java/util/Formatter/BasicDateTime.java	Mon Oct 12 11:20:15 2020 +0900
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2003, 2016, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2003, 2020, Oracle and/or its affiliates. All rights reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
@@ -420,6 +420,7 @@
         //---------------------------------------------------------------------
         tryCatch("%#b", FormatFlagsConversionMismatchException.class);
         tryCatch("%-b", MissingFormatWidthException.class);
+        tryCatch("%0$b", MissingFormatArgumentException.class);
         // correct or side-effect of implementation?
         tryCatch("%.b", UnknownFormatConversionException.class);
         tryCatch("%,b", FormatFlagsConversionMismatchException.class);
@@ -467,6 +468,7 @@
         tryCatch("%(c", FormatFlagsConversionMismatchException.class);
         tryCatch("%$c", UnknownFormatConversionException.class);
         tryCatch("%.2c", IllegalFormatPrecisionException.class);
+        tryCatch("%0$c", MissingFormatArgumentException.class);
 
         //---------------------------------------------------------------------
         // %s
@@ -494,6 +496,7 @@
         tryCatch("%#s", FormatFlagsConversionMismatchException.class, 0.5f);
         tryCatch("%#s", FormatFlagsConversionMismatchException.class, "hello");
         tryCatch("%#s", FormatFlagsConversionMismatchException.class, null);
+        tryCatch("%0$s", MissingFormatArgumentException.class);
 
         //---------------------------------------------------------------------
         // %h
@@ -1661,6 +1664,9 @@
 
 
 
+
+
+
         //---------------------------------------------------------------------
         // %t
         //
@@ -1679,6 +1685,7 @@
         tryCatch("%.5tB", IllegalFormatPrecisionException.class);
         tryCatch("%#tB", FormatFlagsConversionMismatchException.class);
         tryCatch("%-tB", MissingFormatWidthException.class);
+        tryCatch("%0$t", MissingFormatArgumentException.class);
 
 
         //---------------------------------------------------------------------
diff -r bdc20ee1a68d test/jdk/java/util/Formatter/BasicDouble.java
--- a/test/jdk/java/util/Formatter/BasicDouble.java	Fri Sep 04 23:51:26 2020 -0400
+++ b/test/jdk/java/util/Formatter/BasicDouble.java	Mon Oct 12 11:20:15 2020 +0900
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2003, 2019, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2003, 2020, Oracle and/or its affiliates. All rights reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
@@ -420,6 +420,7 @@
         //---------------------------------------------------------------------
         tryCatch("%#b", FormatFlagsConversionMismatchException.class);
         tryCatch("%-b", MissingFormatWidthException.class);
+        tryCatch("%0$b", MissingFormatArgumentException.class);
         // correct or side-effect of implementation?
         tryCatch("%.b", UnknownFormatConversionException.class);
         tryCatch("%,b", FormatFlagsConversionMismatchException.class);
@@ -467,6 +468,7 @@
         tryCatch("%(c", FormatFlagsConversionMismatchException.class);
         tryCatch("%$c", UnknownFormatConversionException.class);
         tryCatch("%.2c", IllegalFormatPrecisionException.class);
+        tryCatch("%0$c", MissingFormatArgumentException.class);
 
         //---------------------------------------------------------------------
         // %s
@@ -494,6 +496,7 @@
         tryCatch("%#s", FormatFlagsConversionMismatchException.class, 0.5f);
         tryCatch("%#s", FormatFlagsConversionMismatchException.class, "hello");
         tryCatch("%#s", FormatFlagsConversionMismatchException.class, null);
+        tryCatch("%0$s", MissingFormatArgumentException.class);
 
         //---------------------------------------------------------------------
         // %h
@@ -893,6 +896,9 @@
 
 
 
+
+
+
         //---------------------------------------------------------------------
         // %s - double
         //---------------------------------------------------------------------
@@ -1679,6 +1685,7 @@
         tryCatch("%.5tB", IllegalFormatPrecisionException.class);
         tryCatch("%#tB", FormatFlagsConversionMismatchException.class);
         tryCatch("%-tB", MissingFormatWidthException.class);
+        tryCatch("%0$t", MissingFormatArgumentException.class);
 
 
 
diff -r bdc20ee1a68d test/jdk/java/util/Formatter/BasicDoubleObject.java
--- a/test/jdk/java/util/Formatter/BasicDoubleObject.java	Fri Sep 04 23:51:26 2020 -0400
+++ b/test/jdk/java/util/Formatter/BasicDoubleObject.java	Mon Oct 12 11:20:15 2020 +0900
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2003, 2019, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2003, 2020, Oracle and/or its affiliates. All rights reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
@@ -420,6 +420,7 @@
         //---------------------------------------------------------------------
         tryCatch("%#b", FormatFlagsConversionMismatchException.class);
         tryCatch("%-b", MissingFormatWidthException.class);
+        tryCatch("%0$b", MissingFormatArgumentException.class);
         // correct or side-effect of implementation?
         tryCatch("%.b", UnknownFormatConversionException.class);
         tryCatch("%,b", FormatFlagsConversionMismatchException.class);
@@ -467,6 +468,7 @@
         tryCatch("%(c", FormatFlagsConversionMismatchException.class);
         tryCatch("%$c", UnknownFormatConversionException.class);
         tryCatch("%.2c", IllegalFormatPrecisionException.class);
+        tryCatch("%0$c", MissingFormatArgumentException.class);
 
         //---------------------------------------------------------------------
         // %s
@@ -494,6 +496,7 @@
         tryCatch("%#s", FormatFlagsConversionMismatchException.class, 0.5f);
         tryCatch("%#s", FormatFlagsConversionMismatchException.class, "hello");
         tryCatch("%#s", FormatFlagsConversionMismatchException.class, null);
+        tryCatch("%0$s", MissingFormatArgumentException.class);
 
         //---------------------------------------------------------------------
         // %h
@@ -903,6 +906,9 @@
 
 
 
+
+
+
         //---------------------------------------------------------------------
         // %s - Double
         //---------------------------------------------------------------------
@@ -1679,6 +1685,7 @@
         tryCatch("%.5tB", IllegalFormatPrecisionException.class);
         tryCatch("%#tB", FormatFlagsConversionMismatchException.class);
         tryCatch("%-tB", MissingFormatWidthException.class);
+        tryCatch("%0$t", MissingFormatArgumentException.class);
 
 
 
diff -r bdc20ee1a68d test/jdk/java/util/Formatter/BasicFloat.java
--- a/test/jdk/java/util/Formatter/BasicFloat.java	Fri Sep 04 23:51:26 2020 -0400
+++ b/test/jdk/java/util/Formatter/BasicFloat.java	Mon Oct 12 11:20:15 2020 +0900
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2003, 2019, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2003, 2020, Oracle and/or its affiliates. All rights reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
@@ -420,6 +420,7 @@
         //---------------------------------------------------------------------
         tryCatch("%#b", FormatFlagsConversionMismatchException.class);
         tryCatch("%-b", MissingFormatWidthException.class);
+        tryCatch("%0$b", MissingFormatArgumentException.class);
         // correct or side-effect of implementation?
         tryCatch("%.b", UnknownFormatConversionException.class);
         tryCatch("%,b", FormatFlagsConversionMismatchException.class);
@@ -467,6 +468,7 @@
         tryCatch("%(c", FormatFlagsConversionMismatchException.class);
         tryCatch("%$c", UnknownFormatConversionException.class);
         tryCatch("%.2c", IllegalFormatPrecisionException.class);
+        tryCatch("%0$c", MissingFormatArgumentException.class);
 
         //---------------------------------------------------------------------
         // %s
@@ -494,6 +496,7 @@
         tryCatch("%#s", FormatFlagsConversionMismatchException.class, 0.5f);
         tryCatch("%#s", FormatFlagsConversionMismatchException.class, "hello");
         tryCatch("%#s", FormatFlagsConversionMismatchException.class, null);
+        tryCatch("%0$s", MissingFormatArgumentException.class);
 
         //---------------------------------------------------------------------
         // %h
@@ -873,6 +876,9 @@
 
 
 
+
+
+
         //---------------------------------------------------------------------
         // %s - float
         //---------------------------------------------------------------------
@@ -1679,6 +1685,7 @@
         tryCatch("%.5tB", IllegalFormatPrecisionException.class);
         tryCatch("%#tB", FormatFlagsConversionMismatchException.class);
         tryCatch("%-tB", MissingFormatWidthException.class);
+        tryCatch("%0$t", MissingFormatArgumentException.class);
 
 
 
diff -r bdc20ee1a68d test/jdk/java/util/Formatter/BasicFloatObject.java
--- a/test/jdk/java/util/Formatter/BasicFloatObject.java	Fri Sep 04 23:51:26 2020 -0400
+++ b/test/jdk/java/util/Formatter/BasicFloatObject.java	Mon Oct 12 11:20:15 2020 +0900
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2003, 2016, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2003, 2020, Oracle and/or its affiliates. All rights reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
@@ -420,6 +420,7 @@
         //---------------------------------------------------------------------
         tryCatch("%#b", FormatFlagsConversionMismatchException.class);
         tryCatch("%-b", MissingFormatWidthException.class);
+        tryCatch("%0$b", MissingFormatArgumentException.class);
         // correct or side-effect of implementation?
         tryCatch("%.b", UnknownFormatConversionException.class);
         tryCatch("%,b", FormatFlagsConversionMismatchException.class);
@@ -467,6 +468,7 @@
         tryCatch("%(c", FormatFlagsConversionMismatchException.class);
         tryCatch("%$c", UnknownFormatConversionException.class);
         tryCatch("%.2c", IllegalFormatPrecisionException.class);
+        tryCatch("%0$c", MissingFormatArgumentException.class);
 
         //---------------------------------------------------------------------
         // %s
@@ -494,6 +496,7 @@
         tryCatch("%#s", FormatFlagsConversionMismatchException.class, 0.5f);
         tryCatch("%#s", FormatFlagsConversionMismatchException.class, "hello");
         tryCatch("%#s", FormatFlagsConversionMismatchException.class, null);
+        tryCatch("%0$s", MissingFormatArgumentException.class);
 
         //---------------------------------------------------------------------
         // %h
@@ -883,6 +886,9 @@
 
 
 
+
+
+
         //---------------------------------------------------------------------
         // %s - Float
         //---------------------------------------------------------------------
@@ -1679,6 +1685,7 @@
         tryCatch("%.5tB", IllegalFormatPrecisionException.class);
         tryCatch("%#tB", FormatFlagsConversionMismatchException.class);
         tryCatch("%-tB", MissingFormatWidthException.class);
+        tryCatch("%0$t", MissingFormatArgumentException.class);
 
 
 
diff -r bdc20ee1a68d test/jdk/java/util/Formatter/BasicInt.java
--- a/test/jdk/java/util/Formatter/BasicInt.java	Fri Sep 04 23:51:26 2020 -0400
+++ b/test/jdk/java/util/Formatter/BasicInt.java	Mon Oct 12 11:20:15 2020 +0900
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2003, 2019, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2003, 2020, Oracle and/or its affiliates. All rights reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
@@ -420,6 +420,7 @@
         //---------------------------------------------------------------------
         tryCatch("%#b", FormatFlagsConversionMismatchException.class);
         tryCatch("%-b", MissingFormatWidthException.class);
+        tryCatch("%0$b", MissingFormatArgumentException.class);
         // correct or side-effect of implementation?
         tryCatch("%.b", UnknownFormatConversionException.class);
         tryCatch("%,b", FormatFlagsConversionMismatchException.class);
@@ -467,6 +468,7 @@
         tryCatch("%(c", FormatFlagsConversionMismatchException.class);
         tryCatch("%$c", UnknownFormatConversionException.class);
         tryCatch("%.2c", IllegalFormatPrecisionException.class);
+        tryCatch("%0$c", MissingFormatArgumentException.class);
 
         //---------------------------------------------------------------------
         // %s
@@ -494,6 +496,7 @@
         tryCatch("%#s", FormatFlagsConversionMismatchException.class, 0.5f);
         tryCatch("%#s", FormatFlagsConversionMismatchException.class, "hello");
         tryCatch("%#s", FormatFlagsConversionMismatchException.class, null);
+        tryCatch("%0$s", MissingFormatArgumentException.class);
 
         //---------------------------------------------------------------------
         // %h
@@ -628,6 +631,7 @@
         tryCatch("%0d", MissingFormatWidthException.class);
         tryCatch("%-d", MissingFormatWidthException.class);
         tryCatch("%7.3d", IllegalFormatPrecisionException.class);
+        tryCatch("%0$d", MissingFormatArgumentException.class);
 
         //---------------------------------------------------------------------
         // %o
@@ -696,6 +700,7 @@
         tryCatch("%-o", MissingFormatWidthException.class);
         tryCatch("%,o", FormatFlagsConversionMismatchException.class);
         tryCatch("%O", UnknownFormatConversionException.class);
+        tryCatch("%0$o", MissingFormatArgumentException.class);
 
         //---------------------------------------------------------------------
         // %x
@@ -773,6 +778,7 @@
         tryCatch("%,x", FormatFlagsConversionMismatchException.class);
         tryCatch("%0x", MissingFormatWidthException.class);
         tryCatch("%-x", MissingFormatWidthException.class);
+        tryCatch("%0$x", MissingFormatArgumentException.class);
 
 
 
@@ -1679,6 +1685,7 @@
         tryCatch("%.5tB", IllegalFormatPrecisionException.class);
         tryCatch("%#tB", FormatFlagsConversionMismatchException.class);
         tryCatch("%-tB", MissingFormatWidthException.class);
+        tryCatch("%0$t", MissingFormatArgumentException.class);
 
 
 
diff -r bdc20ee1a68d test/jdk/java/util/Formatter/BasicIntObject.java
--- a/test/jdk/java/util/Formatter/BasicIntObject.java	Fri Sep 04 23:51:26 2020 -0400
+++ b/test/jdk/java/util/Formatter/BasicIntObject.java	Mon Oct 12 11:20:15 2020 +0900
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2003, 2016, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2003, 2020, Oracle and/or its affiliates. All rights reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
@@ -420,6 +420,7 @@
         //---------------------------------------------------------------------
         tryCatch("%#b", FormatFlagsConversionMismatchException.class);
         tryCatch("%-b", MissingFormatWidthException.class);
+        tryCatch("%0$b", MissingFormatArgumentException.class);
         // correct or side-effect of implementation?
         tryCatch("%.b", UnknownFormatConversionException.class);
         tryCatch("%,b", FormatFlagsConversionMismatchException.class);
@@ -467,6 +468,7 @@
         tryCatch("%(c", FormatFlagsConversionMismatchException.class);
         tryCatch("%$c", UnknownFormatConversionException.class);
         tryCatch("%.2c", IllegalFormatPrecisionException.class);
+        tryCatch("%0$c", MissingFormatArgumentException.class);
 
         //---------------------------------------------------------------------
         // %s
@@ -494,6 +496,7 @@
         tryCatch("%#s", FormatFlagsConversionMismatchException.class, 0.5f);
         tryCatch("%#s", FormatFlagsConversionMismatchException.class, "hello");
         tryCatch("%#s", FormatFlagsConversionMismatchException.class, null);
+        tryCatch("%0$s", MissingFormatArgumentException.class);
 
         //---------------------------------------------------------------------
         // %h
@@ -628,6 +631,7 @@
         tryCatch("%0d", MissingFormatWidthException.class);
         tryCatch("%-d", MissingFormatWidthException.class);
         tryCatch("%7.3d", IllegalFormatPrecisionException.class);
+        tryCatch("%0$d", MissingFormatArgumentException.class);
 
         //---------------------------------------------------------------------
         // %o
@@ -696,6 +700,7 @@
         tryCatch("%-o", MissingFormatWidthException.class);
         tryCatch("%,o", FormatFlagsConversionMismatchException.class);
         tryCatch("%O", UnknownFormatConversionException.class);
+        tryCatch("%0$o", MissingFormatArgumentException.class);
 
         //---------------------------------------------------------------------
         // %x
@@ -773,6 +778,7 @@
         tryCatch("%,x", FormatFlagsConversionMismatchException.class);
         tryCatch("%0x", MissingFormatWidthException.class);
         tryCatch("%-x", MissingFormatWidthException.class);
+        tryCatch("%0$x", MissingFormatArgumentException.class);
 
 
 
@@ -1679,6 +1685,7 @@
         tryCatch("%.5tB", IllegalFormatPrecisionException.class);
         tryCatch("%#tB", FormatFlagsConversionMismatchException.class);
         tryCatch("%-tB", MissingFormatWidthException.class);
+        tryCatch("%0$t", MissingFormatArgumentException.class);
 
 
 
diff -r bdc20ee1a68d test/jdk/java/util/Formatter/BasicLong.java
--- a/test/jdk/java/util/Formatter/BasicLong.java	Fri Sep 04 23:51:26 2020 -0400
+++ b/test/jdk/java/util/Formatter/BasicLong.java	Mon Oct 12 11:20:15 2020 +0900
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2003, 2019, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2003, 2020, Oracle and/or its affiliates. All rights reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
@@ -420,6 +420,7 @@
         //---------------------------------------------------------------------
         tryCatch("%#b", FormatFlagsConversionMismatchException.class);
         tryCatch("%-b", MissingFormatWidthException.class);
+        tryCatch("%0$b", MissingFormatArgumentException.class);
         // correct or side-effect of implementation?
         tryCatch("%.b", UnknownFormatConversionException.class);
         tryCatch("%,b", FormatFlagsConversionMismatchException.class);
@@ -467,6 +468,7 @@
         tryCatch("%(c", FormatFlagsConversionMismatchException.class);
         tryCatch("%$c", UnknownFormatConversionException.class);
         tryCatch("%.2c", IllegalFormatPrecisionException.class);
+        tryCatch("%0$c", MissingFormatArgumentException.class);
 
         //---------------------------------------------------------------------
         // %s
@@ -494,6 +496,7 @@
         tryCatch("%#s", FormatFlagsConversionMismatchException.class, 0.5f);
         tryCatch("%#s", FormatFlagsConversionMismatchException.class, "hello");
         tryCatch("%#s", FormatFlagsConversionMismatchException.class, null);
+        tryCatch("%0$s", MissingFormatArgumentException.class);
 
         //---------------------------------------------------------------------
         // %h
@@ -628,6 +631,7 @@
         tryCatch("%0d", MissingFormatWidthException.class);
         tryCatch("%-d", MissingFormatWidthException.class);
         tryCatch("%7.3d", IllegalFormatPrecisionException.class);
+        tryCatch("%0$d", MissingFormatArgumentException.class);
 
         //---------------------------------------------------------------------
         // %o
@@ -696,6 +700,7 @@
         tryCatch("%-o", MissingFormatWidthException.class);
         tryCatch("%,o", FormatFlagsConversionMismatchException.class);
         tryCatch("%O", UnknownFormatConversionException.class);
+        tryCatch("%0$o", MissingFormatArgumentException.class);
 
         //---------------------------------------------------------------------
         // %x
@@ -773,6 +778,7 @@
         tryCatch("%,x", FormatFlagsConversionMismatchException.class);
         tryCatch("%0x", MissingFormatWidthException.class);
         tryCatch("%-x", MissingFormatWidthException.class);
+        tryCatch("%0$x", MissingFormatArgumentException.class);
 
 
 
@@ -1679,6 +1685,7 @@
         tryCatch("%.5tB", IllegalFormatPrecisionException.class);
         tryCatch("%#tB", FormatFlagsConversionMismatchException.class);
         tryCatch("%-tB", MissingFormatWidthException.class);
+        tryCatch("%0$t", MissingFormatArgumentException.class);
 
 
 
diff -r bdc20ee1a68d test/jdk/java/util/Formatter/BasicLongObject.java
--- a/test/jdk/java/util/Formatter/BasicLongObject.java	Fri Sep 04 23:51:26 2020 -0400
+++ b/test/jdk/java/util/Formatter/BasicLongObject.java	Mon Oct 12 11:20:15 2020 +0900
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2003, 2016, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2003, 2020, Oracle and/or its affiliates. All rights reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
@@ -420,6 +420,7 @@
         //---------------------------------------------------------------------
         tryCatch("%#b", FormatFlagsConversionMismatchException.class);
         tryCatch("%-b", MissingFormatWidthException.class);
+        tryCatch("%0$b", MissingFormatArgumentException.class);
         // correct or side-effect of implementation?
         tryCatch("%.b", UnknownFormatConversionException.class);
         tryCatch("%,b", FormatFlagsConversionMismatchException.class);
@@ -467,6 +468,7 @@
         tryCatch("%(c", FormatFlagsConversionMismatchException.class);
         tryCatch("%$c", UnknownFormatConversionException.class);
         tryCatch("%.2c", IllegalFormatPrecisionException.class);
+        tryCatch("%0$c", MissingFormatArgumentException.class);
 
         //---------------------------------------------------------------------
         // %s
@@ -494,6 +496,7 @@
         tryCatch("%#s", FormatFlagsConversionMismatchException.class, 0.5f);
         tryCatch("%#s", FormatFlagsConversionMismatchException.class, "hello");
         tryCatch("%#s", FormatFlagsConversionMismatchException.class, null);
+        tryCatch("%0$s", MissingFormatArgumentException.class);
 
         //---------------------------------------------------------------------
         // %h
@@ -628,6 +631,7 @@
         tryCatch("%0d", MissingFormatWidthException.class);
         tryCatch("%-d", MissingFormatWidthException.class);
         tryCatch("%7.3d", IllegalFormatPrecisionException.class);
+        tryCatch("%0$d", MissingFormatArgumentException.class);
 
         //---------------------------------------------------------------------
         // %o
@@ -696,6 +700,7 @@
         tryCatch("%-o", MissingFormatWidthException.class);
         tryCatch("%,o", FormatFlagsConversionMismatchException.class);
         tryCatch("%O", UnknownFormatConversionException.class);
+        tryCatch("%0$o", MissingFormatArgumentException.class);
 
         //---------------------------------------------------------------------
         // %x
@@ -773,6 +778,7 @@
         tryCatch("%,x", FormatFlagsConversionMismatchException.class);
         tryCatch("%0x", MissingFormatWidthException.class);
         tryCatch("%-x", MissingFormatWidthException.class);
+        tryCatch("%0$x", MissingFormatArgumentException.class);
 
 
 
@@ -1679,6 +1685,7 @@
         tryCatch("%.5tB", IllegalFormatPrecisionException.class);
         tryCatch("%#tB", FormatFlagsConversionMismatchException.class);
         tryCatch("%-tB", MissingFormatWidthException.class);
+        tryCatch("%0$t", MissingFormatArgumentException.class);
 
 
 
diff -r bdc20ee1a68d test/jdk/java/util/Formatter/BasicShort.java
--- a/test/jdk/java/util/Formatter/BasicShort.java	Fri Sep 04 23:51:26 2020 -0400
+++ b/test/jdk/java/util/Formatter/BasicShort.java	Mon Oct 12 11:20:15 2020 +0900
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2003, 2016, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2003, 2020, Oracle and/or its affiliates. All rights reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
@@ -420,6 +420,7 @@
         //---------------------------------------------------------------------
         tryCatch("%#b", FormatFlagsConversionMismatchException.class);
         tryCatch("%-b", MissingFormatWidthException.class);
+        tryCatch("%0$b", MissingFormatArgumentException.class);
         // correct or side-effect of implementation?
         tryCatch("%.b", UnknownFormatConversionException.class);
         tryCatch("%,b", FormatFlagsConversionMismatchException.class);
@@ -467,6 +468,7 @@
         tryCatch("%(c", FormatFlagsConversionMismatchException.class);
         tryCatch("%$c", UnknownFormatConversionException.class);
         tryCatch("%.2c", IllegalFormatPrecisionException.class);
+        tryCatch("%0$c", MissingFormatArgumentException.class);
 
         //---------------------------------------------------------------------
         // %s
@@ -494,6 +496,7 @@
         tryCatch("%#s", FormatFlagsConversionMismatchException.class, 0.5f);
         tryCatch("%#s", FormatFlagsConversionMismatchException.class, "hello");
         tryCatch("%#s", FormatFlagsConversionMismatchException.class, null);
+        tryCatch("%0$s", MissingFormatArgumentException.class);
 
         //---------------------------------------------------------------------
         // %h
@@ -628,6 +631,7 @@
         tryCatch("%0d", MissingFormatWidthException.class);
         tryCatch("%-d", MissingFormatWidthException.class);
         tryCatch("%7.3d", IllegalFormatPrecisionException.class);
+        tryCatch("%0$d", MissingFormatArgumentException.class);
 
         //---------------------------------------------------------------------
         // %o
@@ -696,6 +700,7 @@
         tryCatch("%-o", MissingFormatWidthException.class);
         tryCatch("%,o", FormatFlagsConversionMismatchException.class);
         tryCatch("%O", UnknownFormatConversionException.class);
+        tryCatch("%0$o", MissingFormatArgumentException.class);
 
         //---------------------------------------------------------------------
         // %x
@@ -773,6 +778,7 @@
         tryCatch("%,x", FormatFlagsConversionMismatchException.class);
         tryCatch("%0x", MissingFormatWidthException.class);
         tryCatch("%-x", MissingFormatWidthException.class);
+        tryCatch("%0$x", MissingFormatArgumentException.class);
 
 
 
@@ -1679,6 +1685,7 @@
         tryCatch("%.5tB", IllegalFormatPrecisionException.class);
         tryCatch("%#tB", FormatFlagsConversionMismatchException.class);
         tryCatch("%-tB", MissingFormatWidthException.class);
+        tryCatch("%0$t", MissingFormatArgumentException.class);
 
 
 
diff -r bdc20ee1a68d test/jdk/java/util/Formatter/BasicShortObject.java
--- a/test/jdk/java/util/Formatter/BasicShortObject.java	Fri Sep 04 23:51:26 2020 -0400
+++ b/test/jdk/java/util/Formatter/BasicShortObject.java	Mon Oct 12 11:20:15 2020 +0900
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2003, 2016, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2003, 2020, Oracle and/or its affiliates. All rights reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
@@ -420,6 +420,7 @@
         //---------------------------------------------------------------------
         tryCatch("%#b", FormatFlagsConversionMismatchException.class);
         tryCatch("%-b", MissingFormatWidthException.class);
+        tryCatch("%0$b", MissingFormatArgumentException.class);
         // correct or side-effect of implementation?
         tryCatch("%.b", UnknownFormatConversionException.class);
         tryCatch("%,b", FormatFlagsConversionMismatchException.class);
@@ -467,6 +468,7 @@
         tryCatch("%(c", FormatFlagsConversionMismatchException.class);
         tryCatch("%$c", UnknownFormatConversionException.class);
         tryCatch("%.2c", IllegalFormatPrecisionException.class);
+        tryCatch("%0$c", MissingFormatArgumentException.class);
 
         //---------------------------------------------------------------------
         // %s
@@ -494,6 +496,7 @@
         tryCatch("%#s", FormatFlagsConversionMismatchException.class, 0.5f);
         tryCatch("%#s", FormatFlagsConversionMismatchException.class, "hello");
         tryCatch("%#s", FormatFlagsConversionMismatchException.class, null);
+        tryCatch("%0$s", MissingFormatArgumentException.class);
 
         //---------------------------------------------------------------------
         // %h
@@ -628,6 +631,7 @@
         tryCatch("%0d", MissingFormatWidthException.class);
         tryCatch("%-d", MissingFormatWidthException.class);
         tryCatch("%7.3d", IllegalFormatPrecisionException.class);
+        tryCatch("%0$d", MissingFormatArgumentException.class);
 
         //---------------------------------------------------------------------
         // %o
@@ -696,6 +700,7 @@
         tryCatch("%-o", MissingFormatWidthException.class);
         tryCatch("%,o", FormatFlagsConversionMismatchException.class);
         tryCatch("%O", UnknownFormatConversionException.class);
+        tryCatch("%0$o", MissingFormatArgumentException.class);
 
         //---------------------------------------------------------------------
         // %x
@@ -773,6 +778,7 @@
         tryCatch("%,x", FormatFlagsConversionMismatchException.class);
         tryCatch("%0x", MissingFormatWidthException.class);
         tryCatch("%-x", MissingFormatWidthException.class);
+        tryCatch("%0$x", MissingFormatArgumentException.class);
 
 
 
@@ -1679,6 +1685,7 @@
         tryCatch("%.5tB", IllegalFormatPrecisionException.class);
         tryCatch("%#tB", FormatFlagsConversionMismatchException.class);
         tryCatch("%-tB", MissingFormatWidthException.class);
+        tryCatch("%0$t", MissingFormatArgumentException.class);


Regards,
Masanori Yano

From smarks at openjdk.java.net  Mon Oct 12 17:25:15 2020
From: smarks at openjdk.java.net (Stuart Marks)
Date: Mon, 12 Oct 2020 17:25:15 GMT
Subject: Integrated: 8254090: Collectors.toUnmodifiableList exposes shared
 secret
In-Reply-To: <8yn1ijJAow2SIaCdRYHBMG2WwH2zrji1A9EYXZZQJHU=.8e9c5af2-8162-48be-8739-92a166c19030@github.com>
References: <8yn1ijJAow2SIaCdRYHBMG2WwH2zrji1A9EYXZZQJHU=.8e9c5af2-8162-48be-8739-92a166c19030@github.com>
Message-ID: <CkH3VLbuGIRtR7ThUHa9HxhcUeu3g3UyX4uVNXLveFg=.2706b48f-606d-4d55-a122-3a3f4f831b01@github.com>

On Thu, 8 Oct 2020 20:52:01 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> Add check for ArrayList.class before passing it to the shared secret.

This pull request has now been integrated.

Changeset: d7128e7d
Author:    Stuart Marks <smarks at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d7128e7d
Stats:     65 lines in 2 files changed: 58 ins; 1 del; 6 mod

8254090: Collectors.toUnmodifiableList exposes shared secret

Co-authored-by: Tagir F. Valeev <tvaleev at openjdk.org>
Reviewed-by: psandoz

-------------

PR: https://git.openjdk.java.net/jdk/pull/569

From tim.bell at oracle.com  Mon Oct 12 17:38:42 2020
From: tim.bell at oracle.com (Tim Bell)
Date: Mon, 12 Oct 2020 10:38:42 -0700
Subject: core-libs-dev email delivery (is broken for external subscribers)
In-Reply-To: <878scdx8b7.fsf@mid.deneb.enyo.de>
References: <878scdx8b7.fsf@mid.deneb.enyo.de>
Message-ID: <1d35ad95-a21d-d0a7-57cf-f5d1f05913d5@oracle.com>

On 2020-10-11 05:21, Florian Weimer wrote:
> We used to have a problem where hotspot-dev mail did not get delivered
> to list subscribers.  Is it possible that a similar issue now affects
> core-libs-dev?  I don't receive mail on two separate mail accounts,
> with completely different infrastructure on my end.

I reproduced this issue with my external mailbox.  My corporate internal 
mailbox receives core-libs-dev messages OK.

This does appear to be a repeat of the earlier issue with hotspot-dev. 
I filed an internal problem report and I will escalate.

Until this issue is resolved, the workaround is to keep an eye on the 
message archive at:

   https://mail.openjdk.java.net/pipermail/core-libs-dev/

Tim

From github.com+51754783+coreyashford at openjdk.java.net  Mon Oct 12 17:55:14 2020
From: github.com+51754783+coreyashford at openjdk.java.net (CoreyAshford)
Date: Mon, 12 Oct 2020 17:55:14 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v4]
In-Reply-To: <HTj0hHy0DzhPqNbzthiCu5OsKGR2lxmwdGd9n63zJO8=.17f53ab3-3f9b-439a-a1a0-eb7c02cbbe99@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <45FtTQB1m6HyZSASY42STMkQffIWlVPibWn9_r00xYs=.daad2653-2571-491f-8dd7-5954fe4ece00@github.com>
 <HTj0hHy0DzhPqNbzthiCu5OsKGR2lxmwdGd9n63zJO8=.17f53ab3-3f9b-439a-a1a0-eb7c02cbbe99@github.com>
Message-ID: <S6Qq1OG_rifAAGJWryN1w0p1aYS0UzxSEEurSDDutl0=.d77a1e18-f9c2-4cea-941f-a866469b5527@github.com>

On Mon, 12 Oct 2020 12:36:19 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> CoreyAshford has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - TestBase64.java: fix comment to correctly reflect actual intrinsic names.
>>    
>>    The intrinsic names that are visible with -XX:+PrintCompilation are encode
>>    and decode, rather than encodeBlock and decodeBlock.
>>  - stubGenerator_ppc.cpp: fix regression caused by change to using loop counter
>>    
>>    My original fix didn't account for the case where sl < block_size.  In the
>>    event sl < block_size, the shifted sl will become zero, so it should
>>    jump to the code that computes how much data was processed - 0 - and return.
>
> src/hotspot/cpu/ppc/stubGenerator_ppc.cpp line 3803:
> 
>> 3801:     // Base64 class will be used to process the last 12 characters.
>> 3802:     __ sub(sl, sl, sp);
>> 3803:     __ subi(sl, sl, 12);
> 
> I think we should subtract 4, now. srawi will round it down below. We have no guarantee that we can subract more than 4
> without getting negative value.

In the original paper this code is based upon, they subtract 12 because of the overwrite issue.  This is discussed in
the preceding code comment as well.  So I think that needs to be retained, but I do need to check for a negative after
the subtract.

According to the `srawi.` specification:

>  CA and CA32 are set to 1 if the low-order 32 bits of (RS) contain a negative number and any 1-bits are shifted out of
>  position 63; otherwise CA and CA32 are set to 0.

Because the `sub` instruction is a 64-bit subtract, all of the upper bits should be 1's if sl is negative after the
subtract, so I think the `srawi.` should catch the negative case if I also check CA after the srawi, via:
   __ srawi_(sl, sl, block_size_shift);
   // if XER CA is set, sl was less than zero.
   __ mcrxrx(CCR2); // moves XER's OV, OV32, CA, CA32 to CCR2's LT, GT, EQ, SO bits, respectively.
   __ beq_predict_not_taken(CCR2, unrolled_loop_exit);
   __ beq_predict_not_taken(CCR0, unrolled_loop_exit);

-------------

PR: https://git.openjdk.java.net/jdk/pull/293

From mcimadamore at openjdk.java.net  Mon Oct 12 17:58:54 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 12 Oct 2020 17:58:54 GMT
Subject: RFR: 8254162: Implementation of Foreign-Memory Access API (Third
 Incubator) [v7]
In-Reply-To: <IngRk57F78UN3yySfo6IABbdwnMogGNdYrykh_3em-c=.b81f7478-015c-45ed-9788-58d7519a2770@github.com>
References: <IngRk57F78UN3yySfo6IABbdwnMogGNdYrykh_3em-c=.b81f7478-015c-45ed-9788-58d7519a2770@github.com>
Message-ID: <Ulx3TYID4US9aXrZc61mwPL7qTG6wsxyXQvSDtXsZ6Q=.fbbc6a7e-3e2d-4887-a3c2-0d77814ce3d4@github.com>

> This patch contains the changes associated with the third incubation round of the foreign memory access API incubation
> (see JEP 393 [1]). This iteration focus on improving the usability of the API in 3 main ways:
> * first, by providing a way to obtain truly *shared* segments, which can be accessed and closed concurrently from
>   multiple threads
> * second, by providing a way to register a memory segment against a `Cleaner`, so as to have some (optional) guarantee
>   that the memory will be deallocated, eventually
> * third, by not requiring users to dive deep into var handles when they first pick up the API; a new `MemoryAccess` class
>   has been added, which defines several useful dereference routines; these are really just thin wrappers around memory
>   access var handles, but they make the barrier of entry for using this API somewhat lower.
> 
> A big conceptual shift that comes with this API refresh is that the role of `MemorySegment` and `MemoryAddress` is not
> the same as it used to be; it used to be the case that a memory address could (sometimes, not always) have a back link
> to the memory segment which originated it; additionally, memory access var handles used `MemoryAddress` as a basic unit
> of dereference.  This has all changed as per this API refresh;  now a `MemoryAddress` is just a dumb carrier which
> wraps a pair of object/long addressing coordinates; `MemorySegment` has become the star of the show, as far as
> dereferencing memory is concerned. You cannot dereference memory if you don't have a segment. This improves usability
> in a number of ways - first, it is a lot easier to wrap native addresses (`long`, essentially) into a `MemoryAddress`;
> secondly, it is crystal clear what a client has to do in order to dereference memory: if a client has a segment, it can
> use that; otherwise, if the client only has an address, it will have to create a segment *unsafely* (this can be done
> by calling `MemoryAddress::asSegmentRestricted`).  A list of the API, implementation and test changes is provided
> below. If  you have any questions, or need more detailed explanations, I (and the  rest of the Panama team) will be
> happy to point at existing discussions,  and/or to provide the feedback required.   A big thank to Erik Osterlund,
> Vladimir Ivanov and David Holmes, without whom the work on shared memory segment would not have been possible; also I'd
> like to thank Paul Sandoz, whose insights on API design have been very helpful in this journey.  Thanks  Maurizio
> Javadoc:   http://cr.openjdk.java.net/~mcimadamore/8254162_v1/javadoc/jdk/incubator/foreign/package-summary.html
> Specdiff:
> 
> http://cr.openjdk.java.net/~mcimadamore/8254162_v1/specdiff/jdk/incubator/foreign/package-summary.html
> 
> CSR:
> 
> https://bugs.openjdk.java.net/browse/JDK-8254163
> 
> 
> 
> ### API Changes
> 
> * `MemorySegment`
>   * drop factory for restricted segment (this has been moved to `MemoryAddress`, see below)
>   * added a no-arg factory for a native restricted segment representing entire native heap
>   * rename `withOwnerThread` to `handoff`
>   * add new `share` method, to create shared segments
>   * add new `registerCleaner` method, to register a segment against a cleaner
>   * add more helpers to create arrays from a segment e.g. `toIntArray`
>   * add some `asSlice` overloads (to make up for the fact that now segments are more frequently used as cursors)
>   * rename `baseAddress` to `address` (so that `MemorySegment` can implement `Addressable`)
> * `MemoryAddress`
>   * drop `segment` accessor
>   * drop `rebase` method and replace it with `segmentOffset` which returns the offset (a `long`) of this address relative
>     to a given segment
> * `MemoryAccess`
>   * New class supporting several static dereference helpers; the helpers are organized by carrier and access mode, where a
>     carrier is one of the usual suspect (a Java primitive, minus `boolean`); the access mode can be simple (e.g. access
>     base address of given segment), or indexed, in which case the accessor takes a segment and either a low-level byte
>     offset,or a high level logical index. The classification is reflected in the naming scheme (e.g. `getByte` vs.
>     `getByteAtOffset` vs `getByteAtIndex`).
> * `MemoryHandles`
>   * drop `withOffset` combinator
>   * drop `withStride` combinator
>   * the basic memory access handle factory now returns a var handle which takes a `MemorySegment` and a `long` - from which
>     it is easy to derive all the other handles using plain var handle combinators.
> * `Addressable`
>   * This is a new interface which is attached to entities which can be projected to a `MemoryAddress`. For now, both
>     `MemoryAddress` and `MemorySegment` implement it; we have plans, with JEP 389 [2] to add more implementations. Clients
>     can largely ignore this interface, which comes in really handy when defining native bindings with tools like `jextract`.
> * `MemoryLayouts`
>   * A new layout, for machine addresses, has been added to the mix.
> 
> 
> 
> ### Implementation changes
> 
> There are two main things to discuss here: support for shared segments, and the general simplification of the memory
> access var handle support.
> #### Shared segments
> 
> The support for shared segments cuts in pretty deep in the VM. Support for shared segments is notoriously hard to
> achieve, at least in a way that guarantees optimal access performances. This is caused by the fact that, if a segment
> is shared, it would be possible for a thread to close it while another is accessing it.  After considering several
> options (see [3]), we zeroed onto an approach which is inspired by an happy idea that Andrew Haley had (and that he
> reminded me of at this year OpenJDK committer workshop - thanks!). The idea is that if we could *freeze* the world
> (e.g. with a GC pause), while a segment is closed, we could then prevent segments from being accessed concurrently to a
> close operation. For this to work, it  is crucial that no GC safepoints can occur between a segment liveness check and
> the access itself (otherwise it would be possible for the accessing thread to stop just right before an unsafe call).
> It also relies on the fact that hotspot/C2 should not be able to propagate loads across safepoints.  Sadly, none of
> these conditions seems to be valid in the current implementation, so we needed to resort to a bit of creativity. First,
> we noted that, if we could mark so called *scoped* method with an annotation, it would be very simply to check as to
> whether a thread was in the middle of a scoped method when we stopped the world for a close operation (btw, instead of
> stopping the world, we do a much more efficient, thread-local polling, thanks to JEP 312 [4]).  The question is, then,
> once we detect that a thread is accessing the very segment we're about to close, what should happen? We first
> experimented with a solution which would install an *asynchronous* exception on the accessing thread, thus making it
> fail. This solution has some desirable properties, in that a `close` operation always succeeds. Unfortunately the
> machinery for async exceptions is a bit fragile (e.g. not all the code in hotspot checks for async exceptions); to
> minimize risks, we decided to revert to a simpler strategy, where `close` might fail when it finds that another thread
> is accessing the segment being closed.  As written in the javadoc, this doesn't mean that clients should just catch and
> try again; an exception on `close` is a bug in the user code, likely arising from lack of synchronization, and should
> be treated as such.  In terms of gritty implementation, we needed to centralize memory access routines in a single
> place, so that we could have a set of routines closely mimicking the primitives exposed by `Unsafe` but which, in
> addition, also provided a liveness check. This way we could mark all these routines with the special `@Scoped`
> annotation, which tells the VM that something important is going on.  To achieve this, we created a new (autogenerated)
> class, called `ScopedMemoryAccess`. This class contains all the main memory access primitives (including bulk access,
> like `copyMemory`, or `setMemory`), and accepts, in addition to the access coordinates, also a scope object, which is
> tested before access. A reachability fence is also thrown in the mix to make sure that the scope is kept alive during
> access (which is important when registering segments against cleaners).  Of course, to make memory access safe, memory
> access var handles, byte buffer var handles, and byte buffer API should use the new `ScopedMemoryAccess` class instead
> of unsafe, so that a liveness check can be triggered (in case a scope is present).  `ScopedMemoryAccess` has a
> `closeScope` method, which initiates the thread-local handshakes, and returns `true` if the handshake completed
> successfully.  The implementation of `MemoryScope` (now significantly simplified from what we had before), has two
> implementations, one for confined segments and one for shared segments; the main difference between the two is what
> happens when the scope is closed; a confined segment sets a boolean flag to false, and returns, whereas a shared
> segment goes into a `CLOSING` state, then starts the handshake, and then updates the state again, to either `CLOSED` or
> `ALIVE` depending on whether the handshake was successful or not. Note that when a shared segment is in the `CLOSING`
> state, `MemorySegment::isAlive` will still return `true`, while the liveness check upon memory access will fail.  ####
> Memory access var handles overhaul  The key realization here was that if all memory access var handles took a
> coordinate pair of `MemorySegment` and `long`, all other access types could be derived from this basic var handle
> form.  This allowed us to remove the on-the-fly var handle generation, and to simply derive structural access var
> handles (such as those obtained by calling `MemoryLayout::varHandle`) using *plain* var handle combinators, so that
> e.g. additional offset is injected into a base memory access var handle.  This also helped in simplifying the
> implementation by removing the special `withStride` and `withOffset` combinators, which previously needed low-level
> access on the innards of the memory access var handle. All that code is now gone.  #### Test changes  Not much to see
> here - most of the tests needed to be updated because of the API changes. Some were beefed up (like the array test,
> since now segments can be projected into many different kinds of arrays). A test has been added to test the `Cleaner`
> functionality, and another stress test has been added for shared segments (`TestHandshake`). Some of the
> microbenchmarks also needed some tweaks - and some of them were also updated to also test performance in the shared
> segment case.  [1] - https://openjdk.java.net/jeps/393 [2] - https://openjdk.java.net/jeps/389 [3] -
> https://mail.openjdk.java.net/pipermail/panama-dev/2020-May/009004.html [4] - https://openjdk.java.net/jeps/312

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Tweak support for mapped memory segments

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/548/files
  - new: https://git.openjdk.java.net/jdk/pull/548/files/770b1e9c..75e406c0

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=548&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=548&range=05-06

  Stats: 543 lines in 13 files changed: 336 ins; 151 del; 56 mod
  Patch: https://git.openjdk.java.net/jdk/pull/548.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/548/head:pull/548

PR: https://git.openjdk.java.net/jdk/pull/548

From mcimadamore at openjdk.java.net  Mon Oct 12 18:10:18 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 12 Oct 2020 18:10:18 GMT
Subject: RFR: 8254162: Implementation of Foreign-Memory Access API (Third
 Incubator) [v6]
In-Reply-To: <pqHBaSZ3wkaJWqdEZ_cVc8iWbhRjdb8z2kLHzy9k7Aw=.e4af889e-1c9b-4a68-b11c-faa43d9ecd8d@github.com>
References: <IngRk57F78UN3yySfo6IABbdwnMogGNdYrykh_3em-c=.b81f7478-015c-45ed-9788-58d7519a2770@github.com>
 <yxFQpOG6cF_COlU-m2KJvS_6BRzRcv1ZiBSGGYNsmbA=.031c9e97-b423-4f8d-b848-b0e03f0866df@github.com>
 <pqHBaSZ3wkaJWqdEZ_cVc8iWbhRjdb8z2kLHzy9k7Aw=.e4af889e-1c9b-4a68-b11c-faa43d9ecd8d@github.com>
Message-ID: <r2OoQ5W5YQ6rjb2l3xrWy86Fju_T4tjncpoO39Gwalw=.882e7d9d-9e79-40c8-8290-71eb22ef39a4@github.com>

On Mon, 12 Oct 2020 11:42:04 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Tweak referenced to MemoryAddressProxy in Utils.java
>
> Build changes look good.

I've just uploaded a biggie update to the foreign memory access support. While doing performance evaluation, we have
realized that mixing a multi-level hierarchy (`MappedMemorySegment extends MemorySegments`) with exact invoke semantics
of `VarHandle` and `MethodHandle` is not a good match and can lead to great performance degradation for seemingly
"correct" code.

While some of this can be attributed to the `VarHandle` API, or to the fact that the so called "generic" invocation
path should not be that slow in case where the parameters are clearly related, it seems smelly that a primitive API
such as `MemorySegment` should give raise to such issues.

We have therefore decided to drop the `MappedMemorySegment` - this means that there's only one memory segment type
users can deal with: `MemorySegment` - and no chance for mistakes. Of course `MappedMemorySegment` has been primarily
introduces to allow for operations which were previously possible on `MappedByteBuffer` such as `force`. To support
these use cases, a separate class has been introduced, namely `MappedMemorySegments` (note the trailing `S`). This
class contains a bunch of static methods which can be used to achieve the desired effects, without polluting the
`MemorySegment` API.

A new method has been added on `MemorySegment` which returns an optional file descriptor; this might be useful for
clients which want to guess whether a segment is in fact a mapped segment, or if they need (e.g. in Windows) the file
descriptor to do some other kind of low level op.

I think this approach is more true to the goals and spirit of the Foreign Memory Access API, and it also offers some
ways to improve over the existing API: for instance, the only reason why the `MemorySegment::spliterator` method was a
static method was that we needed inference, so that we could return either a `Spliterator<MemorySegment>` or a
`Spliterator<MappedMemorySgement>`. All of that is gone now, so the method can return to be what it morally always has
been: an instance method on `MemorySegment`.

Updated javadoc:
http://cr.openjdk.java.net/~mcimadamore/8254162_v2/javadoc/jdk/incubator/foreign/package-summary.html

Updated specdiff:
http://cr.openjdk.java.net/~mcimadamore/8254162_v2/specdiff/overview-summary.html

-------------

PR: https://git.openjdk.java.net/jdk/pull/548

From aph at openjdk.java.net  Mon Oct 12 18:12:29 2020
From: aph at openjdk.java.net (Andrew Haley)
Date: Mon, 12 Oct 2020 18:12:29 GMT
Subject: RFR: 8254078: DataOutputStream is very slow post-disabling of
 Biased Locking [v5]
In-Reply-To: <lLg_yNI_6LvUZTlM4PyN5ra6AaUZZeT35QzYzV_0CpI=.f2d3cb9e-be30-40dc-922c-dad5bef7feea@github.com>
References: <lLg_yNI_6LvUZTlM4PyN5ra6AaUZZeT35QzYzV_0CpI=.f2d3cb9e-be30-40dc-922c-dad5bef7feea@github.com>
Message-ID: <m7ARywFg8Ni4jwTqp3Fm3SQc1B2hygUVpk_GGNekHWM=.9304f26a-e604-44d9-9c37-cf188ee4904f@github.com>

> DataOutputStream is very slow post-disabling of Biased Locking. This
> was discovered when benchmarking a transaction library, which showed
> significant performance loss when moving to JDK 15. WIth some small
> changes to DataOutputStream we can get the performance back. There's a
> JMH benchmark at
> http://cr.openjdk.java.net/~aph/JDK-8254078/jmh-tests.tar
> 
> Some Stream classes use very fine-grained locking.
> 
> In particular, writeInt is defined like this:
> 
>         out.write((v >>> 24) & 0xFF);
>         out.write((v >>> 16) & 0xFF);
>         out.write((v >>> 8) & 0xFF);
>         out.write((v >>> 0) & 0xFF);
>         incCount(4);
> 
> Unfortunately, ByteArrayOutputStream.write(byte) is defined like this:
> 
>     public synchronized void write(int b) {
>         ensureCapacity(count + 1);
>         buf[count] = (byte) b;
>         count += 1;
>     }
> 
> so we acquire and release a lock for every byte that is output.
> 
>  For example, writing 4kb of ints goes from 17.3 us/op to 53.9 us/op when biased locking is disabled:
> 
> 
> +UseBiasedLocking DataOutputStreamTest.dataOutputStreamOverByteArray avgt 6 53.895 ? 5.126 us/op
> -UseBiasedLocking DataOutputStreamTest.dataOutputStreamOverByteArray avgt 6 17.291 ? 4.430 us/op
> 
> There are refactorings of DataOutputStream we can do to mitigate this.

Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:

  8254078: DataOutputStream is very slow post-disabling of Biased Locking

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/542/files
  - new: https://git.openjdk.java.net/jdk/pull/542/files/a776efaa..43be1998

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=542&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=542&range=03-04

  Stats: 95 lines in 1 file changed: 19 ins; 31 del; 45 mod
  Patch: https://git.openjdk.java.net/jdk/pull/542.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/542/head:pull/542

PR: https://git.openjdk.java.net/jdk/pull/542

From aph at openjdk.java.net  Mon Oct 12 18:12:29 2020
From: aph at openjdk.java.net (Andrew Haley)
Date: Mon, 12 Oct 2020 18:12:29 GMT
Subject: RFR: 8254078: DataOutputStream is very slow post-disabling of
 Biased Locking [v2]
In-Reply-To: <Tj_EYEUEPB9fZdspeeU0CtMbmLNhl7S82MNRZIZodXo=.7a17d0a2-ac4d-47f5-98fb-c451afa59374@github.com>
References: <lLg_yNI_6LvUZTlM4PyN5ra6AaUZZeT35QzYzV_0CpI=.f2d3cb9e-be30-40dc-922c-dad5bef7feea@github.com>
 <Tj_EYEUEPB9fZdspeeU0CtMbmLNhl7S82MNRZIZodXo=.7a17d0a2-ac4d-47f5-98fb-c451afa59374@github.com>
Message-ID: <o18-QD9aQbz0twIkGPvMc6QcrmbRly2hRu6aJhslnLQ=.cac1a734-fad8-464b-aa56-4b16c419e5de@github.com>

On Wed, 7 Oct 2020 17:26:26 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> DataOutputStream is very slow post-disabling of Biased Locking. This
>> was discovered when benchmarking a transaction library, which showed
>> significant performance loss when moving to JDK 15. WIth some small
>> changes to DataOutputStream we can get the performance back. There's a
>> JMH benchmark at
>> http://cr.openjdk.java.net/~aph/JDK-8254078/jmh-tests.tar
>> 
>> Some Stream classes use very fine-grained locking.
>> 
>> In particular, writeInt is defined like this:
>> 
>>         out.write((v >>> 24) & 0xFF);
>>         out.write((v >>> 16) & 0xFF);
>>         out.write((v >>> 8) & 0xFF);
>>         out.write((v >>> 0) & 0xFF);
>>         incCount(4);
>> 
>> Unfortunately, ByteArrayOutputStream.write(byte) is defined like this:
>> 
>>     public synchronized void write(int b) {
>>         ensureCapacity(count + 1);
>>         buf[count] = (byte) b;
>>         count += 1;
>>     }
>> 
>> so we acquire and release a lock for every byte that is output.
>> 
>>  For example, writing 4kb of ints goes from 17.3 us/op to 53.9 us/op when biased locking is disabled:
>> 
>> 
>> +UseBiasedLocking DataOutputStreamTest.dataOutputStreamOverByteArray avgt 6 53.895 ? 5.126 us/op
>> -UseBiasedLocking DataOutputStreamTest.dataOutputStreamOverByteArray avgt 6 17.291 ? 4.430 us/op
>> 
>> There are refactorings of DataOutputStream we can do to mitigate this.
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8254078: DataOutputStream is very slow post-disabling of Biased Locking

> I have comments about the benchmark code style :)

Wow, thanks! I didn't know that JMH could do this, I thought you had to jump through the BenchmarkState hoops. This way
is much better.

-------------

PR: https://git.openjdk.java.net/jdk/pull/542

From aph at openjdk.java.net  Mon Oct 12 18:12:30 2020
From: aph at openjdk.java.net (Andrew Haley)
Date: Mon, 12 Oct 2020 18:12:30 GMT
Subject: RFR: 8254078: DataOutputStream is very slow post-disabling of
 Biased Locking [v2]
In-Reply-To: <gqWhGgXpIm1RKM00vCit5gLC7GtMmFaa65lyJBgB6Mo=.4612a8d7-5d8d-45c3-9a69-52e4bb9fd8df@github.com>
References: <lLg_yNI_6LvUZTlM4PyN5ra6AaUZZeT35QzYzV_0CpI=.f2d3cb9e-be30-40dc-922c-dad5bef7feea@github.com>
 <Tj_EYEUEPB9fZdspeeU0CtMbmLNhl7S82MNRZIZodXo=.7a17d0a2-ac4d-47f5-98fb-c451afa59374@github.com>
 <DAg8ijfqluhHelYG6Nc6C1yuxI0qZean31YjTzJzAA4=.c1e4290b-9777-435f-84d9-8b24ba5d37b4@github.com>
 <gqWhGgXpIm1RKM00vCit5gLC7GtMmFaa65lyJBgB6Mo=.4612a8d7-5d8d-45c3-9a69-52e4bb9fd8df@github.com>
Message-ID: <1ybmjQiTvwRhh_z8mH_nZyL0xopMidNw-dR8vycYf4U=.ff33b073-e129-426a-8a3f-b57152c3bbea@github.com>

On Wed, 7 Oct 2020 19:53:31 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I realise this is wording coming from DataInputStream but I don't think specifying the thread safety as optional is
> useful.

Aha, I guessed you wouldn't like that, but I was after changing as little as possible. I'll do ask you ask.

-------------

PR: https://git.openjdk.java.net/jdk/pull/542

From aph at openjdk.java.net  Mon Oct 12 18:12:31 2020
From: aph at openjdk.java.net (Andrew Haley)
Date: Mon, 12 Oct 2020 18:12:31 GMT
Subject: RFR: 8254078: DataOutputStream is very slow post-disabling of
 Biased Locking [v2]
In-Reply-To: <DAg8ijfqluhHelYG6Nc6C1yuxI0qZean31YjTzJzAA4=.c1e4290b-9777-435f-84d9-8b24ba5d37b4@github.com>
References: <lLg_yNI_6LvUZTlM4PyN5ra6AaUZZeT35QzYzV_0CpI=.f2d3cb9e-be30-40dc-922c-dad5bef7feea@github.com>
 <Tj_EYEUEPB9fZdspeeU0CtMbmLNhl7S82MNRZIZodXo=.7a17d0a2-ac4d-47f5-98fb-c451afa59374@github.com>
 <DAg8ijfqluhHelYG6Nc6C1yuxI0qZean31YjTzJzAA4=.c1e4290b-9777-435f-84d9-8b24ba5d37b4@github.com>
Message-ID: <kdS6o6-h2KgoBVBDAUb_3nxEGnYmyD1Qs_HMB7Iw8E0=.fc4abb4f-b829-4908-9f17-ce229f6aed1b@github.com>

On Wed, 7 Oct 2020 19:05:30 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8254078: DataOutputStream is very slow post-disabling of Biased Locking
>
> test/micro/org/openjdk/bench/java/io/DataOutputStreamTest.java line 25:
> 
>> 23:
>> 24: /*
>> 25:
> 
> The historical data will get stale very fast and is very hardware dependent.
> It will continue to exist in the PR, so I think it should be removed from the test.

If you like. I'm following existing practice.

> test/micro/org/openjdk/bench/java/io/DataOutputStreamTest.java line 62:
> 
>> 60:
>> 61: @BenchmarkMode(Mode.AverageTime)
>> 62: @OutputTimeUnit(TimeUnit.MICROSECONDS)
> 
> Most JMH tests use NANOSECOND for reporting.

I suspect that's because of the amount of time for which these other tests are expected to run, not a general principle.

-------------

PR: https://git.openjdk.java.net/jdk/pull/542

From aph at openjdk.java.net  Mon Oct 12 18:12:32 2020
From: aph at openjdk.java.net (Andrew Haley)
Date: Mon, 12 Oct 2020 18:12:32 GMT
Subject: RFR: 8254078: DataOutputStream is very slow post-disabling of
 Biased Locking [v4]
In-Reply-To: <kp3-ISdeUaZnvvfIIH9Kf76K8HiLXByGqQqydyWZ8nE=.9e15c45e-7f2a-48f1-9ae2-3b777f825e36@github.com>
References: <lLg_yNI_6LvUZTlM4PyN5ra6AaUZZeT35QzYzV_0CpI=.f2d3cb9e-be30-40dc-922c-dad5bef7feea@github.com>
 <Gj_g60Z7fHmhYdrpnT2orSadEquafzlbswhNfbOtEf4=.54e3592b-1e86-410d-8a37-9a51337cd0c8@github.com>
 <kp3-ISdeUaZnvvfIIH9Kf76K8HiLXByGqQqydyWZ8nE=.9e15c45e-7f2a-48f1-9ae2-3b777f825e36@github.com>
Message-ID: <Q2_nwwTt72aFpoadkuFRhfruTyHiqqZZq2k8dm2rO8Q=.d387c094-6599-4044-a0b3-382512c81564@github.com>

On Fri, 9 Oct 2020 14:13:36 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8254078: DataOutputStream is very slow post-disabling of Biased Locking
>
> test/micro/org/openjdk/bench/java/io/DataOutputStreamTest.java line 117:
> 
>> 115:             case STRING: writeString(state, dataOutput); break;
>> 116:         }
>> 117:     }
> 
> So, the way I see it, this can be replaced by:
> 
>     public void write(DataOutput dataOutput) {
>         switch (basicType) {
>             case CHAR:
>                 for (int i = 0; i < SIZE; i += 2) {
>                     dataOutput.writeChar(i);
>                 }
>                 break;
>             case SHORT:
>                 for (int i = 0; i < SIZE; i += 2) {
>                     dataOutput.writeShort(i);
>                 }
>                 break;
>             case INT:
>                 for (int i = 0; i < SIZE; i += 4) {
>                     dataOutput.writeInt(i);
>                 }
>                 break;
>             case STRING:
>                 dataOutput.writeChars(state.outputString);
>                 break;
>         }
>     }
> 
> ...thus keeping all the code in one place, and simplifying the benchmark.

I didn't quite do that, preferring to keep the writeX functions separate.

-------------

PR: https://git.openjdk.java.net/jdk/pull/542

From shade at openjdk.java.net  Mon Oct 12 18:24:15 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 12 Oct 2020 18:24:15 GMT
Subject: RFR: 8254078: DataOutputStream is very slow post-disabling of
 Biased Locking [v5]
In-Reply-To: <m7ARywFg8Ni4jwTqp3Fm3SQc1B2hygUVpk_GGNekHWM=.9304f26a-e604-44d9-9c37-cf188ee4904f@github.com>
References: <lLg_yNI_6LvUZTlM4PyN5ra6AaUZZeT35QzYzV_0CpI=.f2d3cb9e-be30-40dc-922c-dad5bef7feea@github.com>
 <m7ARywFg8Ni4jwTqp3Fm3SQc1B2hygUVpk_GGNekHWM=.9304f26a-e604-44d9-9c37-cf188ee4904f@github.com>
Message-ID: <GZPlMNeTDXrRwQS0RCwOpshgulzn-G00sm5QygAnTCo=.9031a38b-9dda-4c5f-bb91-a38bf7d31a01@github.com>

On Mon, 12 Oct 2020 18:12:29 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> DataOutputStream is very slow post-disabling of Biased Locking. This
>> was discovered when benchmarking a transaction library, which showed
>> significant performance loss when moving to JDK 15. WIth some small
>> changes to DataOutputStream we can get the performance back. There's a
>> JMH benchmark at
>> http://cr.openjdk.java.net/~aph/JDK-8254078/jmh-tests.tar
>> 
>> Some Stream classes use very fine-grained locking.
>> 
>> In particular, writeInt is defined like this:
>> 
>>         out.write((v >>> 24) & 0xFF);
>>         out.write((v >>> 16) & 0xFF);
>>         out.write((v >>> 8) & 0xFF);
>>         out.write((v >>> 0) & 0xFF);
>>         incCount(4);
>> 
>> Unfortunately, ByteArrayOutputStream.write(byte) is defined like this:
>> 
>>     public synchronized void write(int b) {
>>         ensureCapacity(count + 1);
>>         buf[count] = (byte) b;
>>         count += 1;
>>     }
>> 
>> so we acquire and release a lock for every byte that is output.
>> 
>>  For example, writing 4kb of ints goes from 17.3 us/op to 53.9 us/op when biased locking is disabled:
>> 
>> 
>> +UseBiasedLocking DataOutputStreamTest.dataOutputStreamOverByteArray avgt 6 53.895 ? 5.126 us/op
>> -UseBiasedLocking DataOutputStreamTest.dataOutputStreamOverByteArray avgt 6 17.291 ? 4.430 us/op
>> 
>> There are refactorings of DataOutputStream we can do to mitigate this.
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8254078: DataOutputStream is very slow post-disabling of Biased Locking

Benchmark code looks good, except a few remaining nits.

test/micro/org/openjdk/bench/java/io/DataOutputStreamTest.java line 44:

> 42:     @Param({"4096"}) int size;
> 43:     final ByteArrayOutputStream byteArrayOutputStream = new ByteArrayOutputStream(size);
> 44:     final File f = new File("DataOutputStreamTest.tmp");

This should be `File.createTempFile("DataOutputStreamTest", "out")`? This way you don't leave waste in current dir.

test/micro/org/openjdk/bench/java/io/DataOutputStreamTest.java line 57:

> 55:             bufferedFileStream = new DataOutputStream(new BufferedOutputStream(fileOutputStream));
> 56:             outputString = new String(new byte[size]);
> 57:         } catch (Exception e) {

You can do `public void setup() throws Exception`, and ditch the `try-catch` block. Let JMH deal with exceptions, if
any.

test/micro/org/openjdk/bench/java/io/DataOutputStreamTest.java line 63:

> 61:
> 62:     public void writeChars(DataOutput dataOutput)
> 63:             throws Exception {

Unusual style to put `throws Exception` on the separate line...

-------------

Marked as reviewed by shade (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/542

From shade at openjdk.java.net  Mon Oct 12 18:24:15 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 12 Oct 2020 18:24:15 GMT
Subject: RFR: 8254078: DataOutputStream is very slow post-disabling of
 Biased Locking [v4]
In-Reply-To: <Q2_nwwTt72aFpoadkuFRhfruTyHiqqZZq2k8dm2rO8Q=.d387c094-6599-4044-a0b3-382512c81564@github.com>
References: <lLg_yNI_6LvUZTlM4PyN5ra6AaUZZeT35QzYzV_0CpI=.f2d3cb9e-be30-40dc-922c-dad5bef7feea@github.com>
 <Gj_g60Z7fHmhYdrpnT2orSadEquafzlbswhNfbOtEf4=.54e3592b-1e86-410d-8a37-9a51337cd0c8@github.com>
 <kp3-ISdeUaZnvvfIIH9Kf76K8HiLXByGqQqydyWZ8nE=.9e15c45e-7f2a-48f1-9ae2-3b777f825e36@github.com>
 <Q2_nwwTt72aFpoadkuFRhfruTyHiqqZZq2k8dm2rO8Q=.d387c094-6599-4044-a0b3-382512c81564@github.com>
Message-ID: <ApaFLo2qDHxGVRdIHKyjYEi2hyLHyTejghlbTQMNIdg=.5ade86c2-1802-4fff-bea9-a426d4b3550d@github.com>

On Mon, 12 Oct 2020 18:09:12 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> test/micro/org/openjdk/bench/java/io/DataOutputStreamTest.java line 117:
>> 
>>> 115:             case STRING: writeString(state, dataOutput); break;
>>> 116:         }
>>> 117:     }
>> 
>> So, the way I see it, this can be replaced by:
>> 
>>     public void write(DataOutput dataOutput) {
>>         switch (basicType) {
>>             case CHAR:
>>                 for (int i = 0; i < SIZE; i += 2) {
>>                     dataOutput.writeChar(i);
>>                 }
>>                 break;
>>             case SHORT:
>>                 for (int i = 0; i < SIZE; i += 2) {
>>                     dataOutput.writeShort(i);
>>                 }
>>                 break;
>>             case INT:
>>                 for (int i = 0; i < SIZE; i += 4) {
>>                     dataOutput.writeInt(i);
>>                 }
>>                 break;
>>             case STRING:
>>                 dataOutput.writeChars(state.outputString);
>>                 break;
>>         }
>>     }
>> 
>> ...thus keeping all the code in one place, and simplifying the benchmark.
>
> I didn't quite do that, preferring to keep the writeX functions separate.

No problem, this is a question of personal style. If this was a very fine-grained benchmark, we would worry about
inlining/dispatch costs.

-------------

PR: https://git.openjdk.java.net/jdk/pull/542

From shade at openjdk.java.net  Mon Oct 12 18:24:16 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 12 Oct 2020 18:24:16 GMT
Subject: RFR: 8254078: DataOutputStream is very slow post-disabling of
 Biased Locking [v5]
In-Reply-To: <GZPlMNeTDXrRwQS0RCwOpshgulzn-G00sm5QygAnTCo=.9031a38b-9dda-4c5f-bb91-a38bf7d31a01@github.com>
References: <lLg_yNI_6LvUZTlM4PyN5ra6AaUZZeT35QzYzV_0CpI=.f2d3cb9e-be30-40dc-922c-dad5bef7feea@github.com>
 <m7ARywFg8Ni4jwTqp3Fm3SQc1B2hygUVpk_GGNekHWM=.9304f26a-e604-44d9-9c37-cf188ee4904f@github.com>
 <GZPlMNeTDXrRwQS0RCwOpshgulzn-G00sm5QygAnTCo=.9031a38b-9dda-4c5f-bb91-a38bf7d31a01@github.com>
Message-ID: <0I6kZ2rCklCMmXMSzTgLaiPMVwBb46A9cJlW9WxHseQ=.9b98fc93-2ee3-4d8f-a7bb-fa606c47a869@github.com>

On Mon, 12 Oct 2020 18:13:50 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8254078: DataOutputStream is very slow post-disabling of Biased Locking
>
> test/micro/org/openjdk/bench/java/io/DataOutputStreamTest.java line 44:
> 
>> 42:     @Param({"4096"}) int size;
>> 43:     final ByteArrayOutputStream byteArrayOutputStream = new ByteArrayOutputStream(size);
>> 44:     final File f = new File("DataOutputStreamTest.tmp");
> 
> This should be `File.createTempFile("DataOutputStreamTest", "out")`? This way you don't leave waste in current dir.

Can probably move all these initializations to `setup()`. It does not look like the fields `final`-ity matter for this
benchmark.

-------------

PR: https://git.openjdk.java.net/jdk/pull/542

From dfuchs at openjdk.java.net  Mon Oct 12 18:24:17 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Mon, 12 Oct 2020 18:24:17 GMT
Subject: RFR: 8254078: DataOutputStream is very slow post-disabling of
 Biased Locking [v5]
In-Reply-To: <m7ARywFg8Ni4jwTqp3Fm3SQc1B2hygUVpk_GGNekHWM=.9304f26a-e604-44d9-9c37-cf188ee4904f@github.com>
References: <lLg_yNI_6LvUZTlM4PyN5ra6AaUZZeT35QzYzV_0CpI=.f2d3cb9e-be30-40dc-922c-dad5bef7feea@github.com>
 <m7ARywFg8Ni4jwTqp3Fm3SQc1B2hygUVpk_GGNekHWM=.9304f26a-e604-44d9-9c37-cf188ee4904f@github.com>
Message-ID: <_aswFpv09W1NlDo-Z8TPosV-i-SOgcrGZ4SkdQWOmB4=.4472c649-7c8a-4125-b5f4-bd0ef3558b6c@github.com>

On Mon, 12 Oct 2020 18:12:29 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> DataOutputStream is very slow post-disabling of Biased Locking. This
>> was discovered when benchmarking a transaction library, which showed
>> significant performance loss when moving to JDK 15. WIth some small
>> changes to DataOutputStream we can get the performance back. There's a
>> JMH benchmark at
>> http://cr.openjdk.java.net/~aph/JDK-8254078/jmh-tests.tar
>> 
>> Some Stream classes use very fine-grained locking.
>> 
>> In particular, writeInt is defined like this:
>> 
>>         out.write((v >>> 24) & 0xFF);
>>         out.write((v >>> 16) & 0xFF);
>>         out.write((v >>> 8) & 0xFF);
>>         out.write((v >>> 0) & 0xFF);
>>         incCount(4);
>> 
>> Unfortunately, ByteArrayOutputStream.write(byte) is defined like this:
>> 
>>     public synchronized void write(int b) {
>>         ensureCapacity(count + 1);
>>         buf[count] = (byte) b;
>>         count += 1;
>>     }
>> 
>> so we acquire and release a lock for every byte that is output.
>> 
>>  For example, writing 4kb of ints goes from 17.3 us/op to 53.9 us/op when biased locking is disabled:
>> 
>> 
>> +UseBiasedLocking DataOutputStreamTest.dataOutputStreamOverByteArray avgt 6 53.895 ? 5.126 us/op
>> -UseBiasedLocking DataOutputStreamTest.dataOutputStreamOverByteArray avgt 6 17.291 ? 4.430 us/op
>> 
>> There are refactorings of DataOutputStream we can do to mitigate this.
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8254078: DataOutputStream is very slow post-disabling of Biased Locking

src/java.base/share/classes/java/io/DataInputStream.java line 37:

> 35:  * <p>
> 36:  * A DataInputStream is not safe for use by multiple concurrent
> 37:  * threads. If a DataOutputStream is to be used by more than one

Hi Andrew, just noticed a typo here: DataOutputStream
best regards,
-- daniel

-------------

PR: https://git.openjdk.java.net/jdk/pull/542

From alanb at openjdk.java.net  Mon Oct 12 18:28:11 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 12 Oct 2020 18:28:11 GMT
Subject: RFR: 8254078: DataOutputStream is very slow post-disabling of
 Biased Locking [v5]
In-Reply-To: <_aswFpv09W1NlDo-Z8TPosV-i-SOgcrGZ4SkdQWOmB4=.4472c649-7c8a-4125-b5f4-bd0ef3558b6c@github.com>
References: <lLg_yNI_6LvUZTlM4PyN5ra6AaUZZeT35QzYzV_0CpI=.f2d3cb9e-be30-40dc-922c-dad5bef7feea@github.com>
 <m7ARywFg8Ni4jwTqp3Fm3SQc1B2hygUVpk_GGNekHWM=.9304f26a-e604-44d9-9c37-cf188ee4904f@github.com>
 <_aswFpv09W1NlDo-Z8TPosV-i-SOgcrGZ4SkdQWOmB4=.4472c649-7c8a-4125-b5f4-bd0ef3558b6c@github.com>
Message-ID: <Eqg_XLWuEON6jCGvkN72cpXq5CMuZ0oxCUkXgfOEQR0=.be2efc0f-910e-493a-a4cc-165facb680fe@github.com>

On Mon, 12 Oct 2020 18:19:28 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8254078: DataOutputStream is very slow post-disabling of Biased Locking
>
> src/java.base/share/classes/java/io/DataInputStream.java line 37:
> 
>> 35:  * <p>
>> 36:  * A DataInputStream is not safe for use by multiple concurrent
>> 37:  * threads. If a DataOutputStream is to be used by more than one
> 
> Hi Andrew, just noticed a typo here: DataOutputStream
> best regards,
> -- daniel

Yes, that was a comment on the previous iteration too. Also s/output/input/.

-------------

PR: https://git.openjdk.java.net/jdk/pull/542

From github.com+51754783+coreyashford at openjdk.java.net  Mon Oct 12 19:15:16 2020
From: github.com+51754783+coreyashford at openjdk.java.net (CoreyAshford)
Date: Mon, 12 Oct 2020 19:15:16 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v4]
In-Reply-To: <2zhMnWcr1cuE5sxUyCvU9bN5HP_ph_1xQEV3wdx_7dg=.3d509c17-db83-432c-a983-79137d12a827@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <45FtTQB1m6HyZSASY42STMkQffIWlVPibWn9_r00xYs=.daad2653-2571-491f-8dd7-5954fe4ece00@github.com>
 <2zhMnWcr1cuE5sxUyCvU9bN5HP_ph_1xQEV3wdx_7dg=.3d509c17-db83-432c-a983-79137d12a827@github.com>
Message-ID: <v73cR-nXiOm7jlocTGR-4yUOEepybv6wFqI1NCFh9f8=.4a9ecb44-e3f1-4b20-b56e-4824a70cf187@github.com>

On Mon, 12 Oct 2020 12:55:02 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> CoreyAshford has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - TestBase64.java: fix comment to correctly reflect actual intrinsic names.
>>    
>>    The intrinsic names that are visible with -XX:+PrintCompilation are encode
>>    and decode, rather than encodeBlock and decodeBlock.
>>  - stubGenerator_ppc.cpp: fix regression caused by change to using loop counter
>>    
>>    My original fix didn't account for the case where sl < block_size.  In the
>>    event sl < block_size, the shifted sl will become zero, so it should
>>    jump to the code that computes how much data was processed - 0 - and return.
>
> src/hotspot/cpu/ppc/stubGenerator_ppc.cpp line 3745:
> 
>> 3743:     __ clrldi(isURL, isURL, 32);
>> 3744:
>> 3745:     // Load constant vec registers that need to be loaded from memory
> 
> With larger unroll factor we run through this code more often without making any progress, because only the Java part
> does all the work for the remaining bytes. Would be nice to move unnecessary parts for that between mtctr and align.

You're right that there's quite a lot of set up before the size check is performed.  I will fix, this and run
regression the regression test.

-------------

PR: https://git.openjdk.java.net/jdk/pull/293

From pliden at openjdk.java.net  Mon Oct 12 19:25:20 2020
From: pliden at openjdk.java.net (Per Liden)
Date: Mon, 12 Oct 2020 19:25:20 GMT
Subject: RFR: 8188055: (ref) Add Reference::refersTo predicate [v2]
In-Reply-To: <c1xBid7xMlFExHk4P43Hyf0SnYAJNPvW511XYzzy3QE=.e401cd8a-d34c-4f54-869c-43f7656b6bac@github.com>
References: <D4HSg8FT20Eaxk5KJkkw0GgETSxRkBn1ipS3Dt0kPto=.e4bab078-2e04-4413-90cb-9bfafb2a6831@github.com>
 <QpVGNFn7FwJVVijkSVKgUxWDLw3Y7im-mlA3yw7_crU=.1e8d22b9-29e8-4347-8790-2fe213435219@github.com>
 <fdRw8XxvrIGJI35awI_IOOg2tucC2JpjupFaVJ1lMvI=.b0b42966-48b0-4915-a9c0-b61866cb9276@github.com>
 <c1xBid7xMlFExHk4P43Hyf0SnYAJNPvW511XYzzy3QE=.e401cd8a-d34c-4f54-869c-43f7656b6bac@github.com>
Message-ID: <pjX8i3PZNjRciV-IeQ77l8R93b2LCtBqk4QxyZTdjSw=.055de682-1a41-4680-847c-2e97dff1abb2@github.com>

On Mon, 12 Oct 2020 15:56:59 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> test/hotspot/jtreg/gc/TestReferenceRefersTo.java line 186:
>> 
>>> 184:
>>> 185:             expectNotValue(testWeak2, testObject3, "testWeak2");
>>> 186:             expectValue(testWeak3, testObject3, "testWeak3");
>> 
>> It looks to me like the `expectNotCleared()` and `expectNotValue()` methods can be removed. All expect-tests can be
>> done with just `expectCleared()` and `expectValue()`.
>
> I don't think so.  For example,
> `expectNotCleared(testWeak1, "testWeak1")`
> is not testing the same thing as
> `expectValue(testWeak1, testObject1, "testWeak1")`
> If the implementation is correct they will indeed always be consistent. But they could be different with an incorrect
> implementation.

Doesn't that just depend on how you implement `expectValue()`/`expectCleared()`? You could for example implement
`expectValue()`/`expectCleared()` to be supersets of `expectNotCleared()`/`expectNotValue()`, which I think would make
this easier to read. Something like this:

private static void expectValue(...) {
    if (ref.refersTo(null)) {
        fail("expected " + which + " to not be cleared");
    }
 
    if (!ref.refersTo(value)) {
        fail(which + " refers to unexpected value");
    }
}

private static void expectCleared(...) {
    if (ref.refersTo(new TestObject(5))) {
        fail(which + " refers to unexpected value");
    }

    if (!ref.refersTo(null)) {
        fail("expected " + which + " to be cleared");
    }
}

-------------

PR: https://git.openjdk.java.net/jdk/pull/498

From thomas.stuefe at gmail.com  Mon Oct 12 19:36:35 2020
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Mon, 12 Oct 2020 21:36:35 +0200
Subject: core-libs-dev email delivery (is broken for external subscribers)
In-Reply-To: <1d35ad95-a21d-d0a7-57cf-f5d1f05913d5@oracle.com>
References: <878scdx8b7.fsf@mid.deneb.enyo.de>
 <1d35ad95-a21d-d0a7-57cf-f5d1f05913d5@oracle.com>
Message-ID: <CAA-vtUy8iK5MkqwdE5hazOkGweKGkLr=253gkxfkog_CZYFVOA@mail.gmail.com>

Thank you, Tim!

On Mon 12. Oct 2020 at 19:38, Tim Bell <tim.bell at oracle.com> wrote:

> On 2020-10-11 05:21, Florian Weimer wrote:
> > We used to have a problem where hotspot-dev mail did not get delivered
> > to list subscribers.  Is it possible that a similar issue now affects
> > core-libs-dev?  I don't receive mail on two separate mail accounts,
> > with completely different infrastructure on my end.
>
> I reproduced this issue with my external mailbox.  My corporate internal
> mailbox receives core-libs-dev messages OK.
>
> This does appear to be a repeat of the earlier issue with hotspot-dev.
> I filed an internal problem report and I will escalate.
>
> Until this issue is resolved, the workaround is to keep an eye on the
> message archive at:
>
>    https://mail.openjdk.java.net/pipermail/core-libs-dev/
>
> Tim
>

From kravikumar at openjdk.java.net  Mon Oct 12 19:45:20 2020
From: kravikumar at openjdk.java.net (Kiran Sidhartha Ravikumar)
Date: Mon, 12 Oct 2020 19:45:20 GMT
Subject: RFR: 8251861: Remove unused jdk.internal.ref.SoftCleanable and
 WeakCleanable
Message-ID: <PXpykxg5wYq8DcCcEglVziPOCW1m4FEqx9EupvNM7go=.3de80256-238e-40bd-86cc-5ed7576f4798@github.com>

Hi Guys,

Please review the fix to remove jdk.internal.ref.SoftCleanable and WeakCleanable classes as there is no visible usage
of them in JDK. Currently, only PhantomCleanable is used.

More information can be viewed at https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-August/067997.html

Bug: https://bugs.openjdk.java.net/browse/JDK-8251861

Thanks,
Kiran

-------------

Commit messages:
 - 8251861: Remove unused jdk.internal.ref.SoftCleanable and WeakCleanable

Changes: https://git.openjdk.java.net/jdk/pull/616/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=616&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8251861
  Stats: 635 lines in 4 files changed: 0 ins; 633 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/616.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/616/head:pull/616

PR: https://git.openjdk.java.net/jdk/pull/616

From mcimadamore at openjdk.java.net  Mon Oct 12 20:18:50 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 12 Oct 2020 20:18:50 GMT
Subject: RFR: 8254162: Implementation of Foreign-Memory Access API (Third
 Incubator) [v8]
In-Reply-To: <IngRk57F78UN3yySfo6IABbdwnMogGNdYrykh_3em-c=.b81f7478-015c-45ed-9788-58d7519a2770@github.com>
References: <IngRk57F78UN3yySfo6IABbdwnMogGNdYrykh_3em-c=.b81f7478-015c-45ed-9788-58d7519a2770@github.com>
Message-ID: <yTbCSfi_Y4jrRStq2NShdli2JBkPfnQAjb1v7kcnaMs=.39608405-19fc-47b0-b2d4-2e5c1e69370f@github.com>

> This patch contains the changes associated with the third incubation round of the foreign memory access API incubation
> (see JEP 393 [1]). This iteration focus on improving the usability of the API in 3 main ways:
> * first, by providing a way to obtain truly *shared* segments, which can be accessed and closed concurrently from
>   multiple threads
> * second, by providing a way to register a memory segment against a `Cleaner`, so as to have some (optional) guarantee
>   that the memory will be deallocated, eventually
> * third, by not requiring users to dive deep into var handles when they first pick up the API; a new `MemoryAccess` class
>   has been added, which defines several useful dereference routines; these are really just thin wrappers around memory
>   access var handles, but they make the barrier of entry for using this API somewhat lower.
> 
> A big conceptual shift that comes with this API refresh is that the role of `MemorySegment` and `MemoryAddress` is not
> the same as it used to be; it used to be the case that a memory address could (sometimes, not always) have a back link
> to the memory segment which originated it; additionally, memory access var handles used `MemoryAddress` as a basic unit
> of dereference.  This has all changed as per this API refresh;  now a `MemoryAddress` is just a dumb carrier which
> wraps a pair of object/long addressing coordinates; `MemorySegment` has become the star of the show, as far as
> dereferencing memory is concerned. You cannot dereference memory if you don't have a segment. This improves usability
> in a number of ways - first, it is a lot easier to wrap native addresses (`long`, essentially) into a `MemoryAddress`;
> secondly, it is crystal clear what a client has to do in order to dereference memory: if a client has a segment, it can
> use that; otherwise, if the client only has an address, it will have to create a segment *unsafely* (this can be done
> by calling `MemoryAddress::asSegmentRestricted`).  A list of the API, implementation and test changes is provided
> below. If  you have any questions, or need more detailed explanations, I (and the  rest of the Panama team) will be
> happy to point at existing discussions,  and/or to provide the feedback required.   A big thank to Erik Osterlund,
> Vladimir Ivanov and David Holmes, without whom the work on shared memory segment would not have been possible; also I'd
> like to thank Paul Sandoz, whose insights on API design have been very helpful in this journey.  Thanks  Maurizio
> Javadoc:   http://cr.openjdk.java.net/~mcimadamore/8254162_v1/javadoc/jdk/incubator/foreign/package-summary.html
> Specdiff:
> 
> http://cr.openjdk.java.net/~mcimadamore/8254162_v1/specdiff/jdk/incubator/foreign/package-summary.html
> 
> CSR:
> 
> https://bugs.openjdk.java.net/browse/JDK-8254163
> 
> 
> 
> ### API Changes
> 
> * `MemorySegment`
>   * drop factory for restricted segment (this has been moved to `MemoryAddress`, see below)
>   * added a no-arg factory for a native restricted segment representing entire native heap
>   * rename `withOwnerThread` to `handoff`
>   * add new `share` method, to create shared segments
>   * add new `registerCleaner` method, to register a segment against a cleaner
>   * add more helpers to create arrays from a segment e.g. `toIntArray`
>   * add some `asSlice` overloads (to make up for the fact that now segments are more frequently used as cursors)
>   * rename `baseAddress` to `address` (so that `MemorySegment` can implement `Addressable`)
> * `MemoryAddress`
>   * drop `segment` accessor
>   * drop `rebase` method and replace it with `segmentOffset` which returns the offset (a `long`) of this address relative
>     to a given segment
> * `MemoryAccess`
>   * New class supporting several static dereference helpers; the helpers are organized by carrier and access mode, where a
>     carrier is one of the usual suspect (a Java primitive, minus `boolean`); the access mode can be simple (e.g. access
>     base address of given segment), or indexed, in which case the accessor takes a segment and either a low-level byte
>     offset,or a high level logical index. The classification is reflected in the naming scheme (e.g. `getByte` vs.
>     `getByteAtOffset` vs `getByteAtIndex`).
> * `MemoryHandles`
>   * drop `withOffset` combinator
>   * drop `withStride` combinator
>   * the basic memory access handle factory now returns a var handle which takes a `MemorySegment` and a `long` - from which
>     it is easy to derive all the other handles using plain var handle combinators.
> * `Addressable`
>   * This is a new interface which is attached to entities which can be projected to a `MemoryAddress`. For now, both
>     `MemoryAddress` and `MemorySegment` implement it; we have plans, with JEP 389 [2] to add more implementations. Clients
>     can largely ignore this interface, which comes in really handy when defining native bindings with tools like `jextract`.
> * `MemoryLayouts`
>   * A new layout, for machine addresses, has been added to the mix.
> 
> 
> 
> ### Implementation changes
> 
> There are two main things to discuss here: support for shared segments, and the general simplification of the memory
> access var handle support.
> #### Shared segments
> 
> The support for shared segments cuts in pretty deep in the VM. Support for shared segments is notoriously hard to
> achieve, at least in a way that guarantees optimal access performances. This is caused by the fact that, if a segment
> is shared, it would be possible for a thread to close it while another is accessing it.  After considering several
> options (see [3]), we zeroed onto an approach which is inspired by an happy idea that Andrew Haley had (and that he
> reminded me of at this year OpenJDK committer workshop - thanks!). The idea is that if we could *freeze* the world
> (e.g. with a GC pause), while a segment is closed, we could then prevent segments from being accessed concurrently to a
> close operation. For this to work, it  is crucial that no GC safepoints can occur between a segment liveness check and
> the access itself (otherwise it would be possible for the accessing thread to stop just right before an unsafe call).
> It also relies on the fact that hotspot/C2 should not be able to propagate loads across safepoints.  Sadly, none of
> these conditions seems to be valid in the current implementation, so we needed to resort to a bit of creativity. First,
> we noted that, if we could mark so called *scoped* method with an annotation, it would be very simply to check as to
> whether a thread was in the middle of a scoped method when we stopped the world for a close operation (btw, instead of
> stopping the world, we do a much more efficient, thread-local polling, thanks to JEP 312 [4]).  The question is, then,
> once we detect that a thread is accessing the very segment we're about to close, what should happen? We first
> experimented with a solution which would install an *asynchronous* exception on the accessing thread, thus making it
> fail. This solution has some desirable properties, in that a `close` operation always succeeds. Unfortunately the
> machinery for async exceptions is a bit fragile (e.g. not all the code in hotspot checks for async exceptions); to
> minimize risks, we decided to revert to a simpler strategy, where `close` might fail when it finds that another thread
> is accessing the segment being closed.  As written in the javadoc, this doesn't mean that clients should just catch and
> try again; an exception on `close` is a bug in the user code, likely arising from lack of synchronization, and should
> be treated as such.  In terms of gritty implementation, we needed to centralize memory access routines in a single
> place, so that we could have a set of routines closely mimicking the primitives exposed by `Unsafe` but which, in
> addition, also provided a liveness check. This way we could mark all these routines with the special `@Scoped`
> annotation, which tells the VM that something important is going on.  To achieve this, we created a new (autogenerated)
> class, called `ScopedMemoryAccess`. This class contains all the main memory access primitives (including bulk access,
> like `copyMemory`, or `setMemory`), and accepts, in addition to the access coordinates, also a scope object, which is
> tested before access. A reachability fence is also thrown in the mix to make sure that the scope is kept alive during
> access (which is important when registering segments against cleaners).  Of course, to make memory access safe, memory
> access var handles, byte buffer var handles, and byte buffer API should use the new `ScopedMemoryAccess` class instead
> of unsafe, so that a liveness check can be triggered (in case a scope is present).  `ScopedMemoryAccess` has a
> `closeScope` method, which initiates the thread-local handshakes, and returns `true` if the handshake completed
> successfully.  The implementation of `MemoryScope` (now significantly simplified from what we had before), has two
> implementations, one for confined segments and one for shared segments; the main difference between the two is what
> happens when the scope is closed; a confined segment sets a boolean flag to false, and returns, whereas a shared
> segment goes into a `CLOSING` state, then starts the handshake, and then updates the state again, to either `CLOSED` or
> `ALIVE` depending on whether the handshake was successful or not. Note that when a shared segment is in the `CLOSING`
> state, `MemorySegment::isAlive` will still return `true`, while the liveness check upon memory access will fail.  ####
> Memory access var handles overhaul  The key realization here was that if all memory access var handles took a
> coordinate pair of `MemorySegment` and `long`, all other access types could be derived from this basic var handle
> form.  This allowed us to remove the on-the-fly var handle generation, and to simply derive structural access var
> handles (such as those obtained by calling `MemoryLayout::varHandle`) using *plain* var handle combinators, so that
> e.g. additional offset is injected into a base memory access var handle.  This also helped in simplifying the
> implementation by removing the special `withStride` and `withOffset` combinators, which previously needed low-level
> access on the innards of the memory access var handle. All that code is now gone.  #### Test changes  Not much to see
> here - most of the tests needed to be updated because of the API changes. Some were beefed up (like the array test,
> since now segments can be projected into many different kinds of arrays). A test has been added to test the `Cleaner`
> functionality, and another stress test has been added for shared segments (`TestHandshake`). Some of the
> microbenchmarks also needed some tweaks - and some of them were also updated to also test performance in the shared
> segment case.  [1] - https://openjdk.java.net/jeps/393 [2] - https://openjdk.java.net/jeps/389 [3] -
> https://mail.openjdk.java.net/pipermail/panama-dev/2020-May/009004.html [4] - https://openjdk.java.net/jeps/312

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Simplify example in the toplevel javadoc

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/548/files
  - new: https://git.openjdk.java.net/jdk/pull/548/files/75e406c0..d14d06a4

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=548&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=548&range=06-07

  Stats: 14 lines in 1 file changed: 4 ins; 5 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/548.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/548/head:pull/548

PR: https://git.openjdk.java.net/jdk/pull/548

From vromero at openjdk.java.net  Mon Oct 12 21:35:36 2020
From: vromero at openjdk.java.net (Vicente Romero)
Date: Mon, 12 Oct 2020 21:35:36 GMT
Subject: RFR: 8246774: implementing Record Classes as a standard feature
 in Java [v11]
In-Reply-To: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com>
References: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com>
Message-ID: <PO-0WLayMrnG-VWjwQ65rDzRYBXAXnACgND7qJI5KTw=.0d321607-e4ea-41a0-8623-dd640dcfc1a0@github.com>

> 8246774: implementing Record Classes as a standard feature in Java

Vicente Romero 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 JDK-8246774
 - removing unused jcod file
 - remove unnecessary jtreg tags from tests, remove othervm etc when applicable
 - adding missing changes to some tests
 - modifiying @since from 14 to 16
 - Remove preview args from ObjectMethodsTest
 - Remove preview args from record serialization tests
 - removing the javax.lang.model related code to be moved to a separate bug
 - 8246774: Record Classes (final) implementation
   
   Co-authored-by: Vicente Romero <vicente.romero at oracle.com>
   Co-authored-by: Harold Seigel <harold.seigel at oracle.com>
   Co-authored-by: Jonathan Gibbons <jonathan.gibbons at oracle.com>
   Co-authored-by: Brian Goetz <brian.goetz at oracle.com>
   Co-authored-by: Maurizio Cimadamore <maurizio.cimadamore at oracle.com>
   Co-authored-by: Joe Darcy <joe.darcy at oracle.com>
   Co-authored-by: Chris Hegarty <chris.hegarty at oracle.com>
   Co-authored-by: Jan Lahoda <jan.lahoda at oracle.com>

-------------

Changes: https://git.openjdk.java.net/jdk/pull/290/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=290&range=10
  Stats: 856 lines in 109 files changed: 64 ins; 552 del; 240 mod
  Patch: https://git.openjdk.java.net/jdk/pull/290.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/290/head:pull/290

PR: https://git.openjdk.java.net/jdk/pull/290

From github.com+51754783+coreyashford at openjdk.java.net  Mon Oct 12 21:41:37 2020
From: github.com+51754783+coreyashford at openjdk.java.net (CoreyAshford)
Date: Mon, 12 Oct 2020 21:41:37 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v5]
In-Reply-To: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
Message-ID: <O4v-ldD7_Ya-1ILjIukRaAbhORzBPBiGZeI2mrnttNc=.b025900d-d284-40b3-814f-9fc8b6f75f46@github.com>

> This patch set encompasses the following commits:
> 
> - Adds a new HotSpot intrinsic candidate to the java.lang.Base64 class - decodeBlock(), and provides a flexible API for
>   the intrinsic.  The API is similar to the existing encodeBlock intrinsic.
> - Adds the code in HotSpot to check and martial the new intrinsic's arguments to the arch-specific intrinsic
>   implementation
> - Adds a Power64LE-specific implementation of the decodeBlock intrinsic.
> - Adds a JMH microbenchmark for both Base64 encoding and encoding.
> - Enhances the JTReg hotspot intrinsic "TestBase64.java" regression test to more fully test both decoding and encoding.

CoreyAshford has updated the pull request incrementally with one additional commit since the last revision:

  Per Martin Doerr's v4 review: fix regression, and speed up return time for buffers that are too small
  
   - Check for case where the result of subtacting 12 off of the source
     length produces a negative number.  To do this efficiently, I added the
     instruction definition for mcrxrx, which is implemented on Power9+.
  
   - Rearrange the code so that minimal initialization is performed before
     checking the size, so that the intrinsic can return quickly in the event
     that the buffer is too small to process.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/293/files
  - new: https://git.openjdk.java.net/jdk/pull/293/files/164fa2a9..b5acb75c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=293&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=293&range=03-04

  Stats: 54 lines in 3 files changed: 33 ins; 19 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/293.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/293/head:pull/293

PR: https://git.openjdk.java.net/jdk/pull/293

From github.com+51754783+coreyashford at openjdk.java.net  Mon Oct 12 21:41:38 2020
From: github.com+51754783+coreyashford at openjdk.java.net (CoreyAshford)
Date: Mon, 12 Oct 2020 21:41:38 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v4]
In-Reply-To: <u6HLR2PyvWgYbA58W3bCF4n38tpwQu2-ujPMvGpyyuo=.5a80f17c-83d5-4dc9-bad0-00e679fdd4be@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <45FtTQB1m6HyZSASY42STMkQffIWlVPibWn9_r00xYs=.daad2653-2571-491f-8dd7-5954fe4ece00@github.com>
 <u6HLR2PyvWgYbA58W3bCF4n38tpwQu2-ujPMvGpyyuo=.5a80f17c-83d5-4dc9-bad0-00e679fdd4be@github.com>
Message-ID: <7-p-Kc9lQyyuoWdNtmgbXbwkxsgk4oQGKmFSCcMpvnU=.97810c01-3200-4767-bbd4-35d53c2bc5ca@github.com>

On Mon, 12 Oct 2020 11:06:23 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> CoreyAshford has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - TestBase64.java: fix comment to correctly reflect actual intrinsic names.
>>    
>>    The intrinsic names that are visible with -XX:+PrintCompilation are encode
>>    and decode, rather than encodeBlock and decodeBlock.
>>  - stubGenerator_ppc.cpp: fix regression caused by change to using loop counter
>>    
>>    My original fix didn't account for the case where sl < block_size.  In the
>>    event sl < block_size, the shifted sl will become zero, so it should
>>    jump to the code that computes how much data was processed - 0 - and return.
>
> Test java/util/Base64/TestBase64.java failed on Power9:
> JavaTest Message: Test threw exception: java.lang.RuntimeException: Base64 decoding(String) failed!
> Seed from RandomFactory = -8714459054005749075L
> 
> java.lang.RuntimeException: Base64 decoding(String) failed!
> 	at TestBase64.checkEqual(TestBase64.java:523)
> 	at TestBase64.test(TestBase64.java:185)
> 	at TestBase64.main(TestBase64.java:61)

This latest push passes the regression test. I thought I had run it last time, though, which confuses me.

-------------

PR: https://git.openjdk.java.net/jdk/pull/293

From mchung at openjdk.java.net  Mon Oct 12 21:49:16 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Mon, 12 Oct 2020 21:49:16 GMT
Subject: RFR: 8188055: (ref) Add Reference::refersTo predicate [v2]
In-Reply-To: <9x0zaxknpYXGIvHun1CkLP0lEC8NQmPTnANxQKjhHF8=.907bdb15-2e2e-4f84-8fe4-ea4ed50534cd@github.com>
References: <D4HSg8FT20Eaxk5KJkkw0GgETSxRkBn1ipS3Dt0kPto=.e4bab078-2e04-4413-90cb-9bfafb2a6831@github.com>
 <Y1IHoNr8vO3OkCbEKw6ywXd4adik1yKKNIS4ABzF0d0=.d21f4183-ef4e-45ed-826d-6613215b6220@github.com>
 <9x0zaxknpYXGIvHun1CkLP0lEC8NQmPTnANxQKjhHF8=.907bdb15-2e2e-4f84-8fe4-ea4ed50534cd@github.com>
Message-ID: <DR2YKv3VavKKD-cpFyf6mCSYfaKq0KAGh2XDqBStkys=.895ba671-f63a-4ba3-b042-6568d647b4ab@github.com>

On Tue, 6 Oct 2020 09:19:32 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/ref/Reference.java line 361:
>> 
>>> 359:
>>> 360:     /* Type-erased implementation of refersTo(). */
>>> 361:     native boolean refersTo0(Object o);
>> 
>> Is there any reason why it can't use the parameter type like `refersTo0(T o)`?  Same for `PhantomReference::refersTo0(T
>> o)`
>
> But should `refersTo` takes a `T`? I mean - if I have a `Reference<?> ref`, the compiler will not let me query
> `ref.refersTo(o)`; is this what we want?

@dfuch I would expect the users of `refersTo` should know the type of the referent to be compared, i.e. it should know
the parameter type of a Reference object.   Do you have any specific use case in mind that you have a `Reference<?>
ref` but wants to compare a referent of unknown type?

-------------

PR: https://git.openjdk.java.net/jdk/pull/498

From github.com+51754783+coreyashford at openjdk.java.net  Mon Oct 12 22:03:20 2020
From: github.com+51754783+coreyashford at openjdk.java.net (CoreyAshford)
Date: Mon, 12 Oct 2020 22:03:20 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v4]
In-Reply-To: <7-p-Kc9lQyyuoWdNtmgbXbwkxsgk4oQGKmFSCcMpvnU=.97810c01-3200-4767-bbd4-35d53c2bc5ca@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <45FtTQB1m6HyZSASY42STMkQffIWlVPibWn9_r00xYs=.daad2653-2571-491f-8dd7-5954fe4ece00@github.com>
 <u6HLR2PyvWgYbA58W3bCF4n38tpwQu2-ujPMvGpyyuo=.5a80f17c-83d5-4dc9-bad0-00e679fdd4be@github.com>
 <7-p-Kc9lQyyuoWdNtmgbXbwkxsgk4oQGKmFSCcMpvnU=.97810c01-3200-4767-bbd4-35d53c2bc5ca@github.com>
Message-ID: <6Voyfr_s-ieyRA-8Rtvvpz7tkhhicA8sY2d2KTp3Kmw=.fa256bae-2143-4b43-bfea-5837ad31eb6a@github.com>

On Mon, 12 Oct 2020 21:38:36 GMT, CoreyAshford <github.com+51754783+CoreyAshford at openjdk.org> wrote:

>> Test java/util/Base64/TestBase64.java failed on Power9:
>> JavaTest Message: Test threw exception: java.lang.RuntimeException: Base64 decoding(String) failed!
>> Seed from RandomFactory = -8714459054005749075L
>> 
>> java.lang.RuntimeException: Base64 decoding(String) failed!
>> 	at TestBase64.checkEqual(TestBase64.java:523)
>> 	at TestBase64.test(TestBase64.java:185)
>> 	at TestBase64.main(TestBase64.java:61)
>
> This latest push passes the intrinsic regression test. I had run the intrinsic TestBase64 regression test on the
> previous push, but not the one in utils.  Interesting.  Somehow it didn't occur to me that there could be a problem
> there if the intrinsic TestBase64 test passed.  I will check into the other regression test.  Don't review this latest
> push just yet.

Ok, all is clear.  I just ran `jdk/java/util/Base64/TestBase64.java` which passes as well.  Please review again when
convenient.

-------------

PR: https://git.openjdk.java.net/jdk/pull/293

From igraves at openjdk.java.net  Mon Oct 12 22:04:25 2020
From: igraves at openjdk.java.net (Ian Graves)
Date: Mon, 12 Oct 2020 22:04:25 GMT
Subject: RFR: 8253459: Formatter treats index,
 width and precision > Integer.MAX_VALUE incorrectly [v3]
In-Reply-To: <3aYgWcp1IVMM0vQT5UMLSnc2JA1uK9cbtRe283RF37g=.fc2049ef-cdbe-4948-a24b-fdb88cc87a1c@github.com>
References: <3aYgWcp1IVMM0vQT5UMLSnc2JA1uK9cbtRe283RF37g=.fc2049ef-cdbe-4948-a24b-fdb88cc87a1c@github.com>
Message-ID: <AxF_1veebuzHCsrzUXZlCRirCmolcZhstDPIFlaelOc=.edc0b258-5749-4467-a22a-77762f66e969@github.com>

> The `java.util.Formatter` format specifies support for field widths, argument indexes, or precision lengths of a field
> that relate to the variadic arguments supplied to the formatter. These numbers are specified by integers, sometimes
> negative. For argument index, it's specified in the documentation that the highest allowed argument is limited by the
> largest possible index of an array (ie the largest possible variadic index), but for the other two it's not defined.
> Moreover, what happens when a number field in a string is too large or too small to be represented by a 32-bit integer
> type is not defined.  This fix adds documentation to specify what error behavior occurs during these cases.
> Additionally it adds an additional exception type to throw when an invalid argument index is observed.  A CSR will be
> required for this PR.

Ian Graves has updated the pull request with a new target base due to a merge or a rebase. The pull request now
contains four commits:

 - Updating docs specifying exception for 0 indices
 - Throwing exceptions for zeroth indexes
 - Updating docs
 - Updating docs and throwing errors accordingly

-------------

Changes: https://git.openjdk.java.net/jdk/pull/516/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=516&range=02
  Stats: 96 lines in 4 files changed: 88 ins; 0 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/516.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/516/head:pull/516

PR: https://git.openjdk.java.net/jdk/pull/516

From valeriep at openjdk.java.net  Mon Oct 12 23:00:12 2020
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Mon, 12 Oct 2020 23:00:12 GMT
Subject: RFR: 8252204: AArch64: Implement SHA3 accelerator/intrinsic [v5]
In-Reply-To: <xrytoJAOW673RPJmBM3ksB4CUliXJKtlnGKm_RaJ8hw=.ac80c083-a8b6-4f63-aead-503ad616d210@github.com>
References: <PJVtIubjiGKhCK81PIMhWuYxnR84DNieMDUGHdhHYZM=.ad903c93-c5e3-4614-9af1-d36bc33f735d@github.com>
 <nR6wQq3N8OnxHsAdAzQ2mIh6RZQ_b7H_M51Y9Eng3J4=.90d276d3-8b4b-427c-a075-bb7db96e37cb@github.com>
 <A5RkMquxaW1OuuiPTpD1wz7pBMcjxU7roLU5wD3cH8E=.0211f34f-eb8b-4b93-8072-82ac1a894019@github.com>
 <4NM17B6l4GvNgCbmmQTUcnfZTA6G-IEc85O8jH_q-xA=.63b10da7-bab7-44bc-a4c8-0a675aca45c0@github.com>
 <lcceWzrMnnFAHnmt-QcVqHWkn43cVpDDM0Q-5GuUCKk=.b0b4ea48-bdb1-4e4c-83e0-feaf5176685d@github.com>
 <xrytoJAOW673RPJmBM3ksB4CUliXJKtlnGKm_RaJ8hw=.ac80c083-a8b6-4f63-aead-503ad616d210@github.com>
Message-ID: <s94FyH3nX6-T-ul8Vz1uRGu21uU87Or-ivqKvUyNVM0=.ead952f1-04ae-4f9b-84e6-80a3b9b61aac@github.com>

On Mon, 12 Oct 2020 07:02:05 GMT, Fei Yang <fyang at openjdk.org> wrote:

> 
> 
> > I have looked at the java security changes, i.e. src/java.base/share/classes/sun/security/provider/SHA3.java. It looks
> > fine.
> 
> @valeriepeng : I see you are not listed under "Reviewers" commit message part, could you please press the magic
> button(s)(approve?) so you get the credit? Thanks.

It's fine, the part I reviewed is only a small part of the changes, so I will leave the reviewer approval upto the
hotspot team. Thanks,
Valerie

-------------

PR: https://git.openjdk.java.net/jdk/pull/207

From github.com+11685886+marcono1234 at openjdk.java.net  Mon Oct 12 23:08:20 2020
From: github.com+11685886+marcono1234 at openjdk.java.net (Marcono1234)
Date: Mon, 12 Oct 2020 23:08:20 GMT
Subject: RFR: 8251989: Hex formatting and parsing utility
In-Reply-To: <HSEn47GMS1K3g57mrTZeQk-WZHl3pKGHpX_OOf8VnsU=.740863c2-f9e4-43c4-b500-614aab4078b1@github.com>
References: <HSEn47GMS1K3g57mrTZeQk-WZHl3pKGHpX_OOf8VnsU=.740863c2-f9e4-43c4-b500-614aab4078b1@github.com>
Message-ID: <lv3X2v4KfUM8fxWZyX8_rwGa5wVnysBQjvqnAJaDYUU=.2b36709d-5547-411d-a609-fa465c4ce17f@github.com>

On Fri, 2 Oct 2020 15:18:04 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> java.util.HexFormat utility:
> 
>  - Format and parse hexadecimal strings, with parameters for delimiter, prefix, suffix and upper/lowercase
>  - Static factories and builder methods to create HexFormat copies with modified parameters.
>  - Consistent naming of methods for conversion of byte arrays to formatted strings and back: formatHex and parseHex
>  - Consistent naming of methods for conversion of primitive types: toHexDigits... and fromHexDigits...
>  - Prefix and suffixes now apply to each formatted value, not the string as a whole
>  - Using java.util.Appendable as a target for buffered conversions so output to Writers and PrintStreams
>    like System.out are supported in addition to StringBuilder. (IOExceptions are converted to unchecked exceptions)
>  - Immutable and thread safe, a "value-based" class
> 
> See the [HexFormat
> javadoc](http://cr.openjdk.java.net/~rriggs/8251989-hex-formatter/java.base/java/util/HexFormat.html) for details.
> Review comments and suggestions welcome.

This is a really useful addition! Utility classes for formatting bytes to hex have been re-invented so often already
that having this in the JDK would be really great.

Now that the OpenJDK project migrated to GitHub I took the opportunity and wrote this GitHub pull request review
(though I am not a OpenJDK contributor). Most things are formatting or documentation related. I hope these comments are
useful and are not too intrusive. Please let me know otherwise.

Also is it common practice to use `System.out` in JDK tests? In my opinion it often does not add much value once the
unit test implementation has been completed because the output is not checked during tests automatically anyways and
might only clutter the console output.

The tests are using `String.toUpperCase`, `toLowerCase` and `format` without `Locale` (therefore using the default
one). Does the test setup guarantee a constant default locale or would be better to include a `Locale` to make sure the
tests don't break for any unusual locale?

Has it been also considered to add support for parsing from a `Reader` to an `OutputStream` and from `InputStream` to
`Appendable` to support arbitrary length input and output?

Maybe it would also be good to mention for the method parsing and formatting `int`, `long`, ... in which byte order the
output is created.

src/java.naming/share/classes/com/sun/jndi/ldap/Filter.java line 32:

> 30:
> 31: import java.io.IOException;
> 32: import java.util.HexFormat;

This import appears to be unused

test/jdk/java/util/HexFormat/HexFormatTest.java line 406:

> 404:
> 405:             int byteVal = hex.fromHexDigits(byteStr);
> 406:             assert(byteStr.equals("7f"));

Why use regular `assert` statements in this test method? TestNG's methods likely yield more useful results.

src/java.base/share/classes/java/util/HexFormat.java line 45:

> 43:  * the {@code withXXX} methods return copies of {@code HexFormat}ters modified
> 44:  * {@link #withPrefix(String)}, {@link #withSuffix(String)}, {@link #withDelimiter(String)}
> 45:  * or choice of {@link #withUppercase()} or {@link #withLowercase()} parameters using

Would <code>withUpper<b>C</b>ase</code> and <code>withLower<b>C</b>ase</code> (captial "C") be better to be consistent
with `String.toUpperCase` and `Character.toUpperCase`?

src/java.base/share/classes/java/util/HexFormat.java line 77:

> 75:  * uppercase or lowercase digits, and the {@code suffix}.
> 76:  * The {@code delimiter} is required after each formatted value, except the last.
> 77:  * <p>

Is this `<p>` needed here? `@apiNote` below is a block tag so javadoc should put it in a separate paragraph anyways.

src/java.base/share/classes/java/util/HexFormat.java line 112:

> 110:  * <pre>{@code
> 111:  *     HexFormat formatFingerprint = HexFormat.ofDelimiter(":").withUppercase();
> 112:  *     byte[] bytes = { 0, 1, 2, 3, 124, 125, 126, 127};

Suggestion:

 *     byte[] bytes = {0, 1, 2, 3, 124, 125, 126, 127};

Space here is not consistent with other code snippets here.

src/java.base/share/classes/java/util/HexFormat.java line 148:

> 146:     private static final byte[] LOWERCASE_DIGITS = {
> 147:             '0' , '1' , '2' , '3' , '4' , '5' , '6' , '7',
> 148:             '8' , '9' , 'a' , 'b' , 'c' , 'd' , 'e' , 'f',

Suggestion:

            '0', '1', '2', '3', '4', '5', '6', '7',
            '8', '9', 'a', 'b', 'c', 'd', 'e', 'f',

src/java.base/share/classes/java/util/HexFormat.java line 182:

> 180:     /**
> 181:      * Returns a hexadecimal formatter with no delimiter and lowercase characters.
> 182:      * The hex characters are lowercase and the delimiter, prefix, and suffix are empty.

> The hex characters are lowercase

This is already mentioned in the sentence before.

src/java.base/share/classes/java/util/HexFormat.java line 195:

> 193:
> 194:     /**
> 195:      * Returns a hexadecimal formatter with a {@code delimiter} and lowercase letters.

Suggestion:

     * Returns a hexadecimal formatter with a {@code delimiter} and lowercase characters.
To be consistent with documentation of other methods.

src/java.base/share/classes/java/util/HexFormat.java line 203:

> 201:      *
> 202:      * @param delimiter a {@code delimiter}, non-null, may be empty
> 203:      * @return a {@link Formatter} with the {@code delimiter} and lowercase letters

Suggestion:

     * @return a {@link Formatter} with the {@code delimiter} and lowercase characters
To be consistent with documentation of other methods.

src/java.base/share/classes/java/util/HexFormat.java line 221:

> 219:      * Returns a copy of this {@code HexFormat} with the {@code prefix}.
> 220:      *
> 221:      * @param prefix a prefix, non-null, may be empty

Suggestion:

     * @param prefix a {@code prefix}, non-null, may be empty
For consistency with other methods.

src/java.base/share/classes/java/util/HexFormat.java line 252:

> 250:      * The lowercase hexadecimal characters are {@code "0-9", "a-f"}.
> 251:      *
> 252:      * @return a copy of this {@code HexFormat} with lowercase hex characters

Suggestion:

     * @return a copy of this {@code HexFormat} with lowercase hexadecimal characters
Either write "hexadecimal" here or change the documentation for `withUppercase()` to use "hex".

src/java.base/share/classes/java/util/HexFormat.java line 261:

> 259:      * Returns the {@code delimiter} between hexadecimal values in a formatted byte array.
> 260:      *
> 261:      * @return return the {@code delimiter}, non-null, may be empty {@code ""}

Suggestion:

     * @return the {@code delimiter}, non-null, may be empty {@code ""}
"return" here and for other methods is redundant because the Standard Doclet already writes "Returns", so you end up
with "Returns return". (Also note that the other methods use "return**s**" (with "s" at the end), which is not
consistent in case you choose to keep the redundant "return")

src/java.base/share/classes/java/util/HexFormat.java line 287:

> 285:     /**
> 286:      * Returns {@code true} if the hexadecimal digits will be uppercase,
> 287:      *          otherwise {@code false}.

Suggestion:

     * otherwise {@code false}.

src/java.base/share/classes/java/util/HexFormat.java line 302:

> 300:      *
> 301:      * The behavior is equivalent to
> 302:      * {@link #formatHex(byte[], int, int) format(bytes, 0, bytes.length))}.

Suggestion:

     * {@link #formatHex(byte[], int, int) formatHex(bytes, 0, bytes.length))}.

src/java.base/share/classes/java/util/HexFormat.java line 324:

> 322:      */
> 323:     public String formatHex(byte[] bytes, int index, int length) {
> 324:         Objects.requireNonNull(bytes,"bytes");

Suggestion:

        Objects.requireNonNull(bytes, "bytes");

src/java.base/share/classes/java/util/HexFormat.java line 346:

> 344:      * A {@code delimiter} appears after each formatted value, except the last.
> 345:      * The behavior is equivalent to
> 346:      * {@link #formatHex(byte[]) out.append(format(bytes))}.

Suggestion:

     * {@link #formatHex(byte[]) out.append(hexFormat.formatHex(bytes))}.
Could possibly also omit the `hexFormat.`; though if you decide to use it, some of the other examples have to be
adjusted as well.

src/java.base/share/classes/java/util/HexFormat.java line 364:

> 362:      * A {@code delimiter} appears after each formatted value, except the last.
> 363:      * The behavior is equivalent to
> 364:      * {@link #formatHex(byte[], int, int)  out.append(format(bytes, index, length))}.

Suggestion:

     * {@link #formatHex(byte[], int, int)  out.append(hexFormat.formatHex(bytes, index, length))}.
Could possibly also omit the `hexFormat.`; though if you decide to use it, some of the other examples have to be
adjusted as well.

src/java.base/share/classes/java/util/HexFormat.java line 457:

> 455:      * A {@code delimiter} appears after each formatted value, except the last.
> 456:      * The {@code delimiter}s, {@code prefix}es, and {@code suffix}es strings must be present;
> 457:      * they may be empty strings.

This is a little bit irritating because the HexFormat dictates whether they may be empty. Having this statement here
might sound as if the caller could somehow influence it. Maybe it should mention that this depends on the HexFormat.

(Applies to the other methods as well)

src/java.base/share/classes/java/util/HexFormat.java line 461:

> 459:      *
> 460:      * @param string a string containing the byte values with {@code prefix}, hexadecimal digits, {@code suffix},
> 461:      *            and delimiters

Suggestion:

     *            and {@code delimiter}s
For consistency with the other documentation

src/java.base/share/classes/java/util/HexFormat.java line 543:

> 541:      *
> 542:      * @param chars a char array range containing an even number of hex digits,
> 543:      *          {@code delimiters}, {@code prefix}, and {@code suffix}.

Suggestion:

     *          {@code delimiter}s, {@code prefix}, and {@code suffix}.
For consistency

src/java.base/share/classes/java/util/HexFormat.java line 482:

> 480:      *
> 481:      * @param string a string range containing hex digits,
> 482:      *           {@code delimiters}, {@code prefix}, and {@code suffix}.

Suggestion:

     *           {@code delimiter}s, {@code prefix}, and {@code suffix}.
For consistency

src/java.base/share/classes/java/util/HexFormat.java line 462:

> 460:      * @param string a string containing the byte values with {@code prefix}, hexadecimal digits, {@code suffix},
> 461:      *            and delimiters
> 462:      * @return a byte array

It might be good to be a little bit more verbose here because the method signature shows that the return type is
`byte[]` so this documentation does not add that much information. Maybe something like "a byte array representing the
parsed hexadecimal string" would be better?

(Applies to the other methods as well)

src/java.base/share/classes/java/util/HexFormat.java line 488:

> 486:      * @throws IllegalArgumentException if the string length is not valid or
> 487:      *          the string contains non-hex characters,
> 488:      *          or the {@code delimiter}, {@code prefix}, or {@code suffix} are not found

Might be good to make this consistent, `parseHex(CharSequence)` says:
if the {@code prefix} or {@code suffix} is not present for each byte value,
the byte values are not hexadecimal characters, or if the {@code delimiter} is not present
after all but the last byte value.

src/java.base/share/classes/java/util/HexFormat.java line 508:

> 506:         if (string.length() < valueChars || (string.length() - valueChars) % stride != 0)
> 507:             throw new IllegalArgumentException("extra or missing delimiters " +
> 508:                     "or values consisting of prefix, two hex digits, and suffix");

> extra or missing delimiters or values consisting of prefix, two hex digits, and suffix

Sounds a little bit like "values consisting of prefix, two hex digits and suffix" is an error condition, while the
sentence probably means valid values being missing is the error condition. It might be clearer if reworded, e.g. like
this:
> extra or missing delimiters, prefix, suffx or hex digits

Or something general like "malformed formatted hex string".

src/java.base/share/classes/java/util/HexFormat.java line 614:

> 612:      *
> 613:      * @param value a value, only bits {@code 4-7} of the value are used
> 614:      * @return the hex character for the bits {@code 4-7} of the value are used

Suggestion:

     * @return the hex character for the bits {@code 4-7} of the value

src/java.base/share/classes/java/util/HexFormat.java line 650:

> 648:      * @throws UncheckedIOException if an I/O exception occurs appending to the output
> 649:      */
> 650:     public Appendable toHexDigits(Appendable out, byte value) {

Why not use a type parameter here for the `Appendable` similar to the other methods?

src/java.base/share/classes/java/util/HexFormat.java line 765:

> 763:      * The {@code delimiter}, {@code prefix} and {@code suffix} are not used.
> 764:      *
> 765:      * @param value an {@code long} value

Suggestion:

     * @param value a {@code long} value

src/java.base/share/classes/java/util/HexFormat.java line 760:

> 758:
> 759:     /**
> 760:      * Returns up to sixteen hex characters for the {@code long} value.

Might be good to clearify that the `digits` starts with the high bytes of the `long`.

src/java.base/share/classes/java/util/HexFormat.java line 836:

> 834:      *          otherwise {@code false}
> 835:      */
> 836:     public boolean isHexDigit(int ch) {

Should this method be `static`? Or otherwise should it consider the `uppercase()` setting?
(Same for `fromHexDigit` and all the other subsequent methods)

These methods being instance methods is likely pretty confusing because they are unrelated to the HexFormat instance
and makes using them cumbersome because the user has to create a HexFormat instance first.

src/java.base/share/classes/java/util/HexFormat.java line 902:

> 900:      * characters.
> 901:      * The characters in the range from {@code index} to {@code index + length - 1},
> 902:      * inclusive, must be valid hex length according to {@link #fromHexDigit(int)}.

Suggestion:

     * inclusive, must be valid hex digits according to {@link #fromHexDigit(int)}.

src/java.base/share/classes/java/util/HexFormat.java line 902:

> 900:      * characters.
> 901:      * The characters in the range from {@code index} to {@code index + length - 1},
> 902:      * inclusive, must be valid hex length according to {@link #fromHexDigit(int)}.

Maybe would be better to specify the "exclusive" value. Because providing a `length` of 0 is allowed in which case this
statement would be incorrect (`index + 0 - 1`). (same for `fromHexDigitsToLong`)

src/java.base/share/classes/java/util/HexFormat.java line 996:

> 994:
> 995:     /**
> 996:      * Returns a hashcode for this {@code HexFormat} that is consistent with

* [...] that is consistent with
* {@link #equals(Object) equals}.
This information might be redundant; the general contract of `Object.hashCode()` requires that.

src/java.base/share/classes/java/util/HexFormat.java line 1015:

> 1013:      */
> 1014:     @Override
> 1015:     public String toString() {

Might be useful to also include the class name?

src/java.base/share/classes/java/util/HexFormat.java line 521:

> 519:                 throw new IllegalArgumentException("input contains non-hex characters");
> 520:             bytes[i] = (byte) v;
> 521:             HexFormat.checkLiteral(string, offset + 2, between);

Suggestion:

            checkLiteral(string, offset + 2, between);

src/java.base/share/classes/java/util/HexFormat.java line 206:

> 204:      */
> 205:     public static HexFormat ofDelimiter(String delimiter) {
> 206:         return new HexFormat(delimiter, "", "", HexFormat.LOWERCASE_DIGITS);

Suggestion:

        return new HexFormat(delimiter, "", "", LOWERCASE_DIGITS);
Might be good to drop the type qualifier here (and for other usages) or for consistency add the type qualifier where it
is currently not used.

-------------

PR: https://git.openjdk.java.net/jdk/pull/482

From github.com+11685886+marcono1234 at openjdk.java.net  Mon Oct 12 23:08:21 2020
From: github.com+11685886+marcono1234 at openjdk.java.net (Marcono1234)
Date: Mon, 12 Oct 2020 23:08:21 GMT
Subject: RFR: 8251989: Hex formatting and parsing utility
In-Reply-To: <LvxxngI4eIpf81LEUfsDfvtNypqxeHwS4-ioIubCFPs=.e30963eb-2ccc-4278-8ce8-f44fccee1a83@github.com>
References: <HSEn47GMS1K3g57mrTZeQk-WZHl3pKGHpX_OOf8VnsU=.740863c2-f9e4-43c4-b500-614aab4078b1@github.com>
 <E4uO8-HUWk8Yyetoq_zp-U3QsEUsA2cWMWs23AcTAss=.25b2feca-d571-44ae-9871-74455fe32619@github.com>
 <LvxxngI4eIpf81LEUfsDfvtNypqxeHwS4-ioIubCFPs=.e30963eb-2ccc-4278-8ce8-f44fccee1a83@github.com>
Message-ID: <hJhoOP4Do0TUpY0wCK16mDWx9vGrYxhWeHnT69MU4uM=.23b88d65-3fae-495b-a88f-b478af3ffa93@github.com>

On Fri, 2 Oct 2020 20:19:11 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/HexFormat.java line 290:
>> 
>>> 288:      * @return returns {@code true} if the hexadecimal digits will be uppercase,
>>> 289:      *          otherwise {@code false}
>>> 290:      */
>> 
>> Can someone choose their own `digits`? If not, how about "=="?
>
> I don't think it would be called HexFormat doing Hexadecimal conversions if it could be an arbitrary set of digits.
> The Arrays.equals implementation contains the == test so its implementers choice.

Though on the other hand `HexFormat.toString()` *does* use `==` (but `equals` does not; could possibly also improve
`hashCode` as well then). Might be good if that was consistent.

-------------

PR: https://git.openjdk.java.net/jdk/pull/482

From psandoz at openjdk.java.net  Mon Oct 12 23:12:36 2020
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Mon, 12 Oct 2020 23:12:36 GMT
Subject: RFR: 8223347: Integration of Vector API (Incubator) [v2]
In-Reply-To: <-PE4TwXgvq2bemAn_8csjn4_j7zoAolnQz6QQt3z0Wk=.eaa9999f-0713-4349-b31d-934717aa37a1@github.com>
References: <-PE4TwXgvq2bemAn_8csjn4_j7zoAolnQz6QQt3z0Wk=.eaa9999f-0713-4349-b31d-934717aa37a1@github.com>
Message-ID: <DFpn8zuu9arqVbtNqnkhFVevazRK5dkMQziPdyuKvmE=.a50230d3-795d-4ae1-9520-5eb01124a75d@github.com>

> This pull request is for integration of the Vector API. It was previously reviewed under conditions when mercurial was
> used for the source code control system. Review threads can be found here (searching for issue number 8223347 in the
> title):  https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-April/thread.html
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-May/thread.html
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-July/thread.html
> 
> If mercurial was still being used the code would be pushed directly, once the CSR is approved. However, in this case a
> pull request is required and needs explicit reviewer approval. Between the final review and this pull request no code
> has changed, except for that related to merging.

Paul Sandoz has updated the pull request with a new target base due to a merge or a rebase. The pull request now
contains seven commits:

 - HotspotIntrinsicCandidate to IntrinsicCandidate
 - Merge master
 - Fix permissions
 - Fix permissions
 - Merge master
 - Vector API new files
 - Integration of Vector API (Incubator)

-------------

Changes: https://git.openjdk.java.net/jdk/pull/367/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=367&range=01
  Stats: 295150 lines in 336 files changed: 292957 ins; 1062 del; 1131 mod
  Patch: https://git.openjdk.java.net/jdk/pull/367.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/367/head:pull/367

PR: https://git.openjdk.java.net/jdk/pull/367

From github.com+1290376+johnlinp at openjdk.java.net  Tue Oct 13 08:19:24 2020
From: github.com+1290376+johnlinp at openjdk.java.net (John Lin)
Date: Tue, 13 Oct 2020 08:19:24 GMT
Subject: RFR: 8247402: rewrite the implementation requirements for
 Map::compute()
Message-ID: <as4mWIy4TmbEz5C238FHXEL6-gynMYyxaQLQqGV_wVM=.6bac3533-5459-4ad7-8d45-c00e3bfdd121@github.com>

This is from the mailing list: http://mail.openjdk.java.net/pipermail/core-libs-dev/2020-June/067213.html

-------------

Commit messages:
 - 8247402: rewrite the implementation requirements for Map::compute()

Changes: https://git.openjdk.java.net/jdk/pull/451/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=451&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8247402
  Stats: 10 lines in 1 file changed: 1 ins; 6 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/451.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/451/head:pull/451

PR: https://git.openjdk.java.net/jdk/pull/451

From dfuchs at openjdk.java.net  Tue Oct 13 08:52:10 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Tue, 13 Oct 2020 08:52:10 GMT
Subject: RFR: 8188055: (ref) Add Reference::refersTo predicate [v2]
In-Reply-To: <DR2YKv3VavKKD-cpFyf6mCSYfaKq0KAGh2XDqBStkys=.895ba671-f63a-4ba3-b042-6568d647b4ab@github.com>
References: <D4HSg8FT20Eaxk5KJkkw0GgETSxRkBn1ipS3Dt0kPto=.e4bab078-2e04-4413-90cb-9bfafb2a6831@github.com>
 <Y1IHoNr8vO3OkCbEKw6ywXd4adik1yKKNIS4ABzF0d0=.d21f4183-ef4e-45ed-826d-6613215b6220@github.com>
 <9x0zaxknpYXGIvHun1CkLP0lEC8NQmPTnANxQKjhHF8=.907bdb15-2e2e-4f84-8fe4-ea4ed50534cd@github.com>
 <DR2YKv3VavKKD-cpFyf6mCSYfaKq0KAGh2XDqBStkys=.895ba671-f63a-4ba3-b042-6568d647b4ab@github.com>
Message-ID: <mkn_t3hsL4mlCOfO5ahZOMbp8i_LMOHwJALA_bNjHIk=.d8031a91-ed13-4882-925f-ea8a9e634198@github.com>

On Mon, 12 Oct 2020 21:46:37 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> But should `refersTo` takes a `T`? I mean - if I have a `Reference<?> ref`, the compiler will not let me query
>> `ref.refersTo(o)`; is this what we want?
>
> @dfuch I would expect the users of `refersTo` should know the type of the referent to be compared, i.e. it should know
> the parameter type of a Reference object.   Do you have any specific use case in mind that you have a `Reference<?>
> ref` but wants to compare a referent of unknown type?

@mlchung  I have often used a `Reference<?>` in tests - but my main usage there would be to call `ref.refersTo(null)`
which works in all cases. My main concern here however is that using `T` in `refersTo` seems to go against the
advertised usage of the method - I mean - if I have an object `obj` of type unknown, I can always do `obj == ref.get()`
whatever the parameter type of `ref` is. But I won't be able to call `ref.refersTo(obj)` unless I use raw types and
suppress warnings. So I just wanted to check that this was intentional.

-------------

PR: https://git.openjdk.java.net/jdk/pull/498

From fweimer at redhat.com  Tue Oct 13 08:58:20 2020
From: fweimer at redhat.com (Florian Weimer)
Date: Tue, 13 Oct 2020 10:58:20 +0200
Subject: core-libs-dev email delivery (is broken for external subscribers)
In-Reply-To: <1d35ad95-a21d-d0a7-57cf-f5d1f05913d5@oracle.com> (Tim Bell's
 message of "Mon, 12 Oct 2020 10:38:42 -0700")
References: <878scdx8b7.fsf@mid.deneb.enyo.de>
 <1d35ad95-a21d-d0a7-57cf-f5d1f05913d5@oracle.com>
Message-ID: <87eem2y02b.fsf@oldenburg2.str.redhat.com>

* Tim Bell:

> On 2020-10-11 05:21, Florian Weimer wrote:
>> We used to have a problem where hotspot-dev mail did not get delivered
>> to list subscribers.  Is it possible that a similar issue now affects
>> core-libs-dev?  I don't receive mail on two separate mail accounts,
>> with completely different infrastructure on my end.
>
> I reproduced this issue with my external mailbox.  My corporate
> internal mailbox receives core-libs-dev messages OK.
>
> This does appear to be a repeat of the earlier issue with
> hotspot-dev. I filed an internal problem report and I will escalate.
>
> Until this issue is resolved, the workaround is to keep an eye on the
> message archive at:
>
>   https://mail.openjdk.java.net/pipermail/core-libs-dev/

Thanks!

FYI, jdk-dev seems to have the same issue.  Would you please make sure
that it is also covered by the ticket?

Florian
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill


From prappo at openjdk.java.net  Tue Oct 13 09:33:17 2020
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Tue, 13 Oct 2020 09:33:17 GMT
Subject: RFR: 8247402: rewrite the implementation requirements for
 Map::compute()
In-Reply-To: <as4mWIy4TmbEz5C238FHXEL6-gynMYyxaQLQqGV_wVM=.6bac3533-5459-4ad7-8d45-c00e3bfdd121@github.com>
References: <as4mWIy4TmbEz5C238FHXEL6-gynMYyxaQLQqGV_wVM=.6bac3533-5459-4ad7-8d45-c00e3bfdd121@github.com>
Message-ID: <9yJU0Hcx60tzcdSIs7KWSVAOvOgaspFWabjMNTbE5cY=.f8815878-be89-44d6-8e70-b5aaec81fe92@github.com>

On Thu, 1 Oct 2020 07:07:24 GMT, John Lin <github.com+1290376+johnlinp at openjdk.org> wrote:

> This is from the mailing list: http://mail.openjdk.java.net/pipermail/core-libs-dev/2020-June/067213.html

The proposed implementation behaves differently from the existing implementation in the case of `null` value. That is,
when `map.containsKey(key) == true && map.get(key) == null`. The difference is that the proposed implementation will
remove the `(key, null)` mapping if `newValue == null`, whereas the existing implementation will not.

-------------

PR: https://git.openjdk.java.net/jdk/pull/451

From avoitylov at openjdk.java.net  Tue Oct 13 09:39:23 2020
From: avoitylov at openjdk.java.net (Aleksei Voitylov)
Date: Tue, 13 Oct 2020 09:39:23 GMT
Subject: Integrated: JDK-8247589: Implementation of Alpine Linux/x64 Port
In-Reply-To: <bjBywiEZ6tEHsG5xi2185_J-tduz4ezP8r6wVKbX1lY=.f6574f6f-be11-4d7c-8ebc-50b24ad8015d@github.com>
References: <bjBywiEZ6tEHsG5xi2185_J-tduz4ezP8r6wVKbX1lY=.f6574f6f-be11-4d7c-8ebc-50b24ad8015d@github.com>
Message-ID: <1UYbWcHetnzMfkPLjmtJp2XUoUdhpGmVBOkPRZ1JhqM=.56033536-ce88-45b7-8d9d-3570819bd063@github.com>

On Mon, 7 Sep 2020 11:23:28 GMT, Aleksei Voitylov <avoitylov at openjdk.org> wrote:

> continuing the review thread from here https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-September/068546.html
> 
>> The download side of using JNI in these tests is that it complicates the
>> setup a bit for those that run jtreg directly and/or just build the JDK
>> and not the test libraries. You could reduce this burden a bit by
>> limiting the load library/isMusl check to Linux only, meaning isMusl
>> would not be called on other platforms.
>>
>> The alternative you suggest above might indeed be better. I assume you
>> don't mean splitting the tests but rather just adding a second @test
>> description so that the vm.musl case runs the test with a system
>> property that allows the test know the expected load library path behavior.
> 
> I have updated the PR to split the two tests in multiple @test s.
> 
>> The updated comment in java_md.c in this looks good. A minor comment on
>> Platform.isBusybox is Files.isSymbolicLink returning true implies that
>> the link exists so no need to check for exists too. Also the
>> if-then-else style for the new class in ProcessBuilder/Basic.java is
>> inconsistent with the rest of the test so it stands out.
> 
> Thank you, these changes are done in the updated PR.
> 
>> Given the repo transition this weekend then I assume you'll create a PR
>> for the final review at least. Also I see JEP 386 hasn't been targeted
>> yet but I assume Boris, as owner, will propose-to-target and wait for it
>> to be targeted before it is integrated.
> 
> Yes. How can this be best accomplished with the new git workflow?
> - we can continue the review process till the end and I will request the integration to happen only after the JEP is
>   targeted. I guess this step is now done by typing "slash integrate" in a comment.
> - we can pause the review process now until the JEP is targeted.
> 
> In the first case I'm kindly asking the Reviewers who already chimed in on that to re-confirm the review here.

This pull request has now been integrated.

Changeset: 63009f90
Author:    Aleksei Voitylov <avoitylov at openjdk.org>
Committer: Alexander Scherbatiy <alexsch at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/63009f90
Stats:     403 lines in 30 files changed: 348 ins; 17 del; 38 mod

8247589: Implementation of Alpine Linux/x64 Port

Co-authored-by: Mikael Vidstedt <mikael at openjdk.org>
Co-authored-by: Alexander Scherbatiy <alexsch at openjdk.org>
Co-authored-by: Axel Siebenborn <asiebenborn at openjdk.org>
Co-authored-by: Aleksei Voitylov <avoitylov at openjdk.org>
Reviewed-by: alanb, erikj, dholmes

-------------

PR: https://git.openjdk.java.net/jdk/pull/49

From avoitylov at openjdk.java.net  Tue Oct 13 09:54:24 2020
From: avoitylov at openjdk.java.net (Aleksei Voitylov)
Date: Tue, 13 Oct 2020 09:54:24 GMT
Subject: RFR: JDK-8247589: Implementation of Alpine Linux/x64 Port [v6]
In-Reply-To: <DR0fMaPzoXlQ5R01RYiE-GqlkHTZhGGximwCU3wxeT0=.95418767-9074-483e-b2f5-b6c48b1c66c7@github.com>
References: <bjBywiEZ6tEHsG5xi2185_J-tduz4ezP8r6wVKbX1lY=.f6574f6f-be11-4d7c-8ebc-50b24ad8015d@github.com>
 <c1MlKKCyF8tYh2i3go62f96qP4Ox49ocnBZgmtBHjtk=.8dd586d0-becb-405e-adfe-e56e2db0636e@github.com>
 <DR0fMaPzoXlQ5R01RYiE-GqlkHTZhGGximwCU3wxeT0=.95418767-9074-483e-b2f5-b6c48b1c66c7@github.com>
Message-ID: <ESHAd_jeMGg2qHqajSN9Ce9dYFsZgIXc505txYe7ud4=.6471d4b0-a061-4131-a145-46c2a5c03cc2@github.com>

On Fri, 9 Oct 2020 06:02:04 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Aleksei Voitylov 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 JDK-8247589
>>  - JDK-8247589: Implementation of Alpine Linux/x64 Port
>>  - JDK-8247589: Implementation of Alpine Linux/x64 Port
>
> Marked as reviewed by dholmes (Reviewer).

Thanks everyone!

-------------

PR: https://git.openjdk.java.net/jdk/pull/49

From mcimadamore at openjdk.java.net  Tue Oct 13 10:27:43 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 13 Oct 2020 10:27:43 GMT
Subject: RFR: 8254162: Implementation of Foreign-Memory Access API (Third
 Incubator) [v9]
In-Reply-To: <IngRk57F78UN3yySfo6IABbdwnMogGNdYrykh_3em-c=.b81f7478-015c-45ed-9788-58d7519a2770@github.com>
References: <IngRk57F78UN3yySfo6IABbdwnMogGNdYrykh_3em-c=.b81f7478-015c-45ed-9788-58d7519a2770@github.com>
Message-ID: <NnTkPDSDqywi5oUfUwnY2hgrDa54xciAHExHlO9sbww=.37ffdadb-c57c-44c3-9834-e9c23baca3dc@github.com>

> This patch contains the changes associated with the third incubation round of the foreign memory access API incubation
> (see JEP 393 [1]). This iteration focus on improving the usability of the API in 3 main ways:
> * first, by providing a way to obtain truly *shared* segments, which can be accessed and closed concurrently from
>   multiple threads
> * second, by providing a way to register a memory segment against a `Cleaner`, so as to have some (optional) guarantee
>   that the memory will be deallocated, eventually
> * third, by not requiring users to dive deep into var handles when they first pick up the API; a new `MemoryAccess` class
>   has been added, which defines several useful dereference routines; these are really just thin wrappers around memory
>   access var handles, but they make the barrier of entry for using this API somewhat lower.
> 
> A big conceptual shift that comes with this API refresh is that the role of `MemorySegment` and `MemoryAddress` is not
> the same as it used to be; it used to be the case that a memory address could (sometimes, not always) have a back link
> to the memory segment which originated it; additionally, memory access var handles used `MemoryAddress` as a basic unit
> of dereference.  This has all changed as per this API refresh;  now a `MemoryAddress` is just a dumb carrier which
> wraps a pair of object/long addressing coordinates; `MemorySegment` has become the star of the show, as far as
> dereferencing memory is concerned. You cannot dereference memory if you don't have a segment. This improves usability
> in a number of ways - first, it is a lot easier to wrap native addresses (`long`, essentially) into a `MemoryAddress`;
> secondly, it is crystal clear what a client has to do in order to dereference memory: if a client has a segment, it can
> use that; otherwise, if the client only has an address, it will have to create a segment *unsafely* (this can be done
> by calling `MemoryAddress::asSegmentRestricted`).  A list of the API, implementation and test changes is provided
> below. If  you have any questions, or need more detailed explanations, I (and the  rest of the Panama team) will be
> happy to point at existing discussions,  and/or to provide the feedback required.   A big thank to Erik Osterlund,
> Vladimir Ivanov and David Holmes, without whom the work on shared memory segment would not have been possible; also I'd
> like to thank Paul Sandoz, whose insights on API design have been very helpful in this journey.  Thanks  Maurizio
> Javadoc:   http://cr.openjdk.java.net/~mcimadamore/8254162_v1/javadoc/jdk/incubator/foreign/package-summary.html
> Specdiff:
> 
> http://cr.openjdk.java.net/~mcimadamore/8254162_v1/specdiff/jdk/incubator/foreign/package-summary.html
> 
> CSR:
> 
> https://bugs.openjdk.java.net/browse/JDK-8254163
> 
> 
> 
> ### API Changes
> 
> * `MemorySegment`
>   * drop factory for restricted segment (this has been moved to `MemoryAddress`, see below)
>   * added a no-arg factory for a native restricted segment representing entire native heap
>   * rename `withOwnerThread` to `handoff`
>   * add new `share` method, to create shared segments
>   * add new `registerCleaner` method, to register a segment against a cleaner
>   * add more helpers to create arrays from a segment e.g. `toIntArray`
>   * add some `asSlice` overloads (to make up for the fact that now segments are more frequently used as cursors)
>   * rename `baseAddress` to `address` (so that `MemorySegment` can implement `Addressable`)
> * `MemoryAddress`
>   * drop `segment` accessor
>   * drop `rebase` method and replace it with `segmentOffset` which returns the offset (a `long`) of this address relative
>     to a given segment
> * `MemoryAccess`
>   * New class supporting several static dereference helpers; the helpers are organized by carrier and access mode, where a
>     carrier is one of the usual suspect (a Java primitive, minus `boolean`); the access mode can be simple (e.g. access
>     base address of given segment), or indexed, in which case the accessor takes a segment and either a low-level byte
>     offset,or a high level logical index. The classification is reflected in the naming scheme (e.g. `getByte` vs.
>     `getByteAtOffset` vs `getByteAtIndex`).
> * `MemoryHandles`
>   * drop `withOffset` combinator
>   * drop `withStride` combinator
>   * the basic memory access handle factory now returns a var handle which takes a `MemorySegment` and a `long` - from which
>     it is easy to derive all the other handles using plain var handle combinators.
> * `Addressable`
>   * This is a new interface which is attached to entities which can be projected to a `MemoryAddress`. For now, both
>     `MemoryAddress` and `MemorySegment` implement it; we have plans, with JEP 389 [2] to add more implementations. Clients
>     can largely ignore this interface, which comes in really handy when defining native bindings with tools like `jextract`.
> * `MemoryLayouts`
>   * A new layout, for machine addresses, has been added to the mix.
> 
> 
> 
> ### Implementation changes
> 
> There are two main things to discuss here: support for shared segments, and the general simplification of the memory
> access var handle support.
> #### Shared segments
> 
> The support for shared segments cuts in pretty deep in the VM. Support for shared segments is notoriously hard to
> achieve, at least in a way that guarantees optimal access performances. This is caused by the fact that, if a segment
> is shared, it would be possible for a thread to close it while another is accessing it.  After considering several
> options (see [3]), we zeroed onto an approach which is inspired by an happy idea that Andrew Haley had (and that he
> reminded me of at this year OpenJDK committer workshop - thanks!). The idea is that if we could *freeze* the world
> (e.g. with a GC pause), while a segment is closed, we could then prevent segments from being accessed concurrently to a
> close operation. For this to work, it  is crucial that no GC safepoints can occur between a segment liveness check and
> the access itself (otherwise it would be possible for the accessing thread to stop just right before an unsafe call).
> It also relies on the fact that hotspot/C2 should not be able to propagate loads across safepoints.  Sadly, none of
> these conditions seems to be valid in the current implementation, so we needed to resort to a bit of creativity. First,
> we noted that, if we could mark so called *scoped* method with an annotation, it would be very simply to check as to
> whether a thread was in the middle of a scoped method when we stopped the world for a close operation (btw, instead of
> stopping the world, we do a much more efficient, thread-local polling, thanks to JEP 312 [4]).  The question is, then,
> once we detect that a thread is accessing the very segment we're about to close, what should happen? We first
> experimented with a solution which would install an *asynchronous* exception on the accessing thread, thus making it
> fail. This solution has some desirable properties, in that a `close` operation always succeeds. Unfortunately the
> machinery for async exceptions is a bit fragile (e.g. not all the code in hotspot checks for async exceptions); to
> minimize risks, we decided to revert to a simpler strategy, where `close` might fail when it finds that another thread
> is accessing the segment being closed.  As written in the javadoc, this doesn't mean that clients should just catch and
> try again; an exception on `close` is a bug in the user code, likely arising from lack of synchronization, and should
> be treated as such.  In terms of gritty implementation, we needed to centralize memory access routines in a single
> place, so that we could have a set of routines closely mimicking the primitives exposed by `Unsafe` but which, in
> addition, also provided a liveness check. This way we could mark all these routines with the special `@Scoped`
> annotation, which tells the VM that something important is going on.  To achieve this, we created a new (autogenerated)
> class, called `ScopedMemoryAccess`. This class contains all the main memory access primitives (including bulk access,
> like `copyMemory`, or `setMemory`), and accepts, in addition to the access coordinates, also a scope object, which is
> tested before access. A reachability fence is also thrown in the mix to make sure that the scope is kept alive during
> access (which is important when registering segments against cleaners).  Of course, to make memory access safe, memory
> access var handles, byte buffer var handles, and byte buffer API should use the new `ScopedMemoryAccess` class instead
> of unsafe, so that a liveness check can be triggered (in case a scope is present).  `ScopedMemoryAccess` has a
> `closeScope` method, which initiates the thread-local handshakes, and returns `true` if the handshake completed
> successfully.  The implementation of `MemoryScope` (now significantly simplified from what we had before), has two
> implementations, one for confined segments and one for shared segments; the main difference between the two is what
> happens when the scope is closed; a confined segment sets a boolean flag to false, and returns, whereas a shared
> segment goes into a `CLOSING` state, then starts the handshake, and then updates the state again, to either `CLOSED` or
> `ALIVE` depending on whether the handshake was successful or not. Note that when a shared segment is in the `CLOSING`
> state, `MemorySegment::isAlive` will still return `true`, while the liveness check upon memory access will fail.  ####
> Memory access var handles overhaul  The key realization here was that if all memory access var handles took a
> coordinate pair of `MemorySegment` and `long`, all other access types could be derived from this basic var handle
> form.  This allowed us to remove the on-the-fly var handle generation, and to simply derive structural access var
> handles (such as those obtained by calling `MemoryLayout::varHandle`) using *plain* var handle combinators, so that
> e.g. additional offset is injected into a base memory access var handle.  This also helped in simplifying the
> implementation by removing the special `withStride` and `withOffset` combinators, which previously needed low-level
> access on the innards of the memory access var handle. All that code is now gone.  #### Test changes  Not much to see
> here - most of the tests needed to be updated because of the API changes. Some were beefed up (like the array test,
> since now segments can be projected into many different kinds of arrays). A test has been added to test the `Cleaner`
> functionality, and another stress test has been added for shared segments (`TestHandshake`). Some of the
> microbenchmarks also needed some tweaks - and some of them were also updated to also test performance in the shared
> segment case.  [1] - https://openjdk.java.net/jeps/393 [2] - https://openjdk.java.net/jeps/389 [3] -
> https://mail.openjdk.java.net/pipermail/panama-dev/2020-May/009004.html [4] - https://openjdk.java.net/jeps/312

Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The incremental
webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits
since the last revision:

 - Merge branch 'master' into 8254162
 - Simplify example in the toplevel javadoc
 - Tweak support for mapped memory segments
 - Tweak referenced to MemoryAddressProxy in Utils.java
 - Fix performance issue with "small" segment mismatch
 - Address review comments
 - Fix indent in GensrcScopedMemoryAccess.gmk
 - Address review comments
 - Add modified files
 - RFR 8254162: Implementation of Foreign-Memory Access API (Third Incubator)
   
   This patch contains the changes associated with the third incubation round of the foreign memory access API incubation
   (see JEP 393 [1]). This iteration focus on improving the usability of the API in 3 main ways:
   
   * first, by providing a way to obtain truly *shared* segments, which can be accessed and closed concurrently from
     multiple threads
   * second, by providing a way to register a memory segment against a `Cleaner`, so as to have some (optional) guarantee
     that the memory will be deallocated, eventually
   * third, by not requiring users to dive deep into var handles when they first pick up the API; a new `MemoryAccess` class
     has been added, which defines several useful dereference routines; these are really just thin wrappers around memory
     access var handles, but they make the barrier of entry for using this API somewhat lower.
   
   A big conceptual shift that comes with this API refresh is that the role of `MemorySegment` and `MemoryAddress` is not
   the same as it used to be; it used to be the case that a memory address could (sometimes, not always) have a back link
   to the memory segment which originated it; additionally, memory access var handles used `MemoryAddress` as a basic unit
   of dereference.
   
   This has all changed as per this API refresh;  now a `MemoryAddress` is just a dumb carrier which wraps a pair of
   object/long addressing coordinates; `MemorySegment` has become the star of the show, as far as dereferencing memory is
   concerned. You cannot dereference memory if you don't have a segment. This improves usability in a number of ways -
   first, it is a lot easier to wrap native addresses (`long`, essentially) into a `MemoryAddress`; secondly, it is
   crystal clear what a client has to do in order to dereference memory: if a client has a segment, it can use that;
   otherwise, if the client only has an address, it will have to create a segment *unsafely* (this can be done by calling
   `MemoryAddress::asSegmentRestricted`).
   
   A list of the API, implementation and test changes is provided below. If  you have any questions, or need more detailed
   explanations, I (and the  rest of the Panama team) will be happy to point at existing discussions,  and/or to provide
   the feedback required.
   
   A big thank to Erik Osterlund, Vladimir Ivanov and David Holmes, without whom the work on shared memory segment would
   not have been possible.
   
   Thanks
   Maurizio
   
   Javadoc:
   
   http://cr.openjdk.java.net/~mcimadamore/8254162_v1/javadoc/jdk/incubator/foreign/package-summary.html
   
   Specdiff:
   
   http://cr.openjdk.java.net/~mcimadamore/8254162_v1/specdiff/jdk/incubator/foreign/package-summary.html
   
   CSR:
   
   https://bugs.openjdk.java.net/browse/JDK-8254163
   
   * `MemorySegment`
     * drop factory for restricted segment (this has been moved to `MemoryAddress`, see below)
     * added a no-arg factory for a native restricted segment representing entire native heap
     * rename `withOwnerThread` to `handoff`
     * add new `share` method, to create shared segments
     * add new `registerCleaner` method, to register a segment against a cleaner
     * add more helpers to create arrays from a segment e.g. `toIntArray`
     * add some `asSlice` overloads (to make up for the fact that now segments are more frequently used as cursors)
     * rename `baseAddress` to `address` (so that `MemorySegment` can implement `Addressable`)
   * `MemoryAddress`
     * drop `segment` accessor
     * drop `rebase` method and replace it with `segmentOffset` which returns the offset (a `long`) of this address relative
       to a given segment
   * `MemoryAccess`
     * New class supporting several static dereference helpers; the helpers are organized by carrier and access mode, where a
       carrier is one of the usual suspect (a Java primitive, minus `boolean`); the access mode can be simple (e.g. access
       base address of given segment), or indexed, in which case the accessor takes a segment and either a low-level byte
       offset,or a high level logical index. The classification is reflected in the naming scheme (e.g. `getByte` vs.
       `getByteAtOffset` vs `getByteAtIndex`).
   * `MemoryHandles`
     * drop `withOffset` combinator
     * drop `withStride` combinator
     * the basic memory access handle factory now returns a var handle which takes a `MemorySegment` and a `long` - from which
       it is easy to derive all the other handles using plain var handle combinators.
   * `Addressable`
     * This is a new interface which is attached to entities which can be projected to a `MemoryAddress`. For now, both
       `MemoryAddress` and `MemorySegment` implement it; we have plans, with JEP 389 [2] to add more implementations. Clients
       can largely ignore this interface, which comes in really handy when defining native bindings with tools like `jextract`.
   * `MemoryLayouts`
     * A new layout, for machine addresses, has been added to the mix.
   
   There are two main things to discuss here: support for shared segments, and the general simplification of the memory
   access var handle support.
   
   The support for shared segments cuts in pretty deep in the VM. Support for shared segments is notoriously hard to
   achieve, at least in a way that guarantees optimal access performances. This is caused by the fact that, if a segment
   is shared, it would be possible for a thread to close it while another is accessing it.
   
   After considering several options (see [3]), we zeroed onto an approach which is inspired by an happy idea that Andrew
   Haley had (and that he reminded me of at this year OpenJDK committer workshop - thanks!). The idea is that if we
   could *freeze* the world (e.g. with a GC pause), while a segment is closed, we could then prevent segments from being
   accessed concurrently to a close operation. For this to work, it  is crucial that no GC safepoints can occur between a
   segment liveness check and the access itself (otherwise it would be possible for the accessing thread to stop just
   right before an unsafe call). It also relies on the fact that hotspot/C2 should not be able to propagate loads across
   safepoints.
   
   Sadly, none of these conditions seems to be valid in the current implementation, so we needed to resort to a bit of
   creativity. First, we noted that, if we could mark so called *scoped* method with an annotation, it would be very
   simply to check as to whether a thread was in the middle of a scoped method when we stopped the world for a close
   operation (btw, instead of stopping the world, we do a much more efficient, thread-local polling, thanks to JEP 312
   [4]).
   
   The question is, then, once we detect that a thread is accessing the very segment we're about to close, what should
   happen? We first experimented with a solution which would install an *asynchronous* exception on the accessing thread,
   thus making it fail. This solution has some desirable properties, in that a `close` operation always succeeds.
   Unfortunately the machinery for async exceptions is a bit fragile (e.g. not all the code in hotspot checks for async
   exceptions); to minimize risks, we decided to revert to a simpler strategy, where `close` might fail when it finds that
   another thread is accessing the segment being closed.
   
   As written in the javadoc, this doesn't mean that clients should just catch and try again; an exception on `close` is a
   bug in the user code, likely arising from lack of synchronization, and should be treated as such.
   
   In terms of gritty implementation, we needed to centralize memory access routines in a single place, so that we could
   have a set of routines closely mimicking the primitives exposed by `Unsafe` but which, in addition, also provided a
   liveness check. This way we could mark all these routines with the special `@Scoped` annotation, which tells the VM
   that something important is going on.
   
   To achieve this, we created a new (autogenerated) class, called `ScopedMemoryAccess`. This class contains all the main
   memory access primitives (including bulk access, like `copyMemory`, or `setMemory`), and accepts, in addition to the
   access coordinates, also a scope object, which is tested before access. A reachability fence is also thrown in the mix
   to make sure that the scope is kept alive during access (which is important when registering segments against cleaners).
   
   Of course, to make memory access safe, memory access var handles, byte buffer var handles, and byte buffer API should
   use the new `ScopedMemoryAccess` class instead of unsafe, so that a liveness check can be triggered (in case a scope is
   present).
   
   `ScopedMemoryAccess` has a `closeScope` method, which initiates the thread-local handshakes, and returns `true` if the
   handshake completed successfully.
   
   The implementation of `MemoryScope` (now significantly simplified from what we had before), has two implementations,
   one for confined segments and one for shared segments; the main difference between the two is what happens when the
   scope is closed; a confined segment sets a boolean flag to false, and returns, whereas a shared segment goes into a
   `CLOSING` state, then starts the handshake, and then updates the state again, to either `CLOSED` or `ALIVE` depending
   on whether the handshake was successful or not. Note that when a shared segment is in the `CLOSING` state,
   `MemorySegment::isAlive` will still return `true`, while the liveness check upon memory access will fail.
   
   The key realization here was that if all memory access var handles took a coordinate pair of `MemorySegment` and
   `long`, all other access types could be derived from this basic var handle form.
   
   This allowed us to remove the on-the-fly var handle generation, and to simply derive structural access var handles
   (such as those obtained by calling `MemoryLayout::varHandle`) using *plain* var handle combinators, so that e.g.
   additional offset is injected into a base memory access var handle.
   
   This also helped in simplifying the implementation by removing the special `withStride` and `withOffset` combinators,
   which previously needed low-level access on the innards of the memory access var handle. All that code is now gone.
   
   Not much to see here - most of the tests needed to be updated because of the API changes. Some were beefed up (like the
   array test, since now segments can be projected into many different kinds of arrays). A test has been added to test the
   `Cleaner` functionality, and another stress test has been added for shared segments (`TestHandshake`). Some of the
   microbenchmarks also needed some tweaks - and some of them were also updated to also test performance in the shared
   segment case.
   
   [1] - https://openjdk.java.net/jeps/393
   [2] - https://openjdk.java.net/jeps/389
   [3] - https://mail.openjdk.java.net/pipermail/panama-dev/2020-May/009004.html
   [4] - https://openjdk.java.net/jeps/312

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/548/files
  - new: https://git.openjdk.java.net/jdk/pull/548/files/d14d06a4..8815d941

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=548&range=08
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=548&range=07-08

  Stats: 22231 lines in 447 files changed: 12727 ins; 6345 del; 3159 mod
  Patch: https://git.openjdk.java.net/jdk/pull/548.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/548/head:pull/548

PR: https://git.openjdk.java.net/jdk/pull/548

From mcimadamore at openjdk.java.net  Tue Oct 13 11:06:32 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 13 Oct 2020 11:06:32 GMT
Subject: RFR: 8254162: Implementation of Foreign-Memory Access API (Third
 Incubator) [v10]
In-Reply-To: <IngRk57F78UN3yySfo6IABbdwnMogGNdYrykh_3em-c=.b81f7478-015c-45ed-9788-58d7519a2770@github.com>
References: <IngRk57F78UN3yySfo6IABbdwnMogGNdYrykh_3em-c=.b81f7478-015c-45ed-9788-58d7519a2770@github.com>
Message-ID: <HkzCR1qvFwQJhQVzjxPzkc9k_aJVrCdMpSqCtCWYzKA=.73619f27-9216-45b6-830c-52b952fcf82f@github.com>

> This patch contains the changes associated with the third incubation round of the foreign memory access API incubation
> (see JEP 393 [1]). This iteration focus on improving the usability of the API in 3 main ways:
> * first, by providing a way to obtain truly *shared* segments, which can be accessed and closed concurrently from
>   multiple threads
> * second, by providing a way to register a memory segment against a `Cleaner`, so as to have some (optional) guarantee
>   that the memory will be deallocated, eventually
> * third, by not requiring users to dive deep into var handles when they first pick up the API; a new `MemoryAccess` class
>   has been added, which defines several useful dereference routines; these are really just thin wrappers around memory
>   access var handles, but they make the barrier of entry for using this API somewhat lower.
> 
> A big conceptual shift that comes with this API refresh is that the role of `MemorySegment` and `MemoryAddress` is not
> the same as it used to be; it used to be the case that a memory address could (sometimes, not always) have a back link
> to the memory segment which originated it; additionally, memory access var handles used `MemoryAddress` as a basic unit
> of dereference.  This has all changed as per this API refresh;  now a `MemoryAddress` is just a dumb carrier which
> wraps a pair of object/long addressing coordinates; `MemorySegment` has become the star of the show, as far as
> dereferencing memory is concerned. You cannot dereference memory if you don't have a segment. This improves usability
> in a number of ways - first, it is a lot easier to wrap native addresses (`long`, essentially) into a `MemoryAddress`;
> secondly, it is crystal clear what a client has to do in order to dereference memory: if a client has a segment, it can
> use that; otherwise, if the client only has an address, it will have to create a segment *unsafely* (this can be done
> by calling `MemoryAddress::asSegmentRestricted`).  A list of the API, implementation and test changes is provided
> below. If  you have any questions, or need more detailed explanations, I (and the  rest of the Panama team) will be
> happy to point at existing discussions,  and/or to provide the feedback required.   A big thank to Erik Osterlund,
> Vladimir Ivanov and David Holmes, without whom the work on shared memory segment would not have been possible; also I'd
> like to thank Paul Sandoz, whose insights on API design have been very helpful in this journey.  Thanks  Maurizio
> Javadoc:   http://cr.openjdk.java.net/~mcimadamore/8254162_v1/javadoc/jdk/incubator/foreign/package-summary.html
> Specdiff:
> 
> http://cr.openjdk.java.net/~mcimadamore/8254162_v1/specdiff/jdk/incubator/foreign/package-summary.html
> 
> CSR:
> 
> https://bugs.openjdk.java.net/browse/JDK-8254163
> 
> 
> 
> ### API Changes
> 
> * `MemorySegment`
>   * drop factory for restricted segment (this has been moved to `MemoryAddress`, see below)
>   * added a no-arg factory for a native restricted segment representing entire native heap
>   * rename `withOwnerThread` to `handoff`
>   * add new `share` method, to create shared segments
>   * add new `registerCleaner` method, to register a segment against a cleaner
>   * add more helpers to create arrays from a segment e.g. `toIntArray`
>   * add some `asSlice` overloads (to make up for the fact that now segments are more frequently used as cursors)
>   * rename `baseAddress` to `address` (so that `MemorySegment` can implement `Addressable`)
> * `MemoryAddress`
>   * drop `segment` accessor
>   * drop `rebase` method and replace it with `segmentOffset` which returns the offset (a `long`) of this address relative
>     to a given segment
> * `MemoryAccess`
>   * New class supporting several static dereference helpers; the helpers are organized by carrier and access mode, where a
>     carrier is one of the usual suspect (a Java primitive, minus `boolean`); the access mode can be simple (e.g. access
>     base address of given segment), or indexed, in which case the accessor takes a segment and either a low-level byte
>     offset,or a high level logical index. The classification is reflected in the naming scheme (e.g. `getByte` vs.
>     `getByteAtOffset` vs `getByteAtIndex`).
> * `MemoryHandles`
>   * drop `withOffset` combinator
>   * drop `withStride` combinator
>   * the basic memory access handle factory now returns a var handle which takes a `MemorySegment` and a `long` - from which
>     it is easy to derive all the other handles using plain var handle combinators.
> * `Addressable`
>   * This is a new interface which is attached to entities which can be projected to a `MemoryAddress`. For now, both
>     `MemoryAddress` and `MemorySegment` implement it; we have plans, with JEP 389 [2] to add more implementations. Clients
>     can largely ignore this interface, which comes in really handy when defining native bindings with tools like `jextract`.
> * `MemoryLayouts`
>   * A new layout, for machine addresses, has been added to the mix.
> 
> 
> 
> ### Implementation changes
> 
> There are two main things to discuss here: support for shared segments, and the general simplification of the memory
> access var handle support.
> #### Shared segments
> 
> The support for shared segments cuts in pretty deep in the VM. Support for shared segments is notoriously hard to
> achieve, at least in a way that guarantees optimal access performances. This is caused by the fact that, if a segment
> is shared, it would be possible for a thread to close it while another is accessing it.  After considering several
> options (see [3]), we zeroed onto an approach which is inspired by an happy idea that Andrew Haley had (and that he
> reminded me of at this year OpenJDK committer workshop - thanks!). The idea is that if we could *freeze* the world
> (e.g. with a GC pause), while a segment is closed, we could then prevent segments from being accessed concurrently to a
> close operation. For this to work, it  is crucial that no GC safepoints can occur between a segment liveness check and
> the access itself (otherwise it would be possible for the accessing thread to stop just right before an unsafe call).
> It also relies on the fact that hotspot/C2 should not be able to propagate loads across safepoints.  Sadly, none of
> these conditions seems to be valid in the current implementation, so we needed to resort to a bit of creativity. First,
> we noted that, if we could mark so called *scoped* method with an annotation, it would be very simply to check as to
> whether a thread was in the middle of a scoped method when we stopped the world for a close operation (btw, instead of
> stopping the world, we do a much more efficient, thread-local polling, thanks to JEP 312 [4]).  The question is, then,
> once we detect that a thread is accessing the very segment we're about to close, what should happen? We first
> experimented with a solution which would install an *asynchronous* exception on the accessing thread, thus making it
> fail. This solution has some desirable properties, in that a `close` operation always succeeds. Unfortunately the
> machinery for async exceptions is a bit fragile (e.g. not all the code in hotspot checks for async exceptions); to
> minimize risks, we decided to revert to a simpler strategy, where `close` might fail when it finds that another thread
> is accessing the segment being closed.  As written in the javadoc, this doesn't mean that clients should just catch and
> try again; an exception on `close` is a bug in the user code, likely arising from lack of synchronization, and should
> be treated as such.  In terms of gritty implementation, we needed to centralize memory access routines in a single
> place, so that we could have a set of routines closely mimicking the primitives exposed by `Unsafe` but which, in
> addition, also provided a liveness check. This way we could mark all these routines with the special `@Scoped`
> annotation, which tells the VM that something important is going on.  To achieve this, we created a new (autogenerated)
> class, called `ScopedMemoryAccess`. This class contains all the main memory access primitives (including bulk access,
> like `copyMemory`, or `setMemory`), and accepts, in addition to the access coordinates, also a scope object, which is
> tested before access. A reachability fence is also thrown in the mix to make sure that the scope is kept alive during
> access (which is important when registering segments against cleaners).  Of course, to make memory access safe, memory
> access var handles, byte buffer var handles, and byte buffer API should use the new `ScopedMemoryAccess` class instead
> of unsafe, so that a liveness check can be triggered (in case a scope is present).  `ScopedMemoryAccess` has a
> `closeScope` method, which initiates the thread-local handshakes, and returns `true` if the handshake completed
> successfully.  The implementation of `MemoryScope` (now significantly simplified from what we had before), has two
> implementations, one for confined segments and one for shared segments; the main difference between the two is what
> happens when the scope is closed; a confined segment sets a boolean flag to false, and returns, whereas a shared
> segment goes into a `CLOSING` state, then starts the handshake, and then updates the state again, to either `CLOSED` or
> `ALIVE` depending on whether the handshake was successful or not. Note that when a shared segment is in the `CLOSING`
> state, `MemorySegment::isAlive` will still return `true`, while the liveness check upon memory access will fail.  ####
> Memory access var handles overhaul  The key realization here was that if all memory access var handles took a
> coordinate pair of `MemorySegment` and `long`, all other access types could be derived from this basic var handle
> form.  This allowed us to remove the on-the-fly var handle generation, and to simply derive structural access var
> handles (such as those obtained by calling `MemoryLayout::varHandle`) using *plain* var handle combinators, so that
> e.g. additional offset is injected into a base memory access var handle.  This also helped in simplifying the
> implementation by removing the special `withStride` and `withOffset` combinators, which previously needed low-level
> access on the innards of the memory access var handle. All that code is now gone.  #### Test changes  Not much to see
> here - most of the tests needed to be updated because of the API changes. Some were beefed up (like the array test,
> since now segments can be projected into many different kinds of arrays). A test has been added to test the `Cleaner`
> functionality, and another stress test has been added for shared segments (`TestHandshake`). Some of the
> microbenchmarks also needed some tweaks - and some of them were also updated to also test performance in the shared
> segment case.  [1] - https://openjdk.java.net/jeps/393 [2] - https://openjdk.java.net/jeps/389 [3] -
> https://mail.openjdk.java.net/pipermail/panama-dev/2020-May/009004.html [4] - https://openjdk.java.net/jeps/312

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Remove spurious check on MemoryScope::confineTo
  Added tests to make sure no spurious exception is thrown when:
  * handing off a segment from A to A
  * sharing an already shared segment

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/548/files
  - new: https://git.openjdk.java.net/jdk/pull/548/files/8815d941..8fb8ff2f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=548&range=09
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=548&range=08-09

  Stats: 27 lines in 2 files changed: 16 ins; 8 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/548.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/548/head:pull/548

PR: https://git.openjdk.java.net/jdk/pull/548

From coffeys at openjdk.java.net  Tue Oct 13 11:10:19 2020
From: coffeys at openjdk.java.net (Sean Coffey)
Date: Tue, 13 Oct 2020 11:10:19 GMT
Subject: RFR: 8254177: (tz) Upgrade time-zone data to tzdata2020b
In-Reply-To: <KvYfzEHlUV_cV29YAN2i2uXph2lldf0GGz_9TE5O0Iw=.c2d0262d-50d8-49fc-9815-1482616d1a3c@github.com>
References: <KvYfzEHlUV_cV29YAN2i2uXph2lldf0GGz_9TE5O0Iw=.c2d0262d-50d8-49fc-9815-1482616d1a3c@github.com>
Message-ID: <aKCw-4GeWTCVDf5a6XtttBy2G67YJHDlWdrmTXjy66I=.67e2e981-4732-4075-a1c7-0c76f845abd9@github.com>

On Mon, 12 Oct 2020 09:32:38 GMT, Kiran Sidhartha Ravikumar <kravikumar at openjdk.org> wrote:

> Hi Guys,
> 
> Please review the patch for tzdata2020b integration into JDK.
> 
> Release details can be found here:
> 
> https://mm.icann.org/pipermail/tz-announce/2020-October/000059.html
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8254177
> 
> I had the pacificnew, systemv files removed from JDK repo and so TimeZoneName classes, make file and few test files
> need to be updated to incorporate the change.
> The patch has passed all the related testing including JCK.
> 
> Thanks,
> Kiran

Looks good. I think we should release-note the removal of the "US/Pacific-New" Link on the off chance that some
production/testing system is looking for such a zone.

-------------

Marked as reviewed by coffeys (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/602

From mcimadamore at openjdk.java.net  Tue Oct 13 11:23:33 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 13 Oct 2020 11:23:33 GMT
Subject: RFR: 8254162: Implementation of Foreign-Memory Access API (Third
 Incubator) [v11]
In-Reply-To: <IngRk57F78UN3yySfo6IABbdwnMogGNdYrykh_3em-c=.b81f7478-015c-45ed-9788-58d7519a2770@github.com>
References: <IngRk57F78UN3yySfo6IABbdwnMogGNdYrykh_3em-c=.b81f7478-015c-45ed-9788-58d7519a2770@github.com>
Message-ID: <McWGh9rcsoHp52SL1femO6Llp58QVBkNGC5cWKo4MBE=.9d77deb5-248d-4dcd-8f8a-90175984a1e3@github.com>

> This patch contains the changes associated with the third incubation round of the foreign memory access API incubation
> (see JEP 393 [1]). This iteration focus on improving the usability of the API in 3 main ways:
> * first, by providing a way to obtain truly *shared* segments, which can be accessed and closed concurrently from
>   multiple threads
> * second, by providing a way to register a memory segment against a `Cleaner`, so as to have some (optional) guarantee
>   that the memory will be deallocated, eventually
> * third, by not requiring users to dive deep into var handles when they first pick up the API; a new `MemoryAccess` class
>   has been added, which defines several useful dereference routines; these are really just thin wrappers around memory
>   access var handles, but they make the barrier of entry for using this API somewhat lower.
> 
> A big conceptual shift that comes with this API refresh is that the role of `MemorySegment` and `MemoryAddress` is not
> the same as it used to be; it used to be the case that a memory address could (sometimes, not always) have a back link
> to the memory segment which originated it; additionally, memory access var handles used `MemoryAddress` as a basic unit
> of dereference.  This has all changed as per this API refresh;  now a `MemoryAddress` is just a dumb carrier which
> wraps a pair of object/long addressing coordinates; `MemorySegment` has become the star of the show, as far as
> dereferencing memory is concerned. You cannot dereference memory if you don't have a segment. This improves usability
> in a number of ways - first, it is a lot easier to wrap native addresses (`long`, essentially) into a `MemoryAddress`;
> secondly, it is crystal clear what a client has to do in order to dereference memory: if a client has a segment, it can
> use that; otherwise, if the client only has an address, it will have to create a segment *unsafely* (this can be done
> by calling `MemoryAddress::asSegmentRestricted`).  A list of the API, implementation and test changes is provided
> below. If  you have any questions, or need more detailed explanations, I (and the  rest of the Panama team) will be
> happy to point at existing discussions,  and/or to provide the feedback required.   A big thank to Erik Osterlund,
> Vladimir Ivanov and David Holmes, without whom the work on shared memory segment would not have been possible; also I'd
> like to thank Paul Sandoz, whose insights on API design have been very helpful in this journey.  Thanks  Maurizio
> Javadoc:   http://cr.openjdk.java.net/~mcimadamore/8254162_v1/javadoc/jdk/incubator/foreign/package-summary.html
> Specdiff:
> 
> http://cr.openjdk.java.net/~mcimadamore/8254162_v1/specdiff/jdk/incubator/foreign/package-summary.html
> 
> CSR:
> 
> https://bugs.openjdk.java.net/browse/JDK-8254163
> 
> 
> 
> ### API Changes
> 
> * `MemorySegment`
>   * drop factory for restricted segment (this has been moved to `MemoryAddress`, see below)
>   * added a no-arg factory for a native restricted segment representing entire native heap
>   * rename `withOwnerThread` to `handoff`
>   * add new `share` method, to create shared segments
>   * add new `registerCleaner` method, to register a segment against a cleaner
>   * add more helpers to create arrays from a segment e.g. `toIntArray`
>   * add some `asSlice` overloads (to make up for the fact that now segments are more frequently used as cursors)
>   * rename `baseAddress` to `address` (so that `MemorySegment` can implement `Addressable`)
> * `MemoryAddress`
>   * drop `segment` accessor
>   * drop `rebase` method and replace it with `segmentOffset` which returns the offset (a `long`) of this address relative
>     to a given segment
> * `MemoryAccess`
>   * New class supporting several static dereference helpers; the helpers are organized by carrier and access mode, where a
>     carrier is one of the usual suspect (a Java primitive, minus `boolean`); the access mode can be simple (e.g. access
>     base address of given segment), or indexed, in which case the accessor takes a segment and either a low-level byte
>     offset,or a high level logical index. The classification is reflected in the naming scheme (e.g. `getByte` vs.
>     `getByteAtOffset` vs `getByteAtIndex`).
> * `MemoryHandles`
>   * drop `withOffset` combinator
>   * drop `withStride` combinator
>   * the basic memory access handle factory now returns a var handle which takes a `MemorySegment` and a `long` - from which
>     it is easy to derive all the other handles using plain var handle combinators.
> * `Addressable`
>   * This is a new interface which is attached to entities which can be projected to a `MemoryAddress`. For now, both
>     `MemoryAddress` and `MemorySegment` implement it; we have plans, with JEP 389 [2] to add more implementations. Clients
>     can largely ignore this interface, which comes in really handy when defining native bindings with tools like `jextract`.
> * `MemoryLayouts`
>   * A new layout, for machine addresses, has been added to the mix.
> 
> 
> 
> ### Implementation changes
> 
> There are two main things to discuss here: support for shared segments, and the general simplification of the memory
> access var handle support.
> #### Shared segments
> 
> The support for shared segments cuts in pretty deep in the VM. Support for shared segments is notoriously hard to
> achieve, at least in a way that guarantees optimal access performances. This is caused by the fact that, if a segment
> is shared, it would be possible for a thread to close it while another is accessing it.  After considering several
> options (see [3]), we zeroed onto an approach which is inspired by an happy idea that Andrew Haley had (and that he
> reminded me of at this year OpenJDK committer workshop - thanks!). The idea is that if we could *freeze* the world
> (e.g. with a GC pause), while a segment is closed, we could then prevent segments from being accessed concurrently to a
> close operation. For this to work, it  is crucial that no GC safepoints can occur between a segment liveness check and
> the access itself (otherwise it would be possible for the accessing thread to stop just right before an unsafe call).
> It also relies on the fact that hotspot/C2 should not be able to propagate loads across safepoints.  Sadly, none of
> these conditions seems to be valid in the current implementation, so we needed to resort to a bit of creativity. First,
> we noted that, if we could mark so called *scoped* method with an annotation, it would be very simply to check as to
> whether a thread was in the middle of a scoped method when we stopped the world for a close operation (btw, instead of
> stopping the world, we do a much more efficient, thread-local polling, thanks to JEP 312 [4]).  The question is, then,
> once we detect that a thread is accessing the very segment we're about to close, what should happen? We first
> experimented with a solution which would install an *asynchronous* exception on the accessing thread, thus making it
> fail. This solution has some desirable properties, in that a `close` operation always succeeds. Unfortunately the
> machinery for async exceptions is a bit fragile (e.g. not all the code in hotspot checks for async exceptions); to
> minimize risks, we decided to revert to a simpler strategy, where `close` might fail when it finds that another thread
> is accessing the segment being closed.  As written in the javadoc, this doesn't mean that clients should just catch and
> try again; an exception on `close` is a bug in the user code, likely arising from lack of synchronization, and should
> be treated as such.  In terms of gritty implementation, we needed to centralize memory access routines in a single
> place, so that we could have a set of routines closely mimicking the primitives exposed by `Unsafe` but which, in
> addition, also provided a liveness check. This way we could mark all these routines with the special `@Scoped`
> annotation, which tells the VM that something important is going on.  To achieve this, we created a new (autogenerated)
> class, called `ScopedMemoryAccess`. This class contains all the main memory access primitives (including bulk access,
> like `copyMemory`, or `setMemory`), and accepts, in addition to the access coordinates, also a scope object, which is
> tested before access. A reachability fence is also thrown in the mix to make sure that the scope is kept alive during
> access (which is important when registering segments against cleaners).  Of course, to make memory access safe, memory
> access var handles, byte buffer var handles, and byte buffer API should use the new `ScopedMemoryAccess` class instead
> of unsafe, so that a liveness check can be triggered (in case a scope is present).  `ScopedMemoryAccess` has a
> `closeScope` method, which initiates the thread-local handshakes, and returns `true` if the handshake completed
> successfully.  The implementation of `MemoryScope` (now significantly simplified from what we had before), has two
> implementations, one for confined segments and one for shared segments; the main difference between the two is what
> happens when the scope is closed; a confined segment sets a boolean flag to false, and returns, whereas a shared
> segment goes into a `CLOSING` state, then starts the handshake, and then updates the state again, to either `CLOSED` or
> `ALIVE` depending on whether the handshake was successful or not. Note that when a shared segment is in the `CLOSING`
> state, `MemorySegment::isAlive` will still return `true`, while the liveness check upon memory access will fail.  ####
> Memory access var handles overhaul  The key realization here was that if all memory access var handles took a
> coordinate pair of `MemorySegment` and `long`, all other access types could be derived from this basic var handle
> form.  This allowed us to remove the on-the-fly var handle generation, and to simply derive structural access var
> handles (such as those obtained by calling `MemoryLayout::varHandle`) using *plain* var handle combinators, so that
> e.g. additional offset is injected into a base memory access var handle.  This also helped in simplifying the
> implementation by removing the special `withStride` and `withOffset` combinators, which previously needed low-level
> access on the innards of the memory access var handle. All that code is now gone.  #### Test changes  Not much to see
> here - most of the tests needed to be updated because of the API changes. Some were beefed up (like the array test,
> since now segments can be projected into many different kinds of arrays). A test has been added to test the `Cleaner`
> functionality, and another stress test has been added for shared segments (`TestHandshake`). Some of the
> microbenchmarks also needed some tweaks - and some of them were also updated to also test performance in the shared
> segment case.  [1] - https://openjdk.java.net/jeps/393 [2] - https://openjdk.java.net/jeps/389 [3] -
> https://mail.openjdk.java.net/pipermail/panama-dev/2020-May/009004.html [4] - https://openjdk.java.net/jeps/312

Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The incremental
webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits
since the last revision:

 - Merge branch 'master' into 8254162
 - Remove spurious check on MemoryScope::confineTo
   Added tests to make sure no spurious exception is thrown when:
   * handing off a segment from A to A
   * sharing an already shared segment
 - Merge branch 'master' into 8254162
 - Simplify example in the toplevel javadoc
 - Tweak support for mapped memory segments
 - Tweak referenced to MemoryAddressProxy in Utils.java
 - Fix performance issue with "small" segment mismatch
 - Address review comments
 - Fix indent in GensrcScopedMemoryAccess.gmk
 - Address review comments
 - ... and 2 more: https://git.openjdk.java.net/jdk/compare/f7d78c01...e866bb23

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/548/files
  - new: https://git.openjdk.java.net/jdk/pull/548/files/8fb8ff2f..e866bb23

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=548&range=10
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=548&range=09-10

  Stats: 605 lines in 49 files changed: 426 ins; 116 del; 63 mod
  Patch: https://git.openjdk.java.net/jdk/pull/548.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/548/head:pull/548

PR: https://git.openjdk.java.net/jdk/pull/548

From kravikumar at openjdk.java.net  Tue Oct 13 11:35:13 2020
From: kravikumar at openjdk.java.net (Kiran Sidhartha Ravikumar)
Date: Tue, 13 Oct 2020 11:35:13 GMT
Subject: RFR: 8254177: (tz) Upgrade time-zone data to tzdata2020b
In-Reply-To: <aKCw-4GeWTCVDf5a6XtttBy2G67YJHDlWdrmTXjy66I=.67e2e981-4732-4075-a1c7-0c76f845abd9@github.com>
References: <KvYfzEHlUV_cV29YAN2i2uXph2lldf0GGz_9TE5O0Iw=.c2d0262d-50d8-49fc-9815-1482616d1a3c@github.com>
 <aKCw-4GeWTCVDf5a6XtttBy2G67YJHDlWdrmTXjy66I=.67e2e981-4732-4075-a1c7-0c76f845abd9@github.com>
Message-ID: <Hsd4_aFWtUkPKQAfgd4741RyCUes_UVlFWEzlw4Q69Y=.2673111e-c458-4807-9d4e-f431f6e76d23@github.com>

On Tue, 13 Oct 2020 11:07:13 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> Hi Guys,
>> 
>> Please review the patch for tzdata2020b integration into JDK.
>> 
>> Release details can be found here:
>> 
>> https://mm.icann.org/pipermail/tz-announce/2020-October/000059.html
>> 
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8254177
>> 
>> I had the pacificnew, systemv files removed from JDK repo and so TimeZoneName classes, make file and few test files
>> need to be updated to incorporate the change.
>> The patch has passed all the related testing including JCK.
>> 
>> Thanks,
>> Kiran
>
> Looks good. I think we should release-note the removal of the "US/Pacific-New" Link on the off chance that some
> production/testing system is looking for such a zone.

Thanks for the review everyone, I have added a release note to the bug. I will integrate the changes

-------------

PR: https://git.openjdk.java.net/jdk/pull/602

From simonis at openjdk.java.net  Tue Oct 13 11:40:36 2020
From: simonis at openjdk.java.net (Volker Simonis)
Date: Tue, 13 Oct 2020 11:40:36 GMT
Subject: RFR: 8253952: Refine ZipOutputStream.putNextEntry() to
 recalculate ZipEntry's compressed size [v4]
In-Reply-To: <0nq5oFKOj6AZqCW6jF268-6oKRI6UkS6TRIHo-_5vKw=.d13c7016-4473-4b20-9117-100b368d3716@github.com>
References: <0nq5oFKOj6AZqCW6jF268-6oKRI6UkS6TRIHo-_5vKw=.d13c7016-4473-4b20-9117-100b368d3716@github.com>
Message-ID: <qi-3I4yAOah36I8pLGLl9Vcfq-1R335KpxyaWHJsJKU=.e6939ba1-7cc8-45b4-af11-694db930d0cb@github.com>

> ### Summary
> 
> Work around wrong usage of `ZipOutputStream.putNextEntry()` in user code which can lead to the `ZipException "invalid
> entry compressed size"`.
> ### Motivation
> 
> In general it is not safe to directly write a ZipEntry obtained from `ZipInputStream.getNextEntry()`,
> `ZipFile.entries()`, `ZipFile.getEntry()` or `ZipFile.stream()` with `ZipOutputStream.putNextEntry()` to a
> `ZipOutputStream` and then read the entries data from the `ZipInputStream` and write it to the `ZipOutputStream` as
> follows:
>  ZipEntry entry;
>  ZipInputStream zis = new ZipInputStream(...);
>  ZipOutputStream zos = new ZipOutputStream(...);
>  while((entry = zis.getNextEntry()) != null) {
>      zos.putNextEntry(entry);
>      zis.transferTo(zos);
>  }
> The problem with this code is that the zip file format does not record the compression level used for deflation in its
> entries. In general, it doesn't even mandate a predefined compression ratio per compression level. Therefore the
> compressed size recorded in a `ZipEntry` read from a zip file might differ from the new compressed size produced by the
> receiving `ZipOutputStream`. Such a difference will result in a `ZipException` with the following message:
>  java.util.zip.ZipException: invalid entry compressed size (expected 12 but got 7 bytes)
>  
> The correct way of copying all entries from one zip file into another requires the creation of a new `ZipEntry` or at
> least resetting of the compressed size field. E.g.:
>  while((entry = zis.getNextEntry()) != null) {
>      ZipEntry newEntry = new ZipEntry(entry.getName());
>      zos.putNextEntry(newEntry);
>      zis.transferTo(zos);
>  }
> or:
>  while((entry = zis.getNextEntry()) != null) {
>      entry.setCompressedSize(-1);
>      zos.putNextEntry(entry);
>      zis.transferTo(zos);
>  }
> Unfortunately, there's a lot of user code out there which gets this wrong and uses the bad coding pattern described
> before. Searching for `"java.util.zip.ZipException: invalid entry compressed size (expected 12 but got 7 bytes)"` gives
> ~2500 hits (~100 on StackOverflow). It's also no hard to find plenty of instances of this anti-pattern on GitHub when
> doing a code search for `ZipEntry` and `putNextEntry()`. E.g. [Gradle 4.x wrapper task][1] is affected as well as the
> latest version of the [mockableAndroidJar task][2]. I've recently fixed two occurrences of this pattern in OpenJDK (see
> [JDK-8240333][3] and [JDK-8240235][4]) but there still exist more of them (e.g.
> [`test/jdk/java/util/zip/ZipFile/CopyJar.java`][5] which is there since 1999 :).  ### Description  So while this has
> clearly been a problem before, it apparently wasn't painful enough to trigger any action from the side of the JDK.
> However, recently quite some zlib forks with [superior deflate/inflate performance have evolved][6]. Using them with
> OpenJDK is quite straight-forward: one just has to configure the alternative implementations by setting
> `LD_LIBRARY_PATH` or `LD_PRELOAD` correspondingly. We've seen big saving by using these new zlib implementations for
> selected services in production and the only reason why we haven't enabled them by default until now is the problem
> I've just described. The reason why these new libraries uncover the described anti-pattern much more often is because
> their compression ratio is slightly different from that of the default zlib library. This can easily trigger a
> `ZipException` even if an application is not using a different compression levels but just a zip file created with
> another zlib version.  I'd therefore like to propose the following workaround for the wrong
> `ZipOutputStream.putNextEntry()` usage in user code:
> -  ignore the compressed size if it was implicitly determined from the zip file and not explicitly set by calling
>    `ZipEntry.setCompressedSize()`.
> 
> - Change the API-documentation of `ZipOutputStream.putNextEntry()` and `JarOutputStream.putNextEntry()` to explain the
>   problem and why `putNextEntry()` will ignore the compressed size of a `ZipEntry` if that was set implicitely when
>   reading that entry from a `ZipFile` or `ZipInputStream`.
> 
> 
> ### Technical Details
> 
> A zip file consists of a stream of File Entries followed by a Central Directory (see [here for a more detailed
> specification][7]). Each File Entry is composed of a Local File Header (LFH) followed by the compressed Data and an
> optional Data Descriptor. The LFH contains the File Name and among other attributes the Compressed and Uncompressed
> size and CRC of the Data. In the case where the latter three attributes are not available at the time when the LFH is
> created, this fact will be recorded in a flag of the LFH and will trigger the creation of a Data Descriptor with the
> corresponding information right after the Data section. Finally, the Central Directory contains one Central Directory
> File Header (CDFH) for each entry of the  zip archive. The CDFH is an extended version of the LFH and the ultimate
> reference for the contents of the zip archive. The redundancy between LFH and CDFH is a tribute to zip's long history
> when it was used to store archives on multiple floppy discs and the CDFH allowed to update the archive by only writing
> to the last disc which contained the Central Directory.  `ZipEntries` read with `ZipInputStream.getNextEntry()` will
> initially only contain the information from the LFH. Only after the next entry was read (or after
> `ZipInputStream.closeEntry()` was called explicitly), will the previously read entry be updated with the data from the
> Data Descriptor. `ZipInputStream` doesn't inspect the Central Directory at all.  On the other hand, `ZipFile` only
> queries the Central Directory for `ZipEntry` information so all `ZipEntries` returned by `ZipFile.entries()`,
> `ZipFile.getEntry()` and `ZipFile.stream()` will always instantly contain the full Compressed and Uncompressed Size and
> CRC information for each entry independently of the LFH contents.  ### Risks and Assumptions  If we choose to ignore
> the implicitly recorded compressed size in a `ZipEntry` read from a zip file when writing it to a `ZipOutputStream`,
> this will lead to zip files with incomplete information in the LFH and an additional Data Descriptor as described
> before. However, the result is still fully compatible to the zip file specification. It's also not unusual, because by
> default all new zip files created with `ZipOutputStream` will contain LFHs without Compressed and Uncompressed Size and
> CRC information and an additional Data Descriptor. Theoretically it is possible to create new zip files with
> `ZipOutputStream` class and Compressed and Uncompressed Size and CRC information in the LFH but that's complex and
> inefficient because it requires two steps. A first step to determine the crc and compressed size of the data and a
> second step to actually write the data to the `ZipOutputStream` (which will compress it a second time). This is because
> the current API offers no possibility to write already compressed data to a `ZipOutputStream`.  Consequently, the only
> straight-forward way of creating zip files from Java which have all the data in the LFH and no Data Descriptor is by
> copying `ZipEntries` from an existing zip file with the buggy method described before. This incidentally worked more or
> less reliable for a long time but breaks miserably when using different zlib implementations. Ignoring the implicitly
> set compressed size of `ZipEntries` can easily fix this problem.  I'm not aware of any tool which can not handle such
> files and if it exists it would have problems with the majority of Java created zip files anyway (e.g. all jar-files
> created with the jar tool have zip entries with incomplete LFH data and additional Data Descriptor).  Ignoring the
> implicitly set compressed size of `ZipEntries` has no measurable performance impact and will increase the size of zip
> archives which used to have the complete file information in the LFH before by 16 bytes per entry. On the other hand it
> will give us the freedom to use whatever zip implementation we like :)   [1]:
> https://github.com/gradle/gradle/blob/e76905e3a/subprojects/build-init/src/main/java/org/gradle/api/tasks/wrapper/Wrapper.java#L152-L158
> [2]:
> https://android.googlesource.com/platform/tools/base/+/refs/heads/master/build-system/builder/src/main/java/com/android/builder/testing/MockableJarGenerator.java#86
> [3]: https://bugs.openjdk.java.net/browse/JDK-8240333 [4]: https://bugs.openjdk.java.net/browse/JDK-8240235 [5]:
> https://github.com/openjdk/jdk/blob/master/test/jdk/java/util/zip/ZipFile/CopyJar.java [6]:
> https://github.com/simonis/zlib-bench/blob/master/Results.md [7]: https://en.wikipedia.org/wiki/Zip_(file_format)

Volker Simonis has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev
excludes the unrelated changes brought in by the merge/rebase. The pull request contains one additional commit since
the last revision:

  8253952: Refine ZipOutputStream.putNextEntry() to recalculate ZipEntry's compressed size

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/520/files
  - new: https://git.openjdk.java.net/jdk/pull/520/files/988f3ef9..3edcf72e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=520&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=520&range=02-03

  Stats: 43936 lines in 2282 files changed: 22490 ins; 10444 del; 11002 mod
  Patch: https://git.openjdk.java.net/jdk/pull/520.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/520/head:pull/520

PR: https://git.openjdk.java.net/jdk/pull/520

From simonis at openjdk.java.net  Tue Oct 13 11:40:36 2020
From: simonis at openjdk.java.net (Volker Simonis)
Date: Tue, 13 Oct 2020 11:40:36 GMT
Subject: RFR: 8253952: Refine ZipOutputStream.putNextEntry() to
 recalculate ZipEntry's compressed size [v3]
In-Reply-To: <HWODTjWT1Sk6HY5Lqr9H3qEn43VvRagGEQBUPau85KU=.3ae62bdc-123b-44d7-b799-f47e21c803bc@github.com>
References: <0nq5oFKOj6AZqCW6jF268-6oKRI6UkS6TRIHo-_5vKw=.d13c7016-4473-4b20-9117-100b368d3716@github.com>
 <iMuYmEv-fCgpaIueHT5E_f28siuhzUjohwreSCZT8Dc=.d765890e-dea1-4207-83be-18d1726262bc@github.com>
 <HWODTjWT1Sk6HY5Lqr9H3qEn43VvRagGEQBUPau85KU=.3ae62bdc-123b-44d7-b799-f47e21c803bc@github.com>
Message-ID: <dlGi6LsOkNDaLsxt66VjK0kkL7jpqgztTxu_tZcgmpE=.0179265f-7e47-410a-869e-5222d68518d8@github.com>

On Mon, 12 Oct 2020 15:42:45 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Volker Simonis 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:
>>   8253952: Refine ZipOutputStream.putNextEntry() to recalculate ZipEntry's compressed size
>
> I think we are getting close.    Once the javadoc is cleaned up along with the minor changes recommended  we should be
> in good shape and can then review the CSR

I hope I've addressed all your comments and suggestion with the latest PR. I've also updated the CSR to reflect the
latest version of the API changes from the PR. Please have a look.

Thank you and best regards,
Volker

-------------

PR: https://git.openjdk.java.net/jdk/pull/520

From kravikumar at openjdk.java.net  Tue Oct 13 11:41:16 2020
From: kravikumar at openjdk.java.net (Kiran Sidhartha Ravikumar)
Date: Tue, 13 Oct 2020 11:41:16 GMT
Subject: Integrated: 8254177: (tz) Upgrade time-zone data to tzdata2020b
In-Reply-To: <KvYfzEHlUV_cV29YAN2i2uXph2lldf0GGz_9TE5O0Iw=.c2d0262d-50d8-49fc-9815-1482616d1a3c@github.com>
References: <KvYfzEHlUV_cV29YAN2i2uXph2lldf0GGz_9TE5O0Iw=.c2d0262d-50d8-49fc-9815-1482616d1a3c@github.com>
Message-ID: <7ehytQcqVn_Zu5PS5lK08N0zXW0pf_OPGfU5LKVGHM8=.5fdd7b75-4e0a-4e67-8d3d-f86175c38cfc@github.com>

On Mon, 12 Oct 2020 09:32:38 GMT, Kiran Sidhartha Ravikumar <kravikumar at openjdk.org> wrote:

> Hi Guys,
> 
> Please review the patch for tzdata2020b integration into JDK.
> 
> Release details can be found here:
> 
> https://mm.icann.org/pipermail/tz-announce/2020-October/000059.html
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8254177
> 
> I had the pacificnew, systemv files removed from JDK repo and so TimeZoneName classes, make file and few test files
> need to be updated to incorporate the change.
> The patch has passed all the related testing including JCK.
> 
> Thanks,
> Kiran

This pull request has now been integrated.

Changeset: 9c934909
Author:    Kiran Sidhartha Ravikumar <kravikumar at openjdk.org>
Committer: Sean Coffey <coffeys at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/9c934909
Stats:     480 lines in 27 files changed: 138 ins; 133 del; 209 mod

8254177: (tz) Upgrade time-zone data to tzdata2020b

Reviewed-by: erikj, naoto, coffeys

-------------

PR: https://git.openjdk.java.net/jdk/pull/602

From aph at openjdk.java.net  Tue Oct 13 12:13:20 2020
From: aph at openjdk.java.net (Andrew Haley)
Date: Tue, 13 Oct 2020 12:13:20 GMT
Subject: RFR: 8254078: DataOutputStream is very slow post-disabling of
 Biased Locking [v5]
In-Reply-To: <0I6kZ2rCklCMmXMSzTgLaiPMVwBb46A9cJlW9WxHseQ=.9b98fc93-2ee3-4d8f-a7bb-fa606c47a869@github.com>
References: <lLg_yNI_6LvUZTlM4PyN5ra6AaUZZeT35QzYzV_0CpI=.f2d3cb9e-be30-40dc-922c-dad5bef7feea@github.com>
 <m7ARywFg8Ni4jwTqp3Fm3SQc1B2hygUVpk_GGNekHWM=.9304f26a-e604-44d9-9c37-cf188ee4904f@github.com>
 <GZPlMNeTDXrRwQS0RCwOpshgulzn-G00sm5QygAnTCo=.9031a38b-9dda-4c5f-bb91-a38bf7d31a01@github.com>
 <0I6kZ2rCklCMmXMSzTgLaiPMVwBb46A9cJlW9WxHseQ=.9b98fc93-2ee3-4d8f-a7bb-fa606c47a869@github.com>
Message-ID: <6cKVx6TAvFjwXHUrOrh-U401du17D-TLMecxFEEzF4I=.fef20e96-68b5-4a47-87e2-0043bbee1f97@github.com>

On Mon, 12 Oct 2020 18:16:57 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Can probably move all these initializations to `setup()`. It does not look like the fields `final`-ity matter for this
> benchmark.

This conflicts with other desiderata, i.e. that fields should be final and if a field can be initialized it should be.
And it makes the benchmark longer. I prefer to pass on this one.

-------------

PR: https://git.openjdk.java.net/jdk/pull/542

From aph at openjdk.java.net  Tue Oct 13 12:39:27 2020
From: aph at openjdk.java.net (Andrew Haley)
Date: Tue, 13 Oct 2020 12:39:27 GMT
Subject: RFR: 8254078: DataOutputStream is very slow post-disabling of
 Biased Locking [v6]
In-Reply-To: <lLg_yNI_6LvUZTlM4PyN5ra6AaUZZeT35QzYzV_0CpI=.f2d3cb9e-be30-40dc-922c-dad5bef7feea@github.com>
References: <lLg_yNI_6LvUZTlM4PyN5ra6AaUZZeT35QzYzV_0CpI=.f2d3cb9e-be30-40dc-922c-dad5bef7feea@github.com>
Message-ID: <OEguX4d1pnZgMjRxZNv6RXIwI4xr2iCdc4TyW7NT4P0=.136853be-9fdd-413e-9584-83a9d6dd5aad@github.com>

> DataOutputStream is very slow post-disabling of Biased Locking. This
> was discovered when benchmarking a transaction library, which showed
> significant performance loss when moving to JDK 15. WIth some small
> changes to DataOutputStream we can get the performance back. There's a
> JMH benchmark at
> http://cr.openjdk.java.net/~aph/JDK-8254078/jmh-tests.tar
> 
> Some Stream classes use very fine-grained locking.
> 
> In particular, writeInt is defined like this:
> 
>         out.write((v >>> 24) & 0xFF);
>         out.write((v >>> 16) & 0xFF);
>         out.write((v >>> 8) & 0xFF);
>         out.write((v >>> 0) & 0xFF);
>         incCount(4);
> 
> Unfortunately, ByteArrayOutputStream.write(byte) is defined like this:
> 
>     public synchronized void write(int b) {
>         ensureCapacity(count + 1);
>         buf[count] = (byte) b;
>         count += 1;
>     }
> 
> so we acquire and release a lock for every byte that is output.
> 
>  For example, writing 4kb of ints goes from 17.3 us/op to 53.9 us/op when biased locking is disabled:
> 
> 
> +UseBiasedLocking DataOutputStreamTest.dataOutputStreamOverByteArray avgt 6 53.895 ? 5.126 us/op
> -UseBiasedLocking DataOutputStreamTest.dataOutputStreamOverByteArray avgt 6 17.291 ? 4.430 us/op
> 
> There are refactorings of DataOutputStream we can do to mitigate this.

Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:

  8254078: DataOutputStream is very slow post-disabling of Biased Locking

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/542/files
  - new: https://git.openjdk.java.net/jdk/pull/542/files/43be1998..cd1d5a0a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=542&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=542&range=04-05

  Stats: 18 lines in 2 files changed: 0 ins; 6 del; 12 mod
  Patch: https://git.openjdk.java.net/jdk/pull/542.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/542/head:pull/542

PR: https://git.openjdk.java.net/jdk/pull/542

From aph at openjdk.java.net  Tue Oct 13 12:39:28 2020
From: aph at openjdk.java.net (Andrew Haley)
Date: Tue, 13 Oct 2020 12:39:28 GMT
Subject: RFR: 8254078: DataOutputStream is very slow post-disabling of
 Biased Locking [v4]
In-Reply-To: <kp3-ISdeUaZnvvfIIH9Kf76K8HiLXByGqQqydyWZ8nE=.9e15c45e-7f2a-48f1-9ae2-3b777f825e36@github.com>
References: <lLg_yNI_6LvUZTlM4PyN5ra6AaUZZeT35QzYzV_0CpI=.f2d3cb9e-be30-40dc-922c-dad5bef7feea@github.com>
 <Gj_g60Z7fHmhYdrpnT2orSadEquafzlbswhNfbOtEf4=.54e3592b-1e86-410d-8a37-9a51337cd0c8@github.com>
 <kp3-ISdeUaZnvvfIIH9Kf76K8HiLXByGqQqydyWZ8nE=.9e15c45e-7f2a-48f1-9ae2-3b777f825e36@github.com>
Message-ID: <Vly_nhR3aWw7T_CuYRvDSLH0KxOyMHJpkE25gZ10XcA=.86df61eb-cd8a-4cf3-8c73-66f75bebea59@github.com>

On Fri, 9 Oct 2020 12:50:35 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8254078: DataOutputStream is very slow post-disabling of Biased Locking
>
> test/micro/org/openjdk/bench/java/io/DataOutputStreamTest.java line 43:
> 
>> 41:     public static class BenchmarkState {
>> 42:         @Param({"4096"}) int SIZE;
>> 43:         @Param({"char", "short", "int", /*"string"*/}) String BASIC_TYPE;
> 
> - Do we use `"string"` case or not?
> - Java style: all caps are reserved for `static final` fields, these should be `size` and `basicType`
> - JMH supports `@Param` over `Enum`-s, so this `String` dance does not seem necessary.

The "string" case is there but I haven't changed anything in String output for now.

-------------

PR: https://git.openjdk.java.net/jdk/pull/542

From herrick at openjdk.java.net  Tue Oct 13 12:59:22 2020
From: herrick at openjdk.java.net (Andy Herrick)
Date: Tue, 13 Oct 2020 12:59:22 GMT
Subject: RFR: JDK-8252870: Finalize (remove "incubator" from) jpackage
Message-ID: <HlksY2mFyKG_kkZA6n6JHHIWBGJT3bjmoLG28c9q1EU=.2b9faa66-08b9-4694-a5db-9d9918039642@github.com>

JDK-8252870: Finalize (remove "incubator" from) jpackage

-------------

Commit messages:
 - JDK-8252870: Finalize (remove "incubator" from) jpackage
 - 8252869 Finalize (remove incubator from) jpackage (implementation)

Changes: https://git.openjdk.java.net/jdk/pull/633/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=633&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8252870
  Stats: 1796 lines in 262 files changed: 723 ins; 732 del; 341 mod
  Patch: https://git.openjdk.java.net/jdk/pull/633.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/633/head:pull/633

PR: https://git.openjdk.java.net/jdk/pull/633

From mcimadamore at openjdk.java.net  Tue Oct 13 13:29:28 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 13 Oct 2020 13:29:28 GMT
Subject: RFR: 8254231: Implementation of Foreign Linker API (Incubator)
Message-ID: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>

This patch contains the changes associated with the first incubation round of the foreign linker access API incubation
(see JEP 389 [1]). This work is meant to sit on top of the foreign memory access support (see JEP 393 [2] and
associated pull request [3]).

The main goal of this API is to provide a way to call native functions from Java code without the need of intermediate
JNI glue code. In order to do this, native calls are modeled through the MethodHandle API. I suggest reading the
writeup [4] I put together few weeks ago, which illustrates what the foreign linker support is, and how it should be
used by clients.

Disclaimer: the pull request mechanism isn't great at managing *dependent* reviews. For this reasons, I'm attaching a
webrev which contains only the differences between this PR and the memory access PR. I will be periodically uploading
new webrevs, as new iterations come out, to try and make the life of reviewers as simple as possible.

A big thank to Jorn Vernee and Vladimir Ivanov - they are the main architects of all the hotspot changes you see here,
and without their help, the foreign linker support wouldn't be what it is today. As usual, a big thank to Paul Sandoz,
who provided many insights (often by trying the bits first hand).

Thanks
Maurizio

Webrev:
http://cr.openjdk.java.net/~mcimadamore/8254231_v1/webrev

Javadoc:

http://cr.openjdk.java.net/~mcimadamore/8254231_v1/javadoc/jdk/incubator/foreign/package-summary.html

Specdiff (relative to [3]):

http://cr.openjdk.java.net/~mcimadamore/8254231_v1/specdiff_delta/overview-summary.html

CSR:

https://bugs.openjdk.java.net/browse/JDK-8254232



### API Changes

The API changes are actually rather slim:

* `LibraryLookup`
  * This class allows clients to lookup symbols in native libraries; the interface is fairly simple; you can load a library
    by name, or absolute path, and then lookup symbols on that library.
* `FunctionDescriptor`
  * This is an abstraction that is very similar, in spirit, to `MethodType`; it is, at its core, an aggregate of memory
    layouts for the function arguments/return type. A function descriptor is used to describe the signature of a native
    function.
* `CLinker`
  * This is the real star of the show. A `CLinker` has two main methods: `downcallHandle` and `upcallStub`; the first takes
    a native symbol (as obtained from `LibraryLookup`), a `MethodType` and a `FunctionDescriptor` and returns a
    `MethodHandle` instance which can be used to call the target native symbol. The second takes an existing method handle,
    and a `FunctionDescriptor` and returns a new `MemorySegment` corresponding to a code stub allocated by the VM which
    acts as a trampoline from native code to the user-provided method handle. This is very useful for implementing upcalls.
   * This class also contains the various layout constants that should be used by clients when describing native signatures
     (e.g. `C_LONG` and friends); these layouts contain additional ABI classfication information (in the form of layout
     attributes) which is used by the runtime to *infer* how Java arguments should be shuffled for the native call to take
     place.
  * Finally, this class provides some helper functions e.g. so that clients can convert Java strings into C strings and
    back.
* `NativeScope`
  * This is an helper class which allows clients to group together logically related allocations; that is, rather than
    allocating separate memory segments using separate *try-with-resource* constructs, a `NativeScope` allows clients to
    use a _single_ block, and allocate all the required segments there. This is not only an usability boost, but also a
    performance boost, since not all allocation requests will be turned into `malloc` calls.
* `MemorySegment`
  * Only one method added here - namely `handoff(NativeScope)` which allows a segment to be transferred onto an existing
    native scope.

### Safety

The foreign linker API is intrinsically unsafe; many things can go wrong when requesting a native method handle. For
instance, the description of the native signature might be wrong (e.g. have too many arguments) - and the runtime has,
in the general case, no way to detect such mismatches. For these reasons, obtaining a `CLinker` instance is
a *restricted* operation, which can be enabled by specifying the usual JDK property `-Dforeign.restricted=permit` (as
it's the case for other restricted method in the foreign memory API).

### Implementation changes

The Java changes associated with `LibraryLookup` are relative straightforward; the only interesting thing to note here
is that library loading does _not_ depend on class loaders, so `LibraryLookup` is not subject to the same restrictions
which apply to JNI library loading (e.g. same library cannot be loaded by different classloaders).

As for `NativeScope` the changes are again relatively straightforward; it is an API which sits neatly on top of the
foreign meory access API, providing some kind of allocation service which shares the same underlying memory segment(s),
and turns an allocation request into a segment slice, which is a much less expensive operation. `NativeScope` comes in
two variants: there are native scopes for which the allocation size is known a priori, and native scopes which can
grow - these two schemes are implemented by two separate subclasses of `AbstractNativeScopeImpl`.

Of course the bulk of the changes are to support the `CLinker` downcall/upcall routines. These changes cut pretty deep
into the JVM; I'll briefly summarize the goal of some of this changes - for further details, Jorn has put together a
detailed writeup which explains the rationale behind the VM support, with some references to the code [5].

The main idea behind foreign linker is to infer, given a Java method type (expressed as a `MethodType` instance) and
the description of the signature of a native function (expressed as a `FunctionDescriptor` instance) a _recipe_ that
can be used to turn a Java call into the corresponding native call targeting the requested native function.

This inference scheme can be defined in a pretty straightforward fashion by looking at the various ABI specifications
(for instance, see [6] for the SysV ABI, which is the one used on Linux/Mac). The various `CallArranger` classes, of
which we have a flavor for each supported platform, do exactly that kind of inference.

For the inference process to work, we need to attach extra information to memory layouts; it is no longer sufficient to
know e.g. that a layout is 32/64 bits - we need to know whether it is meant to represent a floating point value, or an
integral value; this knowledge is required because floating points are passed in different registers by most ABIs. For
this reason, `CLinker` offers a set of pre-baked, platform-dependent layout constants which contain the required
classification attributes (e.g. a `Clinker.TypeKind` enum value). The runtime extracts this attribute, and performs
classification accordingly.

A native call is decomposed into a sequence of basic, primitive operations, called `Binding` (see the great javadoc on
the `Binding.java` class for more info). There are many such bindings - for instance the `Move` binding is used to move
a value into a specific machine register/stack slot. So, the main job of the various `CallingArranger` classes is to
determine, given a Java `MethodType` and `FunctionDescriptor` what is the set of bindings associated with the
downcall/upcall.

At the heart of the foreign linker support is the `ProgrammableInvoker` class. This class effectively generates a
`MethodHandle` which follows the steps described by the various bindings obtained by `CallArranger`. There are actually
various strategies to interpret these bindings - listed below:

* basic intepreted mode; in this mode, all bindings are interpreted using a stack-based machine written in Java (see
  `BindingInterpreter`), except for the `Move` bindings. For these bindings, the move is implemented by allocating
  a *buffer* (whose size is ABI specific) and by moving all the lowered values into positions within this buffer. The
  buffer is then passed to a piece of assembly code inside the VM which takes values from the buffer and moves them in
  their expected registers/stack slots (note that each position in the buffer corresponds to a different register). This
  is the most general invocation mode, the more "customizable" one, but also the slowest - since for every call there is
  some extra allocation which takes place.

* specialized interpreted mode; same as before, but instead of interpreting the bindings with a stack-based interpreter,
  we generate a method handle chain which effectively interprets all the bindings (again, except `Move` ones).

* intrinsified mode; this is typically used in combination with the specialized interpreted mode described above
  (although it can also be used with the Java-based binding interpreter). The goal here is to remove the buffer
  allocation and copy by introducing an additional JVM intrinsic. If a native call recipe is constant (e.g. the set of
  bindings is constant, which is probably the case if the native method handle is stored in a `static`, `final` field),
  then the VM can generate specialized assembly code which interprets the `Move` binding without the need to go for an
  intermediate buffer. This gives us back performances that are on par with JNI.

For upcalls, the support is not (yet) as advanced, and only the basic interpreted mode is available there. We plan to
add support for intrinsified modes there as well, which should considerably boost perfomances (probably well beyond
what JNI can offer at the moment, since the upcall support in JNI is not very well optimized).

Again, for more readings on the internals of the foreign linker support, please refer to [5].

#### Test changes

Many new tests have been added to validate the foreign linker support; we have high level tests (see `StdLibTest`)
which aim at testing the linker from the perspective of code that clients could write. But we also have deeper
combinatorial tests (see `TestUpcall` and `TestDowncall`) which are meant to stress every corner of the ABI
implementation. There are also some great tests (see the `callarranger` folder) which test the various `CallArranger`s
for all the possible platforms; these tests adopt more of a white-box approach - that is, instead of treating the
linker machinery as a black box and verify that the support works by checking that the native call returned the results
we expected, these tests aims at checking that the set of bindings generated by the call arranger is correct. This also
mean that we can test the classification logic for Windows, Mac and Linux regardless of the platform we're executing on.

Some additional microbenchmarks have been added to compare the performances of downcall/upcall with JNI.

[1] - https://openjdk.java.net/jeps/389
[2] - https://openjdk.java.net/jeps/393
[3] - https://git.openjdk.java.net/jdk/pull/548
[4] - https://github.com/openjdk/panama-foreign/blob/foreign-jextract/doc/panama_ffi.md
[5] - http://cr.openjdk.java.net/~jvernee/docs/Foreign-abi%20downcall%20intrinsics%20technical%20description.html

-------------

Commit messages:
 - Fix more whitespaces
 - Fix whitespaces
 - Remove rejected file
 - More updates
 - Add new files
 - Merge with master
 - Merge branch 'master' into 8254162
 - Remove spurious check on MemoryScope::confineTo
 - Merge branch 'master' into 8254162
 - Simplify example in the toplevel javadoc
 - ... and 8 more: https://git.openjdk.java.net/jdk/compare/5d6a6255...7cf0ef09

Changes: https://git.openjdk.java.net/jdk/pull/634/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=634&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8254231
  Stats: 75468 lines in 264 files changed: 72636 ins; 1596 del; 1236 mod
  Patch: https://git.openjdk.java.net/jdk/pull/634.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/634/head:pull/634

PR: https://git.openjdk.java.net/jdk/pull/634

From prappo at openjdk.java.net  Tue Oct 13 13:38:16 2020
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Tue, 13 Oct 2020 13:38:16 GMT
Subject: RFR: 8247402: rewrite the implementation requirements for
 Map::compute()
In-Reply-To: <9yJU0Hcx60tzcdSIs7KWSVAOvOgaspFWabjMNTbE5cY=.f8815878-be89-44d6-8e70-b5aaec81fe92@github.com>
References: <as4mWIy4TmbEz5C238FHXEL6-gynMYyxaQLQqGV_wVM=.6bac3533-5459-4ad7-8d45-c00e3bfdd121@github.com>
 <9yJU0Hcx60tzcdSIs7KWSVAOvOgaspFWabjMNTbE5cY=.f8815878-be89-44d6-8e70-b5aaec81fe92@github.com>
Message-ID: <St57JlJqipoW5XTGdXzWE6Wz46DXovkvqdyxFbbLTI8=.2170e54d-a40c-45e9-b9e0-343c8f842c31@github.com>

On Tue, 13 Oct 2020 09:30:51 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> This is from the mailing list: http://mail.openjdk.java.net/pipermail/core-libs-dev/2020-June/067213.html
>
> The proposed implementation behaves differently from the existing implementation in the case of `null` value. That is,
> when `map.containsKey(key) == true && map.get(key) == null`. The difference is that the proposed implementation will
> remove the `(key, null)` mapping if `newValue == null`, whereas the existing implementation will not.

Perhaps I should clarify my previous comment. When I said "implementation" what I meant was that pseudo-code inside the
`@implSpec` tag, not the actual body of `default V compute(K key, BiFunction<? super K, ? super V, ? extends V>
remappingFunction)`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/451

From alanb at openjdk.java.net  Tue Oct 13 13:47:22 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 13 Oct 2020 13:47:22 GMT
Subject: RFR: 8254078: DataOutputStream is very slow post-disabling of
 Biased Locking [v6]
In-Reply-To: <OEguX4d1pnZgMjRxZNv6RXIwI4xr2iCdc4TyW7NT4P0=.136853be-9fdd-413e-9584-83a9d6dd5aad@github.com>
References: <lLg_yNI_6LvUZTlM4PyN5ra6AaUZZeT35QzYzV_0CpI=.f2d3cb9e-be30-40dc-922c-dad5bef7feea@github.com>
 <OEguX4d1pnZgMjRxZNv6RXIwI4xr2iCdc4TyW7NT4P0=.136853be-9fdd-413e-9584-83a9d6dd5aad@github.com>
Message-ID: <CxbEpTHLnuTmH5Ee2P1EhvD25f5stL3yULEDYlbICZI=.0b67a9bd-5a76-4feb-9dc6-c7a204e88b1c@github.com>

On Tue, 13 Oct 2020 12:39:27 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> DataOutputStream is very slow post-disabling of Biased Locking. This
>> was discovered when benchmarking a transaction library, which showed
>> significant performance loss when moving to JDK 15. WIth some small
>> changes to DataOutputStream we can get the performance back. There's a
>> JMH benchmark at
>> http://cr.openjdk.java.net/~aph/JDK-8254078/jmh-tests.tar
>> 
>> Some Stream classes use very fine-grained locking.
>> 
>> In particular, writeInt is defined like this:
>> 
>>         out.write((v >>> 24) & 0xFF);
>>         out.write((v >>> 16) & 0xFF);
>>         out.write((v >>> 8) & 0xFF);
>>         out.write((v >>> 0) & 0xFF);
>>         incCount(4);
>> 
>> Unfortunately, ByteArrayOutputStream.write(byte) is defined like this:
>> 
>>     public synchronized void write(int b) {
>>         ensureCapacity(count + 1);
>>         buf[count] = (byte) b;
>>         count += 1;
>>     }
>> 
>> so we acquire and release a lock for every byte that is output.
>> 
>>  For example, writing 4kb of ints goes from 17.3 us/op to 53.9 us/op when biased locking is disabled:
>> 
>> 
>> +UseBiasedLocking DataOutputStreamTest.dataOutputStreamOverByteArray avgt 6 53.895 ? 5.126 us/op
>> -UseBiasedLocking DataOutputStreamTest.dataOutputStreamOverByteArray avgt 6 17.291 ? 4.430 us/op
>> 
>> There are refactorings of DataOutputStream we can do to mitigate this.
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8254078: DataOutputStream is very slow post-disabling of Biased Locking

src/java.base/share/classes/java/io/DataInputStream.java line 38:

> 36:  * A DataInputStream is not safe for use by multiple concurrent
> 37:  * threads. If a DataInputStream is to be used by more than one
> 38:  * thread then access to the data output stream should be controlled

"data output stream" should be "data input stream".

-------------

PR: https://git.openjdk.java.net/jdk/pull/542

From kcr at openjdk.java.net  Tue Oct 13 13:54:14 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Tue, 13 Oct 2020 13:54:14 GMT
Subject: RFR: JDK-8252870: Finalize (remove "incubator" from) jpackage
In-Reply-To: <nDExVoHl1Q5IhPuOpyIz_B80AryRQnHIVVQ70iMQZRQ=.b292ee76-d6a7-474f-95c9-51a2e5449aef@github.com>
References: <HlksY2mFyKG_kkZA6n6JHHIWBGJT3bjmoLG28c9q1EU=.2b9faa66-08b9-4694-a5db-9d9918039642@github.com>
 <nDExVoHl1Q5IhPuOpyIz_B80AryRQnHIVVQ70iMQZRQ=.b292ee76-d6a7-474f-95c9-51a2e5449aef@github.com>
Message-ID: <h1KjbggikWVBcEQqK5qNS93dssPfSDlUfEHb3wk8XPA=.5f9dc2a1-250f-4336-8e77-bb18ae4aaf4a@github.com>

On Tue, 13 Oct 2020 13:49:13 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> JDK-8252870: Finalize (remove "incubator" from) jpackage
>
> I spot checked it and left a couple comments. The rest looks good. I'll review it in more detail later this week.

@andyherrick the "reviewer credit" command should not be used in this manner. It is intended for the case where an
offline review of a PR has been done elsewhere and you wish to record that in the commit. It is not how you ask someone
to do a review.

-------------

PR: https://git.openjdk.java.net/jdk/pull/633

From kcr at openjdk.java.net  Tue Oct 13 13:54:14 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Tue, 13 Oct 2020 13:54:14 GMT
Subject: RFR: JDK-8252870: Finalize (remove "incubator" from) jpackage
In-Reply-To: <HlksY2mFyKG_kkZA6n6JHHIWBGJT3bjmoLG28c9q1EU=.2b9faa66-08b9-4694-a5db-9d9918039642@github.com>
References: <HlksY2mFyKG_kkZA6n6JHHIWBGJT3bjmoLG28c9q1EU=.2b9faa66-08b9-4694-a5db-9d9918039642@github.com>
Message-ID: <nDExVoHl1Q5IhPuOpyIz_B80AryRQnHIVVQ70iMQZRQ=.b292ee76-d6a7-474f-95c9-51a2e5449aef@github.com>

On Tue, 13 Oct 2020 12:51:54 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> JDK-8252870: Finalize (remove "incubator" from) jpackage

I spot checked it and left a couple comments. The rest looks good. I'll review it in more detail later this week.

make/data/symbols/jdk.jpackage-E.sym.txt line 29:

> 27: # ##########################################################
> 28: #
> 29: module name jdk.jpackage

I think you need to revert this. Note this comment:

 # ### THIS FILE IS AUTOMATICALLY GENERATED. DO NOT EDIT. ###

make/data/symbols/symbols line 40:

> 38: platform version C base B files
> java.base-C.sym.txt:java.compiler-C.sym.txt:java.desktop-C.sym.txt:java.naming-C.sym.txt:java.rmi-C.sym.txt:java.xml-C.sym.txt:jdk.compiler-C.sym.txt:jdk.jfr-C.sym.txt:jdk.jsobject-C.sym.txt:jdk.unsupported-C.sym.txt
> 39: platform version D base C files
> java.base-D.sym.txt:java.compiler-D.sym.txt:java.desktop-D.sym.txt:java.management-D.sym.txt:java.management.rmi-D.sym.txt:java.net.http-D.sym.txt:java.security.jgss-D.sym.txt:java.xml-D.sym.txt:java.xml.crypto-D.sym.txt:jdk.compiler-D.sym.txt:jdk.httpserver-D.sym.txt:jdk.jartool-D.sym.txt:jdk.javadoc-D.sym.txt:jdk.jlink-D.sym.txt:jdk.jshell-D.sym.txt
> 40: platform version E base D files
> java.base-E.sym.txt:java.compiler-E.sym.txt:java.desktop-E.sym.txt:java.xml-E.sym.txt:jdk.compiler-E.sym.txt:jdk.httpserver-E.sym.txt:jdk.incubator.foreign-E.sym.txt:jdk.jpackage-E.sym.txt:jdk.jfr-E.sym.txt:jdk.jlink-E.sym.txt:jdk.jshell-E.sym.txt:jdk.jsobject-E.sym.txt:jdk.management-E.sym.txt:jdk.net-E.sym.txt:jdk.pack-E.sym.txt

Similarly, I think you need to revert this.

src/jdk.jpackage/share/classes/module-info.java line 49:

> 47:  */
> 48:
> 49: module jdk.jpackage {

Change to `@since 16`

-------------

PR: https://git.openjdk.java.net/jdk/pull/633

From rriggs at openjdk.java.net  Tue Oct 13 14:20:20 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 13 Oct 2020 14:20:20 GMT
Subject: RFR: 8254161: Prevent instantiation of EnumSet subclasses through
 deserialization
In-Reply-To: <etFbiCFeHwDnYXo3yzhQT66jXhSMbRn57DEGZz-d3V8=.55b262dd-27a1-48c2-ae9b-ce6a55f45b53@github.com>
References: <etFbiCFeHwDnYXo3yzhQT66jXhSMbRn57DEGZz-d3V8=.55b262dd-27a1-48c2-ae9b-ce6a55f45b53@github.com>
Message-ID: <j-AGoET0PIT5z4a8-ay-MlbvUiKACD2kFPwc3-p52Tw=.2a830581-5001-40db-b13e-565dbdc550cf@github.com>

On Mon, 12 Oct 2020 13:47:46 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

> TL;DR add EnumSet::readObjectNoData()
> 
> EnumSet is an exemplar of the Serialization Proxy Pattern. As such, it
> should strictly implement that pattern and demonstrate how best to
> defend against inappropriate instantiation through deserialization.
> 
> EnumSet is an extensible class. There are two subclasses in the JDK,
> RegularEnumSet and JumboEnumSet. Since the serialization of an EnumSet
> object writes a replacement object to the serial stream, a serial proxy
> object, then stream objects of type RegularEnumSet or JumboEnumSet are
> not expected in the serial stream. However, if they are present in the
> serial stream, then, during deserialization, the EnumSet::readObject
> method will be invoked. EnumSet::readObject unconditionally throws an
> exception, thus preventing further deserialization of the stream object.
> In this way, stream objects that are subclasses of EnumSet are prevented
> from being instantiated through deserialization. But this is not
> sufficient to prevent such in all scenarios.
> 
> A stream object whose local class equivalent of the specified stream
> class descriptor is a subclasses of EnumSet, but whose specified stream
> class descriptor does not list EnumSet as a superClass, may be
> instantiated through deserialization. Since the stream class descriptor
> does not list EnumSet as a superclass, then the defensive
> EnumSet::readObject is never invoked. To prevent such objects from
> being deserialized, an EnumSet::readObjectNoData() should be added -
> whose implementation unconditionally throws an exception, similar to
> that of the existing EnumSet::readObject.

Marked as reviewed by rriggs (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/611

From kcr at openjdk.java.net  Tue Oct 13 14:34:20 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Tue, 13 Oct 2020 14:34:20 GMT
Subject: RFR: JDK-8252870: Finalize (remove "incubator" from) jpackage
In-Reply-To: <h1KjbggikWVBcEQqK5qNS93dssPfSDlUfEHb3wk8XPA=.5f9dc2a1-250f-4336-8e77-bb18ae4aaf4a@github.com>
References: <HlksY2mFyKG_kkZA6n6JHHIWBGJT3bjmoLG28c9q1EU=.2b9faa66-08b9-4694-a5db-9d9918039642@github.com>
 <nDExVoHl1Q5IhPuOpyIz_B80AryRQnHIVVQ70iMQZRQ=.b292ee76-d6a7-474f-95c9-51a2e5449aef@github.com>
 <h1KjbggikWVBcEQqK5qNS93dssPfSDlUfEHb3wk8XPA=.5f9dc2a1-250f-4336-8e77-bb18ae4aaf4a@github.com>
Message-ID: <gqJpQI8gecZrqC_XsbTOPrR0kkapJjE9Or3am4S7xzY=.cf1287e9-2cba-4930-8fd9-0658ccef764c@github.com>

On Tue, 13 Oct 2020 13:51:27 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> I spot checked it and left a couple comments. The rest looks good. I'll review it in more detail later this week.
>
> @andyherrick the "reviewer credit" command should not be used in this manner. It is intended for the case where an
> offline review of a PR has been done elsewhere and you wish to record that in the commit. It is not how you ask someone
> to do a review.

You can't directly, so I usually just mention in a comment who I want to review it. If you use their GitHub username it
will notify them (unless they have disabled all notifications). Something like this:

@prrace @kevinrushforth @sashamatveev @alexeysemenyukoracle please review

-------------

PR: https://git.openjdk.java.net/jdk/pull/633

From herrick at openjdk.java.net  Tue Oct 13 14:48:40 2020
From: herrick at openjdk.java.net (Andy Herrick)
Date: Tue, 13 Oct 2020 14:48:40 GMT
Subject: RFR: JDK-8252870: Finalize (remove "incubator" from) jpackage [v2]
In-Reply-To: <HlksY2mFyKG_kkZA6n6JHHIWBGJT3bjmoLG28c9q1EU=.2b9faa66-08b9-4694-a5db-9d9918039642@github.com>
References: <HlksY2mFyKG_kkZA6n6JHHIWBGJT3bjmoLG28c9q1EU=.2b9faa66-08b9-4694-a5db-9d9918039642@github.com>
Message-ID: <C1gKE74s6f3xjeBRJ_pYlbqMrLcfkbMSq1jJdvcf92w=.e74b4173-3063-4728-b003-683fa9f85035@github.com>

> JDK-8252870: Finalize (remove "incubator" from) jpackage

Andy Herrick has updated the pull request incrementally with one additional commit since the last revision:

  JDK-8252870: Finalize (remove "incubator" from) jpackage
    - reverting two auto-generated files, and changing module-info to "@since 16"

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/633/files
  - new: https://git.openjdk.java.net/jdk/pull/633/files/4b95b41c..4b1e6363

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=633&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=633&range=00-01

  Stats: 64 lines in 4 files changed: 31 ins; 31 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/633.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/633/head:pull/633

PR: https://git.openjdk.java.net/jdk/pull/633

From herrick at openjdk.java.net  Tue Oct 13 15:03:19 2020
From: herrick at openjdk.java.net (Andy Herrick)
Date: Tue, 13 Oct 2020 15:03:19 GMT
Subject: RFR: JDK-8252870: Finalize (remove "incubator" from) jpackage [v2]
In-Reply-To: <nDExVoHl1Q5IhPuOpyIz_B80AryRQnHIVVQ70iMQZRQ=.b292ee76-d6a7-474f-95c9-51a2e5449aef@github.com>
References: <HlksY2mFyKG_kkZA6n6JHHIWBGJT3bjmoLG28c9q1EU=.2b9faa66-08b9-4694-a5db-9d9918039642@github.com>
 <nDExVoHl1Q5IhPuOpyIz_B80AryRQnHIVVQ70iMQZRQ=.b292ee76-d6a7-474f-95c9-51a2e5449aef@github.com>
Message-ID: <PmX277Vatm-0wl2mqGreRhcBdlFxO-tX0GioqOV4b4M=.9adf4a5e-975f-4238-8997-faf2021a3ae2@github.com>

On Tue, 13 Oct 2020 13:44:22 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Andy Herrick has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   JDK-8252870: Finalize (remove "incubator" from) jpackage
>>     - reverting two auto-generated files, and changing module-info to "@since 16"
>
> make/data/symbols/jdk.jpackage-E.sym.txt line 29:
> 
>> 27: # ##########################################################
>> 28: #
>> 29: module name jdk.jpackage
> 
> I think you need to revert this. Note this comment:
> 
>  # ### THIS FILE IS AUTOMATICALLY GENERATED. DO NOT EDIT. ###

reverted

> make/data/symbols/symbols line 40:
> 
>> 38: platform version C base B files
>> java.base-C.sym.txt:java.compiler-C.sym.txt:java.desktop-C.sym.txt:java.naming-C.sym.txt:java.rmi-C.sym.txt:java.xml-C.sym.txt:jdk.compiler-C.sym.txt:jdk.jfr-C.sym.txt:jdk.jsobject-C.sym.txt:jdk.unsupported-C.sym.txt
>> 39: platform version D base C files
>> java.base-D.sym.txt:java.compiler-D.sym.txt:java.desktop-D.sym.txt:java.management-D.sym.txt:java.management.rmi-D.sym.txt:java.net.http-D.sym.txt:java.security.jgss-D.sym.txt:java.xml-D.sym.txt:java.xml.crypto-D.sym.txt:jdk.compiler-D.sym.txt:jdk.httpserver-D.sym.txt:jdk.jartool-D.sym.txt:jdk.javadoc-D.sym.txt:jdk.jlink-D.sym.txt:jdk.jshell-D.sym.txt
>> 40: platform version E base D files
>> java.base-E.sym.txt:java.compiler-E.sym.txt:java.desktop-E.sym.txt:java.xml-E.sym.txt:jdk.compiler-E.sym.txt:jdk.httpserver-E.sym.txt:jdk.incubator.foreign-E.sym.txt:jdk.jpackage-E.sym.txt:jdk.jfr-E.sym.txt:jdk.jlink-E.sym.txt:jdk.jshell-E.sym.txt:jdk.jsobject-E.sym.txt:jdk.management-E.sym.txt:jdk.net-E.sym.txt:jdk.pack-E.sym.txt
> 
> Similarly, I think you need to revert this.

reverted

> src/jdk.jpackage/share/classes/module-info.java line 49:
> 
>> 47:  */
>> 48:
>> 49: module jdk.jpackage {
> 
> Change to `@since 16`

changed to @since16

-------------

PR: https://git.openjdk.java.net/jdk/pull/633

From psandoz at openjdk.java.net  Tue Oct 13 16:14:40 2020
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Tue, 13 Oct 2020 16:14:40 GMT
Subject: RFR: 8223347: Integration of Vector API (Incubator) [v3]
In-Reply-To: <-PE4TwXgvq2bemAn_8csjn4_j7zoAolnQz6QQt3z0Wk=.eaa9999f-0713-4349-b31d-934717aa37a1@github.com>
References: <-PE4TwXgvq2bemAn_8csjn4_j7zoAolnQz6QQt3z0Wk=.eaa9999f-0713-4349-b31d-934717aa37a1@github.com>
Message-ID: <-wiRtZZKucOjqFnqeDjVm3B8BaThwGyDdt4aFo9t2-g=.2b4350f4-4704-4857-82e4-7e014898b2da@github.com>

> This pull request is for integration of the Vector API. It was previously reviewed under conditions when mercurial was
> used for the source code control system. Review threads can be found here (searching for issue number 8223347 in the
> title):  https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-April/thread.html
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-May/thread.html
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-July/thread.html
> 
> If mercurial was still being used the code would be pushed directly, once the CSR is approved. However, in this case a
> pull request is required and needs explicit reviewer approval. Between the final review and this pull request no code
> has changed, except for that related to merging.

Paul Sandoz has updated the pull request incrementally with one additional commit since the last revision:

  Fix related to merge

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/367/files
  - new: https://git.openjdk.java.net/jdk/pull/367/files/9cca17b8..d5acb4ff

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=367&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=367&range=01-02

  Stats: 76 lines in 1 file changed: 0 ins; 0 del; 76 mod
  Patch: https://git.openjdk.java.net/jdk/pull/367.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/367/head:pull/367

PR: https://git.openjdk.java.net/jdk/pull/367

From mchung at openjdk.java.net  Tue Oct 13 16:18:12 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 13 Oct 2020 16:18:12 GMT
Subject: RFR: 8251861: Remove unused jdk.internal.ref.SoftCleanable and
 WeakCleanable
In-Reply-To: <PXpykxg5wYq8DcCcEglVziPOCW1m4FEqx9EupvNM7go=.3de80256-238e-40bd-86cc-5ed7576f4798@github.com>
References: <PXpykxg5wYq8DcCcEglVziPOCW1m4FEqx9EupvNM7go=.3de80256-238e-40bd-86cc-5ed7576f4798@github.com>
Message-ID: <L0H25eNqvZQzpK3q_40N4nsmwf_rqaEYM6a8913Ttsk=.7eb7c9b7-2874-469f-bd41-7a77fdaf6704@github.com>

On Mon, 12 Oct 2020 19:36:52 GMT, Kiran Sidhartha Ravikumar <kravikumar at openjdk.org> wrote:

> Hi Guys,
> 
> Please review the fix to remove jdk.internal.ref.SoftCleanable and WeakCleanable classes as there is no visible usage
> of them in JDK. Currently, only PhantomCleanable is used.
> More information can be viewed at https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-August/067997.html
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8251861
> 
> Thanks,
> Kiran

Thanks for taking this one.  Looks okay.

-------------

Marked as reviewed by mchung (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/616

From rriggs at openjdk.java.net  Tue Oct 13 16:19:29 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 13 Oct 2020 16:19:29 GMT
Subject: RFR: 8251989: Hex formatting and parsing utility
In-Reply-To: <lv3X2v4KfUM8fxWZyX8_rwGa5wVnysBQjvqnAJaDYUU=.2b36709d-5547-411d-a609-fa465c4ce17f@github.com>
References: <HSEn47GMS1K3g57mrTZeQk-WZHl3pKGHpX_OOf8VnsU=.740863c2-f9e4-43c4-b500-614aab4078b1@github.com>
 <lv3X2v4KfUM8fxWZyX8_rwGa5wVnysBQjvqnAJaDYUU=.2b36709d-5547-411d-a609-fa465c4ce17f@github.com>
Message-ID: <-mHsww0Ju9lmUWruOsKsiXIa6WOHbSaZ46JyCH6vGns=.7fb48d7c-9926-4602-9282-5af922558c3b@github.com>

On Mon, 12 Oct 2020 20:41:20 GMT, Marcono1234 <github.com+11685886+Marcono1234 at openjdk.org> wrote:

>> java.util.HexFormat utility:
>> 
>>  - Format and parse hexadecimal strings, with parameters for delimiter, prefix, suffix and upper/lowercase
>>  - Static factories and builder methods to create HexFormat copies with modified parameters.
>>  - Consistent naming of methods for conversion of byte arrays to formatted strings and back: formatHex and parseHex
>>  - Consistent naming of methods for conversion of primitive types: toHexDigits... and fromHexDigits...
>>  - Prefix and suffixes now apply to each formatted value, not the string as a whole
>>  - Using java.util.Appendable as a target for buffered conversions so output to Writers and PrintStreams
>>    like System.out are supported in addition to StringBuilder. (IOExceptions are converted to unchecked exceptions)
>>  - Immutable and thread safe, a "value-based" class
>> 
>> See the [HexFormat
>> javadoc](http://cr.openjdk.java.net/~rriggs/8251989-hex-formatter/java.base/java/util/HexFormat.html) for details.
>> Review comments and suggestions welcome.
>
> test/jdk/java/util/HexFormat/HexFormatTest.java line 406:
> 
>> 404:
>> 405:             int byteVal = hex.fromHexDigits(byteStr);
>> 406:             assert(byteStr.equals("7f"));
> 
> Why use regular `assert` statements in this test method? TestNG's methods likely yield more useful results.

These code fragments are the examples used in the javadoc; making a simple copy/paste from working code to the javadoc.
In the example code `assert`, a Java language construct is cleaner than showing testng assertions).

-------------

PR: https://git.openjdk.java.net/jdk/pull/482

From smarks at openjdk.java.net  Tue Oct 13 16:20:15 2020
From: smarks at openjdk.java.net (Stuart Marks)
Date: Tue, 13 Oct 2020 16:20:15 GMT
Subject: RFR: 8247402: rewrite the implementation requirements for
 Map::compute()
In-Reply-To: <St57JlJqipoW5XTGdXzWE6Wz46DXovkvqdyxFbbLTI8=.2170e54d-a40c-45e9-b9e0-343c8f842c31@github.com>
References: <as4mWIy4TmbEz5C238FHXEL6-gynMYyxaQLQqGV_wVM=.6bac3533-5459-4ad7-8d45-c00e3bfdd121@github.com>
 <9yJU0Hcx60tzcdSIs7KWSVAOvOgaspFWabjMNTbE5cY=.f8815878-be89-44d6-8e70-b5aaec81fe92@github.com>
 <St57JlJqipoW5XTGdXzWE6Wz46DXovkvqdyxFbbLTI8=.2170e54d-a40c-45e9-b9e0-343c8f842c31@github.com>
Message-ID: <aVTmU-nFmLJv_zrgi7hlwc3fezw3CThbEAq5ojWpf24=.460a1329-87aa-4a2c-ad44-6747323137de@github.com>

On Tue, 13 Oct 2020 13:35:37 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> The proposed implementation behaves differently from the existing implementation in the case of `null` value. That is,
>> when `map.containsKey(key) == true && map.get(key) == null`. The difference is that the proposed implementation will
>> remove the `(key, null)` mapping if `newValue == null`, whereas the existing implementation will not.
>
> Perhaps I should clarify my previous comment. When I said "implementation" what I meant was that pseudo-code inside the
> `@implSpec` tag, not the actual body of `default V compute(K key, BiFunction<? super K, ? super V, ? extends V>
> remappingFunction)`.

This change is to a normative portion of the specification, and as such will require a CSR.

-------------

PR: https://git.openjdk.java.net/jdk/pull/451

From rriggs at openjdk.java.net  Tue Oct 13 16:27:11 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 13 Oct 2020 16:27:11 GMT
Subject: RFR: 8251989: Hex formatting and parsing utility
In-Reply-To: <lv3X2v4KfUM8fxWZyX8_rwGa5wVnysBQjvqnAJaDYUU=.2b36709d-5547-411d-a609-fa465c4ce17f@github.com>
References: <HSEn47GMS1K3g57mrTZeQk-WZHl3pKGHpX_OOf8VnsU=.740863c2-f9e4-43c4-b500-614aab4078b1@github.com>
 <lv3X2v4KfUM8fxWZyX8_rwGa5wVnysBQjvqnAJaDYUU=.2b36709d-5547-411d-a609-fa465c4ce17f@github.com>
Message-ID: <Uc4hqx2BxAFVCOqpn8XoTXNDJewaaBLzy-92Gv6LFGI=.0b4c0cb0-6226-47b5-852e-d873eff8fc37@github.com>

On Mon, 12 Oct 2020 22:36:34 GMT, Marcono1234 <github.com+11685886+Marcono1234 at openjdk.org> wrote:

>> java.util.HexFormat utility:
>> 
>>  - Format and parse hexadecimal strings, with parameters for delimiter, prefix, suffix and upper/lowercase
>>  - Static factories and builder methods to create HexFormat copies with modified parameters.
>>  - Consistent naming of methods for conversion of byte arrays to formatted strings and back: formatHex and parseHex
>>  - Consistent naming of methods for conversion of primitive types: toHexDigits... and fromHexDigits...
>>  - Prefix and suffixes now apply to each formatted value, not the string as a whole
>>  - Using java.util.Appendable as a target for buffered conversions so output to Writers and PrintStreams
>>    like System.out are supported in addition to StringBuilder. (IOExceptions are converted to unchecked exceptions)
>>  - Immutable and thread safe, a "value-based" class
>> 
>> See the [HexFormat
>> javadoc](http://cr.openjdk.java.net/~rriggs/8251989-hex-formatter/java.base/java/util/HexFormat.html) for details.
>> Review comments and suggestions welcome.
>
> src/java.base/share/classes/java/util/HexFormat.java line 1015:
> 
>> 1013:      */
>> 1014:     @Override
>> 1015:     public String toString() {
> 
> Might be useful to also include the class name?

The caller may need to provide their own context for the output.

-------------

PR: https://git.openjdk.java.net/jdk/pull/482

From rriggs at openjdk.java.net  Tue Oct 13 16:38:13 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 13 Oct 2020 16:38:13 GMT
Subject: RFR: 8251989: Hex formatting and parsing utility
In-Reply-To: <lv3X2v4KfUM8fxWZyX8_rwGa5wVnysBQjvqnAJaDYUU=.2b36709d-5547-411d-a609-fa465c4ce17f@github.com>
References: <HSEn47GMS1K3g57mrTZeQk-WZHl3pKGHpX_OOf8VnsU=.740863c2-f9e4-43c4-b500-614aab4078b1@github.com>
 <lv3X2v4KfUM8fxWZyX8_rwGa5wVnysBQjvqnAJaDYUU=.2b36709d-5547-411d-a609-fa465c4ce17f@github.com>
Message-ID: <L--XhfhdVOFf_ZmtrzkB-JByM7oq6rk7NfkF4dPeuc8=.c11648ad-0dcc-4b0f-a271-fca63311ffaf@github.com>

On Mon, 12 Oct 2020 20:48:52 GMT, Marcono1234 <github.com+11685886+Marcono1234 at openjdk.org> wrote:

>> java.util.HexFormat utility:
>> 
>>  - Format and parse hexadecimal strings, with parameters for delimiter, prefix, suffix and upper/lowercase
>>  - Static factories and builder methods to create HexFormat copies with modified parameters.
>>  - Consistent naming of methods for conversion of byte arrays to formatted strings and back: formatHex and parseHex
>>  - Consistent naming of methods for conversion of primitive types: toHexDigits... and fromHexDigits...
>>  - Prefix and suffixes now apply to each formatted value, not the string as a whole
>>  - Using java.util.Appendable as a target for buffered conversions so output to Writers and PrintStreams
>>    like System.out are supported in addition to StringBuilder. (IOExceptions are converted to unchecked exceptions)
>>  - Immutable and thread safe, a "value-based" class
>> 
>> See the [HexFormat
>> javadoc](http://cr.openjdk.java.net/~rriggs/8251989-hex-formatter/java.base/java/util/HexFormat.html) for details.
>> Review comments and suggestions welcome.
>
> src/java.base/share/classes/java/util/HexFormat.java line 45:
> 
>> 43:  * the {@code withXXX} methods return copies of {@code HexFormat}ters modified
>> 44:  * {@link #withPrefix(String)}, {@link #withSuffix(String)}, {@link #withDelimiter(String)}
>> 45:  * or choice of {@link #withUppercase()} or {@link #withLowercase()} parameters using
> 
> Would <code>withUpper<b>C</b>ase</code> and <code>withLower<b>C</b>ase</code> (captial "C") be better to be consistent
> with `String.toUpperCase` and `Character.toUpperCase`?

Good point, the uppercase() method changes too;  ->  isUpperCase().

-------------

PR: https://git.openjdk.java.net/jdk/pull/482

From rriggs at openjdk.java.net  Tue Oct 13 16:42:17 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 13 Oct 2020 16:42:17 GMT
Subject: RFR: 8251861: Remove unused jdk.internal.ref.SoftCleanable and
 WeakCleanable
In-Reply-To: <PXpykxg5wYq8DcCcEglVziPOCW1m4FEqx9EupvNM7go=.3de80256-238e-40bd-86cc-5ed7576f4798@github.com>
References: <PXpykxg5wYq8DcCcEglVziPOCW1m4FEqx9EupvNM7go=.3de80256-238e-40bd-86cc-5ed7576f4798@github.com>
Message-ID: <6iEtXcw8J7G4iHPSuG8gWaACHVOk7pISMJ8rJcqCN7I=.3a3f386d-ee9e-46b6-bb01-e9f2e73c0168@github.com>

On Mon, 12 Oct 2020 19:36:52 GMT, Kiran Sidhartha Ravikumar <kravikumar at openjdk.org> wrote:

> Hi Guys,
> 
> Please review the fix to remove jdk.internal.ref.SoftCleanable and WeakCleanable classes as there is no visible usage
> of them in JDK. Currently, only PhantomCleanable is used.
> More information can be viewed at https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-August/067997.html
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8251861
> 
> Thanks,
> Kiran

Marked as reviewed by rriggs (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/616

From kravikumar at openjdk.java.net  Tue Oct 13 16:56:15 2020
From: kravikumar at openjdk.java.net (Kiran Sidhartha Ravikumar)
Date: Tue, 13 Oct 2020 16:56:15 GMT
Subject: RFR: 8251861: Remove unused jdk.internal.ref.SoftCleanable and
 WeakCleanable
In-Reply-To: <6iEtXcw8J7G4iHPSuG8gWaACHVOk7pISMJ8rJcqCN7I=.3a3f386d-ee9e-46b6-bb01-e9f2e73c0168@github.com>
References: <PXpykxg5wYq8DcCcEglVziPOCW1m4FEqx9EupvNM7go=.3de80256-238e-40bd-86cc-5ed7576f4798@github.com>
 <6iEtXcw8J7G4iHPSuG8gWaACHVOk7pISMJ8rJcqCN7I=.3a3f386d-ee9e-46b6-bb01-e9f2e73c0168@github.com>
Message-ID: <pLhshuFI_tbPAkJWj7mYzlPVbpX-V5VXXT8ulSoOR5U=.a7681dc6-1431-438b-9e01-51e548eb7b32@github.com>

On Tue, 13 Oct 2020 16:39:51 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Hi Guys,
>> 
>> Please review the fix to remove jdk.internal.ref.SoftCleanable and WeakCleanable classes as there is no visible usage
>> of them in JDK. Currently, only PhantomCleanable is used.
>> More information can be viewed at https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-August/067997.html
>> 
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8251861
>> 
>> Thanks,
>> Kiran
>
> Marked as reviewed by rriggs (Reviewer).

Thanks guys

-------------

PR: https://git.openjdk.java.net/jdk/pull/616

From lancea at openjdk.java.net  Tue Oct 13 16:59:17 2020
From: lancea at openjdk.java.net (Lance Andersen)
Date: Tue, 13 Oct 2020 16:59:17 GMT
Subject: RFR: 8253952: Refine ZipOutputStream.putNextEntry() to
 recalculate ZipEntry's compressed size [v4]
In-Reply-To: <KcBcWMkN_kJ7JZXC3yWKbF1KEYX_cd0iYofyGSRuMgk=.1a0b3b65-8aeb-4de8-b38a-cb282966f947@github.com>
References: <0nq5oFKOj6AZqCW6jF268-6oKRI6UkS6TRIHo-_5vKw=.d13c7016-4473-4b20-9117-100b368d3716@github.com>
 <c12QhQcAA4YctkyHYdULM9mSQ6KI9iqZM5MAuLJroGE=.a84fc8f5-411c-4ec0-b421-c3cf62c849c7@github.com>
 <sCZNDJVA17V3tGPsCYV88AODMtfrhTfLlii5q0Qz4u8=.531888c3-19a9-4572-acda-81183a81e08f@github.com>
 <cCg_cQOTmL40ZA0Hta1XGqlG72Be8dFKTZOMRxIBtHc=.3fd89e55-6854-49df-a007-4e3252a92e7a@github.com>
 <KcBcWMkN_kJ7JZXC3yWKbF1KEYX_cd0iYofyGSRuMgk=.1a0b3b65-8aeb-4de8-b38a-cb282966f947@github.com>
Message-ID: <O5F-s_zbTQWT550zxIr8IZ9DB7_aLB8LF4zpNL3pRK0=.c745398a-776c-4011-b392-5899ac24b21e@github.com>

On Wed, 7 Oct 2020 17:04:02 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> I totally agree. What about using just the last sentence (as you've proposed) in the spec section and add the other to
>> as @implNote? O you think the last sentence will be enough?
>
> I think we can just go with the last sentence/paragraph.  Perhaps  we can further simplify the  paragraph/sentence with
> something like:
> The compressed entry size will be recalculated  for compressed (DEFLATED) entries when  ZipEntry::setCompressedSize has
> not been explicitly called on the ZipEntry.
> or
> 
> The compressed (DEFLATED) entry size will be recalculated when  ZipEntry::setCompressedSize has not been explicitly
> called on the ZipEntry.

I think the wording looks much better now

-------------

PR: https://git.openjdk.java.net/jdk/pull/520

From kravikumar at openjdk.java.net  Tue Oct 13 17:12:13 2020
From: kravikumar at openjdk.java.net (Kiran Sidhartha Ravikumar)
Date: Tue, 13 Oct 2020 17:12:13 GMT
Subject: Integrated: 8251861: Remove unused jdk.internal.ref.SoftCleanable and
 WeakCleanable
In-Reply-To: <PXpykxg5wYq8DcCcEglVziPOCW1m4FEqx9EupvNM7go=.3de80256-238e-40bd-86cc-5ed7576f4798@github.com>
References: <PXpykxg5wYq8DcCcEglVziPOCW1m4FEqx9EupvNM7go=.3de80256-238e-40bd-86cc-5ed7576f4798@github.com>
Message-ID: <Xj5R5HRxLtoVF97YibGMqaoTerV2ApW9l4EA7i_J6ww=.7827e7bc-62b6-4ea4-a4e6-cccda7d90055@github.com>

On Mon, 12 Oct 2020 19:36:52 GMT, Kiran Sidhartha Ravikumar <kravikumar at openjdk.org> wrote:

> Hi Guys,
> 
> Please review the fix to remove jdk.internal.ref.SoftCleanable and WeakCleanable classes as there is no visible usage
> of them in JDK. Currently, only PhantomCleanable is used.
> More information can be viewed at https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-August/067997.html
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8251861
> 
> Thanks,
> Kiran

This pull request has now been integrated.

Changeset: ba24f963
Author:    Kiran Sidhartha Ravikumar <kravikumar at openjdk.org>
Committer: Sean Coffey <coffeys at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ba24f963
Stats:     635 lines in 4 files changed: 0 ins; 633 del; 2 mod

8251861: Remove unused jdk.internal.ref.SoftCleanable and WeakCleanable

Reviewed-by: mchung, rriggs

-------------

PR: https://git.openjdk.java.net/jdk/pull/616

From rrich at openjdk.java.net  Tue Oct 13 17:13:24 2020
From: rrich at openjdk.java.net (Richard Reingruber)
Date: Tue, 13 Oct 2020 17:13:24 GMT
Subject: RFR: 8227745: Enable Escape Analysis for Better Performance in
 the Presence of JVMTI Agents [v9]
In-Reply-To: <loXsS2Do_nv5-_VbltTan-Imb1whQGFhtV26DygFkfE=.8901efc3-eaff-45e3-ae8e-7d4c1f1f7d5b@github.com>
References: <Ll2RereRbuQLgFtIjv9pS92kPvCVuo-BI0cP1zGjVbo=.dad3a33c-0fc3-44fd-810a-f01448cf564c@github.com>
 <5O9n8cKBJyjhp2cNOVD2PcpKQiXqEs5BJjkW1lH-5EM=.044a510e-6517-4564-a3db-00c7951f0b22@github.com>
 <kXS8IuV-hgsemXHvzdEUd3V5SPCzxY0ClFQQpL0aDLw=.7aef142a-acfa-4b3f-9568-5af89f7871df@github.com>
 <bUQfqefhgv1bsscHkiMJFA5bsVv1MELncEATFRgO_Po=.9c234693-366a-48b4-aa8c-8e1c7c476852@github.com>
 <loXsS2Do_nv5-_VbltTan-Imb1whQGFhtV26DygFkfE=.8901efc3-eaff-45e3-ae8e-7d4c1f1f7d5b@github.com>
Message-ID: <jpUvZCySps2yK0dCZbClTHUkU2yywT81Ch-Eim6UOdc=.3f404d18-b86a-4db2-92ca-bc9c021da833@github.com>

On Sun, 11 Oct 2020 07:20:07 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>>> 
>>> 
>>> I tried to run testing with latest changes and latest JDK and build failed:
>>> src/hotspot/share/runtime/escapeBarrier.cpp:310:35: error: no matching function for call to
>>> 'StackFrameStream::StackFrameStream(JavaThread*&)' 310 | StackFrameStream fst(deoptee);
>> 
>> I noticed this too. I wanted to test with ZGC before pushing the small
>> fix. Unfortunately I get
>> 
>> #  Internal Error (/priv/d038402/git/reinrich/jdk_ea_new/src/hotspot/share/runtime/stackWatermark.inline.hpp:67),
>> pid=90890, tid=90912 #  assert(processing_started()) failed: Processing should already have started
>> 
>> [...]
>> 
>> Current thread (0x00007f749c25b1c0):  JavaThread "JDWP Transport Listener: dt_socket" daemon [_thread_in_vm, id=90912,
>> stack(0x00007f7474c9f000,0x00007f7474da0000)] _threads_hazard_ptr=0x00007f749c2b00c0, _nested_threads_hazard_ptr_cnt=0
>> Stack: [0x00007f7474c9f000,0x00007f7474da0000],  sp=0x00007f7474d9c240,  free space=1012k
>> Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
>> V  [libjvm.so+0x15b3255]  StackWatermarkSet::on_iteration(JavaThread*, frame const&)+0xa5
>> V  [libjvm.so+0xa1024f]  frame::sender(RegisterMap*) const+0x13f
>> V  [libjvm.so+0xa048f8]  frame::real_sender(RegisterMap*) const+0x18
>> V  [libjvm.so+0x176261b]  vframe::sender() const+0xeb
>> V  [libjvm.so+0x16cd56b]  JavaThread::last_java_vframe(RegisterMap*)+0x5b
>> V  [libjvm.so+0xfa7a56]  JvmtiEnvBase::vframeFor(JavaThread*, int)+0x46
>> V  [libjvm.so+0xfab8e5]  JvmtiEnvBase::check_top_frame(JavaThread*, JavaThread*, jvalue, TosState, Handle*)+0x1f5
>> V  [libjvm.so+0xfac13e]  JvmtiEnvBase::force_early_return(JavaThread*, jvalue, TosState)+0x15e
>> V  [libjvm.so+0xf36fa8]  jvmti_ForceEarlyReturnLong+0x258
>> C  [libjdwp.so+0xa8b3]  forceEarlyReturn+0x293
>> C  [libjdwp.so+0x12945]  debugLoop_run+0x1f5
>> C  [libjdwp.so+0x25bb3]  attachThread+0x33
>> V  [libjvm.so+0xfcf524]  JvmtiAgentThread::call_start_function()+0x1d4
>> V  [libjvm.so+0x16cc8f7]  JavaThread::thread_main_inner()+0x247
>> V  [libjvm.so+0x16d1ce8]  Thread::call_run()+0xf8
>> V  [libjvm.so+0x12dd75e]  thread_native_entry(Thread*)+0x10e
>> 
>> In the test case
>> `EAForceEarlyReturnOfInlinedMethodWithScalarReplacedObjectsReallocFailure` of the
>> new test `jdk/com/sun/jdi/EATests.java`
>> 
>> So far I do not have an indication that the failure is caused by this change but
>> when I run the test with -XX:-DoEscapeAnalysis then the test succeeds.
>> 
>> I need to look more into it. Wish I was a ZGC expert :)
>> 
>> Anyway I pushed the build fix. Tests succeed with default GC.
>
> The crash described above happens after JDK-8253180
> (https://github.com/openjdk/jdk/commit/b9873e18330b7e43ca47bc1c0655e7ab20828f7a) when executing `EATests.java` with
> ZGC:  make run-test TEST=test/jdk/com/sun/jdi/EATests.java JTREG=VM_OPTIONS=-XX:+UseZGC
> 
> My understanding of JDK-8253180 (and ZGC) is rather vague. To me it looks as if stackwalks outside of a
> safepoint/handshake on suspended threads are currently not supported. It would be my understanding that
> `StackWatermarkSet::start_processing()` needs to be called before walking the stack of a thread. Currently this is only
> done in preparation of a safepoint or handshake.  `JvmtiEnvBase::check_top_frame()` walks the stack of a suspended
> thread without safepoint/handshake. This triggers the crash in my opinion. When `StackWatermarkSet::start_processing()`
> is called before the test succeeds.  I will ask Erik ?sterlund about this.

The issues with ZGC concurrent thread stack processing will be resolved with #627

-------------

PR: https://git.openjdk.java.net/jdk/pull/119

From lancea at openjdk.java.net  Tue Oct 13 17:19:23 2020
From: lancea at openjdk.java.net (Lance Andersen)
Date: Tue, 13 Oct 2020 17:19:23 GMT
Subject: RFR: 8253952: Refine ZipOutputStream.putNextEntry() to
 recalculate ZipEntry's compressed size [v4]
In-Reply-To: <qi-3I4yAOah36I8pLGLl9Vcfq-1R335KpxyaWHJsJKU=.e6939ba1-7cc8-45b4-af11-694db930d0cb@github.com>
References: <0nq5oFKOj6AZqCW6jF268-6oKRI6UkS6TRIHo-_5vKw=.d13c7016-4473-4b20-9117-100b368d3716@github.com>
 <qi-3I4yAOah36I8pLGLl9Vcfq-1R335KpxyaWHJsJKU=.e6939ba1-7cc8-45b4-af11-694db930d0cb@github.com>
Message-ID: <SthiB8Qk3SsYn44ueXigiYQ7D0ybcLujCAKqrSezlSQ=.9ed2cbe3-1348-48ce-be8e-4c03798a494a@github.com>

On Tue, 13 Oct 2020 11:40:36 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> ### Summary
>> 
>> Work around wrong usage of `ZipOutputStream.putNextEntry()` in user code which can lead to the `ZipException "invalid
>> entry compressed size"`.
>> ### Motivation
>> 
>> In general it is not safe to directly write a ZipEntry obtained from `ZipInputStream.getNextEntry()`,
>> `ZipFile.entries()`, `ZipFile.getEntry()` or `ZipFile.stream()` with `ZipOutputStream.putNextEntry()` to a
>> `ZipOutputStream` and then read the entries data from the `ZipInputStream` and write it to the `ZipOutputStream` as
>> follows:
>>  ZipEntry entry;
>>  ZipInputStream zis = new ZipInputStream(...);
>>  ZipOutputStream zos = new ZipOutputStream(...);
>>  while((entry = zis.getNextEntry()) != null) {
>>      zos.putNextEntry(entry);
>>      zis.transferTo(zos);
>>  }
>> The problem with this code is that the zip file format does not record the compression level used for deflation in its
>> entries. In general, it doesn't even mandate a predefined compression ratio per compression level. Therefore the
>> compressed size recorded in a `ZipEntry` read from a zip file might differ from the new compressed size produced by the
>> receiving `ZipOutputStream`. Such a difference will result in a `ZipException` with the following message:
>>  java.util.zip.ZipException: invalid entry compressed size (expected 12 but got 7 bytes)
>>  
>> The correct way of copying all entries from one zip file into another requires the creation of a new `ZipEntry` or at
>> least resetting of the compressed size field. E.g.:
>>  while((entry = zis.getNextEntry()) != null) {
>>      ZipEntry newEntry = new ZipEntry(entry.getName());
>>      zos.putNextEntry(newEntry);
>>      zis.transferTo(zos);
>>  }
>> or:
>>  while((entry = zis.getNextEntry()) != null) {
>>      entry.setCompressedSize(-1);
>>      zos.putNextEntry(entry);
>>      zis.transferTo(zos);
>>  }
>> Unfortunately, there's a lot of user code out there which gets this wrong and uses the bad coding pattern described
>> before. Searching for `"java.util.zip.ZipException: invalid entry compressed size (expected 12 but got 7 bytes)"` gives
>> ~2500 hits (~100 on StackOverflow). It's also no hard to find plenty of instances of this anti-pattern on GitHub when
>> doing a code search for `ZipEntry` and `putNextEntry()`. E.g. [Gradle 4.x wrapper task][1] is affected as well as the
>> latest version of the [mockableAndroidJar task][2]. I've recently fixed two occurrences of this pattern in OpenJDK (see
>> [JDK-8240333][3] and [JDK-8240235][4]) but there still exist more of them (e.g.
>> [`test/jdk/java/util/zip/ZipFile/CopyJar.java`][5] which is there since 1999 :).  ### Description  So while this has
>> clearly been a problem before, it apparently wasn't painful enough to trigger any action from the side of the JDK.
>> However, recently quite some zlib forks with [superior deflate/inflate performance have evolved][6]. Using them with
>> OpenJDK is quite straight-forward: one just has to configure the alternative implementations by setting
>> `LD_LIBRARY_PATH` or `LD_PRELOAD` correspondingly. We've seen big saving by using these new zlib implementations for
>> selected services in production and the only reason why we haven't enabled them by default until now is the problem
>> I've just described. The reason why these new libraries uncover the described anti-pattern much more often is because
>> their compression ratio is slightly different from that of the default zlib library. This can easily trigger a
>> `ZipException` even if an application is not using a different compression levels but just a zip file created with
>> another zlib version.  I'd therefore like to propose the following workaround for the wrong
>> `ZipOutputStream.putNextEntry()` usage in user code:
>> -  ignore the compressed size if it was implicitly determined from the zip file and not explicitly set by calling
>>    `ZipEntry.setCompressedSize()`.
>> 
>> - Change the API-documentation of `ZipOutputStream.putNextEntry()` and `JarOutputStream.putNextEntry()` to explain the
>>   problem and why `putNextEntry()` will ignore the compressed size of a `ZipEntry` if that was set implicitely when
>>   reading that entry from a `ZipFile` or `ZipInputStream`.
>> 
>> 
>> ### Technical Details
>> 
>> A zip file consists of a stream of File Entries followed by a Central Directory (see [here for a more detailed
>> specification][7]). Each File Entry is composed of a Local File Header (LFH) followed by the compressed Data and an
>> optional Data Descriptor. The LFH contains the File Name and among other attributes the Compressed and Uncompressed
>> size and CRC of the Data. In the case where the latter three attributes are not available at the time when the LFH is
>> created, this fact will be recorded in a flag of the LFH and will trigger the creation of a Data Descriptor with the
>> corresponding information right after the Data section. Finally, the Central Directory contains one Central Directory
>> File Header (CDFH) for each entry of the  zip archive. The CDFH is an extended version of the LFH and the ultimate
>> reference for the contents of the zip archive. The redundancy between LFH and CDFH is a tribute to zip's long history
>> when it was used to store archives on multiple floppy discs and the CDFH allowed to update the archive by only writing
>> to the last disc which contained the Central Directory.  `ZipEntries` read with `ZipInputStream.getNextEntry()` will
>> initially only contain the information from the LFH. Only after the next entry was read (or after
>> `ZipInputStream.closeEntry()` was called explicitly), will the previously read entry be updated with the data from the
>> Data Descriptor. `ZipInputStream` doesn't inspect the Central Directory at all.  On the other hand, `ZipFile` only
>> queries the Central Directory for `ZipEntry` information so all `ZipEntries` returned by `ZipFile.entries()`,
>> `ZipFile.getEntry()` and `ZipFile.stream()` will always instantly contain the full Compressed and Uncompressed Size and
>> CRC information for each entry independently of the LFH contents.  ### Risks and Assumptions  If we choose to ignore
>> the implicitly recorded compressed size in a `ZipEntry` read from a zip file when writing it to a `ZipOutputStream`,
>> this will lead to zip files with incomplete information in the LFH and an additional Data Descriptor as described
>> before. However, the result is still fully compatible to the zip file specification. It's also not unusual, because by
>> default all new zip files created with `ZipOutputStream` will contain LFHs without Compressed and Uncompressed Size and
>> CRC information and an additional Data Descriptor. Theoretically it is possible to create new zip files with
>> `ZipOutputStream` class and Compressed and Uncompressed Size and CRC information in the LFH but that's complex and
>> inefficient because it requires two steps. A first step to determine the crc and compressed size of the data and a
>> second step to actually write the data to the `ZipOutputStream` (which will compress it a second time). This is because
>> the current API offers no possibility to write already compressed data to a `ZipOutputStream`.  Consequently, the only
>> straight-forward way of creating zip files from Java which have all the data in the LFH and no Data Descriptor is by
>> copying `ZipEntries` from an existing zip file with the buggy method described before. This incidentally worked more or
>> less reliable for a long time but breaks miserably when using different zlib implementations. Ignoring the implicitly
>> set compressed size of `ZipEntries` can easily fix this problem.  I'm not aware of any tool which can not handle such
>> files and if it exists it would have problems with the majority of Java created zip files anyway (e.g. all jar-files
>> created with the jar tool have zip entries with incomplete LFH data and additional Data Descriptor).  Ignoring the
>> implicitly set compressed size of `ZipEntries` has no measurable performance impact and will increase the size of zip
>> archives which used to have the complete file information in the LFH before by 16 bytes per entry. On the other hand it
>> will give us the freedom to use whatever zip implementation we like :)   [1]:
>> https://github.com/gradle/gradle/blob/e76905e3a/subprojects/build-init/src/main/java/org/gradle/api/tasks/wrapper/Wrapper.java#L152-L158
>> [2]:
>> https://android.googlesource.com/platform/tools/base/+/refs/heads/master/build-system/builder/src/main/java/com/android/builder/testing/MockableJarGenerator.java#86
>> [3]: https://bugs.openjdk.java.net/browse/JDK-8240333 [4]: https://bugs.openjdk.java.net/browse/JDK-8240235 [5]:
>> https://github.com/openjdk/jdk/blob/master/test/jdk/java/util/zip/ZipFile/CopyJar.java [6]:
>> https://github.com/simonis/zlib-bench/blob/master/Results.md [7]: https://en.wikipedia.org/wiki/Zip_(file_format)
>
> Volker Simonis has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev
> excludes the unrelated changes brought in by the merge/rebase. The pull request contains one additional commit since
> the last revision:
>   8253952: Refine ZipOutputStream.putNextEntry() to recalculate ZipEntry's compressed size

test/jdk/java/util/zip/CopyZipFile.java line 149:

> 147:         os = new ByteArrayOutputStream();
> 148:         zos = new ZipOutputStream(os);
> 149:         ZipFile zf = new ZipFile(ZIP_FILE);

Any reason to not use try with resources here as well (and below)

-------------

PR: https://git.openjdk.java.net/jdk/pull/520

From rriggs at openjdk.java.net  Tue Oct 13 17:21:17 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 13 Oct 2020 17:21:17 GMT
Subject: RFR: 8251989: Hex formatting and parsing utility
In-Reply-To: <lv3X2v4KfUM8fxWZyX8_rwGa5wVnysBQjvqnAJaDYUU=.2b36709d-5547-411d-a609-fa465c4ce17f@github.com>
References: <HSEn47GMS1K3g57mrTZeQk-WZHl3pKGHpX_OOf8VnsU=.740863c2-f9e4-43c4-b500-614aab4078b1@github.com>
 <lv3X2v4KfUM8fxWZyX8_rwGa5wVnysBQjvqnAJaDYUU=.2b36709d-5547-411d-a609-fa465c4ce17f@github.com>
Message-ID: <PPzDRzUrvYrFOnmyiV9zaDqA7XZhyFih7-8ulo1xyfs=.f28ed7f3-ec9c-4cf9-9f29-d83027597525@github.com>

On Mon, 12 Oct 2020 23:05:44 GMT, Marcono1234 <github.com+11685886+Marcono1234 at openjdk.org> wrote:

> Also is it common practice to use `System.out` in JDK tests? In my opinion it often does not add much value once the
> unit test implementation has been completed because the output is not checked during tests automatically anyways and
> might only clutter the console output.

It has been useful to see the output generated and if there are failures there is additional information available.

> The tests are using `String.toUpperCase`, `toLowerCase` and `format` without `Locale` (therefore using the default
> one). Does the test setup guarantee a constant default locale or would be better to include a `Locale` to make sure the
> tests don't break for any unusual locale?

Good point, the ROOT locale should be used. Though for the cases of the hexadecimal characters, they are consistently
treated across all locales.

> Has it been also considered to add support for parsing from a `Reader` to an `OutputStream` and from `InputStream` to
> `Appendable` to support arbitrary length input and output?

That can be considered separately, the Jira issue 8254708 will track that enhancement.
A typical application reading input may need to handle a mix of input constructs with Hex being just one.
An application usually needs some kind of look ahead or push back to adjust to the contents of the stream
and that brings in a more complex grammar.

> Maybe it would also be good to mention for the method parsing and formatting `int`, `long`, ... in which byte order the
> output is created.

The big/little -endian terminology usually applies to binary representations. The natural reading order for numbers is
left to right but it can be more explicit.

> And would it be worth supporting a delimiter _period_ or _frequency_ to only apply the delimiter every nth byte? This
> would be useful when the user want to write hex chars in groups of 4 or 8.

It is a tradeoff in complexity.  The api focuses on the conversion of byte arrays to strings and back.
That behavior can be achieved naturally using the `toHexDigits` methods with the application handling the insertion of
delimiters.

-------------

PR: https://git.openjdk.java.net/jdk/pull/482

From erikj at openjdk.java.net  Tue Oct 13 17:31:20 2020
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Tue, 13 Oct 2020 17:31:20 GMT
Subject: RFR: JDK-8252870: Finalize (remove "incubator" from) jpackage [v2]
In-Reply-To: <C1gKE74s6f3xjeBRJ_pYlbqMrLcfkbMSq1jJdvcf92w=.e74b4173-3063-4728-b003-683fa9f85035@github.com>
References: <HlksY2mFyKG_kkZA6n6JHHIWBGJT3bjmoLG28c9q1EU=.2b9faa66-08b9-4694-a5db-9d9918039642@github.com>
 <C1gKE74s6f3xjeBRJ_pYlbqMrLcfkbMSq1jJdvcf92w=.e74b4173-3063-4728-b003-683fa9f85035@github.com>
Message-ID: <sO2MJAVPgEivHFauM3G6Iz1LoYrchUssPO38gv2FRqA=.a1610654-7041-4e00-9eab-401d7fa68e3b@github.com>

On Tue, 13 Oct 2020 14:48:40 GMT, Andy Herrick <herrick at openjdk.org> wrote:

>> JDK-8252870: Finalize (remove "incubator" from) jpackage
>
> Andy Herrick has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8252870: Finalize (remove "incubator" from) jpackage
>     - reverting two auto-generated files, and changing module-info to "@since 16"

Build changes look good.

-------------

Marked as reviewed by erikj (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/633

From psandoz at openjdk.java.net  Tue Oct 13 17:34:37 2020
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Tue, 13 Oct 2020 17:34:37 GMT
Subject: RFR: 8223347: Integration of Vector API (Incubator) [v4]
In-Reply-To: <-PE4TwXgvq2bemAn_8csjn4_j7zoAolnQz6QQt3z0Wk=.eaa9999f-0713-4349-b31d-934717aa37a1@github.com>
References: <-PE4TwXgvq2bemAn_8csjn4_j7zoAolnQz6QQt3z0Wk=.eaa9999f-0713-4349-b31d-934717aa37a1@github.com>
Message-ID: <jUo0C9zzD8iOVtsyQkhXPWfd6xphEROScVCmXxvD_Oc=.0b78af70-a731-4aa0-aa22-f527382b80f7@github.com>

> This pull request is for integration of the Vector API. It was previously reviewed under conditions when mercurial was
> used for the source code control system. Review threads can be found here (searching for issue number 8223347 in the
> title):  https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-April/thread.html
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-May/thread.html
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-July/thread.html
> 
> If mercurial was still being used the code would be pushed directly, once the CSR is approved. However, in this case a
> pull request is required and needs explicit reviewer approval. Between the final review and this pull request no code
> has changed, except for that related to merging.

Paul Sandoz 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 master
 - Fix related to merge
 - HotspotIntrinsicCandidate to IntrinsicCandidate
 - Merge master
 - Fix permissions
 - Fix permissions
 - Merge master
 - Vector API new files
 - Integration of Vector API (Incubator)

-------------

Changes: https://git.openjdk.java.net/jdk/pull/367/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=367&range=03
  Stats: 295107 lines in 336 files changed: 292957 ins; 1062 del; 1088 mod
  Patch: https://git.openjdk.java.net/jdk/pull/367.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/367/head:pull/367

PR: https://git.openjdk.java.net/jdk/pull/367

From andrew at openjdk.java.net  Tue Oct 13 18:46:16 2020
From: andrew at openjdk.java.net (Andrew John Hughes)
Date: Tue, 13 Oct 2020 18:46:16 GMT
Subject: RFR: 8254177: (tz) Upgrade time-zone data to tzdata2020b
In-Reply-To: <Hsd4_aFWtUkPKQAfgd4741RyCUes_UVlFWEzlw4Q69Y=.2673111e-c458-4807-9d4e-f431f6e76d23@github.com>
References: <KvYfzEHlUV_cV29YAN2i2uXph2lldf0GGz_9TE5O0Iw=.c2d0262d-50d8-49fc-9815-1482616d1a3c@github.com>
 <aKCw-4GeWTCVDf5a6XtttBy2G67YJHDlWdrmTXjy66I=.67e2e981-4732-4075-a1c7-0c76f845abd9@github.com>
 <Hsd4_aFWtUkPKQAfgd4741RyCUes_UVlFWEzlw4Q69Y=.2673111e-c458-4807-9d4e-f431f6e76d23@github.com>
Message-ID: <BXc3JRbHGJazB9A1lAON7YZ2AhSIxSII656FqnZaqdY=.778983fb-faa1-442f-86d8-5ad174b1317d@github.com>

On Tue, 13 Oct 2020 11:32:54 GMT, Kiran Sidhartha Ravikumar <kravikumar at openjdk.org> wrote:

>> Looks good. I think we should release-note the removal of the "US/Pacific-New" Link on the off chance that some
>> production/testing system is looking for such a zone.
>
> Thanks for the review everyone, I have added a release note to the bug. I will integrate the changes

Looks like we both reached the same patch for this one independently :)
systemv was removed from tzdata some time ago and wasn't even being read by the JDK as far as I could see. Its contents
are duplicated in jdk11_backward anyway. Good to see both it and pacificnew being removed. In the unlikely event the
removal of Pacific_New is problematic, it could be added to jdk11_backward as well, but it seems very unlikely.

-------------

PR: https://git.openjdk.java.net/jdk/pull/602

From alanb at openjdk.java.net  Tue Oct 13 18:53:23 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 13 Oct 2020 18:53:23 GMT
Subject: RFR: 8253952: Refine ZipOutputStream.putNextEntry() to
 recalculate ZipEntry's compressed size [v4]
In-Reply-To: <qi-3I4yAOah36I8pLGLl9Vcfq-1R335KpxyaWHJsJKU=.e6939ba1-7cc8-45b4-af11-694db930d0cb@github.com>
References: <0nq5oFKOj6AZqCW6jF268-6oKRI6UkS6TRIHo-_5vKw=.d13c7016-4473-4b20-9117-100b368d3716@github.com>
 <qi-3I4yAOah36I8pLGLl9Vcfq-1R335KpxyaWHJsJKU=.e6939ba1-7cc8-45b4-af11-694db930d0cb@github.com>
Message-ID: <MeLRom5-27c7jNwMT1t6suOqbH70Sajvoi-6xA-M7KA=.f9a79458-296d-4106-8596-1b1c49e460e2@github.com>

On Tue, 13 Oct 2020 11:40:36 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> ### Summary
>> 
>> Work around wrong usage of `ZipOutputStream.putNextEntry()` in user code which can lead to the `ZipException "invalid
>> entry compressed size"`.
>> ### Motivation
>> 
>> In general it is not safe to directly write a ZipEntry obtained from `ZipInputStream.getNextEntry()`,
>> `ZipFile.entries()`, `ZipFile.getEntry()` or `ZipFile.stream()` with `ZipOutputStream.putNextEntry()` to a
>> `ZipOutputStream` and then read the entries data from the `ZipInputStream` and write it to the `ZipOutputStream` as
>> follows:
>>  ZipEntry entry;
>>  ZipInputStream zis = new ZipInputStream(...);
>>  ZipOutputStream zos = new ZipOutputStream(...);
>>  while((entry = zis.getNextEntry()) != null) {
>>      zos.putNextEntry(entry);
>>      zis.transferTo(zos);
>>  }
>> The problem with this code is that the zip file format does not record the compression level used for deflation in its
>> entries. In general, it doesn't even mandate a predefined compression ratio per compression level. Therefore the
>> compressed size recorded in a `ZipEntry` read from a zip file might differ from the new compressed size produced by the
>> receiving `ZipOutputStream`. Such a difference will result in a `ZipException` with the following message:
>>  java.util.zip.ZipException: invalid entry compressed size (expected 12 but got 7 bytes)
>>  
>> The correct way of copying all entries from one zip file into another requires the creation of a new `ZipEntry` or at
>> least resetting of the compressed size field. E.g.:
>>  while((entry = zis.getNextEntry()) != null) {
>>      ZipEntry newEntry = new ZipEntry(entry.getName());
>>      zos.putNextEntry(newEntry);
>>      zis.transferTo(zos);
>>  }
>> or:
>>  while((entry = zis.getNextEntry()) != null) {
>>      entry.setCompressedSize(-1);
>>      zos.putNextEntry(entry);
>>      zis.transferTo(zos);
>>  }
>> Unfortunately, there's a lot of user code out there which gets this wrong and uses the bad coding pattern described
>> before. Searching for `"java.util.zip.ZipException: invalid entry compressed size (expected 12 but got 7 bytes)"` gives
>> ~2500 hits (~100 on StackOverflow). It's also no hard to find plenty of instances of this anti-pattern on GitHub when
>> doing a code search for `ZipEntry` and `putNextEntry()`. E.g. [Gradle 4.x wrapper task][1] is affected as well as the
>> latest version of the [mockableAndroidJar task][2]. I've recently fixed two occurrences of this pattern in OpenJDK (see
>> [JDK-8240333][3] and [JDK-8240235][4]) but there still exist more of them (e.g.
>> [`test/jdk/java/util/zip/ZipFile/CopyJar.java`][5] which is there since 1999 :).  ### Description  So while this has
>> clearly been a problem before, it apparently wasn't painful enough to trigger any action from the side of the JDK.
>> However, recently quite some zlib forks with [superior deflate/inflate performance have evolved][6]. Using them with
>> OpenJDK is quite straight-forward: one just has to configure the alternative implementations by setting
>> `LD_LIBRARY_PATH` or `LD_PRELOAD` correspondingly. We've seen big saving by using these new zlib implementations for
>> selected services in production and the only reason why we haven't enabled them by default until now is the problem
>> I've just described. The reason why these new libraries uncover the described anti-pattern much more often is because
>> their compression ratio is slightly different from that of the default zlib library. This can easily trigger a
>> `ZipException` even if an application is not using a different compression levels but just a zip file created with
>> another zlib version.  I'd therefore like to propose the following workaround for the wrong
>> `ZipOutputStream.putNextEntry()` usage in user code:
>> -  ignore the compressed size if it was implicitly determined from the zip file and not explicitly set by calling
>>    `ZipEntry.setCompressedSize()`.
>> 
>> - Change the API-documentation of `ZipOutputStream.putNextEntry()` and `JarOutputStream.putNextEntry()` to explain the
>>   problem and why `putNextEntry()` will ignore the compressed size of a `ZipEntry` if that was set implicitely when
>>   reading that entry from a `ZipFile` or `ZipInputStream`.
>> 
>> 
>> ### Technical Details
>> 
>> A zip file consists of a stream of File Entries followed by a Central Directory (see [here for a more detailed
>> specification][7]). Each File Entry is composed of a Local File Header (LFH) followed by the compressed Data and an
>> optional Data Descriptor. The LFH contains the File Name and among other attributes the Compressed and Uncompressed
>> size and CRC of the Data. In the case where the latter three attributes are not available at the time when the LFH is
>> created, this fact will be recorded in a flag of the LFH and will trigger the creation of a Data Descriptor with the
>> corresponding information right after the Data section. Finally, the Central Directory contains one Central Directory
>> File Header (CDFH) for each entry of the  zip archive. The CDFH is an extended version of the LFH and the ultimate
>> reference for the contents of the zip archive. The redundancy between LFH and CDFH is a tribute to zip's long history
>> when it was used to store archives on multiple floppy discs and the CDFH allowed to update the archive by only writing
>> to the last disc which contained the Central Directory.  `ZipEntries` read with `ZipInputStream.getNextEntry()` will
>> initially only contain the information from the LFH. Only after the next entry was read (or after
>> `ZipInputStream.closeEntry()` was called explicitly), will the previously read entry be updated with the data from the
>> Data Descriptor. `ZipInputStream` doesn't inspect the Central Directory at all.  On the other hand, `ZipFile` only
>> queries the Central Directory for `ZipEntry` information so all `ZipEntries` returned by `ZipFile.entries()`,
>> `ZipFile.getEntry()` and `ZipFile.stream()` will always instantly contain the full Compressed and Uncompressed Size and
>> CRC information for each entry independently of the LFH contents.  ### Risks and Assumptions  If we choose to ignore
>> the implicitly recorded compressed size in a `ZipEntry` read from a zip file when writing it to a `ZipOutputStream`,
>> this will lead to zip files with incomplete information in the LFH and an additional Data Descriptor as described
>> before. However, the result is still fully compatible to the zip file specification. It's also not unusual, because by
>> default all new zip files created with `ZipOutputStream` will contain LFHs without Compressed and Uncompressed Size and
>> CRC information and an additional Data Descriptor. Theoretically it is possible to create new zip files with
>> `ZipOutputStream` class and Compressed and Uncompressed Size and CRC information in the LFH but that's complex and
>> inefficient because it requires two steps. A first step to determine the crc and compressed size of the data and a
>> second step to actually write the data to the `ZipOutputStream` (which will compress it a second time). This is because
>> the current API offers no possibility to write already compressed data to a `ZipOutputStream`.  Consequently, the only
>> straight-forward way of creating zip files from Java which have all the data in the LFH and no Data Descriptor is by
>> copying `ZipEntries` from an existing zip file with the buggy method described before. This incidentally worked more or
>> less reliable for a long time but breaks miserably when using different zlib implementations. Ignoring the implicitly
>> set compressed size of `ZipEntries` can easily fix this problem.  I'm not aware of any tool which can not handle such
>> files and if it exists it would have problems with the majority of Java created zip files anyway (e.g. all jar-files
>> created with the jar tool have zip entries with incomplete LFH data and additional Data Descriptor).  Ignoring the
>> implicitly set compressed size of `ZipEntries` has no measurable performance impact and will increase the size of zip
>> archives which used to have the complete file information in the LFH before by 16 bytes per entry. On the other hand it
>> will give us the freedom to use whatever zip implementation we like :)   [1]:
>> https://github.com/gradle/gradle/blob/e76905e3a/subprojects/build-init/src/main/java/org/gradle/api/tasks/wrapper/Wrapper.java#L152-L158
>> [2]:
>> https://android.googlesource.com/platform/tools/base/+/refs/heads/master/build-system/builder/src/main/java/com/android/builder/testing/MockableJarGenerator.java#86
>> [3]: https://bugs.openjdk.java.net/browse/JDK-8240333 [4]: https://bugs.openjdk.java.net/browse/JDK-8240235 [5]:
>> https://github.com/openjdk/jdk/blob/master/test/jdk/java/util/zip/ZipFile/CopyJar.java [6]:
>> https://github.com/simonis/zlib-bench/blob/master/Results.md [7]: https://en.wikipedia.org/wiki/Zip_(file_format)
>
> Volker Simonis has updated the pull request with a new target base due to a merge or a rebase. The pull request now
> contains one commit:
>   8253952: Refine ZipOutputStream.putNextEntry() to recalculate ZipEntry's compressed size

src/java.base/share/classes/java/util/jar/JarOutputStream.java line 85:

> 83:      * ZipEntry#setCompressedSize(long)} method, then the compressed
> 84:      * size will be set to the actual compressed size after deflation.
> 85:      * <p>

I'm happy with the wording. What you think about put a p tag before "The default compression method ..." so that it
goes into its own paragraph? I'm asking because it's inconsistent to have the first paragraph include the details on
the compression method and the details on the current time pushed into a second paragraph - if you generate the javadoc
then you'll see what I mean.

src/java.base/share/classes/java/util/zip/ZipEntry.java line 453:

> 451:     public void setCompressedSize(long csize) {
> 452:         this.csize = csize;
> 453:         this.csizeSet = true;

Latest version of implementation changes look good.

-------------

PR: https://git.openjdk.java.net/jdk/pull/520

From lancea at openjdk.java.net  Tue Oct 13 18:53:24 2020
From: lancea at openjdk.java.net (Lance Andersen)
Date: Tue, 13 Oct 2020 18:53:24 GMT
Subject: RFR: 8253952: Refine ZipOutputStream.putNextEntry() to
 recalculate ZipEntry's compressed size [v4]
In-Reply-To: <MeLRom5-27c7jNwMT1t6suOqbH70Sajvoi-6xA-M7KA=.f9a79458-296d-4106-8596-1b1c49e460e2@github.com>
References: <0nq5oFKOj6AZqCW6jF268-6oKRI6UkS6TRIHo-_5vKw=.d13c7016-4473-4b20-9117-100b368d3716@github.com>
 <qi-3I4yAOah36I8pLGLl9Vcfq-1R335KpxyaWHJsJKU=.e6939ba1-7cc8-45b4-af11-694db930d0cb@github.com>
 <MeLRom5-27c7jNwMT1t6suOqbH70Sajvoi-6xA-M7KA=.f9a79458-296d-4106-8596-1b1c49e460e2@github.com>
Message-ID: <J0kyw_XsAiNTXEkUyWMcGrkfuMvPVswt5Ai4LkFlNLM=.1b7d16dd-f10c-4e0e-9c8a-440e9d9547b7@github.com>

On Tue, 13 Oct 2020 18:46:59 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Volker Simonis has updated the pull request with a new target base due to a merge or a rebase. The pull request now
>> contains one commit:
>>   8253952: Refine ZipOutputStream.putNextEntry() to recalculate ZipEntry's compressed size
>
> src/java.base/share/classes/java/util/jar/JarOutputStream.java line 85:
> 
>> 83:      * ZipEntry#setCompressedSize(long)} method, then the compressed
>> 84:      * size will be set to the actual compressed size after deflation.
>> 85:      * <p>
> 
> I'm happy with the wording. What you think about put a p tag before "The default compression method ..." so that it
> goes into its own paragraph? I'm asking because it's inconsistent to have the first paragraph include the details on
> the compression method and the details on the current time pushed into a second paragraph - if you generate the javadoc
> then you'll see what I mean.

I think that is a good idea to at the paragraph tag as you suggest

-------------

PR: https://git.openjdk.java.net/jdk/pull/520

From simonis at openjdk.java.net  Tue Oct 13 19:00:32 2020
From: simonis at openjdk.java.net (Volker Simonis)
Date: Tue, 13 Oct 2020 19:00:32 GMT
Subject: RFR: 8253952: Refine ZipOutputStream.putNextEntry() to
 recalculate ZipEntry's compressed size [v5]
In-Reply-To: <0nq5oFKOj6AZqCW6jF268-6oKRI6UkS6TRIHo-_5vKw=.d13c7016-4473-4b20-9117-100b368d3716@github.com>
References: <0nq5oFKOj6AZqCW6jF268-6oKRI6UkS6TRIHo-_5vKw=.d13c7016-4473-4b20-9117-100b368d3716@github.com>
Message-ID: <jeB7WBEp15VpHVdyste4bs_TDNQc6kjFhJDIUhZFr3Q=.875b5a99-d431-4bc4-b780-fcb9c39fda12@github.com>

> ### Summary
> 
> Work around wrong usage of `ZipOutputStream.putNextEntry()` in user code which can lead to the `ZipException "invalid
> entry compressed size"`.
> ### Motivation
> 
> In general it is not safe to directly write a ZipEntry obtained from `ZipInputStream.getNextEntry()`,
> `ZipFile.entries()`, `ZipFile.getEntry()` or `ZipFile.stream()` with `ZipOutputStream.putNextEntry()` to a
> `ZipOutputStream` and then read the entries data from the `ZipInputStream` and write it to the `ZipOutputStream` as
> follows:
>  ZipEntry entry;
>  ZipInputStream zis = new ZipInputStream(...);
>  ZipOutputStream zos = new ZipOutputStream(...);
>  while((entry = zis.getNextEntry()) != null) {
>      zos.putNextEntry(entry);
>      zis.transferTo(zos);
>  }
> The problem with this code is that the zip file format does not record the compression level used for deflation in its
> entries. In general, it doesn't even mandate a predefined compression ratio per compression level. Therefore the
> compressed size recorded in a `ZipEntry` read from a zip file might differ from the new compressed size produced by the
> receiving `ZipOutputStream`. Such a difference will result in a `ZipException` with the following message:
>  java.util.zip.ZipException: invalid entry compressed size (expected 12 but got 7 bytes)
>  
> The correct way of copying all entries from one zip file into another requires the creation of a new `ZipEntry` or at
> least resetting of the compressed size field. E.g.:
>  while((entry = zis.getNextEntry()) != null) {
>      ZipEntry newEntry = new ZipEntry(entry.getName());
>      zos.putNextEntry(newEntry);
>      zis.transferTo(zos);
>  }
> or:
>  while((entry = zis.getNextEntry()) != null) {
>      entry.setCompressedSize(-1);
>      zos.putNextEntry(entry);
>      zis.transferTo(zos);
>  }
> Unfortunately, there's a lot of user code out there which gets this wrong and uses the bad coding pattern described
> before. Searching for `"java.util.zip.ZipException: invalid entry compressed size (expected 12 but got 7 bytes)"` gives
> ~2500 hits (~100 on StackOverflow). It's also no hard to find plenty of instances of this anti-pattern on GitHub when
> doing a code search for `ZipEntry` and `putNextEntry()`. E.g. [Gradle 4.x wrapper task][1] is affected as well as the
> latest version of the [mockableAndroidJar task][2]. I've recently fixed two occurrences of this pattern in OpenJDK (see
> [JDK-8240333][3] and [JDK-8240235][4]) but there still exist more of them (e.g.
> [`test/jdk/java/util/zip/ZipFile/CopyJar.java`][5] which is there since 1999 :).  ### Description  So while this has
> clearly been a problem before, it apparently wasn't painful enough to trigger any action from the side of the JDK.
> However, recently quite some zlib forks with [superior deflate/inflate performance have evolved][6]. Using them with
> OpenJDK is quite straight-forward: one just has to configure the alternative implementations by setting
> `LD_LIBRARY_PATH` or `LD_PRELOAD` correspondingly. We've seen big saving by using these new zlib implementations for
> selected services in production and the only reason why we haven't enabled them by default until now is the problem
> I've just described. The reason why these new libraries uncover the described anti-pattern much more often is because
> their compression ratio is slightly different from that of the default zlib library. This can easily trigger a
> `ZipException` even if an application is not using a different compression levels but just a zip file created with
> another zlib version.  I'd therefore like to propose the following workaround for the wrong
> `ZipOutputStream.putNextEntry()` usage in user code:
> -  ignore the compressed size if it was implicitly determined from the zip file and not explicitly set by calling
>    `ZipEntry.setCompressedSize()`.
> 
> - Change the API-documentation of `ZipOutputStream.putNextEntry()` and `JarOutputStream.putNextEntry()` to explain the
>   problem and why `putNextEntry()` will ignore the compressed size of a `ZipEntry` if that was set implicitely when
>   reading that entry from a `ZipFile` or `ZipInputStream`.
> 
> 
> ### Technical Details
> 
> A zip file consists of a stream of File Entries followed by a Central Directory (see [here for a more detailed
> specification][7]). Each File Entry is composed of a Local File Header (LFH) followed by the compressed Data and an
> optional Data Descriptor. The LFH contains the File Name and among other attributes the Compressed and Uncompressed
> size and CRC of the Data. In the case where the latter three attributes are not available at the time when the LFH is
> created, this fact will be recorded in a flag of the LFH and will trigger the creation of a Data Descriptor with the
> corresponding information right after the Data section. Finally, the Central Directory contains one Central Directory
> File Header (CDFH) for each entry of the  zip archive. The CDFH is an extended version of the LFH and the ultimate
> reference for the contents of the zip archive. The redundancy between LFH and CDFH is a tribute to zip's long history
> when it was used to store archives on multiple floppy discs and the CDFH allowed to update the archive by only writing
> to the last disc which contained the Central Directory.  `ZipEntries` read with `ZipInputStream.getNextEntry()` will
> initially only contain the information from the LFH. Only after the next entry was read (or after
> `ZipInputStream.closeEntry()` was called explicitly), will the previously read entry be updated with the data from the
> Data Descriptor. `ZipInputStream` doesn't inspect the Central Directory at all.  On the other hand, `ZipFile` only
> queries the Central Directory for `ZipEntry` information so all `ZipEntries` returned by `ZipFile.entries()`,
> `ZipFile.getEntry()` and `ZipFile.stream()` will always instantly contain the full Compressed and Uncompressed Size and
> CRC information for each entry independently of the LFH contents.  ### Risks and Assumptions  If we choose to ignore
> the implicitly recorded compressed size in a `ZipEntry` read from a zip file when writing it to a `ZipOutputStream`,
> this will lead to zip files with incomplete information in the LFH and an additional Data Descriptor as described
> before. However, the result is still fully compatible to the zip file specification. It's also not unusual, because by
> default all new zip files created with `ZipOutputStream` will contain LFHs without Compressed and Uncompressed Size and
> CRC information and an additional Data Descriptor. Theoretically it is possible to create new zip files with
> `ZipOutputStream` class and Compressed and Uncompressed Size and CRC information in the LFH but that's complex and
> inefficient because it requires two steps. A first step to determine the crc and compressed size of the data and a
> second step to actually write the data to the `ZipOutputStream` (which will compress it a second time). This is because
> the current API offers no possibility to write already compressed data to a `ZipOutputStream`.  Consequently, the only
> straight-forward way of creating zip files from Java which have all the data in the LFH and no Data Descriptor is by
> copying `ZipEntries` from an existing zip file with the buggy method described before. This incidentally worked more or
> less reliable for a long time but breaks miserably when using different zlib implementations. Ignoring the implicitly
> set compressed size of `ZipEntries` can easily fix this problem.  I'm not aware of any tool which can not handle such
> files and if it exists it would have problems with the majority of Java created zip files anyway (e.g. all jar-files
> created with the jar tool have zip entries with incomplete LFH data and additional Data Descriptor).  Ignoring the
> implicitly set compressed size of `ZipEntries` has no measurable performance impact and will increase the size of zip
> archives which used to have the complete file information in the LFH before by 16 bytes per entry. On the other hand it
> will give us the freedom to use whatever zip implementation we like :)   [1]:
> https://github.com/gradle/gradle/blob/e76905e3a/subprojects/build-init/src/main/java/org/gradle/api/tasks/wrapper/Wrapper.java#L152-L158
> [2]:
> https://android.googlesource.com/platform/tools/base/+/refs/heads/master/build-system/builder/src/main/java/com/android/builder/testing/MockableJarGenerator.java#86
> [3]: https://bugs.openjdk.java.net/browse/JDK-8240333 [4]: https://bugs.openjdk.java.net/browse/JDK-8240235 [5]:
> https://github.com/openjdk/jdk/blob/master/test/jdk/java/util/zip/ZipFile/CopyJar.java [6]:
> https://github.com/simonis/zlib-bench/blob/master/Results.md [7]: https://en.wikipedia.org/wiki/Zip_(file_format)

Volker Simonis 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:

  8253952: Refine ZipOutputStream.putNextEntry() to recalculate ZipEntry's compressed size

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/520/files
  - new: https://git.openjdk.java.net/jdk/pull/520/files/3edcf72e..0e2e130a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=520&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=520&range=03-04

  Stats: 115 lines in 1 file changed: 42 ins; 43 del; 30 mod
  Patch: https://git.openjdk.java.net/jdk/pull/520.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/520/head:pull/520

PR: https://git.openjdk.java.net/jdk/pull/520

From simonis at openjdk.java.net  Tue Oct 13 19:07:33 2020
From: simonis at openjdk.java.net (Volker Simonis)
Date: Tue, 13 Oct 2020 19:07:33 GMT
Subject: RFR: 8253952: Refine ZipOutputStream.putNextEntry() to
 recalculate ZipEntry's compressed size [v6]
In-Reply-To: <0nq5oFKOj6AZqCW6jF268-6oKRI6UkS6TRIHo-_5vKw=.d13c7016-4473-4b20-9117-100b368d3716@github.com>
References: <0nq5oFKOj6AZqCW6jF268-6oKRI6UkS6TRIHo-_5vKw=.d13c7016-4473-4b20-9117-100b368d3716@github.com>
Message-ID: <_XrGXAUZwdxVWjx_vSOg2LK-YzijZ7c46-ract7Znd0=.f4f7b55e-ea86-4b5f-8322-9311b0fc3a87@github.com>

> ### Summary
> 
> Work around wrong usage of `ZipOutputStream.putNextEntry()` in user code which can lead to the `ZipException "invalid
> entry compressed size"`.
> ### Motivation
> 
> In general it is not safe to directly write a ZipEntry obtained from `ZipInputStream.getNextEntry()`,
> `ZipFile.entries()`, `ZipFile.getEntry()` or `ZipFile.stream()` with `ZipOutputStream.putNextEntry()` to a
> `ZipOutputStream` and then read the entries data from the `ZipInputStream` and write it to the `ZipOutputStream` as
> follows:
>  ZipEntry entry;
>  ZipInputStream zis = new ZipInputStream(...);
>  ZipOutputStream zos = new ZipOutputStream(...);
>  while((entry = zis.getNextEntry()) != null) {
>      zos.putNextEntry(entry);
>      zis.transferTo(zos);
>  }
> The problem with this code is that the zip file format does not record the compression level used for deflation in its
> entries. In general, it doesn't even mandate a predefined compression ratio per compression level. Therefore the
> compressed size recorded in a `ZipEntry` read from a zip file might differ from the new compressed size produced by the
> receiving `ZipOutputStream`. Such a difference will result in a `ZipException` with the following message:
>  java.util.zip.ZipException: invalid entry compressed size (expected 12 but got 7 bytes)
>  
> The correct way of copying all entries from one zip file into another requires the creation of a new `ZipEntry` or at
> least resetting of the compressed size field. E.g.:
>  while((entry = zis.getNextEntry()) != null) {
>      ZipEntry newEntry = new ZipEntry(entry.getName());
>      zos.putNextEntry(newEntry);
>      zis.transferTo(zos);
>  }
> or:
>  while((entry = zis.getNextEntry()) != null) {
>      entry.setCompressedSize(-1);
>      zos.putNextEntry(entry);
>      zis.transferTo(zos);
>  }
> Unfortunately, there's a lot of user code out there which gets this wrong and uses the bad coding pattern described
> before. Searching for `"java.util.zip.ZipException: invalid entry compressed size (expected 12 but got 7 bytes)"` gives
> ~2500 hits (~100 on StackOverflow). It's also no hard to find plenty of instances of this anti-pattern on GitHub when
> doing a code search for `ZipEntry` and `putNextEntry()`. E.g. [Gradle 4.x wrapper task][1] is affected as well as the
> latest version of the [mockableAndroidJar task][2]. I've recently fixed two occurrences of this pattern in OpenJDK (see
> [JDK-8240333][3] and [JDK-8240235][4]) but there still exist more of them (e.g.
> [`test/jdk/java/util/zip/ZipFile/CopyJar.java`][5] which is there since 1999 :).  ### Description  So while this has
> clearly been a problem before, it apparently wasn't painful enough to trigger any action from the side of the JDK.
> However, recently quite some zlib forks with [superior deflate/inflate performance have evolved][6]. Using them with
> OpenJDK is quite straight-forward: one just has to configure the alternative implementations by setting
> `LD_LIBRARY_PATH` or `LD_PRELOAD` correspondingly. We've seen big saving by using these new zlib implementations for
> selected services in production and the only reason why we haven't enabled them by default until now is the problem
> I've just described. The reason why these new libraries uncover the described anti-pattern much more often is because
> their compression ratio is slightly different from that of the default zlib library. This can easily trigger a
> `ZipException` even if an application is not using a different compression levels but just a zip file created with
> another zlib version.  I'd therefore like to propose the following workaround for the wrong
> `ZipOutputStream.putNextEntry()` usage in user code:
> -  ignore the compressed size if it was implicitly determined from the zip file and not explicitly set by calling
>    `ZipEntry.setCompressedSize()`.
> 
> - Change the API-documentation of `ZipOutputStream.putNextEntry()` and `JarOutputStream.putNextEntry()` to explain the
>   problem and why `putNextEntry()` will ignore the compressed size of a `ZipEntry` if that was set implicitely when
>   reading that entry from a `ZipFile` or `ZipInputStream`.
> 
> 
> ### Technical Details
> 
> A zip file consists of a stream of File Entries followed by a Central Directory (see [here for a more detailed
> specification][7]). Each File Entry is composed of a Local File Header (LFH) followed by the compressed Data and an
> optional Data Descriptor. The LFH contains the File Name and among other attributes the Compressed and Uncompressed
> size and CRC of the Data. In the case where the latter three attributes are not available at the time when the LFH is
> created, this fact will be recorded in a flag of the LFH and will trigger the creation of a Data Descriptor with the
> corresponding information right after the Data section. Finally, the Central Directory contains one Central Directory
> File Header (CDFH) for each entry of the  zip archive. The CDFH is an extended version of the LFH and the ultimate
> reference for the contents of the zip archive. The redundancy between LFH and CDFH is a tribute to zip's long history
> when it was used to store archives on multiple floppy discs and the CDFH allowed to update the archive by only writing
> to the last disc which contained the Central Directory.  `ZipEntries` read with `ZipInputStream.getNextEntry()` will
> initially only contain the information from the LFH. Only after the next entry was read (or after
> `ZipInputStream.closeEntry()` was called explicitly), will the previously read entry be updated with the data from the
> Data Descriptor. `ZipInputStream` doesn't inspect the Central Directory at all.  On the other hand, `ZipFile` only
> queries the Central Directory for `ZipEntry` information so all `ZipEntries` returned by `ZipFile.entries()`,
> `ZipFile.getEntry()` and `ZipFile.stream()` will always instantly contain the full Compressed and Uncompressed Size and
> CRC information for each entry independently of the LFH contents.  ### Risks and Assumptions  If we choose to ignore
> the implicitly recorded compressed size in a `ZipEntry` read from a zip file when writing it to a `ZipOutputStream`,
> this will lead to zip files with incomplete information in the LFH and an additional Data Descriptor as described
> before. However, the result is still fully compatible to the zip file specification. It's also not unusual, because by
> default all new zip files created with `ZipOutputStream` will contain LFHs without Compressed and Uncompressed Size and
> CRC information and an additional Data Descriptor. Theoretically it is possible to create new zip files with
> `ZipOutputStream` class and Compressed and Uncompressed Size and CRC information in the LFH but that's complex and
> inefficient because it requires two steps. A first step to determine the crc and compressed size of the data and a
> second step to actually write the data to the `ZipOutputStream` (which will compress it a second time). This is because
> the current API offers no possibility to write already compressed data to a `ZipOutputStream`.  Consequently, the only
> straight-forward way of creating zip files from Java which have all the data in the LFH and no Data Descriptor is by
> copying `ZipEntries` from an existing zip file with the buggy method described before. This incidentally worked more or
> less reliable for a long time but breaks miserably when using different zlib implementations. Ignoring the implicitly
> set compressed size of `ZipEntries` can easily fix this problem.  I'm not aware of any tool which can not handle such
> files and if it exists it would have problems with the majority of Java created zip files anyway (e.g. all jar-files
> created with the jar tool have zip entries with incomplete LFH data and additional Data Descriptor).  Ignoring the
> implicitly set compressed size of `ZipEntries` has no measurable performance impact and will increase the size of zip
> archives which used to have the complete file information in the LFH before by 16 bytes per entry. On the other hand it
> will give us the freedom to use whatever zip implementation we like :)   [1]:
> https://github.com/gradle/gradle/blob/e76905e3a/subprojects/build-init/src/main/java/org/gradle/api/tasks/wrapper/Wrapper.java#L152-L158
> [2]:
> https://android.googlesource.com/platform/tools/base/+/refs/heads/master/build-system/builder/src/main/java/com/android/builder/testing/MockableJarGenerator.java#86
> [3]: https://bugs.openjdk.java.net/browse/JDK-8240333 [4]: https://bugs.openjdk.java.net/browse/JDK-8240235 [5]:
> https://github.com/openjdk/jdk/blob/master/test/jdk/java/util/zip/ZipFile/CopyJar.java [6]:
> https://github.com/simonis/zlib-bench/blob/master/Results.md [7]: https://en.wikipedia.org/wiki/Zip_(file_format)

Volker Simonis 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:

  8253952: Refine ZipOutputStream.putNextEntry() to recalculate ZipEntry's compressed size

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/520/files
  - new: https://git.openjdk.java.net/jdk/pull/520/files/0e2e130a..7f032e0f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=520&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=520&range=04-05

  Stats: 9 lines in 2 files changed: 3 ins; 0 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/520.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/520/head:pull/520

PR: https://git.openjdk.java.net/jdk/pull/520

From simonis at openjdk.java.net  Tue Oct 13 19:07:37 2020
From: simonis at openjdk.java.net (Volker Simonis)
Date: Tue, 13 Oct 2020 19:07:37 GMT
Subject: RFR: 8253952: Refine ZipOutputStream.putNextEntry() to
 recalculate ZipEntry's compressed size [v4]
In-Reply-To: <SthiB8Qk3SsYn44ueXigiYQ7D0ybcLujCAKqrSezlSQ=.9ed2cbe3-1348-48ce-be8e-4c03798a494a@github.com>
References: <0nq5oFKOj6AZqCW6jF268-6oKRI6UkS6TRIHo-_5vKw=.d13c7016-4473-4b20-9117-100b368d3716@github.com>
 <qi-3I4yAOah36I8pLGLl9Vcfq-1R335KpxyaWHJsJKU=.e6939ba1-7cc8-45b4-af11-694db930d0cb@github.com>
 <SthiB8Qk3SsYn44ueXigiYQ7D0ybcLujCAKqrSezlSQ=.9ed2cbe3-1348-48ce-be8e-4c03798a494a@github.com>
Message-ID: <wzbNoBaA91RRVbHJMt0FPCL7wTOR1EKETQUfRpIE0F4=.646cfd93-55a3-40ac-b2c7-199769a20379@github.com>

On Tue, 13 Oct 2020 17:16:21 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Volker Simonis has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev
>> excludes the unrelated changes brought in by the merge/rebase.
>
> test/jdk/java/util/zip/CopyZipFile.java line 149:
> 
>> 147:         os = new ByteArrayOutputStream();
>> 148:         zos = new ZipOutputStream(os);
>> 149:         ZipFile zf = new ZipFile(ZIP_FILE);
> 
> Any reason to not use try with resources here as well (and below)

Done

-------------

PR: https://git.openjdk.java.net/jdk/pull/520

From simonis at openjdk.java.net  Tue Oct 13 19:07:37 2020
From: simonis at openjdk.java.net (Volker Simonis)
Date: Tue, 13 Oct 2020 19:07:37 GMT
Subject: RFR: 8253952: Refine ZipOutputStream.putNextEntry() to
 recalculate ZipEntry's compressed size [v4]
In-Reply-To: <J0kyw_XsAiNTXEkUyWMcGrkfuMvPVswt5Ai4LkFlNLM=.1b7d16dd-f10c-4e0e-9c8a-440e9d9547b7@github.com>
References: <0nq5oFKOj6AZqCW6jF268-6oKRI6UkS6TRIHo-_5vKw=.d13c7016-4473-4b20-9117-100b368d3716@github.com>
 <qi-3I4yAOah36I8pLGLl9Vcfq-1R335KpxyaWHJsJKU=.e6939ba1-7cc8-45b4-af11-694db930d0cb@github.com>
 <MeLRom5-27c7jNwMT1t6suOqbH70Sajvoi-6xA-M7KA=.f9a79458-296d-4106-8596-1b1c49e460e2@github.com>
 <J0kyw_XsAiNTXEkUyWMcGrkfuMvPVswt5Ai4LkFlNLM=.1b7d16dd-f10c-4e0e-9c8a-440e9d9547b7@github.com>
Message-ID: <C0poXMWR3NILmeKBw38CmLY_VqhEUAEe2XW-KpGHzHs=.b579471e-7f57-485e-a19e-b1eba1c91573@github.com>

On Tue, 13 Oct 2020 18:50:00 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/jar/JarOutputStream.java line 87:
>> 
>>> 85:      * <p>
>>> 86:      * The current time will be used if the entry has no set modification
>>> 87:      * time.
>> 
>> I'm happy with the wording. What you think about put a p tag before "The default compression method ..." so that it
>> goes into its own paragraph? I'm asking because it's inconsistent to have the first paragraph include the details on
>> the compression method and the details on the current time pushed into a second paragraph - if you generate the javadoc
>> then you'll see what I mean.
>
> I think that is a good idea to at the paragraph tag as you suggest

Done

-------------

PR: https://git.openjdk.java.net/jdk/pull/520

From rriggs at openjdk.java.net  Tue Oct 13 19:51:30 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 13 Oct 2020 19:51:30 GMT
Subject: RFR: 8251989: Hex formatting and parsing utility [v2]
In-Reply-To: <HSEn47GMS1K3g57mrTZeQk-WZHl3pKGHpX_OOf8VnsU=.740863c2-f9e4-43c4-b500-614aab4078b1@github.com>
References: <HSEn47GMS1K3g57mrTZeQk-WZHl3pKGHpX_OOf8VnsU=.740863c2-f9e4-43c4-b500-614aab4078b1@github.com>
Message-ID: <Op6a9I7ariq5HWMwVGp_58VyMpElYx41ACVJXc3UdXc=.2faa2c38-503f-4236-9d5c-7afb3ba3f0ef@github.com>

> java.util.HexFormat utility:
> 
>  - Format and parse hexadecimal strings, with parameters for delimiter, prefix, suffix and upper/lowercase
>  - Static factories and builder methods to create HexFormat copies with modified parameters.
>  - Consistent naming of methods for conversion of byte arrays to formatted strings and back: formatHex and parseHex
>  - Consistent naming of methods for conversion of primitive types: toHexDigits... and fromHexDigits...
>  - Prefix and suffixes now apply to each formatted value, not the string as a whole
>  - Using java.util.Appendable as a target for buffered conversions so output to Writers and PrintStreams
>    like System.out are supported in addition to StringBuilder. (IOExceptions are converted to unchecked exceptions)
>  - Immutable and thread safe, a "value-based" class
> 
> See the [HexFormat
> javadoc](http://cr.openjdk.java.net/~rriggs/8251989-hex-formatter/java.base/java/util/HexFormat.html) for details.
> Review comments and suggestions welcome.

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Various code review comments, rename UpperCase and LowerCase methods to match Character, remove unnecessary Class name
  qualifications, etc.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/482/files
  - new: https://git.openjdk.java.net/jdk/pull/482/files/c1bb4514..3170b498

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=482&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=482&range=00-01

  Stats: 61 lines in 9 files changed: 5 ins; 2 del; 54 mod
  Patch: https://git.openjdk.java.net/jdk/pull/482.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/482/head:pull/482

PR: https://git.openjdk.java.net/jdk/pull/482

From lancea at openjdk.java.net  Tue Oct 13 19:59:20 2020
From: lancea at openjdk.java.net (Lance Andersen)
Date: Tue, 13 Oct 2020 19:59:20 GMT
Subject: RFR: 8253952: Refine ZipOutputStream.putNextEntry() to
 recalculate ZipEntry's compressed size [v6]
In-Reply-To: <_XrGXAUZwdxVWjx_vSOg2LK-YzijZ7c46-ract7Znd0=.f4f7b55e-ea86-4b5f-8322-9311b0fc3a87@github.com>
References: <0nq5oFKOj6AZqCW6jF268-6oKRI6UkS6TRIHo-_5vKw=.d13c7016-4473-4b20-9117-100b368d3716@github.com>
 <_XrGXAUZwdxVWjx_vSOg2LK-YzijZ7c46-ract7Znd0=.f4f7b55e-ea86-4b5f-8322-9311b0fc3a87@github.com>
Message-ID: <75L2BpBchAkkPMo8-DtsWC48mN8N9wcdXfLH-e854L4=.bd404a73-6045-4fff-8143-5097041411b3@github.com>

On Tue, 13 Oct 2020 19:07:33 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> ### Summary
>> 
>> Work around wrong usage of `ZipOutputStream.putNextEntry()` in user code which can lead to the `ZipException "invalid
>> entry compressed size"`.
>> ### Motivation
>> 
>> In general it is not safe to directly write a ZipEntry obtained from `ZipInputStream.getNextEntry()`,
>> `ZipFile.entries()`, `ZipFile.getEntry()` or `ZipFile.stream()` with `ZipOutputStream.putNextEntry()` to a
>> `ZipOutputStream` and then read the entries data from the `ZipInputStream` and write it to the `ZipOutputStream` as
>> follows:
>>  ZipEntry entry;
>>  ZipInputStream zis = new ZipInputStream(...);
>>  ZipOutputStream zos = new ZipOutputStream(...);
>>  while((entry = zis.getNextEntry()) != null) {
>>      zos.putNextEntry(entry);
>>      zis.transferTo(zos);
>>  }
>> The problem with this code is that the zip file format does not record the compression level used for deflation in its
>> entries. In general, it doesn't even mandate a predefined compression ratio per compression level. Therefore the
>> compressed size recorded in a `ZipEntry` read from a zip file might differ from the new compressed size produced by the
>> receiving `ZipOutputStream`. Such a difference will result in a `ZipException` with the following message:
>>  java.util.zip.ZipException: invalid entry compressed size (expected 12 but got 7 bytes)
>>  
>> The correct way of copying all entries from one zip file into another requires the creation of a new `ZipEntry` or at
>> least resetting of the compressed size field. E.g.:
>>  while((entry = zis.getNextEntry()) != null) {
>>      ZipEntry newEntry = new ZipEntry(entry.getName());
>>      zos.putNextEntry(newEntry);
>>      zis.transferTo(zos);
>>  }
>> or:
>>  while((entry = zis.getNextEntry()) != null) {
>>      entry.setCompressedSize(-1);
>>      zos.putNextEntry(entry);
>>      zis.transferTo(zos);
>>  }
>> Unfortunately, there's a lot of user code out there which gets this wrong and uses the bad coding pattern described
>> before. Searching for `"java.util.zip.ZipException: invalid entry compressed size (expected 12 but got 7 bytes)"` gives
>> ~2500 hits (~100 on StackOverflow). It's also no hard to find plenty of instances of this anti-pattern on GitHub when
>> doing a code search for `ZipEntry` and `putNextEntry()`. E.g. [Gradle 4.x wrapper task][1] is affected as well as the
>> latest version of the [mockableAndroidJar task][2]. I've recently fixed two occurrences of this pattern in OpenJDK (see
>> [JDK-8240333][3] and [JDK-8240235][4]) but there still exist more of them (e.g.
>> [`test/jdk/java/util/zip/ZipFile/CopyJar.java`][5] which is there since 1999 :).  ### Description  So while this has
>> clearly been a problem before, it apparently wasn't painful enough to trigger any action from the side of the JDK.
>> However, recently quite some zlib forks with [superior deflate/inflate performance have evolved][6]. Using them with
>> OpenJDK is quite straight-forward: one just has to configure the alternative implementations by setting
>> `LD_LIBRARY_PATH` or `LD_PRELOAD` correspondingly. We've seen big saving by using these new zlib implementations for
>> selected services in production and the only reason why we haven't enabled them by default until now is the problem
>> I've just described. The reason why these new libraries uncover the described anti-pattern much more often is because
>> their compression ratio is slightly different from that of the default zlib library. This can easily trigger a
>> `ZipException` even if an application is not using a different compression levels but just a zip file created with
>> another zlib version.  I'd therefore like to propose the following workaround for the wrong
>> `ZipOutputStream.putNextEntry()` usage in user code:
>> -  ignore the compressed size if it was implicitly determined from the zip file and not explicitly set by calling
>>    `ZipEntry.setCompressedSize()`.
>> 
>> - Change the API-documentation of `ZipOutputStream.putNextEntry()` and `JarOutputStream.putNextEntry()` to explain the
>>   problem and why `putNextEntry()` will ignore the compressed size of a `ZipEntry` if that was set implicitely when
>>   reading that entry from a `ZipFile` or `ZipInputStream`.
>> 
>> 
>> ### Technical Details
>> 
>> A zip file consists of a stream of File Entries followed by a Central Directory (see [here for a more detailed
>> specification][7]). Each File Entry is composed of a Local File Header (LFH) followed by the compressed Data and an
>> optional Data Descriptor. The LFH contains the File Name and among other attributes the Compressed and Uncompressed
>> size and CRC of the Data. In the case where the latter three attributes are not available at the time when the LFH is
>> created, this fact will be recorded in a flag of the LFH and will trigger the creation of a Data Descriptor with the
>> corresponding information right after the Data section. Finally, the Central Directory contains one Central Directory
>> File Header (CDFH) for each entry of the  zip archive. The CDFH is an extended version of the LFH and the ultimate
>> reference for the contents of the zip archive. The redundancy between LFH and CDFH is a tribute to zip's long history
>> when it was used to store archives on multiple floppy discs and the CDFH allowed to update the archive by only writing
>> to the last disc which contained the Central Directory.  `ZipEntries` read with `ZipInputStream.getNextEntry()` will
>> initially only contain the information from the LFH. Only after the next entry was read (or after
>> `ZipInputStream.closeEntry()` was called explicitly), will the previously read entry be updated with the data from the
>> Data Descriptor. `ZipInputStream` doesn't inspect the Central Directory at all.  On the other hand, `ZipFile` only
>> queries the Central Directory for `ZipEntry` information so all `ZipEntries` returned by `ZipFile.entries()`,
>> `ZipFile.getEntry()` and `ZipFile.stream()` will always instantly contain the full Compressed and Uncompressed Size and
>> CRC information for each entry independently of the LFH contents.  ### Risks and Assumptions  If we choose to ignore
>> the implicitly recorded compressed size in a `ZipEntry` read from a zip file when writing it to a `ZipOutputStream`,
>> this will lead to zip files with incomplete information in the LFH and an additional Data Descriptor as described
>> before. However, the result is still fully compatible to the zip file specification. It's also not unusual, because by
>> default all new zip files created with `ZipOutputStream` will contain LFHs without Compressed and Uncompressed Size and
>> CRC information and an additional Data Descriptor. Theoretically it is possible to create new zip files with
>> `ZipOutputStream` class and Compressed and Uncompressed Size and CRC information in the LFH but that's complex and
>> inefficient because it requires two steps. A first step to determine the crc and compressed size of the data and a
>> second step to actually write the data to the `ZipOutputStream` (which will compress it a second time). This is because
>> the current API offers no possibility to write already compressed data to a `ZipOutputStream`.  Consequently, the only
>> straight-forward way of creating zip files from Java which have all the data in the LFH and no Data Descriptor is by
>> copying `ZipEntries` from an existing zip file with the buggy method described before. This incidentally worked more or
>> less reliable for a long time but breaks miserably when using different zlib implementations. Ignoring the implicitly
>> set compressed size of `ZipEntries` can easily fix this problem.  I'm not aware of any tool which can not handle such
>> files and if it exists it would have problems with the majority of Java created zip files anyway (e.g. all jar-files
>> created with the jar tool have zip entries with incomplete LFH data and additional Data Descriptor).  Ignoring the
>> implicitly set compressed size of `ZipEntries` has no measurable performance impact and will increase the size of zip
>> archives which used to have the complete file information in the LFH before by 16 bytes per entry. On the other hand it
>> will give us the freedom to use whatever zip implementation we like :)   [1]:
>> https://github.com/gradle/gradle/blob/e76905e3a/subprojects/build-init/src/main/java/org/gradle/api/tasks/wrapper/Wrapper.java#L152-L158
>> [2]:
>> https://android.googlesource.com/platform/tools/base/+/refs/heads/master/build-system/builder/src/main/java/com/android/builder/testing/MockableJarGenerator.java#86
>> [3]: https://bugs.openjdk.java.net/browse/JDK-8240333 [4]: https://bugs.openjdk.java.net/browse/JDK-8240235 [5]:
>> https://github.com/openjdk/jdk/blob/master/test/jdk/java/util/zip/ZipFile/CopyJar.java [6]:
>> https://github.com/simonis/zlib-bench/blob/master/Results.md [7]: https://en.wikipedia.org/wiki/Zip_(file_format)
>
> Volker Simonis has refreshed the contents of this pull request, and previous commits have been removed. The incremental
> views will show differences compared to the previous content of the PR.

test/jdk/java/util/zip/CopyZipFile.java line 104:

> 102:         // all these fields set to '-1'.
> 103:         InputStream is = new FileInputStream(ZIP_FILE);
> 104:         ZipInputStream zis = new ZipInputStream(is);

Any reason not to include the the ZipInputStream and InputStream in the try with Resources and the ZipFile below?  I
know these are nits, but just curious or was it an over site?

I think we are good otherwise

-------------

PR: https://git.openjdk.java.net/jdk/pull/520

From mdoerr at openjdk.java.net  Tue Oct 13 20:00:22 2020
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Tue, 13 Oct 2020 20:00:22 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v4]
In-Reply-To: <6Voyfr_s-ieyRA-8Rtvvpz7tkhhicA8sY2d2KTp3Kmw=.fa256bae-2143-4b43-bfea-5837ad31eb6a@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <45FtTQB1m6HyZSASY42STMkQffIWlVPibWn9_r00xYs=.daad2653-2571-491f-8dd7-5954fe4ece00@github.com>
 <u6HLR2PyvWgYbA58W3bCF4n38tpwQu2-ujPMvGpyyuo=.5a80f17c-83d5-4dc9-bad0-00e679fdd4be@github.com>
 <7-p-Kc9lQyyuoWdNtmgbXbwkxsgk4oQGKmFSCcMpvnU=.97810c01-3200-4767-bbd4-35d53c2bc5ca@github.com>
 <6Voyfr_s-ieyRA-8Rtvvpz7tkhhicA8sY2d2KTp3Kmw=.fa256bae-2143-4b43-bfea-5837ad31eb6a@github.com>
Message-ID: <fFQfDMqdwosVGzcaJfblklUy1nPsEdZJI7ALmKq9XJs=.e869160e-76e7-4a6b-b45b-e9763d1ad06f@github.com>

On Mon, 12 Oct 2020 22:00:24 GMT, CoreyAshford <github.com+51754783+CoreyAshford at openjdk.org> wrote:

>> This latest push passes the intrinsic regression test. I had run the intrinsic TestBase64 regression test on the
>> previous push, but not the one in utils.  Interesting.  Somehow it didn't occur to me that there could be a problem
>> there if the intrinsic TestBase64 test passed.  I will check into the other regression test.  Don't review this latest
>> push just yet.
>
> Ok, all is clear.  I just ran `jdk/java/util/Base64/TestBase64.java` which passes as well.  Please review again when
> convenient.

Hi Corey,

thanks for taking some stuff out of the ?too short? path.
There may be a performance regression when decoding many short arrays because of the stub call overhead and the usage
of the slower part of the Java implementation.

We could do it a little better in many cases to compute the maximum possible iteration count i:
i = (sl - sp) / block_size
if (i * block_size > sl - 12) i--
if (i <= 0) return 0
What do you think?

I don?t think branch prediction hints are helpful for the ?too short? check.

And we should better use CCR1 instead of CCR2 which is specified as non-volatile.

Did you already find a 2nd reviewer for the PPC64 part?

Best regards,
Martin



From: CoreyAshford <notifications at github.com>
Sent: Dienstag, 13. Oktober 2020 00:01
To: openjdk/jdk <jdk at noreply.github.com>
Cc: Doerr, Martin <martin.doerr at sap.com>; Mention <mention at noreply.github.com>
Subject: Re: [openjdk/jdk] 8248188: Add IntrinsicCandidate and API for Base64 decoding (#293)


Ok, all is clear. I just ran jdk/java/util/Base64/TestBase64.java which passes as well. Please review again when
convenient.

?
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<https://github.com/openjdk/jdk/pull/293#issuecomment-707367283>, or
unsubscribe<https://github.com/notifications/unsubscribe-auth/AKR64KGYKHVCHZYEHSHMSD3SKN4ARANCNFSM4RVHNW5Q>.

-------------

PR: https://git.openjdk.java.net/jdk/pull/293

From lancea at openjdk.java.net  Tue Oct 13 20:03:23 2020
From: lancea at openjdk.java.net (Lance Andersen)
Date: Tue, 13 Oct 2020 20:03:23 GMT
Subject: RFR: 8253952: Refine ZipOutputStream.putNextEntry() to
 recalculate ZipEntry's compressed size [v6]
In-Reply-To: <_XrGXAUZwdxVWjx_vSOg2LK-YzijZ7c46-ract7Znd0=.f4f7b55e-ea86-4b5f-8322-9311b0fc3a87@github.com>
References: <0nq5oFKOj6AZqCW6jF268-6oKRI6UkS6TRIHo-_5vKw=.d13c7016-4473-4b20-9117-100b368d3716@github.com>
 <_XrGXAUZwdxVWjx_vSOg2LK-YzijZ7c46-ract7Znd0=.f4f7b55e-ea86-4b5f-8322-9311b0fc3a87@github.com>
Message-ID: <nMgXzqm7wNvfYsI_4f-sqjOrT6y5FCuH-WBKH4g6RYQ=.0aefe46c-cf30-4663-95c0-34af7b0c1dc2@github.com>

On Tue, 13 Oct 2020 19:07:33 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> ### Summary
>> 
>> Work around wrong usage of `ZipOutputStream.putNextEntry()` in user code which can lead to the `ZipException "invalid
>> entry compressed size"`.
>> ### Motivation
>> 
>> In general it is not safe to directly write a ZipEntry obtained from `ZipInputStream.getNextEntry()`,
>> `ZipFile.entries()`, `ZipFile.getEntry()` or `ZipFile.stream()` with `ZipOutputStream.putNextEntry()` to a
>> `ZipOutputStream` and then read the entries data from the `ZipInputStream` and write it to the `ZipOutputStream` as
>> follows:
>>  ZipEntry entry;
>>  ZipInputStream zis = new ZipInputStream(...);
>>  ZipOutputStream zos = new ZipOutputStream(...);
>>  while((entry = zis.getNextEntry()) != null) {
>>      zos.putNextEntry(entry);
>>      zis.transferTo(zos);
>>  }
>> The problem with this code is that the zip file format does not record the compression level used for deflation in its
>> entries. In general, it doesn't even mandate a predefined compression ratio per compression level. Therefore the
>> compressed size recorded in a `ZipEntry` read from a zip file might differ from the new compressed size produced by the
>> receiving `ZipOutputStream`. Such a difference will result in a `ZipException` with the following message:
>>  java.util.zip.ZipException: invalid entry compressed size (expected 12 but got 7 bytes)
>>  
>> The correct way of copying all entries from one zip file into another requires the creation of a new `ZipEntry` or at
>> least resetting of the compressed size field. E.g.:
>>  while((entry = zis.getNextEntry()) != null) {
>>      ZipEntry newEntry = new ZipEntry(entry.getName());
>>      zos.putNextEntry(newEntry);
>>      zis.transferTo(zos);
>>  }
>> or:
>>  while((entry = zis.getNextEntry()) != null) {
>>      entry.setCompressedSize(-1);
>>      zos.putNextEntry(entry);
>>      zis.transferTo(zos);
>>  }
>> Unfortunately, there's a lot of user code out there which gets this wrong and uses the bad coding pattern described
>> before. Searching for `"java.util.zip.ZipException: invalid entry compressed size (expected 12 but got 7 bytes)"` gives
>> ~2500 hits (~100 on StackOverflow). It's also no hard to find plenty of instances of this anti-pattern on GitHub when
>> doing a code search for `ZipEntry` and `putNextEntry()`. E.g. [Gradle 4.x wrapper task][1] is affected as well as the
>> latest version of the [mockableAndroidJar task][2]. I've recently fixed two occurrences of this pattern in OpenJDK (see
>> [JDK-8240333][3] and [JDK-8240235][4]) but there still exist more of them (e.g.
>> [`test/jdk/java/util/zip/ZipFile/CopyJar.java`][5] which is there since 1999 :).  ### Description  So while this has
>> clearly been a problem before, it apparently wasn't painful enough to trigger any action from the side of the JDK.
>> However, recently quite some zlib forks with [superior deflate/inflate performance have evolved][6]. Using them with
>> OpenJDK is quite straight-forward: one just has to configure the alternative implementations by setting
>> `LD_LIBRARY_PATH` or `LD_PRELOAD` correspondingly. We've seen big saving by using these new zlib implementations for
>> selected services in production and the only reason why we haven't enabled them by default until now is the problem
>> I've just described. The reason why these new libraries uncover the described anti-pattern much more often is because
>> their compression ratio is slightly different from that of the default zlib library. This can easily trigger a
>> `ZipException` even if an application is not using a different compression levels but just a zip file created with
>> another zlib version.  I'd therefore like to propose the following workaround for the wrong
>> `ZipOutputStream.putNextEntry()` usage in user code:
>> -  ignore the compressed size if it was implicitly determined from the zip file and not explicitly set by calling
>>    `ZipEntry.setCompressedSize()`.
>> 
>> - Change the API-documentation of `ZipOutputStream.putNextEntry()` and `JarOutputStream.putNextEntry()` to explain the
>>   problem and why `putNextEntry()` will ignore the compressed size of a `ZipEntry` if that was set implicitely when
>>   reading that entry from a `ZipFile` or `ZipInputStream`.
>> 
>> 
>> ### Technical Details
>> 
>> A zip file consists of a stream of File Entries followed by a Central Directory (see [here for a more detailed
>> specification][7]). Each File Entry is composed of a Local File Header (LFH) followed by the compressed Data and an
>> optional Data Descriptor. The LFH contains the File Name and among other attributes the Compressed and Uncompressed
>> size and CRC of the Data. In the case where the latter three attributes are not available at the time when the LFH is
>> created, this fact will be recorded in a flag of the LFH and will trigger the creation of a Data Descriptor with the
>> corresponding information right after the Data section. Finally, the Central Directory contains one Central Directory
>> File Header (CDFH) for each entry of the  zip archive. The CDFH is an extended version of the LFH and the ultimate
>> reference for the contents of the zip archive. The redundancy between LFH and CDFH is a tribute to zip's long history
>> when it was used to store archives on multiple floppy discs and the CDFH allowed to update the archive by only writing
>> to the last disc which contained the Central Directory.  `ZipEntries` read with `ZipInputStream.getNextEntry()` will
>> initially only contain the information from the LFH. Only after the next entry was read (or after
>> `ZipInputStream.closeEntry()` was called explicitly), will the previously read entry be updated with the data from the
>> Data Descriptor. `ZipInputStream` doesn't inspect the Central Directory at all.  On the other hand, `ZipFile` only
>> queries the Central Directory for `ZipEntry` information so all `ZipEntries` returned by `ZipFile.entries()`,
>> `ZipFile.getEntry()` and `ZipFile.stream()` will always instantly contain the full Compressed and Uncompressed Size and
>> CRC information for each entry independently of the LFH contents.  ### Risks and Assumptions  If we choose to ignore
>> the implicitly recorded compressed size in a `ZipEntry` read from a zip file when writing it to a `ZipOutputStream`,
>> this will lead to zip files with incomplete information in the LFH and an additional Data Descriptor as described
>> before. However, the result is still fully compatible to the zip file specification. It's also not unusual, because by
>> default all new zip files created with `ZipOutputStream` will contain LFHs without Compressed and Uncompressed Size and
>> CRC information and an additional Data Descriptor. Theoretically it is possible to create new zip files with
>> `ZipOutputStream` class and Compressed and Uncompressed Size and CRC information in the LFH but that's complex and
>> inefficient because it requires two steps. A first step to determine the crc and compressed size of the data and a
>> second step to actually write the data to the `ZipOutputStream` (which will compress it a second time). This is because
>> the current API offers no possibility to write already compressed data to a `ZipOutputStream`.  Consequently, the only
>> straight-forward way of creating zip files from Java which have all the data in the LFH and no Data Descriptor is by
>> copying `ZipEntries` from an existing zip file with the buggy method described before. This incidentally worked more or
>> less reliable for a long time but breaks miserably when using different zlib implementations. Ignoring the implicitly
>> set compressed size of `ZipEntries` can easily fix this problem.  I'm not aware of any tool which can not handle such
>> files and if it exists it would have problems with the majority of Java created zip files anyway (e.g. all jar-files
>> created with the jar tool have zip entries with incomplete LFH data and additional Data Descriptor).  Ignoring the
>> implicitly set compressed size of `ZipEntries` has no measurable performance impact and will increase the size of zip
>> archives which used to have the complete file information in the LFH before by 16 bytes per entry. On the other hand it
>> will give us the freedom to use whatever zip implementation we like :)   [1]:
>> https://github.com/gradle/gradle/blob/e76905e3a/subprojects/build-init/src/main/java/org/gradle/api/tasks/wrapper/Wrapper.java#L152-L158
>> [2]:
>> https://android.googlesource.com/platform/tools/base/+/refs/heads/master/build-system/builder/src/main/java/com/android/builder/testing/MockableJarGenerator.java#86
>> [3]: https://bugs.openjdk.java.net/browse/JDK-8240333 [4]: https://bugs.openjdk.java.net/browse/JDK-8240235 [5]:
>> https://github.com/openjdk/jdk/blob/master/test/jdk/java/util/zip/ZipFile/CopyJar.java [6]:
>> https://github.com/simonis/zlib-bench/blob/master/Results.md [7]: https://en.wikipedia.org/wiki/Zip_(file_format)
>
> Volker Simonis has refreshed the contents of this pull request, and previous commits have been removed. The incremental
> views will show differences compared to the previous content of the PR.

test/jdk/java/util/zip/CopyZipFile.java line 140:

> 138:         // This means that all ZipEntry objects returned from ZipFile will have correct
> 139:         // settings for these fields.
> 140:         // I the compression level was different in the initial zip file (which we can't find

typo I -> If

-------------

PR: https://git.openjdk.java.net/jdk/pull/520

From lancea at openjdk.java.net  Tue Oct 13 20:09:12 2020
From: lancea at openjdk.java.net (Lance Andersen)
Date: Tue, 13 Oct 2020 20:09:12 GMT
Subject: RFR: 8253952: Refine ZipOutputStream.putNextEntry() to
 recalculate ZipEntry's compressed size [v6]
In-Reply-To: <_XrGXAUZwdxVWjx_vSOg2LK-YzijZ7c46-ract7Znd0=.f4f7b55e-ea86-4b5f-8322-9311b0fc3a87@github.com>
References: <0nq5oFKOj6AZqCW6jF268-6oKRI6UkS6TRIHo-_5vKw=.d13c7016-4473-4b20-9117-100b368d3716@github.com>
 <_XrGXAUZwdxVWjx_vSOg2LK-YzijZ7c46-ract7Znd0=.f4f7b55e-ea86-4b5f-8322-9311b0fc3a87@github.com>
Message-ID: <KtuSZVQPZaGBsl6czNapfh-QCOIbx_8y7-TX1z8-nBQ=.173bacca-a91a-4150-a93a-cadd5d996b0f@github.com>

On Tue, 13 Oct 2020 19:07:33 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> ### Summary
>> 
>> Work around wrong usage of `ZipOutputStream.putNextEntry()` in user code which can lead to the `ZipException "invalid
>> entry compressed size"`.
>> ### Motivation
>> 
>> In general it is not safe to directly write a ZipEntry obtained from `ZipInputStream.getNextEntry()`,
>> `ZipFile.entries()`, `ZipFile.getEntry()` or `ZipFile.stream()` with `ZipOutputStream.putNextEntry()` to a
>> `ZipOutputStream` and then read the entries data from the `ZipInputStream` and write it to the `ZipOutputStream` as
>> follows:
>>  ZipEntry entry;
>>  ZipInputStream zis = new ZipInputStream(...);
>>  ZipOutputStream zos = new ZipOutputStream(...);
>>  while((entry = zis.getNextEntry()) != null) {
>>      zos.putNextEntry(entry);
>>      zis.transferTo(zos);
>>  }
>> The problem with this code is that the zip file format does not record the compression level used for deflation in its
>> entries. In general, it doesn't even mandate a predefined compression ratio per compression level. Therefore the
>> compressed size recorded in a `ZipEntry` read from a zip file might differ from the new compressed size produced by the
>> receiving `ZipOutputStream`. Such a difference will result in a `ZipException` with the following message:
>>  java.util.zip.ZipException: invalid entry compressed size (expected 12 but got 7 bytes)
>>  
>> The correct way of copying all entries from one zip file into another requires the creation of a new `ZipEntry` or at
>> least resetting of the compressed size field. E.g.:
>>  while((entry = zis.getNextEntry()) != null) {
>>      ZipEntry newEntry = new ZipEntry(entry.getName());
>>      zos.putNextEntry(newEntry);
>>      zis.transferTo(zos);
>>  }
>> or:
>>  while((entry = zis.getNextEntry()) != null) {
>>      entry.setCompressedSize(-1);
>>      zos.putNextEntry(entry);
>>      zis.transferTo(zos);
>>  }
>> Unfortunately, there's a lot of user code out there which gets this wrong and uses the bad coding pattern described
>> before. Searching for `"java.util.zip.ZipException: invalid entry compressed size (expected 12 but got 7 bytes)"` gives
>> ~2500 hits (~100 on StackOverflow). It's also no hard to find plenty of instances of this anti-pattern on GitHub when
>> doing a code search for `ZipEntry` and `putNextEntry()`. E.g. [Gradle 4.x wrapper task][1] is affected as well as the
>> latest version of the [mockableAndroidJar task][2]. I've recently fixed two occurrences of this pattern in OpenJDK (see
>> [JDK-8240333][3] and [JDK-8240235][4]) but there still exist more of them (e.g.
>> [`test/jdk/java/util/zip/ZipFile/CopyJar.java`][5] which is there since 1999 :).  ### Description  So while this has
>> clearly been a problem before, it apparently wasn't painful enough to trigger any action from the side of the JDK.
>> However, recently quite some zlib forks with [superior deflate/inflate performance have evolved][6]. Using them with
>> OpenJDK is quite straight-forward: one just has to configure the alternative implementations by setting
>> `LD_LIBRARY_PATH` or `LD_PRELOAD` correspondingly. We've seen big saving by using these new zlib implementations for
>> selected services in production and the only reason why we haven't enabled them by default until now is the problem
>> I've just described. The reason why these new libraries uncover the described anti-pattern much more often is because
>> their compression ratio is slightly different from that of the default zlib library. This can easily trigger a
>> `ZipException` even if an application is not using a different compression levels but just a zip file created with
>> another zlib version.  I'd therefore like to propose the following workaround for the wrong
>> `ZipOutputStream.putNextEntry()` usage in user code:
>> -  ignore the compressed size if it was implicitly determined from the zip file and not explicitly set by calling
>>    `ZipEntry.setCompressedSize()`.
>> 
>> - Change the API-documentation of `ZipOutputStream.putNextEntry()` and `JarOutputStream.putNextEntry()` to explain the
>>   problem and why `putNextEntry()` will ignore the compressed size of a `ZipEntry` if that was set implicitely when
>>   reading that entry from a `ZipFile` or `ZipInputStream`.
>> 
>> 
>> ### Technical Details
>> 
>> A zip file consists of a stream of File Entries followed by a Central Directory (see [here for a more detailed
>> specification][7]). Each File Entry is composed of a Local File Header (LFH) followed by the compressed Data and an
>> optional Data Descriptor. The LFH contains the File Name and among other attributes the Compressed and Uncompressed
>> size and CRC of the Data. In the case where the latter three attributes are not available at the time when the LFH is
>> created, this fact will be recorded in a flag of the LFH and will trigger the creation of a Data Descriptor with the
>> corresponding information right after the Data section. Finally, the Central Directory contains one Central Directory
>> File Header (CDFH) for each entry of the  zip archive. The CDFH is an extended version of the LFH and the ultimate
>> reference for the contents of the zip archive. The redundancy between LFH and CDFH is a tribute to zip's long history
>> when it was used to store archives on multiple floppy discs and the CDFH allowed to update the archive by only writing
>> to the last disc which contained the Central Directory.  `ZipEntries` read with `ZipInputStream.getNextEntry()` will
>> initially only contain the information from the LFH. Only after the next entry was read (or after
>> `ZipInputStream.closeEntry()` was called explicitly), will the previously read entry be updated with the data from the
>> Data Descriptor. `ZipInputStream` doesn't inspect the Central Directory at all.  On the other hand, `ZipFile` only
>> queries the Central Directory for `ZipEntry` information so all `ZipEntries` returned by `ZipFile.entries()`,
>> `ZipFile.getEntry()` and `ZipFile.stream()` will always instantly contain the full Compressed and Uncompressed Size and
>> CRC information for each entry independently of the LFH contents.  ### Risks and Assumptions  If we choose to ignore
>> the implicitly recorded compressed size in a `ZipEntry` read from a zip file when writing it to a `ZipOutputStream`,
>> this will lead to zip files with incomplete information in the LFH and an additional Data Descriptor as described
>> before. However, the result is still fully compatible to the zip file specification. It's also not unusual, because by
>> default all new zip files created with `ZipOutputStream` will contain LFHs without Compressed and Uncompressed Size and
>> CRC information and an additional Data Descriptor. Theoretically it is possible to create new zip files with
>> `ZipOutputStream` class and Compressed and Uncompressed Size and CRC information in the LFH but that's complex and
>> inefficient because it requires two steps. A first step to determine the crc and compressed size of the data and a
>> second step to actually write the data to the `ZipOutputStream` (which will compress it a second time). This is because
>> the current API offers no possibility to write already compressed data to a `ZipOutputStream`.  Consequently, the only
>> straight-forward way of creating zip files from Java which have all the data in the LFH and no Data Descriptor is by
>> copying `ZipEntries` from an existing zip file with the buggy method described before. This incidentally worked more or
>> less reliable for a long time but breaks miserably when using different zlib implementations. Ignoring the implicitly
>> set compressed size of `ZipEntries` can easily fix this problem.  I'm not aware of any tool which can not handle such
>> files and if it exists it would have problems with the majority of Java created zip files anyway (e.g. all jar-files
>> created with the jar tool have zip entries with incomplete LFH data and additional Data Descriptor).  Ignoring the
>> implicitly set compressed size of `ZipEntries` has no measurable performance impact and will increase the size of zip
>> archives which used to have the complete file information in the LFH before by 16 bytes per entry. On the other hand it
>> will give us the freedom to use whatever zip implementation we like :)   [1]:
>> https://github.com/gradle/gradle/blob/e76905e3a/subprojects/build-init/src/main/java/org/gradle/api/tasks/wrapper/Wrapper.java#L152-L158
>> [2]:
>> https://android.googlesource.com/platform/tools/base/+/refs/heads/master/build-system/builder/src/main/java/com/android/builder/testing/MockableJarGenerator.java#86
>> [3]: https://bugs.openjdk.java.net/browse/JDK-8240333 [4]: https://bugs.openjdk.java.net/browse/JDK-8240235 [5]:
>> https://github.com/openjdk/jdk/blob/master/test/jdk/java/util/zip/ZipFile/CopyJar.java [6]:
>> https://github.com/simonis/zlib-bench/blob/master/Results.md [7]: https://en.wikipedia.org/wiki/Zip_(file_format)
>
> Volker Simonis has refreshed the contents of this pull request, and previous commits have been removed. The incremental
> views will show differences compared to the previous content of the PR.

test/jdk/java/util/zip/CopyZipFile.java line 188:

> 186:                     if ("test1.txt".equals(entry.getName()) || "test2.txt".equals(entry.getName())) {
> 187:                         throw new Exception(
> 188:                             "Should throw for STORED files or files compressed with DEFAULT_COMPRESSION");

Perhaps clean up the message above "Should throw" to indicate what is being thrown

-------------

PR: https://git.openjdk.java.net/jdk/pull/520

From github.com+51754783+coreyashford at openjdk.java.net  Tue Oct 13 21:02:21 2020
From: github.com+51754783+coreyashford at openjdk.java.net (CoreyAshford)
Date: Tue, 13 Oct 2020 21:02:21 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v4]
In-Reply-To: <fFQfDMqdwosVGzcaJfblklUy1nPsEdZJI7ALmKq9XJs=.e869160e-76e7-4a6b-b45b-e9763d1ad06f@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <45FtTQB1m6HyZSASY42STMkQffIWlVPibWn9_r00xYs=.daad2653-2571-491f-8dd7-5954fe4ece00@github.com>
 <u6HLR2PyvWgYbA58W3bCF4n38tpwQu2-ujPMvGpyyuo=.5a80f17c-83d5-4dc9-bad0-00e679fdd4be@github.com>
 <7-p-Kc9lQyyuoWdNtmgbXbwkxsgk4oQGKmFSCcMpvnU=.97810c01-3200-4767-bbd4-35d53c2bc5ca@github.com>
 <6Voyfr_s-ieyRA-8Rtvvpz7tkhhicA8sY2d2KTp3Kmw=.fa256bae-2143-4b43-bfea-5837ad31eb6a@github.com>
 <fFQfDMqdwosVGzcaJfblklUy1nPsEdZJI7ALmKq9XJs=.e869160e-76e7-4a6b-b45b-e9763d1ad06f@github.com>
Message-ID: <vKcE4CeascBAQGeyu6is0Va0_k4aTrvgU41cjhG6Wdo=.4078814f-06ed-4978-9fcd-a4a5148c2bdc@github.com>

On Tue, 13 Oct 2020 19:56:42 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Hi Corey, thanks for taking some stuff out of the ?too short? path. There may be a performance regression when decoding
> many short arrays because of the stub call overhead and the usage of the slower part of the Java implementation. We
> could do it a little better in many cases to compute the maximum possible iteration count i: i = (sl - sp) / block_size
> if (i * block_size > sl - 12) i-- if (i <= 0) return 0 What do you think?

Are you thinking of a case where that produces a higher iteration count?  It looks effectively the same to me.

> I don?t think branch prediction hints are helpful for the ?too short? check.

My thinking is that most of the time when the intrinsic is called, it will not take the early exit, but I suppose when
it is processing a sub-block_size buffer, it will return early every time.  I will remove the hints.

> And we should better use CCR1 instead of CCR2 which is specified as non-volatile.

Ah, I should have checked the calling conventions.  I thought all of the CR* regs are volatile.  I will fix that.

>  Did you already find a 2nd reviewer for the PPC64 part?

Your original comment said "2nd review", so I thought you meant you need to review it again after the changes.  So, no,
I haven't looked for or found a second reviewer.  Any suggestions?  The folks on the team here have been busy with
other work.

Btw, I'm off today, so I will push commits to the above-mentioned issues tomorrow.

-------------

PR: https://git.openjdk.java.net/jdk/pull/293

From github.com+11685886+marcono1234 at openjdk.java.net  Tue Oct 13 21:52:11 2020
From: github.com+11685886+marcono1234 at openjdk.java.net (Marcono1234)
Date: Tue, 13 Oct 2020 21:52:11 GMT
Subject: RFR: 8251989: Hex formatting and parsing utility [v2]
In-Reply-To: <-mHsww0Ju9lmUWruOsKsiXIa6WOHbSaZ46JyCH6vGns=.7fb48d7c-9926-4602-9282-5af922558c3b@github.com>
References: <HSEn47GMS1K3g57mrTZeQk-WZHl3pKGHpX_OOf8VnsU=.740863c2-f9e4-43c4-b500-614aab4078b1@github.com>
 <lv3X2v4KfUM8fxWZyX8_rwGa5wVnysBQjvqnAJaDYUU=.2b36709d-5547-411d-a609-fa465c4ce17f@github.com>
 <-mHsww0Ju9lmUWruOsKsiXIa6WOHbSaZ46JyCH6vGns=.7fb48d7c-9926-4602-9282-5af922558c3b@github.com>
Message-ID: <Ui7fI4H0sjvhoelZ3uVU_alpreQz5NyimMGpCl75vzw=.d276212e-6a37-4f06-8523-669951ee06c7@github.com>

On Tue, 13 Oct 2020 16:15:51 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> test/jdk/java/util/HexFormat/HexFormatTest.java line 406:
>> 
>>> 404:
>>> 405:             int byteVal = hex.fromHexDigits(byteStr);
>>> 406:             assert(byteStr.equals("7f"));
>> 
>> Why use regular `assert` statements in this test method? TestNG's methods likely yield more useful results.
>
> These code fragments are the examples used in the javadoc; making a simple copy/paste from working code to the javadoc.
> In the example code `assert`, a Java language construct is cleaner than showing testng assertions).

Yes using test framework specific code in the example code is probably not a good idea and the `assert` statement there
makes the intention clear.

However, for unit tests I assume it can be a little bit problematic if the tests are compiled with assertions disabled.
Additionally if one of the `assert` statements fail you would only get an `AssertionError` without much additional
feedback, while test framework assertion methods usually provide pretty detailed messages and have good IDE support.
For example `assertEquals("a", "b")` would yield something like
> Expected "a" but was "b"

which makes it obvious what the issue is.

-------------

PR: https://git.openjdk.java.net/jdk/pull/482

From github.com+11685886+marcono1234 at openjdk.java.net  Tue Oct 13 22:01:12 2020
From: github.com+11685886+marcono1234 at openjdk.java.net (Marcono1234)
Date: Tue, 13 Oct 2020 22:01:12 GMT
Subject: RFR: 8251989: Hex formatting and parsing utility [v2]
In-Reply-To: <Op6a9I7ariq5HWMwVGp_58VyMpElYx41ACVJXc3UdXc=.2faa2c38-503f-4236-9d5c-7afb3ba3f0ef@github.com>
References: <HSEn47GMS1K3g57mrTZeQk-WZHl3pKGHpX_OOf8VnsU=.740863c2-f9e4-43c4-b500-614aab4078b1@github.com>
 <Op6a9I7ariq5HWMwVGp_58VyMpElYx41ACVJXc3UdXc=.2faa2c38-503f-4236-9d5c-7afb3ba3f0ef@github.com>
Message-ID: <trzkq95ap3yXCanC3th2_SXSu0D55XgPis_dcHNFLJo=.c0b229a2-b4c8-4f0c-ba7c-3efe4ead8abe@github.com>

On Tue, 13 Oct 2020 19:51:30 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> java.util.HexFormat utility:
>> 
>>  - Format and parse hexadecimal strings, with parameters for delimiter, prefix, suffix and upper/lowercase
>>  - Static factories and builder methods to create HexFormat copies with modified parameters.
>>  - Consistent naming of methods for conversion of byte arrays to formatted strings and back: formatHex and parseHex
>>  - Consistent naming of methods for conversion of primitive types: toHexDigits... and fromHexDigits...
>>  - Prefix and suffixes now apply to each formatted value, not the string as a whole
>>  - Using java.util.Appendable as a target for buffered conversions so output to Writers and PrintStreams
>>    like System.out are supported in addition to StringBuilder. (IOExceptions are converted to unchecked exceptions)
>>  - Immutable and thread safe, a "value-based" class
>> 
>> See the [HexFormat
>> javadoc](http://cr.openjdk.java.net/~rriggs/8251989-hex-formatter/java.base/java/util/HexFormat.html) for details.
>> Review comments and suggestions welcome.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Various code review comments, rename UpperCase and LowerCase methods to match Character, remove unnecessary Class name
>   qualifications, etc.

test/jdk/java/util/HexFormat/HexFormatTest.java line 383:

> 381:
> 382:     @Test
> 383:     static void testVariableLength() {

This test does not contain any assertions.

-------------

PR: https://git.openjdk.java.net/jdk/pull/482

From almatvee at openjdk.java.net  Tue Oct 13 22:07:13 2020
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Tue, 13 Oct 2020 22:07:13 GMT
Subject: RFR: JDK-8252870: Finalize (remove "incubator" from) jpackage [v2]
In-Reply-To: <C1gKE74s6f3xjeBRJ_pYlbqMrLcfkbMSq1jJdvcf92w=.e74b4173-3063-4728-b003-683fa9f85035@github.com>
References: <HlksY2mFyKG_kkZA6n6JHHIWBGJT3bjmoLG28c9q1EU=.2b9faa66-08b9-4694-a5db-9d9918039642@github.com>
 <C1gKE74s6f3xjeBRJ_pYlbqMrLcfkbMSq1jJdvcf92w=.e74b4173-3063-4728-b003-683fa9f85035@github.com>
Message-ID: <TNvpf6mH7IY5invyL2M_PWGJNnat-2VIS316XcY0xEU=.ef11956b-5903-41b8-a06a-43611adfe101@github.com>

On Tue, 13 Oct 2020 14:48:40 GMT, Andy Herrick <herrick at openjdk.org> wrote:

>> JDK-8252870: Finalize (remove "incubator" from) jpackage
>
> Andy Herrick has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8252870: Finalize (remove "incubator" from) jpackage
>     - reverting two auto-generated files, and changing module-info to "@since 16"

src/jdk.jpackage/linux/classes/module-info.java.extra line 29:

> 27:     jdk.jpackage.internal.LinuxAppBundler,
> 28:     jdk.jpackage.internal.LinuxDebBundler,
> 29:     jdk.jpackage.internal.LinuxRpmBundler;

Not sure why it was changed. Looks like git recorded file renaming incorrectly.

src/jdk.jpackage/macosx/classes/module-info.java.extra line 30:

> 28:     jdk.jpackage.internal.MacAppStoreBundler,
> 29:     jdk.jpackage.internal.MacDmgBundler,
> 30:     jdk.jpackage.internal.MacPkgBundler;

Looks like another rename issue.

src/jdk.jpackage/windows/classes/module-info.java.extra line 29:

> 27:     jdk.jpackage.internal.WinAppBundler,
> 28:     jdk.jpackage.internal.WinExeBundler,
> 29:     jdk.jpackage.internal.WinMsiBundler;

Another rename issue.

-------------

PR: https://git.openjdk.java.net/jdk/pull/633

From github.com+11685886+marcono1234 at openjdk.java.net  Tue Oct 13 22:09:11 2020
From: github.com+11685886+marcono1234 at openjdk.java.net (Marcono1234)
Date: Tue, 13 Oct 2020 22:09:11 GMT
Subject: RFR: 8251989: Hex formatting and parsing utility [v2]
In-Reply-To: <Uc4hqx2BxAFVCOqpn8XoTXNDJewaaBLzy-92Gv6LFGI=.0b4c0cb0-6226-47b5-852e-d873eff8fc37@github.com>
References: <HSEn47GMS1K3g57mrTZeQk-WZHl3pKGHpX_OOf8VnsU=.740863c2-f9e4-43c4-b500-614aab4078b1@github.com>
 <lv3X2v4KfUM8fxWZyX8_rwGa5wVnysBQjvqnAJaDYUU=.2b36709d-5547-411d-a609-fa465c4ce17f@github.com>
 <Uc4hqx2BxAFVCOqpn8XoTXNDJewaaBLzy-92Gv6LFGI=.0b4c0cb0-6226-47b5-852e-d873eff8fc37@github.com>
Message-ID: <Jh_eGktSpYY-R0l6j7e5PEOO89Me1jBL-AyY8bnZfVk=.0baeb7c9-429d-4f8d-9ad3-709d943644fe@github.com>

On Tue, 13 Oct 2020 16:24:32 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/HexFormat.java line 1015:
>> 
>>> 1013:      */
>>> 1014:     @Override
>>> 1015:     public String toString() {
>> 
>> Might be useful to also include the class name?
>
> The caller may need to provide their own context for the output.

I was thinking of the case where the caller invokes it by accident (due to incorrect code, e.g. `"..." + hexFormat`
instead of `"..." + hexFormat.toHexDigits(...)`) and then wonders what "uppercase: true, ..." means or where it even
comes from. For example `java.util.Optional` also includes "Optional[...]".

-------------

PR: https://git.openjdk.java.net/jdk/pull/482

From github.com+69653380+katyapav at openjdk.java.net  Tue Oct 13 22:13:18 2020
From: github.com+69653380+katyapav at openjdk.java.net (Ekaterina Pavlova)
Date: Tue, 13 Oct 2020 22:13:18 GMT
Subject: RFR: 8223347: Integration of Vector API (Incubator) [v4]
In-Reply-To: <QnkhIpPfeKo5Deg7nEaCsA6r7zhyO_SGRueXfq9naQU=.191a4912-1895-4dae-927d-2550181c06da@github.com>
References: <-PE4TwXgvq2bemAn_8csjn4_j7zoAolnQz6QQt3z0Wk=.eaa9999f-0713-4349-b31d-934717aa37a1@github.com>
 <QnkhIpPfeKo5Deg7nEaCsA6r7zhyO_SGRueXfq9naQU=.191a4912-1895-4dae-927d-2550181c06da@github.com>
Message-ID: <1Nola-xPBRFEk3kdLVEoJ1sO8U4OpFldV2sq_Ta4Jxs=.075fcfb4-ebba-4351-9265-e41066b5da96@github.com>

On Mon, 12 Oct 2020 12:56:10 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Paul Sandoz 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 master
>>  - Fix related to merge
>>  - HotspotIntrinsicCandidate to IntrinsicCandidate
>>  - Merge master
>>  - Fix permissions
>>  - Fix permissions
>>  - Merge master
>>  - Vector API new files
>>  - Integration of Vector API (Incubator)
>
> Build changes look good.

There are several gc tests crashed in panama-vector tier3 testing which seems are not observed in openjdk repo.
The crashes look like:
#  assert(oopDesc::is_oop(obj)) failed: not an oop: 0xfffffffffffffff1
#
# JRE version: Java(TM) SE Runtime Environment (16.0+3) (fastdebug build 16-panama+3-216)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 16-panama+3-216, mixed mode, sharing, tiered, compressed oops,
g1 gc, linux-amd64) # Problematic frame:
# V  [libjvm.so+0xd8ef94]  HandleArea::allocate_handle(oop)+0x144

and the issue is actually tracked by JDK-8233199.

This issue needs to be at least analyzed before integrating Vector API.

-------------

PR: https://git.openjdk.java.net/jdk/pull/367

From ccheung at openjdk.java.net  Tue Oct 13 23:08:22 2020
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Tue, 13 Oct 2020 23:08:22 GMT
Subject: RFR: 8247666: Support Lambda proxy classes in static CDS archive
 [v5]
In-Reply-To: <ynh4JzHY75GjEn5_oCtmRNy9HMFsU34O2PlhSwD41tU=.1a3770f9-9091-429f-8d03-31b826f9b093@github.com>
References: <ynh4JzHY75GjEn5_oCtmRNy9HMFsU34O2PlhSwD41tU=.1a3770f9-9091-429f-8d03-31b826f9b093@github.com>
Message-ID: <PX8-qxYCB8jwJw8EongFi_2-HYdOkdNGkutskSoxulg=.1a85bb57-c65f-42c7-8def-a122ee150055@github.com>

> Following up on archiving lambda proxy classes in dynamic CDS archive
> ([JDK-8198698](https://bugs.openjdk.java.net/browse/JDK-8198698)), this RFE adds the functionality of archiving of
> lambda proxy classes in static CDS archive.
> When the -XX:DumpLoadedClassList is enabled, the constant pool index related to LambdaMetafactory that are resolved
> during application execution will be included in the classlist. The entry for a lambda proxy class in a class list will
> be of the following format:
> `@lambda-proxy: <classname> <cp index>`
> 
> e.g.
> `@lambda-proxy: test/java/lang/invoke/MethodHandlesGeneralTest 233`
> `@lambda-proxy: test/java/lang/invoke/MethodHandlesGeneralTest 355`
> 
> When dumping a CDS archive using the -Xshare:dump and -XX:ExtraSharedClassListFile options, when the above
> `@lambda-proxy` entry is encountered while parsing the classlist, we will resolve the corresponding constant pool
> indices (233 and 355 in the above example). As a result, lambda proxy classes will be generated for the constant pool
> entries, and will be cached using a similar mechanism to JDK-8198698.  During dumping, there is check on the cp index
> and on the created BootstrapInfo using the cp index. VM will exit with an error message if the check has failed.
> During runtime when looking up a lambda proxy class, the lookup will be perform on the static CDS archive and if not
> found, then lookup from the dynamic archive if one is specified.  (Only name change (IsDynamicDumpingEnabled ->
> IsCDSDumpingEnabled) is involved in the core-libs code.)
> Testing: tiers 1,2,3,4.
> 
> Performance results (javac on HelloWorld on linux-x64):
> Results of " perf stat -r 40 bin/javac -J-Xshare:on -J-XX:SharedArchiveFile=javac2.jsa Bench_HelloWorld.java "
>    1:   2228016795  2067752708 (-160264087)      -----    377.760   349.110 (-28.650)      -----
>    2:   2223051476  2063016483 (-160034993)      -----    374.580   350.620 (-23.960)      ----
>    3:   2225908334  2067673847 (-158234487)      -----    375.220   350.990 (-24.230)      ----
>    4:   2225835999  2064596883 (-161239116)      -----    374.670   349.840 (-24.830)      ----
>    5:   2226005510  2061694332 (-164311178)      -----    373.512   351.120 (-22.392)      ----
>    6:   2225574949  2062657482 (-162917467)      -----    374.710   348.380 (-26.330)      -----
>    7:   2224702424  2064634122 (-160068302)      -----    373.670   349.510 (-24.160)      ----
>    8:   2226662277  2066301134 (-160361143)      -----    375.350   349.790 (-25.560)      ----
>    9:   2226761470  2063162795 (-163598675)      -----    374.260   351.290 (-22.970)      ----
>   10:   2230149089  2066203307 (-163945782)      -----    374.760   350.620 (-24.140)      ----
> ============================================================
>         2226266109  2064768307 (-161497801)      -----    374.848   350.126 (-24.722)      ----
> instr delta =   -161497801    -7.2542%
> time  delta =      -24.722 ms -6.5951%

Calvin Cheung has updated the pull request with a new target base due to a merge or a rebase. The pull request now
contains ten commits:

 - fix minimal vm build issues
 - Merge branch 'master' into 8247666
 - Merge branch 'master' into 8247666
 - 1. Symbolic encoding of lambda proxy resolution. An example of @lambda-proxy in the classlist:
   @lambda-proxy: LambHello run ()Ljava/lang/Runnable; ()V 6 LambHello lambdabash ()V ()V
   2. Removed BadCPIndex.java; added LambdaProxyClassList.java test.
   3. Mandy's comments.
 - Merge branch 'master' into 8247666
 - exclude archived lambda proxy classes in the classlist
 - updated systemDictionaryShared.[c|h]pp based on suggestions from Ioi
 - fix extraneous whitespace
 - 8247666 (initial commit)

-------------

Changes: https://git.openjdk.java.net/jdk/pull/364/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=364&range=04
  Stats: 1839 lines in 32 files changed: 1767 ins; 19 del; 53 mod
  Patch: https://git.openjdk.java.net/jdk/pull/364.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/364/head:pull/364

PR: https://git.openjdk.java.net/jdk/pull/364

From kcr at openjdk.java.net  Tue Oct 13 23:25:22 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Tue, 13 Oct 2020 23:25:22 GMT
Subject: RFR: JDK-8252870: Finalize (remove "incubator" from) jpackage [v2]
In-Reply-To: <C1gKE74s6f3xjeBRJ_pYlbqMrLcfkbMSq1jJdvcf92w=.e74b4173-3063-4728-b003-683fa9f85035@github.com>
References: <HlksY2mFyKG_kkZA6n6JHHIWBGJT3bjmoLG28c9q1EU=.2b9faa66-08b9-4694-a5db-9d9918039642@github.com>
 <C1gKE74s6f3xjeBRJ_pYlbqMrLcfkbMSq1jJdvcf92w=.e74b4173-3063-4728-b003-683fa9f85035@github.com>
Message-ID: <zIaSPtyxLVlgwxZZIArKbLYL_eJ0XY20hGBzso1SZPU=.13d4ece7-fe5c-4908-a994-916bf3da17c6@github.com>

On Tue, 13 Oct 2020 14:48:40 GMT, Andy Herrick <herrick at openjdk.org> wrote:

>> JDK-8252870: Finalize (remove "incubator" from) jpackage
>
> Andy Herrick has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8252870: Finalize (remove "incubator" from) jpackage
>     - reverting two auto-generated files, and changing module-info to "@since 16"

Looks good. I double-checked all of the file renames and all are exactly as expected. The diffs got a bit confused in a
couple cases, where it thought that a renamed and modified file was copied from somewhere else (see inline comments),
but that can happen given that git doesn't actually track renames and copies).

-------------

Marked as reviewed by kcr (Author).

PR: https://git.openjdk.java.net/jdk/pull/633

From kcr at openjdk.java.net  Tue Oct 13 23:25:27 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Tue, 13 Oct 2020 23:25:27 GMT
Subject: RFR: JDK-8252870: Finalize (remove "incubator" from) jpackage [v2]
In-Reply-To: <TNvpf6mH7IY5invyL2M_PWGJNnat-2VIS316XcY0xEU=.ef11956b-5903-41b8-a06a-43611adfe101@github.com>
References: <HlksY2mFyKG_kkZA6n6JHHIWBGJT3bjmoLG28c9q1EU=.2b9faa66-08b9-4694-a5db-9d9918039642@github.com>
 <C1gKE74s6f3xjeBRJ_pYlbqMrLcfkbMSq1jJdvcf92w=.e74b4173-3063-4728-b003-683fa9f85035@github.com>
 <TNvpf6mH7IY5invyL2M_PWGJNnat-2VIS316XcY0xEU=.ef11956b-5903-41b8-a06a-43611adfe101@github.com>
Message-ID: <UGx3dOtqiGeNvfn-bklub7gYj6GrCf00yDUGzhTkgA0=.8f5757f0-26f3-4ac4-9c88-085d7a0ee7a8@github.com>

On Tue, 13 Oct 2020 21:30:05 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> Andy Herrick has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   JDK-8252870: Finalize (remove "incubator" from) jpackage
>>     - reverting two auto-generated files, and changing module-info to "@since 16"
>
> src/jdk.jpackage/linux/classes/module-info.java.extra line 29:
> 
>> 27:     jdk.jpackage.internal.LinuxAppBundler,
>> 28:     jdk.jpackage.internal.LinuxDebBundler,
>> 29:     jdk.jpackage.internal.LinuxRpmBundler;
> 
> Not sure why it was changed. Looks like git recorded file renaming incorrectly.

Yes, sometime GIt / Github get a bit confused about identifying rename/copy when generating a diff for a renamed file
with changes. The result is correct, but the diff looks odd.

> src/jdk.jpackage/macosx/classes/module-info.java.extra line 30:
> 
>> 28:     jdk.jpackage.internal.MacAppStoreBundler,
>> 29:     jdk.jpackage.internal.MacDmgBundler,
>> 30:     jdk.jpackage.internal.MacPkgBundler;
> 
> Looks like another rename issue.

Yes (or more precisely another issue displaying the diffs for a renamed file with changes).

-------------

PR: https://git.openjdk.java.net/jdk/pull/633

From almatvee at openjdk.java.net  Tue Oct 13 23:31:12 2020
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Tue, 13 Oct 2020 23:31:12 GMT
Subject: RFR: JDK-8252870: Finalize (remove "incubator" from) jpackage [v2]
In-Reply-To: <C1gKE74s6f3xjeBRJ_pYlbqMrLcfkbMSq1jJdvcf92w=.e74b4173-3063-4728-b003-683fa9f85035@github.com>
References: <HlksY2mFyKG_kkZA6n6JHHIWBGJT3bjmoLG28c9q1EU=.2b9faa66-08b9-4694-a5db-9d9918039642@github.com>
 <C1gKE74s6f3xjeBRJ_pYlbqMrLcfkbMSq1jJdvcf92w=.e74b4173-3063-4728-b003-683fa9f85035@github.com>
Message-ID: <VJcn6Tmqa7XSzjJ_MgmUXjI1ZWVmzGRdvtKAjdmu6WE=.fb10cb47-6268-4e0d-b98f-cf0f392358e2@github.com>

On Tue, 13 Oct 2020 14:48:40 GMT, Andy Herrick <herrick at openjdk.org> wrote:

>> JDK-8252870: Finalize (remove "incubator" from) jpackage
>
> Andy Herrick has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8252870: Finalize (remove "incubator" from) jpackage
>     - reverting two auto-generated files, and changing module-info to "@since 16"

Marked as reviewed by almatvee (Committer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/633

From herrick at openjdk.java.net  Tue Oct 13 23:37:09 2020
From: herrick at openjdk.java.net (Andy Herrick)
Date: Tue, 13 Oct 2020 23:37:09 GMT
Subject: RFR: JDK-8252870: Finalize (remove "incubator" from) jpackage [v2]
In-Reply-To: <VJcn6Tmqa7XSzjJ_MgmUXjI1ZWVmzGRdvtKAjdmu6WE=.fb10cb47-6268-4e0d-b98f-cf0f392358e2@github.com>
References: <HlksY2mFyKG_kkZA6n6JHHIWBGJT3bjmoLG28c9q1EU=.2b9faa66-08b9-4694-a5db-9d9918039642@github.com>
 <C1gKE74s6f3xjeBRJ_pYlbqMrLcfkbMSq1jJdvcf92w=.e74b4173-3063-4728-b003-683fa9f85035@github.com>
 <VJcn6Tmqa7XSzjJ_MgmUXjI1ZWVmzGRdvtKAjdmu6WE=.fb10cb47-6268-4e0d-b98f-cf0f392358e2@github.com>
Message-ID: <9bOP4FdFkdaon84matT7uktjcsUgbdR8VFO9Icg2Z30=.0edeffb1-9c42-4bf0-8880-a1d523fc8e7b@github.com>

On Tue, 13 Oct 2020 23:28:24 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> Andy Herrick has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   JDK-8252870: Finalize (remove "incubator" from) jpackage
>>     - reverting two auto-generated files, and changing module-info to "@since 16"
>
> Marked as reviewed by almatvee (Committer).

>  src/jdk.jpackage/macosx/classes/module-info.java.extra
>     jdk.jpackage.internal.MacAppBundler,
>     jdk.jpackage.internal.MacAppStoreBundler,
not related to this change directly, but even in 14 there was no MacAppStoreBundler

-------------

PR: https://git.openjdk.java.net/jdk/pull/633

From tvaleev at openjdk.java.net  Wed Oct 14 00:11:23 2020
From: tvaleev at openjdk.java.net (Tagir F.Valeev)
Date: Wed, 14 Oct 2020 00:11:23 GMT
Subject: RFR: 8251989: Hex formatting and parsing utility [v2]
In-Reply-To: <Op6a9I7ariq5HWMwVGp_58VyMpElYx41ACVJXc3UdXc=.2faa2c38-503f-4236-9d5c-7afb3ba3f0ef@github.com>
References: <HSEn47GMS1K3g57mrTZeQk-WZHl3pKGHpX_OOf8VnsU=.740863c2-f9e4-43c4-b500-614aab4078b1@github.com>
 <Op6a9I7ariq5HWMwVGp_58VyMpElYx41ACVJXc3UdXc=.2faa2c38-503f-4236-9d5c-7afb3ba3f0ef@github.com>
Message-ID: <dlSmcnO7uyQHpNY-G-urKku0uDjHkIXyWJke7tHtq5w=.ef001876-3099-4120-8e9a-67c7360ba2c5@github.com>

On Tue, 13 Oct 2020 19:51:30 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> java.util.HexFormat utility:
>> 
>>  - Format and parse hexadecimal strings, with parameters for delimiter, prefix, suffix and upper/lowercase
>>  - Static factories and builder methods to create HexFormat copies with modified parameters.
>>  - Consistent naming of methods for conversion of byte arrays to formatted strings and back: formatHex and parseHex
>>  - Consistent naming of methods for conversion of primitive types: toHexDigits... and fromHexDigits...
>>  - Prefix and suffixes now apply to each formatted value, not the string as a whole
>>  - Using java.util.Appendable as a target for buffered conversions so output to Writers and PrintStreams
>>    like System.out are supported in addition to StringBuilder. (IOExceptions are converted to unchecked exceptions)
>>  - Immutable and thread safe, a "value-based" class
>> 
>> See the [HexFormat
>> javadoc](http://cr.openjdk.java.net/~rriggs/8251989-hex-formatter/java.base/java/util/HexFormat.html) for details.
>> Review comments and suggestions welcome.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Various code review comments, rename UpperCase and LowerCase methods to match Character, remove unnecessary Class name
>   qualifications, etc.

Marked as reviewed by tvaleev (Committer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/482

From kvn at openjdk.java.net  Wed Oct 14 00:28:23 2020
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 14 Oct 2020 00:28:23 GMT
Subject: RFR: 8227745: Enable Escape Analysis for Better Performance in
 the Presence of JVMTI Agents [v10]
In-Reply-To: <XaPrmpfi96mMRQnto6zzZlsZeDP0jMR7LAosjDmm0Zw=.12c89fb1-a267-468b-966b-065f97aa2f28@github.com>
References: <Ll2RereRbuQLgFtIjv9pS92kPvCVuo-BI0cP1zGjVbo=.dad3a33c-0fc3-44fd-810a-f01448cf564c@github.com>
 <XaPrmpfi96mMRQnto6zzZlsZeDP0jMR7LAosjDmm0Zw=.12c89fb1-a267-468b-966b-065f97aa2f28@github.com>
Message-ID: <buqJ9cqD9APRW862aGoAk9IyvYvshoItGVRgeNqQTds=.4fc25be1-3e79-4ac8-a174-0e08cdc9fc10@github.com>

On Sat, 10 Oct 2020 08:34:23 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> Hi,
>> 
>> this is the continuation of the review of the implementation for:
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8227745
>> https://bugs.openjdk.java.net/browse/JDK-8233915
>> 
>> It allows for JIT optimizations based on escape analysis even if JVMTI agents acquire capabilities to access references
>> to objects that are subject to such optimizations, e.g. scalar replacement. The implementation reverts such
>> optimizations just before access very much as when switching from JIT compiled execution to the interpreter, aka
>> "deoptimization".  Webrev.8 was the last one before before the transition to Git/Github:
>> 
>> http://cr.openjdk.java.net/~rrich/webrevs/8227745/webrev.8/
>> 
>> Thanks, Richard.
>
> Richard Reingruber has updated the pull request with a new target base due to a merge or a rebase. The pull request now
> contains 21 commits:
>  - The constructor of StackFrameStream takes more parameters after JDK-8253180
>  - Merge branch 'master' into JDK-8227745
>  - Merge branch 'master' into JDK-8227745
>  - Merge branch 'master' into JDK-8227745
>  - Factorized fragment out of EscapeBarrier::deoptimize_objects_internal into new method in compiledVFrame.
>  - More smaller changes proposed by Serguei.
>  - jvmtiDeferredUpdates.hpp: remove forward declarations.
>  - jvmtiDeferredLocalVariable: move member variables to the beginning of the class definition.
>  - jvmtiDeferredUpdates.hpp: add/remove empty lines and improve indentation.
>  - Merge branch 'master' into JDK-8227745
>  - ... and 11 more: https://git.openjdk.java.net/jdk/compare/aaa0a2a0...06b139a9

Good.

-------------

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/119

From sviswanathan at openjdk.java.net  Wed Oct 14 00:37:22 2020
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Wed, 14 Oct 2020 00:37:22 GMT
Subject: RFR: 8223347: Integration of Vector API (Incubator) [v4]
In-Reply-To: <1Nola-xPBRFEk3kdLVEoJ1sO8U4OpFldV2sq_Ta4Jxs=.075fcfb4-ebba-4351-9265-e41066b5da96@github.com>
References: <-PE4TwXgvq2bemAn_8csjn4_j7zoAolnQz6QQt3z0Wk=.eaa9999f-0713-4349-b31d-934717aa37a1@github.com>
 <QnkhIpPfeKo5Deg7nEaCsA6r7zhyO_SGRueXfq9naQU=.191a4912-1895-4dae-927d-2550181c06da@github.com>
 <1Nola-xPBRFEk3kdLVEoJ1sO8U4OpFldV2sq_Ta4Jxs=.075fcfb4-ebba-4351-9265-e41066b5da96@github.com>
Message-ID: <WLjQafCeeog3WTntR9Y-3EBVVFg4-oe9fb-LLSwiI38=.2db52dbf-c436-462f-b897-06f1abc37b74@github.com>

On Tue, 13 Oct 2020 21:29:52 GMT, Ekaterina Pavlova <github.com+69653380+katyapav at openjdk.org> wrote:

>> Build changes look good.
>
> There are several gc tests crashed in panama-vector tier3 testing which seems are not observed in openjdk repo.
> The crashes look like:
> #  assert(oopDesc::is_oop(obj)) failed: not an oop: 0xfffffffffffffff1
> #
> # JRE version: Java(TM) SE Runtime Environment (16.0+3) (fastdebug build 16-panama+3-216)
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 16-panama+3-216, mixed mode, sharing, tiered, compressed oops,
> g1 gc, linux-amd64) # Problematic frame:
> # V  [libjvm.so+0xd8ef94]  HandleArea::allocate_handle(oop)+0x144
> 
> and the issue is actually tracked by JDK-8233199.
> 
> This issue needs to be at least analyzed before integrating Vector API.

@katyapav Is the failure observed on vector-unstable branch of panama-vector?
The code in this pull request is from vector-unstable branch.
The bug report https://bugs.openjdk.java.net/browse/JDK-8233199 refers to repo-valhalla and not
panama-vector:vector-unstable. @PaulSandoz is doing final testing of the pull request today before integration tomorrow
hopefully.

-------------

PR: https://git.openjdk.java.net/jdk/pull/367

From iklam at openjdk.java.net  Wed Oct 14 00:43:12 2020
From: iklam at openjdk.java.net (Ioi Lam)
Date: Wed, 14 Oct 2020 00:43:12 GMT
Subject: RFR: 8247666: Support Lambda proxy classes in static CDS archive
 [v5]
In-Reply-To: <PX8-qxYCB8jwJw8EongFi_2-HYdOkdNGkutskSoxulg=.1a85bb57-c65f-42c7-8def-a122ee150055@github.com>
References: <ynh4JzHY75GjEn5_oCtmRNy9HMFsU34O2PlhSwD41tU=.1a3770f9-9091-429f-8d03-31b826f9b093@github.com>
 <PX8-qxYCB8jwJw8EongFi_2-HYdOkdNGkutskSoxulg=.1a85bb57-c65f-42c7-8def-a122ee150055@github.com>
Message-ID: <wuZkq-j9ciIYkjs25F7LG9-YDFaNzWysnHWQXLT-Z3s=.2f1d4107-586a-4756-bdac-21be9d60425b@github.com>

On Tue, 13 Oct 2020 23:08:22 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> Following up on archiving lambda proxy classes in dynamic CDS archive
>> ([JDK-8198698](https://bugs.openjdk.java.net/browse/JDK-8198698)), this RFE adds the functionality of archiving of
>> lambda proxy classes in static CDS archive.
>> When the -XX:DumpLoadedClassList is enabled, the constant pool index related to LambdaMetafactory that are resolved
>> during application execution will be included in the classlist. The entry for a lambda proxy class in a class list will
>> be of the following format:
>> `@lambda-proxy: <classname> <cp index>`
>> 
>> e.g.
>> `@lambda-proxy: test/java/lang/invoke/MethodHandlesGeneralTest 233`
>> `@lambda-proxy: test/java/lang/invoke/MethodHandlesGeneralTest 355`
>> 
>> When dumping a CDS archive using the -Xshare:dump and -XX:ExtraSharedClassListFile options, when the above
>> `@lambda-proxy` entry is encountered while parsing the classlist, we will resolve the corresponding constant pool
>> indices (233 and 355 in the above example). As a result, lambda proxy classes will be generated for the constant pool
>> entries, and will be cached using a similar mechanism to JDK-8198698.  During dumping, there is check on the cp index
>> and on the created BootstrapInfo using the cp index. VM will exit with an error message if the check has failed.
>> During runtime when looking up a lambda proxy class, the lookup will be perform on the static CDS archive and if not
>> found, then lookup from the dynamic archive if one is specified.  (Only name change (IsDynamicDumpingEnabled ->
>> IsCDSDumpingEnabled) is involved in the core-libs code.)
>> Testing: tiers 1,2,3,4.
>> 
>> Performance results (javac on HelloWorld on linux-x64):
>> Results of " perf stat -r 40 bin/javac -J-Xshare:on -J-XX:SharedArchiveFile=javac2.jsa Bench_HelloWorld.java "
>>    1:   2228016795  2067752708 (-160264087)      -----    377.760   349.110 (-28.650)      -----
>>    2:   2223051476  2063016483 (-160034993)      -----    374.580   350.620 (-23.960)      ----
>>    3:   2225908334  2067673847 (-158234487)      -----    375.220   350.990 (-24.230)      ----
>>    4:   2225835999  2064596883 (-161239116)      -----    374.670   349.840 (-24.830)      ----
>>    5:   2226005510  2061694332 (-164311178)      -----    373.512   351.120 (-22.392)      ----
>>    6:   2225574949  2062657482 (-162917467)      -----    374.710   348.380 (-26.330)      -----
>>    7:   2224702424  2064634122 (-160068302)      -----    373.670   349.510 (-24.160)      ----
>>    8:   2226662277  2066301134 (-160361143)      -----    375.350   349.790 (-25.560)      ----
>>    9:   2226761470  2063162795 (-163598675)      -----    374.260   351.290 (-22.970)      ----
>>   10:   2230149089  2066203307 (-163945782)      -----    374.760   350.620 (-24.140)      ----
>> ============================================================
>>         2226266109  2064768307 (-161497801)      -----    374.848   350.126 (-24.722)      ----
>> instr delta =   -161497801    -7.2542%
>> time  delta =      -24.722 ms -6.5951%
>
> Calvin Cheung has updated the pull request with a new target base due to a merge or a rebase. The pull request now
> contains ten commits:
>  - fix minimal vm build issues
>  - Merge branch 'master' into 8247666
>  - Merge branch 'master' into 8247666
>  - 1. Symbolic encoding of lambda proxy resolution. An example of @lambda-proxy in the classlist:
>    @lambda-proxy: LambHello run ()Ljava/lang/Runnable; ()V 6 LambHello lambdabash ()V ()V
>    2. Removed BadCPIndex.java; added LambdaProxyClassList.java test.
>    3. Mandy's comments.
>  - Merge branch 'master' into 8247666
>  - exclude archived lambda proxy classes in the classlist
>  - updated systemDictionaryShared.[c|h]pp based on suggestions from Ioi
>  - fix extraneous whitespace
>  - 8247666 (initial commit)

Changes requested by iklam (Reviewer).

src/hotspot/share/interpreter/linkResolver.cpp line 34:

> 32: #include "classfile/symbolTable.hpp"
> 33: #include "classfile/systemDictionary.hpp"
> 34: #include "classfile/systemDictionaryShared.hpp"

Are all the new includes necessary?

src/hotspot/share/memory/archiveUtils.cpp line 321:

> 319:     }
> 320:   }
> 321: }

I think if two threads try call ArchiveUtils::log_to_classlist at the same time, the output may be interleaved.

classlist_file is a fileStream, which uses fwrite to write to the file. In theory, if you write the whole line at once,
the output should be thread safe (at least on POSIX and Windows). But in your case, you would need to first get the
whole line into a buffer, and then write it out at once.

I think it would be safer, and more convenient, to use a lock to ensure thready safety. Maybe we can convert all uses
of classlist_file->print() to something like

class ClassListWriter {
    static fileStream* _classlist_file;
    MutexLocker locker;
public:
   outputStream* stream() {
       return _classlist_file;
   }
   static bool is_enabled() {
     return _classlist_file != NULL && _classlist_file->is_open();
   }
   ClassListWriter() :  locker(Thread::current(), ClassListFile_lock) {}

   static void init() {
     // classlist_file init code from ostrea.cpp
   }
};

// WAS if (DumpLoadedClassList != NULL && classlist_file->is_open()) {
if (ClassListWriter::is_enabled()) {
  ClassListWriter w;
  w->stream()->print("aaaa");
  w->stream()->print("bbbb");
  w->stream()->cr();
}

src/hotspot/share/oops/instanceKlass.cpp line 4212:

> 4210:       assert(stream == NULL, "shared class with stream");
> 4211:       if (is_hidden()) {
> 4212:         // Not including archived lambda proxy class in the classlist.

I think it's clearer to say `// Don't include archived lambda proxy class in the classlist.`

src/java.base/share/classes/jdk/internal/misc/CDS.java line 78:

> 76:      * Check if CDS dumping is enabled via the DynamicDumpSharedSpaces or the DumpSharedSpaces flag.
> 77:      */
> 78:     public static native boolean isDumpingEnabled();

I think it will be more consistent if we use the same pattern as `CDS::isDumpingClassList()`

    private static final boolean isDumpingArchive;
    static {
        isDumpingClassList = isDumpingArchive0();
    }

    /**
      * Is the VM writing to a (static or dynamic) CDS archive.
      */
    public static boolean isDumpingArchive() {
        return isDumpingArchive;
    }

Then in LambdaProxyClassArchive.java, there's no need to keep a separate variable of dumpArchive. You can simply call
CDS.isDumpingArchive(). The JIT compiler will automatically inline the call so it will be just as fast.

LambdaProxyClassArchive::sharingEnabled should also be rewritten to use this pattern.

-------------

PR: https://git.openjdk.java.net/jdk/pull/364

From github.com+69653380+katyapav at openjdk.java.net  Wed Oct 14 00:50:25 2020
From: github.com+69653380+katyapav at openjdk.java.net (Ekaterina Pavlova)
Date: Wed, 14 Oct 2020 00:50:25 GMT
Subject: RFR: 8223347: Integration of Vector API (Incubator) [v4]
In-Reply-To: <WLjQafCeeog3WTntR9Y-3EBVVFg4-oe9fb-LLSwiI38=.2db52dbf-c436-462f-b897-06f1abc37b74@github.com>
References: <-PE4TwXgvq2bemAn_8csjn4_j7zoAolnQz6QQt3z0Wk=.eaa9999f-0713-4349-b31d-934717aa37a1@github.com>
 <QnkhIpPfeKo5Deg7nEaCsA6r7zhyO_SGRueXfq9naQU=.191a4912-1895-4dae-927d-2550181c06da@github.com>
 <1Nola-xPBRFEk3kdLVEoJ1sO8U4OpFldV2sq_Ta4Jxs=.075fcfb4-ebba-4351-9265-e41066b5da96@github.com>
 <WLjQafCeeog3WTntR9Y-3EBVVFg4-oe9fb-LLSwiI38=.2db52dbf-c436-462f-b897-06f1abc37b74@github.com>
Message-ID: <57GgbYK9zqtp_hlgSwgHG-vN0th0LEmLksSntjQ7mW8=.3c2a2d5f-e407-41ff-a2b1-3d89043144a2@github.com>

On Wed, 14 Oct 2020 00:34:04 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> There are several gc tests crashed in panama-vector tier3 testing which seems are not observed in openjdk repo.
>> The crashes look like:
>> #  assert(oopDesc::is_oop(obj)) failed: not an oop: 0xfffffffffffffff1
>> #
>> # JRE version: Java(TM) SE Runtime Environment (16.0+3) (fastdebug build 16-panama+3-216)
>> # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 16-panama+3-216, mixed mode, sharing, tiered, compressed oops,
>> g1 gc, linux-amd64) # Problematic frame:
>> # V  [libjvm.so+0xd8ef94]  HandleArea::allocate_handle(oop)+0x144
>> 
>> and the issue is actually tracked by JDK-8233199.
>> 
>> This issue needs to be at least analyzed before integrating Vector API.
>
> @katyapav Is the failure observed on vector-unstable branch of panama-vector?
> The code in this pull request is from vector-unstable branch.
> The bug report https://bugs.openjdk.java.net/browse/JDK-8233199 refers to repo-valhalla and not
> panama-vector:vector-unstable. @PaulSandoz is doing final testing of the pull request today before integration tomorrow
> hopefully.

@sviswa7 you are right, the failure is observed on vector-unstable branch of panama-vector.
I referred to JDK-8233199 because it seems both panama-vector and valhalla-repo have the same issue/crash.
@PaulSandoz also mentioned that panama-vector was not in sync with master and this is perhaps the issue is in
vector-unstable. He said that he tested the PR separately and didn't observe this issue in the PR.

-------------

PR: https://git.openjdk.java.net/jdk/pull/367

From mchung at openjdk.java.net  Wed Oct 14 01:47:10 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 14 Oct 2020 01:47:10 GMT
Subject: RFR: 8247666: Support Lambda proxy classes in static CDS archive
 [v5]
In-Reply-To: <wuZkq-j9ciIYkjs25F7LG9-YDFaNzWysnHWQXLT-Z3s=.2f1d4107-586a-4756-bdac-21be9d60425b@github.com>
References: <ynh4JzHY75GjEn5_oCtmRNy9HMFsU34O2PlhSwD41tU=.1a3770f9-9091-429f-8d03-31b826f9b093@github.com>
 <PX8-qxYCB8jwJw8EongFi_2-HYdOkdNGkutskSoxulg=.1a85bb57-c65f-42c7-8def-a122ee150055@github.com>
 <wuZkq-j9ciIYkjs25F7LG9-YDFaNzWysnHWQXLT-Z3s=.2f1d4107-586a-4756-bdac-21be9d60425b@github.com>
Message-ID: <DGaGgn21Mpmvucd3lJUBt1LAlzFFmQnif5lm_NuTRvA=.44b63649-52c8-45b4-9d3a-f5dad40d3e4f@github.com>

On Wed, 14 Oct 2020 00:40:14 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Calvin Cheung has updated the pull request with a new target base due to a merge or a rebase. The pull request now
>> contains ten commits:
>>  - fix minimal vm build issues
>>  - Merge branch 'master' into 8247666
>>  - Merge branch 'master' into 8247666
>>  - 1. Symbolic encoding of lambda proxy resolution. An example of @lambda-proxy in the classlist:
>>    @lambda-proxy: LambHello run ()Ljava/lang/Runnable; ()V 6 LambHello lambdabash ()V ()V
>>    2. Removed BadCPIndex.java; added LambdaProxyClassList.java test.
>>    3. Mandy's comments.
>>  - Merge branch 'master' into 8247666
>>  - exclude archived lambda proxy classes in the classlist
>>  - updated systemDictionaryShared.[c|h]pp based on suggestions from Ioi
>>  - fix extraneous whitespace
>>  - 8247666 (initial commit)
>
> Changes requested by iklam (Reviewer).

>  `@lambda-proxy: LambHello run ()Ljava/lang/Runnable; ()V 6 LambHello lambda$main$0 ()V ()V`

Can you explain the format?

-------------

PR: https://git.openjdk.java.net/jdk/pull/364

From asemenyuk at openjdk.java.net  Wed Oct 14 01:55:25 2020
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Wed, 14 Oct 2020 01:55:25 GMT
Subject: RFR: JDK-8252870: Finalize (remove "incubator" from) jpackage [v2]
In-Reply-To: <C1gKE74s6f3xjeBRJ_pYlbqMrLcfkbMSq1jJdvcf92w=.e74b4173-3063-4728-b003-683fa9f85035@github.com>
References: <HlksY2mFyKG_kkZA6n6JHHIWBGJT3bjmoLG28c9q1EU=.2b9faa66-08b9-4694-a5db-9d9918039642@github.com>
 <C1gKE74s6f3xjeBRJ_pYlbqMrLcfkbMSq1jJdvcf92w=.e74b4173-3063-4728-b003-683fa9f85035@github.com>
Message-ID: <IkcE1UmDfxgA2ZQpz2mbY_lk-uaKg6klIE7_Ol4e8oE=.60a5834b-a1c2-4b42-82e5-73b1460b2a39@github.com>

On Tue, 13 Oct 2020 14:48:40 GMT, Andy Herrick <herrick at openjdk.org> wrote:

>> JDK-8252870: Finalize (remove "incubator" from) jpackage
>
> Andy Herrick has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8252870: Finalize (remove "incubator" from) jpackage
>     - reverting two auto-generated files, and changing module-info to "@since 16"

Marked as reviewed by asemenyuk (Committer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/633

From github.com+51754783+coreyashford at openjdk.java.net  Wed Oct 14 02:08:18 2020
From: github.com+51754783+coreyashford at openjdk.java.net (CoreyAshford)
Date: Wed, 14 Oct 2020 02:08:18 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v4]
In-Reply-To: <vKcE4CeascBAQGeyu6is0Va0_k4aTrvgU41cjhG6Wdo=.4078814f-06ed-4978-9fcd-a4a5148c2bdc@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <45FtTQB1m6HyZSASY42STMkQffIWlVPibWn9_r00xYs=.daad2653-2571-491f-8dd7-5954fe4ece00@github.com>
 <u6HLR2PyvWgYbA58W3bCF4n38tpwQu2-ujPMvGpyyuo=.5a80f17c-83d5-4dc9-bad0-00e679fdd4be@github.com>
 <7-p-Kc9lQyyuoWdNtmgbXbwkxsgk4oQGKmFSCcMpvnU=.97810c01-3200-4767-bbd4-35d53c2bc5ca@github.com>
 <6Voyfr_s-ieyRA-8Rtvvpz7tkhhicA8sY2d2KTp3Kmw=.fa256bae-2143-4b43-bfea-5837ad31eb6a@github.com>
 <fFQfDMqdwosVGzcaJfblklUy1nPsEdZJI7ALmKq9XJs=.e869160e-76e7-4a6b-b45b-e9763d1ad06f@github.com>
 <vKcE4CeascBAQGeyu6is0Va0_k4aTrvgU41cjhG6Wdo=.4078814f-06ed-4978-9fcd-a4a5148c2bdc@github.com>
Message-ID: <wQ6YtDhYzmcgpTUP4uFfBCo8UFWZENtTARWt_LTqPug=.30bc3fdb-f963-4918-ae4b-0fe174c38a23@github.com>

On Tue, 13 Oct 2020 20:59:01 GMT, CoreyAshford <github.com+51754783+CoreyAshford at openjdk.org> wrote:

> 
> > Did you already find a 2nd reviewer for the PPC64 part?
> 
> Your original comment said "2nd review", so I thought you meant you need to review it again after the changes. So, no,
> I haven't looked for or found a second reviewer. Any suggestions? The folks on the team here have been busy with other
> work.

I am actively asking for some help here, so maybe within a few days I can get a 2nd reviewer.

-------------

PR: https://git.openjdk.java.net/jdk/pull/293

From kim.barrett at oracle.com  Wed Oct 14 04:23:50 2020
From: kim.barrett at oracle.com (Kim Barrett)
Date: Wed, 14 Oct 2020 00:23:50 -0400
Subject: RFR: 8188055: (ref) Add Reference::refersTo predicate [v2]
In-Reply-To: <pjX8i3PZNjRciV-IeQ77l8R93b2LCtBqk4QxyZTdjSw=.055de682-1a41-4680-847c-2e97dff1abb2@github.com>
References: <D4HSg8FT20Eaxk5KJkkw0GgETSxRkBn1ipS3Dt0kPto=.e4bab078-2e04-4413-90cb-9bfafb2a6831@github.com>
 <QpVGNFn7FwJVVijkSVKgUxWDLw3Y7im-mlA3yw7_crU=.1e8d22b9-29e8-4347-8790-2fe213435219@github.com>
 <fdRw8XxvrIGJI35awI_IOOg2tucC2JpjupFaVJ1lMvI=.b0b42966-48b0-4915-a9c0-b61866cb9276@github.com>
 <c1xBid7xMlFExHk4P43Hyf0SnYAJNPvW511XYzzy3QE=.e401cd8a-d34c-4f54-869c-43f7656b6bac@github.com>
 <pjX8i3PZNjRciV-IeQ77l8R93b2LCtBqk4QxyZTdjSw=.055de682-1a41-4680-847c-2e97dff1abb2@github.com>
Message-ID: <77440C7C-73E4-40B9-A617-C90EC90F19FC@oracle.com>

> On Oct 12, 2020, at 3:25 PM, Per Liden <pliden at openjdk.java.net> wrote:
> 
> On Mon, 12 Oct 2020 15:56:59 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:
> 
>>> test/hotspot/jtreg/gc/TestReferenceRefersTo.java line 186:
>>> 
>>>> 184:
>>>> 185:             expectNotValue(testWeak2, testObject3, "testWeak2");
>>>> 186:             expectValue(testWeak3, testObject3, "testWeak3");
>>> 
>>> It looks to me like the `expectNotCleared()` and `expectNotValue()` methods can be removed. All expect-tests can be
>>> done with just `expectCleared()` and `expectValue()`.
>> 
>> I don't think so.  For example,
>> `expectNotCleared(testWeak1, "testWeak1")`
>> is not testing the same thing as
>> `expectValue(testWeak1, testObject1, "testWeak1")`
>> If the implementation is correct they will indeed always be consistent. But they could be different with an incorrect
>> implementation.
> 
> Doesn't that just depend on how you implement `expectValue()`/`expectCleared()`? You could for example implement
> `expectValue()`/`expectCleared()` to be supersets of `expectNotCleared()`/`expectNotValue()`, which I think would make
> this easier to read. Something like this:
> 
> private static void expectValue(...) {
>    if (ref.refersTo(null)) {
>        fail("expected " + which + " to not be cleared");
>    }
> 
>    if (!ref.refersTo(value)) {
>        fail(which + " refers to unexpected value");
>    }
> }
> 
> private static void expectCleared(...) {
>    if (ref.refersTo(new TestObject(5))) {
>        fail(which + " refers to unexpected value");
>    }
> 
>    if (!ref.refersTo(null)) {
>        fail("expected " + which + " to be cleared");
>    }
> }

I didn't understand what you were previously proposing.  Now I think I see.

I've demoted expectNotValue to a helper for the other expectMumble
functions.  This allowed cleaning up the checking blocks, so each one makes
one call to an expectMumble for each test reference.

However, expectNotCleared can't be eliminated in favor of just using
expectValue.  In the places where expectNotCleared is used, the expected
value is unavailable; the associated testObjectN variable has been nulled.


From kbarrett at openjdk.java.net  Wed Oct 14 04:27:34 2020
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Wed, 14 Oct 2020 04:27:34 GMT
Subject: RFR: 8188055: (ref) Add Reference::refersTo predicate [v3]
In-Reply-To: <D4HSg8FT20Eaxk5KJkkw0GgETSxRkBn1ipS3Dt0kPto=.e4bab078-2e04-4413-90cb-9bfafb2a6831@github.com>
References: <D4HSg8FT20Eaxk5KJkkw0GgETSxRkBn1ipS3Dt0kPto=.e4bab078-2e04-4413-90cb-9bfafb2a6831@github.com>
Message-ID: <J-8wUT_ItffnPBtGCcJVokoBDDL5jOVG9COuoMIrVh8=.296b587b-0b4b-48ca-bc9a-dffb7eaa948a@github.com>

> Finally returning to this review that was started in April 2020.  I've
> recast it as a github PR.  I think the security concern raised by Gil
> has been adequately answered.
> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-April/029203.html
> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-July/030401.html
> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-August/030677.html
> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-September/030793.html
> 
> Please review a new function: java.lang.ref.Reference.refersTo.
> 
> This function is needed to test the referent of a Reference object without
> artificially extending the lifetime of the referent object, as may happen
> when calling Reference.get.  Some garbage collectors require extending the
> lifetime of a weak referent when accessed, in order to maintain collector
> invariants.  Lifetime extension may occur with any collector when the
> Reference is a SoftReference, as calling get indicates recent access.  This
> new function also allows testing the referent of a PhantomReference, which
> can't be accessed by calling get.
> 
> The new function uses native methods whose implementations are in the VM so
> they can use the Access API.  It is the intent that these methods will be
> intrinsified by optimizing compilers like C2 or graal, but that hasn't been
> implemented yet.  Bear that in mind before rushing off to change existing
> uses of Reference.get.
> 
> There are two native methods involved, one in Reference and an override in
> PhantomReference, both package private in java.lang.ref. The reason for this
> split is to simplify the intrinsification. This is a change from the version
> from April 2020; that version had a single native method in Reference,
> implemented using the ON_UNKNOWN_OOP_REF Access reference strength category.
> However, adding support for that category in the compilers adds significant
> implementation effort and complexity. Splitting avoids that complexity.
> 
> Testing:
> mach5 tier1
> Locally (linux-x64) verified the new test passes with various garbage collectors.

Kim Barrett has updated the pull request incrementally with three additional commits since the last revision:

 - simplify test
 - cleanup nits from Mandy
 - use Object instead of TestObject

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/498/files
  - new: https://git.openjdk.java.net/jdk/pull/498/files/28f2d1b3..efa40d71

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=498&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=498&range=01-02

  Stats: 51 lines in 2 files changed: 13 ins; 25 del; 13 mod
  Patch: https://git.openjdk.java.net/jdk/pull/498.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/498/head:pull/498

PR: https://git.openjdk.java.net/jdk/pull/498

From alanb at openjdk.java.net  Wed Oct 14 05:04:19 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 14 Oct 2020 05:04:19 GMT
Subject: RFR: 8253952: Refine ZipOutputStream.putNextEntry() to
 recalculate ZipEntry's compressed size [v6]
In-Reply-To: <_XrGXAUZwdxVWjx_vSOg2LK-YzijZ7c46-ract7Znd0=.f4f7b55e-ea86-4b5f-8322-9311b0fc3a87@github.com>
References: <0nq5oFKOj6AZqCW6jF268-6oKRI6UkS6TRIHo-_5vKw=.d13c7016-4473-4b20-9117-100b368d3716@github.com>
 <_XrGXAUZwdxVWjx_vSOg2LK-YzijZ7c46-ract7Znd0=.f4f7b55e-ea86-4b5f-8322-9311b0fc3a87@github.com>
Message-ID: <oo_Uw-Uw9vmeQGiIzhD3s911B3J1rrNJmNPDwtu9Hds=.d619d62b-79e6-4dd2-9945-85779f7f7475@github.com>

On Tue, 13 Oct 2020 19:07:33 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> ### Summary
>> 
>> Work around wrong usage of `ZipOutputStream.putNextEntry()` in user code which can lead to the `ZipException "invalid
>> entry compressed size"`.
>> ### Motivation
>> 
>> In general it is not safe to directly write a ZipEntry obtained from `ZipInputStream.getNextEntry()`,
>> `ZipFile.entries()`, `ZipFile.getEntry()` or `ZipFile.stream()` with `ZipOutputStream.putNextEntry()` to a
>> `ZipOutputStream` and then read the entries data from the `ZipInputStream` and write it to the `ZipOutputStream` as
>> follows:
>>  ZipEntry entry;
>>  ZipInputStream zis = new ZipInputStream(...);
>>  ZipOutputStream zos = new ZipOutputStream(...);
>>  while((entry = zis.getNextEntry()) != null) {
>>      zos.putNextEntry(entry);
>>      zis.transferTo(zos);
>>  }
>> The problem with this code is that the zip file format does not record the compression level used for deflation in its
>> entries. In general, it doesn't even mandate a predefined compression ratio per compression level. Therefore the
>> compressed size recorded in a `ZipEntry` read from a zip file might differ from the new compressed size produced by the
>> receiving `ZipOutputStream`. Such a difference will result in a `ZipException` with the following message:
>>  java.util.zip.ZipException: invalid entry compressed size (expected 12 but got 7 bytes)
>>  
>> The correct way of copying all entries from one zip file into another requires the creation of a new `ZipEntry` or at
>> least resetting of the compressed size field. E.g.:
>>  while((entry = zis.getNextEntry()) != null) {
>>      ZipEntry newEntry = new ZipEntry(entry.getName());
>>      zos.putNextEntry(newEntry);
>>      zis.transferTo(zos);
>>  }
>> or:
>>  while((entry = zis.getNextEntry()) != null) {
>>      entry.setCompressedSize(-1);
>>      zos.putNextEntry(entry);
>>      zis.transferTo(zos);
>>  }
>> Unfortunately, there's a lot of user code out there which gets this wrong and uses the bad coding pattern described
>> before. Searching for `"java.util.zip.ZipException: invalid entry compressed size (expected 12 but got 7 bytes)"` gives
>> ~2500 hits (~100 on StackOverflow). It's also no hard to find plenty of instances of this anti-pattern on GitHub when
>> doing a code search for `ZipEntry` and `putNextEntry()`. E.g. [Gradle 4.x wrapper task][1] is affected as well as the
>> latest version of the [mockableAndroidJar task][2]. I've recently fixed two occurrences of this pattern in OpenJDK (see
>> [JDK-8240333][3] and [JDK-8240235][4]) but there still exist more of them (e.g.
>> [`test/jdk/java/util/zip/ZipFile/CopyJar.java`][5] which is there since 1999 :).  ### Description  So while this has
>> clearly been a problem before, it apparently wasn't painful enough to trigger any action from the side of the JDK.
>> However, recently quite some zlib forks with [superior deflate/inflate performance have evolved][6]. Using them with
>> OpenJDK is quite straight-forward: one just has to configure the alternative implementations by setting
>> `LD_LIBRARY_PATH` or `LD_PRELOAD` correspondingly. We've seen big saving by using these new zlib implementations for
>> selected services in production and the only reason why we haven't enabled them by default until now is the problem
>> I've just described. The reason why these new libraries uncover the described anti-pattern much more often is because
>> their compression ratio is slightly different from that of the default zlib library. This can easily trigger a
>> `ZipException` even if an application is not using a different compression levels but just a zip file created with
>> another zlib version.  I'd therefore like to propose the following workaround for the wrong
>> `ZipOutputStream.putNextEntry()` usage in user code:
>> -  ignore the compressed size if it was implicitly determined from the zip file and not explicitly set by calling
>>    `ZipEntry.setCompressedSize()`.
>> 
>> - Change the API-documentation of `ZipOutputStream.putNextEntry()` and `JarOutputStream.putNextEntry()` to explain the
>>   problem and why `putNextEntry()` will ignore the compressed size of a `ZipEntry` if that was set implicitely when
>>   reading that entry from a `ZipFile` or `ZipInputStream`.
>> 
>> 
>> ### Technical Details
>> 
>> A zip file consists of a stream of File Entries followed by a Central Directory (see [here for a more detailed
>> specification][7]). Each File Entry is composed of a Local File Header (LFH) followed by the compressed Data and an
>> optional Data Descriptor. The LFH contains the File Name and among other attributes the Compressed and Uncompressed
>> size and CRC of the Data. In the case where the latter three attributes are not available at the time when the LFH is
>> created, this fact will be recorded in a flag of the LFH and will trigger the creation of a Data Descriptor with the
>> corresponding information right after the Data section. Finally, the Central Directory contains one Central Directory
>> File Header (CDFH) for each entry of the  zip archive. The CDFH is an extended version of the LFH and the ultimate
>> reference for the contents of the zip archive. The redundancy between LFH and CDFH is a tribute to zip's long history
>> when it was used to store archives on multiple floppy discs and the CDFH allowed to update the archive by only writing
>> to the last disc which contained the Central Directory.  `ZipEntries` read with `ZipInputStream.getNextEntry()` will
>> initially only contain the information from the LFH. Only after the next entry was read (or after
>> `ZipInputStream.closeEntry()` was called explicitly), will the previously read entry be updated with the data from the
>> Data Descriptor. `ZipInputStream` doesn't inspect the Central Directory at all.  On the other hand, `ZipFile` only
>> queries the Central Directory for `ZipEntry` information so all `ZipEntries` returned by `ZipFile.entries()`,
>> `ZipFile.getEntry()` and `ZipFile.stream()` will always instantly contain the full Compressed and Uncompressed Size and
>> CRC information for each entry independently of the LFH contents.  ### Risks and Assumptions  If we choose to ignore
>> the implicitly recorded compressed size in a `ZipEntry` read from a zip file when writing it to a `ZipOutputStream`,
>> this will lead to zip files with incomplete information in the LFH and an additional Data Descriptor as described
>> before. However, the result is still fully compatible to the zip file specification. It's also not unusual, because by
>> default all new zip files created with `ZipOutputStream` will contain LFHs without Compressed and Uncompressed Size and
>> CRC information and an additional Data Descriptor. Theoretically it is possible to create new zip files with
>> `ZipOutputStream` class and Compressed and Uncompressed Size and CRC information in the LFH but that's complex and
>> inefficient because it requires two steps. A first step to determine the crc and compressed size of the data and a
>> second step to actually write the data to the `ZipOutputStream` (which will compress it a second time). This is because
>> the current API offers no possibility to write already compressed data to a `ZipOutputStream`.  Consequently, the only
>> straight-forward way of creating zip files from Java which have all the data in the LFH and no Data Descriptor is by
>> copying `ZipEntries` from an existing zip file with the buggy method described before. This incidentally worked more or
>> less reliable for a long time but breaks miserably when using different zlib implementations. Ignoring the implicitly
>> set compressed size of `ZipEntries` can easily fix this problem.  I'm not aware of any tool which can not handle such
>> files and if it exists it would have problems with the majority of Java created zip files anyway (e.g. all jar-files
>> created with the jar tool have zip entries with incomplete LFH data and additional Data Descriptor).  Ignoring the
>> implicitly set compressed size of `ZipEntries` has no measurable performance impact and will increase the size of zip
>> archives which used to have the complete file information in the LFH before by 16 bytes per entry. On the other hand it
>> will give us the freedom to use whatever zip implementation we like :)   [1]:
>> https://github.com/gradle/gradle/blob/e76905e3a/subprojects/build-init/src/main/java/org/gradle/api/tasks/wrapper/Wrapper.java#L152-L158
>> [2]:
>> https://android.googlesource.com/platform/tools/base/+/refs/heads/master/build-system/builder/src/main/java/com/android/builder/testing/MockableJarGenerator.java#86
>> [3]: https://bugs.openjdk.java.net/browse/JDK-8240333 [4]: https://bugs.openjdk.java.net/browse/JDK-8240235 [5]:
>> https://github.com/openjdk/jdk/blob/master/test/jdk/java/util/zip/ZipFile/CopyJar.java [6]:
>> https://github.com/simonis/zlib-bench/blob/master/Results.md [7]: https://en.wikipedia.org/wiki/Zip_(file_format)
>
> Volker Simonis 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 alanb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/520

From dfuchs at openjdk.java.net  Wed Oct 14 10:07:16 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 14 Oct 2020 10:07:16 GMT
Subject: RFR: 8251989: Hex formatting and parsing utility [v2]
In-Reply-To: <Op6a9I7ariq5HWMwVGp_58VyMpElYx41ACVJXc3UdXc=.2faa2c38-503f-4236-9d5c-7afb3ba3f0ef@github.com>
References: <HSEn47GMS1K3g57mrTZeQk-WZHl3pKGHpX_OOf8VnsU=.740863c2-f9e4-43c4-b500-614aab4078b1@github.com>
 <Op6a9I7ariq5HWMwVGp_58VyMpElYx41ACVJXc3UdXc=.2faa2c38-503f-4236-9d5c-7afb3ba3f0ef@github.com>
Message-ID: <5LxXhzMVml7gGn-iEP18oCQIhkp-KRy6JG5QULIesQI=.3e06b5f4-bcf7-4040-a112-1895f3eb6e86@github.com>

On Tue, 13 Oct 2020 19:51:30 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> java.util.HexFormat utility:
>> 
>>  - Format and parse hexadecimal strings, with parameters for delimiter, prefix, suffix and upper/lowercase
>>  - Static factories and builder methods to create HexFormat copies with modified parameters.
>>  - Consistent naming of methods for conversion of byte arrays to formatted strings and back: formatHex and parseHex
>>  - Consistent naming of methods for conversion of primitive types: toHexDigits... and fromHexDigits...
>>  - Prefix and suffixes now apply to each formatted value, not the string as a whole
>>  - Using java.util.Appendable as a target for buffered conversions so output to Writers and PrintStreams
>>    like System.out are supported in addition to StringBuilder. (IOExceptions are converted to unchecked exceptions)
>>  - Immutable and thread safe, a "value-based" class
>> 
>> See the [HexFormat
>> javadoc](http://cr.openjdk.java.net/~rriggs/8251989-hex-formatter/java.base/java/util/HexFormat.html) for details.
>> Review comments and suggestions welcome.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Various code review comments, rename UpperCase and LowerCase methods to match Character, remove unnecessary Class name
>   qualifications, etc.

src/java.net.http/share/classes/jdk/internal/net/http/common/Utils.java line 1116:

> 1114:         }
> 1115:
> 1116:         HexFormat format = HexFormat.of().withUpperCase();

Should/can this be a static final field in the class?

src/java.base/share/classes/java/util/HexFormat.java line 41:

> 39:  * formatting markup such as prefixes, suffixes, and delimiters.
> 40:  * <p>
> 41:  * There are two {@code HexFormat}ters with preset parameters {@link #of()} and

Just a nit comment: stylistically, mixing fixed fonts and variable length fonts in a single word does not always
display well. Alternative include using plain words, and use {@linkplain } to link to the class/method described (e.g.
`{@linkplain HexFormat hexadecimal formatters}`), or reword (e.g. `There are two factories returning instances of
{@code HexFormat} with ...`)...

src/java.base/share/classes/java/util/HexFormat.java line 538:

> 536:      * A {@code delimiter} appears after each formatted value, except the last.
> 537:      * The {@code delimiter}s, {@code prefix}es, and {@code suffix}es strings must be present;
> 538:      * they may be empty strings.

I'd rather use @linkplain than @code here, or just plain words with no formatting, to avoid mixing different types of
fonts in a single word.

-------------

PR: https://git.openjdk.java.net/jdk/pull/482

From mdoerr at openjdk.java.net  Wed Oct 14 10:33:11 2020
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Wed, 14 Oct 2020 10:33:11 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v4]
In-Reply-To: <wQ6YtDhYzmcgpTUP4uFfBCo8UFWZENtTARWt_LTqPug=.30bc3fdb-f963-4918-ae4b-0fe174c38a23@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <45FtTQB1m6HyZSASY42STMkQffIWlVPibWn9_r00xYs=.daad2653-2571-491f-8dd7-5954fe4ece00@github.com>
 <u6HLR2PyvWgYbA58W3bCF4n38tpwQu2-ujPMvGpyyuo=.5a80f17c-83d5-4dc9-bad0-00e679fdd4be@github.com>
 <7-p-Kc9lQyyuoWdNtmgbXbwkxsgk4oQGKmFSCcMpvnU=.97810c01-3200-4767-bbd4-35d53c2bc5ca@github.com>
 <6Voyfr_s-ieyRA-8Rtvvpz7tkhhicA8sY2d2KTp3Kmw=.fa256bae-2143-4b43-bfea-5837ad31eb6a@github.com>
 <fFQfDMqdwosVGzcaJfblklUy1nPsEdZJI7ALmKq9XJs=.e869160e-76e7-4a6b-b45b-e9763d1ad06f@github.com>
 <vKcE4CeascBAQGeyu6is0Va0_k4aTrvgU41cjhG6Wdo=.4078814f-06ed-4978-9fcd-a4a5148c2bdc@github.com>
 <wQ6YtDhYzmcgpTUP4uFfBCo8UFWZENtTARWt_LTqPug=.30bc3fdb-f963-4918-ae4b-0fe174c38a23@github.com>
Message-ID: <jqzI94j7kygJyD9HWwq5d3q3LGztS5FAdYm5Ix1QdjE=.808de4e6-0f6d-4e17-b807-25ef89e92541@github.com>

On Wed, 14 Oct 2020 02:04:42 GMT, CoreyAshford <github.com+51754783+CoreyAshford at openjdk.org> wrote:

>>> Hi Corey, thanks for taking some stuff out of the ?too short? path. There may be a performance regression when decoding
>>> many short arrays because of the stub call overhead and the usage of the slower part of the Java implementation. We
>>> could do it a little better in many cases to compute the maximum possible iteration count i: i = (sl - sp) / block_size
>>> if (i * block_size > sl - 12) i-- if (i <= 0) return 0 What do you think?
>> 
>> Are you thinking of a case where that produces a higher iteration count?  It looks effectively the same to me.
>> 
>>> I don?t think branch prediction hints are helpful for the ?too short? check.
>> 
>> My thinking is that most of the time when the intrinsic is called, it will not take the early exit, but I suppose when
>> it is processing a sub-block_size buffer, it will return early every time.  I will remove the hints.
>>> And we should better use CCR1 instead of CCR2 which is specified as non-volatile.
>> 
>> Ah, I should have checked the calling conventions.  I thought all of the CR* regs are volatile.  I will fix that.
>> 
>>>  Did you already find a 2nd reviewer for the PPC64 part?
>> 
>> Your original comment said "2nd review", so I thought you meant you need to review it again after the changes.  So, no,
>> I haven't looked for or found a second reviewer.  Any suggestions?  The folks on the team here have been busy with
>> other work.  Btw, I'm off today, so I will push commits to the above-mentioned issues tomorrow.
>
>> 
>> > Did you already find a 2nd reviewer for the PPC64 part?
>> 
>> Your original comment said "2nd review", so I thought you meant you need to review it again after the changes. So, no,
>> I haven't looked for or found a second reviewer. Any suggestions? The folks on the team here have been busy with other
>> work.
> 
> I am actively asking for some help here, so maybe within a few days I can get a 2nd reviewer.

Hi Corey,

> Are you thinking of a case where that produces a higher iteration count?
Sorry for the confusion. This is also fine:
length = sl - sp - 12
i = length / block_size
if (i <= 0) return 0

But I still wonder why we should use 2 branches. Why not
srawi_
ble(CCR0, return_zero)
?

> Ah, I should have checked the calling conventions. I thought all of the CR* regs are volatile. I will fix that.
Actually, we do save and restore all CRs, so it?s not a real problem with the current implementation. But I prefer
staying closer to the elf ABI as long as there?s no good reason to do it differently.

> Your original comment said "2nd review", so I thought you meant you need to review it again after the changes.
We usually require at least 2 reviews by different people for all non-trivial changes. And I don?t consider the PPC64
part as trivial. In addition to that, I?m not familiar with Power 10.

Best regards,
Martin


From: CoreyAshford <notifications at github.com>
Sent: Dienstag, 13. Oktober 2020 22:59
To: openjdk/jdk <jdk at noreply.github.com>
Cc: Doerr, Martin <martin.doerr at sap.com>; Mention <mention at noreply.github.com>
Subject: Re: [openjdk/jdk] 8248188: Add IntrinsicCandidate and API for Base64 decoding (#293)


Hi Corey, thanks for taking some stuff out of the ?too short? path. There may be a performance regression when decoding
many short arrays because of the stub call overhead and the usage of the slower part of the Java implementation. We
could do it a little better in many cases to compute the maximum possible iteration count i: i = (sl - sp) / block_size
if (i * block_size > sl - 12) i-- if (i <= 0) return 0 What do you think?

Are you thinking of a case where that produces a higher iteration count? It looks effectively the same to me.

I don?t think branch prediction hints are helpful for the ?too short? check.

My thinking is that most of the time when the intrinsic is called, it will not take the early exit, but I suppose when
it is processing a sub-block_size buffer, it will return early every time. I will remove the hints.

And we should better use CCR1 instead of CCR2 which is specified as non-volatile.

Ah, I should have checked the calling conventions. I thought all of the CR* regs are volatile. I will fix that.

Did you already find a 2nd reviewer for the PPC64 part?

Your original comment said "2nd review", so I thought you meant you need to review it again after the changes. So, no,
I haven't looked for or found a second reviewer. Any suggestions? The folks on the team here have been busy with other
work.

Btw, I'm off today, so I will push commits to the above-mentioned issues tomorrow.

?
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<https://github.com/openjdk/jdk/pull/293#issuecomment-708005545>, or
unsubscribe<https://github.com/notifications/unsubscribe-auth/AKR64KC2K7IZFAPXVQIVYZDSKS5SLANCNFSM4RVHNW5Q>.

-------------

PR: https://git.openjdk.java.net/jdk/pull/293

From pliden at openjdk.java.net  Wed Oct 14 10:47:13 2020
From: pliden at openjdk.java.net (Per Liden)
Date: Wed, 14 Oct 2020 10:47:13 GMT
Subject: RFR: 8188055: (ref) Add Reference::refersTo predicate [v3]
In-Reply-To: <Tb1VL1yPx2XEmwhHdZwz_NE8DiUcsAzQba9wmmDjEus=.f03ebf90-92c4-44c9-a1c4-21e16d17d262@github.com>
References: <D4HSg8FT20Eaxk5KJkkw0GgETSxRkBn1ipS3Dt0kPto=.e4bab078-2e04-4413-90cb-9bfafb2a6831@github.com>
 <Y1IHoNr8vO3OkCbEKw6ywXd4adik1yKKNIS4ABzF0d0=.d21f4183-ef4e-45ed-826d-6613215b6220@github.com>
 <Tb1VL1yPx2XEmwhHdZwz_NE8DiUcsAzQba9wmmDjEus=.f03ebf90-92c4-44c9-a1c4-21e16d17d262@github.com>
Message-ID: <8-JeTNjr53Ii4Nrwd7A6bQq8fIZEG0nIGrlD27cOGyI=.03673b47-c927-4b43-9695-17765ecc3baf@github.com>

On Thu, 8 Oct 2020 14:00:11 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Can you add a unit test in `test/jdk/java/lang/ref` that serves as a basic API test for this new `refersTo` API without
>> depending the WhiteBox API?     test/hotspot/jtreg/gc` test serves as a more white-boxed type and comprehensive test.
>
> Hi Kim,
> 
> At what point would the @IntrinsicCandidate annotation be added to the
> refersTo0 methods?
> it would be useful documentation even if it is not needed for the mechanism.
> 
> Thanks for the explanation, Roger
> 
> 
> On 10/8/20 3:58 AM, mlbridge[bot] wrote:
>>
>> /Mailing list message from Kim Barrett <mailto:kim.barrett at oracle.com>
>> on hotspot-gc-dev <mailto:hotspot-gc-dev at openjdk.java.net>:/
>>
>>     On Oct 5, 2020, at 9:15 PM, Roger Riggs <rriggs at
>>     openjdk.java.net> wrote:
>>     src/java.base/share/classes/java/lang/ref/PhantomReference.java
>>     line 66:
>>
>>         64: @override
>>         <https://urldefense.com/v3/__https://github.com/override__;!!GqivPVa7Brio!MXZs7XLDGF7idnDuZ1hTIGY4LTzS5Lx_xCAlYuwDG6C1Vno9_RgMleOn8nJgqULa$>
>>         65: native final boolean refersTo0(Object o);
>>         66:
>>
>>     How does the existence of this method help future intrinsification?
>>     If it was called somewhere it would be clearer.
>>     Perhaps a comment now or later would help explain its function.
>>
>> public final refersTo(T o) calls refersTo0(o)
>>
>> We have package private:
>> native boolean Reference::refersTo0(Object)
>> final native boolean PhantomReference::refersTo0(Object)
>>
>> The reason for this split has to do with details in the VM support, in
>> particular C2 intrinsification.
>>
>> For the native method support we don't need this split. The original
>> version from back in April just had a single native method in
>> Reference. (It
>> did have native refersTo0, but that was my not realizing native methods
>> could have a parameterized type that would get type-erased automatically;
>> see response to Mandy.) That native method performed a runtime check
>> on the
>> ReferenceType of the reference's klass to determine what to do. (See
>> below.)
>>
>> Phantom references need to be treated differently from stronger "weak"
>> reference types, because phantom references are weaker than
>> finalization, so
>> might not be cleared when a stronger reference to the same object is
>> cleared. For collectors with STW reference processing this doesn't make
>> much difference (the referent is either cleared or not), but making this
>> distinction correctly is necessary for concurrent reference processing.
>>
>> The Access API that provides the interface to the GC has support for
>> "unknown" referent accesses that perform a runtime lookup. This is
>> supported in C++ code, but not in the various Java code processors
>> (interpreter and compilers). We didn't previously need to support that
>> case
>> for Java because the only place where it mattered was accessing the
>> referent
>> of a PhantomReference, and that is blocked by PhantomReference::get that
>> always returns null.
>>
>> For refersTo the intent is to have the interpreter and C1 use the native
>> method, but have C2 have special knowledge for it. We could add
>> support for
>> the "unknown" reference type to C2, but that's a substantial amount of
>> work,
>> and only useful for this one place. Or we can take the same approach
>> as for
>> get(), i.e. have a second method on PhantomReference so that calls
>> that can
>> select the appropriate method at compile time (usually the case) can have
>> distinct intrinsics for the two cases.
>>
>> By having these intrinsifiable native methods be package private we
>> can have
>> the public refersTo API function be final, while also preventing any
>> further
>> overrides by classes not in the same package.
>>
>> I'll try to come up with some commentary.
>>
>> ?
>> You are receiving this because you commented.
>> Reply to this email directly, view it on GitHub
>> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/498*issuecomment-705400053__;Iw!!GqivPVa7Brio!MXZs7XLDGF7idnDuZ1hTIGY4LTzS5Lx_xCAlYuwDG6C1Vno9_RgMleOn8m3Tmikx$>,
>> or unsubscribe
>> <https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/AAIRSVBIN2XWNEM3ILBOLI3SJVWI3ANCNFSM4SDN74VA__;!!GqivPVa7Brio!MXZs7XLDGF7idnDuZ1hTIGY4LTzS5Lx_xCAlYuwDG6C1Vno9_RgMleOn8skFFiqO$>.
>>

> In the places where expectNotCleared is used, the expected value is unavailable; the associated testObjectN variable
> has been nulled.

Ah, true.

-------------

PR: https://git.openjdk.java.net/jdk/pull/498

From pliden at openjdk.java.net  Wed Oct 14 10:47:13 2020
From: pliden at openjdk.java.net (Per Liden)
Date: Wed, 14 Oct 2020 10:47:13 GMT
Subject: RFR: 8188055: (ref) Add Reference::refersTo predicate [v3]
In-Reply-To: <J-8wUT_ItffnPBtGCcJVokoBDDL5jOVG9COuoMIrVh8=.296b587b-0b4b-48ca-bc9a-dffb7eaa948a@github.com>
References: <D4HSg8FT20Eaxk5KJkkw0GgETSxRkBn1ipS3Dt0kPto=.e4bab078-2e04-4413-90cb-9bfafb2a6831@github.com>
 <J-8wUT_ItffnPBtGCcJVokoBDDL5jOVG9COuoMIrVh8=.296b587b-0b4b-48ca-bc9a-dffb7eaa948a@github.com>
Message-ID: <xqswVYbZvVyLW7azD6aInRuupfzLUn4u7LhtM1h3Uqk=.8cd26f87-e32b-47b9-811c-57fb06d6d41c@github.com>

On Wed, 14 Oct 2020 04:27:34 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Finally returning to this review that was started in April 2020.  I've
>> recast it as a github PR.  I think the security concern raised by Gil
>> has been adequately answered.
>> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-April/029203.html
>> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-July/030401.html
>> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-August/030677.html
>> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-September/030793.html
>> 
>> Please review a new function: java.lang.ref.Reference.refersTo.
>> 
>> This function is needed to test the referent of a Reference object without
>> artificially extending the lifetime of the referent object, as may happen
>> when calling Reference.get.  Some garbage collectors require extending the
>> lifetime of a weak referent when accessed, in order to maintain collector
>> invariants.  Lifetime extension may occur with any collector when the
>> Reference is a SoftReference, as calling get indicates recent access.  This
>> new function also allows testing the referent of a PhantomReference, which
>> can't be accessed by calling get.
>> 
>> The new function uses native methods whose implementations are in the VM so
>> they can use the Access API.  It is the intent that these methods will be
>> intrinsified by optimizing compilers like C2 or graal, but that hasn't been
>> implemented yet.  Bear that in mind before rushing off to change existing
>> uses of Reference.get.
>> 
>> There are two native methods involved, one in Reference and an override in
>> PhantomReference, both package private in java.lang.ref. The reason for this
>> split is to simplify the intrinsification. This is a change from the version
>> from April 2020; that version had a single native method in Reference,
>> implemented using the ON_UNKNOWN_OOP_REF Access reference strength category.
>> However, adding support for that category in the compilers adds significant
>> implementation effort and complexity. Splitting avoids that complexity.
>> 
>> Testing:
>> mach5 tier1
>> Locally (linux-x64) verified the new test passes with various garbage collectors.
>
> Kim Barrett has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - simplify test
>  - cleanup nits from Mandy
>  - use Object instead of TestObject

Marked as reviewed by pliden (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/498

From simonis at openjdk.java.net  Wed Oct 14 10:54:30 2020
From: simonis at openjdk.java.net (Volker Simonis)
Date: Wed, 14 Oct 2020 10:54:30 GMT
Subject: RFR: 8253952: Refine ZipOutputStream.putNextEntry() to
 recalculate ZipEntry's compressed size [v7]
In-Reply-To: <0nq5oFKOj6AZqCW6jF268-6oKRI6UkS6TRIHo-_5vKw=.d13c7016-4473-4b20-9117-100b368d3716@github.com>
References: <0nq5oFKOj6AZqCW6jF268-6oKRI6UkS6TRIHo-_5vKw=.d13c7016-4473-4b20-9117-100b368d3716@github.com>
Message-ID: <8NaRPfinIcIKT6GlY1mqQxGj43ZwwRYp6LYns504BeU=.c52e1ecc-5442-41e3-9e88-1b0be10bdf11@github.com>

> ### Summary
> 
> Work around wrong usage of `ZipOutputStream.putNextEntry()` in user code which can lead to the `ZipException "invalid
> entry compressed size"`.
> ### Motivation
> 
> In general it is not safe to directly write a ZipEntry obtained from `ZipInputStream.getNextEntry()`,
> `ZipFile.entries()`, `ZipFile.getEntry()` or `ZipFile.stream()` with `ZipOutputStream.putNextEntry()` to a
> `ZipOutputStream` and then read the entries data from the `ZipInputStream` and write it to the `ZipOutputStream` as
> follows:
>  ZipEntry entry;
>  ZipInputStream zis = new ZipInputStream(...);
>  ZipOutputStream zos = new ZipOutputStream(...);
>  while((entry = zis.getNextEntry()) != null) {
>      zos.putNextEntry(entry);
>      zis.transferTo(zos);
>  }
> The problem with this code is that the zip file format does not record the compression level used for deflation in its
> entries. In general, it doesn't even mandate a predefined compression ratio per compression level. Therefore the
> compressed size recorded in a `ZipEntry` read from a zip file might differ from the new compressed size produced by the
> receiving `ZipOutputStream`. Such a difference will result in a `ZipException` with the following message:
>  java.util.zip.ZipException: invalid entry compressed size (expected 12 but got 7 bytes)
>  
> The correct way of copying all entries from one zip file into another requires the creation of a new `ZipEntry` or at
> least resetting of the compressed size field. E.g.:
>  while((entry = zis.getNextEntry()) != null) {
>      ZipEntry newEntry = new ZipEntry(entry.getName());
>      zos.putNextEntry(newEntry);
>      zis.transferTo(zos);
>  }
> or:
>  while((entry = zis.getNextEntry()) != null) {
>      entry.setCompressedSize(-1);
>      zos.putNextEntry(entry);
>      zis.transferTo(zos);
>  }
> Unfortunately, there's a lot of user code out there which gets this wrong and uses the bad coding pattern described
> before. Searching for `"java.util.zip.ZipException: invalid entry compressed size (expected 12 but got 7 bytes)"` gives
> ~2500 hits (~100 on StackOverflow). It's also no hard to find plenty of instances of this anti-pattern on GitHub when
> doing a code search for `ZipEntry` and `putNextEntry()`. E.g. [Gradle 4.x wrapper task][1] is affected as well as the
> latest version of the [mockableAndroidJar task][2]. I've recently fixed two occurrences of this pattern in OpenJDK (see
> [JDK-8240333][3] and [JDK-8240235][4]) but there still exist more of them (e.g.
> [`test/jdk/java/util/zip/ZipFile/CopyJar.java`][5] which is there since 1999 :).  ### Description  So while this has
> clearly been a problem before, it apparently wasn't painful enough to trigger any action from the side of the JDK.
> However, recently quite some zlib forks with [superior deflate/inflate performance have evolved][6]. Using them with
> OpenJDK is quite straight-forward: one just has to configure the alternative implementations by setting
> `LD_LIBRARY_PATH` or `LD_PRELOAD` correspondingly. We've seen big saving by using these new zlib implementations for
> selected services in production and the only reason why we haven't enabled them by default until now is the problem
> I've just described. The reason why these new libraries uncover the described anti-pattern much more often is because
> their compression ratio is slightly different from that of the default zlib library. This can easily trigger a
> `ZipException` even if an application is not using a different compression levels but just a zip file created with
> another zlib version.  I'd therefore like to propose the following workaround for the wrong
> `ZipOutputStream.putNextEntry()` usage in user code:
> -  ignore the compressed size if it was implicitly determined from the zip file and not explicitly set by calling
>    `ZipEntry.setCompressedSize()`.
> 
> - Change the API-documentation of `ZipOutputStream.putNextEntry()` and `JarOutputStream.putNextEntry()` to explain the
>   problem and why `putNextEntry()` will ignore the compressed size of a `ZipEntry` if that was set implicitely when
>   reading that entry from a `ZipFile` or `ZipInputStream`.
> 
> 
> ### Technical Details
> 
> A zip file consists of a stream of File Entries followed by a Central Directory (see [here for a more detailed
> specification][7]). Each File Entry is composed of a Local File Header (LFH) followed by the compressed Data and an
> optional Data Descriptor. The LFH contains the File Name and among other attributes the Compressed and Uncompressed
> size and CRC of the Data. In the case where the latter three attributes are not available at the time when the LFH is
> created, this fact will be recorded in a flag of the LFH and will trigger the creation of a Data Descriptor with the
> corresponding information right after the Data section. Finally, the Central Directory contains one Central Directory
> File Header (CDFH) for each entry of the  zip archive. The CDFH is an extended version of the LFH and the ultimate
> reference for the contents of the zip archive. The redundancy between LFH and CDFH is a tribute to zip's long history
> when it was used to store archives on multiple floppy discs and the CDFH allowed to update the archive by only writing
> to the last disc which contained the Central Directory.  `ZipEntries` read with `ZipInputStream.getNextEntry()` will
> initially only contain the information from the LFH. Only after the next entry was read (or after
> `ZipInputStream.closeEntry()` was called explicitly), will the previously read entry be updated with the data from the
> Data Descriptor. `ZipInputStream` doesn't inspect the Central Directory at all.  On the other hand, `ZipFile` only
> queries the Central Directory for `ZipEntry` information so all `ZipEntries` returned by `ZipFile.entries()`,
> `ZipFile.getEntry()` and `ZipFile.stream()` will always instantly contain the full Compressed and Uncompressed Size and
> CRC information for each entry independently of the LFH contents.  ### Risks and Assumptions  If we choose to ignore
> the implicitly recorded compressed size in a `ZipEntry` read from a zip file when writing it to a `ZipOutputStream`,
> this will lead to zip files with incomplete information in the LFH and an additional Data Descriptor as described
> before. However, the result is still fully compatible to the zip file specification. It's also not unusual, because by
> default all new zip files created with `ZipOutputStream` will contain LFHs without Compressed and Uncompressed Size and
> CRC information and an additional Data Descriptor. Theoretically it is possible to create new zip files with
> `ZipOutputStream` class and Compressed and Uncompressed Size and CRC information in the LFH but that's complex and
> inefficient because it requires two steps. A first step to determine the crc and compressed size of the data and a
> second step to actually write the data to the `ZipOutputStream` (which will compress it a second time). This is because
> the current API offers no possibility to write already compressed data to a `ZipOutputStream`.  Consequently, the only
> straight-forward way of creating zip files from Java which have all the data in the LFH and no Data Descriptor is by
> copying `ZipEntries` from an existing zip file with the buggy method described before. This incidentally worked more or
> less reliable for a long time but breaks miserably when using different zlib implementations. Ignoring the implicitly
> set compressed size of `ZipEntries` can easily fix this problem.  I'm not aware of any tool which can not handle such
> files and if it exists it would have problems with the majority of Java created zip files anyway (e.g. all jar-files
> created with the jar tool have zip entries with incomplete LFH data and additional Data Descriptor).  Ignoring the
> implicitly set compressed size of `ZipEntries` has no measurable performance impact and will increase the size of zip
> archives which used to have the complete file information in the LFH before by 16 bytes per entry. On the other hand it
> will give us the freedom to use whatever zip implementation we like :)   [1]:
> https://github.com/gradle/gradle/blob/e76905e3a/subprojects/build-init/src/main/java/org/gradle/api/tasks/wrapper/Wrapper.java#L152-L158
> [2]:
> https://android.googlesource.com/platform/tools/base/+/refs/heads/master/build-system/builder/src/main/java/com/android/builder/testing/MockableJarGenerator.java#86
> [3]: https://bugs.openjdk.java.net/browse/JDK-8240333 [4]: https://bugs.openjdk.java.net/browse/JDK-8240235 [5]:
> https://github.com/openjdk/jdk/blob/master/test/jdk/java/util/zip/ZipFile/CopyJar.java [6]:
> https://github.com/simonis/zlib-bench/blob/master/Results.md [7]: https://en.wikipedia.org/wiki/Zip_(file_format)

Volker Simonis 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:

  8253952: Refine ZipOutputStream.putNextEntry() to recalculate ZipEntry's compressed size

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/520/files
  - new: https://git.openjdk.java.net/jdk/pull/520/files/7f032e0f..6b570c66

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=520&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=520&range=05-06

  Stats: 13 lines in 1 file changed: 2 ins; 2 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/520.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/520/head:pull/520

PR: https://git.openjdk.java.net/jdk/pull/520

From simonis at openjdk.java.net  Wed Oct 14 10:54:32 2020
From: simonis at openjdk.java.net (Volker Simonis)
Date: Wed, 14 Oct 2020 10:54:32 GMT
Subject: RFR: 8253952: Refine ZipOutputStream.putNextEntry() to
 recalculate ZipEntry's compressed size [v6]
In-Reply-To: <75L2BpBchAkkPMo8-DtsWC48mN8N9wcdXfLH-e854L4=.bd404a73-6045-4fff-8143-5097041411b3@github.com>
References: <0nq5oFKOj6AZqCW6jF268-6oKRI6UkS6TRIHo-_5vKw=.d13c7016-4473-4b20-9117-100b368d3716@github.com>
 <_XrGXAUZwdxVWjx_vSOg2LK-YzijZ7c46-ract7Znd0=.f4f7b55e-ea86-4b5f-8322-9311b0fc3a87@github.com>
 <75L2BpBchAkkPMo8-DtsWC48mN8N9wcdXfLH-e854L4=.bd404a73-6045-4fff-8143-5097041411b3@github.com>
Message-ID: <O2o8J_yrONtL79Cv1dywe4-nBKbCeEe7HQF4hRz68hk=.0f423c06-9c1f-48c1-ae04-fbcc08d932ea@github.com>

On Tue, 13 Oct 2020 19:56:50 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Volker Simonis has refreshed the contents of this pull request, and previous commits have been removed. The incremental
>> views will show differences compared to the previous content of the PR.
>
> test/jdk/java/util/zip/CopyZipFile.java line 104:
> 
>> 102:         // all these fields set to '-1'.
>> 103:         InputStream is = new FileInputStream(ZIP_FILE);
>> 104:         ZipInputStream zis = new ZipInputStream(is);
> 
> Any reason not to include the the ZipInputStream and InputStream in the try with Resources and the ZipFile below?  I
> know these are nits, but just curious or was it an over site?
> I think we are good otherwise

No other reason except my laziness :)

> test/jdk/java/util/zip/CopyZipFile.java line 140:
> 
>> 138:         // This means that all ZipEntry objects returned from ZipFile will have correct
>> 139:         // settings for these fields.
>> 140:         // I the compression level was different in the initial zip file (which we can't find
> 
> typo I -> If

Fixed

> test/jdk/java/util/zip/CopyZipFile.java line 188:
> 
>> 186:                     if ("test1.txt".equals(entry.getName()) || "test2.txt".equals(entry.getName())) {
>> 187:                         throw new Exception(
>> 188:                             "Should throw for STORED files or files compressed with DEFAULT_COMPRESSION");
> 
> Perhaps clean up the message above "Should throw" to indicate what is being thrown

Thanks. That should actually red "Shouldn't...". Fixed that and also added ZipExcpetion as exception which shouldn't be
thrown.

-------------

PR: https://git.openjdk.java.net/jdk/pull/520

From simonis at openjdk.java.net  Wed Oct 14 10:54:32 2020
From: simonis at openjdk.java.net (Volker Simonis)
Date: Wed, 14 Oct 2020 10:54:32 GMT
Subject: RFR: 8253952: Refine ZipOutputStream.putNextEntry() to
 recalculate ZipEntry's compressed size [v6]
In-Reply-To: <O2o8J_yrONtL79Cv1dywe4-nBKbCeEe7HQF4hRz68hk=.0f423c06-9c1f-48c1-ae04-fbcc08d932ea@github.com>
References: <0nq5oFKOj6AZqCW6jF268-6oKRI6UkS6TRIHo-_5vKw=.d13c7016-4473-4b20-9117-100b368d3716@github.com>
 <_XrGXAUZwdxVWjx_vSOg2LK-YzijZ7c46-ract7Znd0=.f4f7b55e-ea86-4b5f-8322-9311b0fc3a87@github.com>
 <75L2BpBchAkkPMo8-DtsWC48mN8N9wcdXfLH-e854L4=.bd404a73-6045-4fff-8143-5097041411b3@github.com>
 <O2o8J_yrONtL79Cv1dywe4-nBKbCeEe7HQF4hRz68hk=.0f423c06-9c1f-48c1-ae04-fbcc08d932ea@github.com>
Message-ID: <5TcjFbuMieF40GRe46m9IY6YNSm8OwVWpVW7lIWJe7s=.3446c3e4-a520-41f1-b86c-9fe2dd55503b@github.com>

On Wed, 14 Oct 2020 10:48:55 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> test/jdk/java/util/zip/CopyZipFile.java line 104:
>> 
>>> 102:         // all these fields set to '-1'.
>>> 103:         InputStream is = new FileInputStream(ZIP_FILE);
>>> 104:         ZipInputStream zis = new ZipInputStream(is);
>> 
>> Any reason not to include the the ZipInputStream and InputStream in the try with Resources and the ZipFile below?  I
>> know these are nits, but just curious or was it an over site?
>> I think we are good otherwise
>
> No other reason except my laziness :)

fixed now

-------------

PR: https://git.openjdk.java.net/jdk/pull/520

From ayang at openjdk.java.net  Wed Oct 14 11:21:18 2020
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Wed, 14 Oct 2020 11:21:18 GMT
Subject: RFR: 8188055: (ref) Add Reference::refersTo predicate [v3]
In-Reply-To: <J-8wUT_ItffnPBtGCcJVokoBDDL5jOVG9COuoMIrVh8=.296b587b-0b4b-48ca-bc9a-dffb7eaa948a@github.com>
References: <D4HSg8FT20Eaxk5KJkkw0GgETSxRkBn1ipS3Dt0kPto=.e4bab078-2e04-4413-90cb-9bfafb2a6831@github.com>
 <J-8wUT_ItffnPBtGCcJVokoBDDL5jOVG9COuoMIrVh8=.296b587b-0b4b-48ca-bc9a-dffb7eaa948a@github.com>
Message-ID: <5XemoS4nTtROBzX7sighX_dQrC4ZXzXNKfs3LM5BUR8=.c88f673a-650f-483e-bb7e-d197e53742d4@github.com>

On Wed, 14 Oct 2020 04:27:34 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Finally returning to this review that was started in April 2020.  I've
>> recast it as a github PR.  I think the security concern raised by Gil
>> has been adequately answered.
>> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-April/029203.html
>> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-July/030401.html
>> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-August/030677.html
>> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-September/030793.html
>> 
>> Please review a new function: java.lang.ref.Reference.refersTo.
>> 
>> This function is needed to test the referent of a Reference object without
>> artificially extending the lifetime of the referent object, as may happen
>> when calling Reference.get.  Some garbage collectors require extending the
>> lifetime of a weak referent when accessed, in order to maintain collector
>> invariants.  Lifetime extension may occur with any collector when the
>> Reference is a SoftReference, as calling get indicates recent access.  This
>> new function also allows testing the referent of a PhantomReference, which
>> can't be accessed by calling get.
>> 
>> The new function uses native methods whose implementations are in the VM so
>> they can use the Access API.  It is the intent that these methods will be
>> intrinsified by optimizing compilers like C2 or graal, but that hasn't been
>> implemented yet.  Bear that in mind before rushing off to change existing
>> uses of Reference.get.
>> 
>> There are two native methods involved, one in Reference and an override in
>> PhantomReference, both package private in java.lang.ref. The reason for this
>> split is to simplify the intrinsification. This is a change from the version
>> from April 2020; that version had a single native method in Reference,
>> implemented using the ON_UNKNOWN_OOP_REF Access reference strength category.
>> However, adding support for that category in the compilers adds significant
>> implementation effort and complexity. Splitting avoids that complexity.
>> 
>> Testing:
>> mach5 tier1
>> Locally (linux-x64) verified the new test passes with various garbage collectors.
>
> Kim Barrett has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - simplify test
>  - cleanup nits from Mandy
>  - use Object instead of TestObject

src/java.base/share/classes/java/lang/ref/Reference.java line 362:

> 360:     /* Implementation of refersTo() for non-phantom references.
> 361:      */
> 362:     native boolean refersTo0(Object o);

1. Why is it named `refersTo0`? How about sth more descriptive, e.g.`refersToNative`?
2. Nit: including some text that this method is overridden in `PhantomReference.java` in the comments will be more
informative and helpful; otherwise, one might be wondering how non-phantom and phantom refs are distinguished here.

-------------

PR: https://git.openjdk.java.net/jdk/pull/498

From neliasso at openjdk.java.net  Wed Oct 14 12:06:19 2020
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Wed, 14 Oct 2020 12:06:19 GMT
Subject: RFR: 8173585: Intrinsify StringLatin1.indexOf(char) [v6]
In-Reply-To: <PuKDnAd5G6rpb3scQynqFMBf8zU37yVP_Qmp3SxmfyU=.06c27943-ea4d-4e3d-a4aa-a12a8033c35a@github.com>
References: <_T0873dC5tfUtGn9r1_Y21JkPKRt-za3MM9hPN2GQKQ=.b865fe53-5417-424f-81b6-1566a330640e@github.com>
 <PuKDnAd5G6rpb3scQynqFMBf8zU37yVP_Qmp3SxmfyU=.06c27943-ea4d-4e3d-a4aa-a12a8033c35a@github.com>
Message-ID: <RExrsR0klFewBYnIIuzvv5zcvtB_21lmxx149ZzsbUM=.4f1cabc8-52e3-4b5f-97c2-4c616e6892b6@github.com>

On Mon, 12 Oct 2020 11:17:25 GMT, Jason Tatton <github.com+70893615+jasontatton-aws at openjdk.org> wrote:

>> This is an implementation of the indexOf(char) intrinsic for StringLatin1 (1 byte encoded Strings). It is provided for
>> x86 and ARM64. The implementation is greatly inspired by the indexOf(char) intrinsic for StringUTF16. To incorporate it
>> I had to make a small change to StringLatin1.java (refactor of functionality to intrisified private method) as well as
>> code for C2.  Submitted to: hotspot-compiler-dev and core-libs-dev as this patch contains a change to hotspot and
>> java/lang/StringLatin1.java  https://bugs.openjdk.java.net/browse/JDK-8173585
>> 
>> Details of testing:
>> ============
>> I have created a jtreg test ?compiler/intrinsics/string/TestStringLatin1IndexOfChar? to cover this new intrinsic. Note
>> that, particularly for the x86 implementation of the intrinsic, the code path taken is dependent upon the length of the
>> input String. Hence the test has been designed to cover all these cases. In summary they are:
>> - A ?short? string of < 16 characters.
>> - A SIMD String of 16 ? 31 characters.
>> - A AVX2 SIMD String of 32 characters+.
>> 
>> Hardware used for testing:
>> -----------------------------
>> 
>> - Intel Xeon CPU E5-2680 (JVM did not recognize this as having AVX2 support) ? Intel i7 processor (with AVX2 support).
>> - AWS Graviton 2 (ARM 64 processor).
>> 
>> I also ran; ?run-test-tier1? and ?run-test-tier2? for: x86_64 and aarch64.
>> 
>> Possible future enhancements:
>> ====================
>> For the x86 implementation there may be two further improvements we can make in order to improve performance of both
>> the StringUTF16 and StringLatin1 indexOf(char) intrinsics:
>> 1. Make use of AVX-512 instructions.
>> 2. For ?short? Strings (see below), I think it may be possible to modify the existing algorithm to still use SSE SIMD
>> instructions instead of a loop.
>> Benchmark results:
>> ============
>> **Without** the new StringLatin1 indexOf(char) intrinsic:
>> 
>> | Benchmark  | Mode | Cnt | Score | Error | Units |
>> | ------------- | ------------- |------------- |------------- |------------- |------------- |
>> | IndexOfBenchmark.latin1_mixed_char | avgt | 5 | **26,389.129** | ? 182.581 | ns/op |
>> | IndexOfBenchmark.utf16_mixed_char | avgt | 5 | 17,885.383 | ? 435.933  | ns/op |
>> 
>> 
>> **With** the new StringLatin1 indexOf(char) intrinsic:
>> 
>> | Benchmark  | Mode | Cnt | Score | Error | Units |
>> | ------------- | ------------- |------------- |------------- |------------- |------------- |
>> | IndexOfBenchmark.latin1_mixed_char | avgt | 5 | **17,875.185** | ? 407.716  | ns/op |
>> | IndexOfBenchmark.utf16_mixed_char | avgt | 5 | 18,292.802 | ? 167.306  | ns/op |
>> 
>> 
>> The objective of the patch is to bring the performance of StringLatin1 indexOf(char) in line with StringUTF16
>> indexOf(char) for x86 and ARM64. We can see above that this has been achieved. Similar results were obtained when
>> running on ARM.
>
> Jason Tatton has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added missing copyright notices

Marked as reviewed by neliasso (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/71

From kravikumar at openjdk.java.net  Wed Oct 14 12:59:17 2020
From: kravikumar at openjdk.java.net (Kiran Sidhartha Ravikumar)
Date: Wed, 14 Oct 2020 12:59:17 GMT
Subject: RFR: 8254177: (tz) Upgrade time-zone data to tzdata2020b
In-Reply-To: <BXc3JRbHGJazB9A1lAON7YZ2AhSIxSII656FqnZaqdY=.778983fb-faa1-442f-86d8-5ad174b1317d@github.com>
References: <KvYfzEHlUV_cV29YAN2i2uXph2lldf0GGz_9TE5O0Iw=.c2d0262d-50d8-49fc-9815-1482616d1a3c@github.com>
 <aKCw-4GeWTCVDf5a6XtttBy2G67YJHDlWdrmTXjy66I=.67e2e981-4732-4075-a1c7-0c76f845abd9@github.com>
 <Hsd4_aFWtUkPKQAfgd4741RyCUes_UVlFWEzlw4Q69Y=.2673111e-c458-4807-9d4e-f431f6e76d23@github.com>
 <BXc3JRbHGJazB9A1lAON7YZ2AhSIxSII656FqnZaqdY=.778983fb-faa1-442f-86d8-5ad174b1317d@github.com>
Message-ID: <fDpL9h0scz5O8qBYscHt4R5mxqsw6rvhSsmyd-d_0Xw=.27b504a7-f305-42c0-8ef8-b1b0f463e04b@github.com>

On Tue, 13 Oct 2020 18:43:18 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

>> Thanks for the review everyone, I have added a release note to the bug. I will integrate the changes
>
> Looks like we both reached the same patch for this one independently :)
> systemv was removed from tzdata some time ago and wasn't even being read by the JDK as far as I could see. Its contents
> are duplicated in jdk11_backward anyway. Good to see both it and pacificnew being removed. In the unlikely event the
> removal of Pacific_New is problematic, it could be added to jdk11_backward as well, but it seems very unlikely.

Thanks for the comment, Andrew. I agree

-------------

PR: https://git.openjdk.java.net/jdk/pull/602

From github.com+70893615+jasontatton-aws at openjdk.java.net  Wed Oct 14 13:01:24 2020
From: github.com+70893615+jasontatton-aws at openjdk.java.net (Jason Tatton)
Date: Wed, 14 Oct 2020 13:01:24 GMT
Subject: Integrated: 8173585: Intrinsify StringLatin1.indexOf(char)
In-Reply-To: <_T0873dC5tfUtGn9r1_Y21JkPKRt-za3MM9hPN2GQKQ=.b865fe53-5417-424f-81b6-1566a330640e@github.com>
References: <_T0873dC5tfUtGn9r1_Y21JkPKRt-za3MM9hPN2GQKQ=.b865fe53-5417-424f-81b6-1566a330640e@github.com>
Message-ID: <zdAJM0KenGJ846cQ4Mcy2rdGwL8hmY-w19t5JFmBOcU=.9350810d-b52f-4a9f-a525-d4afedfa3c77@github.com>

On Tue, 8 Sep 2020 11:59:36 GMT, Jason Tatton <github.com+70893615+jasontatton-aws at openjdk.org> wrote:

> This is an implementation of the indexOf(char) intrinsic for StringLatin1 (1 byte encoded Strings). It is provided for
> x86 and ARM64. The implementation is greatly inspired by the indexOf(char) intrinsic for StringUTF16. To incorporate it
> I had to make a small change to StringLatin1.java (refactor of functionality to intrisified private method) as well as
> code for C2.  Submitted to: hotspot-compiler-dev and core-libs-dev as this patch contains a change to hotspot and
> java/lang/StringLatin1.java  https://bugs.openjdk.java.net/browse/JDK-8173585
> 
> Details of testing:
> ============
> I have created a jtreg test ?compiler/intrinsics/string/TestStringLatin1IndexOfChar? to cover this new intrinsic. Note
> that, particularly for the x86 implementation of the intrinsic, the code path taken is dependent upon the length of the
> input String. Hence the test has been designed to cover all these cases. In summary they are:
> - A ?short? string of < 16 characters.
> - A SIMD String of 16 ? 31 characters.
> - A AVX2 SIMD String of 32 characters+.
> 
> Hardware used for testing:
> -----------------------------
> 
> - Intel Xeon CPU E5-2680 (JVM did not recognize this as having AVX2 support) ? Intel i7 processor (with AVX2 support).
> - AWS Graviton 2 (ARM 64 processor).
> 
> I also ran; ?run-test-tier1? and ?run-test-tier2? for: x86_64 and aarch64.
> 
> Possible future enhancements:
> ====================
> For the x86 implementation there may be two further improvements we can make in order to improve performance of both
> the StringUTF16 and StringLatin1 indexOf(char) intrinsics:
> 1. Make use of AVX-512 instructions.
> 2. For ?short? Strings (see below), I think it may be possible to modify the existing algorithm to still use SSE SIMD
> instructions instead of a loop.
> Benchmark results:
> ============
> **Without** the new StringLatin1 indexOf(char) intrinsic:
> 
> | Benchmark  | Mode | Cnt | Score | Error | Units |
> | ------------- | ------------- |------------- |------------- |------------- |------------- |
> | IndexOfBenchmark.latin1_mixed_char | avgt | 5 | **26,389.129** | ? 182.581 | ns/op |
> | IndexOfBenchmark.utf16_mixed_char | avgt | 5 | 17,885.383 | ? 435.933  | ns/op |
> 
> 
> **With** the new StringLatin1 indexOf(char) intrinsic:
> 
> | Benchmark  | Mode | Cnt | Score | Error | Units |
> | ------------- | ------------- |------------- |------------- |------------- |------------- |
> | IndexOfBenchmark.latin1_mixed_char | avgt | 5 | **17,875.185** | ? 407.716  | ns/op |
> | IndexOfBenchmark.utf16_mixed_char | avgt | 5 | 18,292.802 | ? 167.306  | ns/op |
> 
> 
> The objective of the patch is to bring the performance of StringLatin1 indexOf(char) in line with StringUTF16
> indexOf(char) for x86 and ARM64. We can see above that this has been achieved. Similar results were obtained when
> running on ARM.

This pull request has now been integrated.

Changeset: f71e8a61
Author:    Jason Tatton (AWS) <jptatton at amazon.com>
Committer: Paul Hohensee <phh at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f71e8a61
Stats:     613 lines in 15 files changed: 597 ins; 0 del; 16 mod

8173585: Intrinsify StringLatin1.indexOf(char)

Reviewed-by: neliasso

-------------

PR: https://git.openjdk.java.net/jdk/pull/71

From rriggs at openjdk.java.net  Wed Oct 14 13:21:21 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 14 Oct 2020 13:21:21 GMT
Subject: RFR: 8173585: Intrinsify StringLatin1.indexOf(char) [v6]
In-Reply-To: <RExrsR0klFewBYnIIuzvv5zcvtB_21lmxx149ZzsbUM=.4f1cabc8-52e3-4b5f-97c2-4c616e6892b6@github.com>
References: <_T0873dC5tfUtGn9r1_Y21JkPKRt-za3MM9hPN2GQKQ=.b865fe53-5417-424f-81b6-1566a330640e@github.com>
 <PuKDnAd5G6rpb3scQynqFMBf8zU37yVP_Qmp3SxmfyU=.06c27943-ea4d-4e3d-a4aa-a12a8033c35a@github.com>
 <RExrsR0klFewBYnIIuzvv5zcvtB_21lmxx149ZzsbUM=.4f1cabc8-52e3-4b5f-97c2-4c616e6892b6@github.com>
Message-ID: <YyXLIYYqgJakyBBxzps3Pirezp7PtQ0deULmLks7PZk=.50536320-81a3-415d-9c23-bace488ee69f@github.com>

On Wed, 14 Oct 2020 12:03:42 GMT, Nils Eliasson <neliasso at openjdk.org> wrote:

>> Jason Tatton has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added missing copyright notices
>
> Marked as reviewed by neliasso (Reviewer).

Due to the requirement for multiple reviewers, I had been waiting to add my review of the Core-Libs files until the
HotSpot reviewers had approved!  I see only one reviewer credited in the commit.

-------------

PR: https://git.openjdk.java.net/jdk/pull/71

From rriggs at openjdk.java.net  Wed Oct 14 13:41:23 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 14 Oct 2020 13:41:23 GMT
Subject: RFR: 8251989: Hex formatting and parsing utility [v2]
In-Reply-To: <5LxXhzMVml7gGn-iEP18oCQIhkp-KRy6JG5QULIesQI=.3e06b5f4-bcf7-4040-a112-1895f3eb6e86@github.com>
References: <HSEn47GMS1K3g57mrTZeQk-WZHl3pKGHpX_OOf8VnsU=.740863c2-f9e4-43c4-b500-614aab4078b1@github.com>
 <Op6a9I7ariq5HWMwVGp_58VyMpElYx41ACVJXc3UdXc=.2faa2c38-503f-4236-9d5c-7afb3ba3f0ef@github.com>
 <5LxXhzMVml7gGn-iEP18oCQIhkp-KRy6JG5QULIesQI=.3e06b5f4-bcf7-4040-a112-1895f3eb6e86@github.com>
Message-ID: <fxn_VZJJGPQFdNQQrpbXAaZGT3bBhcP2LspdBZCslyQ=.563a588b-39c6-46b8-af0d-7f88cf1b59ed@github.com>

On Wed, 14 Oct 2020 09:28:25 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Various code review comments, rename UpperCase and LowerCase methods to match Character, remove unnecessary Class name
>>   qualifications, etc.
>
> src/java.base/share/classes/java/util/HexFormat.java line 41:
> 
>> 39:  * formatting markup such as prefixes, suffixes, and delimiters.
>> 40:  * <p>
>> 41:  * There are two {@code HexFormat}ters with preset parameters {@link #of()} and
> 
> Just a nit comment: stylistically, mixing fixed fonts and variable length fonts in a single word does not always
> display well. Alternative include using plain words, and use {@linkplain } to link to the class/method described (e.g.
> `{@linkplain HexFormat hexadecimal formatters}`), or reword (e.g. `There are two factories returning instances of
> {@code HexFormat} with ...`)...

Agreed, will fix.  I don't use @link to link to the javadoc of the class the link appears in.  A link to self is
misleading and distracting.

> src/java.net.http/share/classes/jdk/internal/net/http/common/Utils.java line 1116:
> 
>> 1114:         }
>> 1115:
>> 1116:         HexFormat format = HexFormat.of().withUpperCase();
> 
> Should/can this be a static final field in the class?

Its a bit of a space/time trade-off.  And the balance point will change if the class is converted in the future to a
Valhalla primitive class. At this point it looks to me like a premature optimization.

-------------

PR: https://git.openjdk.java.net/jdk/pull/482

From rriggs at openjdk.java.net  Wed Oct 14 13:50:13 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 14 Oct 2020 13:50:13 GMT
Subject: RFR: 8251989: Hex formatting and parsing utility [v2]
In-Reply-To: <5LxXhzMVml7gGn-iEP18oCQIhkp-KRy6JG5QULIesQI=.3e06b5f4-bcf7-4040-a112-1895f3eb6e86@github.com>
References: <HSEn47GMS1K3g57mrTZeQk-WZHl3pKGHpX_OOf8VnsU=.740863c2-f9e4-43c4-b500-614aab4078b1@github.com>
 <Op6a9I7ariq5HWMwVGp_58VyMpElYx41ACVJXc3UdXc=.2faa2c38-503f-4236-9d5c-7afb3ba3f0ef@github.com>
 <5LxXhzMVml7gGn-iEP18oCQIhkp-KRy6JG5QULIesQI=.3e06b5f4-bcf7-4040-a112-1895f3eb6e86@github.com>
Message-ID: <GfK8Dtw1b2AlCLbes3M6owppxasnbXRNAS8TS2ss75M=.582eca9d-15a1-4db3-8b69-c17bf2dc4b99@github.com>

On Wed, 14 Oct 2020 09:53:23 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Various code review comments, rename UpperCase and LowerCase methods to match Character, remove unnecessary Class name
>>   qualifications, etc.
>
> src/java.base/share/classes/java/util/HexFormat.java line 538:
> 
>> 536:      * A {@code delimiter} appears after each formatted value, except the last.
>> 537:      * The {@code delimiter}s, {@code prefix}es, and {@code suffix}es strings must be present;
>> 538:      * they may be empty strings.
> 
> I'd rather use @linkplain than @code here, or just plain words with no formatting, to avoid mixing different types of
> fonts in a single word.

Simpler is better, I will remove all the {@code } mark up on delimiter*, prefix*, and suffix*.

-------------

PR: https://git.openjdk.java.net/jdk/pull/482

From dfuchs at openjdk.java.net  Wed Oct 14 13:50:14 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 14 Oct 2020 13:50:14 GMT
Subject: RFR: 8251989: Hex formatting and parsing utility [v2]
In-Reply-To: <fxn_VZJJGPQFdNQQrpbXAaZGT3bBhcP2LspdBZCslyQ=.563a588b-39c6-46b8-af0d-7f88cf1b59ed@github.com>
References: <HSEn47GMS1K3g57mrTZeQk-WZHl3pKGHpX_OOf8VnsU=.740863c2-f9e4-43c4-b500-614aab4078b1@github.com>
 <Op6a9I7ariq5HWMwVGp_58VyMpElYx41ACVJXc3UdXc=.2faa2c38-503f-4236-9d5c-7afb3ba3f0ef@github.com>
 <5LxXhzMVml7gGn-iEP18oCQIhkp-KRy6JG5QULIesQI=.3e06b5f4-bcf7-4040-a112-1895f3eb6e86@github.com>
 <fxn_VZJJGPQFdNQQrpbXAaZGT3bBhcP2LspdBZCslyQ=.563a588b-39c6-46b8-af0d-7f88cf1b59ed@github.com>
Message-ID: <c5lRar-v6o64ov1G9vt_xiB9uFh1CAIXva5elkeXcHo=.3bffc608-d78b-43e6-a64d-96c294d32613@github.com>

On Wed, 14 Oct 2020 13:38:51 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> src/java.net.http/share/classes/jdk/internal/net/http/common/Utils.java line 1116:
>> 
>>> 1114:         }
>>> 1115:
>>> 1116:         HexFormat format = HexFormat.of().withUpperCase();
>> 
>> Should/can this be a static final field in the class?
>
> Its a bit of a space/time trade-off.  And the balance point will change if the class is converted in the future to a
> Valhalla primitive class. At this point it looks to me like a premature optimization.

OK - but just to avoid misunderstanding - I meant a static final field in  jdk.internal.net.http.common.Utils; as in
public class Utils { ...
    private static final HexFormat HEX_FORMAT = HexFormat.of().withUpperCase();
    ...
}

-------------

PR: https://git.openjdk.java.net/jdk/pull/482

From redestad at openjdk.java.net  Wed Oct 14 14:14:20 2020
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 14 Oct 2020 14:14:20 GMT
Subject: Integrated: 8254761: Wrong intrinsic annotation used for
 StringLatin1.indexOfChar
Message-ID: <qLJT0o71YHGH40eelvEWjv_3fJhWjPFdxDOHX5R53ls=.c59d21e5-10e8-4f09-8fbd-028b83145a02@github.com>

Wrong intrinsic name used, causing a build breakage

-------------

Commit messages:
 - Revert accidental changes
 - Merge branch 'intrinsic' of https://github.com/cl4es/jdk into intrinsic
 - HotspotIntrinsicCandidate is now IntrinsicCandidate
 - Revert accidental changes

Changes: https://git.openjdk.java.net/jdk/pull/654/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=654&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8254761
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/654.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/654/head:pull/654

PR: https://git.openjdk.java.net/jdk/pull/654

From alanb at openjdk.java.net  Wed Oct 14 14:14:21 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 14 Oct 2020 14:14:21 GMT
Subject: Integrated: 8254761: Wrong intrinsic annotation used for
 StringLatin1.indexOfChar
In-Reply-To: <qLJT0o71YHGH40eelvEWjv_3fJhWjPFdxDOHX5R53ls=.c59d21e5-10e8-4f09-8fbd-028b83145a02@github.com>
References: <qLJT0o71YHGH40eelvEWjv_3fJhWjPFdxDOHX5R53ls=.c59d21e5-10e8-4f09-8fbd-028b83145a02@github.com>
Message-ID: <CdEzyu6JVQlQ79ublfvvAWoUdK8OFvdrx8CmOWjgHbg=.146d76b5-46fb-41f8-a70b-52f9620545c3@github.com>

On Wed, 14 Oct 2020 14:04:07 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Wrong intrinsic name used, causing a build breakage

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/654

From redestad at openjdk.java.net  Wed Oct 14 14:14:21 2020
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 14 Oct 2020 14:14:21 GMT
Subject: Integrated: 8254761: Wrong intrinsic annotation used for
 StringLatin1.indexOfChar
In-Reply-To: <CdEzyu6JVQlQ79ublfvvAWoUdK8OFvdrx8CmOWjgHbg=.146d76b5-46fb-41f8-a70b-52f9620545c3@github.com>
References: <qLJT0o71YHGH40eelvEWjv_3fJhWjPFdxDOHX5R53ls=.c59d21e5-10e8-4f09-8fbd-028b83145a02@github.com>
 <CdEzyu6JVQlQ79ublfvvAWoUdK8OFvdrx8CmOWjgHbg=.146d76b5-46fb-41f8-a70b-52f9620545c3@github.com>
Message-ID: <6VShsd6gEinsXdTPrbAWelCF2Ewis_KINh6S3zAL770=.2b481f8f-ee50-4af7-949f-502bbdc5d3cb@github.com>

On Wed, 14 Oct 2020 14:06:44 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Wrong intrinsic name used, causing a build breakage
>
> Marked as reviewed by alanb (Reviewer).

Thanks for reviewing, @AlanBateman

Since builds are broken and I've verified a local build I'll go ahead and integrate without waiting for automated
testing to complete.

-------------

PR: https://git.openjdk.java.net/jdk/pull/654

From redestad at openjdk.java.net  Wed Oct 14 14:14:22 2020
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 14 Oct 2020 14:14:22 GMT
Subject: Integrated: 8254761: Wrong intrinsic annotation used for
 StringLatin1.indexOfChar
In-Reply-To: <qLJT0o71YHGH40eelvEWjv_3fJhWjPFdxDOHX5R53ls=.c59d21e5-10e8-4f09-8fbd-028b83145a02@github.com>
References: <qLJT0o71YHGH40eelvEWjv_3fJhWjPFdxDOHX5R53ls=.c59d21e5-10e8-4f09-8fbd-028b83145a02@github.com>
Message-ID: <YiQMRpd24FojOwYuT_XIjBh1JzfMRFD0muBShCOKXbU=.03ee004b-ccf2-49f3-bcdc-49f0cb9fdb28@github.com>

On Wed, 14 Oct 2020 14:04:07 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Wrong intrinsic name used, causing a build breakage

This pull request has now been integrated.

Changeset: a6a38135
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a6a38135
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8254761: Wrong intrinsic annotation used for StringLatin1.indexOfChar

Reviewed-by: alanb

-------------

PR: https://git.openjdk.java.net/jdk/pull/654

From github.com+70726043+rgiulietti at openjdk.java.net  Wed Oct 14 14:23:25 2020
From: github.com+70726043+rgiulietti at openjdk.java.net (Raffaello Giulietti)
Date: Wed, 14 Oct 2020 14:23:25 GMT
Subject: RFR: 8238669: Long.divideUnsigned is extremely slow for certain
 values (Needs to be Intrinsic) [v2]
In-Reply-To: <_0eIOqisk_pEhQy1ekXy-I2-YxtB9Vs-4kjLrzBevKk=.dbe46c8a-d0f4-4919-87ec-7fa1ab74b8ce@github.com>
References: <qTrgS9EALforkeYHdp592LnIrSJbqVAuv9Flfg3fbaU=.81db05a0-5847-4bfe-94ae-f4fcb922f4bc@github.com>
 <1afMfHAUJEnM5nUkl-LbkSxjYOZwjKgWu2NDIfhbc5U=.bbeab3f9-1278-4103-b5b3-dd9a2ae745a8@github.com>
 <sqDr0vszrj6-PWBC8Oo9kTu4r72yLJwkWjly0yH3I1E=.1409e303-a261-4df5-9f58-b2945843f870@github.com>
 <NnKxMnr2bpd4fh6bj44aF-CNjRVYFvH7JvvbPbGs26E=.a2a1f5db-777b-435e-9f18-9b198c4a2d38@github.com>
 <_0eIOqisk_pEhQy1ekXy-I2-YxtB9Vs-4kjLrzBevKk=.dbe46c8a-d0f4-4919-87ec-7fa1ab74b8ce@github.com>
Message-ID: <meO7jZ6tlDQdl-mBRW52wdsS1OzS2poucMTrRuu0TZI=.ace180df-9094-4602-b8c8-9975816229ad@github.com>

On Thu, 24 Sep 2020 15:33:01 GMT, Raffaello Giulietti <github.com+70726043+rgiulietti at openjdk.org> wrote:

>> @shipilev I agree, but that's the title chosen by the reporter of the JBS issue. Not sure I can edit it without
>> impacting bots and tools.
>
> Hello
> 
> this is a gentle reminder that this issue still needs a more formal review.
> 
> Greetings
> Raffaello

Hello,

a reminder that this issue has not been formally reviewed.
Estimated time: 10-15 min with "Hacker's delight" on the desk.

Greetings
Raffaello

-------------

PR: https://git.openjdk.java.net/jdk/pull/31

From kbarrett at openjdk.java.net  Wed Oct 14 14:24:14 2020
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Wed, 14 Oct 2020 14:24:14 GMT
Subject: RFR: 8188055: (ref) Add Reference::refersTo predicate [v3]
In-Reply-To: <5XemoS4nTtROBzX7sighX_dQrC4ZXzXNKfs3LM5BUR8=.c88f673a-650f-483e-bb7e-d197e53742d4@github.com>
References: <D4HSg8FT20Eaxk5KJkkw0GgETSxRkBn1ipS3Dt0kPto=.e4bab078-2e04-4413-90cb-9bfafb2a6831@github.com>
 <J-8wUT_ItffnPBtGCcJVokoBDDL5jOVG9COuoMIrVh8=.296b587b-0b4b-48ca-bc9a-dffb7eaa948a@github.com>
 <5XemoS4nTtROBzX7sighX_dQrC4ZXzXNKfs3LM5BUR8=.c88f673a-650f-483e-bb7e-d197e53742d4@github.com>
Message-ID: <j8k5iayIiBG8L6y4kxzUcOQdiIdYGOmEooLYLWUUJkA=.0b45920d-a401-4cd0-9297-3dbff6e9eced@github.com>

On Wed, 14 Oct 2020 11:18:18 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Kim Barrett has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - simplify test
>>  - cleanup nits from Mandy
>>  - use Object instead of TestObject
>
> src/java.base/share/classes/java/lang/ref/Reference.java line 362:
> 
>> 360:     /* Implementation of refersTo() for non-phantom references.
>> 361:      */
>> 362:     native boolean refersTo0(Object o);
> 
> 1. Why is it named `refersTo0`? How about sth more descriptive, e.g.`refersToNative`?
> 2. Nit: including some text that this method is overridden in `PhantomReference.java` in the comments will be more
> informative and helpful; otherwise, one might be wondering how non-phantom and phantom refs are distinguished here.

(1) The "0" suffix is idiomatic for this sort of thing.  See, for example,
src/java.base/share/native/libjava/ConstantPool.c. (2) I'm not sure what else besides an override one might wonder
about?  "Default implementation of refersTo(), for non-phantom references."?

-------------

PR: https://git.openjdk.java.net/jdk/pull/498

From ayang at openjdk.java.net  Wed Oct 14 14:42:13 2020
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Wed, 14 Oct 2020 14:42:13 GMT
Subject: RFR: 8188055: (ref) Add Reference::refersTo predicate [v3]
In-Reply-To: <j8k5iayIiBG8L6y4kxzUcOQdiIdYGOmEooLYLWUUJkA=.0b45920d-a401-4cd0-9297-3dbff6e9eced@github.com>
References: <D4HSg8FT20Eaxk5KJkkw0GgETSxRkBn1ipS3Dt0kPto=.e4bab078-2e04-4413-90cb-9bfafb2a6831@github.com>
 <J-8wUT_ItffnPBtGCcJVokoBDDL5jOVG9COuoMIrVh8=.296b587b-0b4b-48ca-bc9a-dffb7eaa948a@github.com>
 <5XemoS4nTtROBzX7sighX_dQrC4ZXzXNKfs3LM5BUR8=.c88f673a-650f-483e-bb7e-d197e53742d4@github.com>
 <j8k5iayIiBG8L6y4kxzUcOQdiIdYGOmEooLYLWUUJkA=.0b45920d-a401-4cd0-9297-3dbff6e9eced@github.com>
Message-ID: <ub1iS4VHGAop9lG_xgKY1n7ktE-vqUchltsdwKdfnLw=.e4d52317-d1e0-42da-a7ce-ebcb5fc3e802@github.com>

On Wed, 14 Oct 2020 14:19:59 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> See, for example, src/java.base/share/native/libjava/ConstantPool.c.

Got it; thank you.

> I'm not sure what else besides an override one might wonder about?

I don't know; maybe override is the only sensible choice. I just believe saying it explicitly is better than implicitly.

-------------

PR: https://git.openjdk.java.net/jdk/pull/498

From lancea at openjdk.java.net  Wed Oct 14 14:56:18 2020
From: lancea at openjdk.java.net (Lance Andersen)
Date: Wed, 14 Oct 2020 14:56:18 GMT
Subject: RFR: 8253952: Refine ZipOutputStream.putNextEntry() to
 recalculate ZipEntry's compressed size [v7]
In-Reply-To: <8NaRPfinIcIKT6GlY1mqQxGj43ZwwRYp6LYns504BeU=.c52e1ecc-5442-41e3-9e88-1b0be10bdf11@github.com>
References: <0nq5oFKOj6AZqCW6jF268-6oKRI6UkS6TRIHo-_5vKw=.d13c7016-4473-4b20-9117-100b368d3716@github.com>
 <8NaRPfinIcIKT6GlY1mqQxGj43ZwwRYp6LYns504BeU=.c52e1ecc-5442-41e3-9e88-1b0be10bdf11@github.com>
Message-ID: <sCic9ba5qJiVFwMbxsGdQqlKDTLVdY9bRPCd8I3aCDU=.7662e600-fac2-4589-9276-6d006ca9bd0c@github.com>

On Wed, 14 Oct 2020 10:54:30 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> ### Summary
>> 
>> Work around wrong usage of `ZipOutputStream.putNextEntry()` in user code which can lead to the `ZipException "invalid
>> entry compressed size"`.
>> ### Motivation
>> 
>> In general it is not safe to directly write a ZipEntry obtained from `ZipInputStream.getNextEntry()`,
>> `ZipFile.entries()`, `ZipFile.getEntry()` or `ZipFile.stream()` with `ZipOutputStream.putNextEntry()` to a
>> `ZipOutputStream` and then read the entries data from the `ZipInputStream` and write it to the `ZipOutputStream` as
>> follows:
>>  ZipEntry entry;
>>  ZipInputStream zis = new ZipInputStream(...);
>>  ZipOutputStream zos = new ZipOutputStream(...);
>>  while((entry = zis.getNextEntry()) != null) {
>>      zos.putNextEntry(entry);
>>      zis.transferTo(zos);
>>  }
>> The problem with this code is that the zip file format does not record the compression level used for deflation in its
>> entries. In general, it doesn't even mandate a predefined compression ratio per compression level. Therefore the
>> compressed size recorded in a `ZipEntry` read from a zip file might differ from the new compressed size produced by the
>> receiving `ZipOutputStream`. Such a difference will result in a `ZipException` with the following message:
>>  java.util.zip.ZipException: invalid entry compressed size (expected 12 but got 7 bytes)
>>  
>> The correct way of copying all entries from one zip file into another requires the creation of a new `ZipEntry` or at
>> least resetting of the compressed size field. E.g.:
>>  while((entry = zis.getNextEntry()) != null) {
>>      ZipEntry newEntry = new ZipEntry(entry.getName());
>>      zos.putNextEntry(newEntry);
>>      zis.transferTo(zos);
>>  }
>> or:
>>  while((entry = zis.getNextEntry()) != null) {
>>      entry.setCompressedSize(-1);
>>      zos.putNextEntry(entry);
>>      zis.transferTo(zos);
>>  }
>> Unfortunately, there's a lot of user code out there which gets this wrong and uses the bad coding pattern described
>> before. Searching for `"java.util.zip.ZipException: invalid entry compressed size (expected 12 but got 7 bytes)"` gives
>> ~2500 hits (~100 on StackOverflow). It's also no hard to find plenty of instances of this anti-pattern on GitHub when
>> doing a code search for `ZipEntry` and `putNextEntry()`. E.g. [Gradle 4.x wrapper task][1] is affected as well as the
>> latest version of the [mockableAndroidJar task][2]. I've recently fixed two occurrences of this pattern in OpenJDK (see
>> [JDK-8240333][3] and [JDK-8240235][4]) but there still exist more of them (e.g.
>> [`test/jdk/java/util/zip/ZipFile/CopyJar.java`][5] which is there since 1999 :).  ### Description  So while this has
>> clearly been a problem before, it apparently wasn't painful enough to trigger any action from the side of the JDK.
>> However, recently quite some zlib forks with [superior deflate/inflate performance have evolved][6]. Using them with
>> OpenJDK is quite straight-forward: one just has to configure the alternative implementations by setting
>> `LD_LIBRARY_PATH` or `LD_PRELOAD` correspondingly. We've seen big saving by using these new zlib implementations for
>> selected services in production and the only reason why we haven't enabled them by default until now is the problem
>> I've just described. The reason why these new libraries uncover the described anti-pattern much more often is because
>> their compression ratio is slightly different from that of the default zlib library. This can easily trigger a
>> `ZipException` even if an application is not using a different compression levels but just a zip file created with
>> another zlib version.  I'd therefore like to propose the following workaround for the wrong
>> `ZipOutputStream.putNextEntry()` usage in user code:
>> -  ignore the compressed size if it was implicitly determined from the zip file and not explicitly set by calling
>>    `ZipEntry.setCompressedSize()`.
>> 
>> - Change the API-documentation of `ZipOutputStream.putNextEntry()` and `JarOutputStream.putNextEntry()` to explain the
>>   problem and why `putNextEntry()` will ignore the compressed size of a `ZipEntry` if that was set implicitely when
>>   reading that entry from a `ZipFile` or `ZipInputStream`.
>> 
>> 
>> ### Technical Details
>> 
>> A zip file consists of a stream of File Entries followed by a Central Directory (see [here for a more detailed
>> specification][7]). Each File Entry is composed of a Local File Header (LFH) followed by the compressed Data and an
>> optional Data Descriptor. The LFH contains the File Name and among other attributes the Compressed and Uncompressed
>> size and CRC of the Data. In the case where the latter three attributes are not available at the time when the LFH is
>> created, this fact will be recorded in a flag of the LFH and will trigger the creation of a Data Descriptor with the
>> corresponding information right after the Data section. Finally, the Central Directory contains one Central Directory
>> File Header (CDFH) for each entry of the  zip archive. The CDFH is an extended version of the LFH and the ultimate
>> reference for the contents of the zip archive. The redundancy between LFH and CDFH is a tribute to zip's long history
>> when it was used to store archives on multiple floppy discs and the CDFH allowed to update the archive by only writing
>> to the last disc which contained the Central Directory.  `ZipEntries` read with `ZipInputStream.getNextEntry()` will
>> initially only contain the information from the LFH. Only after the next entry was read (or after
>> `ZipInputStream.closeEntry()` was called explicitly), will the previously read entry be updated with the data from the
>> Data Descriptor. `ZipInputStream` doesn't inspect the Central Directory at all.  On the other hand, `ZipFile` only
>> queries the Central Directory for `ZipEntry` information so all `ZipEntries` returned by `ZipFile.entries()`,
>> `ZipFile.getEntry()` and `ZipFile.stream()` will always instantly contain the full Compressed and Uncompressed Size and
>> CRC information for each entry independently of the LFH contents.  ### Risks and Assumptions  If we choose to ignore
>> the implicitly recorded compressed size in a `ZipEntry` read from a zip file when writing it to a `ZipOutputStream`,
>> this will lead to zip files with incomplete information in the LFH and an additional Data Descriptor as described
>> before. However, the result is still fully compatible to the zip file specification. It's also not unusual, because by
>> default all new zip files created with `ZipOutputStream` will contain LFHs without Compressed and Uncompressed Size and
>> CRC information and an additional Data Descriptor. Theoretically it is possible to create new zip files with
>> `ZipOutputStream` class and Compressed and Uncompressed Size and CRC information in the LFH but that's complex and
>> inefficient because it requires two steps. A first step to determine the crc and compressed size of the data and a
>> second step to actually write the data to the `ZipOutputStream` (which will compress it a second time). This is because
>> the current API offers no possibility to write already compressed data to a `ZipOutputStream`.  Consequently, the only
>> straight-forward way of creating zip files from Java which have all the data in the LFH and no Data Descriptor is by
>> copying `ZipEntries` from an existing zip file with the buggy method described before. This incidentally worked more or
>> less reliable for a long time but breaks miserably when using different zlib implementations. Ignoring the implicitly
>> set compressed size of `ZipEntries` can easily fix this problem.  I'm not aware of any tool which can not handle such
>> files and if it exists it would have problems with the majority of Java created zip files anyway (e.g. all jar-files
>> created with the jar tool have zip entries with incomplete LFH data and additional Data Descriptor).  Ignoring the
>> implicitly set compressed size of `ZipEntries` has no measurable performance impact and will increase the size of zip
>> archives which used to have the complete file information in the LFH before by 16 bytes per entry. On the other hand it
>> will give us the freedom to use whatever zip implementation we like :)   [1]:
>> https://github.com/gradle/gradle/blob/e76905e3a/subprojects/build-init/src/main/java/org/gradle/api/tasks/wrapper/Wrapper.java#L152-L158
>> [2]:
>> https://android.googlesource.com/platform/tools/base/+/refs/heads/master/build-system/builder/src/main/java/com/android/builder/testing/MockableJarGenerator.java#86
>> [3]: https://bugs.openjdk.java.net/browse/JDK-8240333 [4]: https://bugs.openjdk.java.net/browse/JDK-8240235 [5]:
>> https://github.com/openjdk/jdk/blob/master/test/jdk/java/util/zip/ZipFile/CopyJar.java [6]:
>> https://github.com/simonis/zlib-bench/blob/master/Results.md [7]: https://en.wikipedia.org/wiki/Zip_(file_format)
>
> Volker Simonis 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 changes look good.  Thank you for the updates.  I have kicked off mach5 jdk-tier1,jdk-tier2,jdk-tier3 runs across
all of the platforms.

-------------

Marked as reviewed by lancea (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/520

From lancea at openjdk.java.net  Wed Oct 14 14:56:19 2020
From: lancea at openjdk.java.net (Lance Andersen)
Date: Wed, 14 Oct 2020 14:56:19 GMT
Subject: RFR: 8253952: Refine ZipOutputStream.putNextEntry() to
 recalculate ZipEntry's compressed size [v2]
In-Reply-To: <fXfRwQU9AkSALTw37EQ6DNA_CinRUq4qBy3ECh1hhrU=.a9e49e85-b4e1-4cb1-8e19-72a646429334@github.com>
References: <0nq5oFKOj6AZqCW6jF268-6oKRI6UkS6TRIHo-_5vKw=.d13c7016-4473-4b20-9117-100b368d3716@github.com>
 <hY8lfhGTXizeHqM6iWX3eKDXz5B4-WHAFaZNvHLk6qc=.d9bf046e-f493-4653-94b1-39d154a4175e@github.com>
 <Jd3oV6qV9tPRHCqKNnIjMaJx6kYi--G7oyykOL_w5qU=.8be45e77-2ea4-4e02-9a07-4f9ba53f6e59@github.com>
 <6RMxyurj4wb-oTldhToZhDebkRlbFrSTPzAWnhcni0Q=.457787d6-d1fe-455d-9ade-03e01c099db9@github.com>
 <fXfRwQU9AkSALTw37EQ6DNA_CinRUq4qBy3ECh1hhrU=.a9e49e85-b4e1-4cb1-8e19-72a646429334@github.com>
Message-ID: <VoNLYs1iZfKdJdkpP1CvTqh4EKedVzz0XgF9Lv9y9bc=.0d7b051f-9d7c-4faf-a11b-527ef9e2e151@github.com>

On Mon, 12 Oct 2020 11:46:31 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> I don't believe we discuss/reference the data descriptor for a Zip entry (outside of the PKWare Zip specification) so I
>> am not sure we should reference it in the javadoc.
>>  Placing the sentence after "The default compression method will be used if no compression method was specified for the
>>  entry" makes sense
>
> Thanks for your input. I've tried to somehow merge both suggestions :)
> 
> Did you had a chance to look at the CSR? I think somebody has to review it before I can move it to "Finalized".
> 
> Thank you and best regards,
> Volker

I have added myself as a reviewer based on the updates made by you and Alan

-------------

PR: https://git.openjdk.java.net/jdk/pull/520

From shade at openjdk.java.net  Wed Oct 14 14:58:20 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 14 Oct 2020 14:58:20 GMT
Subject: RFR: 8253525: Implement getInstanceSize/sizeOf intrinsics
Message-ID: <e93rUplFjEg-aHNsK_erFVgID73Egxk_x2Z82nOln1Q=.8fd819d9-b20b-4b54-98f9-6596c1933518@github.com>

This is fork off the SizeOf JEP, JDK-8249196. There is already the entry point in JDK that can use the intrinsic like
this: `Instrumentation.getInstanceSize`. Therefore, we can implement the C1/C2 intrinsic now, hook it up to
`Instrumentation`, and let the tools use that fast path today.

With this patch, JOL is able to be close to `deepSizeOf` implementation from SizeOf JEP.

Example performance improvements for sizing up a custom linked list:

Benchmark                     (size)  Mode  Cnt       Score      Error  Units

# Default
LinkedChainBench.linkedChain       1  avgt    5     705.835 ?    8.051  ns/op
LinkedChainBench.linkedChain      10  avgt    5    3148.874 ?   37.856  ns/op
LinkedChainBench.linkedChain     100  avgt    5   28693.256 ?  142.254  ns/op
LinkedChainBench.linkedChain    1000  avgt    5  290161.590 ? 4594.631  ns/op

# Instrumentation attached, no intrinsics
LinkedChainBench.linkedChain       1  avgt    5    159.659 ?   19.238  ns/op
LinkedChainBench.linkedChain      10  avgt    5    717.659 ?   22.540  ns/op
LinkedChainBench.linkedChain     100  avgt    5   7739.394 ?  111.683  ns/op
LinkedChainBench.linkedChain    1000  avgt    5  80724.238 ? 2887.794  ns/op

# Instrumentation attached, new intrinsics
LinkedChainBench.linkedChain       1  avgt    5     95.254 ?   0.808  ns/op
LinkedChainBench.linkedChain      10  avgt    5    261.564 ?   8.524  ns/op
LinkedChainBench.linkedChain     100  avgt    5   3367.192 ?  21.128  ns/op
LinkedChainBench.linkedChain    1000  avgt    5  34148.851 ? 373.080  ns/op

-------------

Commit messages:
 - 8253525: Implement getInstanceSize/sizeOf intrinsics

Changes: https://git.openjdk.java.net/jdk/pull/650/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=650&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8253525
  Stats: 613 lines in 10 files changed: 564 ins; 0 del; 49 mod
  Patch: https://git.openjdk.java.net/jdk/pull/650.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/650/head:pull/650

PR: https://git.openjdk.java.net/jdk/pull/650

From rriggs at openjdk.java.net  Wed Oct 14 15:05:28 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 14 Oct 2020 15:05:28 GMT
Subject: RFR: 8173585: Intrinsify StringLatin1.indexOf(char) [v6]
In-Reply-To: <YyXLIYYqgJakyBBxzps3Pirezp7PtQ0deULmLks7PZk=.50536320-81a3-415d-9c23-bace488ee69f@github.com>
References: <_T0873dC5tfUtGn9r1_Y21JkPKRt-za3MM9hPN2GQKQ=.b865fe53-5417-424f-81b6-1566a330640e@github.com>
 <PuKDnAd5G6rpb3scQynqFMBf8zU37yVP_Qmp3SxmfyU=.06c27943-ea4d-4e3d-a4aa-a12a8033c35a@github.com>
 <RExrsR0klFewBYnIIuzvv5zcvtB_21lmxx149ZzsbUM=.4f1cabc8-52e3-4b5f-97c2-4c616e6892b6@github.com>
 <YyXLIYYqgJakyBBxzps3Pirezp7PtQ0deULmLks7PZk=.50536320-81a3-415d-9c23-bace488ee69f@github.com>
Message-ID: <UmWKeutVtUj7LngtfcEE5OecBuyx0A125H8DysqQaXQ=.574d0863-7045-4b07-b8bc-3fcc1074648b@github.com>

On Wed, 14 Oct 2020 13:18:19 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Marked as reviewed by neliasso (Reviewer).
>
> Due to the requirement for multiple reviewers, I had been waiting to add my review of the Core-Libs files until the
> HotSpot reviewers had approved!  I see only one reviewer credited in the commit.

This integration without testing with a current merge from the master and has caused two build failures.
JDK-8254761: Wrong intrinsic annotation used for StringLatin1.indexOfChar

Also, there is a raw unicode character in the JMH test that causes a compilation error.
== Output from failing command(s) repeated here ===
[2020-10-14T14:39:09,608Z] * For target support_test_micro_classes__the.BUILD_JDK_MICROBENCHMARK_batch:
[2020-10-14T14:39:09,611Z]
/opt/mach5/mesos/work_dir/slaves/4076d11c-c6ed-4d07-84c1-4ab8d55cd975-S108796/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/400e1f56-2d49-42d8-8879-97d4fbb6c909/runs/c49da2bc-a8fe-4a5d-8159-57a9b0316fd2/workspace/open/test/micro/org/openjdk/bench/java/lang/StringIndexOfChar.java:71:
error: unmappable character (0xE2) for encoding ascii [2020-10-14T14:39:09,611Z]
sb.append(isUtf16?'???':'b'); [2020-10-14T14:39:09,611Z]                                ^ [2020-10-14T14:39:09,611Z]
/opt/mach5/mesos/work_dir/slaves/4076d11c-c6ed-4d07-84c1-4ab8d55cd975-S108796/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/400e1f56-2d49-42d8-8879-97d4fbb6c909/runs/c49da2bc-a8fe-4a5d-8159-57a9b0316fd2/workspace/open/test/micro/org/openjdk/bench/java/lang/StringIndexOfChar.java:71:
error: unmappable character (0x98) for encoding ascii [2020-10-14T14:39:09,611Z]
sb.append(isUtf16?'???':'b'); [2020-10-14T14:39:09,611Z]                                 ^ [2020-10-14T14:39:09,611Z]
/opt/mach5/mesos/work_dir/slaves/4076d11c-c6ed-4d07-84c1-4ab8d55cd975-S108796/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/400e1f56-2d49-42d8-8879-97d4fbb6c909/runs/c49da2bc-a8fe-4a5d-8159-57a9b0316fd2/workspace/open/test/micro/org/openjdk/bench/java/lang/StringIndexOfChar.java:71:
error: unmappable character (0xBA) for encoding ascii [2020-10-14T14:39:09,611Z]
sb.append(isUtf16?'???':'b'); [2020-10-14T14:39:09,611Z]                                  ^ [2020-10-14T14:39:09,611Z]
/opt/mach5/mesos/work_dir/slaves/4076d11c-c6ed-4d07-84c1-4ab8d55cd975-S108796/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/400e1f56-2d49-42d8-8879-97d4fbb6c909/runs/c49da2bc-a8fe-4a5d-8159-57a9b0316fd2/workspace/open/test/micro/org/openjdk/bench/java/lang/StringIndexOfChar.java:71:
error: unclosed character literal [2020-10-14T14:39:09,611Z]             sb.append(isUtf16?'???':'b');
[2020-10-14T14:39:09,611Z]                               ^ [2020-10-14T14:39:09,611Z]
/opt/mach5/mesos/work_dir/slaves/4076d11c-c6ed-4d07-84c1-4ab8d55cd975-S108796/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/400e1f56-2d49-42d8-8879-97d4fbb6c909/runs/c49da2bc-a8fe-4a5d-8159-57a9b0316fd2/workspace/open/test/micro/org/openjdk/bench/java/lang/StringIndexOfChar.java:71:
error: unclosed character literal [2020-10-14T14:39:09,611Z]             sb.append(isUtf16?'???':'b');```

-------------

PR: https://git.openjdk.java.net/jdk/pull/71

From rriggs at openjdk.java.net  Wed Oct 14 15:11:25 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 14 Oct 2020 15:11:25 GMT
Subject: RFR: 8251989: Hex formatting and parsing utility [v2]
In-Reply-To: <c5lRar-v6o64ov1G9vt_xiB9uFh1CAIXva5elkeXcHo=.3bffc608-d78b-43e6-a64d-96c294d32613@github.com>
References: <HSEn47GMS1K3g57mrTZeQk-WZHl3pKGHpX_OOf8VnsU=.740863c2-f9e4-43c4-b500-614aab4078b1@github.com>
 <Op6a9I7ariq5HWMwVGp_58VyMpElYx41ACVJXc3UdXc=.2faa2c38-503f-4236-9d5c-7afb3ba3f0ef@github.com>
 <5LxXhzMVml7gGn-iEP18oCQIhkp-KRy6JG5QULIesQI=.3e06b5f4-bcf7-4040-a112-1895f3eb6e86@github.com>
 <fxn_VZJJGPQFdNQQrpbXAaZGT3bBhcP2LspdBZCslyQ=.563a588b-39c6-46b8-af0d-7f88cf1b59ed@github.com>
 <c5lRar-v6o64ov1G9vt_xiB9uFh1CAIXva5elkeXcHo=.3bffc608-d78b-43e6-a64d-96c294d32613@github.com>
Message-ID: <coLUQ6I7CjMfcYnHf_-wfhNnxzGwmWfqolO2MxF8rSg=.3ee1f147-178f-4f48-bde8-629acdca9274@github.com>

On Wed, 14 Oct 2020 13:46:59 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Its a bit of a space/time trade-off.  And the balance point will change if the class is converted in the future to a
>> Valhalla primitive class. At this point it looks to me like a premature optimization.
>
> OK - but just to avoid misunderstanding - I meant a static final field in  jdk.internal.net.http.common.Utils; as in
> public class Utils { ...
>     private static final HexFormat HEX_FORMAT = HexFormat.of().withUpperCase();
>     ...
> }

Yes, that's what I understood.  Still it take up space and gc is aware of it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/482

From psandoz at openjdk.java.net  Wed Oct 14 15:16:48 2020
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Wed, 14 Oct 2020 15:16:48 GMT
Subject: RFR: 8223347: Integration of Vector API (Incubator) [v5]
In-Reply-To: <-PE4TwXgvq2bemAn_8csjn4_j7zoAolnQz6QQt3z0Wk=.eaa9999f-0713-4349-b31d-934717aa37a1@github.com>
References: <-PE4TwXgvq2bemAn_8csjn4_j7zoAolnQz6QQt3z0Wk=.eaa9999f-0713-4349-b31d-934717aa37a1@github.com>
Message-ID: <e7JTzntlnXulVzZEAILzsnvJ8Hwq-Lcq3Hf8Di_2Oig=.b3bd86f0-02d6-4d01-9e11-193493c9b153@github.com>

> This pull request is for integration of the Vector API. It was previously reviewed under conditions when mercurial was
> used for the source code control system. Review threads can be found here (searching for issue number 8223347 in the
> title):  https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-April/thread.html
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-May/thread.html
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-July/thread.html
> 
> If mercurial was still being used the code would be pushed directly, once the CSR is approved. However, in this case a
> pull request is required and needs explicit reviewer approval. Between the final review and this pull request no code
> has changed, except for that related to merging.

Paul Sandoz 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 master
 - Merge master
 - Fix related to merge
 - HotspotIntrinsicCandidate to IntrinsicCandidate
 - Merge master
 - Fix permissions
 - Fix permissions
 - Merge master
 - Vector API new files
 - Integration of Vector API (Incubator)

-------------

Changes: https://git.openjdk.java.net/jdk/pull/367/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=367&range=04
  Stats: 295107 lines in 336 files changed: 292957 ins; 1062 del; 1088 mod
  Patch: https://git.openjdk.java.net/jdk/pull/367.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/367/head:pull/367

PR: https://git.openjdk.java.net/jdk/pull/367

From redestad at openjdk.java.net  Wed Oct 14 15:21:22 2020
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 14 Oct 2020 15:21:22 GMT
Subject: RFR: 8254775: Microbenchmark StringIndexOfChar doesn't compile
Message-ID: <DaDGwgndD4P8TBcQarOSgAoIGcBZKK-aE_qHla3TN3U=.57c4e24f-996a-4d5f-b34f-dbb5f1b2dbdd@github.com>

- Illegal use of a unicode codepoint > \uFFFF as a char.
- Wrong class name.
- @Benchmark methods shouldn't be static.

Each of these breaks the build, e.g. make build-microbenchmark fails, so it seems the micro was never tested..?

This patch fixes up the micro so it compiles, but makes no guarantees the micro does anything useful.

-------------

Commit messages:
 - Benchmark methods should be non-static
 - Mismatching name
 - Use a codepoint that fits in a char

Changes: https://git.openjdk.java.net/jdk/pull/661/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=661&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8254775
  Stats: 18 lines in 1 file changed: 0 ins; 0 del; 18 mod
  Patch: https://git.openjdk.java.net/jdk/pull/661.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/661/head:pull/661

PR: https://git.openjdk.java.net/jdk/pull/661

From rriggs at openjdk.java.net  Wed Oct 14 15:21:23 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 14 Oct 2020 15:21:23 GMT
Subject: RFR: 8254775: Microbenchmark StringIndexOfChar doesn't compile
In-Reply-To: <DaDGwgndD4P8TBcQarOSgAoIGcBZKK-aE_qHla3TN3U=.57c4e24f-996a-4d5f-b34f-dbb5f1b2dbdd@github.com>
References: <DaDGwgndD4P8TBcQarOSgAoIGcBZKK-aE_qHla3TN3U=.57c4e24f-996a-4d5f-b34f-dbb5f1b2dbdd@github.com>
Message-ID: <LjLYdzr8AcfP-RvzysXgYiY-3V4iD2lX9V_Rv7C-shY=.fec76d95-f3e6-4578-bb42-e20d9e6b2da6@github.com>

On Wed, 14 Oct 2020 15:09:59 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> - Illegal use of a unicode codepoint > \uFFFF as a char.
> - Wrong class name.
> - @Benchmark methods shouldn't be static.
> 
> Each of these breaks the build, e.g. make build-microbenchmark fails, so it seems the micro was never tested..?
> 
> This patch fixes up the micro so it compiles, but makes no guarantees the micro does anything useful.

Thanks for fixing these problems.

-------------

Marked as reviewed by rriggs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/661

From redestad at openjdk.java.net  Wed Oct 14 15:26:16 2020
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 14 Oct 2020 15:26:16 GMT
Subject: RFR: 8254775: Microbenchmark StringIndexOfChar doesn't compile
In-Reply-To: <LjLYdzr8AcfP-RvzysXgYiY-3V4iD2lX9V_Rv7C-shY=.fec76d95-f3e6-4578-bb42-e20d9e6b2da6@github.com>
References: <DaDGwgndD4P8TBcQarOSgAoIGcBZKK-aE_qHla3TN3U=.57c4e24f-996a-4d5f-b34f-dbb5f1b2dbdd@github.com>
 <LjLYdzr8AcfP-RvzysXgYiY-3V4iD2lX9V_Rv7C-shY=.fec76d95-f3e6-4578-bb42-e20d9e6b2da6@github.com>
Message-ID: <HGpaKBgx0EGBpfJDAltk9q4WxFf1CXM48TUr30LUEkQ=.ddb5d5c6-8dec-422b-b833-80950ee0f7fc@github.com>

On Wed, 14 Oct 2020 15:13:00 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> - Illegal use of a unicode codepoint > \uFFFF as a char.
>> - Wrong class name.
>> - @Benchmark methods shouldn't be static.
>> 
>> Each of these breaks the build, e.g. make build-microbenchmark fails, so it seems the micro was never tested..?
>> 
>> This patch fixes up the micro so it compiles, but makes no guarantees the micro does anything useful.
>
> Thanks for fixing these problems.

Thanks for reviewing, @RogerRiggs - hopefully this is the last of 'em

-------------

PR: https://git.openjdk.java.net/jdk/pull/661

From redestad at openjdk.java.net  Wed Oct 14 15:29:16 2020
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 14 Oct 2020 15:29:16 GMT
Subject: Integrated: 8254775: Microbenchmark StringIndexOfChar doesn't compile
In-Reply-To: <DaDGwgndD4P8TBcQarOSgAoIGcBZKK-aE_qHla3TN3U=.57c4e24f-996a-4d5f-b34f-dbb5f1b2dbdd@github.com>
References: <DaDGwgndD4P8TBcQarOSgAoIGcBZKK-aE_qHla3TN3U=.57c4e24f-996a-4d5f-b34f-dbb5f1b2dbdd@github.com>
Message-ID: <mXQR4l5OQv4PFqUE50PtLiPnNLzB6FJCfGoCyHVdUxI=.33b58040-1081-4fa5-a536-c4491bba8729@github.com>

On Wed, 14 Oct 2020 15:09:59 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> - Illegal use of a unicode codepoint > \uFFFF as a char.
> - Wrong class name.
> - @Benchmark methods shouldn't be static.
> 
> Each of these breaks the build, e.g. make build-microbenchmark fails, so it seems the micro was never tested..?
> 
> This patch fixes up the micro so it compiles, but makes no guarantees the micro does anything useful.

This pull request has now been integrated.

Changeset: 96a1f08e
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/96a1f08e
Stats:     18 lines in 1 file changed: 0 ins; 0 del; 18 mod

8254775: Microbenchmark StringIndexOfChar doesn't compile

Reviewed-by: rriggs

-------------

PR: https://git.openjdk.java.net/jdk/pull/661

From shade at openjdk.java.net  Wed Oct 14 15:35:17 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 14 Oct 2020 15:35:17 GMT
Subject: RFR: 8254775: Microbenchmark StringIndexOfChar doesn't compile
In-Reply-To: <HGpaKBgx0EGBpfJDAltk9q4WxFf1CXM48TUr30LUEkQ=.ddb5d5c6-8dec-422b-b833-80950ee0f7fc@github.com>
References: <DaDGwgndD4P8TBcQarOSgAoIGcBZKK-aE_qHla3TN3U=.57c4e24f-996a-4d5f-b34f-dbb5f1b2dbdd@github.com>
 <LjLYdzr8AcfP-RvzysXgYiY-3V4iD2lX9V_Rv7C-shY=.fec76d95-f3e6-4578-bb42-e20d9e6b2da6@github.com>
 <HGpaKBgx0EGBpfJDAltk9q4WxFf1CXM48TUr30LUEkQ=.ddb5d5c6-8dec-422b-b833-80950ee0f7fc@github.com>
Message-ID: <WWrYgIShV98NobF3NkJKVQS7fZrKSuYIXBJqneUT3-Q=.95b96876-0f71-44b2-96d8-0fcb786fb53f@github.com>

On Wed, 14 Oct 2020 15:23:31 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Thanks for fixing these problems.
>
> Thanks for reviewing, @RogerRiggs - hopefully this is the last of 'em

The benchmark is oddly written. I submitted https://bugs.openjdk.java.net/browse/JDK-8254782 -- to let original authors
fix it up.

-------------

PR: https://git.openjdk.java.net/jdk/pull/661

From redestad at openjdk.java.net  Wed Oct 14 15:42:13 2020
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 14 Oct 2020 15:42:13 GMT
Subject: RFR: 8254775: Microbenchmark StringIndexOfChar doesn't compile
In-Reply-To: <WWrYgIShV98NobF3NkJKVQS7fZrKSuYIXBJqneUT3-Q=.95b96876-0f71-44b2-96d8-0fcb786fb53f@github.com>
References: <DaDGwgndD4P8TBcQarOSgAoIGcBZKK-aE_qHla3TN3U=.57c4e24f-996a-4d5f-b34f-dbb5f1b2dbdd@github.com>
 <LjLYdzr8AcfP-RvzysXgYiY-3V4iD2lX9V_Rv7C-shY=.fec76d95-f3e6-4578-bb42-e20d9e6b2da6@github.com>
 <HGpaKBgx0EGBpfJDAltk9q4WxFf1CXM48TUr30LUEkQ=.ddb5d5c6-8dec-422b-b833-80950ee0f7fc@github.com>
 <WWrYgIShV98NobF3NkJKVQS7fZrKSuYIXBJqneUT3-Q=.95b96876-0f71-44b2-96d8-0fcb786fb53f@github.com>
Message-ID: <9MinwHJY1Qylug3IpYi9zqMwv0jecEbhRDHnlToxH0s=.d9aabaf0-18f6-4385-b1d3-476e6ecfc131@github.com>

On Wed, 14 Oct 2020 15:32:13 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Thanks for reviewing, @RogerRiggs - hopefully this is the last of 'em
>
> The benchmark is oddly written. I submitted https://bugs.openjdk.java.net/browse/JDK-8254782 -- to let original authors
> fix it up.

@shipilev yeah, seems reasonable. Thanks!

-------------

PR: https://git.openjdk.java.net/jdk/pull/661

From prr at openjdk.java.net  Wed Oct 14 16:16:16 2020
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 14 Oct 2020 16:16:16 GMT
Subject: RFR: JDK-8252870: Finalize (remove "incubator" from) jpackage [v2]
In-Reply-To: <C1gKE74s6f3xjeBRJ_pYlbqMrLcfkbMSq1jJdvcf92w=.e74b4173-3063-4728-b003-683fa9f85035@github.com>
References: <HlksY2mFyKG_kkZA6n6JHHIWBGJT3bjmoLG28c9q1EU=.2b9faa66-08b9-4694-a5db-9d9918039642@github.com>
 <C1gKE74s6f3xjeBRJ_pYlbqMrLcfkbMSq1jJdvcf92w=.e74b4173-3063-4728-b003-683fa9f85035@github.com>
Message-ID: <rjoMS7Jp8Qj5smwOO_Lf8G45zbBGoBT1Yq9Ir3nOBIE=.81b0c3d0-bda7-4779-9631-45bf3ed884f2@github.com>

On Tue, 13 Oct 2020 14:48:40 GMT, Andy Herrick <herrick at openjdk.org> wrote:

>> JDK-8252870: Finalize (remove "incubator" from) jpackage
>
> Andy Herrick has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8252870: Finalize (remove "incubator" from) jpackage
>     - reverting two auto-generated files, and changing module-info to "@since 16"

Amazing how many places the word incubator appeared.
I am approving on the understanding that all the automated jpackage tests pass on all platforms.

-------------

Marked as reviewed by prr (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/633

From ccheung at openjdk.java.net  Wed Oct 14 16:27:25 2020
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Wed, 14 Oct 2020 16:27:25 GMT
Subject: RFR: 8247666: Support Lambda proxy classes in static CDS archive
 [v5]
In-Reply-To: <DGaGgn21Mpmvucd3lJUBt1LAlzFFmQnif5lm_NuTRvA=.44b63649-52c8-45b4-9d3a-f5dad40d3e4f@github.com>
References: <ynh4JzHY75GjEn5_oCtmRNy9HMFsU34O2PlhSwD41tU=.1a3770f9-9091-429f-8d03-31b826f9b093@github.com>
 <PX8-qxYCB8jwJw8EongFi_2-HYdOkdNGkutskSoxulg=.1a85bb57-c65f-42c7-8def-a122ee150055@github.com>
 <wuZkq-j9ciIYkjs25F7LG9-YDFaNzWysnHWQXLT-Z3s=.2f1d4107-586a-4756-bdac-21be9d60425b@github.com>
 <DGaGgn21Mpmvucd3lJUBt1LAlzFFmQnif5lm_NuTRvA=.44b63649-52c8-45b4-9d3a-f5dad40d3e4f@github.com>
Message-ID: <HCKF2Oe7zPBy-lTCDXixvDGqdNnFHixFE3nRCV0jeII=.54f90676-13db-405d-a36e-f1156a12912c@github.com>

On Wed, 14 Oct 2020 01:44:05 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Changes requested by iklam (Reviewer).
>
>>  `@lambda-proxy: LambHello run ()Ljava/lang/Runnable; ()V 6 LambHello lambda$main$0 ()V ()V`
> 
> Can you explain the format?

`@lambda-proxy LambHello run ()Ljava/lang/Runnable; ()V REF_invokeStatic LambHello lambda$main$0 ()V ()V`
means
`@lambda-proxy <classname> <intf-method-name> <intf-method-sig> <bsm-arg0> <bsm-arg1a> <bsm-arg1b>? <bsm-arg1c>?
<bsm-arg1d> <bsm-arg2>`

It is a symbolic representation of a invoke dynamic constant pool entry.
public class LambHello {
    public static void main(String[] args) {
        doit(() -> {
            System.out.println("Hello from Lambda");
        });
    }
    static void doit(Runnable t) {
        t.run();
    }
}

An invoke dynamic constant pool of the above program is:
` -   7 : InvokeDynamic : bootstrap_method_index=43 name_and_type_index=8 arguments={50, 51, 50}`
Other constant pool entries related to the above are:
 -   8 : NameAndType : name_index=9 signature_index=10
 -   9 : Utf8 : 'run'
 -  10 : Utf8 : '()Ljava/lang/Runnable;'

 -  50 : MethodType : signature_index=6
 -  51 : MethodHandle : ref_kind=6 ref_index=52
 -  52 : Method : klass_index=12 name_and_type_index=53
 -  53 : NameAndType : name_index=39 signature_index=6

 -   6 : Utf8 : '()V'
 -  12 : Class : 'LambHello' {0x0000000800c10040}
 -  39 : Utf8 : 'lambda$main$0'
The info included in the class list are:
    <classname>                  = LambHello
    <intf-method-name>     = run
    <intf-method-sig>         = ()Ljava/lang/Runnable;
    <bsm-arg0>                   = ()V
    <bsm-arg1a>                  = REF_invokeStatic
    <bsm-arg1b>                  = LambHello
    <bsm-arg1c>                  = lambda$main$0
    <bsm-arg1d>                  = ()V
    <bsm-arg2>                   = ()V

-------------

PR: https://git.openjdk.java.net/jdk/pull/364

From lancea at openjdk.java.net  Wed Oct 14 16:34:17 2020
From: lancea at openjdk.java.net (Lance Andersen)
Date: Wed, 14 Oct 2020 16:34:17 GMT
Subject: RFR: 8253952: Refine ZipOutputStream.putNextEntry() to
 recalculate ZipEntry's compressed size [v7]
In-Reply-To: <sCic9ba5qJiVFwMbxsGdQqlKDTLVdY9bRPCd8I3aCDU=.7662e600-fac2-4589-9276-6d006ca9bd0c@github.com>
References: <0nq5oFKOj6AZqCW6jF268-6oKRI6UkS6TRIHo-_5vKw=.d13c7016-4473-4b20-9117-100b368d3716@github.com>
 <8NaRPfinIcIKT6GlY1mqQxGj43ZwwRYp6LYns504BeU=.c52e1ecc-5442-41e3-9e88-1b0be10bdf11@github.com>
 <sCic9ba5qJiVFwMbxsGdQqlKDTLVdY9bRPCd8I3aCDU=.7662e600-fac2-4589-9276-6d006ca9bd0c@github.com>
Message-ID: <hvMgjRE6rX14SRWKGgkwGH1M09cvjmfRc5jPNbOdjmA=.1e8e86fe-795a-4c53-9be7-588ab61ca968@github.com>

On Wed, 14 Oct 2020 14:52:29 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Volker Simonis 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 changes look good.  Thank you for the updates.  I have kicked off mach5 jdk-tier1,jdk-tier2,jdk-tier3 runs across
> all of the platforms.

Mach5 run is clean :-)

-------------

PR: https://git.openjdk.java.net/jdk/pull/520

From psandoz at openjdk.java.net  Wed Oct 14 17:10:43 2020
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Wed, 14 Oct 2020 17:10:43 GMT
Subject: RFR: 8223347: Integration of Vector API (Incubator) [v6]
In-Reply-To: <-PE4TwXgvq2bemAn_8csjn4_j7zoAolnQz6QQt3z0Wk=.eaa9999f-0713-4349-b31d-934717aa37a1@github.com>
References: <-PE4TwXgvq2bemAn_8csjn4_j7zoAolnQz6QQt3z0Wk=.eaa9999f-0713-4349-b31d-934717aa37a1@github.com>
Message-ID: <LgLGAQE6cDrbq0GliHcyMefhX7lIcUycwozyv2cfgyU=.607b6786-db20-4e21-9110-3ef01260a083@github.com>

> This pull request is for integration of the Vector API. It was previously reviewed under conditions when mercurial was
> used for the source code control system. Review threads can be found here (searching for issue number 8223347 in the
> title):  https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-April/thread.html
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-May/thread.html
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-July/thread.html
> 
> If mercurial was still being used the code would be pushed directly, once the CSR is approved. However, in this case a
> pull request is required and needs explicit reviewer approval. Between the final review and this pull request no code
> has changed, except for that related to merging.

Paul Sandoz has updated the pull request with a new target base due to a merge or a rebase. The pull request now
contains 11 commits:

 - Merge master
 - Merge master
 - Merge master
 - Fix related to merge
 - HotspotIntrinsicCandidate to IntrinsicCandidate
 - Merge master
 - Fix permissions
 - Fix permissions
 - Merge master
 - Vector API new files
 - ... and 1 more: https://git.openjdk.java.net/jdk/compare/96a1f08e...3346d292

-------------

Changes: https://git.openjdk.java.net/jdk/pull/367/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=367&range=05
  Stats: 295107 lines in 336 files changed: 292957 ins; 1062 del; 1088 mod
  Patch: https://git.openjdk.java.net/jdk/pull/367.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/367/head:pull/367

PR: https://git.openjdk.java.net/jdk/pull/367

From simonis at openjdk.java.net  Wed Oct 14 17:56:20 2020
From: simonis at openjdk.java.net (Volker Simonis)
Date: Wed, 14 Oct 2020 17:56:20 GMT
Subject: RFR: 8253952: Refine ZipOutputStream.putNextEntry() to
 recalculate ZipEntry's compressed size [v7]
In-Reply-To: <hvMgjRE6rX14SRWKGgkwGH1M09cvjmfRc5jPNbOdjmA=.1e8e86fe-795a-4c53-9be7-588ab61ca968@github.com>
References: <0nq5oFKOj6AZqCW6jF268-6oKRI6UkS6TRIHo-_5vKw=.d13c7016-4473-4b20-9117-100b368d3716@github.com>
 <8NaRPfinIcIKT6GlY1mqQxGj43ZwwRYp6LYns504BeU=.c52e1ecc-5442-41e3-9e88-1b0be10bdf11@github.com>
 <sCic9ba5qJiVFwMbxsGdQqlKDTLVdY9bRPCd8I3aCDU=.7662e600-fac2-4589-9276-6d006ca9bd0c@github.com>
 <hvMgjRE6rX14SRWKGgkwGH1M09cvjmfRc5jPNbOdjmA=.1e8e86fe-795a-4c53-9be7-588ab61ca968@github.com>
Message-ID: <Dc4ZRrb6HcxftN0_byFapQrNTeettij0EzxqRMbjscU=.7b59c976-c74a-402d-be5b-e86d3046ae71@github.com>

On Wed, 14 Oct 2020 16:31:32 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Mach5 run is clean :-)

Thanks a lot Lance.
Just waiting for the CSR to get approved now.

-------------

PR: https://git.openjdk.java.net/jdk/pull/520

From rriggs at openjdk.java.net  Wed Oct 14 18:02:21 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 14 Oct 2020 18:02:21 GMT
Subject: RFR: 8173585: Intrinsify StringLatin1.indexOf(char) [v6]
In-Reply-To: <UmWKeutVtUj7LngtfcEE5OecBuyx0A125H8DysqQaXQ=.574d0863-7045-4b07-b8bc-3fcc1074648b@github.com>
References: <_T0873dC5tfUtGn9r1_Y21JkPKRt-za3MM9hPN2GQKQ=.b865fe53-5417-424f-81b6-1566a330640e@github.com>
 <PuKDnAd5G6rpb3scQynqFMBf8zU37yVP_Qmp3SxmfyU=.06c27943-ea4d-4e3d-a4aa-a12a8033c35a@github.com>
 <RExrsR0klFewBYnIIuzvv5zcvtB_21lmxx149ZzsbUM=.4f1cabc8-52e3-4b5f-97c2-4c616e6892b6@github.com>
 <YyXLIYYqgJakyBBxzps3Pirezp7PtQ0deULmLks7PZk=.50536320-81a3-415d-9c23-bace488ee69f@github.com>
 <UmWKeutVtUj7LngtfcEE5OecBuyx0A125H8DysqQaXQ=.574d0863-7045-4b07-b8bc-3fcc1074648b@github.com>
Message-ID: <C0y8SClaKhPte8NRhWaeogWZf1MyX3TJ5o4A9j_7vFo=.29da6814-ac51-425a-94a4-e9b1b5c5c573@github.com>

On Wed, 14 Oct 2020 15:01:42 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Due to the requirement for multiple reviewers, I had been waiting to add my review of the Core-Libs files until the
>> HotSpot reviewers had approved!  I see only one reviewer credited in the commit.
>
> This integration without testing with a current merge from the master and has caused two build failures.
> 
> JDK-8254761: Wrong intrinsic annotation used for StringLatin1.indexOfChar
> 
> JDK-8254775: Microbenchmark StringIndexOfChar doesn't compile
> 
> There is a raw unicode character in the JMH test that causes a compilation error.
> == Output from failing command(s) repeated here ===
> [2020-10-14T14:39:09,608Z] * For target support_test_micro_classes__the.BUILD_JDK_MICROBENCHMARK_batch:
> [2020-10-14T14:39:09,611Z]
> /opt/mach5/mesos/work_dir/slaves/4076d11c-c6ed-4d07-84c1-4ab8d55cd975-S108796/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/400e1f56-2d49-42d8-8879-97d4fbb6c909/runs/c49da2bc-a8fe-4a5d-8159-57a9b0316fd2/workspace/open/test/micro/org/openjdk/bench/java/lang/StringIndexOfChar.java:71:
> error: unmappable character (0xE2) for encoding ascii [2020-10-14T14:39:09,611Z]
> sb.append(isUtf16?'???':'b'); [2020-10-14T14:39:09,611Z]                                ^ [2020-10-14T14:39:09,611Z]
> /opt/mach5/mesos/work_dir/slaves/4076d11c-c6ed-4d07-84c1-4ab8d55cd975-S108796/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/400e1f56-2d49-42d8-8879-97d4fbb6c909/runs/c49da2bc-a8fe-4a5d-8159-57a9b0316fd2/workspace/open/test/micro/org/openjdk/bench/java/lang/StringIndexOfChar.java:71:
> error: unmappable character (0x98) for encoding ascii [2020-10-14T14:39:09,611Z]
> sb.append(isUtf16?'???':'b'); [2020-10-14T14:39:09,611Z]                                 ^ [2020-10-14T14:39:09,611Z]
> /opt/mach5/mesos/work_dir/slaves/4076d11c-c6ed-4d07-84c1-4ab8d55cd975-S108796/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/400e1f56-2d49-42d8-8879-97d4fbb6c909/runs/c49da2bc-a8fe-4a5d-8159-57a9b0316fd2/workspace/open/test/micro/org/openjdk/bench/java/lang/StringIndexOfChar.java:71:
> error: unmappable character (0xBA) for encoding ascii [2020-10-14T14:39:09,611Z]
> sb.append(isUtf16?'???':'b'); [2020-10-14T14:39:09,611Z]                                  ^ [2020-10-14T14:39:09,611Z]
> /opt/mach5/mesos/work_dir/slaves/4076d11c-c6ed-4d07-84c1-4ab8d55cd975-S108796/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/400e1f56-2d49-42d8-8879-97d4fbb6c909/runs/c49da2bc-a8fe-4a5d-8159-57a9b0316fd2/workspace/open/test/micro/org/openjdk/bench/java/lang/StringIndexOfChar.java:71:
> error: unclosed character literal [2020-10-14T14:39:09,611Z]             sb.append(isUtf16?'???':'b');
> [2020-10-14T14:39:09,611Z]                               ^ [2020-10-14T14:39:09,611Z]
> /opt/mach5/mesos/work_dir/slaves/4076d11c-c6ed-4d07-84c1-4ab8d55cd975-S108796/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/400e1f56-2d49-42d8-8879-97d4fbb6c909/runs/c49da2bc-a8fe-4a5d-8159-57a9b0316fd2/workspace/open/test/micro/org/openjdk/bench/java/lang/StringIndexOfChar.java:71:
> error: unclosed character literal [2020-10-14T14:39:09,611Z]             sb.append(isUtf16?'???':'b');```

And also a failed Graal test because of the new intrinsic.

And JDK-8254785: compiler/graalunit/HotspotTest.java failed with "missing Graal intrinsics for:
java/lang/StringLatin1.indexOfChar([BIII)I"

@phohensee don't be so quick to type `/sponsor`; there are three separate build and test failures.

-------------

PR: https://git.openjdk.java.net/jdk/pull/71

From mchung at openjdk.java.net  Wed Oct 14 18:12:10 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 14 Oct 2020 18:12:10 GMT
Subject: RFR: 8188055: (ref) Add Reference::refersTo predicate [v3]
In-Reply-To: <mkn_t3hsL4mlCOfO5ahZOMbp8i_LMOHwJALA_bNjHIk=.d8031a91-ed13-4882-925f-ea8a9e634198@github.com>
References: <D4HSg8FT20Eaxk5KJkkw0GgETSxRkBn1ipS3Dt0kPto=.e4bab078-2e04-4413-90cb-9bfafb2a6831@github.com>
 <Y1IHoNr8vO3OkCbEKw6ywXd4adik1yKKNIS4ABzF0d0=.d21f4183-ef4e-45ed-826d-6613215b6220@github.com>
 <9x0zaxknpYXGIvHun1CkLP0lEC8NQmPTnANxQKjhHF8=.907bdb15-2e2e-4f84-8fe4-ea4ed50534cd@github.com>
 <DR2YKv3VavKKD-cpFyf6mCSYfaKq0KAGh2XDqBStkys=.895ba671-f63a-4ba3-b042-6568d647b4ab@github.com>
 <mkn_t3hsL4mlCOfO5ahZOMbp8i_LMOHwJALA_bNjHIk=.d8031a91-ed13-4882-925f-ea8a9e634198@github.com>
Message-ID: <3JzF7OkemZ-Lxc4jZgdEh3qNDzW8wF7ITeq-s7_TOlo=.11e4e40b-b775-47cf-9862-735fbc61ffd3@github.com>

On Tue, 13 Oct 2020 08:49:23 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> @dfuch I would expect the users of `refersTo` should know the type of the referent to be compared, i.e. it should know
>> the parameter type of a Reference object.   Do you have any specific use case in mind that you have a `Reference<?>
>> ref` but wants to compare a referent of unknown type?
>
> @mlchung  I have often used a `Reference<?>` in tests - but my main usage there would be to call `ref.refersTo(null)`
> which works in all cases. My main concern here however is that using `T` in `refersTo` seems to go against the
> advertised usage of the method - I mean - if I have an object `obj` of type unknown, I can always do `obj == ref.get()`
> whatever the parameter type of `ref` is. But I won't be able to call `ref.refersTo(obj)` unless I use raw types and
> suppress warnings. So I just wanted to check that this was intentional.

For the common cases, the application should know the type of the referent and using `T` in `refersTo` will benefit
from the compiler type checking.   For the unknown type case, cast to `Reference<Object>` is not ideal but reasonable?
something like this:

Reference<Object> r = (Reference<Object>) ref;
r.refersTo(obj);

-------------

PR: https://git.openjdk.java.net/jdk/pull/498

From dfuchs at openjdk.java.net  Wed Oct 14 18:18:18 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 14 Oct 2020 18:18:18 GMT
Subject: RFR: 8188055: (ref) Add Reference::refersTo predicate [v3]
In-Reply-To: <3JzF7OkemZ-Lxc4jZgdEh3qNDzW8wF7ITeq-s7_TOlo=.11e4e40b-b775-47cf-9862-735fbc61ffd3@github.com>
References: <D4HSg8FT20Eaxk5KJkkw0GgETSxRkBn1ipS3Dt0kPto=.e4bab078-2e04-4413-90cb-9bfafb2a6831@github.com>
 <Y1IHoNr8vO3OkCbEKw6ywXd4adik1yKKNIS4ABzF0d0=.d21f4183-ef4e-45ed-826d-6613215b6220@github.com>
 <9x0zaxknpYXGIvHun1CkLP0lEC8NQmPTnANxQKjhHF8=.907bdb15-2e2e-4f84-8fe4-ea4ed50534cd@github.com>
 <DR2YKv3VavKKD-cpFyf6mCSYfaKq0KAGh2XDqBStkys=.895ba671-f63a-4ba3-b042-6568d647b4ab@github.com>
 <mkn_t3hsL4mlCOfO5ahZOMbp8i_LMOHwJALA_bNjHIk=.d8031a91-ed13-4882-925f-ea8a9e634198@github.com>
 <3JzF7OkemZ-Lxc4jZgdEh3qNDzW8wF7ITeq-s7_TOlo=.11e4e40b-b775-47cf-9862-735fbc61ffd3@github.com>
Message-ID: <iPK64Jh4aJtfqoPDqADOBN8BczKet53bod5y_VjZoBw=.fed662e8-2b40-478b-a9de-4906c0a897dc@github.com>

On Wed, 14 Oct 2020 18:09:16 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> @mlchung  I have often used a `Reference<?>` in tests - but my main usage there would be to call `ref.refersTo(null)`
>> which works in all cases. My main concern here however is that using `T` in `refersTo` seems to go against the
>> advertised usage of the method - I mean - if I have an object `obj` of type unknown, I can always do `obj == ref.get()`
>> whatever the parameter type of `ref` is. But I won't be able to call `ref.refersTo(obj)` unless I use raw types and
>> suppress warnings. So I just wanted to check that this was intentional.
>
> For the common cases, the application should know the type of the referent and using `T` in `refersTo` will benefit
> from the compiler type checking.   For the unknown type case, cast to `Reference<Object>` is not ideal but reasonable?
> something like this:  Reference<Object> r = (Reference<Object>) ref;
> r.refersTo(obj);

That sounds reasonable to me. Thanks for looking into it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/498

From smarks at openjdk.java.net  Wed Oct 14 18:19:14 2020
From: smarks at openjdk.java.net (Stuart Marks)
Date: Wed, 14 Oct 2020 18:19:14 GMT
Subject: RFR: 8254161: Prevent instantiation of EnumSet subclasses through
 deserialization
In-Reply-To: <etFbiCFeHwDnYXo3yzhQT66jXhSMbRn57DEGZz-d3V8=.55b262dd-27a1-48c2-ae9b-ce6a55f45b53@github.com>
References: <etFbiCFeHwDnYXo3yzhQT66jXhSMbRn57DEGZz-d3V8=.55b262dd-27a1-48c2-ae9b-ce6a55f45b53@github.com>
Message-ID: <hxRgTvwTSBIaHyl-kMIL4WrR8ZdwejTRLNRosZcCNas=.9f835271-a712-42ce-8d9f-4eeb4ff8d13d@github.com>

On Mon, 12 Oct 2020 13:47:46 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

> TL;DR add EnumSet::readObjectNoData()
> 
> EnumSet is an exemplar of the Serialization Proxy Pattern. As such, it
> should strictly implement that pattern and demonstrate how best to
> defend against inappropriate instantiation through deserialization.
> 
> EnumSet is an extensible class. There are two subclasses in the JDK,
> RegularEnumSet and JumboEnumSet. Since the serialization of an EnumSet
> object writes a replacement object to the serial stream, a serial proxy
> object, then stream objects of type RegularEnumSet or JumboEnumSet are
> not expected in the serial stream. However, if they are present in the
> serial stream, then, during deserialization, the EnumSet::readObject
> method will be invoked. EnumSet::readObject unconditionally throws an
> exception, thus preventing further deserialization of the stream object.
> In this way, stream objects that are subclasses of EnumSet are prevented
> from being instantiated through deserialization. But this is not
> sufficient to prevent such in all scenarios.
> 
> A stream object whose local class equivalent of the specified stream
> class descriptor is a subclasses of EnumSet, but whose specified stream
> class descriptor does not list EnumSet as a superClass, may be
> instantiated through deserialization. Since the stream class descriptor
> does not list EnumSet as a superclass, then the defensive
> EnumSet::readObject is never invoked. To prevent such objects from
> being deserialized, an EnumSet::readObjectNoData() should be added -
> whose implementation unconditionally throws an exception, similar to
> that of the existing EnumSet::readObject.

Marked as reviewed by smarks (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/611

From igraves at openjdk.java.net  Wed Oct 14 18:39:31 2020
From: igraves at openjdk.java.net (Ian Graves)
Date: Wed, 14 Oct 2020 18:39:31 GMT
Subject: RFR: 8253459: Formatter treats index,
 width and precision > Integer.MAX_VALUE incorrectly [v4]
In-Reply-To: <3aYgWcp1IVMM0vQT5UMLSnc2JA1uK9cbtRe283RF37g=.fc2049ef-cdbe-4948-a24b-fdb88cc87a1c@github.com>
References: <3aYgWcp1IVMM0vQT5UMLSnc2JA1uK9cbtRe283RF37g=.fc2049ef-cdbe-4948-a24b-fdb88cc87a1c@github.com>
Message-ID: <UNDO-R_iCPXgjeKbwAvP5iCISCW0vJs710ISp768TT0=.3ebec6f4-b6ae-45fa-b6f5-318aa05a5dca@github.com>

> The `java.util.Formatter` format specifies support for field widths, argument indexes, or precision lengths of a field
> that relate to the variadic arguments supplied to the formatter. These numbers are specified by integers, sometimes
> negative. For argument index, it's specified in the documentation that the highest allowed argument is limited by the
> largest possible index of an array (ie the largest possible variadic index), but for the other two it's not defined.
> Moreover, what happens when a number field in a string is too large or too small to be represented by a 32-bit integer
> type is not defined.  This fix adds documentation to specify what error behavior occurs during these cases.
> Additionally it adds an additional exception type to throw when an invalid argument index is observed.  A CSR will be
> required for this PR.

Ian Graves has updated the pull request incrementally with one additional commit since the last revision:

  Tweaking verbiage

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/516/files
  - new: https://git.openjdk.java.net/jdk/pull/516/files/391449a8..9b07ef33

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=516&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=516&range=02-03

  Stats: 18 lines in 2 files changed: 0 ins; 5 del; 13 mod
  Patch: https://git.openjdk.java.net/jdk/pull/516.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/516/head:pull/516

PR: https://git.openjdk.java.net/jdk/pull/516

From rriggs at openjdk.java.net  Wed Oct 14 19:12:37 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 14 Oct 2020 19:12:37 GMT
Subject: RFR: 8251989: Hex formatting and parsing utility [v3]
In-Reply-To: <HSEn47GMS1K3g57mrTZeQk-WZHl3pKGHpX_OOf8VnsU=.740863c2-f9e4-43c4-b500-614aab4078b1@github.com>
References: <HSEn47GMS1K3g57mrTZeQk-WZHl3pKGHpX_OOf8VnsU=.740863c2-f9e4-43c4-b500-614aab4078b1@github.com>
Message-ID: <RBOpBD73GYZMCKkIq4meErFeNil87on2HoJ2vqKIQJ4=.ddd442c0-ad34-4167-a49c-6ae7a0f6b9fc@github.com>

> java.util.HexFormat utility:
> 
>  - Format and parse hexadecimal strings, with parameters for delimiter, prefix, suffix and upper/lowercase
>  - Static factories and builder methods to create HexFormat copies with modified parameters.
>  - Consistent naming of methods for conversion of byte arrays to formatted strings and back: formatHex and parseHex
>  - Consistent naming of methods for conversion of primitive types: toHexDigits... and fromHexDigits...
>  - Prefix and suffixes now apply to each formatted value, not the string as a whole
>  - Using java.util.Appendable as a target for buffered conversions so output to Writers and PrintStreams
>    like System.out are supported in addition to StringBuilder. (IOExceptions are converted to unchecked exceptions)
>  - Immutable and thread safe, a "value-based" class
> 
> See the [HexFormat
> javadoc](http://cr.openjdk.java.net/~rriggs/8251989-hex-formatter/java.base/java/util/HexFormat.html) for details.
> Review comments and suggestions welcome.

Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev
excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since
the last revision:

 - Added assertions to testVariableLength and samples
 - Merge branch 'master' into 8251989-hex-formatter
 - temp updates
 - Various code review comments, rename UpperCase and LowerCase methods to match Character, remove unnecessary Class name
   qualifications, etc.
 - 8251989: Hex formatting and parsing utility

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/482/files
  - new: https://git.openjdk.java.net/jdk/pull/482/files/3170b498..ec334dbc

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=482&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=482&range=01-02

  Stats: 39353 lines in 906 files changed: 21925 ins; 9958 del; 7470 mod
  Patch: https://git.openjdk.java.net/jdk/pull/482.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/482/head:pull/482

PR: https://git.openjdk.java.net/jdk/pull/482

From rriggs at openjdk.java.net  Wed Oct 14 19:17:25 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 14 Oct 2020 19:17:25 GMT
Subject: RFR: 8188055: (ref) Add Reference::refersTo predicate [v3]
In-Reply-To: <J-8wUT_ItffnPBtGCcJVokoBDDL5jOVG9COuoMIrVh8=.296b587b-0b4b-48ca-bc9a-dffb7eaa948a@github.com>
References: <D4HSg8FT20Eaxk5KJkkw0GgETSxRkBn1ipS3Dt0kPto=.e4bab078-2e04-4413-90cb-9bfafb2a6831@github.com>
 <J-8wUT_ItffnPBtGCcJVokoBDDL5jOVG9COuoMIrVh8=.296b587b-0b4b-48ca-bc9a-dffb7eaa948a@github.com>
Message-ID: <-ywxpD3jT3f8GLY0jXPUjg7sDxQYHhdRm0xNTxCCFek=.e2be6fe5-942f-4b4f-bb49-e3b07f1c32c8@github.com>

On Wed, 14 Oct 2020 04:27:34 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Finally returning to this review that was started in April 2020.  I've
>> recast it as a github PR.  I think the security concern raised by Gil
>> has been adequately answered.
>> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-April/029203.html
>> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-July/030401.html
>> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-August/030677.html
>> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-September/030793.html
>> 
>> Please review a new function: java.lang.ref.Reference.refersTo.
>> 
>> This function is needed to test the referent of a Reference object without
>> artificially extending the lifetime of the referent object, as may happen
>> when calling Reference.get.  Some garbage collectors require extending the
>> lifetime of a weak referent when accessed, in order to maintain collector
>> invariants.  Lifetime extension may occur with any collector when the
>> Reference is a SoftReference, as calling get indicates recent access.  This
>> new function also allows testing the referent of a PhantomReference, which
>> can't be accessed by calling get.
>> 
>> The new function uses native methods whose implementations are in the VM so
>> they can use the Access API.  It is the intent that these methods will be
>> intrinsified by optimizing compilers like C2 or graal, but that hasn't been
>> implemented yet.  Bear that in mind before rushing off to change existing
>> uses of Reference.get.
>> 
>> There are two native methods involved, one in Reference and an override in
>> PhantomReference, both package private in java.lang.ref. The reason for this
>> split is to simplify the intrinsification. This is a change from the version
>> from April 2020; that version had a single native method in Reference,
>> implemented using the ON_UNKNOWN_OOP_REF Access reference strength category.
>> However, adding support for that category in the compilers adds significant
>> implementation effort and complexity. Splitting avoids that complexity.
>> 
>> Testing:
>> mach5 tier1
>> Locally (linux-x64) verified the new test passes with various garbage collectors.
>
> Kim Barrett has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - simplify test
>  - cleanup nits from Mandy
>  - use Object instead of TestObject

Marked as reviewed by rriggs (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/498

From rriggs at openjdk.java.net  Wed Oct 14 19:18:22 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 14 Oct 2020 19:18:22 GMT
Subject: RFR: 8251989: Hex formatting and parsing utility [v2]
In-Reply-To: <trzkq95ap3yXCanC3th2_SXSu0D55XgPis_dcHNFLJo=.c0b229a2-b4c8-4f0c-ba7c-3efe4ead8abe@github.com>
References: <HSEn47GMS1K3g57mrTZeQk-WZHl3pKGHpX_OOf8VnsU=.740863c2-f9e4-43c4-b500-614aab4078b1@github.com>
 <Op6a9I7ariq5HWMwVGp_58VyMpElYx41ACVJXc3UdXc=.2faa2c38-503f-4236-9d5c-7afb3ba3f0ef@github.com>
 <trzkq95ap3yXCanC3th2_SXSu0D55XgPis_dcHNFLJo=.c0b229a2-b4c8-4f0c-ba7c-3efe4ead8abe@github.com>
Message-ID: <NR8uNaNxPMoq76JDbFhTJX-4qymwpe8Eeu7oPlmWi0U=.634a8753-6a61-40db-84ea-3c5cece42128@github.com>

On Tue, 13 Oct 2020 21:56:31 GMT, Marcono1234 <github.com+11685886+Marcono1234 at openjdk.org> wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Various code review comments, rename UpperCase and LowerCase methods to match Character, remove unnecessary Class name
>>   qualifications, etc.
>
> test/jdk/java/util/HexFormat/HexFormatTest.java line 383:
> 
>> 381:
>> 382:     @Test
>> 383:     static void testVariableLength() {
> 
> This test does not contain any assertions.

Added missing assertions.

-------------

PR: https://git.openjdk.java.net/jdk/pull/482

From psandoz at openjdk.java.net  Wed Oct 14 20:06:30 2020
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Wed, 14 Oct 2020 20:06:30 GMT
Subject: Integrated: 8223347: Integration of Vector API (Incubator)
In-Reply-To: <-PE4TwXgvq2bemAn_8csjn4_j7zoAolnQz6QQt3z0Wk=.eaa9999f-0713-4349-b31d-934717aa37a1@github.com>
References: <-PE4TwXgvq2bemAn_8csjn4_j7zoAolnQz6QQt3z0Wk=.eaa9999f-0713-4349-b31d-934717aa37a1@github.com>
Message-ID: <JfEs-76_XJfcwM-1WL_wjx-qw1tVC0NS_BY-jN4GS4g=.6b434176-c077-42f9-b529-c7013b032606@github.com>

On Fri, 25 Sep 2020 20:14:29 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> This pull request is for integration of the Vector API. It was previously reviewed under conditions when mercurial was
> used for the source code control system. Review threads can be found here (searching for issue number 8223347 in the
> title):  https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-April/thread.html
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-May/thread.html
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-July/thread.html
> 
> If mercurial was still being used the code would be pushed directly, once the CSR is approved. However, in this case a
> pull request is required and needs explicit reviewer approval. Between the final review and this pull request no code
> has changed, except for that related to merging.

This pull request has now been integrated.

Changeset: 0c99b192
Author:    Paul Sandoz <psandoz at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/0c99b192
Stats:     295107 lines in 336 files changed: 292957 ins; 1062 del; 1088 mod

8223347: Integration of Vector API (Incubator)

Co-authored-by: Vivek Deshpande <vdeshpande at openjdk.org>
Co-authored-by: Qi Feng <qfeng at openjdk.org>
Co-authored-by: Ian Graves <igraves at openjdk.org>
Co-authored-by: Jean-Philippe Halimi <jphalimi at openjdk.org>
Co-authored-by: Vladimir Ivanov <vlivanov at openjdk.org>
Co-authored-by: Ningsheng Jian <njian at openjdk.org>
Co-authored-by: Razvan Lupusoru <rlupusoru at openjdk.org>
Co-authored-by: Smita Kamath <svkamath at openjdk.org>
Co-authored-by: Rahul Kandu <rkandu at openjdk.org>
Co-authored-by: Kishor Kharbas <kkharbas at openjdk.org>
Co-authored-by: Eric Liu <Eric.Liu2 at arm.com>
Co-authored-by: Aaloan Miftah <someusername3 at gmail.com>
Co-authored-by: John R Rose <jrose at openjdk.org>
Co-authored-by: Shravya Rukmannagari <srukmannagar at openjdk.org>
Co-authored-by: Paul Sandoz <psandoz at openjdk.org>
Co-authored-by: Sandhya Viswanathan <sviswanathan at openjdk.org>
Co-authored-by: Lauren Walkowski <lauren.walkowski at arm.com>
Co-authored-by: Yang Zang <Yang.Zhang at arm.com>
Co-authored-by: Joshua Zhu <jzhu at openjdk.org>
Co-authored-by: Wang Zhuo <wzhuo at openjdk.org>
Co-authored-by: Jatin Bhateja <jbhateja at openjdk.org>
Reviewed-by: erikj, chegar, kvn, darcy, forax, briangoetz, aph, epavlova, coleenp

-------------

PR: https://git.openjdk.java.net/jdk/pull/367

From rrich at openjdk.java.net  Wed Oct 14 20:53:15 2020
From: rrich at openjdk.java.net (Richard Reingruber)
Date: Wed, 14 Oct 2020 20:53:15 GMT
Subject: RFR: 8227745: Enable Escape Analysis for Better Performance in
 the Presence of JVMTI Agents [v10]
In-Reply-To: <buqJ9cqD9APRW862aGoAk9IyvYvshoItGVRgeNqQTds=.4fc25be1-3e79-4ac8-a174-0e08cdc9fc10@github.com>
References: <Ll2RereRbuQLgFtIjv9pS92kPvCVuo-BI0cP1zGjVbo=.dad3a33c-0fc3-44fd-810a-f01448cf564c@github.com>
 <XaPrmpfi96mMRQnto6zzZlsZeDP0jMR7LAosjDmm0Zw=.12c89fb1-a267-468b-966b-065f97aa2f28@github.com>
 <buqJ9cqD9APRW862aGoAk9IyvYvshoItGVRgeNqQTds=.4fc25be1-3e79-4ac8-a174-0e08cdc9fc10@github.com>
Message-ID: <PrlpMaxn0QM4FaL46JOMJQ_kyHQb7Qc6wOvY48BXrG0=.c813267c-53e9-486c-ade2-8017d820c579@github.com>

On Wed, 14 Oct 2020 00:25:14 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> 
> 
> Good.

Thanks for the review, Vladimir (@vnkozlov)!
I'm still (stress) testing adaptations to lazy/concurrent thread stack processing for ZGC.
--Richard.

-------------

PR: https://git.openjdk.java.net/jdk/pull/119

From dcubed at openjdk.java.net  Wed Oct 14 20:55:17 2020
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 14 Oct 2020 20:55:17 GMT
Subject: RFR: 8173585: Intrinsify StringLatin1.indexOf(char) [v6]
In-Reply-To: <C0y8SClaKhPte8NRhWaeogWZf1MyX3TJ5o4A9j_7vFo=.29da6814-ac51-425a-94a4-e9b1b5c5c573@github.com>
References: <_T0873dC5tfUtGn9r1_Y21JkPKRt-za3MM9hPN2GQKQ=.b865fe53-5417-424f-81b6-1566a330640e@github.com>
 <PuKDnAd5G6rpb3scQynqFMBf8zU37yVP_Qmp3SxmfyU=.06c27943-ea4d-4e3d-a4aa-a12a8033c35a@github.com>
 <RExrsR0klFewBYnIIuzvv5zcvtB_21lmxx149ZzsbUM=.4f1cabc8-52e3-4b5f-97c2-4c616e6892b6@github.com>
 <YyXLIYYqgJakyBBxzps3Pirezp7PtQ0deULmLks7PZk=.50536320-81a3-415d-9c23-bace488ee69f@github.com>
 <UmWKeutVtUj7LngtfcEE5OecBuyx0A125H8DysqQaXQ=.574d0863-7045-4b07-b8bc-3fcc1074648b@github.com>
 <C0y8SClaKhPte8NRhWaeogWZf1MyX3TJ5o4A9j_7vFo=.29da6814-ac51-425a-94a4-e9b1b5c5c573@github.com>
Message-ID: <R58U2HB1BgeSZdsyXhKSta4kYLTWp07e2Ay3RQ9zYbk=.2c168c7d-d25f-4154-89f2-b6ee8240fcf5@github.com>

On Wed, 14 Oct 2020 17:59:53 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> This integration without testing with a current merge from the master and has caused two build failures.
>> 
>> JDK-8254761: Wrong intrinsic annotation used for StringLatin1.indexOfChar
>> 
>> JDK-8254775: Microbenchmark StringIndexOfChar doesn't compile
>> 
>> There is a raw unicode character in the JMH test that causes a compilation error.
>> == Output from failing command(s) repeated here ===
>> [2020-10-14T14:39:09,608Z] * For target support_test_micro_classes__the.BUILD_JDK_MICROBENCHMARK_batch:
>> [2020-10-14T14:39:09,611Z]
>> /opt/mach5/mesos/work_dir/slaves/4076d11c-c6ed-4d07-84c1-4ab8d55cd975-S108796/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/400e1f56-2d49-42d8-8879-97d4fbb6c909/runs/c49da2bc-a8fe-4a5d-8159-57a9b0316fd2/workspace/open/test/micro/org/openjdk/bench/java/lang/StringIndexOfChar.java:71:
>> error: unmappable character (0xE2) for encoding ascii [2020-10-14T14:39:09,611Z]
>> sb.append(isUtf16?'???':'b'); [2020-10-14T14:39:09,611Z]                                ^ [2020-10-14T14:39:09,611Z]
>> /opt/mach5/mesos/work_dir/slaves/4076d11c-c6ed-4d07-84c1-4ab8d55cd975-S108796/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/400e1f56-2d49-42d8-8879-97d4fbb6c909/runs/c49da2bc-a8fe-4a5d-8159-57a9b0316fd2/workspace/open/test/micro/org/openjdk/bench/java/lang/StringIndexOfChar.java:71:
>> error: unmappable character (0x98) for encoding ascii [2020-10-14T14:39:09,611Z]
>> sb.append(isUtf16?'???':'b'); [2020-10-14T14:39:09,611Z]                                 ^ [2020-10-14T14:39:09,611Z]
>> /opt/mach5/mesos/work_dir/slaves/4076d11c-c6ed-4d07-84c1-4ab8d55cd975-S108796/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/400e1f56-2d49-42d8-8879-97d4fbb6c909/runs/c49da2bc-a8fe-4a5d-8159-57a9b0316fd2/workspace/open/test/micro/org/openjdk/bench/java/lang/StringIndexOfChar.java:71:
>> error: unmappable character (0xBA) for encoding ascii [2020-10-14T14:39:09,611Z]
>> sb.append(isUtf16?'???':'b'); [2020-10-14T14:39:09,611Z]                                  ^ [2020-10-14T14:39:09,611Z]
>> /opt/mach5/mesos/work_dir/slaves/4076d11c-c6ed-4d07-84c1-4ab8d55cd975-S108796/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/400e1f56-2d49-42d8-8879-97d4fbb6c909/runs/c49da2bc-a8fe-4a5d-8159-57a9b0316fd2/workspace/open/test/micro/org/openjdk/bench/java/lang/StringIndexOfChar.java:71:
>> error: unclosed character literal [2020-10-14T14:39:09,611Z]             sb.append(isUtf16?'???':'b');
>> [2020-10-14T14:39:09,611Z]                               ^ [2020-10-14T14:39:09,611Z]
>> /opt/mach5/mesos/work_dir/slaves/4076d11c-c6ed-4d07-84c1-4ab8d55cd975-S108796/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/400e1f56-2d49-42d8-8879-97d4fbb6c909/runs/c49da2bc-a8fe-4a5d-8159-57a9b0316fd2/workspace/open/test/micro/org/openjdk/bench/java/lang/StringIndexOfChar.java:71:
>> error: unclosed character literal [2020-10-14T14:39:09,611Z]             sb.append(isUtf16?'???':'b');```
>
> And also a failed Graal test because of the new intrinsic.
> 
> And JDK-8254785: compiler/graalunit/HotspotTest.java failed with "missing Graal intrinsics for:
> java/lang/StringLatin1.indexOfChar([BIII)I"
> @phohensee don't be so quick to type `/sponsor`; there are three separate build and test failures.

@phohensee - @vnkozlov has determined that a new Tier2 test failure is
also caused by this fix. See https://bugs.openjdk.java.net/browse/JDK-8254790.

-------------

PR: https://git.openjdk.java.net/jdk/pull/71

From hohensee at amazon.com  Wed Oct 14 21:28:09 2020
From: hohensee at amazon.com (Hohensee, Paul)
Date: Wed, 14 Oct 2020 21:28:09 +0000
Subject: RFR: 8173585: Intrinsify StringLatin1.indexOf(char) [v6]
Message-ID: <838553DC-4961-4681-990E-4254D3316538@amazon.com>

My apologies. I relied on the other reviewers. I'll do an independent review in the future.

Thanks,
Paul

?On 10/14/20, 11:02 AM, "core-libs-dev on behalf of Roger Riggs" <core-libs-dev-retn at openjdk.java.net on behalf of rriggs at openjdk.java.net> wrote:

    On Wed, 14 Oct 2020 15:01:42 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

    >> Due to the requirement for multiple reviewers, I had been waiting to add my review of the Core-Libs files until the
    >> HotSpot reviewers had approved!  I see only one reviewer credited in the commit.
    >
    > This integration without testing with a current merge from the master and has caused two build failures.
    >
    > JDK-8254761: Wrong intrinsic annotation used for StringLatin1.indexOfChar
    >
    > JDK-8254775: Microbenchmark StringIndexOfChar doesn't compile
    >
    > There is a raw unicode character in the JMH test that causes a compilation error.
    > == Output from failing command(s) repeated here ===
    > [2020-10-14T14:39:09,608Z] * For target support_test_micro_classes__the.BUILD_JDK_MICROBENCHMARK_batch:
    > [2020-10-14T14:39:09,611Z]
    > /opt/mach5/mesos/work_dir/slaves/4076d11c-c6ed-4d07-84c1-4ab8d55cd975-S108796/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/400e1f56-2d49-42d8-8879-97d4fbb6c909/runs/c49da2bc-a8fe-4a5d-8159-57a9b0316fd2/workspace/open/test/micro/org/openjdk/bench/java/lang/StringIndexOfChar.java:71:
    > error: unmappable character (0xE2) for encoding ascii [2020-10-14T14:39:09,611Z]
    > sb.append(isUtf16?'???':'b'); [2020-10-14T14:39:09,611Z]                                ^ [2020-10-14T14:39:09,611Z]
    > /opt/mach5/mesos/work_dir/slaves/4076d11c-c6ed-4d07-84c1-4ab8d55cd975-S108796/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/400e1f56-2d49-42d8-8879-97d4fbb6c909/runs/c49da2bc-a8fe-4a5d-8159-57a9b0316fd2/workspace/open/test/micro/org/openjdk/bench/java/lang/StringIndexOfChar.java:71:
    > error: unmappable character (0x98) for encoding ascii [2020-10-14T14:39:09,611Z]
    > sb.append(isUtf16?'???':'b'); [2020-10-14T14:39:09,611Z]                                 ^ [2020-10-14T14:39:09,611Z]
    > /opt/mach5/mesos/work_dir/slaves/4076d11c-c6ed-4d07-84c1-4ab8d55cd975-S108796/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/400e1f56-2d49-42d8-8879-97d4fbb6c909/runs/c49da2bc-a8fe-4a5d-8159-57a9b0316fd2/workspace/open/test/micro/org/openjdk/bench/java/lang/StringIndexOfChar.java:71:
    > error: unmappable character (0xBA) for encoding ascii [2020-10-14T14:39:09,611Z]
    > sb.append(isUtf16?'???':'b'); [2020-10-14T14:39:09,611Z]                                  ^ [2020-10-14T14:39:09,611Z]
    > /opt/mach5/mesos/work_dir/slaves/4076d11c-c6ed-4d07-84c1-4ab8d55cd975-S108796/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/400e1f56-2d49-42d8-8879-97d4fbb6c909/runs/c49da2bc-a8fe-4a5d-8159-57a9b0316fd2/workspace/open/test/micro/org/openjdk/bench/java/lang/StringIndexOfChar.java:71:
    > error: unclosed character literal [2020-10-14T14:39:09,611Z]             sb.append(isUtf16?'???':'b');
    > [2020-10-14T14:39:09,611Z]                               ^ [2020-10-14T14:39:09,611Z]
    > /opt/mach5/mesos/work_dir/slaves/4076d11c-c6ed-4d07-84c1-4ab8d55cd975-S108796/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/400e1f56-2d49-42d8-8879-97d4fbb6c909/runs/c49da2bc-a8fe-4a5d-8159-57a9b0316fd2/workspace/open/test/micro/org/openjdk/bench/java/lang/StringIndexOfChar.java:71:
    > error: unclosed character literal [2020-10-14T14:39:09,611Z]             sb.append(isUtf16?'???':'b');```

    And also a failed Graal test because of the new intrinsic.

    And JDK-8254785: compiler/graalunit/HotspotTest.java failed with "missing Graal intrinsics for:
    java/lang/StringLatin1.indexOfChar([BIII)I"

    @phohensee don't be so quick to type `/sponsor`; there are three separate build and test failures.

    -------------

    PR: https://git.openjdk.java.net/jdk/pull/71


From github.com+51754783+coreyashford at openjdk.java.net  Wed Oct 14 21:33:15 2020
From: github.com+51754783+coreyashford at openjdk.java.net (CoreyAshford)
Date: Wed, 14 Oct 2020 21:33:15 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v4]
In-Reply-To: <jqzI94j7kygJyD9HWwq5d3q3LGztS5FAdYm5Ix1QdjE=.808de4e6-0f6d-4e17-b807-25ef89e92541@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <45FtTQB1m6HyZSASY42STMkQffIWlVPibWn9_r00xYs=.daad2653-2571-491f-8dd7-5954fe4ece00@github.com>
 <u6HLR2PyvWgYbA58W3bCF4n38tpwQu2-ujPMvGpyyuo=.5a80f17c-83d5-4dc9-bad0-00e679fdd4be@github.com>
 <7-p-Kc9lQyyuoWdNtmgbXbwkxsgk4oQGKmFSCcMpvnU=.97810c01-3200-4767-bbd4-35d53c2bc5ca@github.com>
 <6Voyfr_s-ieyRA-8Rtvvpz7tkhhicA8sY2d2KTp3Kmw=.fa256bae-2143-4b43-bfea-5837ad31eb6a@github.com>
 <fFQfDMqdwosVGzcaJfblklUy1nPsEdZJI7ALmKq9XJs=.e869160e-76e7-4a6b-b45b-e9763d1ad06f@github.com>
 <vKcE4CeascBAQGeyu6is0Va0_k4aTrvgU41cjhG6Wdo=.4078814f-06ed-4978-9fcd-a4a5148c2bdc@github.com>
 <wQ6YtDhYzmcgpTUP4uFfBCo8UFWZENtTARWt_LTqPug=.30bc3fdb-f963-4918-ae4b-0fe174c38a23@github.com>
 <jqzI94j7kygJyD9HWwq5d3q3LGztS5FAdYm5Ix1QdjE=.808de4e6-0f6d-4e17-b807-25ef89e92541@github.com>
Message-ID: <7XjzEn5DggliDrvjhrGwXZL5r4lsqeGF9SGLmRr5L84=.a4481a62-4ecf-4e3f-98f3-70e548c67b52@github.com>

On Wed, 14 Oct 2020 10:29:40 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Hi Corey,
> Are you thinking of a case where that produces a higher iteration count?
> Sorry for the confusion. This is also fine: length = sl - sp - 12 i = length / block_size if (i <= 0) return 0 But I
> still wonder why we should use 2 branches. Why not srawi_ ble(CCR0, return_zero) ?

You're right!  I originally thought that the `srawi.` was setting only the Zero bit, but it sets others as well.

> Ah, I should have checked the calling conventions. I thought all of the CR* regs are volatile. I will fix that.
> Actually, we do save and restore all CRs, so it?s not a real problem with the current implementation. But I prefer
> staying closer to the elf ABI as long as there?s no good reason to do it differently.

Looks like I don't need that code at all now, but it's good to know for the future; I have an encode intrinsic in the
works.

> Your original comment said "2nd review", so I thought you meant you need to review it again after the changes.
> We usually require at least 2 reviews by different people for all non-trivial changes. And I don?t consider the PPC64
> part as trivial. In addition to that, I?m not familiar with Power 10.

I received permission to request help from the GNU toolchain team here to review it.  Due to family issues and work
schedule on my end, it will be at least the middle of next week before I can get a reviewer to have a look.

Thanks for your continued patience and help.

-------------

PR: https://git.openjdk.java.net/jdk/pull/293

From minqi at openjdk.java.net  Wed Oct 14 22:18:17 2020
From: minqi at openjdk.java.net (Yumin Qi)
Date: Wed, 14 Oct 2020 22:18:17 GMT
Subject: RFR: 8254192: ExtraSharedClassListFile contains extra white space at
 end of line
Message-ID: <0LTIfmJUJ1A68tgQsBqhx1WWomwtXr2ogZE9MF_kVAc=.86bb7579-248a-4370-bcee-a52587c5f90b@github.com>

Hi, Please review the simple change.

  The removing of white spaces from end of line in ClassListParser should be moved to before we add lambda-form-invoker
  line to array.  After made such arrangement, changed CDS.java for trimming line code.

Tests: local test on runtime/cds/appcds. Mach5 tier1,4 is in progress.

Thanks

-------------

Commit messages:
 - 8254192: ExtraSharedClassListFile contains extra white space at end of line

Changes: https://git.openjdk.java.net/jdk/pull/669/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=669&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8254192
  Stats: 57 lines in 2 files changed: 26 ins; 25 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/669.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/669/head:pull/669

PR: https://git.openjdk.java.net/jdk/pull/669

From jptatton at amazon.com  Thu Oct 15 00:42:35 2020
From: jptatton at amazon.com (Tatton, Jason)
Date: Thu, 15 Oct 2020 00:42:35 +0000
Subject: Howto replicate failure of 8254790?
Message-ID: <4bd7e9f73ea24ae09f1bb0f1808ce5a7@EX13D46EUB003.ant.amazon.com>

Hi all,



I am trying to replicate the failure of the tier2 test mentioned in 8254790<https://bugs.openjdk.java.net/browse/JDK-8254790> but I am only seeing it pass under an x86 linux machine. Are there any specific architectural constraints under which this test should be run in order to make it fail?



I am running the test via: make test TEST="test/jdk/javax/xml/crypto/dsig/GenerationTests.java"



Note that I am running the test against master without the commit: "8254792: Disable intrinsic StringLatin1.indexOf until 8254790 is fixed" which disables the intrinsic that is causing the test to fail.



Thanks
--
Jason


From david.holmes at oracle.com  Thu Oct 15 00:48:04 2020
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 15 Oct 2020 10:48:04 +1000
Subject: Howto replicate failure of 8254790?
In-Reply-To: <4bd7e9f73ea24ae09f1bb0f1808ce5a7@EX13D46EUB003.ant.amazon.com>
References: <4bd7e9f73ea24ae09f1bb0f1808ce5a7@EX13D46EUB003.ant.amazon.com>
Message-ID: <661485ab-7de7-26cb-b2b1-3a4f643125eb@oracle.com>

Hi Jason,

On 15/10/2020 10:42 am, Tatton, Jason wrote:
> Hi all,
> 
> 
> 
> I am trying to replicate the failure of the tier2 test mentioned in 8254790<https://bugs.openjdk.java.net/browse/JDK-8254790> but I am only seeing it pass under an x86 linux machine. Are there any specific architectural constraints under which this test should be run in order to make it fail?

It failed on a Mac, not Linux.

Cheers,
David

> 
> 
> I am running the test via: make test TEST="test/jdk/javax/xml/crypto/dsig/GenerationTests.java"
> 
> 
> 
> Note that I am running the test against master without the commit: "8254792: Disable intrinsic StringLatin1.indexOf until 8254790 is fixed" which disables the intrinsic that is causing the test to fail.
> 
> 
> 
> Thanks
> --
> Jason
> 

From minqi at openjdk.java.net  Thu Oct 15 01:04:25 2020
From: minqi at openjdk.java.net (Yumin Qi)
Date: Thu, 15 Oct 2020 01:04:25 GMT
Subject: RFR: 8254192: ExtraSharedClassListFile contains extra white space
 at end of line [v2]
In-Reply-To: <0LTIfmJUJ1A68tgQsBqhx1WWomwtXr2ogZE9MF_kVAc=.86bb7579-248a-4370-bcee-a52587c5f90b@github.com>
References: <0LTIfmJUJ1A68tgQsBqhx1WWomwtXr2ogZE9MF_kVAc=.86bb7579-248a-4370-bcee-a52587c5f90b@github.com>
Message-ID: <uufPGPiY3XiM3aFPy4s6re0CaqoI9FIqPofP9CGkajs=.5fcf0594-f837-4224-b8a5-6ae581d750ed@github.com>

> Hi, Please review the simple change.
> 
>   The removing of white spaces from end of line in ClassListParser should be moved to before we add lambda-form-invoker
>   line to array.  After made such arrangement, changed CDS.java for trimming line code.
> 
> Tests: local test on runtime/cds/appcds. Mach5 tier1,4 is in progress.
> 
> Thanks

Yumin Qi has updated the pull request incrementally with one additional commit since the last revision:

  Fix comment adding \f for Replace

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/669/files
  - new: https://git.openjdk.java.net/jdk/pull/669/files/2086b3d8..f2984a4b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=669&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=669&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/669.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/669/head:pull/669

PR: https://git.openjdk.java.net/jdk/pull/669

From iklam at openjdk.java.net  Thu Oct 15 01:09:12 2020
From: iklam at openjdk.java.net (Ioi Lam)
Date: Thu, 15 Oct 2020 01:09:12 GMT
Subject: RFR: 8254192: ExtraSharedClassListFile contains extra white space
 at end of line [v2]
In-Reply-To: <uufPGPiY3XiM3aFPy4s6re0CaqoI9FIqPofP9CGkajs=.5fcf0594-f837-4224-b8a5-6ae581d750ed@github.com>
References: <0LTIfmJUJ1A68tgQsBqhx1WWomwtXr2ogZE9MF_kVAc=.86bb7579-248a-4370-bcee-a52587c5f90b@github.com>
 <uufPGPiY3XiM3aFPy4s6re0CaqoI9FIqPofP9CGkajs=.5fcf0594-f837-4224-b8a5-6ae581d750ed@github.com>
Message-ID: <MPrpQ-EUM8iGToFQj3BTLxRDFWWeLf3SpXD-bb3M2Zg=.3b024800-eb6b-4995-80d9-6a256a16c51d@github.com>

On Thu, 15 Oct 2020 01:04:25 GMT, Yumin Qi <minqi at openjdk.org> wrote:

>> Hi, Please review the simple change.
>> 
>>   The removing of white spaces from end of line in ClassListParser should be moved to before we add lambda-form-invoker
>>   line to array.  After made such arrangement, changed CDS.java for trimming line code.
>> 
>> Tests: local test on runtime/cds/appcds. Mach5 tier1,4 is in progress.
>> 
>> Thanks
>
> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comment adding \f for Replace

Marked as reviewed by iklam (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/669

From jason_mehrens at hotmail.com  Thu Oct 15 02:30:18 2020
From: jason_mehrens at hotmail.com (Jason Mehrens)
Date: Thu, 15 Oct 2020 02:30:18 +0000
Subject: RFR: 8253459: Formatter treats index, width and precision >
 Integer.MAX_VALUE incorrectly [v4]
In-Reply-To: <UNDO-R_iCPXgjeKbwAvP5iCISCW0vJs710ISp768TT0=.3ebec6f4-b6ae-45fa-b6f5-318aa05a5dca@github.com>
References: <3aYgWcp1IVMM0vQT5UMLSnc2JA1uK9cbtRe283RF37g=.fc2049ef-cdbe-4948-a24b-fdb88cc87a1c@github.com>,
 <UNDO-R_iCPXgjeKbwAvP5iCISCW0vJs710ISp768TT0=.3ebec6f4-b6ae-45fa-b6f5-318aa05a5dca@github.com>
Message-ID: <DM5PR1801MB2074FC52596831F81296296283020@DM5PR1801MB2074.namprd18.prod.outlook.com>

Ian,

Should IllegalFormatArgumentIndexException.java provide an override of getMessage?  It appears that is done in the following:

https://github.com/openjdk/jdk/blob/9b07ef33b6e07afae1a8bfa034200eb3aab1f94f/src/java.base/share/classes/java/util/IllegalFormatWidthException.java
https://github.com/openjdk/jdk/blob/9b07ef33b6e07afae1a8bfa034200eb3aab1f94f/src/java.base/share/classes/java/util/IllegalFormatPrecisionException.java

Otherwise the index won't be rendered when toString or printStackTrace is invoked.

Jason

________________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.java.net> on behalf of Ian Graves <igraves at openjdk.java.net>
Sent: Wednesday, October 14, 2020 1:39 PM
To: core-libs-dev at openjdk.java.net; i18n-dev at openjdk.java.net
Subject: Re: RFR: 8253459: Formatter treats index, width and precision > Integer.MAX_VALUE incorrectly [v4]

> The `java.util.Formatter` format specifies support for field widths, argument indexes, or precision lengths of a field
> that relate to the variadic arguments supplied to the formatter. These numbers are specified by integers, sometimes
> negative. For argument index, it's specified in the documentation that the highest allowed argument is limited by the
> largest possible index of an array (ie the largest possible variadic index), but for the other two it's not defined.
> Moreover, what happens when a number field in a string is too large or too small to be represented by a 32-bit integer
> type is not defined.  This fix adds documentation to specify what error behavior occurs during these cases.
> Additionally it adds an additional exception type to throw when an invalid argument index is observed.  A CSR will be
> required for this PR.

Ian Graves has updated the pull request incrementally with one additional commit since the last revision:

  Tweaking verbiage

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/516/files
  - new: https://git.openjdk.java.net/jdk/pull/516/files/391449a8..9b07ef33

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=516&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=516&range=02-03

  Stats: 18 lines in 2 files changed: 0 ins; 5 del; 13 mod
  Patch: https://git.openjdk.java.net/jdk/pull/516.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/516/head:pull/516

PR: https://git.openjdk.java.net/jdk/pull/516

From mchung at openjdk.java.net  Thu Oct 15 02:50:43 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Thu, 15 Oct 2020 02:50:43 GMT
Subject: RFR: 8159746: (proxy) Support for default methods [v4]
In-Reply-To: <kw2VXh3vTFf1zgfd4biXA41OKffZ5oU7KT23tXAxgUA=.bcf14ffc-4dba-4c9c-8754-184172c5acbd@github.com>
References: <kw2VXh3vTFf1zgfd4biXA41OKffZ5oU7KT23tXAxgUA=.bcf14ffc-4dba-4c9c-8754-184172c5acbd@github.com>
Message-ID: <TTcwE6tgxXf81_tijACGIAcc9Hy_l9-lR_2WPhhADvM=.461a041a-0512-40e2-bd38-177504264afe@github.com>

> This proposes a new static `Proxy::invokeDefaultMethod` method to invoke
> the given default method on the given proxy instance.
> 
> The implementation looks up a method handle for `invokespecial` instruction
> as if called from with the proxy class as the caller, equivalent to calling
> `X.super::m` where `X` is a proxy interface of the proxy class and
> `X.super::m` will resolve to the specified default method.
> 
> The implementation will call a private static `proxyClassLookup(Lookup caller)`
> method of the proxy class to obtain its private Lookup.  This private method
> in the proxy class only allows a caller Lookup on java.lang.reflect.Proxy class
> with full privilege access to use, or else `IllegalAccessException` will be
> thrown.
> 
> This patch also proposes to define a proxy class in an unnamed module to
> a dynamic module to strengthen encapsulation such that they are only
> unconditionally exported from a named module but not open for deep reflective
> access.  This only applies to the case if all the proxy interfaces are public
> and in a package that is exported or open.
> 
> One dynamic module is created for each class loader that defines proxies.
> The change changes the dynamic module to contain another package (same
> name as the module) that is unconditionally exported and is opened to
> `java.base` only.
> 
> There is no change to the package and module of the proxy class for
> the following cases:
> 
> - if at least one proxy interface is non-public, then the proxy class is defined
>   in the package and module of the non-public interfaces
> - if at least one proxy is in a package that is non-exported and non-open,
>   if all proxy interfaces are public, then the proxy class is defined in
>   a non-exported, non-open package of a dynamic module.
> 
> The spec change is that a proxy class used to be defined in an unnamed
> module, i.e. in a exported and open package, is defined in an unconditionally
> exported but non-open package.  Programs that assume it to be open unconditionally
> will be affected and cannot do deep reflection on such proxy classes.
> 
> Peter Levart contributed an initial prototype [1] (thanks Peter).  I think
> the exceptions could be simplified as more checking should be done prior to
> the invocation of the method handle like checking the types of the arguments
> with the method type.  This approach avoids defining a public API
> `protected Proxy::$$proxyClassLookup$$` method.  Instead it defines a
> private static method that is restricted for Proxy class to use (by
> taking a caller parameter to ensure it's a private lookup on Proxy class).
> 
> javadoc/specdiff:
> http://cr.openjdk.java.net/~mchung/jdk16/webrevs/8159746/api/
> http://cr.openjdk.java.net/~mchung/jdk16/webrevs/8159746/specdiff/
> 
> [1]  http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-June/041629.html

Mandy Chung has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev
excludes the unrelated changes brought in by the merge/rebase. The pull request contains 20 additional commits since
the last revision:

 - Merge branch 'master' of https://github.com/openjdk/jdk into proxy-default-method
 - move invokeDefaultMethod to InvocationHandler and throw IAE if access check fails
 - Merge branch 'master' of https://github.com/openjdk/jdk into proxy-default-method
 - Merge branch 'master' of https://github.com/openjdk/jdk into proxy-default-method
 - minor tweak to the spec wording and impl
 - Merge pull request #1 from plevart/proxy-default-method-performance
   
   Performance improvements for Proxy::invokeDefaultMethod
 - Add test case for InvocationTargetException
 - Revert the thrown exceptions spec to be consistent with Method::invoke
 - Speed up Proxy.invokeDefaultMethod while also changing its spec regarding exception types thrown
 - Merge branch 'master' of https://github.com/openjdk/jdk into proxy-default-method
 - ... and 10 more: https://git.openjdk.java.net/jdk/compare/b3d81c94...8e0248a1

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/313/files
  - new: https://git.openjdk.java.net/jdk/pull/313/files/db6cfc13..8e0248a1

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=313&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=313&range=02-03

  Stats: 341121 lines in 1531 files changed: 317557 ins; 13324 del; 10240 mod
  Patch: https://git.openjdk.java.net/jdk/pull/313.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/313/head:pull/313

PR: https://git.openjdk.java.net/jdk/pull/313

From mchung at openjdk.java.net  Thu Oct 15 02:57:16 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Thu, 15 Oct 2020 02:57:16 GMT
Subject: RFR: 8159746: (proxy) Support for default methods
In-Reply-To: <Y0hE51G3YefI6NY1O_E6VoZSKwxE78S1hv6fEatmOG8=.0a2c686c-d9ad-418c-8c1b-49addb8a54b1@github.com>
References: <kw2VXh3vTFf1zgfd4biXA41OKffZ5oU7KT23tXAxgUA=.bcf14ffc-4dba-4c9c-8754-184172c5acbd@github.com>
 <U-6RiCpFVIrhLztPN6opiPcpFtxValDzU-K7WWFZM-4=.6bc8aaa4-636a-4664-b380-4c4af00513bd@github.com>
 <-cLIJ8pFHtnNoJMHV3aXI7XMJWp4Jrutc8Xn5PG0OK8=.d2cd87ab-3592-4524-ad85-05444c43689b@github.com>
 <r0UK2qjnmgeTNDDSWaSLPAj3QRgx_4YB82ielllO7jM=.fa615bc0-db49-4a74-b842-793f8f5209bb@github.com>
 <1T8kXDZN1bhHr4c8v4SQsImeBySCqTfX-u3_jzvyocA=.b4957400-9a33-4b6e-8475-329642a5888c@github.com>
 <XIux-dY0JXHRafHk48kVNXId9r-HSceNSytBojDxelY=.872e74cb-b064-406e-b71f-13c90ec7fbbc@github.com>
 <j4t2vT0SnwnU7lhKRlXtk967d-K6nA0EqHrqNbba7W0=.dc05dba6-bf7e-4606-8a02-9c2bad4b3b58@github.com>
 <fmVtPcBdgMuZOPm2qx3Q3znVZM7JgQPkhPAVLtwkOhE=.2d8b8447-cfae-4cb3-9a7c-6567a881231f@github.com>
 <GSeWP29fAIUFSk0CYsC557w52CuLqeUWwHNK9maltwI=.3d5f002e-6b74-4a57-a5d8-244d27da9dde@github.com>
 <GF8iEOkMUEL2dYB0HytFIc9gyeeUJ_KP0ImlqFsul2Y=.894afc05-9310-43e1-a308-8f7d71dc572b@github.com>
 <HvtDex3cmiv7XeTMITOroYfu74amSGQavQ_
 BAmVzmXw=.223be989-7c20-4ba4-ac0d-013d2b75a8cb@github.com>
 <IqRiLphFPBpGiKAnMJXqxjie9YeZ03rcE-qG1s92BLw=.d4fd5e92-5067-40df-8a0b-1dfd3d6e23af@github.com>
 <Y0hE51G3YefI6NY1O_E6VoZSKwxE78S1hv6fEatmOG8=.0a2c686c-d9ad-418c-8c1b-49addb8a54b1@github.com>
Message-ID: <QrNk57L2PWQhJjzYiGTsvYyGIPAfK7bP_kANtTR-2uM=.3e5ce990-f8ea-4751-8147-27a8a9dad40d@github.com>

On Wed, 7 Oct 2020 21:31:29 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> I'm thinking a static method `InvocationHandler::invokeDefaultMethod` and no new method in `Proxy` class.   Proxy class
>> will still have the package-private methods for `InvocationHandler::invokeDefaultMethod` implementation to use.
>> It may seem to be cleaner to be a default method at the use site called from InvocationHandler.  However, it's not
>> really a method meant to be overridden.
>
> Thanks for the input Peter.
> 
>> I'm in favour of following the bytecode (method handles) behaviour here even though it allows more than Java language
>> allows.
> 
> The proposal intends to follow the bytecode behavior.   I can clarify in the javadoc.

`invokeDefaultMethod` is moved to a static method in `InvocationHandler`.
 I also add `@throws IllegalAccessException` if the specified default method is
inaccessible to the caller (access check was missing in the previous version).
The declaring interface of the default method must be exported to the caller to
use.  If it's a non-public interface, the caller class must be in the same runtime
package as the interface.  The example in javadoc includes the case when
the proxy interface is modified.

-------------

PR: https://git.openjdk.java.net/jdk/pull/313

From kbarrett at openjdk.java.net  Thu Oct 15 03:10:31 2020
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Thu, 15 Oct 2020 03:10:31 GMT
Subject: RFR: 8188055: (ref) Add Reference::refersTo predicate [v4]
In-Reply-To: <D4HSg8FT20Eaxk5KJkkw0GgETSxRkBn1ipS3Dt0kPto=.e4bab078-2e04-4413-90cb-9bfafb2a6831@github.com>
References: <D4HSg8FT20Eaxk5KJkkw0GgETSxRkBn1ipS3Dt0kPto=.e4bab078-2e04-4413-90cb-9bfafb2a6831@github.com>
Message-ID: <8qBXXAAjz3yFtVc4DXlKLOcTWit1X05U7kLC-_CfZo0=.08d6126d-e702-44e8-876e-111985c2b7b4@github.com>

> Finally returning to this review that was started in April 2020.  I've
> recast it as a github PR.  I think the security concern raised by Gil
> has been adequately answered.
> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-April/029203.html
> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-July/030401.html
> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-August/030677.html
> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-September/030793.html
> 
> Please review a new function: java.lang.ref.Reference.refersTo.
> 
> This function is needed to test the referent of a Reference object without
> artificially extending the lifetime of the referent object, as may happen
> when calling Reference.get.  Some garbage collectors require extending the
> lifetime of a weak referent when accessed, in order to maintain collector
> invariants.  Lifetime extension may occur with any collector when the
> Reference is a SoftReference, as calling get indicates recent access.  This
> new function also allows testing the referent of a PhantomReference, which
> can't be accessed by calling get.
> 
> The new function uses native methods whose implementations are in the VM so
> they can use the Access API.  It is the intent that these methods will be
> intrinsified by optimizing compilers like C2 or graal, but that hasn't been
> implemented yet.  Bear that in mind before rushing off to change existing
> uses of Reference.get.
> 
> There are two native methods involved, one in Reference and an override in
> PhantomReference, both package private in java.lang.ref. The reason for this
> split is to simplify the intrinsification. This is a change from the version
> from April 2020; that version had a single native method in Reference,
> implemented using the ON_UNKNOWN_OOP_REF Access reference strength category.
> However, adding support for that category in the compilers adds significant
> implementation effort and complexity. Splitting avoids that complexity.
> 
> Testing:
> mach5 tier1
> Locally (linux-x64) verified the new test passes with various garbage collectors.

Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:

  More explicit refersTo0 comment.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/498/files
  - new: https://git.openjdk.java.net/jdk/pull/498/files/efa40d71..c1062ec6

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=498&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=498&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/498.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/498/head:pull/498

PR: https://git.openjdk.java.net/jdk/pull/498

From kbarrett at openjdk.java.net  Thu Oct 15 03:10:32 2020
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Thu, 15 Oct 2020 03:10:32 GMT
Subject: RFR: 8188055: (ref) Add Reference::refersTo predicate [v3]
In-Reply-To: <ub1iS4VHGAop9lG_xgKY1n7ktE-vqUchltsdwKdfnLw=.e4d52317-d1e0-42da-a7ce-ebcb5fc3e802@github.com>
References: <D4HSg8FT20Eaxk5KJkkw0GgETSxRkBn1ipS3Dt0kPto=.e4bab078-2e04-4413-90cb-9bfafb2a6831@github.com>
 <J-8wUT_ItffnPBtGCcJVokoBDDL5jOVG9COuoMIrVh8=.296b587b-0b4b-48ca-bc9a-dffb7eaa948a@github.com>
 <5XemoS4nTtROBzX7sighX_dQrC4ZXzXNKfs3LM5BUR8=.c88f673a-650f-483e-bb7e-d197e53742d4@github.com>
 <j8k5iayIiBG8L6y4kxzUcOQdiIdYGOmEooLYLWUUJkA=.0b45920d-a401-4cd0-9297-3dbff6e9eced@github.com>
 <ub1iS4VHGAop9lG_xgKY1n7ktE-vqUchltsdwKdfnLw=.e4d52317-d1e0-42da-a7ce-ebcb5fc3e802@github.com>
Message-ID: <EYSPooZGJzvDb7ifeyQydIsIvEG1dSbEw1IMevbw4MA=.d48cf3a2-d0b2-4354-9a77-2c5c6c94bc07@github.com>

On Wed, 14 Oct 2020 14:39:40 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> (1) The "0" suffix is idiomatic for this sort of thing.  See, for example,
>> src/java.base/share/native/libjava/ConstantPool.c. (2) I'm not sure what else besides an override one might wonder
>> about?  "Default implementation of refersTo(), for non-phantom references."?
>
>> See, for example, src/java.base/share/native/libjava/ConstantPool.c.
> 
> Got it; thank you.
> 
>> I'm not sure what else besides an override one might wonder about?
> 
> I don't know; maybe override is the only sensible choice. I just believe saying it explicitly is better than implicitly.

OK.

-------------

PR: https://git.openjdk.java.net/jdk/pull/498

From ayang at openjdk.java.net  Thu Oct 15 07:12:13 2020
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Thu, 15 Oct 2020 07:12:13 GMT
Subject: RFR: 8188055: (ref) Add Reference::refersTo predicate [v3]
In-Reply-To: <EYSPooZGJzvDb7ifeyQydIsIvEG1dSbEw1IMevbw4MA=.d48cf3a2-d0b2-4354-9a77-2c5c6c94bc07@github.com>
References: <D4HSg8FT20Eaxk5KJkkw0GgETSxRkBn1ipS3Dt0kPto=.e4bab078-2e04-4413-90cb-9bfafb2a6831@github.com>
 <J-8wUT_ItffnPBtGCcJVokoBDDL5jOVG9COuoMIrVh8=.296b587b-0b4b-48ca-bc9a-dffb7eaa948a@github.com>
 <5XemoS4nTtROBzX7sighX_dQrC4ZXzXNKfs3LM5BUR8=.c88f673a-650f-483e-bb7e-d197e53742d4@github.com>
 <j8k5iayIiBG8L6y4kxzUcOQdiIdYGOmEooLYLWUUJkA=.0b45920d-a401-4cd0-9297-3dbff6e9eced@github.com>
 <ub1iS4VHGAop9lG_xgKY1n7ktE-vqUchltsdwKdfnLw=.e4d52317-d1e0-42da-a7ce-ebcb5fc3e802@github.com>
 <EYSPooZGJzvDb7ifeyQydIsIvEG1dSbEw1IMevbw4MA=.d48cf3a2-d0b2-4354-9a77-2c5c6c94bc07@github.com>
Message-ID: <DLxvy7vc-IceUVv4Bb953Jg3wp4rjj_Z9NtnURMF1V8=.3d8af588-5b19-461f-b75a-9844e9ac4a9b@github.com>

On Thu, 15 Oct 2020 03:06:45 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>>> See, for example, src/java.base/share/native/libjava/ConstantPool.c.
>> 
>> Got it; thank you.
>> 
>>> I'm not sure what else besides an override one might wonder about?
>> 
>> I don't know; maybe override is the only sensible choice. I just believe saying it explicitly is better than implicitly.
>
> OK.

Thank you for the update.

-------------

PR: https://git.openjdk.java.net/jdk/pull/498

From dfuchs at openjdk.java.net  Thu Oct 15 08:59:24 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 15 Oct 2020 08:59:24 GMT
Subject: RFR: 8251989: Hex formatting and parsing utility [v3]
In-Reply-To: <RBOpBD73GYZMCKkIq4meErFeNil87on2HoJ2vqKIQJ4=.ddd442c0-ad34-4167-a49c-6ae7a0f6b9fc@github.com>
References: <HSEn47GMS1K3g57mrTZeQk-WZHl3pKGHpX_OOf8VnsU=.740863c2-f9e4-43c4-b500-614aab4078b1@github.com>
 <RBOpBD73GYZMCKkIq4meErFeNil87on2HoJ2vqKIQJ4=.ddd442c0-ad34-4167-a49c-6ae7a0f6b9fc@github.com>
Message-ID: <b-VT8g_t4D-znNqvUQ4R9tVtX9G1QiCovqnxwQwO3C4=.68abd7e0-f14e-4af7-b7c3-09d3822badb8@github.com>

On Wed, 14 Oct 2020 19:12:37 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> java.util.HexFormat utility:
>> 
>>  - Format and parse hexadecimal strings, with parameters for delimiter, prefix, suffix and upper/lowercase
>>  - Static factories and builder methods to create HexFormat copies with modified parameters.
>>  - Consistent naming of methods for conversion of byte arrays to formatted strings and back: formatHex and parseHex
>>  - Consistent naming of methods for conversion of primitive types: toHexDigits... and fromHexDigits...
>>  - Prefix and suffixes now apply to each formatted value, not the string as a whole
>>  - Using java.util.Appendable as a target for buffered conversions so output to Writers and PrintStreams
>>    like System.out are supported in addition to StringBuilder. (IOExceptions are converted to unchecked exceptions)
>>  - Immutable and thread safe, a "value-based" class
>> 
>> See the [HexFormat
>> javadoc](http://cr.openjdk.java.net/~rriggs/8251989-hex-formatter/java.base/java/util/HexFormat.html) for details.
>> Review comments and suggestions welcome.
>
> Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev
> excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since
> the last revision:
>  - Added assertions to testVariableLength and samples
>  - Merge branch 'master' into 8251989-hex-formatter
>  - temp updates
>  - Various code review comments, rename UpperCase and LowerCase methods to match Character, remove unnecessary Class name
>    qualifications, etc.
>  - 8251989: Hex formatting and parsing utility

This version looks much better to me, thanks!
Still some references to the non-existing `format` method (spotted by @Marcono1234 )

src/java.base/share/classes/java/util/HexFormat.java line 64:

> 62:  * and {@link #formatHex(Appendable, byte[]) formatHex(Appendable, byte[])}.
> 63:  * The formatted output can be appended to {@link StringBuilder}, {@link System#out},
> 64:  * {@link java.io.Writer}, and {@link java.io.PrintStream}, all of which are {@link Appendable}s.

I would argue that the `s` is not necessary: `... all of which are {@link Appendable}.`

-------------

PR: https://git.openjdk.java.net/jdk/pull/482

From plevart at openjdk.java.net  Thu Oct 15 09:07:15 2020
From: plevart at openjdk.java.net (Peter Levart)
Date: Thu, 15 Oct 2020 09:07:15 GMT
Subject: RFR: 8159746: (proxy) Support for default methods
In-Reply-To: <QrNk57L2PWQhJjzYiGTsvYyGIPAfK7bP_kANtTR-2uM=.3e5ce990-f8ea-4751-8147-27a8a9dad40d@github.com>
References: <kw2VXh3vTFf1zgfd4biXA41OKffZ5oU7KT23tXAxgUA=.bcf14ffc-4dba-4c9c-8754-184172c5acbd@github.com>
 <U-6RiCpFVIrhLztPN6opiPcpFtxValDzU-K7WWFZM-4=.6bc8aaa4-636a-4664-b380-4c4af00513bd@github.com>
 <-cLIJ8pFHtnNoJMHV3aXI7XMJWp4Jrutc8Xn5PG0OK8=.d2cd87ab-3592-4524-ad85-05444c43689b@github.com>
 <r0UK2qjnmgeTNDDSWaSLPAj3QRgx_4YB82ielllO7jM=.fa615bc0-db49-4a74-b842-793f8f5209bb@github.com>
 <1T8kXDZN1bhHr4c8v4SQsImeBySCqTfX-u3_jzvyocA=.b4957400-9a33-4b6e-8475-329642a5888c@github.com>
 <XIux-dY0JXHRafHk48kVNXId9r-HSceNSytBojDxelY=.872e74cb-b064-406e-b71f-13c90ec7fbbc@github.com>
 <j4t2vT0SnwnU7lhKRlXtk967d-K6nA0EqHrqNbba7W0=.dc05dba6-bf7e-4606-8a02-9c2bad4b3b58@github.com>
 <fmVtPcBdgMuZOPm2qx3Q3znVZM7JgQPkhPAVLtwkOhE=.2d8b8447-cfae-4cb3-9a7c-6567a881231f@github.com>
 <GSeWP29fAIUFSk0CYsC557w52CuLqeUWwHNK9maltwI=.3d5f002e-6b74-4a57-a5d8-244d27da9dde@github.com>
 <GF8iEOkMUEL2dYB0HytFIc9gyeeUJ_KP0ImlqFsul2Y=.894afc05-9310-43e1-a308-8f7d71dc572b@github.com>
 <HvtDex3cmiv7XeTMITOroYfu74amSGQavQ_
 BAmVzmXw=.223be989-7c20-4ba4-ac0d-013d2b75a8cb@github.com>
 <IqRiLphFPBpGiKAnMJXqxjie9YeZ03rcE-qG1s92BLw=.d4fd5e92-5067-40df-8a0b-1dfd3d6e23af@github.com>
 <Y0hE51G3YefI6NY1O_E6VoZSKwxE78S1hv6fEatmOG8=.0a2c686c-d9ad-418c-8c1b-49addb8a54b1@github.com>
 <QrNk57L2PWQhJjzYiGTsvYyGIPAfK7bP_kANtTR-2uM=.3e5ce990-f8ea-4751-8147-27a8a9dad40d@github.com>
Message-ID: <9JNNUzfV3PSvKtSg2a_zyYJmgEn3sZL9cb5sfqemk2o=.f1ef7fb7-bdd5-44ed-98c8-59213e9094f9@github.com>

On Thu, 15 Oct 2020 02:54:06 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Thanks for the input Peter.
>> 
>>> I'm in favour of following the bytecode (method handles) behaviour here even though it allows more than Java language
>>> allows.
>> 
>> The proposal intends to follow the bytecode behavior.   I can clarify in the javadoc.
>
> `invokeDefaultMethod` is moved to a static method in `InvocationHandler`.
>  I also add `@throws IllegalAccessException` if the specified default method is
> inaccessible to the caller (access check was missing in the previous version).
> The declaring interface of the default method must be exported to the caller to
> use.  If it's a non-public interface, the caller class must be in the same runtime
> package as the interface.  The example in javadoc includes the case when
> the proxy interface is modified.

Hi Mandy,

I'm beginning to think that we somewhat wondered away from the original intent which was to mimic the bytecode
behaviour as much as possible. Bytecode behaviour for super calls (invokespecial) is very special and what you do in
the last patch is guarding invocation to a super default method via @CallerSensitive method which checks the access of
the caller as though this was a normal call. Similar access check when a default method might reside in a
package-private class or when this class might not be exported is already performed when the code creates a Proxy
class/instance (Proxy::getProxyClass/newProxyInstance). This code also designates an InvocationHandler for the proxy
instance. From that point on, the designated invocation handler should have full access to invoking super default
methods on the proxy instance regardless of where it resides because it has been chosen as the delegate of the Proxy
class with full powers.

Since we are exposing the invokeDefaultMethod functionality in a public static method, it is hard (or not quite
possible) to check that the code doing the invocation is in fact the designated invocation handler code. One
approximation might be the following check:

`Proxy.getInvocationHandler(proxy).getClass() == callerClass`

...but that would not work for code residing in the invocation handler superclass even though such code might be
eligible to call the super default method. OTOH such check is over permissive as it allows calling the super method
from static context too.

So I was thinking about an alternative approach. To expose the method as a protected final instance method in an
abstract class implementing InvocationHandler:

public interface InvocationHandler {
  ...
  abstract class Support implements InvocationHandler {
    protected final Object invokeDefaultMethod(Object proxy, Method method, Object... args) throws
    InvocationTargetException {
      if (this != Proxy.getInvocationHandler(proxy)) throw ...
      ...
    }
  }
}

Users would have to extend `InvocationHandler.Support` to access this feature. This might be OK for most users, but
those wanting to extend some other class will not be able to do that.

So WDYT? In case you still prefer your approach of re-checking the permissions in invokeDefaultMethod, then I might
have some ideas of how to speed-up theses checks. As currently stands, invoking public exported interface default
methods does exhibit a little more penalty, but for non-public or non-exported interfaces, the penalty is bigger:

Mandy's original:

Benchmark             Mode  Cnt    Score    Error  Units
ProxyBench.implClass  avgt    5    3.709 ?  0.026  ns/op
ProxyBench.implProxy  avgt    5  926.215 ? 11.835  ns/op

Peter's performance patch:

Benchmark             Mode  Cnt   Score   Error  Units
ProxyBench.implClass  avgt    5   3.777 ? 0.005  ns/op
ProxyBench.implProxy  avgt    5  27.579 ? 0.250  ns/op

Moved to InvocationHandler + added access check

Benchmark               Mode  Cnt    Score   Error  Units
ProxyBench.implClass    avgt    5    3.740 ? 0.004  ns/op
ProxyBench.implProxy    avgt    5   34.226 ? 0.125  ns/op
ProxyBench.ppImplClass  avgt    5    3.780 ? 0.004  ns/op
ProxyBench.ppImplProxy  avgt    5  147.318 ? 1.422  ns/op

The updated benchmark code is here: https://gist.github.com/plevart/f6e0a5224c3ffbf14b28b47755599226
(the ppImpl... benchmarks are against package-private interface)

-------------

PR: https://git.openjdk.java.net/jdk/pull/313

From github.com+10835776+stsypanov at openjdk.java.net  Thu Oct 15 09:20:21 2020
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Thu, 15 Oct 2020 09:20:21 GMT
Subject: RFR: 8254146: Avoid unnecessary volatile write on new
 AtomicBoolean(false)
In-Reply-To: <RyR2m1MR6UPKbcnxdi_tHwJvQxEtMhT-o2ljRTQDcEo=.976aa7a1-6706-4502-a150-5eb25dd744d1@github.com>
References: <AzWKluHZjvFYm2wUanwYfn91iKKMacpk_qSsje3tXWk=.ba873b46-4e12-4415-8832-fa314d6759a3@github.com>
 <RyR2m1MR6UPKbcnxdi_tHwJvQxEtMhT-o2ljRTQDcEo=.976aa7a1-6706-4502-a150-5eb25dd744d1@github.com>
Message-ID: <b7teCaJhFTu-4FHTyQqDwOqy1B1blXQaoowClBcqnTU=.d75b5dd9-050b-4137-b8fd-8b8e9171a6ca@github.com>

On Thu, 8 Oct 2020 08:03:12 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

>> Hi,
>> 
>> the following PR optimizes `new AtomicBoolean(boolean)` by avoiding the volatile write in case `false` is passed.
>> Essentially, it changes the ternary operator to a simple `if` without the `else` that would cause the volatile write.
>> The resulting bytecode seems to also benefit from the change:
>>     Code:
>>        0: aload_0
>>        1: invokespecial #1                  // Method java/lang/Object."<init>":()V
>>        4: aload_0
>>        5: iload_1
>>        6: ifeq          13
>>        9: iconst_1
>>       10: goto          14
>>       13: iconst_0
>>       14: putfield      #7                  // Field value:I
>>       17: return
>> 
>> After:
>>     Code:
>>        0: aload_0
>>        1: invokespecial #1                  // Method java/lang/Object."<init>":()V
>>        4: iload_1
>>        5: ifeq          13
>>        8: aload_0
>>        9: iconst_1
>>       10: putfield      #7                  // Field value:I
>>       13: return
>> 
>> A simple benchmark that returns `new AtomicBoolean(false)` shows the following results, that brings it on par to `new
>> AtomicBoolean()`: MyBenchmark.empty                                         avgt   10     3,103 ?   0,246   ns/op
>> MyBenchmark.explicitNew                                   avgt   10     2,966 ?   0,071   ns/op
>> MyBenchmark.explicitOld                                   avgt   10     7,738 ?   0,321   ns/op
>> 
>> In case you think this is worthwhile I'd be happy if this is sponsored.
>> Cheers,
>> Christoph
>
> Marked as reviewed by chegar (Reviewer).

I appologise for writing this to already closed issue, but Christoph's approach seems to be applicable for at least
`AtomicInteger` and `AtomicLong`, because they are often explicitly zeroed at creation time (see one of my previous PRs
https://github.com/spring-projects/spring-framework/pull/25846) and there we have the same effect as in
`AtomicBoolean`: @State(Scope.Thread) @OutputTimeUnit(TimeUnit.NANOSECONDS) @BenchmarkMode(value = Mode.AverageTime)
public class AtomicBenchmark {
  @Benchmark
  public Object defaultValue() {
    return new AtomicInteger();
  }
  @Benchmark
  public Object explicitValue() {
    return new AtomicInteger(0);
  }
}
Semantically both new AtomicInteger() and new AtomicInteger(0) are the same, but explicitValue() is much slower:
Benchmark                      Mode  Cnt   Score   Error  Units
AtomicBenchmark.defaultValue   avgt   30   4.778 ? 0.403  ns/op
AtomicBenchmark.explicitValue  avgt   30  11.846 ? 0.273  ns/op
So the same pattern as we used here could be applied for `AtomicInteger`:
public AtomicInteger(int initialValue) {
  if (initialValue != 0 {
    value = initialValue;
  }
}
What do you think?

-------------

PR: https://git.openjdk.java.net/jdk/pull/510

From simonis at openjdk.java.net  Thu Oct 15 09:22:21 2020
From: simonis at openjdk.java.net (Volker Simonis)
Date: Thu, 15 Oct 2020 09:22:21 GMT
Subject: Integrated: 8253952: Refine ZipOutputStream.putNextEntry() to
 recalculate ZipEntry's compressed size
In-Reply-To: <0nq5oFKOj6AZqCW6jF268-6oKRI6UkS6TRIHo-_5vKw=.d13c7016-4473-4b20-9117-100b368d3716@github.com>
References: <0nq5oFKOj6AZqCW6jF268-6oKRI6UkS6TRIHo-_5vKw=.d13c7016-4473-4b20-9117-100b368d3716@github.com>
Message-ID: <UUqLHmKVHrbkkXkWog7YOA1dydv7NcRO9WBGqqJfTAs=.c02b1165-8693-4138-a049-d1001fa12192@github.com>

On Tue, 6 Oct 2020 10:02:09 GMT, Volker Simonis <simonis at openjdk.org> wrote:

> ### Summary
> 
> Work around wrong usage of `ZipOutputStream.putNextEntry()` in user code which can lead to the `ZipException "invalid
> entry compressed size"`.
> ### Motivation
> 
> In general it is not safe to directly write a ZipEntry obtained from `ZipInputStream.getNextEntry()`,
> `ZipFile.entries()`, `ZipFile.getEntry()` or `ZipFile.stream()` with `ZipOutputStream.putNextEntry()` to a
> `ZipOutputStream` and then read the entries data from the `ZipInputStream` and write it to the `ZipOutputStream` as
> follows:
>  ZipEntry entry;
>  ZipInputStream zis = new ZipInputStream(...);
>  ZipOutputStream zos = new ZipOutputStream(...);
>  while((entry = zis.getNextEntry()) != null) {
>      zos.putNextEntry(entry);
>      zis.transferTo(zos);
>  }
> The problem with this code is that the zip file format does not record the compression level used for deflation in its
> entries. In general, it doesn't even mandate a predefined compression ratio per compression level. Therefore the
> compressed size recorded in a `ZipEntry` read from a zip file might differ from the new compressed size produced by the
> receiving `ZipOutputStream`. Such a difference will result in a `ZipException` with the following message:
>  java.util.zip.ZipException: invalid entry compressed size (expected 12 but got 7 bytes)
>  
> The correct way of copying all entries from one zip file into another requires the creation of a new `ZipEntry` or at
> least resetting of the compressed size field. E.g.:
>  while((entry = zis.getNextEntry()) != null) {
>      ZipEntry newEntry = new ZipEntry(entry.getName());
>      zos.putNextEntry(newEntry);
>      zis.transferTo(zos);
>  }
> or:
>  while((entry = zis.getNextEntry()) != null) {
>      entry.setCompressedSize(-1);
>      zos.putNextEntry(entry);
>      zis.transferTo(zos);
>  }
> Unfortunately, there's a lot of user code out there which gets this wrong and uses the bad coding pattern described
> before. Searching for `"java.util.zip.ZipException: invalid entry compressed size (expected 12 but got 7 bytes)"` gives
> ~2500 hits (~100 on StackOverflow). It's also no hard to find plenty of instances of this anti-pattern on GitHub when
> doing a code search for `ZipEntry` and `putNextEntry()`. E.g. [Gradle 4.x wrapper task][1] is affected as well as the
> latest version of the [mockableAndroidJar task][2]. I've recently fixed two occurrences of this pattern in OpenJDK (see
> [JDK-8240333][3] and [JDK-8240235][4]) but there still exist more of them (e.g.
> [`test/jdk/java/util/zip/ZipFile/CopyJar.java`][5] which is there since 1999 :).  ### Description  So while this has
> clearly been a problem before, it apparently wasn't painful enough to trigger any action from the side of the JDK.
> However, recently quite some zlib forks with [superior deflate/inflate performance have evolved][6]. Using them with
> OpenJDK is quite straight-forward: one just has to configure the alternative implementations by setting
> `LD_LIBRARY_PATH` or `LD_PRELOAD` correspondingly. We've seen big saving by using these new zlib implementations for
> selected services in production and the only reason why we haven't enabled them by default until now is the problem
> I've just described. The reason why these new libraries uncover the described anti-pattern much more often is because
> their compression ratio is slightly different from that of the default zlib library. This can easily trigger a
> `ZipException` even if an application is not using a different compression levels but just a zip file created with
> another zlib version.  I'd therefore like to propose the following workaround for the wrong
> `ZipOutputStream.putNextEntry()` usage in user code:
> -  ignore the compressed size if it was implicitly determined from the zip file and not explicitly set by calling
>    `ZipEntry.setCompressedSize()`.
> 
> - Change the API-documentation of `ZipOutputStream.putNextEntry()` and `JarOutputStream.putNextEntry()` to explain the
>   problem and why `putNextEntry()` will ignore the compressed size of a `ZipEntry` if that was set implicitely when
>   reading that entry from a `ZipFile` or `ZipInputStream`.
> 
> 
> ### Technical Details
> 
> A zip file consists of a stream of File Entries followed by a Central Directory (see [here for a more detailed
> specification][7]). Each File Entry is composed of a Local File Header (LFH) followed by the compressed Data and an
> optional Data Descriptor. The LFH contains the File Name and among other attributes the Compressed and Uncompressed
> size and CRC of the Data. In the case where the latter three attributes are not available at the time when the LFH is
> created, this fact will be recorded in a flag of the LFH and will trigger the creation of a Data Descriptor with the
> corresponding information right after the Data section. Finally, the Central Directory contains one Central Directory
> File Header (CDFH) for each entry of the  zip archive. The CDFH is an extended version of the LFH and the ultimate
> reference for the contents of the zip archive. The redundancy between LFH and CDFH is a tribute to zip's long history
> when it was used to store archives on multiple floppy discs and the CDFH allowed to update the archive by only writing
> to the last disc which contained the Central Directory.  `ZipEntries` read with `ZipInputStream.getNextEntry()` will
> initially only contain the information from the LFH. Only after the next entry was read (or after
> `ZipInputStream.closeEntry()` was called explicitly), will the previously read entry be updated with the data from the
> Data Descriptor. `ZipInputStream` doesn't inspect the Central Directory at all.  On the other hand, `ZipFile` only
> queries the Central Directory for `ZipEntry` information so all `ZipEntries` returned by `ZipFile.entries()`,
> `ZipFile.getEntry()` and `ZipFile.stream()` will always instantly contain the full Compressed and Uncompressed Size and
> CRC information for each entry independently of the LFH contents.  ### Risks and Assumptions  If we choose to ignore
> the implicitly recorded compressed size in a `ZipEntry` read from a zip file when writing it to a `ZipOutputStream`,
> this will lead to zip files with incomplete information in the LFH and an additional Data Descriptor as described
> before. However, the result is still fully compatible to the zip file specification. It's also not unusual, because by
> default all new zip files created with `ZipOutputStream` will contain LFHs without Compressed and Uncompressed Size and
> CRC information and an additional Data Descriptor. Theoretically it is possible to create new zip files with
> `ZipOutputStream` class and Compressed and Uncompressed Size and CRC information in the LFH but that's complex and
> inefficient because it requires two steps. A first step to determine the crc and compressed size of the data and a
> second step to actually write the data to the `ZipOutputStream` (which will compress it a second time). This is because
> the current API offers no possibility to write already compressed data to a `ZipOutputStream`.  Consequently, the only
> straight-forward way of creating zip files from Java which have all the data in the LFH and no Data Descriptor is by
> copying `ZipEntries` from an existing zip file with the buggy method described before. This incidentally worked more or
> less reliable for a long time but breaks miserably when using different zlib implementations. Ignoring the implicitly
> set compressed size of `ZipEntries` can easily fix this problem.  I'm not aware of any tool which can not handle such
> files and if it exists it would have problems with the majority of Java created zip files anyway (e.g. all jar-files
> created with the jar tool have zip entries with incomplete LFH data and additional Data Descriptor).  Ignoring the
> implicitly set compressed size of `ZipEntries` has no measurable performance impact and will increase the size of zip
> archives which used to have the complete file information in the LFH before by 16 bytes per entry. On the other hand it
> will give us the freedom to use whatever zip implementation we like :)   [1]:
> https://github.com/gradle/gradle/blob/e76905e3a/subprojects/build-init/src/main/java/org/gradle/api/tasks/wrapper/Wrapper.java#L152-L158
> [2]:
> https://android.googlesource.com/platform/tools/base/+/refs/heads/master/build-system/builder/src/main/java/com/android/builder/testing/MockableJarGenerator.java#86
> [3]: https://bugs.openjdk.java.net/browse/JDK-8240333 [4]: https://bugs.openjdk.java.net/browse/JDK-8240235 [5]:
> https://github.com/openjdk/jdk/blob/master/test/jdk/java/util/zip/ZipFile/CopyJar.java [6]:
> https://github.com/simonis/zlib-bench/blob/master/Results.md [7]: https://en.wikipedia.org/wiki/Zip_(file_format)

This pull request has now been integrated.

Changeset: 60159cff
Author:    Volker Simonis <simonis at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/60159cff
Stats:     231 lines in 4 files changed: 223 ins; 0 del; 8 mod

8253952: Refine ZipOutputStream.putNextEntry() to recalculate ZipEntry's compressed size

Reviewed-by: lancea, alanb

-------------

PR: https://git.openjdk.java.net/jdk/pull/520

From redestad at openjdk.java.net  Thu Oct 15 10:41:13 2020
From: redestad at openjdk.java.net (Claes Redestad)
Date: Thu, 15 Oct 2020 10:41:13 GMT
Subject: RFR: 8254146: Avoid unnecessary volatile write on new
 AtomicBoolean(false)
In-Reply-To: <b7teCaJhFTu-4FHTyQqDwOqy1B1blXQaoowClBcqnTU=.d75b5dd9-050b-4137-b8fd-8b8e9171a6ca@github.com>
References: <AzWKluHZjvFYm2wUanwYfn91iKKMacpk_qSsje3tXWk=.ba873b46-4e12-4415-8832-fa314d6759a3@github.com>
 <RyR2m1MR6UPKbcnxdi_tHwJvQxEtMhT-o2ljRTQDcEo=.976aa7a1-6706-4502-a150-5eb25dd744d1@github.com>
 <b7teCaJhFTu-4FHTyQqDwOqy1B1blXQaoowClBcqnTU=.d75b5dd9-050b-4137-b8fd-8b8e9171a6ca@github.com>
Message-ID: <xc23wavVAM3Cu4YOo122ikO4FDNUeEx0O96jUobmrYM=.455b3ead-f83b-4956-9f0a-844b3f538b57@github.com>

On Thu, 15 Oct 2020 09:17:09 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

> What do you think?

For `AtomicBoolean`, this optimization piggy-backed on an existing test, just rewriting it so that no action is taken
when none is needed. So it's never a pessimization, and even improves bytecode size marginally. So it'll be a marginal
gain even if the current overhead of writing to a volatile field in a constructor is removed/reduced.

For `AtomicInteger/-Long`, we'd have to add a test that's not there, so we'd pessimize non-zero cases by adding some
bytecode and a branch to remove the overhead. An overhead that can already be avoided by calling the empty constructor
instead. So I think it's questionable to do this.

In the short term we could consider a point fix to replace existing use of `new AtomicInteger/-Long(0)` with `new
AtomicInteger/-Long()`, but in the long term we should really try and optimize our JITs so that writing to a volatile
field in constructors can be made cheaper.

-------------

PR: https://git.openjdk.java.net/jdk/pull/510

From github.com+6304496+dreis2211 at openjdk.java.net  Thu Oct 15 10:46:17 2020
From: github.com+6304496+dreis2211 at openjdk.java.net (Christoph Dreis)
Date: Thu, 15 Oct 2020 10:46:17 GMT
Subject: RFR: 8254146: Avoid unnecessary volatile write on new
 AtomicBoolean(false)
In-Reply-To: <xc23wavVAM3Cu4YOo122ikO4FDNUeEx0O96jUobmrYM=.455b3ead-f83b-4956-9f0a-844b3f538b57@github.com>
References: <AzWKluHZjvFYm2wUanwYfn91iKKMacpk_qSsje3tXWk=.ba873b46-4e12-4415-8832-fa314d6759a3@github.com>
 <RyR2m1MR6UPKbcnxdi_tHwJvQxEtMhT-o2ljRTQDcEo=.976aa7a1-6706-4502-a150-5eb25dd744d1@github.com>
 <b7teCaJhFTu-4FHTyQqDwOqy1B1blXQaoowClBcqnTU=.d75b5dd9-050b-4137-b8fd-8b8e9171a6ca@github.com>
 <xc23wavVAM3Cu4YOo122ikO4FDNUeEx0O96jUobmrYM=.455b3ead-f83b-4956-9f0a-844b3f538b57@github.com>
Message-ID: <sB9RocumdcfW5wfgqxl6OJtPFS1xbsXHx8oBUzmkOOc=.e05ae7ca-9999-4f2b-9ab7-36021863f7e6@github.com>

On Thu, 15 Oct 2020 10:37:01 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> I appologise for writing this to already closed issue, but Christoph's approach seems to be applicable for at least
>> `AtomicInteger` and `AtomicLong`, because they are often explicitly zeroed at creation time (see one of my previous PRs
>> https://github.com/spring-projects/spring-framework/pull/25846) and there we have the same effect as in
>> `AtomicBoolean`: @State(Scope.Thread) @OutputTimeUnit(TimeUnit.NANOSECONDS) @BenchmarkMode(value = Mode.AverageTime)
>> public class AtomicBenchmark {
>>   @Benchmark
>>   public Object defaultValue() {
>>     return new AtomicInteger();
>>   }
>>   @Benchmark
>>   public Object explicitValue() {
>>     return new AtomicInteger(0);
>>   }
>> }
>> Semantically both new AtomicInteger() and new AtomicInteger(0) are the same, but explicitValue() is much slower:
>> Benchmark                      Mode  Cnt   Score   Error  Units
>> AtomicBenchmark.defaultValue   avgt   30   4.778 ? 0.403  ns/op
>> AtomicBenchmark.explicitValue  avgt   30  11.846 ? 0.273  ns/op
>> So the same pattern as we used here could be applied for `AtomicInteger`:
>> public AtomicInteger(int initialValue) {
>>   if (initialValue != 0 {
>>     value = initialValue;
>>   }
>> }
>> What do you think?
>
>> What do you think?
> 
> For `AtomicBoolean`, this optimization piggy-backed on an existing test, just rewriting it so that no action is taken
> when none is needed. So it's never a pessimization, and even improves bytecode size marginally. So it'll be a marginal
> gain even if the current overhead of writing to a volatile field in a constructor is removed/reduced.   For
> `AtomicInteger/-Long`, we'd have to add a test that's not there, so we'd pessimize non-zero cases by adding some
> bytecode and a branch to remove the overhead. An overhead that can already be avoided by calling the empty constructor
> instead. So I think it's questionable to do this.  In the short term we could consider a point fix to replace existing
> use of `new AtomicInteger/-Long(0)` with `new AtomicInteger/-Long()`, but in the long term we should really try and
> optimize our JITs so that writing to a volatile field in constructors can be made cheaper.

@stsypanov What Claes said: I explicitly only did it for `AtomicBoolean` as the conditional expression was already
present.

I don't think we should do it for the other Atomic classes for the mentioned reasons. Let's rather work on the JIT
compiler for future optimizations in this area. The `AtomicBoolean` was really just an exception.

-------------

PR: https://git.openjdk.java.net/jdk/pull/510

From github.com+10835776+stsypanov at openjdk.java.net  Thu Oct 15 12:12:18 2020
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Thu, 15 Oct 2020 12:12:18 GMT
Subject: RFR: 8254146: Avoid unnecessary volatile write on new
 AtomicBoolean(false)
In-Reply-To: <xc23wavVAM3Cu4YOo122ikO4FDNUeEx0O96jUobmrYM=.455b3ead-f83b-4956-9f0a-844b3f538b57@github.com>
References: <AzWKluHZjvFYm2wUanwYfn91iKKMacpk_qSsje3tXWk=.ba873b46-4e12-4415-8832-fa314d6759a3@github.com>
 <RyR2m1MR6UPKbcnxdi_tHwJvQxEtMhT-o2ljRTQDcEo=.976aa7a1-6706-4502-a150-5eb25dd744d1@github.com>
 <b7teCaJhFTu-4FHTyQqDwOqy1B1blXQaoowClBcqnTU=.d75b5dd9-050b-4137-b8fd-8b8e9171a6ca@github.com>
 <xc23wavVAM3Cu4YOo122ikO4FDNUeEx0O96jUobmrYM=.455b3ead-f83b-4956-9f0a-844b3f538b57@github.com>
Message-ID: <gvcLDkPPC4XuKqtAaSUiKhiRXWW0v_cQfnMsz22T3RI=.86f4cbcb-cd02-4e6a-98a9-120fa46cc497@github.com>

On Thu, 15 Oct 2020 10:37:01 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> I appologise for writing this to already closed issue, but Christoph's approach seems to be applicable for at least
>> `AtomicInteger` and `AtomicLong`, because they are often explicitly zeroed at creation time (see one of my previous PRs
>> https://github.com/spring-projects/spring-framework/pull/25846) and there we have the same effect as in
>> `AtomicBoolean`: @State(Scope.Thread) @OutputTimeUnit(TimeUnit.NANOSECONDS) @BenchmarkMode(value = Mode.AverageTime)
>> public class AtomicBenchmark {
>>   @Benchmark
>>   public Object defaultValue() {
>>     return new AtomicInteger();
>>   }
>>   @Benchmark
>>   public Object explicitValue() {
>>     return new AtomicInteger(0);
>>   }
>> }
>> Semantically both new AtomicInteger() and new AtomicInteger(0) are the same, but explicitValue() is much slower:
>> Benchmark                      Mode  Cnt   Score   Error  Units
>> AtomicBenchmark.defaultValue   avgt   30   4.778 ? 0.403  ns/op
>> AtomicBenchmark.explicitValue  avgt   30  11.846 ? 0.273  ns/op
>> So the same pattern as we used here could be applied for `AtomicInteger`:
>> public AtomicInteger(int initialValue) {
>>   if (initialValue != 0 {
>>     value = initialValue;
>>   }
>> }
>> What do you think?
>
>> What do you think?
> 
> For `AtomicBoolean`, this optimization piggy-backed on an existing test, just rewriting it so that no action is taken
> when none is needed. So it's never a pessimization, and even improves bytecode size marginally. So it'll be a marginal
> gain even if the current overhead of writing to a volatile field in a constructor is removed/reduced.   For
> `AtomicInteger/-Long`, we'd have to add a test that's not there, so we'd pessimize non-zero cases by adding some
> bytecode and a branch to remove the overhead. An overhead that can already be avoided by calling the empty constructor
> instead. So I think it's questionable to do this.  In the short term we could consider a point fix to replace existing
> use of `new AtomicInteger/-Long(0)` with `new AtomicInteger/-Long()`, but in the long term we should really try and
> optimize our JITs so that writing to a volatile field in constructors can be made cheaper.

@cl4es , @dreis2211 thanks for explanation!

-------------

PR: https://git.openjdk.java.net/jdk/pull/510

From aph at redhat.com  Thu Oct 15 12:41:28 2020
From: aph at redhat.com (Andrew Haley)
Date: Thu, 15 Oct 2020 13:41:28 +0100
Subject: RFR: 8254146: Avoid unnecessary volatile write on new
 AtomicBoolean(false)
In-Reply-To: <xc23wavVAM3Cu4YOo122ikO4FDNUeEx0O96jUobmrYM=.455b3ead-f83b-4956-9f0a-844b3f538b57@github.com>
References: <AzWKluHZjvFYm2wUanwYfn91iKKMacpk_qSsje3tXWk=.ba873b46-4e12-4415-8832-fa314d6759a3@github.com>
 <RyR2m1MR6UPKbcnxdi_tHwJvQxEtMhT-o2ljRTQDcEo=.976aa7a1-6706-4502-a150-5eb25dd744d1@github.com>
 <b7teCaJhFTu-4FHTyQqDwOqy1B1blXQaoowClBcqnTU=.d75b5dd9-050b-4137-b8fd-8b8e9171a6ca@github.com>
 <xc23wavVAM3Cu4YOo122ikO4FDNUeEx0O96jUobmrYM=.455b3ead-f83b-4956-9f0a-844b3f538b57@github.com>
Message-ID: <fb59ee83-e771-0b31-a671-fcff0a217c1a@redhat.com>

On 15/10/2020 11:41, Claes Redestad wrote:

> In the short term we could consider a point fix to replace existing
> use of `new AtomicInteger/-Long(0)` with `new
> AtomicInteger/-Long()`, but in the long term we should really try
> and optimize our JITs so that writing to a volatile field in
> constructors can be made cheaper.

I guess it all depends on whether there's a happens-before
relationship between the volatile store to Field X in a constructor
and any subsequent get() of Field X in another thread. Intuitively I
would have thought so, but I can't find any guarantee in the spec.
Nonetheless, I think we'd have little gain by changing this and it
might break (arguably incorrect) programs.

-- 
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 herrick at openjdk.java.net  Thu Oct 15 13:57:31 2020
From: herrick at openjdk.java.net (Andy Herrick)
Date: Thu, 15 Oct 2020 13:57:31 GMT
Subject: RFR: JDK-8252870: Finalize (remove "incubator" from) jpackage [v3]
In-Reply-To: <HlksY2mFyKG_kkZA6n6JHHIWBGJT3bjmoLG28c9q1EU=.2b9faa66-08b9-4694-a5db-9d9918039642@github.com>
References: <HlksY2mFyKG_kkZA6n6JHHIWBGJT3bjmoLG28c9q1EU=.2b9faa66-08b9-4694-a5db-9d9918039642@github.com>
Message-ID: <ChYJhfvRe0RMdj8jlPY6r7DEHplUhY-yaVZvlQzE5W0=.d14a30f5-f100-40a8-accd-db9910cdba32@github.com>

> JDK-8252870: Finalize (remove "incubator" from) jpackage

Andy Herrick has updated the pull request with a new target base due to a merge or a rebase. The pull request now
contains four commits:

 - Merge branch 'master' into JDK-8252870
 - JDK-8252870: Finalize (remove "incubator" from) jpackage
     - reverting two auto-generated files, and changing module-info to "@since 16"
 - JDK-8252870: Finalize (remove "incubator" from) jpackage
   Merge branch 'finalize' into JDK-8252870
 - 8252869 Finalize (remove incubator from) jpackage (implementation)

-------------

Changes: https://git.openjdk.java.net/jdk/pull/633/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=633&range=02
  Stats: 1733 lines in 259 files changed: 692 ins; 701 del; 340 mod
  Patch: https://git.openjdk.java.net/jdk/pull/633.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/633/head:pull/633

PR: https://git.openjdk.java.net/jdk/pull/633

From rriggs at openjdk.java.net  Thu Oct 15 13:58:21 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 15 Oct 2020 13:58:21 GMT
Subject: RFR: 8188055: (ref) Add Reference::refersTo predicate [v4]
In-Reply-To: <8qBXXAAjz3yFtVc4DXlKLOcTWit1X05U7kLC-_CfZo0=.08d6126d-e702-44e8-876e-111985c2b7b4@github.com>
References: <D4HSg8FT20Eaxk5KJkkw0GgETSxRkBn1ipS3Dt0kPto=.e4bab078-2e04-4413-90cb-9bfafb2a6831@github.com>
 <8qBXXAAjz3yFtVc4DXlKLOcTWit1X05U7kLC-_CfZo0=.08d6126d-e702-44e8-876e-111985c2b7b4@github.com>
Message-ID: <JCHPN7R7PBNnS4tUETseTFewP98S0L6mwg57Iwpsfu8=.7c7104bd-4f13-42bd-9762-fd9c425c3fc6@github.com>

On Thu, 15 Oct 2020 03:10:31 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Finally returning to this review that was started in April 2020.  I've
>> recast it as a github PR.  I think the security concern raised by Gil
>> has been adequately answered.
>> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-April/029203.html
>> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-July/030401.html
>> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-August/030677.html
>> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-September/030793.html
>> 
>> Please review a new function: java.lang.ref.Reference.refersTo.
>> 
>> This function is needed to test the referent of a Reference object without
>> artificially extending the lifetime of the referent object, as may happen
>> when calling Reference.get.  Some garbage collectors require extending the
>> lifetime of a weak referent when accessed, in order to maintain collector
>> invariants.  Lifetime extension may occur with any collector when the
>> Reference is a SoftReference, as calling get indicates recent access.  This
>> new function also allows testing the referent of a PhantomReference, which
>> can't be accessed by calling get.
>> 
>> The new function uses native methods whose implementations are in the VM so
>> they can use the Access API.  It is the intent that these methods will be
>> intrinsified by optimizing compilers like C2 or graal, but that hasn't been
>> implemented yet.  Bear that in mind before rushing off to change existing
>> uses of Reference.get.
>> 
>> There are two native methods involved, one in Reference and an override in
>> PhantomReference, both package private in java.lang.ref. The reason for this
>> split is to simplify the intrinsification. This is a change from the version
>> from April 2020; that version had a single native method in Reference,
>> implemented using the ON_UNKNOWN_OOP_REF Access reference strength category.
>> However, adding support for that category in the compilers adds significant
>> implementation effort and complexity. Splitting avoids that complexity.
>> 
>> Testing:
>> mach5 tier1
>> Locally (linux-x64) verified the new test passes with various garbage collectors.
>
> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More explicit refersTo0 comment.

Marked as reviewed by rriggs (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/498

From ccheung at openjdk.java.net  Thu Oct 15 15:54:31 2020
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Thu, 15 Oct 2020 15:54:31 GMT
Subject: RFR: 8247666: Support Lambda proxy classes in static CDS archive
 [v5]
In-Reply-To: <wuZkq-j9ciIYkjs25F7LG9-YDFaNzWysnHWQXLT-Z3s=.2f1d4107-586a-4756-bdac-21be9d60425b@github.com>
References: <ynh4JzHY75GjEn5_oCtmRNy9HMFsU34O2PlhSwD41tU=.1a3770f9-9091-429f-8d03-31b826f9b093@github.com>
 <PX8-qxYCB8jwJw8EongFi_2-HYdOkdNGkutskSoxulg=.1a85bb57-c65f-42c7-8def-a122ee150055@github.com>
 <wuZkq-j9ciIYkjs25F7LG9-YDFaNzWysnHWQXLT-Z3s=.2f1d4107-586a-4756-bdac-21be9d60425b@github.com>
Message-ID: <sMtQSaza8zNbU3qMi4cVzQKlr68jDs329IISRr1kj80=.cf51c537-6218-42c9-a4d9-d757b97517d0@github.com>

On Tue, 13 Oct 2020 23:59:38 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Calvin Cheung has updated the pull request with a new target base due to a merge or a rebase. The pull request now
>> contains ten commits:
>>  - fix minimal vm build issues
>>  - Merge branch 'master' into 8247666
>>  - Merge branch 'master' into 8247666
>>  - 1. Symbolic encoding of lambda proxy resolution. An example of @lambda-proxy in the classlist:
>>    @lambda-proxy: LambHello run ()Ljava/lang/Runnable; ()V 6 LambHello lambdabash ()V ()V
>>    2. Removed BadCPIndex.java; added LambdaProxyClassList.java test.
>>    3. Mandy's comments.
>>  - Merge branch 'master' into 8247666
>>  - exclude archived lambda proxy classes in the classlist
>>  - updated systemDictionaryShared.[c|h]pp based on suggestions from Ioi
>>  - fix extraneous whitespace
>>  - 8247666 (initial commit)
>
> src/hotspot/share/interpreter/linkResolver.cpp line 34:
> 
>> 32: #include "classfile/symbolTable.hpp"
>> 33: #include "classfile/systemDictionary.hpp"
>> 34: #include "classfile/systemDictionaryShared.hpp"
> 
> Are all the new includes necessary?

Those new includes are not needed. I've removed them.

> src/hotspot/share/memory/archiveUtils.cpp line 321:
> 
>> 319:     }
>> 320:   }
>> 321: }
> 
> I think if two threads try call ArchiveUtils::log_to_classlist at the same time, the output may be interleaved.
> 
> classlist_file is a fileStream, which uses fwrite to write to the file. In theory, if you write the whole line at once,
> the output should be thread safe (at least on POSIX and Windows). But in your case, you would need to first get the
> whole line into a buffer, and then write it out at once.  I think it would be safer, and more convenient, to use a lock
> to ensure thready safety. Maybe we can convert all uses of classlist_file->print() to something like
> class ClassListWriter {
>     static fileStream* _classlist_file;
>     MutexLocker locker;
> public:
>    outputStream* stream() {
>        return _classlist_file;
>    }
>    static bool is_enabled() {
>      return _classlist_file != NULL && _classlist_file->is_open();
>    }
>    ClassListWriter() :  locker(Thread::current(), ClassListFile_lock) {}
> 
>    static void init() {
>      // classlist_file init code from ostrea.cpp
>    }
> };
> 
> // WAS if (DumpLoadedClassList != NULL && classlist_file->is_open()) {
> if (ClassListWriter::is_enabled()) {
>   ClassListWriter w;
>   w->stream()->print("aaaa");
>   w->stream()->print("bbbb");
>   w->stream()->cr();
> }

I've added the ClassListWriter.hpp and changed other classes which operate on the classlist.

> src/hotspot/share/oops/instanceKlass.cpp line 4212:
> 
>> 4210:       assert(stream == NULL, "shared class with stream");
>> 4211:       if (is_hidden()) {
>> 4212:         // Not including archived lambda proxy class in the classlist.
> 
> I think it's clearer to say `// Don't include archived lambda proxy class in the classlist.`

Fixed.

> src/java.base/share/classes/jdk/internal/misc/CDS.java line 78:
> 
>> 76:      * Check if CDS dumping is enabled via the DynamicDumpSharedSpaces or the DumpSharedSpaces flag.
>> 77:      */
>> 78:     public static native boolean isDumpingEnabled();
> 
> I think it will be more consistent if we use the same pattern as `CDS::isDumpingClassList()`
> 
>     private static final boolean isDumpingArchive;
>     static {
>         isDumpingClassList = isDumpingArchive0();
>     }
> 
>     /**
>       * Is the VM writing to a (static or dynamic) CDS archive.
>       */
>     public static boolean isDumpingArchive() {
>         return isDumpingArchive;
>     }
> 
> Then in LambdaProxyClassArchive.java, there's no need to keep a separate variable of dumpArchive. You can simply call
> CDS.isDumpingArchive(). The JIT compiler will automatically inline the call so it will be just as fast.
> LambdaProxyClassArchive::sharingEnabled should also be rewritten to use this pattern.

I've changed the API's in CDS.java to be consistent with CDS.isDumpingClasslist.

-------------

PR: https://git.openjdk.java.net/jdk/pull/364

From ccheung at openjdk.java.net  Thu Oct 15 15:54:27 2020
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Thu, 15 Oct 2020 15:54:27 GMT
Subject: RFR: 8247666: Support Lambda proxy classes in static CDS archive
 [v6]
In-Reply-To: <ynh4JzHY75GjEn5_oCtmRNy9HMFsU34O2PlhSwD41tU=.1a3770f9-9091-429f-8d03-31b826f9b093@github.com>
References: <ynh4JzHY75GjEn5_oCtmRNy9HMFsU34O2PlhSwD41tU=.1a3770f9-9091-429f-8d03-31b826f9b093@github.com>
Message-ID: <kIugYBUY1dRZk9YmxX5kZ1IPm7EAn96Y9XtbRtDouBY=.181eecc1-0389-41a1-bc24-64fb99164873@github.com>

> Following up on archiving lambda proxy classes in dynamic CDS archive
> ([JDK-8198698](https://bugs.openjdk.java.net/browse/JDK-8198698)), this RFE adds the functionality of archiving of
> lambda proxy classes in static CDS archive.
> When the -XX:DumpLoadedClassList is enabled, the constant pool index related to LambdaMetafactory that are resolved
> during application execution will be included in the classlist. The entry for a lambda proxy class in a class list will
> be of the following format:
> `@lambda-proxy: <classname> <cp index>`
> 
> e.g.
> `@lambda-proxy: test/java/lang/invoke/MethodHandlesGeneralTest 233`
> `@lambda-proxy: test/java/lang/invoke/MethodHandlesGeneralTest 355`
> 
> When dumping a CDS archive using the -Xshare:dump and -XX:ExtraSharedClassListFile options, when the above
> `@lambda-proxy` entry is encountered while parsing the classlist, we will resolve the corresponding constant pool
> indices (233 and 355 in the above example). As a result, lambda proxy classes will be generated for the constant pool
> entries, and will be cached using a similar mechanism to JDK-8198698.  During dumping, there is check on the cp index
> and on the created BootstrapInfo using the cp index. VM will exit with an error message if the check has failed.
> During runtime when looking up a lambda proxy class, the lookup will be perform on the static CDS archive and if not
> found, then lookup from the dynamic archive if one is specified.  (Only name change (IsDynamicDumpingEnabled ->
> IsCDSDumpingEnabled) is involved in the core-libs code.)
> Testing: tiers 1,2,3,4.
> 
> Performance results (javac on HelloWorld on linux-x64):
> Results of " perf stat -r 40 bin/javac -J-Xshare:on -J-XX:SharedArchiveFile=javac2.jsa Bench_HelloWorld.java "
>    1:   2228016795  2067752708 (-160264087)      -----    377.760   349.110 (-28.650)      -----
>    2:   2223051476  2063016483 (-160034993)      -----    374.580   350.620 (-23.960)      ----
>    3:   2225908334  2067673847 (-158234487)      -----    375.220   350.990 (-24.230)      ----
>    4:   2225835999  2064596883 (-161239116)      -----    374.670   349.840 (-24.830)      ----
>    5:   2226005510  2061694332 (-164311178)      -----    373.512   351.120 (-22.392)      ----
>    6:   2225574949  2062657482 (-162917467)      -----    374.710   348.380 (-26.330)      -----
>    7:   2224702424  2064634122 (-160068302)      -----    373.670   349.510 (-24.160)      ----
>    8:   2226662277  2066301134 (-160361143)      -----    375.350   349.790 (-25.560)      ----
>    9:   2226761470  2063162795 (-163598675)      -----    374.260   351.290 (-22.970)      ----
>   10:   2230149089  2066203307 (-163945782)      -----    374.760   350.620 (-24.140)      ----
> ============================================================
>         2226266109  2064768307 (-161497801)      -----    374.848   350.126 (-24.722)      ----
> instr delta =   -161497801    -7.2542%
> time  delta =      -24.722 ms -6.5951%

Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:

  Changes based on Ioi's suggestions:
  1. Added the ClassListWriter class to make writing to a classlist file thread safe;
  2. Changed API's in CDS.java to be more consistent with CDS.isDumpingClasslist.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/364/files
  - new: https://git.openjdk.java.net/jdk/pull/364/files/218d4484..fd4f563b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=364&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=364&range=04-05

  Stats: 183 lines in 13 files changed: 112 ins; 50 del; 21 mod
  Patch: https://git.openjdk.java.net/jdk/pull/364.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/364/head:pull/364

PR: https://git.openjdk.java.net/jdk/pull/364

From ccheung at openjdk.java.net  Thu Oct 15 16:02:15 2020
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Thu, 15 Oct 2020 16:02:15 GMT
Subject: RFR: 8254192: ExtraSharedClassListFile contains extra white space
 at end of line [v2]
In-Reply-To: <uufPGPiY3XiM3aFPy4s6re0CaqoI9FIqPofP9CGkajs=.5fcf0594-f837-4224-b8a5-6ae581d750ed@github.com>
References: <0LTIfmJUJ1A68tgQsBqhx1WWomwtXr2ogZE9MF_kVAc=.86bb7579-248a-4370-bcee-a52587c5f90b@github.com>
 <uufPGPiY3XiM3aFPy4s6re0CaqoI9FIqPofP9CGkajs=.5fcf0594-f837-4224-b8a5-6ae581d750ed@github.com>
Message-ID: <7AQu7SAGozjdhd6SsivW2Bx22pgOK7T5g2PdpkQ6D8c=.4146bd8d-b4d2-4b22-b796-a2e3c9238597@github.com>

On Thu, 15 Oct 2020 01:04:25 GMT, Yumin Qi <minqi at openjdk.org> wrote:

>> Hi, Please review the simple change.
>> 
>>   The removing of white spaces from end of line in ClassListParser should be moved to before we add lambda-form-invoker
>>   line to array.  After made such arrangement, changed CDS.java for trimming line code.
>> 
>> Tests: local test on runtime/cds/appcds. Mach5 tier1,4 is in progress.
>> 
>> Thanks
>
> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comment adding \f for Replace

Looks good.

-------------

Marked as reviewed by ccheung (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/669

From psandoz at openjdk.java.net  Thu Oct 15 16:02:20 2020
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Thu, 15 Oct 2020 16:02:20 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v4]
In-Reply-To: <7XjzEn5DggliDrvjhrGwXZL5r4lsqeGF9SGLmRr5L84=.a4481a62-4ecf-4e3f-98f3-70e548c67b52@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <45FtTQB1m6HyZSASY42STMkQffIWlVPibWn9_r00xYs=.daad2653-2571-491f-8dd7-5954fe4ece00@github.com>
 <u6HLR2PyvWgYbA58W3bCF4n38tpwQu2-ujPMvGpyyuo=.5a80f17c-83d5-4dc9-bad0-00e679fdd4be@github.com>
 <7-p-Kc9lQyyuoWdNtmgbXbwkxsgk4oQGKmFSCcMpvnU=.97810c01-3200-4767-bbd4-35d53c2bc5ca@github.com>
 <6Voyfr_s-ieyRA-8Rtvvpz7tkhhicA8sY2d2KTp3Kmw=.fa256bae-2143-4b43-bfea-5837ad31eb6a@github.com>
 <fFQfDMqdwosVGzcaJfblklUy1nPsEdZJI7ALmKq9XJs=.e869160e-76e7-4a6b-b45b-e9763d1ad06f@github.com>
 <vKcE4CeascBAQGeyu6is0Va0_k4aTrvgU41cjhG6Wdo=.4078814f-06ed-4978-9fcd-a4a5148c2bdc@github.com>
 <wQ6YtDhYzmcgpTUP4uFfBCo8UFWZENtTARWt_LTqPug=.30bc3fdb-f963-4918-ae4b-0fe174c38a23@github.com>
 <jqzI94j7kygJyD9HWwq5d3q3LGztS5FAdYm5Ix1QdjE=.808de4e6-0f6d-4e17-b807-25ef89e92541@github.com>
 <7XjzEn5DggliDrvjhrGwXZL5r4lsqeGF9SGLmRr5L84=.a4481a62-4ecf-4e3f-98f3-70e548c67b52@github.com>
Message-ID: <9y5m4zfsDZMdIZ6CT38BzO0tpFMuFxUswAbpjfDny-w=.44c7ada7-bf77-45f1-b5a6-b542731d6685@github.com>

On Wed, 14 Oct 2020 21:29:55 GMT, CoreyAshford <github.com+51754783+CoreyAshford at openjdk.org> wrote:

>> Hi Corey,
>> 
>>> Are you thinking of a case where that produces a higher iteration count?
>> Sorry for the confusion. This is also fine:
>> length = sl - sp - 12
>> i = length / block_size
>> if (i <= 0) return 0
>> 
>> But I still wonder why we should use 2 branches. Why not
>> srawi_
>> ble(CCR0, return_zero)
>> ?
>> 
>>> Ah, I should have checked the calling conventions. I thought all of the CR* regs are volatile. I will fix that.
>> Actually, we do save and restore all CRs, so it?s not a real problem with the current implementation. But I prefer
>> staying closer to the elf ABI as long as there?s no good reason to do it differently.
>>> Your original comment said "2nd review", so I thought you meant you need to review it again after the changes.
>> We usually require at least 2 reviews by different people for all non-trivial changes. And I don?t consider the PPC64
>> part as trivial. In addition to that, I?m not familiar with Power 10.
>> Best regards,
>> Martin
>> 
>> 
>> From: CoreyAshford <notifications at github.com>
>> Sent: Dienstag, 13. Oktober 2020 22:59
>> To: openjdk/jdk <jdk at noreply.github.com>
>> Cc: Doerr, Martin <martin.doerr at sap.com>; Mention <mention at noreply.github.com>
>> Subject: Re: [openjdk/jdk] 8248188: Add IntrinsicCandidate and API for Base64 decoding (#293)
>> 
>> 
>> Hi Corey, thanks for taking some stuff out of the ?too short? path. There may be a performance regression when decoding
>> many short arrays because of the stub call overhead and the usage of the slower part of the Java implementation. We
>> could do it a little better in many cases to compute the maximum possible iteration count i: i = (sl - sp) / block_size
>> if (i * block_size > sl - 12) i-- if (i <= 0) return 0 What do you think?  Are you thinking of a case where that
>> produces a higher iteration count? It looks effectively the same to me.  I don?t think branch prediction hints are
>> helpful for the ?too short? check.
>> My thinking is that most of the time when the intrinsic is called, it will not take the early exit, but I suppose when
>> it is processing a sub-block_size buffer, it will return early every time. I will remove the hints.
>> And we should better use CCR1 instead of CCR2 which is specified as non-volatile.
>> 
>> Ah, I should have checked the calling conventions. I thought all of the CR* regs are volatile. I will fix that.
>> 
>> Did you already find a 2nd reviewer for the PPC64 part?
>> 
>> Your original comment said "2nd review", so I thought you meant you need to review it again after the changes. So, no,
>> I haven't looked for or found a second reviewer. Any suggestions? The folks on the team here have been busy with other
>> work.  Btw, I'm off today, so I will push commits to the above-mentioned issues tomorrow.
>> 
>> ?
>> You are receiving this because you were mentioned.
>> Reply to this email directly, view it on GitHub<https://github.com/openjdk/jdk/pull/293#issuecomment-708005545>, or
>> unsubscribe<https://github.com/notifications/unsubscribe-auth/AKR64KC2K7IZFAPXVQIVYZDSKS5SLANCNFSM4RVHNW5Q>.
>
>> Hi Corey,
>> Are you thinking of a case where that produces a higher iteration count?
>> Sorry for the confusion. This is also fine: length = sl - sp - 12 i = length / block_size if (i <= 0) return 0 But I
>> still wonder why we should use 2 branches. Why not srawi_ ble(CCR0, return_zero) ?
> 
> You're right!  I originally thought that the `srawi.` was setting only the Zero bit, but it sets others as well.
> 
>> Ah, I should have checked the calling conventions. I thought all of the CR* regs are volatile. I will fix that.
>> Actually, we do save and restore all CRs, so it?s not a real problem with the current implementation. But I prefer
>> staying closer to the elf ABI as long as there?s no good reason to do it differently.
> 
> Looks like I don't need that code at all now, but it's good to know for the future; I have an encode intrinsic in the
> works.
>> Your original comment said "2nd review", so I thought you meant you need to review it again after the changes.
>> We usually require at least 2 reviews by different people for all non-trivial changes. And I don?t consider the PPC64
>> part as trivial. In addition to that, I?m not familiar with Power 10.
> 
> I received permission to request help from the GNU toolchain team here to review it.  Due to family issues and work
> schedule on my end, it will be at least the middle of next week before I can get a reviewer to have a look.
> Thanks for your continued patience and help.

Please update
[compiler/graalunit/HotspotTest.java](https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/compiler/graalunit/HotspotTest.java),
and add the intrinsic signature.

-------------

PR: https://git.openjdk.java.net/jdk/pull/293

From mcimadamore at openjdk.java.net  Thu Oct 15 16:20:25 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 15 Oct 2020 16:20:25 GMT
Subject: RFR: 8254231: Implementation of Foreign Linker API (Incubator)
 [v2]
In-Reply-To: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
References: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
Message-ID: <8CkvfiM_PR0iDEo-tgUNRXWlG-qDwEDN2Qd15pbgQ0E=.353d8045-3593-4c72-9d81-c290b43ca89c@github.com>

> This patch contains the changes associated with the first incubation round of the foreign linker access API incubation
> (see JEP 389 [1]). This work is meant to sit on top of the foreign memory access support (see JEP 393 [2] and
> associated pull request [3]).
> The main goal of this API is to provide a way to call native functions from Java code without the need of intermediate
> JNI glue code. In order to do this, native calls are modeled through the MethodHandle API. I suggest reading the
> writeup [4] I put together few weeks ago, which illustrates what the foreign linker support is, and how it should be
> used by clients.  Disclaimer: the pull request mechanism isn't great at managing *dependent* reviews. For this reasons,
> I'm attaching a webrev which contains only the differences between this PR and the memory access PR. I will be
> periodically uploading new webrevs, as new iterations come out, to try and make the life of reviewers as simple as
> possible.  A big thank to Jorn Vernee and Vladimir Ivanov - they are the main architects of all the hotspot changes you
> see here, and without their help, the foreign linker support wouldn't be what it is today. As usual, a big thank to
> Paul Sandoz, who provided many insights (often by trying the bits first hand).  Thanks Maurizio
> Webrev:
> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/webrev
> 
> Javadoc:
> 
> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/javadoc/jdk/incubator/foreign/package-summary.html
> 
> Specdiff (relative to [3]):
> 
> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/specdiff_delta/overview-summary.html
> 
> CSR:
> 
> https://bugs.openjdk.java.net/browse/JDK-8254232
> 
> 
> 
> ### API Changes
> 
> The API changes are actually rather slim:
> 
> * `LibraryLookup`
>   * This class allows clients to lookup symbols in native libraries; the interface is fairly simple; you can load a library
>     by name, or absolute path, and then lookup symbols on that library.
> * `FunctionDescriptor`
>   * This is an abstraction that is very similar, in spirit, to `MethodType`; it is, at its core, an aggregate of memory
>     layouts for the function arguments/return type. A function descriptor is used to describe the signature of a native
>     function.
> * `CLinker`
>   * This is the real star of the show. A `CLinker` has two main methods: `downcallHandle` and `upcallStub`; the first takes
>     a native symbol (as obtained from `LibraryLookup`), a `MethodType` and a `FunctionDescriptor` and returns a
>     `MethodHandle` instance which can be used to call the target native symbol. The second takes an existing method handle,
>     and a `FunctionDescriptor` and returns a new `MemorySegment` corresponding to a code stub allocated by the VM which
>     acts as a trampoline from native code to the user-provided method handle. This is very useful for implementing upcalls.
>    * This class also contains the various layout constants that should be used by clients when describing native signatures
>      (e.g. `C_LONG` and friends); these layouts contain additional ABI classfication information (in the form of layout
>      attributes) which is used by the runtime to *infer* how Java arguments should be shuffled for the native call to take
>      place.
>   * Finally, this class provides some helper functions e.g. so that clients can convert Java strings into C strings and
>     back.
> * `NativeScope`
>   * This is an helper class which allows clients to group together logically related allocations; that is, rather than
>     allocating separate memory segments using separate *try-with-resource* constructs, a `NativeScope` allows clients to
>     use a _single_ block, and allocate all the required segments there. This is not only an usability boost, but also a
>     performance boost, since not all allocation requests will be turned into `malloc` calls.
> * `MemorySegment`
>   * Only one method added here - namely `handoff(NativeScope)` which allows a segment to be transferred onto an existing
>     native scope.
> 
> ### Safety
> 
> The foreign linker API is intrinsically unsafe; many things can go wrong when requesting a native method handle. For
> instance, the description of the native signature might be wrong (e.g. have too many arguments) - and the runtime has,
> in the general case, no way to detect such mismatches. For these reasons, obtaining a `CLinker` instance is
> a *restricted* operation, which can be enabled by specifying the usual JDK property `-Dforeign.restricted=permit` (as
> it's the case for other restricted method in the foreign memory API).  ### Implementation changes  The Java changes
> associated with `LibraryLookup` are relative straightforward; the only interesting thing to note here is that library
> loading does _not_ depend on class loaders, so `LibraryLookup` is not subject to the same restrictions which apply to
> JNI library loading (e.g. same library cannot be loaded by different classloaders).  As for `NativeScope` the changes
> are again relatively straightforward; it is an API which sits neatly on top of the foreign meory access API, providing
> some kind of allocation service which shares the same underlying memory segment(s), and turns an allocation request
> into a segment slice, which is a much less expensive operation. `NativeScope` comes in two variants: there are native
> scopes for which the allocation size is known a priori, and native scopes which can grow - these two schemes are
> implemented by two separate subclasses of `AbstractNativeScopeImpl`.  Of course the bulk of the changes are to support
> the `CLinker` downcall/upcall routines. These changes cut pretty deep into the JVM; I'll briefly summarize the goal of
> some of this changes - for further details, Jorn has put together a detailed writeup which explains the rationale
> behind the VM support, with some references to the code [5].  The main idea behind foreign linker is to infer, given a
> Java method type (expressed as a `MethodType` instance) and the description of the signature of a native function
> (expressed as a `FunctionDescriptor` instance) a _recipe_ that can be used to turn a Java call into the corresponding
> native call targeting the requested native function.  This inference scheme can be defined in a pretty straightforward
> fashion by looking at the various ABI specifications (for instance, see [6] for the SysV ABI, which is the one used on
> Linux/Mac). The various `CallArranger` classes, of which we have a flavor for each supported platform, do exactly that
> kind of inference.  For the inference process to work, we need to attach extra information to memory layouts; it is no
> longer sufficient to know e.g. that a layout is 32/64 bits - we need to know whether it is meant to represent a
> floating point value, or an integral value; this knowledge is required because floating points are passed in different
> registers by most ABIs. For this reason, `CLinker` offers a set of pre-baked, platform-dependent layout constants which
> contain the required classification attributes (e.g. a `Clinker.TypeKind` enum value). The runtime extracts this
> attribute, and performs classification accordingly.  A native call is decomposed into a sequence of basic, primitive
> operations, called `Binding` (see the great javadoc on the `Binding.java` class for more info). There are many such
> bindings - for instance the `Move` binding is used to move a value into a specific machine register/stack slot. So, the
> main job of the various `CallingArranger` classes is to determine, given a Java `MethodType` and `FunctionDescriptor`
> what is the set of bindings associated with the downcall/upcall.  At the heart of the foreign linker support is the
> `ProgrammableInvoker` class. This class effectively generates a `MethodHandle` which follows the steps described by the
> various bindings obtained by `CallArranger`. There are actually various strategies to interpret these bindings - listed
> below:
> * basic intepreted mode; in this mode, all bindings are interpreted using a stack-based machine written in Java (see
>   `BindingInterpreter`), except for the `Move` bindings. For these bindings, the move is implemented by allocating
>   a *buffer* (whose size is ABI specific) and by moving all the lowered values into positions within this buffer. The
>   buffer is then passed to a piece of assembly code inside the VM which takes values from the buffer and moves them in
>   their expected registers/stack slots (note that each position in the buffer corresponds to a different register). This
>   is the most general invocation mode, the more "customizable" one, but also the slowest - since for every call there is
>   some extra allocation which takes place.
> 
> * specialized interpreted mode; same as before, but instead of interpreting the bindings with a stack-based interpreter,
>   we generate a method handle chain which effectively interprets all the bindings (again, except `Move` ones).
> 
> * intrinsified mode; this is typically used in combination with the specialized interpreted mode described above
>   (although it can also be used with the Java-based binding interpreter). The goal here is to remove the buffer
>   allocation and copy by introducing an additional JVM intrinsic. If a native call recipe is constant (e.g. the set of
>   bindings is constant, which is probably the case if the native method handle is stored in a `static`, `final` field),
>   then the VM can generate specialized assembly code which interprets the `Move` binding without the need to go for an
>   intermediate buffer. This gives us back performances that are on par with JNI.
> 
> For upcalls, the support is not (yet) as advanced, and only the basic interpreted mode is available there. We plan to
> add support for intrinsified modes there as well, which should considerably boost perfomances (probably well beyond
> what JNI can offer at the moment, since the upcall support in JNI is not very well optimized).  Again, for more
> readings on the internals of the foreign linker support, please refer to [5].
> #### Test changes
> 
> Many new tests have been added to validate the foreign linker support; we have high level tests (see `StdLibTest`)
> which aim at testing the linker from the perspective of code that clients could write. But we also have deeper
> combinatorial tests (see `TestUpcall` and `TestDowncall`) which are meant to stress every corner of the ABI
> implementation. There are also some great tests (see the `callarranger` folder) which test the various `CallArranger`s
> for all the possible platforms; these tests adopt more of a white-box approach - that is, instead of treating the
> linker machinery as a black box and verify that the support works by checking that the native call returned the results
> we expected, these tests aims at checking that the set of bindings generated by the call arranger is correct. This also
> mean that we can test the classification logic for Windows, Mac and Linux regardless of the platform we're executing
> on.  Some additional microbenchmarks have been added to compare the performances of downcall/upcall with JNI.  [1] -
> https://openjdk.java.net/jeps/389 [2] - https://openjdk.java.net/jeps/393 [3] -
> https://git.openjdk.java.net/jdk/pull/548 [4] -
> https://github.com/openjdk/panama-foreign/blob/foreign-jextract/doc/panama_ffi.md [5] -
> http://cr.openjdk.java.net/~jvernee/docs/Foreign-abi%20downcall%20intrinsics%20technical%20description.html

Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request
now contains 19 commits:

 - Merge branch 'master' into 8254231_linker
   
   - Fix tests
 - Fix more whitespaces
 - Fix whitespaces
 - Remove rejected file
 - More updates
 - Add new files
 - Merge with master
 - Merge branch 'master' into 8254162
 - Remove spurious check on MemoryScope::confineTo
   Added tests to make sure no spurious exception is thrown when:
   * handing off a segment from A to A
   * sharing an already shared segment
 - Merge branch 'master' into 8254162
 - ... and 9 more: https://git.openjdk.java.net/jdk/compare/3c2f5e08...ad8bee12

-------------

Changes: https://git.openjdk.java.net/jdk/pull/634/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=634&range=01
  Stats: 84781 lines in 279 files changed: 72658 ins; 10861 del; 1262 mod
  Patch: https://git.openjdk.java.net/jdk/pull/634.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/634/head:pull/634

PR: https://git.openjdk.java.net/jdk/pull/634

From mcimadamore at openjdk.java.net  Thu Oct 15 16:32:03 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 15 Oct 2020 16:32:03 GMT
Subject: RFR: 8254231: Implementation of Foreign Linker API (Incubator)
 [v3]
In-Reply-To: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
References: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
Message-ID: <4w2EB316f1EZC9b-zMmHIa1xqQL6Jw0-Vif_CXzkDS4=.16eaa7d6-f59b-4622-8b34-b9df57d63f45@github.com>

> This patch contains the changes associated with the first incubation round of the foreign linker access API incubation
> (see JEP 389 [1]). This work is meant to sit on top of the foreign memory access support (see JEP 393 [2] and
> associated pull request [3]).
> The main goal of this API is to provide a way to call native functions from Java code without the need of intermediate
> JNI glue code. In order to do this, native calls are modeled through the MethodHandle API. I suggest reading the
> writeup [4] I put together few weeks ago, which illustrates what the foreign linker support is, and how it should be
> used by clients.  Disclaimer: the pull request mechanism isn't great at managing *dependent* reviews. For this reasons,
> I'm attaching a webrev which contains only the differences between this PR and the memory access PR. I will be
> periodically uploading new webrevs, as new iterations come out, to try and make the life of reviewers as simple as
> possible.  A big thank to Jorn Vernee and Vladimir Ivanov - they are the main architects of all the hotspot changes you
> see here, and without their help, the foreign linker support wouldn't be what it is today. As usual, a big thank to
> Paul Sandoz, who provided many insights (often by trying the bits first hand).  Thanks Maurizio
> Webrev:
> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/webrev
> 
> Javadoc:
> 
> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/javadoc/jdk/incubator/foreign/package-summary.html
> 
> Specdiff (relative to [3]):
> 
> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/specdiff_delta/overview-summary.html
> 
> CSR:
> 
> https://bugs.openjdk.java.net/browse/JDK-8254232
> 
> 
> 
> ### API Changes
> 
> The API changes are actually rather slim:
> 
> * `LibraryLookup`
>   * This class allows clients to lookup symbols in native libraries; the interface is fairly simple; you can load a library
>     by name, or absolute path, and then lookup symbols on that library.
> * `FunctionDescriptor`
>   * This is an abstraction that is very similar, in spirit, to `MethodType`; it is, at its core, an aggregate of memory
>     layouts for the function arguments/return type. A function descriptor is used to describe the signature of a native
>     function.
> * `CLinker`
>   * This is the real star of the show. A `CLinker` has two main methods: `downcallHandle` and `upcallStub`; the first takes
>     a native symbol (as obtained from `LibraryLookup`), a `MethodType` and a `FunctionDescriptor` and returns a
>     `MethodHandle` instance which can be used to call the target native symbol. The second takes an existing method handle,
>     and a `FunctionDescriptor` and returns a new `MemorySegment` corresponding to a code stub allocated by the VM which
>     acts as a trampoline from native code to the user-provided method handle. This is very useful for implementing upcalls.
>    * This class also contains the various layout constants that should be used by clients when describing native signatures
>      (e.g. `C_LONG` and friends); these layouts contain additional ABI classfication information (in the form of layout
>      attributes) which is used by the runtime to *infer* how Java arguments should be shuffled for the native call to take
>      place.
>   * Finally, this class provides some helper functions e.g. so that clients can convert Java strings into C strings and
>     back.
> * `NativeScope`
>   * This is an helper class which allows clients to group together logically related allocations; that is, rather than
>     allocating separate memory segments using separate *try-with-resource* constructs, a `NativeScope` allows clients to
>     use a _single_ block, and allocate all the required segments there. This is not only an usability boost, but also a
>     performance boost, since not all allocation requests will be turned into `malloc` calls.
> * `MemorySegment`
>   * Only one method added here - namely `handoff(NativeScope)` which allows a segment to be transferred onto an existing
>     native scope.
> 
> ### Safety
> 
> The foreign linker API is intrinsically unsafe; many things can go wrong when requesting a native method handle. For
> instance, the description of the native signature might be wrong (e.g. have too many arguments) - and the runtime has,
> in the general case, no way to detect such mismatches. For these reasons, obtaining a `CLinker` instance is
> a *restricted* operation, which can be enabled by specifying the usual JDK property `-Dforeign.restricted=permit` (as
> it's the case for other restricted method in the foreign memory API).  ### Implementation changes  The Java changes
> associated with `LibraryLookup` are relative straightforward; the only interesting thing to note here is that library
> loading does _not_ depend on class loaders, so `LibraryLookup` is not subject to the same restrictions which apply to
> JNI library loading (e.g. same library cannot be loaded by different classloaders).  As for `NativeScope` the changes
> are again relatively straightforward; it is an API which sits neatly on top of the foreign meory access API, providing
> some kind of allocation service which shares the same underlying memory segment(s), and turns an allocation request
> into a segment slice, which is a much less expensive operation. `NativeScope` comes in two variants: there are native
> scopes for which the allocation size is known a priori, and native scopes which can grow - these two schemes are
> implemented by two separate subclasses of `AbstractNativeScopeImpl`.  Of course the bulk of the changes are to support
> the `CLinker` downcall/upcall routines. These changes cut pretty deep into the JVM; I'll briefly summarize the goal of
> some of this changes - for further details, Jorn has put together a detailed writeup which explains the rationale
> behind the VM support, with some references to the code [5].  The main idea behind foreign linker is to infer, given a
> Java method type (expressed as a `MethodType` instance) and the description of the signature of a native function
> (expressed as a `FunctionDescriptor` instance) a _recipe_ that can be used to turn a Java call into the corresponding
> native call targeting the requested native function.  This inference scheme can be defined in a pretty straightforward
> fashion by looking at the various ABI specifications (for instance, see [6] for the SysV ABI, which is the one used on
> Linux/Mac). The various `CallArranger` classes, of which we have a flavor for each supported platform, do exactly that
> kind of inference.  For the inference process to work, we need to attach extra information to memory layouts; it is no
> longer sufficient to know e.g. that a layout is 32/64 bits - we need to know whether it is meant to represent a
> floating point value, or an integral value; this knowledge is required because floating points are passed in different
> registers by most ABIs. For this reason, `CLinker` offers a set of pre-baked, platform-dependent layout constants which
> contain the required classification attributes (e.g. a `Clinker.TypeKind` enum value). The runtime extracts this
> attribute, and performs classification accordingly.  A native call is decomposed into a sequence of basic, primitive
> operations, called `Binding` (see the great javadoc on the `Binding.java` class for more info). There are many such
> bindings - for instance the `Move` binding is used to move a value into a specific machine register/stack slot. So, the
> main job of the various `CallingArranger` classes is to determine, given a Java `MethodType` and `FunctionDescriptor`
> what is the set of bindings associated with the downcall/upcall.  At the heart of the foreign linker support is the
> `ProgrammableInvoker` class. This class effectively generates a `MethodHandle` which follows the steps described by the
> various bindings obtained by `CallArranger`. There are actually various strategies to interpret these bindings - listed
> below:
> * basic intepreted mode; in this mode, all bindings are interpreted using a stack-based machine written in Java (see
>   `BindingInterpreter`), except for the `Move` bindings. For these bindings, the move is implemented by allocating
>   a *buffer* (whose size is ABI specific) and by moving all the lowered values into positions within this buffer. The
>   buffer is then passed to a piece of assembly code inside the VM which takes values from the buffer and moves them in
>   their expected registers/stack slots (note that each position in the buffer corresponds to a different register). This
>   is the most general invocation mode, the more "customizable" one, but also the slowest - since for every call there is
>   some extra allocation which takes place.
> 
> * specialized interpreted mode; same as before, but instead of interpreting the bindings with a stack-based interpreter,
>   we generate a method handle chain which effectively interprets all the bindings (again, except `Move` ones).
> 
> * intrinsified mode; this is typically used in combination with the specialized interpreted mode described above
>   (although it can also be used with the Java-based binding interpreter). The goal here is to remove the buffer
>   allocation and copy by introducing an additional JVM intrinsic. If a native call recipe is constant (e.g. the set of
>   bindings is constant, which is probably the case if the native method handle is stored in a `static`, `final` field),
>   then the VM can generate specialized assembly code which interprets the `Move` binding without the need to go for an
>   intermediate buffer. This gives us back performances that are on par with JNI.
> 
> For upcalls, the support is not (yet) as advanced, and only the basic interpreted mode is available there. We plan to
> add support for intrinsified modes there as well, which should considerably boost perfomances (probably well beyond
> what JNI can offer at the moment, since the upcall support in JNI is not very well optimized).  Again, for more
> readings on the internals of the foreign linker support, please refer to [5].
> #### Test changes
> 
> Many new tests have been added to validate the foreign linker support; we have high level tests (see `StdLibTest`)
> which aim at testing the linker from the perspective of code that clients could write. But we also have deeper
> combinatorial tests (see `TestUpcall` and `TestDowncall`) which are meant to stress every corner of the ABI
> implementation. There are also some great tests (see the `callarranger` folder) which test the various `CallArranger`s
> for all the possible platforms; these tests adopt more of a white-box approach - that is, instead of treating the
> linker machinery as a black box and verify that the support works by checking that the native call returned the results
> we expected, these tests aims at checking that the set of bindings generated by the call arranger is correct. This also
> mean that we can test the classification logic for Windows, Mac and Linux regardless of the platform we're executing
> on.  Some additional microbenchmarks have been added to compare the performances of downcall/upcall with JNI.  [1] -
> https://openjdk.java.net/jeps/389 [2] - https://openjdk.java.net/jeps/393 [3] -
> https://git.openjdk.java.net/jdk/pull/548 [4] -
> https://github.com/openjdk/panama-foreign/blob/foreign-jextract/doc/panama_ffi.md [5] -
> http://cr.openjdk.java.net/~jvernee/docs/Foreign-abi%20downcall%20intrinsics%20technical%20description.html

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Re-add erroneously removed files

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/634/files
  - new: https://git.openjdk.java.net/jdk/pull/634/files/ad8bee12..2184831e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=634&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=634&range=01-02

  Stats: 9218 lines in 14 files changed: 9218 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/634.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/634/head:pull/634

PR: https://git.openjdk.java.net/jdk/pull/634

From minqi at openjdk.java.net  Thu Oct 15 16:51:18 2020
From: minqi at openjdk.java.net (Yumin Qi)
Date: Thu, 15 Oct 2020 16:51:18 GMT
Subject: RFR: 8254192: ExtraSharedClassListFile contains extra white space
 at end of line [v2]
In-Reply-To: <7AQu7SAGozjdhd6SsivW2Bx22pgOK7T5g2PdpkQ6D8c=.4146bd8d-b4d2-4b22-b796-a2e3c9238597@github.com>
References: <0LTIfmJUJ1A68tgQsBqhx1WWomwtXr2ogZE9MF_kVAc=.86bb7579-248a-4370-bcee-a52587c5f90b@github.com>
 <uufPGPiY3XiM3aFPy4s6re0CaqoI9FIqPofP9CGkajs=.5fcf0594-f837-4224-b8a5-6ae581d750ed@github.com>
 <7AQu7SAGozjdhd6SsivW2Bx22pgOK7T5g2PdpkQ6D8c=.4146bd8d-b4d2-4b22-b796-a2e3c9238597@github.com>
Message-ID: <rXYaBNKX4-rbRQwR76p0faMC6Yf0fY231vBuroXdgz0=.6c9c591e-3983-43e5-8d24-13837aad8994@github.com>

On Thu, 15 Oct 2020 15:59:31 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix comment adding \f for Replace
>
> Looks good.

Thanks @iklam and @calvinccheung  for the review.

-------------

PR: https://git.openjdk.java.net/jdk/pull/669

From mchung at openjdk.java.net  Thu Oct 15 16:51:14 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Thu, 15 Oct 2020 16:51:14 GMT
Subject: RFR: 8254192: ExtraSharedClassListFile contains extra white space
 at end of line [v2]
In-Reply-To: <uufPGPiY3XiM3aFPy4s6re0CaqoI9FIqPofP9CGkajs=.5fcf0594-f837-4224-b8a5-6ae581d750ed@github.com>
References: <0LTIfmJUJ1A68tgQsBqhx1WWomwtXr2ogZE9MF_kVAc=.86bb7579-248a-4370-bcee-a52587c5f90b@github.com>
 <uufPGPiY3XiM3aFPy4s6re0CaqoI9FIqPofP9CGkajs=.5fcf0594-f837-4224-b8a5-6ae581d750ed@github.com>
Message-ID: <70iL1k-EDQrm_m9xE6UTJ_gd5hZ0qCsZlN8_kKqfQ2I=.c40d262f-61fc-4e9d-97ae-caee7d114451@github.com>

On Thu, 15 Oct 2020 01:04:25 GMT, Yumin Qi <minqi at openjdk.org> wrote:

>> Hi, Please review the simple change.
>> 
>>   The removing of white spaces from end of line in ClassListParser should be moved to before we add lambda-form-invoker
>>   line to array.  After made such arrangement, changed CDS.java for trimming line code.
>> 
>> Tests: local test on runtime/cds/appcds. Mach5 tier1,4 is in progress.
>> 
>> Thanks
>
> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comment adding \f for Replace

Marked as reviewed by mchung (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/669

From minqi at openjdk.java.net  Thu Oct 15 16:51:20 2020
From: minqi at openjdk.java.net (Yumin Qi)
Date: Thu, 15 Oct 2020 16:51:20 GMT
Subject: Integrated: 8254192: ExtraSharedClassListFile contains extra white
 space at end of line
In-Reply-To: <0LTIfmJUJ1A68tgQsBqhx1WWomwtXr2ogZE9MF_kVAc=.86bb7579-248a-4370-bcee-a52587c5f90b@github.com>
References: <0LTIfmJUJ1A68tgQsBqhx1WWomwtXr2ogZE9MF_kVAc=.86bb7579-248a-4370-bcee-a52587c5f90b@github.com>
Message-ID: <4-QBKg5Sv7c0q3ZMxoSIHzHgcaBs28fu32ZsDYubOcs=.cd99fe58-f8af-4448-a210-e7c4accc123b@github.com>

On Wed, 14 Oct 2020 22:09:50 GMT, Yumin Qi <minqi at openjdk.org> wrote:

> Hi, Please review the simple change.
> 
>   The removing of white spaces from end of line in ClassListParser should be moved to before we add lambda-form-invoker
>   line to array.  After made such arrangement, changed CDS.java for trimming line code.
> 
> Tests: local test on runtime/cds/appcds. Mach5 tier1,4 is in progress.
> 
> Thanks

This pull request has now been integrated.

Changeset: 546620bb
Author:    Yumin Qi <minqi at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/546620bb
Stats:     57 lines in 2 files changed: 26 ins; 25 del; 6 mod

8254192: ExtraSharedClassListFile contains extra white space at end of line

Reviewed-by: iklam, ccheung, mchung

-------------

PR: https://git.openjdk.java.net/jdk/pull/669

From rriggs at openjdk.java.net  Thu Oct 15 16:58:37 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 15 Oct 2020 16:58:37 GMT
Subject: RFR: 8251989: Hex formatting and parsing utility [v4]
In-Reply-To: <HSEn47GMS1K3g57mrTZeQk-WZHl3pKGHpX_OOf8VnsU=.740863c2-f9e4-43c4-b500-614aab4078b1@github.com>
References: <HSEn47GMS1K3g57mrTZeQk-WZHl3pKGHpX_OOf8VnsU=.740863c2-f9e4-43c4-b500-614aab4078b1@github.com>
Message-ID: <VpYQwi73QH-fPOrd7wRiLFB8vBDQNoCJac3rEA_tM0c=.f9962324-7e8a-42f1-966b-4e3dc48ae0ac@github.com>

> java.util.HexFormat utility:
> 
>  - Format and parse hexadecimal strings, with parameters for delimiter, prefix, suffix and upper/lowercase
>  - Static factories and builder methods to create HexFormat copies with modified parameters.
>  - Consistent naming of methods for conversion of byte arrays to formatted strings and back: formatHex and parseHex
>  - Consistent naming of methods for conversion of primitive types: toHexDigits... and fromHexDigits...
>  - Prefix and suffixes now apply to each formatted value, not the string as a whole
>  - Using java.util.Appendable as a target for buffered conversions so output to Writers and PrintStreams
>    like System.out are supported in addition to StringBuilder. (IOExceptions are converted to unchecked exceptions)
>  - Immutable and thread safe, a "value-based" class
> 
> See the [HexFormat
> javadoc](http://cr.openjdk.java.net/~rriggs/8251989-hex-formatter/java.base/java/util/HexFormat.html) for details.
> Review comments and suggestions welcome.

Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev
excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since
the last revision:

 - Merge branch 'master' into 8251989-hex-formatter
 - Cleanup of javadoc markup
 - Added assertions to testVariableLength and samples
 - Merge branch 'master' into 8251989-hex-formatter
 - temp updates
 - Various code review comments, rename UpperCase and LowerCase methods to match Character, remove unnecessary Class name
   qualifications, etc.
 - 8251989: Hex formatting and parsing utility

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/482/files
  - new: https://git.openjdk.java.net/jdk/pull/482/files/ec334dbc..880cebbf

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=482&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=482&range=02-03

  Stats: 296616 lines in 429 files changed: 293891 ins; 1362 del; 1363 mod
  Patch: https://git.openjdk.java.net/jdk/pull/482.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/482/head:pull/482

PR: https://git.openjdk.java.net/jdk/pull/482

From kbarrett at openjdk.java.net  Thu Oct 15 17:04:37 2020
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Thu, 15 Oct 2020 17:04:37 GMT
Subject: RFR: 8188055: (ref) Add Reference::refersTo predicate [v5]
In-Reply-To: <D4HSg8FT20Eaxk5KJkkw0GgETSxRkBn1ipS3Dt0kPto=.e4bab078-2e04-4413-90cb-9bfafb2a6831@github.com>
References: <D4HSg8FT20Eaxk5KJkkw0GgETSxRkBn1ipS3Dt0kPto=.e4bab078-2e04-4413-90cb-9bfafb2a6831@github.com>
Message-ID: <FHx-oBhE254DZWHhg2RTKjZn_-yYN5xadTW7GXhTxzM=.7e6a46fa-5259-428c-b725-81b4fe48b8f7@github.com>

> Finally returning to this review that was started in April 2020.  I've
> recast it as a github PR.  I think the security concern raised by Gil
> has been adequately answered.
> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-April/029203.html
> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-July/030401.html
> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-August/030677.html
> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-September/030793.html
> 
> Please review a new function: java.lang.ref.Reference.refersTo.
> 
> This function is needed to test the referent of a Reference object without
> artificially extending the lifetime of the referent object, as may happen
> when calling Reference.get.  Some garbage collectors require extending the
> lifetime of a weak referent when accessed, in order to maintain collector
> invariants.  Lifetime extension may occur with any collector when the
> Reference is a SoftReference, as calling get indicates recent access.  This
> new function also allows testing the referent of a PhantomReference, which
> can't be accessed by calling get.
> 
> The new function uses native methods whose implementations are in the VM so
> they can use the Access API.  It is the intent that these methods will be
> intrinsified by optimizing compilers like C2 or graal, but that hasn't been
> implemented yet.  Bear that in mind before rushing off to change existing
> uses of Reference.get.
> 
> There are two native methods involved, one in Reference and an override in
> PhantomReference, both package private in java.lang.ref. The reason for this
> split is to simplify the intrinsification. This is a change from the version
> from April 2020; that version had a single native method in Reference,
> implemented using the ON_UNKNOWN_OOP_REF Access reference strength category.
> However, adding support for that category in the compilers adds significant
> implementation effort and complexity. Splitting avoids that complexity.
> 
> Testing:
> mach5 tier1
> Locally (linux-x64) verified the new test passes with various garbage collectors.

Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev
excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since
the last revision:

 - Merge branch 'master' into refersto
 - More explicit refersTo0 comment.
 - simplify test
 - cleanup nits from Mandy
 - use Object instead of TestObject
 - improve refersTo0 descriptions
 - basic functional test
 - change referent access
 - expand test
 - remove CMS comment
 - ... and 1 more: https://git.openjdk.java.net/jdk/compare/1c92ac39...ab4e519b

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/498/files
  - new: https://git.openjdk.java.net/jdk/pull/498/files/c1062ec6..ab4e519b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=498&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=498&range=03-04

  Stats: 331969 lines in 1120 files changed: 314757 ins; 10957 del; 6255 mod
  Patch: https://git.openjdk.java.net/jdk/pull/498.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/498/head:pull/498

PR: https://git.openjdk.java.net/jdk/pull/498

From mcimadamore at openjdk.java.net  Thu Oct 15 17:08:28 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 15 Oct 2020 17:08:28 GMT
Subject: RFR: 8254231: Implementation of Foreign Linker API (Incubator)
 [v4]
In-Reply-To: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
References: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
Message-ID: <0Zh0H5gSXzvHSstQ2w8NBM-P8yERRPouvhZJDNGvu4A=.6cde913f-7499-4c45-bc63-b717502b661e@github.com>

> This patch contains the changes associated with the first incubation round of the foreign linker access API incubation
> (see JEP 389 [1]). This work is meant to sit on top of the foreign memory access support (see JEP 393 [2] and
> associated pull request [3]).
> The main goal of this API is to provide a way to call native functions from Java code without the need of intermediate
> JNI glue code. In order to do this, native calls are modeled through the MethodHandle API. I suggest reading the
> writeup [4] I put together few weeks ago, which illustrates what the foreign linker support is, and how it should be
> used by clients.  Disclaimer: the pull request mechanism isn't great at managing *dependent* reviews. For this reasons,
> I'm attaching a webrev which contains only the differences between this PR and the memory access PR. I will be
> periodically uploading new webrevs, as new iterations come out, to try and make the life of reviewers as simple as
> possible.  A big thank to Jorn Vernee and Vladimir Ivanov - they are the main architects of all the hotspot changes you
> see here, and without their help, the foreign linker support wouldn't be what it is today. As usual, a big thank to
> Paul Sandoz, who provided many insights (often by trying the bits first hand).  Thanks Maurizio
> Webrev:
> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/webrev
> 
> Javadoc:
> 
> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/javadoc/jdk/incubator/foreign/package-summary.html
> 
> Specdiff (relative to [3]):
> 
> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/specdiff_delta/overview-summary.html
> 
> CSR:
> 
> https://bugs.openjdk.java.net/browse/JDK-8254232
> 
> 
> 
> ### API Changes
> 
> The API changes are actually rather slim:
> 
> * `LibraryLookup`
>   * This class allows clients to lookup symbols in native libraries; the interface is fairly simple; you can load a library
>     by name, or absolute path, and then lookup symbols on that library.
> * `FunctionDescriptor`
>   * This is an abstraction that is very similar, in spirit, to `MethodType`; it is, at its core, an aggregate of memory
>     layouts for the function arguments/return type. A function descriptor is used to describe the signature of a native
>     function.
> * `CLinker`
>   * This is the real star of the show. A `CLinker` has two main methods: `downcallHandle` and `upcallStub`; the first takes
>     a native symbol (as obtained from `LibraryLookup`), a `MethodType` and a `FunctionDescriptor` and returns a
>     `MethodHandle` instance which can be used to call the target native symbol. The second takes an existing method handle,
>     and a `FunctionDescriptor` and returns a new `MemorySegment` corresponding to a code stub allocated by the VM which
>     acts as a trampoline from native code to the user-provided method handle. This is very useful for implementing upcalls.
>    * This class also contains the various layout constants that should be used by clients when describing native signatures
>      (e.g. `C_LONG` and friends); these layouts contain additional ABI classfication information (in the form of layout
>      attributes) which is used by the runtime to *infer* how Java arguments should be shuffled for the native call to take
>      place.
>   * Finally, this class provides some helper functions e.g. so that clients can convert Java strings into C strings and
>     back.
> * `NativeScope`
>   * This is an helper class which allows clients to group together logically related allocations; that is, rather than
>     allocating separate memory segments using separate *try-with-resource* constructs, a `NativeScope` allows clients to
>     use a _single_ block, and allocate all the required segments there. This is not only an usability boost, but also a
>     performance boost, since not all allocation requests will be turned into `malloc` calls.
> * `MemorySegment`
>   * Only one method added here - namely `handoff(NativeScope)` which allows a segment to be transferred onto an existing
>     native scope.
> 
> ### Safety
> 
> The foreign linker API is intrinsically unsafe; many things can go wrong when requesting a native method handle. For
> instance, the description of the native signature might be wrong (e.g. have too many arguments) - and the runtime has,
> in the general case, no way to detect such mismatches. For these reasons, obtaining a `CLinker` instance is
> a *restricted* operation, which can be enabled by specifying the usual JDK property `-Dforeign.restricted=permit` (as
> it's the case for other restricted method in the foreign memory API).  ### Implementation changes  The Java changes
> associated with `LibraryLookup` are relative straightforward; the only interesting thing to note here is that library
> loading does _not_ depend on class loaders, so `LibraryLookup` is not subject to the same restrictions which apply to
> JNI library loading (e.g. same library cannot be loaded by different classloaders).  As for `NativeScope` the changes
> are again relatively straightforward; it is an API which sits neatly on top of the foreign meory access API, providing
> some kind of allocation service which shares the same underlying memory segment(s), and turns an allocation request
> into a segment slice, which is a much less expensive operation. `NativeScope` comes in two variants: there are native
> scopes for which the allocation size is known a priori, and native scopes which can grow - these two schemes are
> implemented by two separate subclasses of `AbstractNativeScopeImpl`.  Of course the bulk of the changes are to support
> the `CLinker` downcall/upcall routines. These changes cut pretty deep into the JVM; I'll briefly summarize the goal of
> some of this changes - for further details, Jorn has put together a detailed writeup which explains the rationale
> behind the VM support, with some references to the code [5].  The main idea behind foreign linker is to infer, given a
> Java method type (expressed as a `MethodType` instance) and the description of the signature of a native function
> (expressed as a `FunctionDescriptor` instance) a _recipe_ that can be used to turn a Java call into the corresponding
> native call targeting the requested native function.  This inference scheme can be defined in a pretty straightforward
> fashion by looking at the various ABI specifications (for instance, see [6] for the SysV ABI, which is the one used on
> Linux/Mac). The various `CallArranger` classes, of which we have a flavor for each supported platform, do exactly that
> kind of inference.  For the inference process to work, we need to attach extra information to memory layouts; it is no
> longer sufficient to know e.g. that a layout is 32/64 bits - we need to know whether it is meant to represent a
> floating point value, or an integral value; this knowledge is required because floating points are passed in different
> registers by most ABIs. For this reason, `CLinker` offers a set of pre-baked, platform-dependent layout constants which
> contain the required classification attributes (e.g. a `Clinker.TypeKind` enum value). The runtime extracts this
> attribute, and performs classification accordingly.  A native call is decomposed into a sequence of basic, primitive
> operations, called `Binding` (see the great javadoc on the `Binding.java` class for more info). There are many such
> bindings - for instance the `Move` binding is used to move a value into a specific machine register/stack slot. So, the
> main job of the various `CallingArranger` classes is to determine, given a Java `MethodType` and `FunctionDescriptor`
> what is the set of bindings associated with the downcall/upcall.  At the heart of the foreign linker support is the
> `ProgrammableInvoker` class. This class effectively generates a `MethodHandle` which follows the steps described by the
> various bindings obtained by `CallArranger`. There are actually various strategies to interpret these bindings - listed
> below:
> * basic intepreted mode; in this mode, all bindings are interpreted using a stack-based machine written in Java (see
>   `BindingInterpreter`), except for the `Move` bindings. For these bindings, the move is implemented by allocating
>   a *buffer* (whose size is ABI specific) and by moving all the lowered values into positions within this buffer. The
>   buffer is then passed to a piece of assembly code inside the VM which takes values from the buffer and moves them in
>   their expected registers/stack slots (note that each position in the buffer corresponds to a different register). This
>   is the most general invocation mode, the more "customizable" one, but also the slowest - since for every call there is
>   some extra allocation which takes place.
> 
> * specialized interpreted mode; same as before, but instead of interpreting the bindings with a stack-based interpreter,
>   we generate a method handle chain which effectively interprets all the bindings (again, except `Move` ones).
> 
> * intrinsified mode; this is typically used in combination with the specialized interpreted mode described above
>   (although it can also be used with the Java-based binding interpreter). The goal here is to remove the buffer
>   allocation and copy by introducing an additional JVM intrinsic. If a native call recipe is constant (e.g. the set of
>   bindings is constant, which is probably the case if the native method handle is stored in a `static`, `final` field),
>   then the VM can generate specialized assembly code which interprets the `Move` binding without the need to go for an
>   intermediate buffer. This gives us back performances that are on par with JNI.
> 
> For upcalls, the support is not (yet) as advanced, and only the basic interpreted mode is available there. We plan to
> add support for intrinsified modes there as well, which should considerably boost perfomances (probably well beyond
> what JNI can offer at the moment, since the upcall support in JNI is not very well optimized).  Again, for more
> readings on the internals of the foreign linker support, please refer to [5].
> #### Test changes
> 
> Many new tests have been added to validate the foreign linker support; we have high level tests (see `StdLibTest`)
> which aim at testing the linker from the perspective of code that clients could write. But we also have deeper
> combinatorial tests (see `TestUpcall` and `TestDowncall`) which are meant to stress every corner of the ABI
> implementation. There are also some great tests (see the `callarranger` folder) which test the various `CallArranger`s
> for all the possible platforms; these tests adopt more of a white-box approach - that is, instead of treating the
> linker machinery as a black box and verify that the support works by checking that the native call returned the results
> we expected, these tests aims at checking that the set of bindings generated by the call arranger is correct. This also
> mean that we can test the classification logic for Windows, Mac and Linux regardless of the platform we're executing
> on.  Some additional microbenchmarks have been added to compare the performances of downcall/upcall with JNI.  [1] -
> https://openjdk.java.net/jeps/389 [2] - https://openjdk.java.net/jeps/393 [3] -
> https://git.openjdk.java.net/jdk/pull/548 [4] -
> https://github.com/openjdk/panama-foreign/blob/foreign-jextract/doc/panama_ffi.md [5] -
> http://cr.openjdk.java.net/~jvernee/docs/Foreign-abi%20downcall%20intrinsics%20technical%20description.html

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Re-add file erroneously deleted (detected as rename)

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/634/files
  - new: https://git.openjdk.java.net/jdk/pull/634/files/2184831e..830c5cea

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=634&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=634&range=02-03

  Stats: 35 lines in 1 file changed: 35 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/634.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/634/head:pull/634

PR: https://git.openjdk.java.net/jdk/pull/634

From github.com+51754783+coreyashford at openjdk.java.net  Thu Oct 15 18:01:18 2020
From: github.com+51754783+coreyashford at openjdk.java.net (CoreyAshford)
Date: Thu, 15 Oct 2020 18:01:18 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v4]
In-Reply-To: <9y5m4zfsDZMdIZ6CT38BzO0tpFMuFxUswAbpjfDny-w=.44c7ada7-bf77-45f1-b5a6-b542731d6685@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <45FtTQB1m6HyZSASY42STMkQffIWlVPibWn9_r00xYs=.daad2653-2571-491f-8dd7-5954fe4ece00@github.com>
 <u6HLR2PyvWgYbA58W3bCF4n38tpwQu2-ujPMvGpyyuo=.5a80f17c-83d5-4dc9-bad0-00e679fdd4be@github.com>
 <7-p-Kc9lQyyuoWdNtmgbXbwkxsgk4oQGKmFSCcMpvnU=.97810c01-3200-4767-bbd4-35d53c2bc5ca@github.com>
 <6Voyfr_s-ieyRA-8Rtvvpz7tkhhicA8sY2d2KTp3Kmw=.fa256bae-2143-4b43-bfea-5837ad31eb6a@github.com>
 <fFQfDMqdwosVGzcaJfblklUy1nPsEdZJI7ALmKq9XJs=.e869160e-76e7-4a6b-b45b-e9763d1ad06f@github.com>
 <vKcE4CeascBAQGeyu6is0Va0_k4aTrvgU41cjhG6Wdo=.4078814f-06ed-4978-9fcd-a4a5148c2bdc@github.com>
 <wQ6YtDhYzmcgpTUP4uFfBCo8UFWZENtTARWt_LTqPug=.30bc3fdb-f963-4918-ae4b-0fe174c38a23@github.com>
 <jqzI94j7kygJyD9HWwq5d3q3LGztS5FAdYm5Ix1QdjE=.808de4e6-0f6d-4e17-b807-25ef89e92541@github.com>
 <7XjzEn5DggliDrvjhrGwXZL5r4lsqeGF9SGLmRr5L84=.a4481a62-4ecf-4e3f-98f3-70e548c67b52@github.com>
 <9y5m4zfsDZMdIZ6CT38BzO0tpFMuFxUswAb
 pjfDny-w=.44c7ada7-bf77-45f1-b5a6-b542731d6685@github.com>
Message-ID: <gC1r5U7FYGeYMGD5Kv0z9cUsqJ1P5mQRbXwbAP6MQ78=.5bfa32b0-8afa-492d-9499-2cfabf0f9352@github.com>

On Thu, 15 Oct 2020 15:59:23 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> Please update
> [compiler/graalunit/HotspotTest.java](https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/compiler/graalunit/HotspotTest.java),
> and add the intrinsic signature.

It looks like that is auto-generated, but I will figure out what to modify so that the signature is added.

-------------

PR: https://git.openjdk.java.net/jdk/pull/293

From dfuchs at openjdk.java.net  Thu Oct 15 18:10:15 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 15 Oct 2020 18:10:15 GMT
Subject: RFR: 8251989: Hex formatting and parsing utility [v4]
In-Reply-To: <VpYQwi73QH-fPOrd7wRiLFB8vBDQNoCJac3rEA_tM0c=.f9962324-7e8a-42f1-966b-4e3dc48ae0ac@github.com>
References: <HSEn47GMS1K3g57mrTZeQk-WZHl3pKGHpX_OOf8VnsU=.740863c2-f9e4-43c4-b500-614aab4078b1@github.com>
 <VpYQwi73QH-fPOrd7wRiLFB8vBDQNoCJac3rEA_tM0c=.f9962324-7e8a-42f1-966b-4e3dc48ae0ac@github.com>
Message-ID: <vYbUiBDOknIlXX9r3aJsWs8DkIGyA78KrWPL3zCUXX4=.a1523e0b-858c-4946-8606-99adf8d74eec@github.com>

On Thu, 15 Oct 2020 16:58:37 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> java.util.HexFormat utility:
>> 
>>  - Format and parse hexadecimal strings, with parameters for delimiter, prefix, suffix and upper/lowercase
>>  - Static factories and builder methods to create HexFormat copies with modified parameters.
>>  - Consistent naming of methods for conversion of byte arrays to formatted strings and back: formatHex and parseHex
>>  - Consistent naming of methods for conversion of primitive types: toHexDigits... and fromHexDigits...
>>  - Prefix and suffixes now apply to each formatted value, not the string as a whole
>>  - Using java.util.Appendable as a target for buffered conversions so output to Writers and PrintStreams
>>    like System.out are supported in addition to StringBuilder. (IOExceptions are converted to unchecked exceptions)
>>  - Immutable and thread safe, a "value-based" class
>> 
>> See the [HexFormat
>> javadoc](http://cr.openjdk.java.net/~rriggs/8251989-hex-formatter/java.base/java/util/HexFormat.html) for details.
>> Review comments and suggestions welcome.
>
> Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev
> excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since
> the last revision:
>  - Merge branch 'master' into 8251989-hex-formatter
>  - Cleanup of javadoc markup
>  - Added assertions to testVariableLength and samples
>  - Merge branch 'master' into 8251989-hex-formatter
>  - temp updates
>  - Various code review comments, rename UpperCase and LowerCase methods to match Character, remove unnecessary Class name
>    qualifications, etc.
>  - 8251989: Hex formatting and parsing utility

Marked as reviewed by dfuchs (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/482

From jvernee at openjdk.java.net  Thu Oct 15 18:24:15 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Thu, 15 Oct 2020 18:24:15 GMT
Subject: RFR: 8254231: Implementation of Foreign Linker API (Incubator)
In-Reply-To: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
References: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
Message-ID: <9f-iShxyaRbjn74wlAqBPH3ycRWisVwlWuB81Kv8Q6A=.be903417-dda9-434a-96a4-d9ea6a1e1737@github.com>

On Tue, 13 Oct 2020 13:08:14 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This patch contains the changes associated with the first incubation round of the foreign linker access API incubation
> (see JEP 389 [1]). This work is meant to sit on top of the foreign memory access support (see JEP 393 [2] and
> associated pull request [3]).
> The main goal of this API is to provide a way to call native functions from Java code without the need of intermediate
> JNI glue code. In order to do this, native calls are modeled through the MethodHandle API. I suggest reading the
> writeup [4] I put together few weeks ago, which illustrates what the foreign linker support is, and how it should be
> used by clients.  Disclaimer: the pull request mechanism isn't great at managing *dependent* reviews. For this reasons,
> I'm attaching a webrev which contains only the differences between this PR and the memory access PR. I will be
> periodically uploading new webrevs, as new iterations come out, to try and make the life of reviewers as simple as
> possible.  A big thank to Jorn Vernee and Vladimir Ivanov - they are the main architects of all the hotspot changes you
> see here, and without their help, the foreign linker support wouldn't be what it is today. As usual, a big thank to
> Paul Sandoz, who provided many insights (often by trying the bits first hand).  Thanks Maurizio
> Webrev:
> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/webrev
> 
> Javadoc:
> 
> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/javadoc/jdk/incubator/foreign/package-summary.html
> 
> Specdiff (relative to [3]):
> 
> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/specdiff_delta/overview-summary.html
> 
> CSR:
> 
> https://bugs.openjdk.java.net/browse/JDK-8254232
> 
> 
> 
> ### API Changes
> 
> The API changes are actually rather slim:
> 
> * `LibraryLookup`
>   * This class allows clients to lookup symbols in native libraries; the interface is fairly simple; you can load a library
>     by name, or absolute path, and then lookup symbols on that library.
> * `FunctionDescriptor`
>   * This is an abstraction that is very similar, in spirit, to `MethodType`; it is, at its core, an aggregate of memory
>     layouts for the function arguments/return type. A function descriptor is used to describe the signature of a native
>     function.
> * `CLinker`
>   * This is the real star of the show. A `CLinker` has two main methods: `downcallHandle` and `upcallStub`; the first takes
>     a native symbol (as obtained from `LibraryLookup`), a `MethodType` and a `FunctionDescriptor` and returns a
>     `MethodHandle` instance which can be used to call the target native symbol. The second takes an existing method handle,
>     and a `FunctionDescriptor` and returns a new `MemorySegment` corresponding to a code stub allocated by the VM which
>     acts as a trampoline from native code to the user-provided method handle. This is very useful for implementing upcalls.
>    * This class also contains the various layout constants that should be used by clients when describing native signatures
>      (e.g. `C_LONG` and friends); these layouts contain additional ABI classfication information (in the form of layout
>      attributes) which is used by the runtime to *infer* how Java arguments should be shuffled for the native call to take
>      place.
>   * Finally, this class provides some helper functions e.g. so that clients can convert Java strings into C strings and
>     back.
> * `NativeScope`
>   * This is an helper class which allows clients to group together logically related allocations; that is, rather than
>     allocating separate memory segments using separate *try-with-resource* constructs, a `NativeScope` allows clients to
>     use a _single_ block, and allocate all the required segments there. This is not only an usability boost, but also a
>     performance boost, since not all allocation requests will be turned into `malloc` calls.
> * `MemorySegment`
>   * Only one method added here - namely `handoff(NativeScope)` which allows a segment to be transferred onto an existing
>     native scope.
> 
> ### Safety
> 
> The foreign linker API is intrinsically unsafe; many things can go wrong when requesting a native method handle. For
> instance, the description of the native signature might be wrong (e.g. have too many arguments) - and the runtime has,
> in the general case, no way to detect such mismatches. For these reasons, obtaining a `CLinker` instance is
> a *restricted* operation, which can be enabled by specifying the usual JDK property `-Dforeign.restricted=permit` (as
> it's the case for other restricted method in the foreign memory API).  ### Implementation changes  The Java changes
> associated with `LibraryLookup` are relative straightforward; the only interesting thing to note here is that library
> loading does _not_ depend on class loaders, so `LibraryLookup` is not subject to the same restrictions which apply to
> JNI library loading (e.g. same library cannot be loaded by different classloaders).  As for `NativeScope` the changes
> are again relatively straightforward; it is an API which sits neatly on top of the foreign meory access API, providing
> some kind of allocation service which shares the same underlying memory segment(s), and turns an allocation request
> into a segment slice, which is a much less expensive operation. `NativeScope` comes in two variants: there are native
> scopes for which the allocation size is known a priori, and native scopes which can grow - these two schemes are
> implemented by two separate subclasses of `AbstractNativeScopeImpl`.  Of course the bulk of the changes are to support
> the `CLinker` downcall/upcall routines. These changes cut pretty deep into the JVM; I'll briefly summarize the goal of
> some of this changes - for further details, Jorn has put together a detailed writeup which explains the rationale
> behind the VM support, with some references to the code [5].  The main idea behind foreign linker is to infer, given a
> Java method type (expressed as a `MethodType` instance) and the description of the signature of a native function
> (expressed as a `FunctionDescriptor` instance) a _recipe_ that can be used to turn a Java call into the corresponding
> native call targeting the requested native function.  This inference scheme can be defined in a pretty straightforward
> fashion by looking at the various ABI specifications (for instance, see [6] for the SysV ABI, which is the one used on
> Linux/Mac). The various `CallArranger` classes, of which we have a flavor for each supported platform, do exactly that
> kind of inference.  For the inference process to work, we need to attach extra information to memory layouts; it is no
> longer sufficient to know e.g. that a layout is 32/64 bits - we need to know whether it is meant to represent a
> floating point value, or an integral value; this knowledge is required because floating points are passed in different
> registers by most ABIs. For this reason, `CLinker` offers a set of pre-baked, platform-dependent layout constants which
> contain the required classification attributes (e.g. a `Clinker.TypeKind` enum value). The runtime extracts this
> attribute, and performs classification accordingly.  A native call is decomposed into a sequence of basic, primitive
> operations, called `Binding` (see the great javadoc on the `Binding.java` class for more info). There are many such
> bindings - for instance the `Move` binding is used to move a value into a specific machine register/stack slot. So, the
> main job of the various `CallingArranger` classes is to determine, given a Java `MethodType` and `FunctionDescriptor`
> what is the set of bindings associated with the downcall/upcall.  At the heart of the foreign linker support is the
> `ProgrammableInvoker` class. This class effectively generates a `MethodHandle` which follows the steps described by the
> various bindings obtained by `CallArranger`. There are actually various strategies to interpret these bindings - listed
> below:
> * basic intepreted mode; in this mode, all bindings are interpreted using a stack-based machine written in Java (see
>   `BindingInterpreter`), except for the `Move` bindings. For these bindings, the move is implemented by allocating
>   a *buffer* (whose size is ABI specific) and by moving all the lowered values into positions within this buffer. The
>   buffer is then passed to a piece of assembly code inside the VM which takes values from the buffer and moves them in
>   their expected registers/stack slots (note that each position in the buffer corresponds to a different register). This
>   is the most general invocation mode, the more "customizable" one, but also the slowest - since for every call there is
>   some extra allocation which takes place.
> 
> * specialized interpreted mode; same as before, but instead of interpreting the bindings with a stack-based interpreter,
>   we generate a method handle chain which effectively interprets all the bindings (again, except `Move` ones).
> 
> * intrinsified mode; this is typically used in combination with the specialized interpreted mode described above
>   (although it can also be used with the Java-based binding interpreter). The goal here is to remove the buffer
>   allocation and copy by introducing an additional JVM intrinsic. If a native call recipe is constant (e.g. the set of
>   bindings is constant, which is probably the case if the native method handle is stored in a `static`, `final` field),
>   then the VM can generate specialized assembly code which interprets the `Move` binding without the need to go for an
>   intermediate buffer. This gives us back performances that are on par with JNI.
> 
> For upcalls, the support is not (yet) as advanced, and only the basic interpreted mode is available there. We plan to
> add support for intrinsified modes there as well, which should considerably boost perfomances (probably well beyond
> what JNI can offer at the moment, since the upcall support in JNI is not very well optimized).  Again, for more
> readings on the internals of the foreign linker support, please refer to [5].
> #### Test changes
> 
> Many new tests have been added to validate the foreign linker support; we have high level tests (see `StdLibTest`)
> which aim at testing the linker from the perspective of code that clients could write. But we also have deeper
> combinatorial tests (see `TestUpcall` and `TestDowncall`) which are meant to stress every corner of the ABI
> implementation. There are also some great tests (see the `callarranger` folder) which test the various `CallArranger`s
> for all the possible platforms; these tests adopt more of a white-box approach - that is, instead of treating the
> linker machinery as a black box and verify that the support works by checking that the native call returned the results
> we expected, these tests aims at checking that the set of bindings generated by the call arranger is correct. This also
> mean that we can test the classification logic for Windows, Mac and Linux regardless of the platform we're executing
> on.  Some additional microbenchmarks have been added to compare the performances of downcall/upcall with JNI.  [1] -
> https://openjdk.java.net/jeps/389 [2] - https://openjdk.java.net/jeps/393 [3] -
> https://git.openjdk.java.net/jdk/pull/548 [4] -
> https://github.com/openjdk/panama-foreign/blob/foreign-jextract/doc/panama_ffi.md [5] -
> http://cr.openjdk.java.net/~jvernee/docs/Foreign-abi%20downcall%20intrinsics%20technical%20description.html

Here is the updated partial webrev against https://github.com/openjdk/jdk/pull/548 :
http://cr.openjdk.java.net/~jvernee/linker_rfr/v2/

-------------

PR: https://git.openjdk.java.net/jdk/pull/634

From rriggs at openjdk.java.net  Thu Oct 15 18:25:17 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 15 Oct 2020 18:25:17 GMT
Subject: RFR: 8251989: Hex formatting and parsing utility [v4]
In-Reply-To: <vYbUiBDOknIlXX9r3aJsWs8DkIGyA78KrWPL3zCUXX4=.a1523e0b-858c-4946-8606-99adf8d74eec@github.com>
References: <HSEn47GMS1K3g57mrTZeQk-WZHl3pKGHpX_OOf8VnsU=.740863c2-f9e4-43c4-b500-614aab4078b1@github.com>
 <VpYQwi73QH-fPOrd7wRiLFB8vBDQNoCJac3rEA_tM0c=.f9962324-7e8a-42f1-966b-4e3dc48ae0ac@github.com>
 <vYbUiBDOknIlXX9r3aJsWs8DkIGyA78KrWPL3zCUXX4=.a1523e0b-858c-4946-8606-99adf8d74eec@github.com>
Message-ID: <R6ZL6QASZ81hlZ8eiawDp8Z8gkkXuPcKzc3PE5nT0Dg=.63d51928-0db0-41b7-a3ee-6614dba1dedb@github.com>

On Thu, 15 Oct 2020 18:07:10 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev
>> excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since
>> the last revision:
>>  - Merge branch 'master' into 8251989-hex-formatter
>>  - Cleanup of javadoc markup
>>  - Added assertions to testVariableLength and samples
>>  - Merge branch 'master' into 8251989-hex-formatter
>>  - temp updates
>>  - Various code review comments, rename UpperCase and LowerCase methods to match Character, remove unnecessary Class name
>>    qualifications, etc.
>>  - 8251989: Hex formatting and parsing utility
>
> Marked as reviewed by dfuchs (Reviewer).

Please review the corresponding CSR:
    https://bugs.openjdk.java.net/browse/JDK-8251991

-------------

PR: https://git.openjdk.java.net/jdk/pull/482

From ccheung at openjdk.java.net  Thu Oct 15 18:29:20 2020
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Thu, 15 Oct 2020 18:29:20 GMT
Subject: RFR: 8247666: Support Lambda proxy classes in static CDS archive
 [v7]
In-Reply-To: <ynh4JzHY75GjEn5_oCtmRNy9HMFsU34O2PlhSwD41tU=.1a3770f9-9091-429f-8d03-31b826f9b093@github.com>
References: <ynh4JzHY75GjEn5_oCtmRNy9HMFsU34O2PlhSwD41tU=.1a3770f9-9091-429f-8d03-31b826f9b093@github.com>
Message-ID: <u33Y5kS6vFNxuHP2k9gjgnqgyV0yR1tQ9TayhfNqCH0=.c8973ca9-2819-488c-9c1c-ead4dcc82dc4@github.com>

> Following up on archiving lambda proxy classes in dynamic CDS archive
> ([JDK-8198698](https://bugs.openjdk.java.net/browse/JDK-8198698)), this RFE adds the functionality of archiving of
> lambda proxy classes in static CDS archive.
> When the -XX:DumpLoadedClassList is enabled, the constant pool index related to LambdaMetafactory that are resolved
> during application execution will be included in the classlist. The entry for a lambda proxy class in a class list will
> be of the following format:
> `@lambda-proxy: <classname> <cp index>`
> 
> e.g.
> `@lambda-proxy: test/java/lang/invoke/MethodHandlesGeneralTest 233`
> `@lambda-proxy: test/java/lang/invoke/MethodHandlesGeneralTest 355`
> 
> When dumping a CDS archive using the -Xshare:dump and -XX:ExtraSharedClassListFile options, when the above
> `@lambda-proxy` entry is encountered while parsing the classlist, we will resolve the corresponding constant pool
> indices (233 and 355 in the above example). As a result, lambda proxy classes will be generated for the constant pool
> entries, and will be cached using a similar mechanism to JDK-8198698.  During dumping, there is check on the cp index
> and on the created BootstrapInfo using the cp index. VM will exit with an error message if the check has failed.
> During runtime when looking up a lambda proxy class, the lookup will be perform on the static CDS archive and if not
> found, then lookup from the dynamic archive if one is specified.  (Only name change (IsDynamicDumpingEnabled ->
> IsCDSDumpingEnabled) is involved in the core-libs code.)
> Testing: tiers 1,2,3,4.
> 
> Performance results (javac on HelloWorld on linux-x64):
> Results of " perf stat -r 40 bin/javac -J-Xshare:on -J-XX:SharedArchiveFile=javac2.jsa Bench_HelloWorld.java "
>    1:   2228016795  2067752708 (-160264087)      -----    377.760   349.110 (-28.650)      -----
>    2:   2223051476  2063016483 (-160034993)      -----    374.580   350.620 (-23.960)      ----
>    3:   2225908334  2067673847 (-158234487)      -----    375.220   350.990 (-24.230)      ----
>    4:   2225835999  2064596883 (-161239116)      -----    374.670   349.840 (-24.830)      ----
>    5:   2226005510  2061694332 (-164311178)      -----    373.512   351.120 (-22.392)      ----
>    6:   2225574949  2062657482 (-162917467)      -----    374.710   348.380 (-26.330)      -----
>    7:   2224702424  2064634122 (-160068302)      -----    373.670   349.510 (-24.160)      ----
>    8:   2226662277  2066301134 (-160361143)      -----    375.350   349.790 (-25.560)      ----
>    9:   2226761470  2063162795 (-163598675)      -----    374.260   351.290 (-22.970)      ----
>   10:   2230149089  2066203307 (-163945782)      -----    374.760   350.620 (-24.140)      ----
> ============================================================
>         2226266109  2064768307 (-161497801)      -----    374.848   350.126 (-24.722)      ----
> instr delta =   -161497801    -7.2542%
> time  delta =      -24.722 ms -6.5951%

Calvin Cheung has updated the pull request with a new target base due to a merge or a rebase. The pull request now
contains 11 commits:

 - Merge branch 'master' into 8247666
 - Changes based on Ioi's suggestions:
   1. Added the ClassListWriter class to make writing to a classlist file thread safe;
   2. Changed API's in CDS.java to be more consistent with CDS.isDumpingClasslist.
 - fix minimal vm build issues
 - Merge branch 'master' into 8247666
 - Merge branch 'master' into 8247666
 - 1. Symbolic encoding of lambda proxy resolution. An example of @lambda-proxy in the classlist:
   @lambda-proxy: LambHello run ()Ljava/lang/Runnable; ()V 6 LambHello lambdabash ()V ()V
   2. Removed BadCPIndex.java; added LambdaProxyClassList.java test.
   3. Mandy's comments.
 - Merge branch 'master' into 8247666
 - exclude archived lambda proxy classes in the classlist
 - updated systemDictionaryShared.[c|h]pp based on suggestions from Ioi
 - fix extraneous whitespace
 - ... and 1 more: https://git.openjdk.java.net/jdk/compare/546620bb...dfdf12ea

-------------

Changes: https://git.openjdk.java.net/jdk/pull/364/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=364&range=06
  Stats: 2006 lines in 38 files changed: 1876 ins; 66 del; 64 mod
  Patch: https://git.openjdk.java.net/jdk/pull/364.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/364/head:pull/364

PR: https://git.openjdk.java.net/jdk/pull/364

From mchung at openjdk.java.net  Thu Oct 15 18:33:13 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Thu, 15 Oct 2020 18:33:13 GMT
Subject: RFR: 8159746: (proxy) Support for default methods
In-Reply-To: <9JNNUzfV3PSvKtSg2a_zyYJmgEn3sZL9cb5sfqemk2o=.f1ef7fb7-bdd5-44ed-98c8-59213e9094f9@github.com>
References: <kw2VXh3vTFf1zgfd4biXA41OKffZ5oU7KT23tXAxgUA=.bcf14ffc-4dba-4c9c-8754-184172c5acbd@github.com>
 <U-6RiCpFVIrhLztPN6opiPcpFtxValDzU-K7WWFZM-4=.6bc8aaa4-636a-4664-b380-4c4af00513bd@github.com>
 <-cLIJ8pFHtnNoJMHV3aXI7XMJWp4Jrutc8Xn5PG0OK8=.d2cd87ab-3592-4524-ad85-05444c43689b@github.com>
 <r0UK2qjnmgeTNDDSWaSLPAj3QRgx_4YB82ielllO7jM=.fa615bc0-db49-4a74-b842-793f8f5209bb@github.com>
 <1T8kXDZN1bhHr4c8v4SQsImeBySCqTfX-u3_jzvyocA=.b4957400-9a33-4b6e-8475-329642a5888c@github.com>
 <XIux-dY0JXHRafHk48kVNXId9r-HSceNSytBojDxelY=.872e74cb-b064-406e-b71f-13c90ec7fbbc@github.com>
 <j4t2vT0SnwnU7lhKRlXtk967d-K6nA0EqHrqNbba7W0=.dc05dba6-bf7e-4606-8a02-9c2bad4b3b58@github.com>
 <fmVtPcBdgMuZOPm2qx3Q3znVZM7JgQPkhPAVLtwkOhE=.2d8b8447-cfae-4cb3-9a7c-6567a881231f@github.com>
 <GSeWP29fAIUFSk0CYsC557w52CuLqeUWwHNK9maltwI=.3d5f002e-6b74-4a57-a5d8-244d27da9dde@github.com>
 <GF8iEOkMUEL2dYB0HytFIc9gyeeUJ_KP0ImlqFsul2Y=.894afc05-9310-43e1-a308-8f7d71dc572b@github.com>
 <HvtDex3cmiv7XeTMITOroYfu74amSGQavQ_
 BAmVzmXw=.223be989-7c20-4ba4-ac0d-013d2b75a8cb@github.com>
 <IqRiLphFPBpGiKAnMJXqxjie9YeZ03rcE-qG1s92BLw=.d4fd5e92-5067-40df-8a0b-1dfd3d6e23af@github.com>
 <Y0hE51G3YefI6NY1O_E6VoZSKwxE78S1hv6fEatmOG8=.0a2c686c-d9ad-418c-8c1b-49addb8a54b1@github.com>
 <QrNk57L2PWQhJjzYiGTsvYyGIPAfK7bP_kANtTR-2uM=.3e5ce990-f8ea-4751-8147-27a8a9dad40d@github.com>
 <9JNNUzfV3PSvKtSg2a_zyYJmgEn3sZL9cb5sfqemk2o=.f1ef7fb7-bdd5-44ed-98c8-59213e9094f9@github.com>
Message-ID: <zWGhaC8YB5I0XgffiR7o_YT5gSp9Gbj8Drtt23brl-c=.1e59f0e4-bbe3-4fb2-94dc-c55fc862f091@github.com>

On Thu, 15 Oct 2020 09:04:09 GMT, Peter Levart <plevart at openjdk.org> wrote:

>> `invokeDefaultMethod` is moved to a static method in `InvocationHandler`.
>>  I also add `@throws IllegalAccessException` if the specified default method is
>> inaccessible to the caller (access check was missing in the previous version).
>> The declaring interface of the default method must be exported to the caller to
>> use.  If it's a non-public interface, the caller class must be in the same runtime
>> package as the interface.  The example in javadoc includes the case when
>> the proxy interface is modified.
>
> Hi Mandy,
> 
> I'm beginning to think that we somewhat wondered away from the original intent which was to mimic the bytecode
> behaviour as much as possible. Bytecode behaviour for super calls (invokespecial) is very special and what you do in
> the last patch is guarding invocation to a super default method via @CallerSensitive method which checks the access of
> the caller as though this was a normal call. Similar access check when a default method might reside in a
> package-private class or when this class might not be exported is already performed when the code creates a Proxy
> class/instance (Proxy::getProxyClass/newProxyInstance). This code also designates an InvocationHandler for the proxy
> instance. From that point on, the designated invocation handler should have full access to invoking super default
> methods on the proxy instance regardless of where it resides because it has been chosen as the delegate of the Proxy
> class with full powers.  Since we are exposing the invokeDefaultMethod functionality in a public static method, it is
> hard (or not quite possible) to check that the code doing the invocation is in fact the designated invocation handler
> code. One approximation might be the following check:  `Proxy.getInvocationHandler(proxy).getClass() == callerClass`
> ...but that would not work for code residing in the invocation handler superclass even though such code might be
> eligible to call the super default method. OTOH such check is over permissive as it allows calling the super method
> from static context too.  So I was thinking about an alternative approach. To expose the method as a protected final
> instance method in an abstract class implementing InvocationHandler:  public interface InvocationHandler {
>   ...
>   abstract class Support implements InvocationHandler {
>     protected final Object invokeDefaultMethod(Object proxy, Method method, Object... args) throws
>     InvocationTargetException {
>       if (this != Proxy.getInvocationHandler(proxy)) throw ...
>       ...
>     }
>   }
> }
> 
> Users would have to extend `InvocationHandler.Support` to access this feature. This might be OK for most users, but
> those wanting to extend some other class will not be able to do that.
> So WDYT? In case you still prefer your approach of re-checking the permissions in invokeDefaultMethod, then I might
> have some ideas of how to speed-up theses checks. As currently stands, invoking public exported interface default
> methods does exhibit a little more penalty, but for non-public or non-exported interfaces, the penalty is bigger:
> Mandy's original:
> Benchmark             Mode  Cnt    Score    Error  Units
> ProxyBench.implClass  avgt    5    3.709 ?  0.026  ns/op
> ProxyBench.implProxy  avgt    5  926.215 ? 11.835  ns/op
> 
> Peter's performance patch:
> 
> Benchmark             Mode  Cnt   Score   Error  Units
> ProxyBench.implClass  avgt    5   3.777 ? 0.005  ns/op
> ProxyBench.implProxy  avgt    5  27.579 ? 0.250  ns/op
> 
> Moved to InvocationHandler + added access check
> 
> Benchmark               Mode  Cnt    Score   Error  Units
> ProxyBench.implClass    avgt    5    3.740 ? 0.004  ns/op
> ProxyBench.implProxy    avgt    5   34.226 ? 0.125  ns/op
> ProxyBench.ppImplClass  avgt    5    3.780 ? 0.004  ns/op
> ProxyBench.ppImplProxy  avgt    5  147.318 ? 1.422  ns/op
> 
> The updated benchmark code is here: https://gist.github.com/plevart/f6e0a5224c3ffbf14b28b47755599226
> (the ppImpl... benchmarks are against package-private interface)

Hi Peter,

The current `newProxyInstance` API does not perform access check against the proxy interfaces.    I want to avoid
adding new caller-sensitive method where possible.   I did consider any alternative to make it non-static method which
only allows a proxy's invocation handler to call `invokeDefaultMethod` if `proxy.getInvocationHandler() == this`.  If
access check done at invocation time, `invokeDefaultMethod` still needs to be caller-sensitive which must be a final
method (can't be on a default method)  In addition, an invocation handler to call `invokeDefaultMethod` can't be
implemented in a lambda because it can't self-reference itself.  So the invocation handler that wants to invoke default
methods must be a concrete or anonymous class which is a limitation.

Alan and I also discussed other alternative earlier.   I agree to prototype a slightly different alternative that will
perform access check at proxy instance creation time: 1. define an abstract `DelegatingInvocationHandler` class that
defines a protected final `invokeDefault` method (shortened method name). 2. `Proxy::newProxyClass` will perform access
check if the given `InvocationHandler` is an instance of `DelegatingInvocationHandler` 3. `Proxy(InvocationHandler h)`
constructor should throw an exception if the given `h` is an instance of `DelegatingInvocationHandler`.
`Proxy::getProxyClass` is deprecated and it's recommended to call `newProxyInstance` instead.  It's strongly
discouraged to invoke the Proxy constructor and so I think not supporting `DelegatingInvocationHandler` may be
reasonable. 4. `Proxy::getInvocationHandler` needs to check if the caller class has access to the proxy interfaces if
it's a `DelegatingInvocationHandler`.

So one can't get a proxy instance whose invocation handler can invoke default methods if the caller has no access to
the proxy interfaces; similarly one can't get a `DelegatingInvocationHandler` from a proxy instance if the caller has
no access.

This alternative avoids `invokeDefault` being caller-sensitive but the limitation of `DelegatingInvocationHandler`
implementation in a concrete/anonymous class.

Thought/feedback?

-------------

PR: https://git.openjdk.java.net/jdk/pull/313

From redestad at openjdk.java.net  Thu Oct 15 19:08:19 2020
From: redestad at openjdk.java.net (Claes Redestad)
Date: Thu, 15 Oct 2020 19:08:19 GMT
Subject: RFR: 8254146: Avoid unnecessary volatile write on new
 AtomicBoolean(false)
In-Reply-To: <gvcLDkPPC4XuKqtAaSUiKhiRXWW0v_cQfnMsz22T3RI=.86f4cbcb-cd02-4e6a-98a9-120fa46cc497@github.com>
References: <AzWKluHZjvFYm2wUanwYfn91iKKMacpk_qSsje3tXWk=.ba873b46-4e12-4415-8832-fa314d6759a3@github.com>
 <RyR2m1MR6UPKbcnxdi_tHwJvQxEtMhT-o2ljRTQDcEo=.976aa7a1-6706-4502-a150-5eb25dd744d1@github.com>
 <b7teCaJhFTu-4FHTyQqDwOqy1B1blXQaoowClBcqnTU=.d75b5dd9-050b-4137-b8fd-8b8e9171a6ca@github.com>
 <xc23wavVAM3Cu4YOo122ikO4FDNUeEx0O96jUobmrYM=.455b3ead-f83b-4956-9f0a-844b3f538b57@github.com>
 <gvcLDkPPC4XuKqtAaSUiKhiRXWW0v_cQfnMsz22T3RI=.86f4cbcb-cd02-4e6a-98a9-120fa46cc497@github.com>
Message-ID: <U1IJfN94lsWZr8VITuU9ZPOJFZrj8EzC0Lo5K9R-LFQ=.9745aaa3-ff28-4563-9f47-8dbe83e2388c@github.com>

On Thu, 15 Oct 2020 12:09:09 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

>>> What do you think?
>> 
>> For `AtomicBoolean`, this optimization piggy-backed on an existing test, just rewriting it so that no action is taken
>> when none is needed. So it's never a pessimization, and even improves bytecode size marginally. So it'll be a marginal
>> gain even if the current overhead of writing to a volatile field in a constructor is removed/reduced.   For
>> `AtomicInteger/-Long`, we'd have to add a test that's not there, so we'd pessimize non-zero cases by adding some
>> bytecode and a branch to remove the overhead. An overhead that can already be avoided by calling the empty constructor
>> instead. So I think it's questionable to do this.  In the short term we could consider a point fix to replace existing
>> use of `new AtomicInteger/-Long(0)` with `new AtomicInteger/-Long()`, but in the long term we should really try and
>> optimize our JITs so that writing to a volatile field in constructors can be made cheaper.
>
> @cl4es , @dreis2211 thanks for explanation!

> On 15/10/2020 11:41, Claes Redestad wrote:
> 
> > In the short term we could consider a point fix to replace existing
> > use of `new AtomicInteger/-Long(0)` with `new
> > AtomicInteger/-Long()`, but in the long term we should really try
> > and optimize our JITs so that writing to a volatile field in
> > constructors can be made cheaper.
> 
> I guess it all depends on whether there's a happens-before
> relationship between the volatile store to Field X in a constructor
> and any subsequent get() of Field X in another thread. Intuitively I
> would have thought so, but I can't find any guarantee in the spec.
> Nonetheless, I think we'd have little gain by changing this and it
> might break (arguably incorrect) programs.

I misphrased somewhat: I think we should try and remove explicit stores of default values to volatile fields in
constructors, as suggested by https://bugs.openjdk.java.net/browse/JDK-8145948

I can't think of a way this would break any program (even arguably incorrect ones), and would net us the gains shown in
comments here without any point fixes.

-------------

PR: https://git.openjdk.java.net/jdk/pull/510

From igraves at openjdk.java.net  Thu Oct 15 19:20:28 2020
From: igraves at openjdk.java.net (Ian Graves)
Date: Thu, 15 Oct 2020 19:20:28 GMT
Subject: RFR: 8253459: Formatter treats index,
 width and precision > Integer.MAX_VALUE incorrectly [v5]
In-Reply-To: <3aYgWcp1IVMM0vQT5UMLSnc2JA1uK9cbtRe283RF37g=.fc2049ef-cdbe-4948-a24b-fdb88cc87a1c@github.com>
References: <3aYgWcp1IVMM0vQT5UMLSnc2JA1uK9cbtRe283RF37g=.fc2049ef-cdbe-4948-a24b-fdb88cc87a1c@github.com>
Message-ID: <4unPdZ6ip7WjZYg3AK-wZg6YTJBGlXN0XB2h8dlgyQc=.2e232f34-269d-4021-999d-fc43ecc3391b@github.com>

> The `java.util.Formatter` format specifies support for field widths, argument indexes, or precision lengths of a field
> that relate to the variadic arguments supplied to the formatter. These numbers are specified by integers, sometimes
> negative. For argument index, it's specified in the documentation that the highest allowed argument is limited by the
> largest possible index of an array (ie the largest possible variadic index), but for the other two it's not defined.
> Moreover, what happens when a number field in a string is too large or too small to be represented by a 32-bit integer
> type is not defined.  This fix adds documentation to specify what error behavior occurs during these cases.
> Additionally it adds an additional exception type to throw when an invalid argument index is observed.  A CSR will be
> required for this PR.

Ian Graves has updated the pull request incrementally with one additional commit since the last revision:

  Additional specificity around width

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/516/files
  - new: https://git.openjdk.java.net/jdk/pull/516/files/9b07ef33..0526ef43

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=516&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=516&range=03-04

  Stats: 5 lines in 1 file changed: 3 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/516.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/516/head:pull/516

PR: https://git.openjdk.java.net/jdk/pull/516

From vladimir.kozlov at oracle.com  Thu Oct 15 19:24:59 2020
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 15 Oct 2020 12:24:59 -0700
Subject: Howto replicate failure of 8254790?
In-Reply-To: <661485ab-7de7-26cb-b2b1-3a4f643125eb@oracle.com>
References: <4bd7e9f73ea24ae09f1bb0f1808ce5a7@EX13D46EUB003.ant.amazon.com>
 <661485ab-7de7-26cb-b2b1-3a4f643125eb@oracle.com>
Message-ID: <617f010e-629d-7329-ac72-dce797bf3075@oracle.com>

Note, we have old Mac machines in our testing env:
cx8, cmov, fxsr, ht, mmx, 3dnowpref, sse, sse2, sse3, ssse3, sse4.1, sse4.2, popcnt, lzcnt, tsc, tscinvbit, avx, avx2, 
aes, erms, clmul, bmi1, bmi2, rtm, adx, fma, vzeroupper, clflush, clflushopt

Use -XX:UseAVX=2

But I was not able reproduce failure on my Skylake Linux machine even with -XX:UseAVX=2. Maybe there are other factors 
on MacOS.

Regards,
Vladimir K

On 10/14/20 5:48 PM, David Holmes wrote:
> Hi Jason,
> 
> On 15/10/2020 10:42 am, Tatton, Jason wrote:
>> Hi all,
>>
>>
>>
>> I am trying to replicate the failure of the tier2 test mentioned in 
>> 8254790<https://bugs.openjdk.java.net/browse/JDK-8254790> but I am only seeing it pass under an x86 linux machine. Are 
>> there any specific architectural constraints under which this test should be run in order to make it fail?
> 
> It failed on a Mac, not Linux.
> 
> Cheers,
> David
> 
>>
>>
>> I am running the test via: make test TEST="test/jdk/javax/xml/crypto/dsig/GenerationTests.java"
>>
>>
>>
>> Note that I am running the test against master without the commit: "8254792: Disable intrinsic StringLatin1.indexOf 
>> until 8254790 is fixed" which disables the intrinsic that is causing the test to fail.
>>
>>
>>
>> Thanks
>> -- 
>> Jason
>>

From jptatton at amazon.com  Thu Oct 15 21:10:24 2020
From: jptatton at amazon.com (Tatton, Jason)
Date: Thu, 15 Oct 2020 21:10:24 +0000
Subject: Howto replicate failure of 8254790?
In-Reply-To: <617f010e-629d-7329-ac72-dce797bf3075@oracle.com>
References: <4bd7e9f73ea24ae09f1bb0f1808ce5a7@EX13D46EUB003.ant.amazon.com>
 <661485ab-7de7-26cb-b2b1-3a4f643125eb@oracle.com>
 <617f010e-629d-7329-ac72-dce797bf3075@oracle.com>
Message-ID: <d6061b53d0854305a1fdb1a5ea7a019c@EX13D46EUB003.ant.amazon.com>

Thanks Vladimir and David, I have access to a new macbook with an Intel i7-9750H (supports AVX2) so I will try on that.

-----Original Message-----
From: Vladimir Kozlov <vladimir.kozlov at oracle.com> 
Sent: 15 October 2020 20:25
To: David Holmes <david.holmes at oracle.com>; Tatton, Jason <jptatton at amazon.com>; hotspot-compiler-dev at openjdk.java.net; core-libs-dev at openjdk.java.net
Subject: RE: [EXTERNAL] Howto replicate failure of 8254790?

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.



Note, we have old Mac machines in our testing env:
cx8, cmov, fxsr, ht, mmx, 3dnowpref, sse, sse2, sse3, ssse3, sse4.1, sse4.2, popcnt, lzcnt, tsc, tscinvbit, avx, avx2, aes, erms, clmul, bmi1, bmi2, rtm, adx, fma, vzeroupper, clflush, clflushopt

Use -XX:UseAVX=2

But I was not able reproduce failure on my Skylake Linux machine even with -XX:UseAVX=2. Maybe there are other factors on MacOS.

Regards,
Vladimir K

On 10/14/20 5:48 PM, David Holmes wrote:
> Hi Jason,
>
> On 15/10/2020 10:42 am, Tatton, Jason wrote:
>> Hi all,
>>
>>
>>
>> I am trying to replicate the failure of the tier2 test mentioned in 
>> 8254790<https://bugs.openjdk.java.net/browse/JDK-8254790> but I am 
>> only seeing it pass under an x86 linux machine. Are there any specific architectural constraints under which this test should be run in order to make it fail?
>
> It failed on a Mac, not Linux.
>
> Cheers,
> David
>
>>
>>
>> I am running the test via: make test TEST="test/jdk/javax/xml/crypto/dsig/GenerationTests.java"
>>
>>
>>
>> Note that I am running the test against master without the commit: 
>> "8254792: Disable intrinsic StringLatin1.indexOf until 8254790 is fixed" which disables the intrinsic that is causing the test to fail.
>>
>>
>>
>> Thanks
>> --
>> Jason
>>

From vladimir.kozlov at oracle.com  Thu Oct 15 22:59:20 2020
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 15 Oct 2020 15:59:20 -0700
Subject: Howto replicate failure of 8254790?
In-Reply-To: <d6061b53d0854305a1fdb1a5ea7a019c@EX13D46EUB003.ant.amazon.com>
References: <4bd7e9f73ea24ae09f1bb0f1808ce5a7@EX13D46EUB003.ant.amazon.com>
 <661485ab-7de7-26cb-b2b1-3a4f643125eb@oracle.com>
 <617f010e-629d-7329-ac72-dce797bf3075@oracle.com>
 <d6061b53d0854305a1fdb1a5ea7a019c@EX13D46EUB003.ant.amazon.com>
Message-ID: <efc3cbff-2e42-cf57-c753-f9d30b68d394@oracle.com>

Hi Jason,

I added surrounding instructions dump from hs_err file we have so you can reconstruct x86 assembler from it.

If you look on si_addr: 0x00000000e41d2718 which case memory map failure, it looks like R8 =0x00000007e41d2700 is an 
oop: [B with upper 32-bits zeroed. It seems uppers 32-bits of address were cut.

But I don't see it can happens in stringL_indexof_char() sub. You correctly used movptr() and addptr() instructions.

Vladimir K

On 10/15/20 2:10 PM, Tatton, Jason wrote:
> Thanks Vladimir and David, I have access to a new macbook with an Intel i7-9750H (supports AVX2) so I will try on that.
> 
> -----Original Message-----
> From: Vladimir Kozlov <vladimir.kozlov at oracle.com>
> Sent: 15 October 2020 20:25
> To: David Holmes <david.holmes at oracle.com>; Tatton, Jason <jptatton at amazon.com>; hotspot-compiler-dev at openjdk.java.net; core-libs-dev at openjdk.java.net
> Subject: RE: [EXTERNAL] Howto replicate failure of 8254790?
> 
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
> 
> 
> 
> Note, we have old Mac machines in our testing env:
> cx8, cmov, fxsr, ht, mmx, 3dnowpref, sse, sse2, sse3, ssse3, sse4.1, sse4.2, popcnt, lzcnt, tsc, tscinvbit, avx, avx2, aes, erms, clmul, bmi1, bmi2, rtm, adx, fma, vzeroupper, clflush, clflushopt
> 
> Use -XX:UseAVX=2
> 
> But I was not able reproduce failure on my Skylake Linux machine even with -XX:UseAVX=2. Maybe there are other factors on MacOS.
> 
> Regards,
> Vladimir K
> 
> On 10/14/20 5:48 PM, David Holmes wrote:
>> Hi Jason,
>>
>> On 15/10/2020 10:42 am, Tatton, Jason wrote:
>>> Hi all,
>>>
>>>
>>>
>>> I am trying to replicate the failure of the tier2 test mentioned in
>>> 8254790<https://bugs.openjdk.java.net/browse/JDK-8254790> but I am
>>> only seeing it pass under an x86 linux machine. Are there any specific architectural constraints under which this test should be run in order to make it fail?
>>
>> It failed on a Mac, not Linux.
>>
>> Cheers,
>> David
>>
>>>
>>>
>>> I am running the test via: make test TEST="test/jdk/javax/xml/crypto/dsig/GenerationTests.java"
>>>
>>>
>>>
>>> Note that I am running the test against master without the commit:
>>> "8254792: Disable intrinsic StringLatin1.indexOf until 8254790 is fixed" which disables the intrinsic that is causing the test to fail.
>>>
>>>
>>>
>>> Thanks
>>> --
>>> Jason
>>>

From coleenp at openjdk.java.net  Thu Oct 15 23:18:14 2020
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Thu, 15 Oct 2020 23:18:14 GMT
Subject: RFR: 8254231: Implementation of Foreign Linker API (Incubator)
 [v4]
In-Reply-To: <0Zh0H5gSXzvHSstQ2w8NBM-P8yERRPouvhZJDNGvu4A=.6cde913f-7499-4c45-bc63-b717502b661e@github.com>
References: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
 <0Zh0H5gSXzvHSstQ2w8NBM-P8yERRPouvhZJDNGvu4A=.6cde913f-7499-4c45-bc63-b717502b661e@github.com>
Message-ID: <2moJ2056gzwWoleYccv21TpFYQHw5h9bA-IZCImplhs=.763198bf-06b0-4589-b01e-217ba84af94a@github.com>

On Thu, 15 Oct 2020 17:08:28 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This patch contains the changes associated with the first incubation round of the foreign linker access API incubation
>> (see JEP 389 [1]). This work is meant to sit on top of the foreign memory access support (see JEP 393 [2] and
>> associated pull request [3]).
>> The main goal of this API is to provide a way to call native functions from Java code without the need of intermediate
>> JNI glue code. In order to do this, native calls are modeled through the MethodHandle API. I suggest reading the
>> writeup [4] I put together few weeks ago, which illustrates what the foreign linker support is, and how it should be
>> used by clients.  Disclaimer: the pull request mechanism isn't great at managing *dependent* reviews. For this reasons,
>> I'm attaching a webrev which contains only the differences between this PR and the memory access PR. I will be
>> periodically uploading new webrevs, as new iterations come out, to try and make the life of reviewers as simple as
>> possible.  A big thank to Jorn Vernee and Vladimir Ivanov - they are the main architects of all the hotspot changes you
>> see here, and without their help, the foreign linker support wouldn't be what it is today. As usual, a big thank to
>> Paul Sandoz, who provided many insights (often by trying the bits first hand).  Thanks Maurizio
>> Webrev:
>> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/webrev
>> 
>> Javadoc:
>> 
>> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/javadoc/jdk/incubator/foreign/package-summary.html
>> 
>> Specdiff (relative to [3]):
>> 
>> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/specdiff_delta/overview-summary.html
>> 
>> CSR:
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8254232
>> 
>> 
>> 
>> ### API Changes
>> 
>> The API changes are actually rather slim:
>> 
>> * `LibraryLookup`
>>   * This class allows clients to lookup symbols in native libraries; the interface is fairly simple; you can load a library
>>     by name, or absolute path, and then lookup symbols on that library.
>> * `FunctionDescriptor`
>>   * This is an abstraction that is very similar, in spirit, to `MethodType`; it is, at its core, an aggregate of memory
>>     layouts for the function arguments/return type. A function descriptor is used to describe the signature of a native
>>     function.
>> * `CLinker`
>>   * This is the real star of the show. A `CLinker` has two main methods: `downcallHandle` and `upcallStub`; the first takes
>>     a native symbol (as obtained from `LibraryLookup`), a `MethodType` and a `FunctionDescriptor` and returns a
>>     `MethodHandle` instance which can be used to call the target native symbol. The second takes an existing method handle,
>>     and a `FunctionDescriptor` and returns a new `MemorySegment` corresponding to a code stub allocated by the VM which
>>     acts as a trampoline from native code to the user-provided method handle. This is very useful for implementing upcalls.
>>    * This class also contains the various layout constants that should be used by clients when describing native signatures
>>      (e.g. `C_LONG` and friends); these layouts contain additional ABI classfication information (in the form of layout
>>      attributes) which is used by the runtime to *infer* how Java arguments should be shuffled for the native call to take
>>      place.
>>   * Finally, this class provides some helper functions e.g. so that clients can convert Java strings into C strings and
>>     back.
>> * `NativeScope`
>>   * This is an helper class which allows clients to group together logically related allocations; that is, rather than
>>     allocating separate memory segments using separate *try-with-resource* constructs, a `NativeScope` allows clients to
>>     use a _single_ block, and allocate all the required segments there. This is not only an usability boost, but also a
>>     performance boost, since not all allocation requests will be turned into `malloc` calls.
>> * `MemorySegment`
>>   * Only one method added here - namely `handoff(NativeScope)` which allows a segment to be transferred onto an existing
>>     native scope.
>> 
>> ### Safety
>> 
>> The foreign linker API is intrinsically unsafe; many things can go wrong when requesting a native method handle. For
>> instance, the description of the native signature might be wrong (e.g. have too many arguments) - and the runtime has,
>> in the general case, no way to detect such mismatches. For these reasons, obtaining a `CLinker` instance is
>> a *restricted* operation, which can be enabled by specifying the usual JDK property `-Dforeign.restricted=permit` (as
>> it's the case for other restricted method in the foreign memory API).  ### Implementation changes  The Java changes
>> associated with `LibraryLookup` are relative straightforward; the only interesting thing to note here is that library
>> loading does _not_ depend on class loaders, so `LibraryLookup` is not subject to the same restrictions which apply to
>> JNI library loading (e.g. same library cannot be loaded by different classloaders).  As for `NativeScope` the changes
>> are again relatively straightforward; it is an API which sits neatly on top of the foreign meory access API, providing
>> some kind of allocation service which shares the same underlying memory segment(s), and turns an allocation request
>> into a segment slice, which is a much less expensive operation. `NativeScope` comes in two variants: there are native
>> scopes for which the allocation size is known a priori, and native scopes which can grow - these two schemes are
>> implemented by two separate subclasses of `AbstractNativeScopeImpl`.  Of course the bulk of the changes are to support
>> the `CLinker` downcall/upcall routines. These changes cut pretty deep into the JVM; I'll briefly summarize the goal of
>> some of this changes - for further details, Jorn has put together a detailed writeup which explains the rationale
>> behind the VM support, with some references to the code [5].  The main idea behind foreign linker is to infer, given a
>> Java method type (expressed as a `MethodType` instance) and the description of the signature of a native function
>> (expressed as a `FunctionDescriptor` instance) a _recipe_ that can be used to turn a Java call into the corresponding
>> native call targeting the requested native function.  This inference scheme can be defined in a pretty straightforward
>> fashion by looking at the various ABI specifications (for instance, see [6] for the SysV ABI, which is the one used on
>> Linux/Mac). The various `CallArranger` classes, of which we have a flavor for each supported platform, do exactly that
>> kind of inference.  For the inference process to work, we need to attach extra information to memory layouts; it is no
>> longer sufficient to know e.g. that a layout is 32/64 bits - we need to know whether it is meant to represent a
>> floating point value, or an integral value; this knowledge is required because floating points are passed in different
>> registers by most ABIs. For this reason, `CLinker` offers a set of pre-baked, platform-dependent layout constants which
>> contain the required classification attributes (e.g. a `Clinker.TypeKind` enum value). The runtime extracts this
>> attribute, and performs classification accordingly.  A native call is decomposed into a sequence of basic, primitive
>> operations, called `Binding` (see the great javadoc on the `Binding.java` class for more info). There are many such
>> bindings - for instance the `Move` binding is used to move a value into a specific machine register/stack slot. So, the
>> main job of the various `CallingArranger` classes is to determine, given a Java `MethodType` and `FunctionDescriptor`
>> what is the set of bindings associated with the downcall/upcall.  At the heart of the foreign linker support is the
>> `ProgrammableInvoker` class. This class effectively generates a `MethodHandle` which follows the steps described by the
>> various bindings obtained by `CallArranger`. There are actually various strategies to interpret these bindings - listed
>> below:
>> * basic intepreted mode; in this mode, all bindings are interpreted using a stack-based machine written in Java (see
>>   `BindingInterpreter`), except for the `Move` bindings. For these bindings, the move is implemented by allocating
>>   a *buffer* (whose size is ABI specific) and by moving all the lowered values into positions within this buffer. The
>>   buffer is then passed to a piece of assembly code inside the VM which takes values from the buffer and moves them in
>>   their expected registers/stack slots (note that each position in the buffer corresponds to a different register). This
>>   is the most general invocation mode, the more "customizable" one, but also the slowest - since for every call there is
>>   some extra allocation which takes place.
>> 
>> * specialized interpreted mode; same as before, but instead of interpreting the bindings with a stack-based interpreter,
>>   we generate a method handle chain which effectively interprets all the bindings (again, except `Move` ones).
>> 
>> * intrinsified mode; this is typically used in combination with the specialized interpreted mode described above
>>   (although it can also be used with the Java-based binding interpreter). The goal here is to remove the buffer
>>   allocation and copy by introducing an additional JVM intrinsic. If a native call recipe is constant (e.g. the set of
>>   bindings is constant, which is probably the case if the native method handle is stored in a `static`, `final` field),
>>   then the VM can generate specialized assembly code which interprets the `Move` binding without the need to go for an
>>   intermediate buffer. This gives us back performances that are on par with JNI.
>> 
>> For upcalls, the support is not (yet) as advanced, and only the basic interpreted mode is available there. We plan to
>> add support for intrinsified modes there as well, which should considerably boost perfomances (probably well beyond
>> what JNI can offer at the moment, since the upcall support in JNI is not very well optimized).  Again, for more
>> readings on the internals of the foreign linker support, please refer to [5].
>> #### Test changes
>> 
>> Many new tests have been added to validate the foreign linker support; we have high level tests (see `StdLibTest`)
>> which aim at testing the linker from the perspective of code that clients could write. But we also have deeper
>> combinatorial tests (see `TestUpcall` and `TestDowncall`) which are meant to stress every corner of the ABI
>> implementation. There are also some great tests (see the `callarranger` folder) which test the various `CallArranger`s
>> for all the possible platforms; these tests adopt more of a white-box approach - that is, instead of treating the
>> linker machinery as a black box and verify that the support works by checking that the native call returned the results
>> we expected, these tests aims at checking that the set of bindings generated by the call arranger is correct. This also
>> mean that we can test the classification logic for Windows, Mac and Linux regardless of the platform we're executing
>> on.  Some additional microbenchmarks have been added to compare the performances of downcall/upcall with JNI.  [1] -
>> https://openjdk.java.net/jeps/389 [2] - https://openjdk.java.net/jeps/393 [3] -
>> https://git.openjdk.java.net/jdk/pull/548 [4] -
>> https://github.com/openjdk/panama-foreign/blob/foreign-jextract/doc/panama_ffi.md [5] -
>> http://cr.openjdk.java.net/~jvernee/docs/Foreign-abi%20downcall%20intrinsics%20technical%20description.html
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Re-add file erroneously deleted (detected as rename)

I looked through some Hotspot runtime code and that looks ok.  I saw a couple of strange things on my way through the
code.  See comments.

src/hotspot/cpu/x86/foreign_globals_x86.cpp line 2:

> 1: /*
> 2:  * Copyright (c) 2018, Oracle and/or its affiliates. All rights reserved.

Copyright should be 2020.  All the new files should have 2020 as the copyright, a bunch don't.

src/hotspot/cpu/x86/foreign_globals_x86.cpp line 56:

> 54: }
> 55:
> 56: const ABIDescriptor parseABIDescriptor(JNIEnv* env, jobject jabi) {

I don't know if you care about performance but of these env->calls transition into the VM and back out again.  You
should prefix all the code that comes from java to native with JNI_ENTRY and just use native JVM code to implement
these.

src/hotspot/cpu/x86/foreign_globals_x86.hpp line 32:

> 30: #define __ _masm->
> 31:
> 32: struct VectorRegister {

Why are these structs and not classes?

src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp line 3885:

> 3883:
> 3884:   __ flush();
> 3885: }

I think as a future RFE we should refactor this function and generate_native_wrapper since they're similar (this is
nicer to read).  If I can remove is_critical_native code they will be more similar.

-------------

Changes requested by coleenp (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/634

From dholmes at openjdk.java.net  Fri Oct 16 05:38:23 2020
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 16 Oct 2020 05:38:23 GMT
Subject: RFR: 8188055: (ref) Add Reference::refersTo predicate [v5]
In-Reply-To: <FHx-oBhE254DZWHhg2RTKjZn_-yYN5xadTW7GXhTxzM=.7e6a46fa-5259-428c-b725-81b4fe48b8f7@github.com>
References: <D4HSg8FT20Eaxk5KJkkw0GgETSxRkBn1ipS3Dt0kPto=.e4bab078-2e04-4413-90cb-9bfafb2a6831@github.com>
 <FHx-oBhE254DZWHhg2RTKjZn_-yYN5xadTW7GXhTxzM=.7e6a46fa-5259-428c-b725-81b4fe48b8f7@github.com>
Message-ID: <gerZuLAfVUZE2sQOGX0mZGaiZ2oA-5tTK9ynHSOp2Ws=.c753f63f-7c69-4bea-ae59-ba72901d60ea@github.com>

On Thu, 15 Oct 2020 17:04:37 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Finally returning to this review that was started in April 2020.  I've
>> recast it as a github PR.  I think the security concern raised by Gil
>> has been adequately answered.
>> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-April/029203.html
>> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-July/030401.html
>> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-August/030677.html
>> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-September/030793.html
>> 
>> Please review a new function: java.lang.ref.Reference.refersTo.
>> 
>> This function is needed to test the referent of a Reference object without
>> artificially extending the lifetime of the referent object, as may happen
>> when calling Reference.get.  Some garbage collectors require extending the
>> lifetime of a weak referent when accessed, in order to maintain collector
>> invariants.  Lifetime extension may occur with any collector when the
>> Reference is a SoftReference, as calling get indicates recent access.  This
>> new function also allows testing the referent of a PhantomReference, which
>> can't be accessed by calling get.
>> 
>> The new function uses native methods whose implementations are in the VM so
>> they can use the Access API.  It is the intent that these methods will be
>> intrinsified by optimizing compilers like C2 or graal, but that hasn't been
>> implemented yet.  Bear that in mind before rushing off to change existing
>> uses of Reference.get.
>> 
>> There are two native methods involved, one in Reference and an override in
>> PhantomReference, both package private in java.lang.ref. The reason for this
>> split is to simplify the intrinsification. This is a change from the version
>> from April 2020; that version had a single native method in Reference,
>> implemented using the ON_UNKNOWN_OOP_REF Access reference strength category.
>> However, adding support for that category in the compilers adds significant
>> implementation effort and complexity. Splitting avoids that complexity.
>> 
>> Testing:
>> mach5 tier1
>> Locally (linux-x64) verified the new test passes with various garbage collectors.
>
> Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev
> excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since
> the last revision:
>  - Merge branch 'master' into refersto
>  - More explicit refersTo0 comment.
>  - simplify test
>  - cleanup nits from Mandy
>  - use Object instead of TestObject
>  - improve refersTo0 descriptions
>  - basic functional test
>  - change referent access
>  - expand test
>  - remove CMS comment
>  - ... and 1 more: https://git.openjdk.java.net/jdk/compare/844db4bb...ab4e519b

src/java.base/share/classes/java/lang/ref/PhantomReference.java line 63:

> 61:     }
> 62:
> 63:     /* Override the implementation of Reference.refersTo.

s/refersTo/refersTo0/

-------------

PR: https://git.openjdk.java.net/jdk/pull/498

From dholmes at openjdk.java.net  Fri Oct 16 05:56:21 2020
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 16 Oct 2020 05:56:21 GMT
Subject: RFR: 8188055: (ref) Add Reference::refersTo predicate [v5]
In-Reply-To: <FHx-oBhE254DZWHhg2RTKjZn_-yYN5xadTW7GXhTxzM=.7e6a46fa-5259-428c-b725-81b4fe48b8f7@github.com>
References: <D4HSg8FT20Eaxk5KJkkw0GgETSxRkBn1ipS3Dt0kPto=.e4bab078-2e04-4413-90cb-9bfafb2a6831@github.com>
 <FHx-oBhE254DZWHhg2RTKjZn_-yYN5xadTW7GXhTxzM=.7e6a46fa-5259-428c-b725-81b4fe48b8f7@github.com>
Message-ID: <3L0hT4NZvzC8V2D7WfDFdv1T7FRdTPMPOWWGnHoKxB0=.3f962415-7d0d-40ae-b5ed-a0a1f9da11be@github.com>

On Thu, 15 Oct 2020 17:04:37 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Finally returning to this review that was started in April 2020.  I've
>> recast it as a github PR.  I think the security concern raised by Gil
>> has been adequately answered.
>> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-April/029203.html
>> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-July/030401.html
>> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-August/030677.html
>> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-September/030793.html
>> 
>> Please review a new function: java.lang.ref.Reference.refersTo.
>> 
>> This function is needed to test the referent of a Reference object without
>> artificially extending the lifetime of the referent object, as may happen
>> when calling Reference.get.  Some garbage collectors require extending the
>> lifetime of a weak referent when accessed, in order to maintain collector
>> invariants.  Lifetime extension may occur with any collector when the
>> Reference is a SoftReference, as calling get indicates recent access.  This
>> new function also allows testing the referent of a PhantomReference, which
>> can't be accessed by calling get.
>> 
>> The new function uses native methods whose implementations are in the VM so
>> they can use the Access API.  It is the intent that these methods will be
>> intrinsified by optimizing compilers like C2 or graal, but that hasn't been
>> implemented yet.  Bear that in mind before rushing off to change existing
>> uses of Reference.get.
>> 
>> There are two native methods involved, one in Reference and an override in
>> PhantomReference, both package private in java.lang.ref. The reason for this
>> split is to simplify the intrinsification. This is a change from the version
>> from April 2020; that version had a single native method in Reference,
>> implemented using the ON_UNKNOWN_OOP_REF Access reference strength category.
>> However, adding support for that category in the compilers adds significant
>> implementation effort and complexity. Splitting avoids that complexity.
>> 
>> Testing:
>> mach5 tier1
>> Locally (linux-x64) verified the new test passes with various garbage collectors.
>
> Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev
> excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since
> the last revision:
>  - Merge branch 'master' into refersto
>  - More explicit refersTo0 comment.
>  - simplify test
>  - cleanup nits from Mandy
>  - use Object instead of TestObject
>  - improve refersTo0 descriptions
>  - basic functional test
>  - change referent access
>  - expand test
>  - remove CMS comment
>  - ... and 1 more: https://git.openjdk.java.net/jdk/compare/80d418e3...ab4e519b

src/java.base/share/classes/java/lang/ref/Reference.java line 348:

> 346:      * Tests if this reference object refers to {@code obj}.  If {@code obj} is
> 347:      * {@code null}, this method returns {@code true} if this reference object
> 348:      * refers to {@code null} or has been cleared.

Is there actually a distinction between clearing and referring to null?

-------------

PR: https://git.openjdk.java.net/jdk/pull/498

From chegar at openjdk.java.net  Fri Oct 16 08:13:13 2020
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Fri, 16 Oct 2020 08:13:13 GMT
Subject: Integrated: 8254161: Prevent instantiation of EnumSet subclasses
 through deserialization
In-Reply-To: <etFbiCFeHwDnYXo3yzhQT66jXhSMbRn57DEGZz-d3V8=.55b262dd-27a1-48c2-ae9b-ce6a55f45b53@github.com>
References: <etFbiCFeHwDnYXo3yzhQT66jXhSMbRn57DEGZz-d3V8=.55b262dd-27a1-48c2-ae9b-ce6a55f45b53@github.com>
Message-ID: <u-7pv4EBh8X_TWVuHwD-W1f5727IxL4b5yW8UPOE4Y4=.ed5d0a9f-a56f-4fb5-b034-dae1937da63e@github.com>

On Mon, 12 Oct 2020 13:47:46 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

> TL;DR add EnumSet::readObjectNoData()
> 
> EnumSet is an exemplar of the Serialization Proxy Pattern. As such, it
> should strictly implement that pattern and demonstrate how best to
> defend against inappropriate instantiation through deserialization.
> 
> EnumSet is an extensible class. There are two subclasses in the JDK,
> RegularEnumSet and JumboEnumSet. Since the serialization of an EnumSet
> object writes a replacement object to the serial stream, a serial proxy
> object, then stream objects of type RegularEnumSet or JumboEnumSet are
> not expected in the serial stream. However, if they are present in the
> serial stream, then, during deserialization, the EnumSet::readObject
> method will be invoked. EnumSet::readObject unconditionally throws an
> exception, thus preventing further deserialization of the stream object.
> In this way, stream objects that are subclasses of EnumSet are prevented
> from being instantiated through deserialization. But this is not
> sufficient to prevent such in all scenarios.
> 
> A stream object whose local class equivalent of the specified stream
> class descriptor is a subclasses of EnumSet, but whose specified stream
> class descriptor does not list EnumSet as a superClass, may be
> instantiated through deserialization. Since the stream class descriptor
> does not list EnumSet as a superclass, then the defensive
> EnumSet::readObject is never invoked. To prevent such objects from
> being deserialized, an EnumSet::readObjectNoData() should be added -
> whose implementation unconditionally throws an exception, similar to
> that of the existing EnumSet::readObject.

This pull request has now been integrated.

Changeset: 34583ebd
Author:    Chris Hegarty <chegar at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/34583ebd
Stats:     11 lines in 1 file changed: 11 ins; 0 del; 0 mod

8254161: Prevent instantiation of EnumSet subclasses through deserialization

Reviewed-by: dfuchs, alanb, rriggs, smarks

-------------

PR: https://git.openjdk.java.net/jdk/pull/611

From jvernee at openjdk.java.net  Fri Oct 16 10:01:11 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Fri, 16 Oct 2020 10:01:11 GMT
Subject: RFR: 8254231: Implementation of Foreign Linker API (Incubator)
 [v4]
In-Reply-To: <2moJ2056gzwWoleYccv21TpFYQHw5h9bA-IZCImplhs=.763198bf-06b0-4589-b01e-217ba84af94a@github.com>
References: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
 <0Zh0H5gSXzvHSstQ2w8NBM-P8yERRPouvhZJDNGvu4A=.6cde913f-7499-4c45-bc63-b717502b661e@github.com>
 <2moJ2056gzwWoleYccv21TpFYQHw5h9bA-IZCImplhs=.763198bf-06b0-4589-b01e-217ba84af94a@github.com>
Message-ID: <QQUSsbuhWO-QIzdshiybT-NRBYTmRcSlHwVH3heJxi4=.6a889ce1-eefe-44c0-966a-00ac022a6377@github.com>

On Thu, 15 Oct 2020 22:39:50 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Re-add file erroneously deleted (detected as rename)
>
> src/hotspot/cpu/x86/foreign_globals_x86.cpp line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2018, Oracle and/or its affiliates. All rights reserved.
> 
> Copyright should be 2020.  All the new files should have 2020 as the copyright, a bunch don't.

Ok, will go and check them. FWIW, this file was added back in 2018 in the panama repo. But, I suppose it is considered
new here?

-------------

PR: https://git.openjdk.java.net/jdk/pull/634

From mcimadamore at openjdk.java.net  Fri Oct 16 10:54:21 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 16 Oct 2020 10:54:21 GMT
Subject: RFR: 8254162: Implementation of Foreign-Memory Access API (Third
 Incubator) [v12]
In-Reply-To: <IngRk57F78UN3yySfo6IABbdwnMogGNdYrykh_3em-c=.b81f7478-015c-45ed-9788-58d7519a2770@github.com>
References: <IngRk57F78UN3yySfo6IABbdwnMogGNdYrykh_3em-c=.b81f7478-015c-45ed-9788-58d7519a2770@github.com>
Message-ID: <OKNrCJ2af1GsVZ8J3RdTlDO6_R2eM-lUSqahAH7jTKY=.b6b25956-1d97-4015-80ea-46eb9c2ef526@github.com>

> This patch contains the changes associated with the third incubation round of the foreign memory access API incubation
> (see JEP 393 [1]). This iteration focus on improving the usability of the API in 3 main ways:
> * first, by providing a way to obtain truly *shared* segments, which can be accessed and closed concurrently from
>   multiple threads
> * second, by providing a way to register a memory segment against a `Cleaner`, so as to have some (optional) guarantee
>   that the memory will be deallocated, eventually
> * third, by not requiring users to dive deep into var handles when they first pick up the API; a new `MemoryAccess` class
>   has been added, which defines several useful dereference routines; these are really just thin wrappers around memory
>   access var handles, but they make the barrier of entry for using this API somewhat lower.
> 
> A big conceptual shift that comes with this API refresh is that the role of `MemorySegment` and `MemoryAddress` is not
> the same as it used to be; it used to be the case that a memory address could (sometimes, not always) have a back link
> to the memory segment which originated it; additionally, memory access var handles used `MemoryAddress` as a basic unit
> of dereference.  This has all changed as per this API refresh;  now a `MemoryAddress` is just a dumb carrier which
> wraps a pair of object/long addressing coordinates; `MemorySegment` has become the star of the show, as far as
> dereferencing memory is concerned. You cannot dereference memory if you don't have a segment. This improves usability
> in a number of ways - first, it is a lot easier to wrap native addresses (`long`, essentially) into a `MemoryAddress`;
> secondly, it is crystal clear what a client has to do in order to dereference memory: if a client has a segment, it can
> use that; otherwise, if the client only has an address, it will have to create a segment *unsafely* (this can be done
> by calling `MemoryAddress::asSegmentRestricted`).  A list of the API, implementation and test changes is provided
> below. If  you have any questions, or need more detailed explanations, I (and the  rest of the Panama team) will be
> happy to point at existing discussions,  and/or to provide the feedback required.   A big thank to Erik Osterlund,
> Vladimir Ivanov and David Holmes, without whom the work on shared memory segment would not have been possible; also I'd
> like to thank Paul Sandoz, whose insights on API design have been very helpful in this journey.  Thanks  Maurizio
> Javadoc:   http://cr.openjdk.java.net/~mcimadamore/8254162_v1/javadoc/jdk/incubator/foreign/package-summary.html
> Specdiff:
> 
> http://cr.openjdk.java.net/~mcimadamore/8254162_v1/specdiff/jdk/incubator/foreign/package-summary.html
> 
> CSR:
> 
> https://bugs.openjdk.java.net/browse/JDK-8254163
> 
> 
> 
> ### API Changes
> 
> * `MemorySegment`
>   * drop factory for restricted segment (this has been moved to `MemoryAddress`, see below)
>   * added a no-arg factory for a native restricted segment representing entire native heap
>   * rename `withOwnerThread` to `handoff`
>   * add new `share` method, to create shared segments
>   * add new `registerCleaner` method, to register a segment against a cleaner
>   * add more helpers to create arrays from a segment e.g. `toIntArray`
>   * add some `asSlice` overloads (to make up for the fact that now segments are more frequently used as cursors)
>   * rename `baseAddress` to `address` (so that `MemorySegment` can implement `Addressable`)
> * `MemoryAddress`
>   * drop `segment` accessor
>   * drop `rebase` method and replace it with `segmentOffset` which returns the offset (a `long`) of this address relative
>     to a given segment
> * `MemoryAccess`
>   * New class supporting several static dereference helpers; the helpers are organized by carrier and access mode, where a
>     carrier is one of the usual suspect (a Java primitive, minus `boolean`); the access mode can be simple (e.g. access
>     base address of given segment), or indexed, in which case the accessor takes a segment and either a low-level byte
>     offset,or a high level logical index. The classification is reflected in the naming scheme (e.g. `getByte` vs.
>     `getByteAtOffset` vs `getByteAtIndex`).
> * `MemoryHandles`
>   * drop `withOffset` combinator
>   * drop `withStride` combinator
>   * the basic memory access handle factory now returns a var handle which takes a `MemorySegment` and a `long` - from which
>     it is easy to derive all the other handles using plain var handle combinators.
> * `Addressable`
>   * This is a new interface which is attached to entities which can be projected to a `MemoryAddress`. For now, both
>     `MemoryAddress` and `MemorySegment` implement it; we have plans, with JEP 389 [2] to add more implementations. Clients
>     can largely ignore this interface, which comes in really handy when defining native bindings with tools like `jextract`.
> * `MemoryLayouts`
>   * A new layout, for machine addresses, has been added to the mix.
> 
> 
> 
> ### Implementation changes
> 
> There are two main things to discuss here: support for shared segments, and the general simplification of the memory
> access var handle support.
> #### Shared segments
> 
> The support for shared segments cuts in pretty deep in the VM. Support for shared segments is notoriously hard to
> achieve, at least in a way that guarantees optimal access performances. This is caused by the fact that, if a segment
> is shared, it would be possible for a thread to close it while another is accessing it.  After considering several
> options (see [3]), we zeroed onto an approach which is inspired by an happy idea that Andrew Haley had (and that he
> reminded me of at this year OpenJDK committer workshop - thanks!). The idea is that if we could *freeze* the world
> (e.g. with a GC pause), while a segment is closed, we could then prevent segments from being accessed concurrently to a
> close operation. For this to work, it  is crucial that no GC safepoints can occur between a segment liveness check and
> the access itself (otherwise it would be possible for the accessing thread to stop just right before an unsafe call).
> It also relies on the fact that hotspot/C2 should not be able to propagate loads across safepoints.  Sadly, none of
> these conditions seems to be valid in the current implementation, so we needed to resort to a bit of creativity. First,
> we noted that, if we could mark so called *scoped* method with an annotation, it would be very simply to check as to
> whether a thread was in the middle of a scoped method when we stopped the world for a close operation (btw, instead of
> stopping the world, we do a much more efficient, thread-local polling, thanks to JEP 312 [4]).  The question is, then,
> once we detect that a thread is accessing the very segment we're about to close, what should happen? We first
> experimented with a solution which would install an *asynchronous* exception on the accessing thread, thus making it
> fail. This solution has some desirable properties, in that a `close` operation always succeeds. Unfortunately the
> machinery for async exceptions is a bit fragile (e.g. not all the code in hotspot checks for async exceptions); to
> minimize risks, we decided to revert to a simpler strategy, where `close` might fail when it finds that another thread
> is accessing the segment being closed.  As written in the javadoc, this doesn't mean that clients should just catch and
> try again; an exception on `close` is a bug in the user code, likely arising from lack of synchronization, and should
> be treated as such.  In terms of gritty implementation, we needed to centralize memory access routines in a single
> place, so that we could have a set of routines closely mimicking the primitives exposed by `Unsafe` but which, in
> addition, also provided a liveness check. This way we could mark all these routines with the special `@Scoped`
> annotation, which tells the VM that something important is going on.  To achieve this, we created a new (autogenerated)
> class, called `ScopedMemoryAccess`. This class contains all the main memory access primitives (including bulk access,
> like `copyMemory`, or `setMemory`), and accepts, in addition to the access coordinates, also a scope object, which is
> tested before access. A reachability fence is also thrown in the mix to make sure that the scope is kept alive during
> access (which is important when registering segments against cleaners).  Of course, to make memory access safe, memory
> access var handles, byte buffer var handles, and byte buffer API should use the new `ScopedMemoryAccess` class instead
> of unsafe, so that a liveness check can be triggered (in case a scope is present).  `ScopedMemoryAccess` has a
> `closeScope` method, which initiates the thread-local handshakes, and returns `true` if the handshake completed
> successfully.  The implementation of `MemoryScope` (now significantly simplified from what we had before), has two
> implementations, one for confined segments and one for shared segments; the main difference between the two is what
> happens when the scope is closed; a confined segment sets a boolean flag to false, and returns, whereas a shared
> segment goes into a `CLOSING` state, then starts the handshake, and then updates the state again, to either `CLOSED` or
> `ALIVE` depending on whether the handshake was successful or not. Note that when a shared segment is in the `CLOSING`
> state, `MemorySegment::isAlive` will still return `true`, while the liveness check upon memory access will fail.  ####
> Memory access var handles overhaul  The key realization here was that if all memory access var handles took a
> coordinate pair of `MemorySegment` and `long`, all other access types could be derived from this basic var handle
> form.  This allowed us to remove the on-the-fly var handle generation, and to simply derive structural access var
> handles (such as those obtained by calling `MemoryLayout::varHandle`) using *plain* var handle combinators, so that
> e.g. additional offset is injected into a base memory access var handle.  This also helped in simplifying the
> implementation by removing the special `withStride` and `withOffset` combinators, which previously needed low-level
> access on the innards of the memory access var handle. All that code is now gone.  #### Test changes  Not much to see
> here - most of the tests needed to be updated because of the API changes. Some were beefed up (like the array test,
> since now segments can be projected into many different kinds of arrays). A test has been added to test the `Cleaner`
> functionality, and another stress test has been added for shared segments (`TestHandshake`). Some of the
> microbenchmarks also needed some tweaks - and some of them were also updated to also test performance in the shared
> segment case.  [1] - https://openjdk.java.net/jeps/393 [2] - https://openjdk.java.net/jeps/389 [3] -
> https://mail.openjdk.java.net/pipermail/panama-dev/2020-May/009004.html [4] - https://openjdk.java.net/jeps/312

Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request
now contains 15 commits:

 - Back-port of TestByteBuffer fix
 - Merge branch 'master' into 8254162
 - Merge branch 'master' into 8254162
 - Merge branch 'master' into 8254162
 - Remove spurious check on MemoryScope::confineTo
   Added tests to make sure no spurious exception is thrown when:
   * handing off a segment from A to A
   * sharing an already shared segment
 - Merge branch 'master' into 8254162
 - Simplify example in the toplevel javadoc
 - Tweak support for mapped memory segments
 - Tweak referenced to MemoryAddressProxy in Utils.java
 - Fix performance issue with "small" segment mismatch
 - ... and 5 more: https://git.openjdk.java.net/jdk/compare/1742c44a...6091ed0f

-------------

Changes: https://git.openjdk.java.net/jdk/pull/548/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=548&range=11
  Stats: 8110 lines in 79 files changed: 5403 ins; 1530 del; 1177 mod
  Patch: https://git.openjdk.java.net/jdk/pull/548.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/548/head:pull/548

PR: https://git.openjdk.java.net/jdk/pull/548

From jvernee at openjdk.java.net  Fri Oct 16 10:57:12 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Fri, 16 Oct 2020 10:57:12 GMT
Subject: RFR: 8254231: Implementation of Foreign Linker API (Incubator)
 [v4]
In-Reply-To: <2moJ2056gzwWoleYccv21TpFYQHw5h9bA-IZCImplhs=.763198bf-06b0-4589-b01e-217ba84af94a@github.com>
References: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
 <0Zh0H5gSXzvHSstQ2w8NBM-P8yERRPouvhZJDNGvu4A=.6cde913f-7499-4c45-bc63-b717502b661e@github.com>
 <2moJ2056gzwWoleYccv21TpFYQHw5h9bA-IZCImplhs=.763198bf-06b0-4589-b01e-217ba84af94a@github.com>
Message-ID: <_goqdHgVLP0vMwrSHTTdfsHui0Etdcl5rBGB_8ksII8=.8f2fdc3f-7f67-4434-9096-69b9a64b50d9@github.com>

On Thu, 15 Oct 2020 22:44:54 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Re-add file erroneously deleted (detected as rename)
>
> src/hotspot/cpu/x86/foreign_globals_x86.hpp line 32:
> 
>> 30: #define __ _masm->
>> 31:
>> 32: struct VectorRegister {
> 
> Why are these structs and not classes?

The fields are meant to be accessed directly, so I went with `struct` since the members default to public.

-------------

PR: https://git.openjdk.java.net/jdk/pull/634

From jvernee at openjdk.java.net  Fri Oct 16 11:01:14 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Fri, 16 Oct 2020 11:01:14 GMT
Subject: RFR: 8254231: Implementation of Foreign Linker API (Incubator)
 [v4]
In-Reply-To: <2moJ2056gzwWoleYccv21TpFYQHw5h9bA-IZCImplhs=.763198bf-06b0-4589-b01e-217ba84af94a@github.com>
References: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
 <0Zh0H5gSXzvHSstQ2w8NBM-P8yERRPouvhZJDNGvu4A=.6cde913f-7499-4c45-bc63-b717502b661e@github.com>
 <2moJ2056gzwWoleYccv21TpFYQHw5h9bA-IZCImplhs=.763198bf-06b0-4589-b01e-217ba84af94a@github.com>
Message-ID: <whUZr4eAseu4Eynnb63ZUoH4hshqaVI1gNSsiAbZb4Q=.171650d1-d4af-4b2d-915e-84484214efce@github.com>

On Thu, 15 Oct 2020 22:52:14 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Re-add file erroneously deleted (detected as rename)
>
> src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp line 3885:
> 
>> 3883:
>> 3884:   __ flush();
>> 3885: }
> 
> I think as a future RFE we should refactor this function and generate_native_wrapper since they're similar (this is
> nicer to read).  If I can remove is_critical_native code they will be more similar.

Yes, I've had similar thoughts as well. This is meant to be temporary code any ways.

-------------

PR: https://git.openjdk.java.net/jdk/pull/634

From jvernee at openjdk.java.net  Fri Oct 16 11:15:11 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Fri, 16 Oct 2020 11:15:11 GMT
Subject: RFR: 8254231: Implementation of Foreign Linker API (Incubator)
 [v4]
In-Reply-To: <2moJ2056gzwWoleYccv21TpFYQHw5h9bA-IZCImplhs=.763198bf-06b0-4589-b01e-217ba84af94a@github.com>
References: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
 <0Zh0H5gSXzvHSstQ2w8NBM-P8yERRPouvhZJDNGvu4A=.6cde913f-7499-4c45-bc63-b717502b661e@github.com>
 <2moJ2056gzwWoleYccv21TpFYQHw5h9bA-IZCImplhs=.763198bf-06b0-4589-b01e-217ba84af94a@github.com>
Message-ID: <QDYay9GMfL5qGkEb5KiRcW9eTVkL3iqmQVywG70UVwo=.9d936943-ee36-4b9b-8f40-dea670e9e055@github.com>

On Thu, 15 Oct 2020 22:42:49 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Re-add file erroneously deleted (detected as rename)
>
> src/hotspot/cpu/x86/foreign_globals_x86.cpp line 56:
> 
>> 54: }
>> 55:
>> 56: const ABIDescriptor parseABIDescriptor(JNIEnv* env, jobject jabi) {
> 
> I don't know if you care about performance but of these env->calls transition into the VM and back out again.  You
> should prefix all the code that comes from java to native with JNI_ENTRY and just use native JVM code to implement
> these.

Currently this is prefixed with `JVM_ENTRY` e.g. like:
JVM_ENTRY(jlong, PI_generateAdapter(JNIEnv* env, jclass _unused, jobject abi, jobject layout))
  {
    ThreadToNativeFromVM ttnfvm(thread);
    return ProgrammableInvoker::generate_adapter(env, abi, layout);
  }
JVM_END
(where `generate_adapter` ends up calling `parseABIDescriptor`)

JVM_ENTYRY seems to be mostly the same except for JNI_ENTRY having a `WeakPreserverExceptionMark` as well. Do we need
to switch these? Also, I guess if we want to use VM code directly, we should get rid of the `ThreadToNativeFromVM` RAII
handle.

-------------

PR: https://git.openjdk.java.net/jdk/pull/634

From chegar at openjdk.java.net  Fri Oct 16 11:49:10 2020
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Fri, 16 Oct 2020 11:49:10 GMT
Subject: RFR: 8251989: Hex formatting and parsing utility [v4]
In-Reply-To: <R6ZL6QASZ81hlZ8eiawDp8Z8gkkXuPcKzc3PE5nT0Dg=.63d51928-0db0-41b7-a3ee-6614dba1dedb@github.com>
References: <HSEn47GMS1K3g57mrTZeQk-WZHl3pKGHpX_OOf8VnsU=.740863c2-f9e4-43c4-b500-614aab4078b1@github.com>
 <VpYQwi73QH-fPOrd7wRiLFB8vBDQNoCJac3rEA_tM0c=.f9962324-7e8a-42f1-966b-4e3dc48ae0ac@github.com>
 <vYbUiBDOknIlXX9r3aJsWs8DkIGyA78KrWPL3zCUXX4=.a1523e0b-858c-4946-8606-99adf8d74eec@github.com>
 <R6ZL6QASZ81hlZ8eiawDp8Z8gkkXuPcKzc3PE5nT0Dg=.63d51928-0db0-41b7-a3ee-6614dba1dedb@github.com>
Message-ID: <HYPD-s1z19oBJCW7n8pq7C_mweaVAtBaI5fNd7mvL0g=.fb608188-2de3-4f54-ad1a-92f6d8e149d1@github.com>

On Thu, 15 Oct 2020 18:22:12 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Marked as reviewed by dfuchs (Reviewer).
>
> Please review the corresponding CSR:
>     https://bugs.openjdk.java.net/browse/JDK-8251991

Hi Roger,

This looks very good.

I have a few minor comments:

1. Add an explicit type parameter <A extends Appendable> to toHexDigits
2. Some clean opportunities to reduce line lengths in the test.

I went ahead and created a PR for these, I hope that it ok. Please take a look https://github.com/RogerRiggs/jdk/pull/1
.

-------------

PR: https://git.openjdk.java.net/jdk/pull/482

From rrich at openjdk.java.net  Fri Oct 16 12:08:27 2020
From: rrich at openjdk.java.net (Richard Reingruber)
Date: Fri, 16 Oct 2020 12:08:27 GMT
Subject: RFR: 8227745: Enable Escape Analysis for Better Performance in
 the Presence of JVMTI Agents [v11]
In-Reply-To: <Ll2RereRbuQLgFtIjv9pS92kPvCVuo-BI0cP1zGjVbo=.dad3a33c-0fc3-44fd-810a-f01448cf564c@github.com>
References: <Ll2RereRbuQLgFtIjv9pS92kPvCVuo-BI0cP1zGjVbo=.dad3a33c-0fc3-44fd-810a-f01448cf564c@github.com>
Message-ID: <PnH3p9ym6jtsIPgvPVHjrr2xmP4ityhAQLtpRxQwdDQ=.1cfd84d8-2f8d-4015-9aba-a92b7c3715fa@github.com>

> Hi,
> 
> this is the continuation of the review of the implementation for:
> 
> https://bugs.openjdk.java.net/browse/JDK-8227745
> https://bugs.openjdk.java.net/browse/JDK-8233915
> 
> It allows for JIT optimizations based on escape analysis even if JVMTI agents acquire capabilities to access references
> to objects that are subject to such optimizations, e.g. scalar replacement. The implementation reverts such
> optimizations just before access very much as when switching from JIT compiled execution to the interpreter, aka
> "deoptimization".  Webrev.8 was the last one before before the transition to Git/Github:
> 
> http://cr.openjdk.java.net/~rrich/webrevs/8227745/webrev.8/
> 
> Thanks, Richard.

Richard Reingruber has updated the pull request with a new target base due to a merge or a rebase. The pull request now
contains 26 commits:

 - Removed unused parameter from EscapeBarrierSuspendHandshake.
 - Adaptations to JDK-8254263: Remove special_runtime_exit_condition() check from ~ThreadInVMForHandshake()
   
   With JDK-8254263 the special_runtime_exit_condition() check was removed from
   ~ThreadInVMForHandshake() because now a thread never becomes unsafe when
   processing its own handshakes. EscapeBarrier uses handshakes to sync with the
   target thread for object deoptimization so we add a check for object
   deoptimization to ThreadSafepointState::handle_polling_page_exception().
   
   In JavaThread::wait_for_object_deoptimization() we must check
   is_obj_deopt_suspend() again after handshake/safepoint processing because a
   handshake for obj. deopt suspend could have been processed.
 - Adaptions to lazy/concurrent thread stack processing for ZGC (JEP 376)
 - EATests.java improvements
 - Merge branch 'master' into JDK-8227745
 - The constructor of StackFrameStream takes more parameters after JDK-8253180
 - Merge branch 'master' into JDK-8227745
 - Merge branch 'master' into JDK-8227745
 - Merge branch 'master' into JDK-8227745
 - Factorized fragment out of EscapeBarrier::deoptimize_objects_internal into new method in compiledVFrame.
 - ... and 16 more: https://git.openjdk.java.net/jdk/compare/9359ff03...f02f07b6

-------------

Changes: https://git.openjdk.java.net/jdk/pull/119/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=119&range=10
  Stats: 5863 lines in 53 files changed: 5645 ins; 116 del; 102 mod
  Patch: https://git.openjdk.java.net/jdk/pull/119.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/119/head:pull/119

PR: https://git.openjdk.java.net/jdk/pull/119

From chegar at openjdk.java.net  Fri Oct 16 13:13:19 2020
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Fri, 16 Oct 2020 13:13:19 GMT
Subject: RFR: 8251989: Hex formatting and parsing utility [v4]
In-Reply-To: <HYPD-s1z19oBJCW7n8pq7C_mweaVAtBaI5fNd7mvL0g=.fb608188-2de3-4f54-ad1a-92f6d8e149d1@github.com>
References: <HSEn47GMS1K3g57mrTZeQk-WZHl3pKGHpX_OOf8VnsU=.740863c2-f9e4-43c4-b500-614aab4078b1@github.com>
 <VpYQwi73QH-fPOrd7wRiLFB8vBDQNoCJac3rEA_tM0c=.f9962324-7e8a-42f1-966b-4e3dc48ae0ac@github.com>
 <vYbUiBDOknIlXX9r3aJsWs8DkIGyA78KrWPL3zCUXX4=.a1523e0b-858c-4946-8606-99adf8d74eec@github.com>
 <R6ZL6QASZ81hlZ8eiawDp8Z8gkkXuPcKzc3PE5nT0Dg=.63d51928-0db0-41b7-a3ee-6614dba1dedb@github.com>
 <HYPD-s1z19oBJCW7n8pq7C_mweaVAtBaI5fNd7mvL0g=.fb608188-2de3-4f54-ad1a-92f6d8e149d1@github.com>
Message-ID: <m7JRSJPhDTeiQEA9ZR2pjEgsK8oaGIGxMyriOQP8aKU=.6e36f57a-7d60-4f0c-9084-a98750b79563@github.com>

On Fri, 16 Oct 2020 11:46:47 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

>> Please review the corresponding CSR:
>>     https://bugs.openjdk.java.net/browse/JDK-8251991
>
> Hi Roger,
> 
> This looks very good.
> 
> I have a few minor comments:
> 
> 1. Add an explicit type parameter <A extends Appendable> to toHexDigits
> 2. Some clean opportunities to reduce line lengths in the test.
> 
> I went ahead and created a PR for these, I hope that it ok. Please take a look https://github.com/RogerRiggs/jdk/pull/1
> .

Maybe I'm being too pedantic, but is the use of the term _copy_ for the withers overly prescriptive, and possibly
limiting an implementation? For example, for `withDelimiter` does _copy_ preclude such an implementation:

     /**
      * Returns a copy of this {@code HexFormat} with the delimiter.
      * @param delimiter the delimiter, non-null, may be empty
      * @return a copy of this {@code HexFormat} with the delimiter
      */
     public HexFormat withDelimiter(String delimiter) {
+        if (delimiter.equals(this.delimiter))
+            return this;
         return new HexFormat(delimiter, this.prefix, this.suffix, this.digits);
     }

-------------

PR: https://git.openjdk.java.net/jdk/pull/482

From rriggs at openjdk.java.net  Fri Oct 16 14:03:21 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 16 Oct 2020 14:03:21 GMT
Subject: RFR: 8251989: Hex formatting and parsing utility [v4]
In-Reply-To: <m7JRSJPhDTeiQEA9ZR2pjEgsK8oaGIGxMyriOQP8aKU=.6e36f57a-7d60-4f0c-9084-a98750b79563@github.com>
References: <HSEn47GMS1K3g57mrTZeQk-WZHl3pKGHpX_OOf8VnsU=.740863c2-f9e4-43c4-b500-614aab4078b1@github.com>
 <VpYQwi73QH-fPOrd7wRiLFB8vBDQNoCJac3rEA_tM0c=.f9962324-7e8a-42f1-966b-4e3dc48ae0ac@github.com>
 <vYbUiBDOknIlXX9r3aJsWs8DkIGyA78KrWPL3zCUXX4=.a1523e0b-858c-4946-8606-99adf8d74eec@github.com>
 <R6ZL6QASZ81hlZ8eiawDp8Z8gkkXuPcKzc3PE5nT0Dg=.63d51928-0db0-41b7-a3ee-6614dba1dedb@github.com>
 <HYPD-s1z19oBJCW7n8pq7C_mweaVAtBaI5fNd7mvL0g=.fb608188-2de3-4f54-ad1a-92f6d8e149d1@github.com>
 <m7JRSJPhDTeiQEA9ZR2pjEgsK8oaGIGxMyriOQP8aKU=.6e36f57a-7d60-4f0c-9084-a98750b79563@github.com>
Message-ID: <JKPetBc-Ma9kCD9rzR0eZgFhDlqi6oKutnFym2bTTrI=.8b6f060f-e8a1-42d8-a828-ecc32e43ec39@github.com>

On Fri, 16 Oct 2020 13:10:24 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

> Maybe I'm being too pedantic, but is the use of the term _copy_ for the withers overly prescriptive, and possibly
> limiting an implementation? For example, for `withDelimiter` does _copy_ preclude such an implementation:
> ```
>      /**
>       * Returns a copy of this {@code HexFormat} with the delimiter.
>       * @param delimiter the delimiter, non-null, may be empty
>       * @return a copy of this {@code HexFormat} with the delimiter
>       */
>      public HexFormat withDelimiter(String delimiter) {
> +        if (delimiter.equals(this.delimiter))
> +            return this;
>          return new HexFormat(delimiter, this.prefix, this.suffix, this.digits);
>      }
> ```

Since the instances are immutable, it seemed useful to emphasize that only the instance returned has the requested
change.  Discarding the return value was incorrect programming.  The original instance is not modified. The "copy"
phrasing was used throughout java.time. Since reference equality is specifically dis-allowed for value-based objects,
there is no way to discover a difference between a copy and the original with the same parameters.

-------------

PR: https://git.openjdk.java.net/jdk/pull/482

From rriggs at openjdk.java.net  Fri Oct 16 14:10:20 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 16 Oct 2020 14:10:20 GMT
Subject: RFR: 8251989: Hex formatting and parsing utility [v4]
In-Reply-To: <JKPetBc-Ma9kCD9rzR0eZgFhDlqi6oKutnFym2bTTrI=.8b6f060f-e8a1-42d8-a828-ecc32e43ec39@github.com>
References: <HSEn47GMS1K3g57mrTZeQk-WZHl3pKGHpX_OOf8VnsU=.740863c2-f9e4-43c4-b500-614aab4078b1@github.com>
 <VpYQwi73QH-fPOrd7wRiLFB8vBDQNoCJac3rEA_tM0c=.f9962324-7e8a-42f1-966b-4e3dc48ae0ac@github.com>
 <vYbUiBDOknIlXX9r3aJsWs8DkIGyA78KrWPL3zCUXX4=.a1523e0b-858c-4946-8606-99adf8d74eec@github.com>
 <R6ZL6QASZ81hlZ8eiawDp8Z8gkkXuPcKzc3PE5nT0Dg=.63d51928-0db0-41b7-a3ee-6614dba1dedb@github.com>
 <HYPD-s1z19oBJCW7n8pq7C_mweaVAtBaI5fNd7mvL0g=.fb608188-2de3-4f54-ad1a-92f6d8e149d1@github.com>
 <m7JRSJPhDTeiQEA9ZR2pjEgsK8oaGIGxMyriOQP8aKU=.6e36f57a-7d60-4f0c-9084-a98750b79563@github.com>
 <JKPetBc-Ma9kCD9rzR0eZgFhDlqi6oKutnFym2bTTrI=.8b6f060f-e8a1-42d8-a828-ecc32e43ec39@github.com>
Message-ID: <8Hwfzo0uNxusDROyc4iConerZzVUNtpgwFCOUxWtMbs=.73c6d864-e300-4b9e-a733-e1da54010e67@github.com>

On Fri, 16 Oct 2020 14:00:38 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Maybe I'm being too pedantic, but is the use of the term _copy_ for the withers overly prescriptive, and possibly
>> limiting an implementation? For example, for `withDelimiter` does _copy_ preclude such an implementation:
>>      /**
>>       * Returns a copy of this {@code HexFormat} with the delimiter.
>>       * @param delimiter the delimiter, non-null, may be empty
>>       * @return a copy of this {@code HexFormat} with the delimiter
>>       */
>>      public HexFormat withDelimiter(String delimiter) {
>> +        if (delimiter.equals(this.delimiter))
>> +            return this;
>>          return new HexFormat(delimiter, this.prefix, this.suffix, this.digits);
>>      }
>
>> Maybe I'm being too pedantic, but is the use of the term _copy_ for the withers overly prescriptive, and possibly
>> limiting an implementation? For example, for `withDelimiter` does _copy_ preclude such an implementation:
>> ```
>>      /**
>>       * Returns a copy of this {@code HexFormat} with the delimiter.
>>       * @param delimiter the delimiter, non-null, may be empty
>>       * @return a copy of this {@code HexFormat} with the delimiter
>>       */
>>      public HexFormat withDelimiter(String delimiter) {
>> +        if (delimiter.equals(this.delimiter))
>> +            return this;
>>          return new HexFormat(delimiter, this.prefix, this.suffix, this.digits);
>>      }
>> ```
> 
> Since the instances are immutable, it seemed useful to emphasize that only the instance returned has the requested
> change.  Discarding the return value was incorrect programming.  The original instance is not modified. The "copy"
> phrasing was used throughout java.time. Since reference equality is specifically dis-allowed for value-based objects,
> there is no way to discover a difference between a copy and the original with the same parameters.

Thanks for the PR.
For TestNG asserts as a point of personal style, I eschew the static imports for asserts.
The correction for `<A extends Appendable>` is already in the works.

-------------

PR: https://git.openjdk.java.net/jdk/pull/482

From chegar at openjdk.java.net  Fri Oct 16 14:27:15 2020
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Fri, 16 Oct 2020 14:27:15 GMT
Subject: RFR: 8251989: Hex formatting and parsing utility [v4]
In-Reply-To: <JKPetBc-Ma9kCD9rzR0eZgFhDlqi6oKutnFym2bTTrI=.8b6f060f-e8a1-42d8-a828-ecc32e43ec39@github.com>
References: <HSEn47GMS1K3g57mrTZeQk-WZHl3pKGHpX_OOf8VnsU=.740863c2-f9e4-43c4-b500-614aab4078b1@github.com>
 <VpYQwi73QH-fPOrd7wRiLFB8vBDQNoCJac3rEA_tM0c=.f9962324-7e8a-42f1-966b-4e3dc48ae0ac@github.com>
 <vYbUiBDOknIlXX9r3aJsWs8DkIGyA78KrWPL3zCUXX4=.a1523e0b-858c-4946-8606-99adf8d74eec@github.com>
 <R6ZL6QASZ81hlZ8eiawDp8Z8gkkXuPcKzc3PE5nT0Dg=.63d51928-0db0-41b7-a3ee-6614dba1dedb@github.com>
 <HYPD-s1z19oBJCW7n8pq7C_mweaVAtBaI5fNd7mvL0g=.fb608188-2de3-4f54-ad1a-92f6d8e149d1@github.com>
 <m7JRSJPhDTeiQEA9ZR2pjEgsK8oaGIGxMyriOQP8aKU=.6e36f57a-7d60-4f0c-9084-a98750b79563@github.com>
 <JKPetBc-Ma9kCD9rzR0eZgFhDlqi6oKutnFym2bTTrI=.8b6f060f-e8a1-42d8-a828-ecc32e43ec39@github.com>
Message-ID: <9AdXf8IZI8Ch1gmDIn7_wiKViBSduw_jAEb0pL0zxrY=.35ff5103-90c3-4d95-94e6-9732d3649353@github.com>

On Fri, 16 Oct 2020 14:00:38 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Since the instances are immutable, it seemed useful to emphasize that only the instance returned has the requested
> change. Discarding the return value was incorrect programming. The original instance is not modified.

Understood, and agree.

> The "copy" phrasing was used throughout java.time.

Ok, but that does not mean that it is appropriate or correct.

> Since reference equality is specifically dis-allowed for value-based objects, there is no way to discover a difference
> between a copy and the original with the same parameters.

A _copy_ implies that something identical or similar is _created_ or _made_, but that does not *always* have to be the
case here, but the spec *requires* it. Why not just; "Returns a formatter similar to this formatter with the given
delimiter". OR something along those lines.

-------------

PR: https://git.openjdk.java.net/jdk/pull/482

From rriggs at openjdk.java.net  Fri Oct 16 14:49:09 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 16 Oct 2020 14:49:09 GMT
Subject: RFR: 8251989: Hex formatting and parsing utility [v4]
In-Reply-To: <9AdXf8IZI8Ch1gmDIn7_wiKViBSduw_jAEb0pL0zxrY=.35ff5103-90c3-4d95-94e6-9732d3649353@github.com>
References: <HSEn47GMS1K3g57mrTZeQk-WZHl3pKGHpX_OOf8VnsU=.740863c2-f9e4-43c4-b500-614aab4078b1@github.com>
 <VpYQwi73QH-fPOrd7wRiLFB8vBDQNoCJac3rEA_tM0c=.f9962324-7e8a-42f1-966b-4e3dc48ae0ac@github.com>
 <vYbUiBDOknIlXX9r3aJsWs8DkIGyA78KrWPL3zCUXX4=.a1523e0b-858c-4946-8606-99adf8d74eec@github.com>
 <R6ZL6QASZ81hlZ8eiawDp8Z8gkkXuPcKzc3PE5nT0Dg=.63d51928-0db0-41b7-a3ee-6614dba1dedb@github.com>
 <HYPD-s1z19oBJCW7n8pq7C_mweaVAtBaI5fNd7mvL0g=.fb608188-2de3-4f54-ad1a-92f6d8e149d1@github.com>
 <m7JRSJPhDTeiQEA9ZR2pjEgsK8oaGIGxMyriOQP8aKU=.6e36f57a-7d60-4f0c-9084-a98750b79563@github.com>
 <JKPetBc-Ma9kCD9rzR0eZgFhDlqi6oKutnFym2bTTrI=.8b6f060f-e8a1-42d8-a828-ecc32e43ec39@github.com>
 <9AdXf8IZI8Ch1gmDIn7_wiKViBSduw_jAEb0pL0zxrY=.35ff5103-90c3-4d95-94e6-9732d3649353@github.com>
Message-ID: <8Bz0GeJ3i2yon_jPtjDMc-9aNnleJ6UGEuTsV-qr-QU=.b0eb152d-353e-4ae7-bc34-e0c45dfb5482@github.com>

On Fri, 16 Oct 2020 14:24:41 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

>>> Maybe I'm being too pedantic, but is the use of the term _copy_ for the withers overly prescriptive, and possibly
>>> limiting an implementation? For example, for `withDelimiter` does _copy_ preclude such an implementation:
>>> ```
>>>      /**
>>>       * Returns a copy of this {@code HexFormat} with the delimiter.
>>>       * @param delimiter the delimiter, non-null, may be empty
>>>       * @return a copy of this {@code HexFormat} with the delimiter
>>>       */
>>>      public HexFormat withDelimiter(String delimiter) {
>>> +        if (delimiter.equals(this.delimiter))
>>> +            return this;
>>>          return new HexFormat(delimiter, this.prefix, this.suffix, this.digits);
>>>      }
>>> ```
>> 
>> Since the instances are immutable, it seemed useful to emphasize that only the instance returned has the requested
>> change.  Discarding the return value was incorrect programming.  The original instance is not modified. The "copy"
>> phrasing was used throughout java.time. Since reference equality is specifically dis-allowed for value-based objects,
>> there is no way to discover a difference between a copy and the original with the same parameters.
>
>> Since the instances are immutable, it seemed useful to emphasize that only the instance returned has the requested
>> change. Discarding the return value was incorrect programming. The original instance is not modified.
> 
> Understood, and agree.
> 
>> The "copy" phrasing was used throughout java.time.
> 
> Ok, but that does not mean that it is appropriate or correct.
> 
>> Since reference equality is specifically dis-allowed for value-based objects, there is no way to discover a difference
>> between a copy and the original with the same parameters.
> 
> A _copy_ implies that something identical or similar is _created_ or _made_, but that does not *always* have to be the
> case here, but the spec *requires* it. Why not just; "Returns a formatter similar to this formatter with the given
> delimiter". OR something along those lines.

The HexFormat API currently uses an indexing model for arrays and strings based on an index and a length.
Many other APIs in the JDK use an index model of `fromIndex` and `toIndex` (exclusive).

They are equivalent and convertible but many programming bugs occur in corners of APIs like this.
Which indexing convention should HexFormat follow?

-------------

PR: https://git.openjdk.java.net/jdk/pull/482

From plevart at openjdk.java.net  Fri Oct 16 14:50:11 2020
From: plevart at openjdk.java.net (Peter Levart)
Date: Fri, 16 Oct 2020 14:50:11 GMT
Subject: RFR: 8159746: (proxy) Support for default methods
In-Reply-To: <zWGhaC8YB5I0XgffiR7o_YT5gSp9Gbj8Drtt23brl-c=.1e59f0e4-bbe3-4fb2-94dc-c55fc862f091@github.com>
References: <kw2VXh3vTFf1zgfd4biXA41OKffZ5oU7KT23tXAxgUA=.bcf14ffc-4dba-4c9c-8754-184172c5acbd@github.com>
 <U-6RiCpFVIrhLztPN6opiPcpFtxValDzU-K7WWFZM-4=.6bc8aaa4-636a-4664-b380-4c4af00513bd@github.com>
 <-cLIJ8pFHtnNoJMHV3aXI7XMJWp4Jrutc8Xn5PG0OK8=.d2cd87ab-3592-4524-ad85-05444c43689b@github.com>
 <r0UK2qjnmgeTNDDSWaSLPAj3QRgx_4YB82ielllO7jM=.fa615bc0-db49-4a74-b842-793f8f5209bb@github.com>
 <1T8kXDZN1bhHr4c8v4SQsImeBySCqTfX-u3_jzvyocA=.b4957400-9a33-4b6e-8475-329642a5888c@github.com>
 <XIux-dY0JXHRafHk48kVNXId9r-HSceNSytBojDxelY=.872e74cb-b064-406e-b71f-13c90ec7fbbc@github.com>
 <j4t2vT0SnwnU7lhKRlXtk967d-K6nA0EqHrqNbba7W0=.dc05dba6-bf7e-4606-8a02-9c2bad4b3b58@github.com>
 <fmVtPcBdgMuZOPm2qx3Q3znVZM7JgQPkhPAVLtwkOhE=.2d8b8447-cfae-4cb3-9a7c-6567a881231f@github.com>
 <GSeWP29fAIUFSk0CYsC557w52CuLqeUWwHNK9maltwI=.3d5f002e-6b74-4a57-a5d8-244d27da9dde@github.com>
 <GF8iEOkMUEL2dYB0HytFIc9gyeeUJ_KP0ImlqFsul2Y=.894afc05-9310-43e1-a308-8f7d71dc572b@github.com>
 <HvtDex3cmiv7XeTMITOroYfu74amSGQavQ_
 BAmVzmXw=.223be989-7c20-4ba4-ac0d-013d2b75a8cb@github.com>
 <IqRiLphFPBpGiKAnMJXqxjie9YeZ03rcE-qG1s92BLw=.d4fd5e92-5067-40df-8a0b-1dfd3d6e23af@github.com>
 <Y0hE51G3YefI6NY1O_E6VoZSKwxE78S1hv6fEatmOG8=.0a2c686c-d9ad-418c-8c1b-49addb8a54b1@github.com>
 <QrNk57L2PWQhJjzYiGTsvYyGIPAfK7bP_kANtTR-2uM=.3e5ce990-f8ea-4751-8147-27a8a9dad40d@github.com>
 <9JNNUzfV3PSvKtSg2a_zyYJmgEn3sZL9cb5sfqemk2o=.f1ef7fb7-bdd5-44ed-98c8-59213e9094f9@github.com>
 <zWGhaC8YB5I0XgffiR7o_YT5gSp9Gbj8Drtt23brl-c=.1e59f0e4-bbe3-4fb2-94dc-c55fc862f091@github.com>
Message-ID: <LljojgqBhEi6tFptsbmu1jS-Xx7lYEXm9tRkkPqDGzE=.3d7d6a37-1042-4539-88d1-9f4cf5378128@github.com>

On Thu, 15 Oct 2020 18:30:20 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Hi Mandy,
>> 
>> I'm beginning to think that we somewhat wondered away from the original intent which was to mimic the bytecode
>> behaviour as much as possible. Bytecode behaviour for super calls (invokespecial) is very special and what you do in
>> the last patch is guarding invocation to a super default method via @CallerSensitive method which checks the access of
>> the caller as though this was a normal call. Similar access check when a default method might reside in a
>> package-private class or when this class might not be exported is already performed when the code creates a Proxy
>> class/instance (Proxy::getProxyClass/newProxyInstance). This code also designates an InvocationHandler for the proxy
>> instance. From that point on, the designated invocation handler should have full access to invoking super default
>> methods on the proxy instance regardless of where it resides because it has been chosen as the delegate of the Proxy
>> class with full powers.  Since we are exposing the invokeDefaultMethod functionality in a public static method, it is
>> hard (or not quite possible) to check that the code doing the invocation is in fact the designated invocation handler
>> code. One approximation might be the following check:  `Proxy.getInvocationHandler(proxy).getClass() == callerClass`
>> ...but that would not work for code residing in the invocation handler superclass even though such code might be
>> eligible to call the super default method. OTOH such check is over permissive as it allows calling the super method
>> from static context too.  So I was thinking about an alternative approach. To expose the method as a protected final
>> instance method in an abstract class implementing InvocationHandler:  public interface InvocationHandler {
>>   ...
>>   abstract class Support implements InvocationHandler {
>>     protected final Object invokeDefaultMethod(Object proxy, Method method, Object... args) throws
>>     InvocationTargetException {
>>       if (this != Proxy.getInvocationHandler(proxy)) throw ...
>>       ...
>>     }
>>   }
>> }
>> 
>> Users would have to extend `InvocationHandler.Support` to access this feature. This might be OK for most users, but
>> those wanting to extend some other class will not be able to do that.
>> So WDYT? In case you still prefer your approach of re-checking the permissions in invokeDefaultMethod, then I might
>> have some ideas of how to speed-up theses checks. As currently stands, invoking public exported interface default
>> methods does exhibit a little more penalty, but for non-public or non-exported interfaces, the penalty is bigger:
>> Mandy's original:
>> Benchmark             Mode  Cnt    Score    Error  Units
>> ProxyBench.implClass  avgt    5    3.709 ?  0.026  ns/op
>> ProxyBench.implProxy  avgt    5  926.215 ? 11.835  ns/op
>> 
>> Peter's performance patch:
>> 
>> Benchmark             Mode  Cnt   Score   Error  Units
>> ProxyBench.implClass  avgt    5   3.777 ? 0.005  ns/op
>> ProxyBench.implProxy  avgt    5  27.579 ? 0.250  ns/op
>> 
>> Moved to InvocationHandler + added access check
>> 
>> Benchmark               Mode  Cnt    Score   Error  Units
>> ProxyBench.implClass    avgt    5    3.740 ? 0.004  ns/op
>> ProxyBench.implProxy    avgt    5   34.226 ? 0.125  ns/op
>> ProxyBench.ppImplClass  avgt    5    3.780 ? 0.004  ns/op
>> ProxyBench.ppImplProxy  avgt    5  147.318 ? 1.422  ns/op
>> 
>> The updated benchmark code is here: https://gist.github.com/plevart/f6e0a5224c3ffbf14b28b47755599226
>> (the ppImpl... benchmarks are against package-private interface)
>
> Hi Peter,
> 
> The current `newProxyInstance` API does not perform access check against the proxy interfaces.    I want to avoid
> adding new caller-sensitive method where possible.   I did consider any alternative to make it non-static method which
> only allows a proxy's invocation handler to call `invokeDefaultMethod` if `proxy.getInvocationHandler() == this`.  If
> access check done at invocation time, `invokeDefaultMethod` still needs to be caller-sensitive which must be a final
> method (can't be on a default method)  In addition, an invocation handler to call `invokeDefaultMethod` can't be
> implemented in a lambda because it can't self-reference itself.  So the invocation handler that wants to invoke default
> methods must be a concrete or anonymous class which is a limitation.    Alan and I also discussed other alternative
> earlier.   I agree to prototype a slightly different alternative that will perform access check at proxy instance
> creation time: 1. define an abstract `DelegatingInvocationHandler` class that defines a protected final `invokeDefault`
> method (shortened method name). 2. `Proxy::newProxyClass` will perform access check if the given `InvocationHandler` is
> an instance of `DelegatingInvocationHandler` 3. `Proxy(InvocationHandler h)` constructor should throw an exception if
> the given `h` is an instance of `DelegatingInvocationHandler`.  `Proxy::getProxyClass` is deprecated and it's
> recommended to call `newProxyInstance` instead.  It's strongly discouraged to invoke the Proxy constructor and so I
> think not supporting `DelegatingInvocationHandler` may be reasonable. 4. `Proxy::getInvocationHandler` needs to check
> if the caller class has access to the proxy interfaces if it's a `DelegatingInvocationHandler`.  So one can't get a
> proxy instance whose invocation handler can invoke default methods if the caller has no access to the proxy interfaces;
> similarly one can't get a `DelegatingInvocationHandler` from a proxy instance if the caller has no access.  This
> alternative avoids `invokeDefault` being caller-sensitive but the limitation of `DelegatingInvocationHandler`
> implementation in a concrete/anonymous class.  Thought/feedback?

Hi Mandy,

I read your concerns and have an alternative API proposition here. Instread of an abstract class with protected final
`invokeDefaultMethod` method, we can keep the public static `invokeDefaultMethod` and add a `Lookup` parameter to it.
The Lookup instance to be passed to the method should be able to `findSpecial` the default method - it has to be the
full privilege lookup with proxy class as lookup class. Such instance is provided in a call to the alternative
invocation handler: `InvocationHandlerWithLookup` which is a super-interface of plain `InvocationHandler` that just
forwards the invocation with the additional Lookup parameter to the abstract method without parameter (in order to keep
backwards-compatibility). The generated proxy class invokes this new method in new interface and passes its own lookup
to it. There's also an overloaded Proxy::newProxyInstance method that takes this new InvocationHandlerWithLookup
parameter instead of plain InvocationHandler. This allows specifying lambdas for both overloaded methods and the right
one is selected according to the number of lambda parameters. invoking the constructor of the proxy class taking plain
InvocationHandler is still allowed but only if the handler class does not use the Lookup parameter. The overloaded
Proxy.newProxyInstance throws IllegalAccessException in case the passed-in handler uses the provided lookup but some
interfaces of the proxy are not accessible.

Performance with this implementation is restored and is not worse when dealing with inaccessible interfaces:

Mandy's original:

Benchmark             Mode  Cnt    Score    Error  Units
ProxyBench.implClass  avgt    5    3.709 ?  0.026  ns/op
ProxyBench.implProxy  avgt    5  926.215 ? 11.835  ns/op


Peter's performance patch:

Benchmark             Mode  Cnt   Score   Error  Units
ProxyBench.implClass  avgt    5   3.777 ? 0.005  ns/op
ProxyBench.implProxy  avgt    5  27.579 ? 0.250  ns/op


Moved to InvocationHandler + added access check

Benchmark               Mode  Cnt    Score   Error  Units
ProxyBench.implClass    avgt    5    3.740 ? 0.004  ns/op
ProxyBench.implProxy    avgt    5   34.226 ? 0.125  ns/op
ProxyBench.ppImplClass  avgt    5    3.780 ? 0.004  ns/op
ProxyBench.ppImplProxy  avgt    5  147.318 ? 1.422  ns/op


Alternative API with access check in newProxyInstance

Benchmark               Mode  Cnt   Score   Error  Units
ProxyBench.implClass    avgt    5   3.782 ? 0.013  ns/op
ProxyBench.implProxy    avgt    5  32.493 ? 0.192  ns/op
ProxyBench.ppImplClass  avgt    5   3.749 ? 0.002  ns/op
ProxyBench.ppImplProxy  avgt    5  30.565 ? 0.190  ns/op

The code is in this pull request against your last commit in your branch: https://github.com/mlchung/jdk/pull/2

-------------

PR: https://git.openjdk.java.net/jdk/pull/313

From kbarrett at openjdk.java.net  Fri Oct 16 15:23:24 2020
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Fri, 16 Oct 2020 15:23:24 GMT
Subject: RFR: 8188055: (ref) Add Reference::refersTo predicate [v5]
In-Reply-To: <3L0hT4NZvzC8V2D7WfDFdv1T7FRdTPMPOWWGnHoKxB0=.3f962415-7d0d-40ae-b5ed-a0a1f9da11be@github.com>
References: <D4HSg8FT20Eaxk5KJkkw0GgETSxRkBn1ipS3Dt0kPto=.e4bab078-2e04-4413-90cb-9bfafb2a6831@github.com>
 <FHx-oBhE254DZWHhg2RTKjZn_-yYN5xadTW7GXhTxzM=.7e6a46fa-5259-428c-b725-81b4fe48b8f7@github.com>
 <3L0hT4NZvzC8V2D7WfDFdv1T7FRdTPMPOWWGnHoKxB0=.3f962415-7d0d-40ae-b5ed-a0a1f9da11be@github.com>
Message-ID: <VZRnbCYjfDq8Bo94vjB9jJKt4_tDFelcEHNiOB4VHuM=.023edb69-a402-44c9-904c-bda9a8349263@github.com>

On Fri, 16 Oct 2020 05:41:17 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev
>> excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since
>> the last revision:
>>  - Merge branch 'master' into refersto
>>  - More explicit refersTo0 comment.
>>  - simplify test
>>  - cleanup nits from Mandy
>>  - use Object instead of TestObject
>>  - improve refersTo0 descriptions
>>  - basic functional test
>>  - change referent access
>>  - expand test
>>  - remove CMS comment
>>  - ... and 1 more: https://git.openjdk.java.net/jdk/compare/b5adeaad...ab4e519b
>
> src/java.base/share/classes/java/lang/ref/Reference.java line 348:
> 
>> 346:      * Tests if this reference object refers to {@code obj}.  If {@code obj} is
>> 347:      * {@code null}, this method returns {@code true} if this reference object
>> 348:      * refers to {@code null} or has been cleared.
> 
> Is there actually a distinction between clearing and referring to null?

A (not very useful) Reference can be created with a null referent.

-------------

PR: https://git.openjdk.java.net/jdk/pull/498

From rriggs at openjdk.java.net  Fri Oct 16 15:26:18 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 16 Oct 2020 15:26:18 GMT
Subject: RFR: 8251989: Hex formatting and parsing utility [v4]
In-Reply-To: <8Bz0GeJ3i2yon_jPtjDMc-9aNnleJ6UGEuTsV-qr-QU=.b0eb152d-353e-4ae7-bc34-e0c45dfb5482@github.com>
References: <HSEn47GMS1K3g57mrTZeQk-WZHl3pKGHpX_OOf8VnsU=.740863c2-f9e4-43c4-b500-614aab4078b1@github.com>
 <VpYQwi73QH-fPOrd7wRiLFB8vBDQNoCJac3rEA_tM0c=.f9962324-7e8a-42f1-966b-4e3dc48ae0ac@github.com>
 <vYbUiBDOknIlXX9r3aJsWs8DkIGyA78KrWPL3zCUXX4=.a1523e0b-858c-4946-8606-99adf8d74eec@github.com>
 <R6ZL6QASZ81hlZ8eiawDp8Z8gkkXuPcKzc3PE5nT0Dg=.63d51928-0db0-41b7-a3ee-6614dba1dedb@github.com>
 <HYPD-s1z19oBJCW7n8pq7C_mweaVAtBaI5fNd7mvL0g=.fb608188-2de3-4f54-ad1a-92f6d8e149d1@github.com>
 <m7JRSJPhDTeiQEA9ZR2pjEgsK8oaGIGxMyriOQP8aKU=.6e36f57a-7d60-4f0c-9084-a98750b79563@github.com>
 <JKPetBc-Ma9kCD9rzR0eZgFhDlqi6oKutnFym2bTTrI=.8b6f060f-e8a1-42d8-a828-ecc32e43ec39@github.com>
 <9AdXf8IZI8Ch1gmDIn7_wiKViBSduw_jAEb0pL0zxrY=.35ff5103-90c3-4d95-94e6-9732d3649353@github.com>
 <8Bz0GeJ3i2yon_jPtjDMc-9aNnleJ6UGEuTsV-qr-QU=.b0eb152d-353e-4ae7-bc34-e0c45dfb5482@github.com>
Message-ID: <rPw9_R5ys44AKkUGwK24gXp64agYp4kq56arBDHPek8=.97703042-ba33-4f60-8660-a43abd7edaeb@github.com>

On Fri, 16 Oct 2020 14:46:11 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>>> Since the instances are immutable, it seemed useful to emphasize that only the instance returned has the requested
>>> change. Discarding the return value was incorrect programming. The original instance is not modified.
>> 
>> Understood, and agree.
>> 
>>> The "copy" phrasing was used throughout java.time.
>> 
>> Ok, but that does not mean that it is appropriate or correct.
>> 
>>> Since reference equality is specifically dis-allowed for value-based objects, there is no way to discover a difference
>>> between a copy and the original with the same parameters.
>> 
>> A _copy_ implies that something identical or similar is _created_ or _made_, but that does not *always* have to be the
>> case here, but the spec *requires* it. Why not just; "Returns a formatter similar to this formatter with the given
>> delimiter". OR something along those lines.
>
> The HexFormat API currently uses an indexing model for arrays and strings based on an index and a length.
> Many other APIs in the JDK use an index model of `fromIndex` and `toIndex` (exclusive).
> 
> They are equivalent and convertible but many programming bugs occur in corners of APIs like this.
> Which indexing convention should HexFormat follow?

> A copy implies that something identical or similar is created or made, but that does not always have to be the case
> here, but the spec requires it. Why not just; "Returns a formatter similar to this formatter with the given delimiter".
> OR something along those lines.

With value-based objects, copies are *always* made, two references to the value are indistinguishable.
The phrasing needs to express that what you get is the same as the original with the parameter requested.
The wording has been a bike-shedding topic in Valhalla for a couple of years.

The usage of 'copy' in java.time did receive a lot of attention and review and is a precedent.

The 'similar to' phrasing is too ambiguous.

How about:
`Returns a HexFormat with the xxx and other parameters from this HexFormat.`

-------------

PR: https://git.openjdk.java.net/jdk/pull/482

From jlahoda at openjdk.java.net  Fri Oct 16 15:27:22 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Fri, 16 Oct 2020 15:27:22 GMT
Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12
Message-ID: <RRMAPzh6xcVcxOj2S_VW_r50YvZz-3Imaj46bDi8e9U=.9347534e-d482-468a-8668-132d5516bb76@github.com>

This is an update to javac and javadoc, to introduce support for Preview APIs, and generally improve javac and javadoc
behavior to more closely adhere to JEP 12.

The notable changes are:

 * adding support for Preview APIs (javac until now supported primarily only preview language features, and APIs
   associated with preview language features). This includes:
     * the @PreviewFeature annotation has boolean attribute "reflective", which should be true for reflective Preview APIs,
       false otherwise. This replaces the existing "essentialAPI" attribute with roughly inverted meaning.
     * the preview warnings for preview APIs are auto-suppressed as described in the JEP 12. E.g. the module that declares the
       preview API is free to use it without warnings
 * improving error/warning messages. Please see [1] for a list of cases/examples.
 * class files are only marked as preview if they are using a preview feature. [1] also shows if a class file is marked as
   preview or not.
 * the PreviewFeature annotation has been moved to jdk.internal.javac package (originally was in the jdk.internal package).
 * Preview API in JDK's javadoc no longer needs to specify @preview tag in the source files. javadoc will auto-generate a
   note for @PreviewFeature elements, see e.g. [2] and [3] (non-reflective and reflective API, respectively). A summary of
   preview elements is also provided [4]. Existing uses of @preview have been updated/removed.
 * non-JDK javadoc is also enhanced to auto-generate preview notes for uses of Preview elements, and for declaring
   elements using preview language features [5].
 
 Please also see the CSR [6] for more information.
 
 [1] http://cr.openjdk.java.net/~jlahoda/8250768/JEP12-errors-warnings-v6.html
 [2] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.base/java/lang/Record.html
 [3]
 http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.compiler/javax/lang/model/element/RecordComponentElement.html
 [4] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/preview-list.html [5]
 http://cr.openjdk.java.net/~jlahoda/8250768/test.javadoc.00/ [6] https://bugs.openjdk.java.net/browse/JDK-8250769

-------------

Commit messages:
 - Fixing tests.
 - Various cleanup.
 - The Preview taglet is not needed anymore.
 - There is not jdk.internal package anymore
 - No, jdk.incubator.vector does not need jdk.internal package.
 - Merging master into JDK-8250768
 - Fixing tests.
 - Adding forgotten files.
 - Updating build.
 - Post-merge fix.
 - ... and 19 more: https://git.openjdk.java.net/jdk/compare/9359ff03...efb37a9b

Changes: https://git.openjdk.java.net/jdk/pull/703/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=703&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8250768
  Stats: 3179 lines in 158 files changed: 2487 ins; 410 del; 282 mod
  Patch: https://git.openjdk.java.net/jdk/pull/703.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/703/head:pull/703

PR: https://git.openjdk.java.net/jdk/pull/703

From chegar at openjdk.java.net  Fri Oct 16 15:32:12 2020
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Fri, 16 Oct 2020 15:32:12 GMT
Subject: RFR: 8251989: Hex formatting and parsing utility [v4]
In-Reply-To: <rPw9_R5ys44AKkUGwK24gXp64agYp4kq56arBDHPek8=.97703042-ba33-4f60-8660-a43abd7edaeb@github.com>
References: <HSEn47GMS1K3g57mrTZeQk-WZHl3pKGHpX_OOf8VnsU=.740863c2-f9e4-43c4-b500-614aab4078b1@github.com>
 <VpYQwi73QH-fPOrd7wRiLFB8vBDQNoCJac3rEA_tM0c=.f9962324-7e8a-42f1-966b-4e3dc48ae0ac@github.com>
 <vYbUiBDOknIlXX9r3aJsWs8DkIGyA78KrWPL3zCUXX4=.a1523e0b-858c-4946-8606-99adf8d74eec@github.com>
 <R6ZL6QASZ81hlZ8eiawDp8Z8gkkXuPcKzc3PE5nT0Dg=.63d51928-0db0-41b7-a3ee-6614dba1dedb@github.com>
 <HYPD-s1z19oBJCW7n8pq7C_mweaVAtBaI5fNd7mvL0g=.fb608188-2de3-4f54-ad1a-92f6d8e149d1@github.com>
 <m7JRSJPhDTeiQEA9ZR2pjEgsK8oaGIGxMyriOQP8aKU=.6e36f57a-7d60-4f0c-9084-a98750b79563@github.com>
 <JKPetBc-Ma9kCD9rzR0eZgFhDlqi6oKutnFym2bTTrI=.8b6f060f-e8a1-42d8-a828-ecc32e43ec39@github.com>
 <9AdXf8IZI8Ch1gmDIn7_wiKViBSduw_jAEb0pL0zxrY=.35ff5103-90c3-4d95-94e6-9732d3649353@github.com>
 <8Bz0GeJ3i2yon_jPtjDMc-9aNnleJ6UGEuTsV-qr-QU=.b0eb152d-353e-4ae7-bc34-e0c45dfb5482@github.com>
 <rPw9_R5ys44AKkUGwK24gXp64agYp4kq56arBDHPek8=.97703042-ba33-4f60-8660-a43abd7edaeb@github.com>
Message-ID: <cE-wvGyAiMsdMrq8CTKrxgkz03TffZWH6m3K5erqWx8=.66d78b32-e0fd-4a4b-8c2e-9d1db28af736@github.com>

On Fri, 16 Oct 2020 15:22:37 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> The HexFormat API currently uses an indexing model for arrays and strings based on an index and a length.
>> Many other APIs in the JDK use an index model of `fromIndex` and `toIndex` (exclusive).
>> 
>> They are equivalent and convertible but many programming bugs occur in corners of APIs like this.
>> Which indexing convention should HexFormat follow?
>
>> A copy implies that something identical or similar is created or made, but that does not always have to be the case
>> here, but the spec requires it. Why not just; "Returns a formatter similar to this formatter with the given delimiter".
>> OR something along those lines.
> 
> With value-based objects, copies are *always* made, two references to the value are indistinguishable.
> The phrasing needs to express that what you get is the same as the original with the parameter requested.
> The wording has been a bike-shedding topic in Valhalla for a couple of years.
> 
> The usage of 'copy' in java.time did receive a lot of attention and review and is a precedent.
> 
> The 'similar to' phrasing is too ambiguous.
> 
> How about:
> `Returns a HexFormat with the xxx and other parameters from this HexFormat.`

> > A copy implies that something identical or similar is created or made, but that does not always have to be the case
> > here, but the spec requires it. Why not just; "Returns a formatter similar to this formatter with the given delimiter".
> > OR something along those lines.
> 
> With value-based objects, copies are _always_ made, two references to the value are indistinguishable.
> The phrasing needs to express that what you get is the same as the original with the parameter requested.
> The wording has been a bike-shedding topic in Valhalla for a couple of years.
> 
> The usage of 'copy' in java.time did receive a lot of attention and review and is a precedent.
> 
> The 'similar to' phrasing is too ambiguous.
> 
> How about:
> `Returns a HexFormat with the xxx and other parameters from this HexFormat.`

If _copy_ has been bikeshedded a number of previous times and discussed elsewhere, then I'm ok with that. Please leave
it as is ( use _copy_ ), since there will be just one common term for developers to learn. Just so long as we agree
that it would not preclude an implementation that returns the same instance where all state is the same.

-------------

PR: https://git.openjdk.java.net/jdk/pull/482

From mcimadamore at openjdk.java.net  Fri Oct 16 16:12:11 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 16 Oct 2020 16:12:11 GMT
Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12
In-Reply-To: <RRMAPzh6xcVcxOj2S_VW_r50YvZz-3Imaj46bDi8e9U=.9347534e-d482-468a-8668-132d5516bb76@github.com>
References: <RRMAPzh6xcVcxOj2S_VW_r50YvZz-3Imaj46bDi8e9U=.9347534e-d482-468a-8668-132d5516bb76@github.com>
Message-ID: <5xE8fziHH9n04bSHhODnOB9On3t_zGz-JY0gJhVhP74=.0c79430f-fac0-44f9-82be-40ef2f94a0d9@github.com>

On Fri, 16 Oct 2020 15:20:03 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> This is an update to javac and javadoc, to introduce support for Preview APIs, and generally improve javac and javadoc
> behavior to more closely adhere to JEP 12.
> The notable changes are:
> 
>  * adding support for Preview APIs (javac until now supported primarily only preview language features, and APIs
>    associated with preview language features). This includes:
>      * the @PreviewFeature annotation has boolean attribute "reflective", which should be true for reflective Preview APIs,
>        false otherwise. This replaces the existing "essentialAPI" attribute with roughly inverted meaning.
>      * the preview warnings for preview APIs are auto-suppressed as described in the JEP 12. E.g. the module that declares the
>        preview API is free to use it without warnings
>  * improving error/warning messages. Please see [1] for a list of cases/examples.
>  * class files are only marked as preview if they are using a preview feature. [1] also shows if a class file is marked as
>    preview or not.
>  * the PreviewFeature annotation has been moved to jdk.internal.javac package (originally was in the jdk.internal package).
>  * Preview API in JDK's javadoc no longer needs to specify @preview tag in the source files. javadoc will auto-generate a
>    note for @PreviewFeature elements, see e.g. [2] and [3] (non-reflective and reflective API, respectively). A summary of
>    preview elements is also provided [4]. Existing uses of @preview have been updated/removed.
>  * non-JDK javadoc is also enhanced to auto-generate preview notes for uses of Preview elements, and for declaring
>    elements using preview language features [5].
>  
>  Please also see the CSR [6] for more information.
>  
>  [1] http://cr.openjdk.java.net/~jlahoda/8250768/JEP12-errors-warnings-v6.html
>  [2] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.base/java/lang/Record.html
>  [3]
>  http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.compiler/javax/lang/model/element/RecordComponentElement.html
>  [4] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/preview-list.html [5]
>  http://cr.openjdk.java.net/~jlahoda/8250768/test.javadoc.00/ [6] https://bugs.openjdk.java.net/browse/JDK-8250769

I've done a quick pass over the javac changes, things look good, apart from some (minor) comments.

I'm a bit worried about the scalability of the output in this page:

http://cr.openjdk.java.net/~jlahoda/8250768/test.javadoc.00/use/Factory.html

E.g. if the types which use preview features are a lot (e.g. 50), what would the text inside the black box look like?

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Enter.java line 108:

> 106:     Modules modules;
> 107:     JCDiagnostic.Factory diags;
> 108:     Preview preview;

Are these changes spurious?

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 3565:

> 3563:         }
> 3564:     }
> 3565:     private boolean declaredUsingPreviewFeature(Symbol sym) {

I wonder, maybe this routine should go in Preview.java?

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 2649:

> 2647:         }
> 2648:         if (isRecordStart() && allowRecords) {
> 2649:             checkSourceLevel(Feature.RECORDS);

Is this change really related to the JEP 12?

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 3713:

> 3711:             return classDeclaration(mods, dc);
> 3712:         } if (isRecordStart()) {
> 3713:              checkSourceLevel(Feature.RECORDS);

Same here

src/jdk.compiler/share/classes/com/sun/tools/javac/util/RawDiagnosticFormatter.java line 166:

> 164:             s = "compiler.misc.tree.tag." + StringUtils.toLowerCase(((Tag) arg).name());
> 165:         } else if (arg instanceof Source && arg == Source.DEFAULT &&
> 166:                 CODES_NEEDING_SOURCE_NORMALIZATION.contains(diag.getCode())) {

Nice trick to keep raw output constant across versions :-)

-------------

PR: https://git.openjdk.java.net/jdk/pull/703

From erikj at openjdk.java.net  Fri Oct 16 16:50:12 2020
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Fri, 16 Oct 2020 16:50:12 GMT
Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12
In-Reply-To: <RRMAPzh6xcVcxOj2S_VW_r50YvZz-3Imaj46bDi8e9U=.9347534e-d482-468a-8668-132d5516bb76@github.com>
References: <RRMAPzh6xcVcxOj2S_VW_r50YvZz-3Imaj46bDi8e9U=.9347534e-d482-468a-8668-132d5516bb76@github.com>
Message-ID: <P5BfFxsebzKxmkt3Ds_wM1YmmbbqtCoCJ3l2VzqajDk=.279a85d1-7ee4-4522-a92a-564ee55e5663@github.com>

On Fri, 16 Oct 2020 15:20:03 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> This is an update to javac and javadoc, to introduce support for Preview APIs, and generally improve javac and javadoc
> behavior to more closely adhere to JEP 12.
> The notable changes are:
> 
>  * adding support for Preview APIs (javac until now supported primarily only preview language features, and APIs
>    associated with preview language features). This includes:
>      * the @PreviewFeature annotation has boolean attribute "reflective", which should be true for reflective Preview APIs,
>        false otherwise. This replaces the existing "essentialAPI" attribute with roughly inverted meaning.
>      * the preview warnings for preview APIs are auto-suppressed as described in the JEP 12. E.g. the module that declares the
>        preview API is free to use it without warnings
>  * improving error/warning messages. Please see [1] for a list of cases/examples.
>  * class files are only marked as preview if they are using a preview feature. [1] also shows if a class file is marked as
>    preview or not.
>  * the PreviewFeature annotation has been moved to jdk.internal.javac package (originally was in the jdk.internal package).
>  * Preview API in JDK's javadoc no longer needs to specify @preview tag in the source files. javadoc will auto-generate a
>    note for @PreviewFeature elements, see e.g. [2] and [3] (non-reflective and reflective API, respectively). A summary of
>    preview elements is also provided [4]. Existing uses of @preview have been updated/removed.
>  * non-JDK javadoc is also enhanced to auto-generate preview notes for uses of Preview elements, and for declaring
>    elements using preview language features [5].
>  
>  Please also see the CSR [6] for more information.
>  
>  [1] http://cr.openjdk.java.net/~jlahoda/8250768/JEP12-errors-warnings-v6.html
>  [2] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.base/java/lang/Record.html
>  [3]
>  http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.compiler/javax/lang/model/element/RecordComponentElement.html
>  [4] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/preview-list.html [5]
>  http://cr.openjdk.java.net/~jlahoda/8250768/test.javadoc.00/ [6] https://bugs.openjdk.java.net/browse/JDK-8250769

Build changes look good.

-------------

Marked as reviewed by erikj (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/703

From mchung at openjdk.java.net  Fri Oct 16 17:07:24 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Fri, 16 Oct 2020 17:07:24 GMT
Subject: RFR: 8188055: (ref) Add Reference::refersTo predicate [v5]
In-Reply-To: <FHx-oBhE254DZWHhg2RTKjZn_-yYN5xadTW7GXhTxzM=.7e6a46fa-5259-428c-b725-81b4fe48b8f7@github.com>
References: <D4HSg8FT20Eaxk5KJkkw0GgETSxRkBn1ipS3Dt0kPto=.e4bab078-2e04-4413-90cb-9bfafb2a6831@github.com>
 <FHx-oBhE254DZWHhg2RTKjZn_-yYN5xadTW7GXhTxzM=.7e6a46fa-5259-428c-b725-81b4fe48b8f7@github.com>
Message-ID: <Ch2xqBrcg76WqiK0RVUEl_XcN4o7X4bvo44RPDDi3O8=.852fb1b6-77f5-4aaa-9ed6-bdee28ec8eb3@github.com>

On Thu, 15 Oct 2020 17:04:37 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Finally returning to this review that was started in April 2020.  I've
>> recast it as a github PR.  I think the security concern raised by Gil
>> has been adequately answered.
>> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-April/029203.html
>> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-July/030401.html
>> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-August/030677.html
>> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-September/030793.html
>> 
>> Please review a new function: java.lang.ref.Reference.refersTo.
>> 
>> This function is needed to test the referent of a Reference object without
>> artificially extending the lifetime of the referent object, as may happen
>> when calling Reference.get.  Some garbage collectors require extending the
>> lifetime of a weak referent when accessed, in order to maintain collector
>> invariants.  Lifetime extension may occur with any collector when the
>> Reference is a SoftReference, as calling get indicates recent access.  This
>> new function also allows testing the referent of a PhantomReference, which
>> can't be accessed by calling get.
>> 
>> The new function uses native methods whose implementations are in the VM so
>> they can use the Access API.  It is the intent that these methods will be
>> intrinsified by optimizing compilers like C2 or graal, but that hasn't been
>> implemented yet.  Bear that in mind before rushing off to change existing
>> uses of Reference.get.
>> 
>> There are two native methods involved, one in Reference and an override in
>> PhantomReference, both package private in java.lang.ref. The reason for this
>> split is to simplify the intrinsification. This is a change from the version
>> from April 2020; that version had a single native method in Reference,
>> implemented using the ON_UNKNOWN_OOP_REF Access reference strength category.
>> However, adding support for that category in the compilers adds significant
>> implementation effort and complexity. Splitting avoids that complexity.
>> 
>> Testing:
>> mach5 tier1
>> Locally (linux-x64) verified the new test passes with various garbage collectors.
>
> Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev
> excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since
> the last revision:
>  - Merge branch 'master' into refersto
>  - More explicit refersTo0 comment.
>  - simplify test
>  - cleanup nits from Mandy
>  - use Object instead of TestObject
>  - improve refersTo0 descriptions
>  - basic functional test
>  - change referent access
>  - expand test
>  - remove CMS comment
>  - ... and 1 more: https://git.openjdk.java.net/jdk/compare/3b7ebed6...ab4e519b

Looks good.

-------------

Marked as reviewed by mchung (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/498

From jjg at openjdk.java.net  Fri Oct 16 17:26:10 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Fri, 16 Oct 2020 17:26:10 GMT
Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12
In-Reply-To: <RRMAPzh6xcVcxOj2S_VW_r50YvZz-3Imaj46bDi8e9U=.9347534e-d482-468a-8668-132d5516bb76@github.com>
References: <RRMAPzh6xcVcxOj2S_VW_r50YvZz-3Imaj46bDi8e9U=.9347534e-d482-468a-8668-132d5516bb76@github.com>
Message-ID: <QaGa4X3R9i6YM0TMwbeM_AhmIRCEgb6-6GJzRIpBgqU=.c12f09d7-670f-499c-a91b-edb2c9f9c3ca@github.com>

On Fri, 16 Oct 2020 15:20:03 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> This is an update to javac and javadoc, to introduce support for Preview APIs, and generally improve javac and javadoc
> behavior to more closely adhere to JEP 12.
> The notable changes are:
> 
>  * adding support for Preview APIs (javac until now supported primarily only preview language features, and APIs
>    associated with preview language features). This includes:
>      * the @PreviewFeature annotation has boolean attribute "reflective", which should be true for reflective Preview APIs,
>        false otherwise. This replaces the existing "essentialAPI" attribute with roughly inverted meaning.
>      * the preview warnings for preview APIs are auto-suppressed as described in the JEP 12. E.g. the module that declares the
>        preview API is free to use it without warnings
>  * improving error/warning messages. Please see [1] for a list of cases/examples.
>  * class files are only marked as preview if they are using a preview feature. [1] also shows if a class file is marked as
>    preview or not.
>  * the PreviewFeature annotation has been moved to jdk.internal.javac package (originally was in the jdk.internal package).
>  * Preview API in JDK's javadoc no longer needs to specify @preview tag in the source files. javadoc will auto-generate a
>    note for @PreviewFeature elements, see e.g. [2] and [3] (non-reflective and reflective API, respectively). A summary of
>    preview elements is also provided [4]. Existing uses of @preview have been updated/removed.
>  * non-JDK javadoc is also enhanced to auto-generate preview notes for uses of Preview elements, and for declaring
>    elements using preview language features [5].
>  
>  Please also see the CSR [6] for more information.
>  
>  [1] http://cr.openjdk.java.net/~jlahoda/8250768/JEP12-errors-warnings-v6.html
>  [2] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.base/java/lang/Record.html
>  [3]
>  http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.compiler/javax/lang/model/element/RecordComponentElement.html
>  [4] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/preview-list.html [5]
>  http://cr.openjdk.java.net/~jlahoda/8250768/test.javadoc.00/ [6] https://bugs.openjdk.java.net/browse/JDK-8250769

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassWriterImpl.java line 209:

> 207:                 "sealed".equals(modifiersPart) || "non-sealed".equals(modifiersPart)) {
> 208:                 pre.add(modifiersPart);
> 209:                 pre.add(new HtmlTree(TagName.SUP).add(HtmlTree.A("#preview", contents.previewMark)));

This will likely clash with a public field named "preview". You should choose a name for the anchor that is not a Java
identifier.

Also, in general, it is better to use the `Links` class if possible to create links.

-------------

PR: https://git.openjdk.java.net/jdk/pull/703

From herrick at openjdk.java.net  Fri Oct 16 18:09:15 2020
From: herrick at openjdk.java.net (Andy Herrick)
Date: Fri, 16 Oct 2020 18:09:15 GMT
Subject: RFR: JDK-8254843: Exception launching app on windows in some cases
Message-ID: <TPcZJguZshLTz6DP1TeLYnmI7d2lMrI89UBYXOF0How=.91e29d6f-1b4e-4f5d-bb4d-345d7be2866f@github.com>

JDK-8254843: Exception launching app on windows in some cases
loading splashscreen.dll in WinLaunchercpp would load java.dll from path instead of runtime/bin causing jni launcher to
crash. instead we just use what used to be the fallback, using loadDllWithAddDllDirectory().

-------------

Commit messages:
 - JDK-8254843: Exception launching app on windows in some cases

Changes: https://git.openjdk.java.net/jdk/pull/706/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=706&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8254843
  Stats: 15 lines in 1 file changed: 0 ins; 10 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/706.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/706/head:pull/706

PR: https://git.openjdk.java.net/jdk/pull/706

From mchung at openjdk.java.net  Fri Oct 16 18:18:12 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Fri, 16 Oct 2020 18:18:12 GMT
Subject: RFR: 8159746: (proxy) Support for default methods
In-Reply-To: <LljojgqBhEi6tFptsbmu1jS-Xx7lYEXm9tRkkPqDGzE=.3d7d6a37-1042-4539-88d1-9f4cf5378128@github.com>
References: <kw2VXh3vTFf1zgfd4biXA41OKffZ5oU7KT23tXAxgUA=.bcf14ffc-4dba-4c9c-8754-184172c5acbd@github.com>
 <U-6RiCpFVIrhLztPN6opiPcpFtxValDzU-K7WWFZM-4=.6bc8aaa4-636a-4664-b380-4c4af00513bd@github.com>
 <-cLIJ8pFHtnNoJMHV3aXI7XMJWp4Jrutc8Xn5PG0OK8=.d2cd87ab-3592-4524-ad85-05444c43689b@github.com>
 <r0UK2qjnmgeTNDDSWaSLPAj3QRgx_4YB82ielllO7jM=.fa615bc0-db49-4a74-b842-793f8f5209bb@github.com>
 <1T8kXDZN1bhHr4c8v4SQsImeBySCqTfX-u3_jzvyocA=.b4957400-9a33-4b6e-8475-329642a5888c@github.com>
 <XIux-dY0JXHRafHk48kVNXId9r-HSceNSytBojDxelY=.872e74cb-b064-406e-b71f-13c90ec7fbbc@github.com>
 <j4t2vT0SnwnU7lhKRlXtk967d-K6nA0EqHrqNbba7W0=.dc05dba6-bf7e-4606-8a02-9c2bad4b3b58@github.com>
 <fmVtPcBdgMuZOPm2qx3Q3znVZM7JgQPkhPAVLtwkOhE=.2d8b8447-cfae-4cb3-9a7c-6567a881231f@github.com>
 <GSeWP29fAIUFSk0CYsC557w52CuLqeUWwHNK9maltwI=.3d5f002e-6b74-4a57-a5d8-244d27da9dde@github.com>
 <GF8iEOkMUEL2dYB0HytFIc9gyeeUJ_KP0ImlqFsul2Y=.894afc05-9310-43e1-a308-8f7d71dc572b@github.com>
 <HvtDex3cmiv7XeTMITOroYfu74amSGQavQ_
 BAmVzmXw=.223be989-7c20-4ba4-ac0d-013d2b75a8cb@github.com>
 <IqRiLphFPBpGiKAnMJXqxjie9YeZ03rcE-qG1s92BLw=.d4fd5e92-5067-40df-8a0b-1dfd3d6e23af@github.com>
 <Y0hE51G3YefI6NY1O_E6VoZSKwxE78S1hv6fEatmOG8=.0a2c686c-d9ad-418c-8c1b-49addb8a54b1@github.com>
 <QrNk57L2PWQhJjzYiGTsvYyGIPAfK7bP_kANtTR-2uM=.3e5ce990-f8ea-4751-8147-27a8a9dad40d@github.com>
 <9JNNUzfV3PSvKtSg2a_zyYJmgEn3sZL9cb5sfqemk2o=.f1ef7fb7-bdd5-44ed-98c8-59213e9094f9@github.com>
 <zWGhaC8YB5I0XgffiR7o_YT5gSp9Gbj8Drtt23brl-c=.1e59f0e4-bbe3-4fb2-94dc-c55fc862f091@github.com>
 <LljojgqBhEi6tFptsbmu1jS-Xx7lYEXm9tRkkPqDGzE=.3d7d6a37-1042-4539-88d1-9f4cf5378128@github.com>
Message-ID: <Gn33ydZNxqOpWUrmYiWJadMF0mukI2MR85EtgrV4D1I=.958521f2-1167-4a68-b513-e10bba37ae18@github.com>

On Fri, 16 Oct 2020 14:46:59 GMT, Peter Levart <plevart at openjdk.org> wrote:

>> Hi Peter,
>> 
>> The current `newProxyInstance` API does not perform access check against the proxy interfaces.    I want to avoid
>> adding new caller-sensitive method where possible.   I did consider any alternative to make it non-static method which
>> only allows a proxy's invocation handler to call `invokeDefaultMethod` if `proxy.getInvocationHandler() == this`.  If
>> access check done at invocation time, `invokeDefaultMethod` still needs to be caller-sensitive which must be a final
>> method (can't be on a default method)  In addition, an invocation handler to call `invokeDefaultMethod` can't be
>> implemented in a lambda because it can't self-reference itself.  So the invocation handler that wants to invoke default
>> methods must be a concrete or anonymous class which is a limitation.    Alan and I also discussed other alternative
>> earlier.   I agree to prototype a slightly different alternative that will perform access check at proxy instance
>> creation time: 1. define an abstract `DelegatingInvocationHandler` class that defines a protected final `invokeDefault`
>> method (shortened method name). 2. `Proxy::newProxyClass` will perform access check if the given `InvocationHandler` is
>> an instance of `DelegatingInvocationHandler` 3. `Proxy(InvocationHandler h)` constructor should throw an exception if
>> the given `h` is an instance of `DelegatingInvocationHandler`.  `Proxy::getProxyClass` is deprecated and it's
>> recommended to call `newProxyInstance` instead.  It's strongly discouraged to invoke the Proxy constructor and so I
>> think not supporting `DelegatingInvocationHandler` may be reasonable. 4. `Proxy::getInvocationHandler` needs to check
>> if the caller class has access to the proxy interfaces if it's a `DelegatingInvocationHandler`.  So one can't get a
>> proxy instance whose invocation handler can invoke default methods if the caller has no access to the proxy interfaces;
>> similarly one can't get a `DelegatingInvocationHandler` from a proxy instance if the caller has no access.  This
>> alternative avoids `invokeDefault` being caller-sensitive but the limitation of `DelegatingInvocationHandler`
>> implementation in a concrete/anonymous class.  Thought/feedback?
>
> Hi Mandy,
> 
> I read your concerns and have an alternative API proposition here. Instread of an abstract class with protected final
> `invokeDefaultMethod` method, we can keep the public static `invokeDefaultMethod` and add a `Lookup` parameter to it.
> The Lookup instance to be passed to the method should be able to `findSpecial` the default method - it has to be the
> full privilege lookup with proxy class as lookup class. Such instance is provided in a call to the alternative
> invocation handler: `InvocationHandlerWithLookup` which is a super-interface of plain `InvocationHandler` that just
> forwards the invocation with the additional Lookup parameter to the abstract method without parameter (in order to keep
> backwards-compatibility). The generated proxy class invokes this new method in new interface and passes its own lookup
> to it. There's also an overloaded Proxy::newProxyInstance method that takes this new InvocationHandlerWithLookup
> parameter instead of plain InvocationHandler. This allows specifying lambdas for both overloaded methods and the right
> one is selected according to the number of lambda parameters. invoking the constructor of the proxy class taking plain
> InvocationHandler is still allowed but only if the handler class does not use the Lookup parameter. The overloaded
> Proxy.newProxyInstance throws IllegalAccessException in case the passed-in handler uses the provided lookup but some
> interfaces of the proxy are not accessible.  Performance with this implementation is restored and is not worse when
> dealing with inaccessible interfaces:  Mandy's original:  Benchmark             Mode  Cnt    Score    Error  Units
> ProxyBench.implClass  avgt    5    3.709 ?  0.026  ns/op ProxyBench.implProxy  avgt    5  926.215 ? 11.835  ns/op
> Peter's performance patch:  Benchmark             Mode  Cnt   Score   Error  Units ProxyBench.implClass  avgt    5
> 3.777 ? 0.005  ns/op ProxyBench.implProxy  avgt    5  27.579 ? 0.250  ns/op
> 
> Moved to InvocationHandler + added access check
> 
> Benchmark               Mode  Cnt    Score   Error  Units
> ProxyBench.implClass    avgt    5    3.740 ? 0.004  ns/op
> ProxyBench.implProxy    avgt    5   34.226 ? 0.125  ns/op
> ProxyBench.ppImplClass  avgt    5    3.780 ? 0.004  ns/op
> ProxyBench.ppImplProxy  avgt    5  147.318 ? 1.422  ns/op
> 
> 
> Alternative API with access check in newProxyInstance
> 
> Benchmark               Mode  Cnt   Score   Error  Units
> ProxyBench.implClass    avgt    5   3.782 ? 0.013  ns/op
> ProxyBench.implProxy    avgt    5  32.493 ? 0.192  ns/op
> ProxyBench.ppImplClass  avgt    5   3.749 ? 0.002  ns/op
> ProxyBench.ppImplProxy  avgt    5  30.565 ? 0.190  ns/op
> 
> The code is in this pull request against your last commit in your branch: https://github.com/mlchung/jdk/pull/2

Hi Peter,

This seems an attracting idea to keep the possibility of using lambdas.  However, the full privileged lookup of the
proxy class will be leaked to `InvocationHandlerWithLookup` implementation which imposes security concerns.   This
full-privileged lookup has access to other proxy classes in that module including private members that we don't want to
hand out to user code.

Other than this security concern, we will also need to consider the inconsistency having `java.lang.reflect` API to
reference `Lookup`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/313

From plevart at openjdk.java.net  Fri Oct 16 18:30:13 2020
From: plevart at openjdk.java.net (Peter Levart)
Date: Fri, 16 Oct 2020 18:30:13 GMT
Subject: RFR: 8188055: (ref) Add Reference::refersTo predicate [v5]
In-Reply-To: <iPK64Jh4aJtfqoPDqADOBN8BczKet53bod5y_VjZoBw=.fed662e8-2b40-478b-a9de-4906c0a897dc@github.com>
References: <D4HSg8FT20Eaxk5KJkkw0GgETSxRkBn1ipS3Dt0kPto=.e4bab078-2e04-4413-90cb-9bfafb2a6831@github.com>
 <Y1IHoNr8vO3OkCbEKw6ywXd4adik1yKKNIS4ABzF0d0=.d21f4183-ef4e-45ed-826d-6613215b6220@github.com>
 <9x0zaxknpYXGIvHun1CkLP0lEC8NQmPTnANxQKjhHF8=.907bdb15-2e2e-4f84-8fe4-ea4ed50534cd@github.com>
 <DR2YKv3VavKKD-cpFyf6mCSYfaKq0KAGh2XDqBStkys=.895ba671-f63a-4ba3-b042-6568d647b4ab@github.com>
 <mkn_t3hsL4mlCOfO5ahZOMbp8i_LMOHwJALA_bNjHIk=.d8031a91-ed13-4882-925f-ea8a9e634198@github.com>
 <3JzF7OkemZ-Lxc4jZgdEh3qNDzW8wF7ITeq-s7_TOlo=.11e4e40b-b775-47cf-9862-735fbc61ffd3@github.com>
 <iPK64Jh4aJtfqoPDqADOBN8BczKet53bod5y_VjZoBw=.fed662e8-2b40-478b-a9de-4906c0a897dc@github.com>
Message-ID: <3kV3qhFRXBadf7Tol9n0Yomud_ndV_T_p7ShUfk4eVE=.d7151a63-0066-4020-b0ef-bae0d03dc133@github.com>

On Wed, 14 Oct 2020 18:15:19 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> For the common cases, the application should know the type of the referent and using `T` in `refersTo` will benefit
>> from the compiler type checking.   For the unknown type case, cast to `Reference<Object>` is not ideal but reasonable?
>> something like this:  Reference<Object> r = (Reference<Object>) ref;
>> r.refersTo(obj);
>
> That sounds reasonable to me. Thanks for looking into it.

I just want to note that if you have a `Reference<SomeType> ref` at hand, you can not just do:
Referemce<Object> r = (Reference<Object>) ref;
...since those generic types are not related. You have to do something like:

@SuppressWarnings({"unchecked", "rawtypes"})
Referemce<Object> r = (Reference) ref;
which is very unfortunate. Comparing this method with for example `Collection.contains(Object element)`, you can see
that Collection API has made a decision to not bother with T here. That was also due to keeping old code compatible
when migrating from pre-generics Java to generified Collection, but as @dfuch noted, we have a migration story here
too. We will be migrating `obj == ref.get()` to `ref.refersTo(obj)` ... Mind you that this is a boolean expression
fragment which might be written inline surrounded with other parts of expression. So you'll be forced to split that
into assignment with @SuppressWarnings and an expression or you will have to force the whole expression or method to
@SuppressWarnings. I don't know if type "safety" is forth it here.

-------------

PR: https://git.openjdk.java.net/jdk/pull/498

From mchung at openjdk.java.net  Fri Oct 16 19:28:12 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Fri, 16 Oct 2020 19:28:12 GMT
Subject: RFR: 8188055: (ref) Add Reference::refersTo predicate [v5]
In-Reply-To: <3kV3qhFRXBadf7Tol9n0Yomud_ndV_T_p7ShUfk4eVE=.d7151a63-0066-4020-b0ef-bae0d03dc133@github.com>
References: <D4HSg8FT20Eaxk5KJkkw0GgETSxRkBn1ipS3Dt0kPto=.e4bab078-2e04-4413-90cb-9bfafb2a6831@github.com>
 <Y1IHoNr8vO3OkCbEKw6ywXd4adik1yKKNIS4ABzF0d0=.d21f4183-ef4e-45ed-826d-6613215b6220@github.com>
 <9x0zaxknpYXGIvHun1CkLP0lEC8NQmPTnANxQKjhHF8=.907bdb15-2e2e-4f84-8fe4-ea4ed50534cd@github.com>
 <DR2YKv3VavKKD-cpFyf6mCSYfaKq0KAGh2XDqBStkys=.895ba671-f63a-4ba3-b042-6568d647b4ab@github.com>
 <mkn_t3hsL4mlCOfO5ahZOMbp8i_LMOHwJALA_bNjHIk=.d8031a91-ed13-4882-925f-ea8a9e634198@github.com>
 <3JzF7OkemZ-Lxc4jZgdEh3qNDzW8wF7ITeq-s7_TOlo=.11e4e40b-b775-47cf-9862-735fbc61ffd3@github.com>
 <iPK64Jh4aJtfqoPDqADOBN8BczKet53bod5y_VjZoBw=.fed662e8-2b40-478b-a9de-4906c0a897dc@github.com>
 <3kV3qhFRXBadf7Tol9n0Yomud_ndV_T_p7ShUfk4eVE=.d7151a63-0066-4020-b0ef-bae0d03dc133@github.com>
Message-ID: <WhvzLc5GEYMSBz9jYgaRDBTbpaZGFWPHqzdfYHa-W6Q=.8efc48fe-6ae2-4608-ba4c-136df49c3707@github.com>

On Fri, 16 Oct 2020 18:27:31 GMT, Peter Levart <plevart at openjdk.org> wrote:

>> That sounds reasonable to me. Thanks for looking into it.
>
> I just want to note that if you have a `Reference<SomeType> ref` at hand, you can not just do:
> Referemce<Object> r = (Reference<Object>) ref;
> ...since those generic types are not related. You have to do something like:
> 
> @SuppressWarnings({"unchecked", "rawtypes"})
> Referemce<Object> r = (Reference) ref;
> which is very unfortunate. Comparing this method with for example `Collection.contains(Object element)`, you can see
> that Collection API has made a decision to not bother with T here. That was also due to keeping old code compatible
> when migrating from pre-generics Java to generified Collection, but as @dfuch noted, we have a migration story here
> too. We will be migrating `obj == ref.get()` to `ref.refersTo(obj)` ... Mind you that this is a boolean expression
> fragment which might be written inline surrounded with other parts of expression. So you'll be forced to split that
> into assignment with @SuppressWarnings and an expression or you will have to force the whole expression or method to
> @SuppressWarnings. I don't know if type "safety" is forth it here.

Reference instances should not be leaked and so I don't see very common that caller of `Reference::get` does not know
the referent's type.   It also depends on the `refersTo` check against `null` vs an object.  Any known use case would
be helpful if any (some existing code that wants to call `refersTo` to compare a `Reference` of raw type with an object
of unknown type).

FWIW, when converting a few use of `Reference::get` to `refersTo` in JDK, there is only one case (`equals(Object o)`
method that needs the cast.

http://cr.openjdk.java.net/~mchung/jdk15/webrevs/8188055/jdk-use-refersTo/index.html

-------------

PR: https://git.openjdk.java.net/jdk/pull/498

From asemenyuk at openjdk.java.net  Fri Oct 16 19:30:12 2020
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Fri, 16 Oct 2020 19:30:12 GMT
Subject: RFR: JDK-8254843: Exception launching app on windows in some cases
In-Reply-To: <TPcZJguZshLTz6DP1TeLYnmI7d2lMrI89UBYXOF0How=.91e29d6f-1b4e-4f5d-bb4d-345d7be2866f@github.com>
References: <TPcZJguZshLTz6DP1TeLYnmI7d2lMrI89UBYXOF0How=.91e29d6f-1b4e-4f5d-bb4d-345d7be2866f@github.com>
Message-ID: <WHbSzlMHyV9J2dU2JjNWFuNk3NtGbfYnOz3DJb32I5g=.9b1ea8f1-886e-446c-aedd-4a95a3f7e934@github.com>

On Fri, 16 Oct 2020 17:59:14 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> JDK-8254843: Exception launching app on windows in some cases
> loading splashscreen.dll in WinLaunchercpp would load java.dll from path instead of runtime/bin causing jni launcher to
> crash. instead we just use what used to be the fallback, using loadDllWithAddDllDirectory().

Marked as reviewed by asemenyuk (Committer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/706

From vsharma at openjdk.java.net  Fri Oct 16 19:45:17 2020
From: vsharma at openjdk.java.net (Vipin Sharma)
Date: Fri, 16 Oct 2020 19:45:17 GMT
Subject: RFR: JDK-8253936 Replace <code>...</code> with {@code ...} for
 java.sql
Message-ID: <zr8HOhlJbmboYIC-rVP0S3Mj5FeXOI4lzlUXvL2XMoc=.f173b3a1-f879-458c-9450-c432cecb6d6f@github.com>

<code>...</code> is replaced with {@code ...} in java.sql classes.
Please review and sponsor this change.

-------------

Commit messages:
 - JDK-8253936 Replace <code>...</code> with {@code ...} for java.sql

Changes: https://git.openjdk.java.net/jdk/pull/707/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=707&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8253936
  Stats: 4698 lines in 58 files changed: 0 ins; 0 del; 4698 mod
  Patch: https://git.openjdk.java.net/jdk/pull/707.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/707/head:pull/707

PR: https://git.openjdk.java.net/jdk/pull/707

From rriggs at openjdk.java.net  Fri Oct 16 19:56:30 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 16 Oct 2020 19:56:30 GMT
Subject: RFR: 8251989: Hex formatting and parsing utility [v5]
In-Reply-To: <HSEn47GMS1K3g57mrTZeQk-WZHl3pKGHpX_OOf8VnsU=.740863c2-f9e4-43c4-b500-614aab4078b1@github.com>
References: <HSEn47GMS1K3g57mrTZeQk-WZHl3pKGHpX_OOf8VnsU=.740863c2-f9e4-43c4-b500-614aab4078b1@github.com>
Message-ID: <-Y_CD_hhxBgqmlaQnSxkXPh_88f03wak3HIb1IgnfNY=.ec1f8832-ddbc-4ccd-8b09-08ee8da3f8bd@github.com>

> java.util.HexFormat utility:
> 
>  - Format and parse hexadecimal strings, with parameters for delimiter, prefix, suffix and upper/lowercase
>  - Static factories and builder methods to create HexFormat copies with modified parameters.
>  - Consistent naming of methods for conversion of byte arrays to formatted strings and back: formatHex and parseHex
>  - Consistent naming of methods for conversion of primitive types: toHexDigits... and fromHexDigits...
>  - Prefix and suffixes now apply to each formatted value, not the string as a whole
>  - Using java.util.Appendable as a target for buffered conversions so output to Writers and PrintStreams
>    like System.out are supported in addition to StringBuilder. (IOExceptions are converted to unchecked exceptions)
>  - Immutable and thread safe, a "value-based" class
> 
> See the [HexFormat
> javadoc](http://cr.openjdk.java.net/~rriggs/8251989-hex-formatter/java.base/java/util/HexFormat.html) for details.
> Review comments and suggestions welcome.

Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev
excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since
the last revision:

 - Merge branch 'master' into 8251989-hex-formatter
 - Test enhancements from Chris Hegarty
 - Expanded test coverage and fixed related bugs; Added static imports for TestNG; Corrected declaration of return type of
   tohexDigits(Appendable...)
 - Merge branch 'master' into 8251989-hex-formatter
 - Cleanup of javadoc markup
 - Added assertions to testVariableLength and samples
 - Merge branch 'master' into 8251989-hex-formatter
 - temp updates
 - Various code review comments, rename UpperCase and LowerCase methods to match Character, remove unnecessary Class name
   qualifications, etc.
 - 8251989: Hex formatting and parsing utility

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/482/files
  - new: https://git.openjdk.java.net/jdk/pull/482/files/880cebbf..d9f2b6e4

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=482&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=482&range=03-04

  Stats: 1045 lines in 30 files changed: 567 ins; 276 del; 202 mod
  Patch: https://git.openjdk.java.net/jdk/pull/482.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/482/head:pull/482

PR: https://git.openjdk.java.net/jdk/pull/482

From LANCE.ANDERSEN at ORACLE.COM  Fri Oct 16 20:54:42 2020
From: LANCE.ANDERSEN at ORACLE.COM (Lance Andersen)
Date: Fri, 16 Oct 2020 16:54:42 -0400
Subject: RFR: JDK-8253936 Replace <code>...</code> with {@code ...} for
 java.sql
In-Reply-To: <zr8HOhlJbmboYIC-rVP0S3Mj5FeXOI4lzlUXvL2XMoc=.f173b3a1-f879-458c-9450-c432cecb6d6f@github.com>
References: <zr8HOhlJbmboYIC-rVP0S3Mj5FeXOI4lzlUXvL2XMoc=.f173b3a1-f879-458c-9450-c432cecb6d6f@github.com>
Message-ID: <7F29283E-7183-49BB-85A3-BB09B6F74402@ORACLE.COM>

Hi Vipin,

Have you generated the javadocs for this change?  If not I will pull the changes over this weekend and take a look

> On Oct 16, 2020, at 3:45 PM, Vipin Sharma <vsharma at openjdk.java.net> wrote:
> 
> <code>...</code> is replaced with {@code ...} in java.sql classes.
> Please review and sponsor this change.
> 
> -------------
> 
> Commit messages:
> - JDK-8253936 Replace <code>...</code> with {@code ...} for java.sql
> 
> Changes: https://git.openjdk.java.net/jdk/pull/707/files
> Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=707&range=00
>  Issue: https://bugs.openjdk.java.net/browse/JDK-8253936
>  Stats: 4698 lines in 58 files changed: 0 ins; 0 del; 4698 mod
>  Patch: https://git.openjdk.java.net/jdk/pull/707.diff
>  Fetch: git fetch https://git.openjdk.java.net/jdk pull/707/head:pull/707
> 
> PR: https://git.openjdk.java.net/jdk/pull/707


Best
Lance
------------------




Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com





From ccheung at openjdk.java.net  Fri Oct 16 21:01:23 2020
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Fri, 16 Oct 2020 21:01:23 GMT
Subject: RFR: 8247666: Support Lambda proxy classes in static CDS archive
 [v8]
In-Reply-To: <ynh4JzHY75GjEn5_oCtmRNy9HMFsU34O2PlhSwD41tU=.1a3770f9-9091-429f-8d03-31b826f9b093@github.com>
References: <ynh4JzHY75GjEn5_oCtmRNy9HMFsU34O2PlhSwD41tU=.1a3770f9-9091-429f-8d03-31b826f9b093@github.com>
Message-ID: <0tMvEbzMqsT5-oHGdGcPKLX-bWPJwwypq7wmRmIwzE4=.450e762e-ca0e-4227-b3cc-c76cac88b3be@github.com>

> Following up on archiving lambda proxy classes in dynamic CDS archive
> ([JDK-8198698](https://bugs.openjdk.java.net/browse/JDK-8198698)), this RFE adds the functionality of archiving of
> lambda proxy classes in static CDS archive.
> When the -XX:DumpLoadedClassList is enabled, the constant pool index related to LambdaMetafactory that are resolved
> during application execution will be included in the classlist. The entry for a lambda proxy class in a class list will
> be of the following format:
> `@lambda-proxy: <classname> <cp index>`
> 
> e.g.
> `@lambda-proxy: test/java/lang/invoke/MethodHandlesGeneralTest 233`
> `@lambda-proxy: test/java/lang/invoke/MethodHandlesGeneralTest 355`
> 
> When dumping a CDS archive using the -Xshare:dump and -XX:ExtraSharedClassListFile options, when the above
> `@lambda-proxy` entry is encountered while parsing the classlist, we will resolve the corresponding constant pool
> indices (233 and 355 in the above example). As a result, lambda proxy classes will be generated for the constant pool
> entries, and will be cached using a similar mechanism to JDK-8198698.  During dumping, there is check on the cp index
> and on the created BootstrapInfo using the cp index. VM will exit with an error message if the check has failed.
> During runtime when looking up a lambda proxy class, the lookup will be perform on the static CDS archive and if not
> found, then lookup from the dynamic archive if one is specified.  (Only name change (IsDynamicDumpingEnabled ->
> IsCDSDumpingEnabled) is involved in the core-libs code.)
> Testing: tiers 1,2,3,4.
> 
> Performance results (javac on HelloWorld on linux-x64):
> Results of " perf stat -r 40 bin/javac -J-Xshare:on -J-XX:SharedArchiveFile=javac2.jsa Bench_HelloWorld.java "
>    1:   2228016795  2067752708 (-160264087)      -----    377.760   349.110 (-28.650)      -----
>    2:   2223051476  2063016483 (-160034993)      -----    374.580   350.620 (-23.960)      ----
>    3:   2225908334  2067673847 (-158234487)      -----    375.220   350.990 (-24.230)      ----
>    4:   2225835999  2064596883 (-161239116)      -----    374.670   349.840 (-24.830)      ----
>    5:   2226005510  2061694332 (-164311178)      -----    373.512   351.120 (-22.392)      ----
>    6:   2225574949  2062657482 (-162917467)      -----    374.710   348.380 (-26.330)      -----
>    7:   2224702424  2064634122 (-160068302)      -----    373.670   349.510 (-24.160)      ----
>    8:   2226662277  2066301134 (-160361143)      -----    375.350   349.790 (-25.560)      ----
>    9:   2226761470  2063162795 (-163598675)      -----    374.260   351.290 (-22.970)      ----
>   10:   2230149089  2066203307 (-163945782)      -----    374.760   350.620 (-24.140)      ----
> ============================================================
>         2226266109  2064768307 (-161497801)      -----    374.848   350.126 (-24.722)      ----
> instr delta =   -161497801    -7.2542%
> time  delta =      -24.722 ms -6.5951%

Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:

  1. Add some comment at the beginning of a classlist.
  2. Enclose some debug statements with DEBUG_ONLY.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/364/files
  - new: https://git.openjdk.java.net/jdk/pull/364/files/dfdf12ea..dd6d440b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=364&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=364&range=06-07

  Stats: 26 lines in 2 files changed: 11 ins; 0 del; 15 mod
  Patch: https://git.openjdk.java.net/jdk/pull/364.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/364/head:pull/364

PR: https://git.openjdk.java.net/jdk/pull/364

From mchung at openjdk.java.net  Fri Oct 16 21:28:10 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Fri, 16 Oct 2020 21:28:10 GMT
Subject: RFR: 8247666: Support Lambda proxy classes in static CDS archive
 [v5]
In-Reply-To: <HCKF2Oe7zPBy-lTCDXixvDGqdNnFHixFE3nRCV0jeII=.54f90676-13db-405d-a36e-f1156a12912c@github.com>
References: <ynh4JzHY75GjEn5_oCtmRNy9HMFsU34O2PlhSwD41tU=.1a3770f9-9091-429f-8d03-31b826f9b093@github.com>
 <PX8-qxYCB8jwJw8EongFi_2-HYdOkdNGkutskSoxulg=.1a85bb57-c65f-42c7-8def-a122ee150055@github.com>
 <wuZkq-j9ciIYkjs25F7LG9-YDFaNzWysnHWQXLT-Z3s=.2f1d4107-586a-4756-bdac-21be9d60425b@github.com>
 <DGaGgn21Mpmvucd3lJUBt1LAlzFFmQnif5lm_NuTRvA=.44b63649-52c8-45b4-9d3a-f5dad40d3e4f@github.com>
 <HCKF2Oe7zPBy-lTCDXixvDGqdNnFHixFE3nRCV0jeII=.54f90676-13db-405d-a36e-f1156a12912c@github.com>
Message-ID: <CKY6aTIUZvIS35n24RmX8WnaoX-Y88JBO722rbX6ExA=.15390823-c04e-4f0f-95e1-620e9accfef0@github.com>

On Wed, 14 Oct 2020 16:24:47 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>>>  `@lambda-proxy: LambHello run ()Ljava/lang/Runnable; ()V 6 LambHello lambda$main$0 ()V ()V`
>> 
>> Can you explain the format?
>
> `@lambda-proxy LambHello run ()Ljava/lang/Runnable; ()V REF_invokeStatic LambHello lambda$main$0 ()V ()V`
> means
> `@lambda-proxy <classname> <intf-method-name> <intf-method-sig> <bsm-arg0> <bsm-arg1a> <bsm-arg1b>? <bsm-arg1c>?
> <bsm-arg1d> <bsm-arg2>`
> It is a symbolic representation of a invoke dynamic constant pool entry.
> public class LambHello {
>     public static void main(String[] args) {
>         doit(() -> {
>             System.out.println("Hello from Lambda");
>         });
>     }
>     static void doit(Runnable t) {
>         t.run();
>     }
> }
> 
> An invoke dynamic constant pool of the above program is:
> ` -   7 : InvokeDynamic : bootstrap_method_index=43 name_and_type_index=8 arguments={50, 51, 50}`
> Other constant pool entries related to the above are:
>  -   8 : NameAndType : name_index=9 signature_index=10
>  -   9 : Utf8 : 'run'
>  -  10 : Utf8 : '()Ljava/lang/Runnable;'
> 
>  -  50 : MethodType : signature_index=6
>  -  51 : MethodHandle : ref_kind=6 ref_index=52
>  -  52 : Method : klass_index=12 name_and_type_index=53
>  -  53 : NameAndType : name_index=39 signature_index=6
> 
>  -   6 : Utf8 : '()V'
>  -  12 : Class : 'LambHello' {0x0000000800c10040}
>  -  39 : Utf8 : 'lambda$main$0'
> The info included in the class list are:
>     <classname>                  = LambHello
>     <intf-method-name>     = run
>     <intf-method-sig>         = ()Ljava/lang/Runnable;
>     <bsm-arg0>                   = ()V
>     <bsm-arg1a>                  = REF_invokeStatic
>     <bsm-arg1b>                  = LambHello
>     <bsm-arg1c>                  = lambda$main$0
>     <bsm-arg1d>                  = ()V
>     <bsm-arg2>                   = ()V

Since the class list file is not intended for users to edit/modify but rather a configuration file given
when -Xshare:dump is used, the format of `@lambda-proxy` entry is internal implementation details and so it's fine.

BTW:  for the method handle reference kind, does the entry have the value (e.g. 6) or the name ("REF_invokeStatic")?
I see both formats are described in your different replies.

> @lambda-proxy: LambHello run ()Ljava/lang/Runnable; ()V 6 LambHello lambda$main$0 ()V ()V
or
> @lambda-proxy LambHello run ()Ljava/lang/Runnable; ()V REF_invokeStatic LambHello lambda$main$0 ()V ()V

-------------

PR: https://git.openjdk.java.net/jdk/pull/364

From ccheung at openjdk.java.net  Fri Oct 16 21:36:16 2020
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Fri, 16 Oct 2020 21:36:16 GMT
Subject: RFR: 8247666: Support Lambda proxy classes in static CDS archive
 [v5]
In-Reply-To: <CKY6aTIUZvIS35n24RmX8WnaoX-Y88JBO722rbX6ExA=.15390823-c04e-4f0f-95e1-620e9accfef0@github.com>
References: <ynh4JzHY75GjEn5_oCtmRNy9HMFsU34O2PlhSwD41tU=.1a3770f9-9091-429f-8d03-31b826f9b093@github.com>
 <PX8-qxYCB8jwJw8EongFi_2-HYdOkdNGkutskSoxulg=.1a85bb57-c65f-42c7-8def-a122ee150055@github.com>
 <wuZkq-j9ciIYkjs25F7LG9-YDFaNzWysnHWQXLT-Z3s=.2f1d4107-586a-4756-bdac-21be9d60425b@github.com>
 <DGaGgn21Mpmvucd3lJUBt1LAlzFFmQnif5lm_NuTRvA=.44b63649-52c8-45b4-9d3a-f5dad40d3e4f@github.com>
 <HCKF2Oe7zPBy-lTCDXixvDGqdNnFHixFE3nRCV0jeII=.54f90676-13db-405d-a36e-f1156a12912c@github.com>
 <CKY6aTIUZvIS35n24RmX8WnaoX-Y88JBO722rbX6ExA=.15390823-c04e-4f0f-95e1-620e9accfef0@github.com>
Message-ID: <bFP3z-Z1IJC2Z0eUX6u3grYp-9LwQ7JwbLKCrDA2OR0=.3fa6884f-501e-4b22-a658-343ac6845580@github.com>

On Fri, 16 Oct 2020 21:25:04 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> `@lambda-proxy LambHello run ()Ljava/lang/Runnable; ()V REF_invokeStatic LambHello lambda$main$0 ()V ()V`
>> means
>> `@lambda-proxy <classname> <intf-method-name> <intf-method-sig> <bsm-arg0> <bsm-arg1a> <bsm-arg1b>? <bsm-arg1c>?
>> <bsm-arg1d> <bsm-arg2>`
>> It is a symbolic representation of a invoke dynamic constant pool entry.
>> public class LambHello {
>>     public static void main(String[] args) {
>>         doit(() -> {
>>             System.out.println("Hello from Lambda");
>>         });
>>     }
>>     static void doit(Runnable t) {
>>         t.run();
>>     }
>> }
>> 
>> An invoke dynamic constant pool of the above program is:
>> ` -   7 : InvokeDynamic : bootstrap_method_index=43 name_and_type_index=8 arguments={50, 51, 50}`
>> Other constant pool entries related to the above are:
>>  -   8 : NameAndType : name_index=9 signature_index=10
>>  -   9 : Utf8 : 'run'
>>  -  10 : Utf8 : '()Ljava/lang/Runnable;'
>> 
>>  -  50 : MethodType : signature_index=6
>>  -  51 : MethodHandle : ref_kind=6 ref_index=52
>>  -  52 : Method : klass_index=12 name_and_type_index=53
>>  -  53 : NameAndType : name_index=39 signature_index=6
>> 
>>  -   6 : Utf8 : '()V'
>>  -  12 : Class : 'LambHello' {0x0000000800c10040}
>>  -  39 : Utf8 : 'lambda$main$0'
>> The info included in the class list are:
>>     <classname>                  = LambHello
>>     <intf-method-name>     = run
>>     <intf-method-sig>         = ()Ljava/lang/Runnable;
>>     <bsm-arg0>                   = ()V
>>     <bsm-arg1a>                  = REF_invokeStatic
>>     <bsm-arg1b>                  = LambHello
>>     <bsm-arg1c>                  = lambda$main$0
>>     <bsm-arg1d>                  = ()V
>>     <bsm-arg2>                   = ()V
>
> Since the class list file is not intended for users to edit/modify but rather a configuration file given
> when -Xshare:dump is used, the format of `@lambda-proxy` entry is internal implementation details and so it's fine.
> BTW:  for the method handle reference kind, does the entry have the value (e.g. 6) or the name ("REF_invokeStatic")?
> I see both formats are described in your different replies.
>> @lambda-proxy: LambHello run ()Ljava/lang/Runnable; ()V 6 LambHello lambda$main$0 ()V ()V
> or
>> @lambda-proxy LambHello run ()Ljava/lang/Runnable; ()V REF_invokeStatic LambHello lambda$main$0 ()V ()V

For the reference kind, the first format (with number '6') will be stored in the classlist.

-------------

PR: https://git.openjdk.java.net/jdk/pull/364

From kcr at openjdk.java.net  Fri Oct 16 22:15:11 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 16 Oct 2020 22:15:11 GMT
Subject: RFR: JDK-8254843: Exception launching app on windows in some cases
In-Reply-To: <TPcZJguZshLTz6DP1TeLYnmI7d2lMrI89UBYXOF0How=.91e29d6f-1b4e-4f5d-bb4d-345d7be2866f@github.com>
References: <TPcZJguZshLTz6DP1TeLYnmI7d2lMrI89UBYXOF0How=.91e29d6f-1b4e-4f5d-bb4d-345d7be2866f@github.com>
Message-ID: <XH1lBmX2B-oCD2chiSVJzq3uRJ8rg6bMzyGTbQ3UlVs=.5f55f545-33c1-4205-a0f7-4bf971ee1daa@github.com>

On Fri, 16 Oct 2020 17:59:14 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> JDK-8254843: Exception launching app on windows in some cases
> loading splashscreen.dll in WinLaunchercpp would load java.dll from path instead of runtime/bin causing jni launcher to
> crash. instead we just use what used to be the fallback, using loadDllWithAddDllDirectory().

Looks good. I verified that it fixes the problem.

-------------

Marked as reviewed by kcr (Author).

PR: https://git.openjdk.java.net/jdk/pull/706

From almatvee at openjdk.java.net  Fri Oct 16 23:34:22 2020
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Fri, 16 Oct 2020 23:34:22 GMT
Subject: RFR: JDK-8254843: Exception launching app on windows in some cases
In-Reply-To: <TPcZJguZshLTz6DP1TeLYnmI7d2lMrI89UBYXOF0How=.91e29d6f-1b4e-4f5d-bb4d-345d7be2866f@github.com>
References: <TPcZJguZshLTz6DP1TeLYnmI7d2lMrI89UBYXOF0How=.91e29d6f-1b4e-4f5d-bb4d-345d7be2866f@github.com>
Message-ID: <-B1DmsWgtBbw38skdUnJcqtls4ToSNz5mTUmwjf32Xo=.9b2ef88f-fa26-4a85-8243-8141108ec447@github.com>

On Fri, 16 Oct 2020 17:59:14 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> JDK-8254843: Exception launching app on windows in some cases
> loading splashscreen.dll in WinLaunchercpp would load java.dll from path instead of runtime/bin causing jni launcher to
> crash. instead we just use what used to be the fallback, using loadDllWithAddDllDirectory().

Marked as reviewed by almatvee (Committer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/706

From bpb at openjdk.java.net  Sat Oct 17 00:20:10 2020
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Sat, 17 Oct 2020 00:20:10 GMT
Subject: RFR: 8238669: Long.divideUnsigned is extremely slow for certain
 values (Needs to be Intrinsic) [v2]
In-Reply-To: <meO7jZ6tlDQdl-mBRW52wdsS1OzS2poucMTrRuu0TZI=.ace180df-9094-4602-b8c8-9975816229ad@github.com>
References: <qTrgS9EALforkeYHdp592LnIrSJbqVAuv9Flfg3fbaU=.81db05a0-5847-4bfe-94ae-f4fcb922f4bc@github.com>
 <1afMfHAUJEnM5nUkl-LbkSxjYOZwjKgWu2NDIfhbc5U=.bbeab3f9-1278-4103-b5b3-dd9a2ae745a8@github.com>
 <sqDr0vszrj6-PWBC8Oo9kTu4r72yLJwkWjly0yH3I1E=.1409e303-a261-4df5-9f58-b2945843f870@github.com>
 <NnKxMnr2bpd4fh6bj44aF-CNjRVYFvH7JvvbPbGs26E=.a2a1f5db-777b-435e-9f18-9b198c4a2d38@github.com>
 <_0eIOqisk_pEhQy1ekXy-I2-YxtB9Vs-4kjLrzBevKk=.dbe46c8a-d0f4-4919-87ec-7fa1ab74b8ce@github.com>
 <meO7jZ6tlDQdl-mBRW52wdsS1OzS2poucMTrRuu0TZI=.ace180df-9094-4602-b8c8-9975816229ad@github.com>
Message-ID: <2VxJg6afuoPHO_LhlG3bImwC-F5WDAj2ZUArlGR8JeM=.4e782633-36de-40dc-ac27-7ff85f2b3325@github.com>

On Wed, 14 Oct 2020 14:20:11 GMT, Raffaello Giulietti <github.com+70726043+rgiulietti at openjdk.org> wrote:

>> Hello
>> 
>> this is a gentle reminder that this issue still needs a more formal review.
>> 
>> Greetings
>> Raffaello
>
> Hello,
> 
> a reminder that this issue has not been formally reviewed.
> Estimated time: 10-15 min with "Hacker's delight" on the desk.
> 
> Greetings
> Raffaello

I think the change looks good.

Before the project was on GitHub, there was a change to the test posted in
http://mail.openjdk.java.net/pipermail/core-libs-dev/2020-September/068504.html to address the comment in
http://mail.openjdk.java.net/pipermail/core-libs-dev/2020-September/068484.html. I think the test is all right but
perhaps someone else still has a comment. The copyright year in any case needs to be adjusted.

-------------

PR: https://git.openjdk.java.net/jdk/pull/31

From github.com+1290376+johnlinp at openjdk.java.net  Sat Oct 17 02:43:10 2020
From: github.com+1290376+johnlinp at openjdk.java.net (John Lin)
Date: Sat, 17 Oct 2020 02:43:10 GMT
Subject: RFR: 8247402: rewrite the implementation requirements for
 Map::compute()
In-Reply-To: <aVTmU-nFmLJv_zrgi7hlwc3fezw3CThbEAq5ojWpf24=.460a1329-87aa-4a2c-ad44-6747323137de@github.com>
References: <as4mWIy4TmbEz5C238FHXEL6-gynMYyxaQLQqGV_wVM=.6bac3533-5459-4ad7-8d45-c00e3bfdd121@github.com>
 <9yJU0Hcx60tzcdSIs7KWSVAOvOgaspFWabjMNTbE5cY=.f8815878-be89-44d6-8e70-b5aaec81fe92@github.com>
 <St57JlJqipoW5XTGdXzWE6Wz46DXovkvqdyxFbbLTI8=.2170e54d-a40c-45e9-b9e0-343c8f842c31@github.com>
 <aVTmU-nFmLJv_zrgi7hlwc3fezw3CThbEAq5ojWpf24=.460a1329-87aa-4a2c-ad44-6747323137de@github.com>
Message-ID: <twEVRCFpnjxarBxq4nP8i1hx0wiwaLS9iu1cM_ARd88=.69028791-c1eb-486e-972c-e90f9294a56a@github.com>

On Tue, 13 Oct 2020 16:17:49 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> Perhaps I should clarify my previous comment. When I said "implementation" what I meant was that pseudo-code inside the
>> `@implSpec` tag, not the actual body of `default V compute(K key, BiFunction<? super K, ? super V, ? extends V>
>> remappingFunction)`.
>
> This change is to a normative portion of the specification, and as such will require a CSR.

Hi @pavelrappo & @stuart-marks,

Thank you for the review. When I first proposed this patch in the mailing list, the patch looked like this:

# HG changeset patch
# User John Lin <johnl... at gmail.com>
# Date 1591923561 -28800
#      Fri Jun 12 08:59:21 2020 +0800
# Node ID 03c9b5c9e632a0d6e33a1f13c98bb3b31b1bf659
# Parent  49a68abdb0ba68351db0f140ddac793b1c391bd5
8247402: Rewrite the implementation requirements for Map::compute()

diff --git a/src/java.base/share/classes/java/util/Map.java
b/src/java.base/share/classes/java/util/Map.java
--- a/src/java.base/share/classes/java/util/Map.java
+++ b/src/java.base/share/classes/java/util/Map.java
@@ -1113,17 +1113,12 @@ public interface Map<K, V> {
      * <pre> {@code
      * V oldValue = map.get(key);
      * V newValue = remappingFunction.apply(key, oldValue);
-     * if (oldValue != null) {
-     *    if (newValue != null)
-     *       map.put(key, newValue);
-     *    else
-     *       map.remove(key);
-     * } else {
-     *    if (newValue != null)
-     *       map.put(key, newValue);
-     *    else
-     *       return null;
+     * if (newValue != null) {
+     *     map.put(key, newValue);
+     * } else if (oldValue != null) {
+     *     map.remove(key);
      * }
+     * return newValue;
      * }</pre>
      *
      * <p>The default implementation makes no guarantees about detecting if the

which didn't change the pseudo-code implementation.

However, Martin Buchholz reviewed my patch and suggested me to modify it to match the real implementation in HashMap:
https://www.mail-archive.com/core-libs-dev at openjdk.java.net/msg66197.html
https://www.mail-archive.com/core-libs-dev at openjdk.java.net/msg66199.html
https://www.mail-archive.com/core-libs-dev at openjdk.java.net/msg66210.html
Therefore, I modified my patch and submitted it in the original mailing list and in this PR.

I don't think creating a CSR is in the scope of JDK-8247402. I'll create another PR with my original patch. Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/451

From github.com+1290376+johnlinp at openjdk.java.net  Sat Oct 17 02:54:11 2020
From: github.com+1290376+johnlinp at openjdk.java.net (John Lin)
Date: Sat, 17 Oct 2020 02:54:11 GMT
Subject: RFR: 8247402: rewrite the implementation requirements for
 Map::compute()
In-Reply-To: <twEVRCFpnjxarBxq4nP8i1hx0wiwaLS9iu1cM_ARd88=.69028791-c1eb-486e-972c-e90f9294a56a@github.com>
References: <as4mWIy4TmbEz5C238FHXEL6-gynMYyxaQLQqGV_wVM=.6bac3533-5459-4ad7-8d45-c00e3bfdd121@github.com>
 <9yJU0Hcx60tzcdSIs7KWSVAOvOgaspFWabjMNTbE5cY=.f8815878-be89-44d6-8e70-b5aaec81fe92@github.com>
 <St57JlJqipoW5XTGdXzWE6Wz46DXovkvqdyxFbbLTI8=.2170e54d-a40c-45e9-b9e0-343c8f842c31@github.com>
 <aVTmU-nFmLJv_zrgi7hlwc3fezw3CThbEAq5ojWpf24=.460a1329-87aa-4a2c-ad44-6747323137de@github.com>
 <twEVRCFpnjxarBxq4nP8i1hx0wiwaLS9iu1cM_ARd88=.69028791-c1eb-486e-972c-e90f9294a56a@github.com>
Message-ID: <3bwp0VGx8SeawIWWlXlzg8M1L5GPF_99TU1x7w6AOGA=.6b97fae1-bd5c-4552-86d5-b3cd7392af90@github.com>

On Sat, 17 Oct 2020 02:40:35 GMT, John Lin <github.com+1290376+johnlinp at openjdk.org> wrote:

>> This change is to a normative portion of the specification, and as such will require a CSR.
>
> Hi @pavelrappo & @stuart-marks,
> 
> Thank you for the review. When I first proposed this patch in the mailing list, the patch looked like this:
> 
> # HG changeset patch
> # User John Lin <johnl... at gmail.com>
> # Date 1591923561 -28800
> #      Fri Jun 12 08:59:21 2020 +0800
> # Node ID 03c9b5c9e632a0d6e33a1f13c98bb3b31b1bf659
> # Parent  49a68abdb0ba68351db0f140ddac793b1c391bd5
> 8247402: Rewrite the implementation requirements for Map::compute()
> 
> diff --git a/src/java.base/share/classes/java/util/Map.java
> b/src/java.base/share/classes/java/util/Map.java
> --- a/src/java.base/share/classes/java/util/Map.java
> +++ b/src/java.base/share/classes/java/util/Map.java
> @@ -1113,17 +1113,12 @@ public interface Map<K, V> {
>       * <pre> {@code
>       * V oldValue = map.get(key);
>       * V newValue = remappingFunction.apply(key, oldValue);
> -     * if (oldValue != null) {
> -     *    if (newValue != null)
> -     *       map.put(key, newValue);
> -     *    else
> -     *       map.remove(key);
> -     * } else {
> -     *    if (newValue != null)
> -     *       map.put(key, newValue);
> -     *    else
> -     *       return null;
> +     * if (newValue != null) {
> +     *     map.put(key, newValue);
> +     * } else if (oldValue != null) {
> +     *     map.remove(key);
>       * }
> +     * return newValue;
>       * }</pre>
>       *
>       * <p>The default implementation makes no guarantees about detecting if the
> 
> which didn't change the pseudo-code implementation.
> 
> However, Martin Buchholz reviewed my patch and suggested me to modify it to match the real implementation in HashMap:
> https://www.mail-archive.com/core-libs-dev at openjdk.java.net/msg66197.html
> https://www.mail-archive.com/core-libs-dev at openjdk.java.net/msg66199.html
> https://www.mail-archive.com/core-libs-dev at openjdk.java.net/msg66210.html
> Therefore, I modified my patch and submitted it in the original mailing list and in this PR.
> 
> I don't think creating a CSR is in the scope of JDK-8247402. I'll create another PR with my original patch. Thanks.

I've created https://github.com/openjdk/jdk/pull/714.

-------------

PR: https://git.openjdk.java.net/jdk/pull/451

From github.com+1290376+johnlinp at openjdk.java.net  Sat Oct 17 03:04:14 2020
From: github.com+1290376+johnlinp at openjdk.java.net (John Lin)
Date: Sat, 17 Oct 2020 03:04:14 GMT
Subject: RFR: 8247402: Documentation for Map::compute contains confusing
 implementation requirements
Message-ID: <ZQNheDIQUwvUufEkds2N7kkr0kV6No0Cc9qIzX_FY04=.6624b5ff-dad7-4fd1-8677-51da85a5b149@github.com>

This is from the mailing list: http://mail.openjdk.java.net/pipermail/core-libs-dev/2020-June/067190.html

---------
### Progress
- [x] Change must not contain extraneous whitespace
- [x] Commit message must refer to an issue
- [ ] Change must be properly reviewed

### Testing

|     | Linux x64 | Windows x64 | macOS x64 |
| --- | ----- | ----- | ----- |
| Build | ? (3/5 running) | ? (2/2 running) | ? (2/2 running) |



### Download
`$ git fetch https://git.openjdk.java.net/jdk pull/714/head:pull/714`
`$ git checkout pull/714`

-------------

Commit messages:
 - 8247402: Documentation for Map::compute contains confusing implementation requirements

Changes: https://git.openjdk.java.net/jdk/pull/714/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=714&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8247402
  Stats: 11 lines in 1 file changed: 1 ins; 6 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/714.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/714/head:pull/714

PR: https://git.openjdk.java.net/jdk/pull/714

From vsharma at openjdk.java.net  Sat Oct 17 07:29:14 2020
From: vsharma at openjdk.java.net (Vipin Sharma)
Date: Sat, 17 Oct 2020 07:29:14 GMT
Subject: RFR: JDK-8253936 Replace <code>...</code> with {@code ...} for
 java.sql
In-Reply-To: <zr8HOhlJbmboYIC-rVP0S3Mj5FeXOI4lzlUXvL2XMoc=.f173b3a1-f879-458c-9450-c432cecb6d6f@github.com>
References: <zr8HOhlJbmboYIC-rVP0S3Mj5FeXOI4lzlUXvL2XMoc=.f173b3a1-f879-458c-9450-c432cecb6d6f@github.com>
Message-ID: <vuqlGOgmlX7utAXo6gmGP3_zGLMfmImnDsebenMSIGk=.568d669a-a3da-40d1-9f10-28079c4a861d@github.com>

On Fri, 16 Oct 2020 19:38:45 GMT, Vipin Sharma <vsharma at openjdk.org> wrote:

> <code>...</code> is replaced with {@code ...} in java.sql classes.
> Please review and sponsor this change.

Hi @LanceAndersen,

I have generated javadoc before and after change. Following are 3 differences showing side by side comparison here.

DriverManager.java - line 417 (Change: CODE replaced with code)
<CODE>d.getClass().getName()</CODE></div>		      |	 <code>d.getClass().getName()</code></div>

ResultSet.java - line 3085 (Change: CODE replaced with code)
the result set concurrency is <CODE>CONCUR_READ_ONLY</code>  |	 the result set concurrency is
<code>CONCUR_READ_ONLY</code>

SQLClientInfoException.java - line 60 (Change: removed space before null)
 <code> null</code> and the vendor code is initialized to 0.  |	 <code>null</code> and the vendor code is initialized to
 0.
 
All the above three changes doesn't change the effective view.

-------------

PR: https://git.openjdk.java.net/jdk/pull/707

From herrick at openjdk.java.net  Sat Oct 17 14:08:16 2020
From: herrick at openjdk.java.net (Andy Herrick)
Date: Sat, 17 Oct 2020 14:08:16 GMT
Subject: RFR: JDK-8254783: jpackage fails on Windows when application name
 differs =?UTF-8?B?4oCm?=
Message-ID: <r6qCtHMkiKtZiotu5BHVP84rqeUL_5mkVyFlBeCqC7A=.45656321-6f24-4fa1-b82d-2c9797c511cf@github.com>

?from installer name
JDK-8254783: jpackage fails on Windows when application name differs from installer name
When using --app-image, to create MSI installer, use the application name from AppImageData instead of the Msi
installer name if possible.

-------------

Commit messages:
 - JDK-8254783: jpackage fails on Windows when application name differs from installer name

Changes: https://git.openjdk.java.net/jdk/pull/720/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=720&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8254783
  Stats: 8 lines in 1 file changed: 7 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/720.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/720/head:pull/720

PR: https://git.openjdk.java.net/jdk/pull/720

From rrich at openjdk.java.net  Sun Oct 18 06:20:25 2020
From: rrich at openjdk.java.net (Richard Reingruber)
Date: Sun, 18 Oct 2020 06:20:25 GMT
Subject: RFR: 8227745: Enable Escape Analysis for Better Performance in
 the Presence of JVMTI Agents [v12]
In-Reply-To: <Ll2RereRbuQLgFtIjv9pS92kPvCVuo-BI0cP1zGjVbo=.dad3a33c-0fc3-44fd-810a-f01448cf564c@github.com>
References: <Ll2RereRbuQLgFtIjv9pS92kPvCVuo-BI0cP1zGjVbo=.dad3a33c-0fc3-44fd-810a-f01448cf564c@github.com>
Message-ID: <h2QplRcNfrPR2VWYOCSPboou9DhkNYu0mM0NetQelMg=.03b1e205-cdef-4c0f-b419-c9552866027f@github.com>

> Hi,
> 
> this is the continuation of the review of the implementation for:
> 
> https://bugs.openjdk.java.net/browse/JDK-8227745
> https://bugs.openjdk.java.net/browse/JDK-8233915
> 
> It allows for JIT optimizations based on escape analysis even if JVMTI agents acquire capabilities to access references
> to objects that are subject to such optimizations, e.g. scalar replacement. The implementation reverts such
> optimizations just before access very much as when switching from JIT compiled execution to the interpreter, aka
> "deoptimization".  Webrev.8 was the last one before before the transition to Git/Github:
> 
> http://cr.openjdk.java.net/~rrich/webrevs/8227745/webrev.8/
> 
> Thanks, Richard.

Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision:

  handle_special_runtime_exit_condition(): wait (blocked) for obj. deoptimization _before_ async ex. check.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/119/files
  - new: https://git.openjdk.java.net/jdk/pull/119/files/f02f07b6..272fb025

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=119&range=11
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=119&range=10-11

  Stats: 10 lines in 1 file changed: 5 ins; 5 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/119.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/119/head:pull/119

PR: https://git.openjdk.java.net/jdk/pull/119

From plevart at openjdk.java.net  Sun Oct 18 15:12:13 2020
From: plevart at openjdk.java.net (Peter Levart)
Date: Sun, 18 Oct 2020 15:12:13 GMT
Subject: RFR: 8159746: (proxy) Support for default methods
In-Reply-To: <Gn33ydZNxqOpWUrmYiWJadMF0mukI2MR85EtgrV4D1I=.958521f2-1167-4a68-b513-e10bba37ae18@github.com>
References: <kw2VXh3vTFf1zgfd4biXA41OKffZ5oU7KT23tXAxgUA=.bcf14ffc-4dba-4c9c-8754-184172c5acbd@github.com>
 <U-6RiCpFVIrhLztPN6opiPcpFtxValDzU-K7WWFZM-4=.6bc8aaa4-636a-4664-b380-4c4af00513bd@github.com>
 <-cLIJ8pFHtnNoJMHV3aXI7XMJWp4Jrutc8Xn5PG0OK8=.d2cd87ab-3592-4524-ad85-05444c43689b@github.com>
 <r0UK2qjnmgeTNDDSWaSLPAj3QRgx_4YB82ielllO7jM=.fa615bc0-db49-4a74-b842-793f8f5209bb@github.com>
 <1T8kXDZN1bhHr4c8v4SQsImeBySCqTfX-u3_jzvyocA=.b4957400-9a33-4b6e-8475-329642a5888c@github.com>
 <XIux-dY0JXHRafHk48kVNXId9r-HSceNSytBojDxelY=.872e74cb-b064-406e-b71f-13c90ec7fbbc@github.com>
 <j4t2vT0SnwnU7lhKRlXtk967d-K6nA0EqHrqNbba7W0=.dc05dba6-bf7e-4606-8a02-9c2bad4b3b58@github.com>
 <fmVtPcBdgMuZOPm2qx3Q3znVZM7JgQPkhPAVLtwkOhE=.2d8b8447-cfae-4cb3-9a7c-6567a881231f@github.com>
 <GSeWP29fAIUFSk0CYsC557w52CuLqeUWwHNK9maltwI=.3d5f002e-6b74-4a57-a5d8-244d27da9dde@github.com>
 <GF8iEOkMUEL2dYB0HytFIc9gyeeUJ_KP0ImlqFsul2Y=.894afc05-9310-43e1-a308-8f7d71dc572b@github.com>
 <HvtDex3cmiv7XeTMITOroYfu74amSGQavQ_
 BAmVzmXw=.223be989-7c20-4ba4-ac0d-013d2b75a8cb@github.com>
 <IqRiLphFPBpGiKAnMJXqxjie9YeZ03rcE-qG1s92BLw=.d4fd5e92-5067-40df-8a0b-1dfd3d6e23af@github.com>
 <Y0hE51G3YefI6NY1O_E6VoZSKwxE78S1hv6fEatmOG8=.0a2c686c-d9ad-418c-8c1b-49addb8a54b1@github.com>
 <QrNk57L2PWQhJjzYiGTsvYyGIPAfK7bP_kANtTR-2uM=.3e5ce990-f8ea-4751-8147-27a8a9dad40d@github.com>
 <9JNNUzfV3PSvKtSg2a_zyYJmgEn3sZL9cb5sfqemk2o=.f1ef7fb7-bdd5-44ed-98c8-59213e9094f9@github.com>
 <zWGhaC8YB5I0XgffiR7o_YT5gSp9Gbj8Drtt23brl-c=.1e59f0e4-bbe3-4fb2-94dc-c55fc862f091@github.com>
 <LljojgqBhEi6tFptsbmu1jS-Xx7lYEXm9tRkkPqDGzE=.3d7d6a37-1042-4539-88d1-9f4cf5378128@github.com>
 <Gn33ydZNxqOpWUrmYiWJadMF0mukI2MR85EtgrV4D1I=.958521f2-1167-4a68-b513-e10bba37ae18@github.com>
Message-ID: <NMXKaHql9XjndqPgyoN1Lasa9H8ugl8-ltD1j2XiT9Y=.3ff8871e-0f9d-40ea-8f35-e804a9afcbd5@github.com>

On Fri, 16 Oct 2020 18:13:08 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Hi Mandy,
>> 
>> I read your concerns and have an alternative API proposition here. Instread of an abstract class with protected final
>> `invokeDefaultMethod` method, we can keep the public static `invokeDefaultMethod` and add a `Lookup` parameter to it.
>> The Lookup instance to be passed to the method should be able to `findSpecial` the default method - it has to be the
>> full privilege lookup with proxy class as lookup class. Such instance is provided in a call to the alternative
>> invocation handler: `InvocationHandlerWithLookup` which is a super-interface of plain `InvocationHandler` that just
>> forwards the invocation with the additional Lookup parameter to the abstract method without parameter (in order to keep
>> backwards-compatibility). The generated proxy class invokes this new method in new interface and passes its own lookup
>> to it. There's also an overloaded Proxy::newProxyInstance method that takes this new InvocationHandlerWithLookup
>> parameter instead of plain InvocationHandler. This allows specifying lambdas for both overloaded methods and the right
>> one is selected according to the number of lambda parameters. invoking the constructor of the proxy class taking plain
>> InvocationHandler is still allowed but only if the handler class does not use the Lookup parameter. The overloaded
>> Proxy.newProxyInstance throws IllegalAccessException in case the passed-in handler uses the provided lookup but some
>> interfaces of the proxy are not accessible.  Performance with this implementation is restored and is not worse when
>> dealing with inaccessible interfaces:  Mandy's original:  Benchmark             Mode  Cnt    Score    Error  Units
>> ProxyBench.implClass  avgt    5    3.709 ?  0.026  ns/op ProxyBench.implProxy  avgt    5  926.215 ? 11.835  ns/op
>> Peter's performance patch:  Benchmark             Mode  Cnt   Score   Error  Units ProxyBench.implClass  avgt    5
>> 3.777 ? 0.005  ns/op ProxyBench.implProxy  avgt    5  27.579 ? 0.250  ns/op
>> 
>> Moved to InvocationHandler + added access check
>> 
>> Benchmark               Mode  Cnt    Score   Error  Units
>> ProxyBench.implClass    avgt    5    3.740 ? 0.004  ns/op
>> ProxyBench.implProxy    avgt    5   34.226 ? 0.125  ns/op
>> ProxyBench.ppImplClass  avgt    5    3.780 ? 0.004  ns/op
>> ProxyBench.ppImplProxy  avgt    5  147.318 ? 1.422  ns/op
>> 
>> 
>> Alternative API with access check in newProxyInstance
>> 
>> Benchmark               Mode  Cnt   Score   Error  Units
>> ProxyBench.implClass    avgt    5   3.782 ? 0.013  ns/op
>> ProxyBench.implProxy    avgt    5  32.493 ? 0.192  ns/op
>> ProxyBench.ppImplClass  avgt    5   3.749 ? 0.002  ns/op
>> ProxyBench.ppImplProxy  avgt    5  30.565 ? 0.190  ns/op
>> 
>> The code is in this pull request against your last commit in your branch: https://github.com/mlchung/jdk/pull/2
>
> Hi Peter,
> 
> This seems an attracting idea to keep the possibility of using lambdas.  However, the full privileged lookup of the
> proxy class will be leaked to `InvocationHandlerWithLookup` implementation which imposes security concerns.   This
> full-privileged lookup has access to other proxy classes in that module including private members that we don't want to
> hand out to user code.  Other than this security concern, we will also need to consider the inconsistency having
> `java.lang.reflect` API to reference `Lookup`.

Hi Mandy,

You're right. I haven't thought of what one can do with a Lookup for one proxy class when other proxy classes are
co-located in the same module and/or package. So instead of a Lookup, we could use some other more targeted
"capability". Here's alternative API no.2 that uses special SuperInvoker callback interface passed as argument to
invocation handler:

https://github.com/mlchung/jdk/pull/4

Each proxy class has its own SuperInvoker instance, assigned to static final field of generated proxy class like Method
objects, which is passed to invocation handler in the same way as the selected Method object. Invocation handler can
use this SuperInvoker instance to invoke the super default method on the proxy. SuperInvoker can verify that the
passed-in proxy is of the correct class very quickly. Also the cache of transformed method handles per Method is
embedded in the SuperInvoker itself instead of using ClassValue to hold it, so overhead for super invocations is
further reduced:

Mandy's original:

Benchmark             Mode  Cnt    Score    Error  Units
ProxyBench.implClass  avgt    5    3.709 ?  0.026  ns/op
ProxyBench.implProxy  avgt    5  926.215 ? 11.835  ns/op


Peter's performance patch:

Benchmark             Mode  Cnt   Score   Error  Units
ProxyBench.implClass  avgt    5   3.777 ? 0.005  ns/op
ProxyBench.implProxy  avgt    5  27.579 ? 0.250  ns/op


Static method moved to InvocationHandler + added access check

Benchmark               Mode  Cnt    Score   Error  Units
ProxyBench.implClass    avgt    5    3.740 ? 0.004  ns/op
ProxyBench.implProxy    avgt    5   34.226 ? 0.125  ns/op
ProxyBench.ppImplClass  avgt    5    3.780 ? 0.004  ns/op
ProxyBench.ppImplProxy  avgt    5  147.318 ? 1.422  ns/op


Alternative API #1 with access check in newProxyInstance and Lookup parameter

Benchmark               Mode  Cnt   Score   Error  Units
ProxyBench.implClass    avgt    5   3.782 ? 0.013  ns/op
ProxyBench.implProxy    avgt    5  32.493 ? 0.192  ns/op
ProxyBench.ppImplClass  avgt    5   3.749 ? 0.002  ns/op
ProxyBench.ppImplProxy  avgt    5  30.565 ? 0.190  ns/op


Alternative API #2 with SuperInvoker parameter

Benchmark               Mode  Cnt   Score   Error  Units
ProxyBench.implClass    avgt    5   3.777 ? 0.003  ns/op
ProxyBench.implProxy    avgt    5  20.282 ? 0.585  ns/op
ProxyBench.ppImplClass  avgt    5   3.752 ? 0.002  ns/op
ProxyBench.ppImplProxy  avgt    5  19.790 ? 0.335  ns/op

So what do you think about this one?

-------------

PR: https://git.openjdk.java.net/jdk/pull/313

From vromero at openjdk.java.net  Sun Oct 18 16:12:22 2020
From: vromero at openjdk.java.net (Vicente Romero)
Date: Sun, 18 Oct 2020 16:12:22 GMT
Subject: RFR: 8246774: implement Record Classes as a standard feature in
 Java [v12]
In-Reply-To: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com>
References: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com>
Message-ID: <f4a_JbJpqstQAtwzj6YXaMZwsW4d9caVILKF5kR-E9M=.fb122a82-559b-4a15-814e-462de2ca95c8@github.com>

> 8246774: implement Record Classes as a standard feature in Java

Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The pull request now
contains 10 commits:

 - Merge branch 'master' into JDK-8246774
 - Merge branch 'master' into JDK-8246774
 - removing unused jcod file
 - remove unnecessary jtreg tags from tests, remove othervm etc when applicable
 - adding missing changes to some tests
 - modifiying @since from 14 to 16
 - Remove preview args from ObjectMethodsTest
 - Remove preview args from record serialization tests
 - removing the javax.lang.model related code to be moved to a separate bug
 - 8246774: Record Classes (final) implementation
   
   Co-authored-by: Vicente Romero <vicente.romero at oracle.com>
   Co-authored-by: Harold Seigel <harold.seigel at oracle.com>
   Co-authored-by: Jonathan Gibbons <jonathan.gibbons at oracle.com>
   Co-authored-by: Brian Goetz <brian.goetz at oracle.com>
   Co-authored-by: Maurizio Cimadamore <maurizio.cimadamore at oracle.com>
   Co-authored-by: Joe Darcy <joe.darcy at oracle.com>
   Co-authored-by: Chris Hegarty <chris.hegarty at oracle.com>
   Co-authored-by: Jan Lahoda <jan.lahoda at oracle.com>

-------------

Changes: https://git.openjdk.java.net/jdk/pull/290/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=290&range=11
  Stats: 856 lines in 109 files changed: 72 ins; 562 del; 222 mod
  Patch: https://git.openjdk.java.net/jdk/pull/290.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/290/head:pull/290

PR: https://git.openjdk.java.net/jdk/pull/290

From vromero at openjdk.java.net  Sun Oct 18 16:40:31 2020
From: vromero at openjdk.java.net (Vicente Romero)
Date: Sun, 18 Oct 2020 16:40:31 GMT
Subject: RFR: 8246774: implement Record Classes as a standard feature in
 Java [v13]
In-Reply-To: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com>
References: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com>
Message-ID: <ziM4fiznFt6zP51v2rI-2bXSj70Y9VMDsgtFY4-x4MA=.912a955e-92c2-40b2-8045-82e0aa1d7b01@github.com>

> 8246774: implement Record Classes as a standard feature in Java

Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:

  removing reference to unused jcod file from test

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/290/files
  - new: https://git.openjdk.java.net/jdk/pull/290/files/5bfbde59..3e472bc3

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=290&range=12
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=290&range=11-12

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/290.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/290/head:pull/290

PR: https://git.openjdk.java.net/jdk/pull/290

From vromero at openjdk.java.net  Sun Oct 18 18:58:16 2020
From: vromero at openjdk.java.net (Vicente Romero)
Date: Sun, 18 Oct 2020 18:58:16 GMT
Subject: Integrated: 8246774: implement Record Classes as a standard feature
 in Java
In-Reply-To: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com>
References: <48S0UHUnWOQmJO6ErAIDgerNxM4Ibm9anIDZAdcKBp0=.32180f4d-1096-4645-8b23-54aa9f0300fb@github.com>
Message-ID: <PVO_dtYeXlyWyJkmGjmrDRoYtVNXEQTH6AhZ2Xo6J9M=.8f20037c-e4e6-408f-a916-518313626de4@github.com>

On Mon, 21 Sep 2020 21:30:51 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> 8246774: implement Record Classes as a standard feature in Java

This pull request has now been integrated.

Changeset: c17d5851
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c17d5851
Stats:     856 lines in 109 files changed: 72 ins; 562 del; 222 mod

8246774: implement Record Classes as a standard feature in Java

Co-authored-by: Vicente Romero <vromero at openjdk.org>
Co-authored-by: Harold Seigel <hseigel at openjdk.org>
Co-authored-by: Chris Hegarty <chegar at openjdk.org>
Reviewed-by: coleenp, jlahoda, sspitsyn, chegar

-------------

PR: https://git.openjdk.java.net/jdk/pull/290

From david.holmes at oracle.com  Sun Oct 18 21:36:41 2020
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 19 Oct 2020 07:36:41 +1000
Subject: RFR: 8188055: (ref) Add Reference::refersTo predicate [v5]
In-Reply-To: <VZRnbCYjfDq8Bo94vjB9jJKt4_tDFelcEHNiOB4VHuM=.023edb69-a402-44c9-904c-bda9a8349263@github.com>
References: <D4HSg8FT20Eaxk5KJkkw0GgETSxRkBn1ipS3Dt0kPto=.e4bab078-2e04-4413-90cb-9bfafb2a6831@github.com>
 <FHx-oBhE254DZWHhg2RTKjZn_-yYN5xadTW7GXhTxzM=.7e6a46fa-5259-428c-b725-81b4fe48b8f7@github.com>
 <3L0hT4NZvzC8V2D7WfDFdv1T7FRdTPMPOWWGnHoKxB0=.3f962415-7d0d-40ae-b5ed-a0a1f9da11be@github.com>
 <VZRnbCYjfDq8Bo94vjB9jJKt4_tDFelcEHNiOB4VHuM=.023edb69-a402-44c9-904c-bda9a8349263@github.com>
Message-ID: <5f8f5c3c-6c1a-a426-b2d4-df94885e76cc@oracle.com>

On 17/10/2020 1:23 am, Kim Barrett wrote:
> On Fri, 16 Oct 2020 05:41:17 GMT, David Holmes <dholmes at openjdk.org> wrote:
> 
>>> Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev
>>> excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since
>>> the last revision:
>>>   - Merge branch 'master' into refersto
>>>   - More explicit refersTo0 comment.
>>>   - simplify test
>>>   - cleanup nits from Mandy
>>>   - use Object instead of TestObject
>>>   - improve refersTo0 descriptions
>>>   - basic functional test
>>>   - change referent access
>>>   - expand test
>>>   - remove CMS comment
>>>   - ... and 1 more: https://git.openjdk.java.net/jdk/compare/b5adeaad...ab4e519b
>>
>> src/java.base/share/classes/java/lang/ref/Reference.java line 348:
>>
>>> 346:      * Tests if this reference object refers to {@code obj}.  If {@code obj} is
>>> 347:      * {@code null}, this method returns {@code true} if this reference object
>>> 348:      * refers to {@code null} or has been cleared.
>>
>> Is there actually a distinction between clearing and referring to null?
> 
> A (not very useful) Reference can be created with a null referent.

Yes but you cannot distinguish between the two cases yet this wording is 
trying to make that distinction. My concern is interaction with the 
wording here:

   * @return  {@code true} if and only if {@code obj} is the referent
   *          of this reference object

As written it implies to me that given:

Object o = new Object();
PhantomReference r = new PhantomReference(o);
r.clear();
assert(r.refersTo(null)); // pass or fail?

then the assert should fail because "null" was not the referent, as r 
has been cleared - which are two distinct cases according to the initial 
java doc. The initial doc would be clearer if it stated words to the 
effect of:

"returns {@code true} if this reference object refers to {@code null} 
(either because it was constructed that way, or it has been cleared)."

or else the @return doc needs to account for the null case more 
explicitly. Also why the "if and only if" in the @return doc versus a 
simple "if"? What is being emphasized by using "if and only if"?

Cheers,
David
-----


> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/498
> 

From david.holmes at oracle.com  Sun Oct 18 22:09:06 2020
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 19 Oct 2020 08:09:06 +1000
Subject: RFR: 8254231: Implementation of Foreign Linker API (Incubator)
 [v4]
In-Reply-To: <QDYay9GMfL5qGkEb5KiRcW9eTVkL3iqmQVywG70UVwo=.9d936943-ee36-4b9b-8f40-dea670e9e055@github.com>
References: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
 <0Zh0H5gSXzvHSstQ2w8NBM-P8yERRPouvhZJDNGvu4A=.6cde913f-7499-4c45-bc63-b717502b661e@github.com>
 <2moJ2056gzwWoleYccv21TpFYQHw5h9bA-IZCImplhs=.763198bf-06b0-4589-b01e-217ba84af94a@github.com>
 <QDYay9GMfL5qGkEb5KiRcW9eTVkL3iqmQVywG70UVwo=.9d936943-ee36-4b9b-8f40-dea670e9e055@github.com>
Message-ID: <ff476c22-952f-4aef-40ae-c7974669e34c@oracle.com>

Hi Jorn,

I'm not reviewing this but this exchange caught my attention ...

On 16/10/2020 9:15 pm, Jorn Vernee wrote:
> On Thu, 15 Oct 2020 22:42:49 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:
> 
>>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>>>
>>>    Re-add file erroneously deleted (detected as rename)
>>
>> src/hotspot/cpu/x86/foreign_globals_x86.cpp line 56:
>>
>>> 54: }
>>> 55:
>>> 56: const ABIDescriptor parseABIDescriptor(JNIEnv* env, jobject jabi) {
>>
>> I don't know if you care about performance but of these env->calls transition into the VM and back out again.  You
>> should prefix all the code that comes from java to native with JNI_ENTRY and just use native JVM code to implement
>> these.
> 
> Currently this is prefixed with `JVM_ENTRY` e.g. like:
> JVM_ENTRY(jlong, PI_generateAdapter(JNIEnv* env, jclass _unused, jobject abi, jobject layout))
>    {
>      ThreadToNativeFromVM ttnfvm(thread);
>      return ProgrammableInvoker::generate_adapter(env, abi, layout);
>    }
> JVM_END
> (where `generate_adapter` ends up calling `parseABIDescriptor`)
> 
> JVM_ENTYRY seems to be mostly the same except for JNI_ENTRY having a `WeakPreserverExceptionMark` as well. Do we need
> to switch these? Also, I guess if we want to use VM code directly, we should get rid of the `ThreadToNativeFromVM` RAII
> handle.

Why are you going from native to VM to native again with this code? You 
would use a JNI/JVM_ENTRY because you have to execute VM runtime code. 
But your code immediately switches back to native and doesn't execute 
any VM runtime code (other than that involved in the transition logic 
itself). ??

Cheers,
David

> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/634
> 

From winterhalter at openjdk.java.net  Sun Oct 18 22:31:20 2020
From: winterhalter at openjdk.java.net (Rafael Winterhalter)
Date: Sun, 18 Oct 2020 22:31:20 GMT
Subject: RFR: 8228988: AnnotationParser throws NullPointerException on
 incompatible member type
Message-ID: <JE30SMjxGYOwl5toXuiKli58w9oeMb6n8wG2uA_4pl4=.0e965cac-2f8d-4d8d-b8ae-9146f9389578@github.com>

If an annotation member type is changed in an incompatible manner, the `AnnotationParser` currently throws a
`NullPointerException` if:

- An enumeration-typed member is changed to be an annotation type or a `Class` type.
- An annotation type is changed to be a non-annotation type.

This patch creates `AnnotationTypeMismatchExceptionProxy` to give users a better error message and to delay the
exception to the time where the annotation member is attempted to be accessed.

-------------

Commit messages:
 - 8228988: AnnotationParser throws NullPointerException on incompatible member type

Changes: https://git.openjdk.java.net/jdk/pull/725/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=725&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8228988
  Stats: 10 lines in 1 file changed: 6 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/725.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/725/head:pull/725

PR: https://git.openjdk.java.net/jdk/pull/725

From vromero at openjdk.java.net  Mon Oct 19 02:08:15 2020
From: vromero at openjdk.java.net (Vicente Romero)
Date: Mon, 19 Oct 2020 02:08:15 GMT
Subject: Integrated: 8253455: Record Classes javax.lang.model changes
In-Reply-To: <_EiRbvHonuflkmP-H77rZp9DQCpMs74zdWG3aO0_z0U=.c3b70b2f-75f2-4638-a4b4-a911e3f0851f@github.com>
References: <_EiRbvHonuflkmP-H77rZp9DQCpMs74zdWG3aO0_z0U=.c3b70b2f-75f2-4638-a4b4-a911e3f0851f@github.com>
Message-ID: <MRTjUStVJ4_r96D21JARfYVRb4Ga4k_aWHrUxmmJJ6A=.e9aa2ae1-a487-4039-8aad-4fd62570250b@github.com>

On Mon, 21 Sep 2020 23:31:51 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Please review the fix for [JDK-8253455](https://bugs.openjdk.java.net/browse/JDK-8253455) which is part of the effort
> to make records a final feature of the Java Language. The rest of the code has been published in
> [PR#290](https://github.com/openjdk/jdk/pull/290)  Thanks,
> Vicente

This pull request has now been integrated.

Changeset: 272bb5d5
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/272bb5d5
Stats:     144 lines in 12 files changed: 5 ins; 126 del; 13 mod

8253455: Record Classes javax.lang.model changes

Reviewed-by: darcy

-------------

PR: https://git.openjdk.java.net/jdk/pull/291

From rrich at openjdk.java.net  Mon Oct 19 05:18:31 2020
From: rrich at openjdk.java.net (Richard Reingruber)
Date: Mon, 19 Oct 2020 05:18:31 GMT
Subject: RFR: 8227745: Enable Escape Analysis for Better Performance in
 the Presence of JVMTI Agents [v13]
In-Reply-To: <Ll2RereRbuQLgFtIjv9pS92kPvCVuo-BI0cP1zGjVbo=.dad3a33c-0fc3-44fd-810a-f01448cf564c@github.com>
References: <Ll2RereRbuQLgFtIjv9pS92kPvCVuo-BI0cP1zGjVbo=.dad3a33c-0fc3-44fd-810a-f01448cf564c@github.com>
Message-ID: <LIoGR_CvFpC9I8voWMAioF8emhhWFEV21pekghoBJGk=.c6eff9e0-fe9a-45d3-8fcc-e745ecaaa55e@github.com>

> Hi,
> 
> this is the continuation of the review of the implementation for:
> 
> https://bugs.openjdk.java.net/browse/JDK-8227745
> https://bugs.openjdk.java.net/browse/JDK-8233915
> 
> It allows for JIT optimizations based on escape analysis even if JVMTI agents acquire capabilities to access references
> to objects that are subject to such optimizations, e.g. scalar replacement. The implementation reverts such
> optimizations just before access very much as when switching from JIT compiled execution to the interpreter, aka
> "deoptimization".  Webrev.8 was the last one before before the transition to Git/Github:
> 
> http://cr.openjdk.java.net/~rrich/webrevs/8227745/webrev.8/
> 
> Thanks, Richard.

Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision:

  Removed cross_modify_fence from JT::wait_for_object_deoptimization(). See JDK-8254264.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/119/files
  - new: https://git.openjdk.java.net/jdk/pull/119/files/272fb025..2ca09188

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=119&range=12
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=119&range=11-12

  Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/119.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/119/head:pull/119

PR: https://git.openjdk.java.net/jdk/pull/119

From shade at openjdk.java.net  Mon Oct 19 06:38:16 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 19 Oct 2020 06:38:16 GMT
Subject: RFR: 8253525: Implement getInstanceSize/sizeOf intrinsics [v2]
In-Reply-To: <e93rUplFjEg-aHNsK_erFVgID73Egxk_x2Z82nOln1Q=.8fd819d9-b20b-4b54-98f9-6596c1933518@github.com>
References: <e93rUplFjEg-aHNsK_erFVgID73Egxk_x2Z82nOln1Q=.8fd819d9-b20b-4b54-98f9-6596c1933518@github.com>
Message-ID: <4PVuHaDhnUx61L4tg9slmrd6KDHuwjABffj2bVce1RM=.c574f639-2c21-44cb-bc78-3d69d54e68de@github.com>

> This is fork off the SizeOf JEP, JDK-8249196. There is already the entry point in JDK that can use the intrinsic like
> this: `Instrumentation.getInstanceSize`. Therefore, we can implement the C1/C2 intrinsic now, hook it up to
> `Instrumentation`, and let the tools use that fast path today.  With this patch, JOL is able to be close to
> `deepSizeOf` implementation from SizeOf JEP.
> Example performance improvements for sizing up a custom linked list:
> 
> Benchmark                     (size)  Mode  Cnt       Score      Error  Units
> 
> # Default
> LinkedChainBench.linkedChain       1  avgt    5     705.835 ?    8.051  ns/op
> LinkedChainBench.linkedChain      10  avgt    5    3148.874 ?   37.856  ns/op
> LinkedChainBench.linkedChain     100  avgt    5   28693.256 ?  142.254  ns/op
> LinkedChainBench.linkedChain    1000  avgt    5  290161.590 ? 4594.631  ns/op
> 
> # Instrumentation attached, no intrinsics
> LinkedChainBench.linkedChain       1  avgt    5    159.659 ?   19.238  ns/op
> LinkedChainBench.linkedChain      10  avgt    5    717.659 ?   22.540  ns/op
> LinkedChainBench.linkedChain     100  avgt    5   7739.394 ?  111.683  ns/op
> LinkedChainBench.linkedChain    1000  avgt    5  80724.238 ? 2887.794  ns/op
> 
> # Instrumentation attached, new intrinsics
> LinkedChainBench.linkedChain       1  avgt    5     95.254 ?   0.808  ns/op
> LinkedChainBench.linkedChain      10  avgt    5    261.564 ?   8.524  ns/op
> LinkedChainBench.linkedChain     100  avgt    5   3367.192 ?  21.128  ns/op
> LinkedChainBench.linkedChain    1000  avgt    5  34148.851 ? 373.080  ns/op

Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now
contains one commit:

  8253525: Implement getInstanceSize/sizeOf intrinsics

-------------

Changes: https://git.openjdk.java.net/jdk/pull/650/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=650&range=01
  Stats: 612 lines in 10 files changed: 563 ins; 0 del; 49 mod
  Patch: https://git.openjdk.java.net/jdk/pull/650.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/650/head:pull/650

PR: https://git.openjdk.java.net/jdk/pull/650

From shade at openjdk.java.net  Mon Oct 19 06:57:24 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 19 Oct 2020 06:57:24 GMT
Subject: RFR: 8253525: Implement getInstanceSize/sizeOf intrinsics [v3]
In-Reply-To: <e93rUplFjEg-aHNsK_erFVgID73Egxk_x2Z82nOln1Q=.8fd819d9-b20b-4b54-98f9-6596c1933518@github.com>
References: <e93rUplFjEg-aHNsK_erFVgID73Egxk_x2Z82nOln1Q=.8fd819d9-b20b-4b54-98f9-6596c1933518@github.com>
Message-ID: <WBF6B2x9DbvEX2SXbhPHcCsQrJ2q9zIblQJ0-S1bSiA=.b9005c9b-ad7d-409f-a114-28f6b90afcd6@github.com>

> This is fork off the SizeOf JEP, JDK-8249196. There is already the entry point in JDK that can use the intrinsic like
> this: `Instrumentation.getInstanceSize`. Therefore, we can implement the C1/C2 intrinsic now, hook it up to
> `Instrumentation`, and let the tools use that fast path today.  With this patch, JOL is able to be close to
> `deepSizeOf` implementation from SizeOf JEP.
> Example performance improvements for sizing up a custom linked list:
> 
> Benchmark                     (size)  Mode  Cnt       Score      Error  Units
> 
> # Default
> LinkedChainBench.linkedChain       1  avgt    5     705.835 ?    8.051  ns/op
> LinkedChainBench.linkedChain      10  avgt    5    3148.874 ?   37.856  ns/op
> LinkedChainBench.linkedChain     100  avgt    5   28693.256 ?  142.254  ns/op
> LinkedChainBench.linkedChain    1000  avgt    5  290161.590 ? 4594.631  ns/op
> 
> # Instrumentation attached, no intrinsics
> LinkedChainBench.linkedChain       1  avgt    5    159.659 ?   19.238  ns/op
> LinkedChainBench.linkedChain      10  avgt    5    717.659 ?   22.540  ns/op
> LinkedChainBench.linkedChain     100  avgt    5   7739.394 ?  111.683  ns/op
> LinkedChainBench.linkedChain    1000  avgt    5  80724.238 ? 2887.794  ns/op
> 
> # Instrumentation attached, new intrinsics
> LinkedChainBench.linkedChain       1  avgt    5     95.254 ?   0.808  ns/op
> LinkedChainBench.linkedChain      10  avgt    5    261.564 ?   8.524  ns/op
> LinkedChainBench.linkedChain     100  avgt    5   3367.192 ?  21.128  ns/op
> LinkedChainBench.linkedChain    1000  avgt    5  34148.851 ? 373.080  ns/op

Aleksey Shipilev 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:

  8253525: Implement getInstanceSize/sizeOf intrinsics

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/650/files
  - new: https://git.openjdk.java.net/jdk/pull/650/files/d744a913..6160f6a8

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=650&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=650&range=01-02

  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/650.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/650/head:pull/650

PR: https://git.openjdk.java.net/jdk/pull/650

From mcimadamore at openjdk.java.net  Mon Oct 19 10:34:32 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 19 Oct 2020 10:34:32 GMT
Subject: RFR: 8254162: Implementation of Foreign-Memory Access API (Third
 Incubator) [v13]
In-Reply-To: <IngRk57F78UN3yySfo6IABbdwnMogGNdYrykh_3em-c=.b81f7478-015c-45ed-9788-58d7519a2770@github.com>
References: <IngRk57F78UN3yySfo6IABbdwnMogGNdYrykh_3em-c=.b81f7478-015c-45ed-9788-58d7519a2770@github.com>
Message-ID: <TUZ_G4CzBA8tf0NgODaBk2p3S9Q0U_2ORYzIiqblUB8=.b7c38d3a-167f-4ad6-9816-f8e14baf4075@github.com>

> This patch contains the changes associated with the third incubation round of the foreign memory access API incubation
> (see JEP 393 [1]). This iteration focus on improving the usability of the API in 3 main ways:
> * first, by providing a way to obtain truly *shared* segments, which can be accessed and closed concurrently from
>   multiple threads
> * second, by providing a way to register a memory segment against a `Cleaner`, so as to have some (optional) guarantee
>   that the memory will be deallocated, eventually
> * third, by not requiring users to dive deep into var handles when they first pick up the API; a new `MemoryAccess` class
>   has been added, which defines several useful dereference routines; these are really just thin wrappers around memory
>   access var handles, but they make the barrier of entry for using this API somewhat lower.
> 
> A big conceptual shift that comes with this API refresh is that the role of `MemorySegment` and `MemoryAddress` is not
> the same as it used to be; it used to be the case that a memory address could (sometimes, not always) have a back link
> to the memory segment which originated it; additionally, memory access var handles used `MemoryAddress` as a basic unit
> of dereference.  This has all changed as per this API refresh;  now a `MemoryAddress` is just a dumb carrier which
> wraps a pair of object/long addressing coordinates; `MemorySegment` has become the star of the show, as far as
> dereferencing memory is concerned. You cannot dereference memory if you don't have a segment. This improves usability
> in a number of ways - first, it is a lot easier to wrap native addresses (`long`, essentially) into a `MemoryAddress`;
> secondly, it is crystal clear what a client has to do in order to dereference memory: if a client has a segment, it can
> use that; otherwise, if the client only has an address, it will have to create a segment *unsafely* (this can be done
> by calling `MemoryAddress::asSegmentRestricted`).  A list of the API, implementation and test changes is provided
> below. If  you have any questions, or need more detailed explanations, I (and the  rest of the Panama team) will be
> happy to point at existing discussions,  and/or to provide the feedback required.   A big thank to Erik Osterlund,
> Vladimir Ivanov and David Holmes, without whom the work on shared memory segment would not have been possible; also I'd
> like to thank Paul Sandoz, whose insights on API design have been very helpful in this journey.  Thanks  Maurizio
> Javadoc:   http://cr.openjdk.java.net/~mcimadamore/8254162_v1/javadoc/jdk/incubator/foreign/package-summary.html
> Specdiff:
> 
> http://cr.openjdk.java.net/~mcimadamore/8254162_v1/specdiff/jdk/incubator/foreign/package-summary.html
> 
> CSR:
> 
> https://bugs.openjdk.java.net/browse/JDK-8254163
> 
> 
> 
> ### API Changes
> 
> * `MemorySegment`
>   * drop factory for restricted segment (this has been moved to `MemoryAddress`, see below)
>   * added a no-arg factory for a native restricted segment representing entire native heap
>   * rename `withOwnerThread` to `handoff`
>   * add new `share` method, to create shared segments
>   * add new `registerCleaner` method, to register a segment against a cleaner
>   * add more helpers to create arrays from a segment e.g. `toIntArray`
>   * add some `asSlice` overloads (to make up for the fact that now segments are more frequently used as cursors)
>   * rename `baseAddress` to `address` (so that `MemorySegment` can implement `Addressable`)
> * `MemoryAddress`
>   * drop `segment` accessor
>   * drop `rebase` method and replace it with `segmentOffset` which returns the offset (a `long`) of this address relative
>     to a given segment
> * `MemoryAccess`
>   * New class supporting several static dereference helpers; the helpers are organized by carrier and access mode, where a
>     carrier is one of the usual suspect (a Java primitive, minus `boolean`); the access mode can be simple (e.g. access
>     base address of given segment), or indexed, in which case the accessor takes a segment and either a low-level byte
>     offset,or a high level logical index. The classification is reflected in the naming scheme (e.g. `getByte` vs.
>     `getByteAtOffset` vs `getByteAtIndex`).
> * `MemoryHandles`
>   * drop `withOffset` combinator
>   * drop `withStride` combinator
>   * the basic memory access handle factory now returns a var handle which takes a `MemorySegment` and a `long` - from which
>     it is easy to derive all the other handles using plain var handle combinators.
> * `Addressable`
>   * This is a new interface which is attached to entities which can be projected to a `MemoryAddress`. For now, both
>     `MemoryAddress` and `MemorySegment` implement it; we have plans, with JEP 389 [2] to add more implementations. Clients
>     can largely ignore this interface, which comes in really handy when defining native bindings with tools like `jextract`.
> * `MemoryLayouts`
>   * A new layout, for machine addresses, has been added to the mix.
> 
> 
> 
> ### Implementation changes
> 
> There are two main things to discuss here: support for shared segments, and the general simplification of the memory
> access var handle support.
> #### Shared segments
> 
> The support for shared segments cuts in pretty deep in the VM. Support for shared segments is notoriously hard to
> achieve, at least in a way that guarantees optimal access performances. This is caused by the fact that, if a segment
> is shared, it would be possible for a thread to close it while another is accessing it.  After considering several
> options (see [3]), we zeroed onto an approach which is inspired by an happy idea that Andrew Haley had (and that he
> reminded me of at this year OpenJDK committer workshop - thanks!). The idea is that if we could *freeze* the world
> (e.g. with a GC pause), while a segment is closed, we could then prevent segments from being accessed concurrently to a
> close operation. For this to work, it  is crucial that no GC safepoints can occur between a segment liveness check and
> the access itself (otherwise it would be possible for the accessing thread to stop just right before an unsafe call).
> It also relies on the fact that hotspot/C2 should not be able to propagate loads across safepoints.  Sadly, none of
> these conditions seems to be valid in the current implementation, so we needed to resort to a bit of creativity. First,
> we noted that, if we could mark so called *scoped* method with an annotation, it would be very simply to check as to
> whether a thread was in the middle of a scoped method when we stopped the world for a close operation (btw, instead of
> stopping the world, we do a much more efficient, thread-local polling, thanks to JEP 312 [4]).  The question is, then,
> once we detect that a thread is accessing the very segment we're about to close, what should happen? We first
> experimented with a solution which would install an *asynchronous* exception on the accessing thread, thus making it
> fail. This solution has some desirable properties, in that a `close` operation always succeeds. Unfortunately the
> machinery for async exceptions is a bit fragile (e.g. not all the code in hotspot checks for async exceptions); to
> minimize risks, we decided to revert to a simpler strategy, where `close` might fail when it finds that another thread
> is accessing the segment being closed.  As written in the javadoc, this doesn't mean that clients should just catch and
> try again; an exception on `close` is a bug in the user code, likely arising from lack of synchronization, and should
> be treated as such.  In terms of gritty implementation, we needed to centralize memory access routines in a single
> place, so that we could have a set of routines closely mimicking the primitives exposed by `Unsafe` but which, in
> addition, also provided a liveness check. This way we could mark all these routines with the special `@Scoped`
> annotation, which tells the VM that something important is going on.  To achieve this, we created a new (autogenerated)
> class, called `ScopedMemoryAccess`. This class contains all the main memory access primitives (including bulk access,
> like `copyMemory`, or `setMemory`), and accepts, in addition to the access coordinates, also a scope object, which is
> tested before access. A reachability fence is also thrown in the mix to make sure that the scope is kept alive during
> access (which is important when registering segments against cleaners).  Of course, to make memory access safe, memory
> access var handles, byte buffer var handles, and byte buffer API should use the new `ScopedMemoryAccess` class instead
> of unsafe, so that a liveness check can be triggered (in case a scope is present).  `ScopedMemoryAccess` has a
> `closeScope` method, which initiates the thread-local handshakes, and returns `true` if the handshake completed
> successfully.  The implementation of `MemoryScope` (now significantly simplified from what we had before), has two
> implementations, one for confined segments and one for shared segments; the main difference between the two is what
> happens when the scope is closed; a confined segment sets a boolean flag to false, and returns, whereas a shared
> segment goes into a `CLOSING` state, then starts the handshake, and then updates the state again, to either `CLOSED` or
> `ALIVE` depending on whether the handshake was successful or not. Note that when a shared segment is in the `CLOSING`
> state, `MemorySegment::isAlive` will still return `true`, while the liveness check upon memory access will fail.  ####
> Memory access var handles overhaul  The key realization here was that if all memory access var handles took a
> coordinate pair of `MemorySegment` and `long`, all other access types could be derived from this basic var handle
> form.  This allowed us to remove the on-the-fly var handle generation, and to simply derive structural access var
> handles (such as those obtained by calling `MemoryLayout::varHandle`) using *plain* var handle combinators, so that
> e.g. additional offset is injected into a base memory access var handle.  This also helped in simplifying the
> implementation by removing the special `withStride` and `withOffset` combinators, which previously needed low-level
> access on the innards of the memory access var handle. All that code is now gone.  #### Test changes  Not much to see
> here - most of the tests needed to be updated because of the API changes. Some were beefed up (like the array test,
> since now segments can be projected into many different kinds of arrays). A test has been added to test the `Cleaner`
> functionality, and another stress test has been added for shared segments (`TestHandshake`). Some of the
> microbenchmarks also needed some tweaks - and some of them were also updated to also test performance in the shared
> segment case.  [1] - https://openjdk.java.net/jeps/393 [2] - https://openjdk.java.net/jeps/389 [3] -
> https://mail.openjdk.java.net/pipermail/panama-dev/2020-May/009004.html [4] - https://openjdk.java.net/jeps/312

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Address CSR comments

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/548/files
  - new: https://git.openjdk.java.net/jdk/pull/548/files/6091ed0f..31674311

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=548&range=12
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=548&range=11-12

  Stats: 1224 lines in 2 files changed: 135 ins; 737 del; 352 mod
  Patch: https://git.openjdk.java.net/jdk/pull/548.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/548/head:pull/548

PR: https://git.openjdk.java.net/jdk/pull/548

From mcimadamore at openjdk.java.net  Mon Oct 19 10:39:14 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 19 Oct 2020 10:39:14 GMT
Subject: RFR: 8254162: Implementation of Foreign-Memory Access API (Third
 Incubator) [v6]
In-Reply-To: <r2OoQ5W5YQ6rjb2l3xrWy86Fju_T4tjncpoO39Gwalw=.882e7d9d-9e79-40c8-8290-71eb22ef39a4@github.com>
References: <IngRk57F78UN3yySfo6IABbdwnMogGNdYrykh_3em-c=.b81f7478-015c-45ed-9788-58d7519a2770@github.com>
 <yxFQpOG6cF_COlU-m2KJvS_6BRzRcv1ZiBSGGYNsmbA=.031c9e97-b423-4f8d-b848-b0e03f0866df@github.com>
 <pqHBaSZ3wkaJWqdEZ_cVc8iWbhRjdb8z2kLHzy9k7Aw=.e4af889e-1c9b-4a68-b11c-faa43d9ecd8d@github.com>
 <r2OoQ5W5YQ6rjb2l3xrWy86Fju_T4tjncpoO39Gwalw=.882e7d9d-9e79-40c8-8290-71eb22ef39a4@github.com>
Message-ID: <ygIP1C048S2tbLoXf5f5xzeGGK9vn-EcBvWp-WXj5Uw=.4896374a-59cb-4505-be87-43bea8ba2d57@github.com>

On Mon, 12 Oct 2020 18:06:55 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Build changes look good.
>
> I've just uploaded a biggie update to the foreign memory access support. While doing performance evaluation, we have
> realized that mixing a multi-level hierarchy (`MappedMemorySegment extends MemorySegments`) with exact invoke semantics
> of `VarHandle` and `MethodHandle` is not a good match and can lead to great performance degradation for seemingly
> "correct" code.  While some of this can be attributed to the `VarHandle` API, or to the fact that the so called
> "generic" invocation path should not be that slow in case where the parameters are clearly related, it seems smelly
> that a primitive API such as `MemorySegment` should give raise to such issues.  We have therefore decided to drop the
> `MappedMemorySegment` - this means that there's only one memory segment type users can deal with: `MemorySegment` - and
> no chance for mistakes. Of course `MappedMemorySegment` has been primarily introduces to allow for operations which
> were previously possible on `MappedByteBuffer` such as `force`. To support these use cases, a separate class has been
> introduced, namely `MappedMemorySegments` (note the trailing `S`). This class contains a bunch of static methods which
> can be used to achieve the desired effects, without polluting the `MemorySegment` API.  A new method has been added on
> `MemorySegment` which returns an optional file descriptor; this might be useful for clients which want to guess whether
> a segment is in fact a mapped segment, or if they need (e.g. in Windows) the file descriptor to do some other kind of
> low level op.  I think this approach is more true to the goals and spirit of the Foreign Memory Access API, and it also
> offers some ways to improve over the existing API: for instance, the only reason why the `MemorySegment::spliterator`
> method was a static method was that we needed inference, so that we could return either a `Spliterator<MemorySegment>`
> or a `Spliterator<MappedMemorySgement>`. All of that is gone now, so the method can return to be what it morally always
> has been: an instance method on `MemorySegment`.  Updated javadoc:
> http://cr.openjdk.java.net/~mcimadamore/8254162_v2/javadoc/jdk/incubator/foreign/package-summary.html  Updated
> specdiff: http://cr.openjdk.java.net/~mcimadamore/8254162_v2/specdiff/overview-summary.html

The latest iteration addresses a comment raised during CSR review; more specifically, the `MemoryAccess` class has
several variants of dereference methods - e.g. `getInt`, `getInt_LE`, `getInt_BE`, to support different endianness. The
comment was to just have two overloads, e.g. `getInt` and `getInt(ByteOrder)` instead of three. I've implemented the
suggestion in this new iteration, as I think it makes the API a bit more compact.

-------------

PR: https://git.openjdk.java.net/jdk/pull/548

From asemenyuk at openjdk.java.net  Mon Oct 19 10:58:12 2020
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Mon, 19 Oct 2020 10:58:12 GMT
Subject: RFR: JDK-8254783: jpackage fails on Windows when application name
 differs =?UTF-8?B?4oCm?=
In-Reply-To: <r6qCtHMkiKtZiotu5BHVP84rqeUL_5mkVyFlBeCqC7A=.45656321-6f24-4fa1-b82d-2c9797c511cf@github.com>
References: <r6qCtHMkiKtZiotu5BHVP84rqeUL_5mkVyFlBeCqC7A=.45656321-6f24-4fa1-b82d-2c9797c511cf@github.com>
Message-ID: <Iw__2RxZr9CLXc4FBRkyJhVIE_lJeiasK4f34j20l5k=.04eb7da6-3d55-40e8-94a3-a728fb682258@github.com>

On Sat, 17 Oct 2020 14:01:22 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> ?from installer name
> JDK-8254783: jpackage fails on Windows when application name differs from installer name
> When using --app-image, to create MSI installer, use the application name from AppImageData instead of the Msi
> installer name if possible.

I think we need a test for this use case.

-------------

PR: https://git.openjdk.java.net/jdk/pull/720

From fyang at openjdk.java.net  Mon Oct 19 11:14:22 2020
From: fyang at openjdk.java.net (Fei Yang)
Date: Mon, 19 Oct 2020 11:14:22 GMT
Subject: RFR: 8252204: AArch64: Implement SHA3 accelerator/intrinsic [v9]
In-Reply-To: <PJVtIubjiGKhCK81PIMhWuYxnR84DNieMDUGHdhHYZM=.ad903c93-c5e3-4614-9af1-d36bc33f735d@github.com>
References: <PJVtIubjiGKhCK81PIMhWuYxnR84DNieMDUGHdhHYZM=.ad903c93-c5e3-4614-9af1-d36bc33f735d@github.com>
Message-ID: <tk-ljSMdkVcSl3FVQkWxQ66tX2e8Fpv96NUlr1iBgTA=.f6734f3c-74db-4f22-8754-974ba665e8b7@github.com>

> Contributed-by: ard.biesheuvel at linaro.org, dongbo4 at huawei.com
> 
> This added an intrinsic for SHA3 using aarch64 v8.2 SHA3 Crypto Extensions.
> Reference implementation for core SHA-3 transform using ARMv8.2 Crypto Extensions:
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm64/crypto/sha3-ce-core.S?h=v5.4.52
> 
> Trivial adaptation in SHA3. implCompress is needed for the purpose of adding the intrinsic.
> For SHA3, we need to pass one extra parameter "digestLength" to the stub for the calculation of block size.
> "digestLength" is also used in for the EOR loop before keccak to differentiate different SHA3 variants.
> 
> We added jtreg tests for SHA3 and used QEMU system emulator which supports SHA3 instructions to test the functionality.
> Patch passed jtreg tier1-3 tests with QEMU system emulator.
> Also verified with jtreg tier1-3 tests without SHA3 instructions on aarch64-linux-gnu and x86_64-linux-gnu, to make
> sure that there's no regression.
> We used one existing JMH test for performance test: test/micro/org/openjdk/bench/java/security/MessageDigests.java
> We measured the performance benefit with an aarch64 cycle-accurate simulator.
> Patch delivers 20% - 40% performance improvement depending on specific SHA3 digest length and size of the message.
> 
> For now, this feature will not be enabled automatically for aarch64. We can auto-enable this when it is fully tested on
> real hardware.  But for the above testing purposes, this is auto-enabled when the corresponding hardware feature is
> detected.

Fei Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains
11 commits:

 - Merge master
 - Remove unnecessary code changes in vm_version_aarch64.cpp
 - Merge master
 - Merge master
 - Merge master
 - Merge master
 - Add sha3 instructions to cpu/aarch64/aarch64-asmtest.py and regenerate the test in assembler_aarch64.cpp:asm_check
 - Rebase
 - Merge master
 - Fix trailing whitespace issue
 - ... and 1 more: https://git.openjdk.java.net/jdk/compare/e9be2db7...05551701

-------------

Changes: https://git.openjdk.java.net/jdk/pull/207/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=207&range=08
  Stats: 1262 lines in 36 files changed: 1007 ins; 22 del; 233 mod
  Patch: https://git.openjdk.java.net/jdk/pull/207.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/207/head:pull/207

PR: https://git.openjdk.java.net/jdk/pull/207

From kim.barrett at oracle.com  Mon Oct 19 11:29:02 2020
From: kim.barrett at oracle.com (Kim Barrett)
Date: Mon, 19 Oct 2020 07:29:02 -0400
Subject: RFR: 8188055: (ref) Add Reference::refersTo predicate [v5]
In-Reply-To: <5f8f5c3c-6c1a-a426-b2d4-df94885e76cc@oracle.com>
References: <D4HSg8FT20Eaxk5KJkkw0GgETSxRkBn1ipS3Dt0kPto=.e4bab078-2e04-4413-90cb-9bfafb2a6831@github.com>
 <FHx-oBhE254DZWHhg2RTKjZn_-yYN5xadTW7GXhTxzM=.7e6a46fa-5259-428c-b725-81b4fe48b8f7@github.com>
 <3L0hT4NZvzC8V2D7WfDFdv1T7FRdTPMPOWWGnHoKxB0=.3f962415-7d0d-40ae-b5ed-a0a1f9da11be@github.com>
 <VZRnbCYjfDq8Bo94vjB9jJKt4_tDFelcEHNiOB4VHuM=.023edb69-a402-44c9-904c-bda9a8349263@github.com>
 <5f8f5c3c-6c1a-a426-b2d4-df94885e76cc@oracle.com>
Message-ID: <DEA2CA91-03D4-4EB0-97ED-860D0CC51114@oracle.com>

> On Oct 18, 2020, at 5:36 PM, David Holmes <david.holmes at oracle.com> wrote:
> 
> On 17/10/2020 1:23 am, Kim Barrett wrote:
>>> src/java.base/share/classes/java/lang/ref/Reference.java line 348:
>>> 
>>>> 346:      * Tests if this reference object refers to {@code obj}.  If {@code obj} is
>>>> 347:      * {@code null}, this method returns {@code true} if this reference object
>>>> 348:      * refers to {@code null} or has been cleared.
>>> 
>>> Is there actually a distinction between clearing and referring to null?
>> A (not very useful) Reference can be created with a null referent.
> 
> Yes but you cannot distinguish between the two cases yet this wording is trying to make that distinction. My concern is interaction with the wording here:
> 
>  * @return  {@code true} if and only if {@code obj} is the referent
>  *          of this reference object
> 
> As written it implies to me that given:
> 
> Object o = new Object();
> PhantomReference r = new PhantomReference(o);
> r.clear();
> assert(r.refersTo(null)); // pass or fail?
> 
> then the assert should fail because "null" was not the referent, as r has been cleared - which are two distinct cases according to the initial java doc. The initial doc would be clearer if it stated words to the effect of:
> 
> "returns {@code true} if this reference object refers to {@code null} (either because it was constructed that way, or it has been cleared)."
> 
> or else the @return doc needs to account for the null case more explicitly.

I don't see how you arrive at the assert failing. The referent is what get
would return, by definition. And get returns null for a cleared reference.

The wording in the initial javadoc is the result of offline requests from
Mandy from before the first public version.  Before that I had just

* Tests if {@code obj} is the referent of this reference object.

My recollection (the discussion is lost - darn slack retention limits) is
that Mandy felt the reliance on the meaning of "referent" from get was too
indirect, and that some additional discussion of the null case was needed
for refersTo. Personally, I'd be happy with deleting that 2nd sentence, and
even reverting to my original description, but Mandy (and others) might not
agree.

Maybe something like the following?

* Tests if {@code obj} is the referent of this reference object.
* If {@code obj} is {@code null}, this method returns {@code true} if
* this reference object was constructed with a {@code null} referent
* or has been cleared.

> Also why the "if and only if" in the @return doc versus a simple "if"? What is being emphasized by using "if and only if"?

"if and only if" is the same phrasing used by isEnqueued; I just followed
that, perhaps overly slavishly.  It seems like that's pretty common usage
elsewhere too.  But I don't have any objection to removing "and only if" if
that's what the experts want.  (I'm not really a Java programmer.)



From jvernee at openjdk.java.net  Mon Oct 19 11:29:23 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Mon, 19 Oct 2020 11:29:23 GMT
Subject: RFR: 8254231: Implementation of Foreign Linker API (Incubator)
 [v4]
In-Reply-To: <QDYay9GMfL5qGkEb5KiRcW9eTVkL3iqmQVywG70UVwo=.9d936943-ee36-4b9b-8f40-dea670e9e055@github.com>
References: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
 <0Zh0H5gSXzvHSstQ2w8NBM-P8yERRPouvhZJDNGvu4A=.6cde913f-7499-4c45-bc63-b717502b661e@github.com>
 <2moJ2056gzwWoleYccv21TpFYQHw5h9bA-IZCImplhs=.763198bf-06b0-4589-b01e-217ba84af94a@github.com>
 <QDYay9GMfL5qGkEb5KiRcW9eTVkL3iqmQVywG70UVwo=.9d936943-ee36-4b9b-8f40-dea670e9e055@github.com>
Message-ID: <nc34SzKyogtvj_Ma2fsdedTAv1NLFkLoQQ-aYsSqn_8=.f5f8f320-747e-49d7-8a60-8b8d49388d84@github.com>

On Fri, 16 Oct 2020 11:12:01 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> src/hotspot/cpu/x86/foreign_globals_x86.cpp line 56:
>> 
>>> 54: }
>>> 55:
>>> 56: const ABIDescriptor parseABIDescriptor(JNIEnv* env, jobject jabi) {
>> 
>> I don't know if you care about performance but of these env->calls transition into the VM and back out again.  You
>> should prefix all the code that comes from java to native with JNI_ENTRY and just use native JVM code to implement
>> these.
>
> Currently this is prefixed with `JVM_ENTRY` e.g. like:
> JVM_ENTRY(jlong, PI_generateAdapter(JNIEnv* env, jclass _unused, jobject abi, jobject layout))
>   {
>     ThreadToNativeFromVM ttnfvm(thread);
>     return ProgrammableInvoker::generate_adapter(env, abi, layout);
>   }
> JVM_END
> (where `generate_adapter` ends up calling `parseABIDescriptor`)
> 
> JVM_ENTYRY seems to be mostly the same except for JNI_ENTRY having a `WeakPreserverExceptionMark` as well. Do we need
> to switch these? Also, I guess if we want to use VM code directly, we should get rid of the `ThreadToNativeFromVM` RAII
> handle.

re-wrote this code to use the VM internal APIs instead of JNI, changes are isolated in a sub-pr here:
https://github.com/mcimadamore/jdk/pull/1 Could you take a look?

-------------

PR: https://git.openjdk.java.net/jdk/pull/634

From jvernee at openjdk.java.net  Mon Oct 19 11:29:22 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Mon, 19 Oct 2020 11:29:22 GMT
Subject: RFR: 8254231: Implementation of Foreign Linker API (Incubator)
 [v4]
In-Reply-To: <2moJ2056gzwWoleYccv21TpFYQHw5h9bA-IZCImplhs=.763198bf-06b0-4589-b01e-217ba84af94a@github.com>
References: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
 <0Zh0H5gSXzvHSstQ2w8NBM-P8yERRPouvhZJDNGvu4A=.6cde913f-7499-4c45-bc63-b717502b661e@github.com>
 <2moJ2056gzwWoleYccv21TpFYQHw5h9bA-IZCImplhs=.763198bf-06b0-4589-b01e-217ba84af94a@github.com>
Message-ID: <1qSzjGTeTsGkvOvOIiXjY8JP944k3uLaq6KhkUP1vHE=.068f0409-ef1d-486a-8d74-c587619893e9@github.com>

On Thu, 15 Oct 2020 23:15:07 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Re-add file erroneously deleted (detected as rename)
>
> I looked through some Hotspot runtime code and that looks ok.  I saw a couple of strange things on my way through the
> code.  See comments.

Hi David, this code somewhat predates me, so I initially kept the JVM_ENTRY since that was what was already in place.
IIRC the thread state transition was added later to be able to call JNI code, which checks that the thread state is
native in some asserts.

I've re-written this code, per @coleenp 's suggestion, to use VM code directly to replace what we were doing with JNI,
so the thread state transition is also gone.

I've looked at some of the *_ENTRY macros and the only one that seems to avoid the thread state transition is JVM_LEAF.
I've switched the RegisterNatives functions we use to JVM_LEAF to avoid the redundant transitions. I also tried
changing `PI_invokeNative` to JVM_LEAF, but since we can call back into Java from that, I run into a missing handle
mark assert for some of the tests, so I've left that one as JVM_ENTRY (but removed some redundant braces).

I've created a separate sub-pr against this PR's branch to make it easier to see what I've changed:
https://github.com/mcimadamore/jdk/pull/1 (feel free to take a look).

Thanks for the comments.

-------------

PR: https://git.openjdk.java.net/jdk/pull/634

From herrick at openjdk.java.net  Mon Oct 19 13:04:12 2020
From: herrick at openjdk.java.net (Andy Herrick)
Date: Mon, 19 Oct 2020 13:04:12 GMT
Subject: RFR: JDK-8254843: Exception launching app on windows in some cases
In-Reply-To: <-B1DmsWgtBbw38skdUnJcqtls4ToSNz5mTUmwjf32Xo=.9b2ef88f-fa26-4a85-8243-8141108ec447@github.com>
References: <TPcZJguZshLTz6DP1TeLYnmI7d2lMrI89UBYXOF0How=.91e29d6f-1b4e-4f5d-bb4d-345d7be2866f@github.com>
 <-B1DmsWgtBbw38skdUnJcqtls4ToSNz5mTUmwjf32Xo=.9b2ef88f-fa26-4a85-8243-8141108ec447@github.com>
Message-ID: <fGNiR4eHv9osMklUzXJInybdpInKpIJGQF9ZJzBwBzs=.5334555d-af99-4a06-8fb9-7ec250152805@github.com>

On Fri, 16 Oct 2020 23:31:24 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> JDK-8254843: Exception launching app on windows in some cases
>> loading splashscreen.dll in WinLaunchercpp would load java.dll from path instead of runtime/bin causing jni launcher to
>> crash. instead we just use what used to be the fallback, using loadDllWithAddDllDirectory().
>
> Marked as reviewed by almatvee (Committer).

@azuev-java - can you review also ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/706

From mcimadamore at openjdk.java.net  Mon Oct 19 13:13:27 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 19 Oct 2020 13:13:27 GMT
Subject: RFR: 8254231: Implementation of Foreign Linker API (Incubator)
 [v5]
In-Reply-To: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
References: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
Message-ID: <ZFJ-ZXVHOnQZEqLuxOJ-ipl27NGhmrzKz2Iq8sgMRew=.2da2e1fe-e0fd-45eb-ad2e-cf1a28b61ba1@github.com>

> This patch contains the changes associated with the first incubation round of the foreign linker access API incubation
> (see JEP 389 [1]). This work is meant to sit on top of the foreign memory access support (see JEP 393 [2] and
> associated pull request [3]).
> The main goal of this API is to provide a way to call native functions from Java code without the need of intermediate
> JNI glue code. In order to do this, native calls are modeled through the MethodHandle API. I suggest reading the
> writeup [4] I put together few weeks ago, which illustrates what the foreign linker support is, and how it should be
> used by clients.  Disclaimer: the pull request mechanism isn't great at managing *dependent* reviews. For this reasons,
> I'm attaching a webrev which contains only the differences between this PR and the memory access PR. I will be
> periodically uploading new webrevs, as new iterations come out, to try and make the life of reviewers as simple as
> possible.  A big thank to Jorn Vernee and Vladimir Ivanov - they are the main architects of all the hotspot changes you
> see here, and without their help, the foreign linker support wouldn't be what it is today. As usual, a big thank to
> Paul Sandoz, who provided many insights (often by trying the bits first hand).  Thanks Maurizio
> Webrev:
> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/webrev
> 
> Javadoc:
> 
> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/javadoc/jdk/incubator/foreign/package-summary.html
> 
> Specdiff (relative to [3]):
> 
> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/specdiff_delta/overview-summary.html
> 
> CSR:
> 
> https://bugs.openjdk.java.net/browse/JDK-8254232
> 
> 
> 
> ### API Changes
> 
> The API changes are actually rather slim:
> 
> * `LibraryLookup`
>   * This class allows clients to lookup symbols in native libraries; the interface is fairly simple; you can load a library
>     by name, or absolute path, and then lookup symbols on that library.
> * `FunctionDescriptor`
>   * This is an abstraction that is very similar, in spirit, to `MethodType`; it is, at its core, an aggregate of memory
>     layouts for the function arguments/return type. A function descriptor is used to describe the signature of a native
>     function.
> * `CLinker`
>   * This is the real star of the show. A `CLinker` has two main methods: `downcallHandle` and `upcallStub`; the first takes
>     a native symbol (as obtained from `LibraryLookup`), a `MethodType` and a `FunctionDescriptor` and returns a
>     `MethodHandle` instance which can be used to call the target native symbol. The second takes an existing method handle,
>     and a `FunctionDescriptor` and returns a new `MemorySegment` corresponding to a code stub allocated by the VM which
>     acts as a trampoline from native code to the user-provided method handle. This is very useful for implementing upcalls.
>    * This class also contains the various layout constants that should be used by clients when describing native signatures
>      (e.g. `C_LONG` and friends); these layouts contain additional ABI classfication information (in the form of layout
>      attributes) which is used by the runtime to *infer* how Java arguments should be shuffled for the native call to take
>      place.
>   * Finally, this class provides some helper functions e.g. so that clients can convert Java strings into C strings and
>     back.
> * `NativeScope`
>   * This is an helper class which allows clients to group together logically related allocations; that is, rather than
>     allocating separate memory segments using separate *try-with-resource* constructs, a `NativeScope` allows clients to
>     use a _single_ block, and allocate all the required segments there. This is not only an usability boost, but also a
>     performance boost, since not all allocation requests will be turned into `malloc` calls.
> * `MemorySegment`
>   * Only one method added here - namely `handoff(NativeScope)` which allows a segment to be transferred onto an existing
>     native scope.
> 
> ### Safety
> 
> The foreign linker API is intrinsically unsafe; many things can go wrong when requesting a native method handle. For
> instance, the description of the native signature might be wrong (e.g. have too many arguments) - and the runtime has,
> in the general case, no way to detect such mismatches. For these reasons, obtaining a `CLinker` instance is
> a *restricted* operation, which can be enabled by specifying the usual JDK property `-Dforeign.restricted=permit` (as
> it's the case for other restricted method in the foreign memory API).  ### Implementation changes  The Java changes
> associated with `LibraryLookup` are relative straightforward; the only interesting thing to note here is that library
> loading does _not_ depend on class loaders, so `LibraryLookup` is not subject to the same restrictions which apply to
> JNI library loading (e.g. same library cannot be loaded by different classloaders).  As for `NativeScope` the changes
> are again relatively straightforward; it is an API which sits neatly on top of the foreign meory access API, providing
> some kind of allocation service which shares the same underlying memory segment(s), and turns an allocation request
> into a segment slice, which is a much less expensive operation. `NativeScope` comes in two variants: there are native
> scopes for which the allocation size is known a priori, and native scopes which can grow - these two schemes are
> implemented by two separate subclasses of `AbstractNativeScopeImpl`.  Of course the bulk of the changes are to support
> the `CLinker` downcall/upcall routines. These changes cut pretty deep into the JVM; I'll briefly summarize the goal of
> some of this changes - for further details, Jorn has put together a detailed writeup which explains the rationale
> behind the VM support, with some references to the code [5].  The main idea behind foreign linker is to infer, given a
> Java method type (expressed as a `MethodType` instance) and the description of the signature of a native function
> (expressed as a `FunctionDescriptor` instance) a _recipe_ that can be used to turn a Java call into the corresponding
> native call targeting the requested native function.  This inference scheme can be defined in a pretty straightforward
> fashion by looking at the various ABI specifications (for instance, see [6] for the SysV ABI, which is the one used on
> Linux/Mac). The various `CallArranger` classes, of which we have a flavor for each supported platform, do exactly that
> kind of inference.  For the inference process to work, we need to attach extra information to memory layouts; it is no
> longer sufficient to know e.g. that a layout is 32/64 bits - we need to know whether it is meant to represent a
> floating point value, or an integral value; this knowledge is required because floating points are passed in different
> registers by most ABIs. For this reason, `CLinker` offers a set of pre-baked, platform-dependent layout constants which
> contain the required classification attributes (e.g. a `Clinker.TypeKind` enum value). The runtime extracts this
> attribute, and performs classification accordingly.  A native call is decomposed into a sequence of basic, primitive
> operations, called `Binding` (see the great javadoc on the `Binding.java` class for more info). There are many such
> bindings - for instance the `Move` binding is used to move a value into a specific machine register/stack slot. So, the
> main job of the various `CallingArranger` classes is to determine, given a Java `MethodType` and `FunctionDescriptor`
> what is the set of bindings associated with the downcall/upcall.  At the heart of the foreign linker support is the
> `ProgrammableInvoker` class. This class effectively generates a `MethodHandle` which follows the steps described by the
> various bindings obtained by `CallArranger`. There are actually various strategies to interpret these bindings - listed
> below:
> * basic intepreted mode; in this mode, all bindings are interpreted using a stack-based machine written in Java (see
>   `BindingInterpreter`), except for the `Move` bindings. For these bindings, the move is implemented by allocating
>   a *buffer* (whose size is ABI specific) and by moving all the lowered values into positions within this buffer. The
>   buffer is then passed to a piece of assembly code inside the VM which takes values from the buffer and moves them in
>   their expected registers/stack slots (note that each position in the buffer corresponds to a different register). This
>   is the most general invocation mode, the more "customizable" one, but also the slowest - since for every call there is
>   some extra allocation which takes place.
> 
> * specialized interpreted mode; same as before, but instead of interpreting the bindings with a stack-based interpreter,
>   we generate a method handle chain which effectively interprets all the bindings (again, except `Move` ones).
> 
> * intrinsified mode; this is typically used in combination with the specialized interpreted mode described above
>   (although it can also be used with the Java-based binding interpreter). The goal here is to remove the buffer
>   allocation and copy by introducing an additional JVM intrinsic. If a native call recipe is constant (e.g. the set of
>   bindings is constant, which is probably the case if the native method handle is stored in a `static`, `final` field),
>   then the VM can generate specialized assembly code which interprets the `Move` binding without the need to go for an
>   intermediate buffer. This gives us back performances that are on par with JNI.
> 
> For upcalls, the support is not (yet) as advanced, and only the basic interpreted mode is available there. We plan to
> add support for intrinsified modes there as well, which should considerably boost perfomances (probably well beyond
> what JNI can offer at the moment, since the upcall support in JNI is not very well optimized).  Again, for more
> readings on the internals of the foreign linker support, please refer to [5].
> #### Test changes
> 
> Many new tests have been added to validate the foreign linker support; we have high level tests (see `StdLibTest`)
> which aim at testing the linker from the perspective of code that clients could write. But we also have deeper
> combinatorial tests (see `TestUpcall` and `TestDowncall`) which are meant to stress every corner of the ABI
> implementation. There are also some great tests (see the `callarranger` folder) which test the various `CallArranger`s
> for all the possible platforms; these tests adopt more of a white-box approach - that is, instead of treating the
> linker machinery as a black box and verify that the support works by checking that the native call returned the results
> we expected, these tests aims at checking that the set of bindings generated by the call arranger is correct. This also
> mean that we can test the classification logic for Windows, Mac and Linux regardless of the platform we're executing
> on.  Some additional microbenchmarks have been added to compare the performances of downcall/upcall with JNI.  [1] -
> https://openjdk.java.net/jeps/389 [2] - https://openjdk.java.net/jeps/393 [3] -
> https://git.openjdk.java.net/jdk/pull/548 [4] -
> https://github.com/openjdk/panama-foreign/blob/foreign-jextract/doc/panama_ffi.md [5] -
> http://cr.openjdk.java.net/~jvernee/docs/Foreign-abi%20downcall%20intrinsics%20technical%20description.html

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Use separate constants for native invoker code size

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/634/files
  - new: https://git.openjdk.java.net/jdk/pull/634/files/830c5cea..c595a8dd

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=634&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=634&range=03-04

  Stats: 12 lines in 4 files changed: 8 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/634.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/634/head:pull/634

PR: https://git.openjdk.java.net/jdk/pull/634

From hannesw at openjdk.java.net  Mon Oct 19 14:12:19 2020
From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Mon, 19 Oct 2020 14:12:19 GMT
Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12
In-Reply-To: <RRMAPzh6xcVcxOj2S_VW_r50YvZz-3Imaj46bDi8e9U=.9347534e-d482-468a-8668-132d5516bb76@github.com>
References: <RRMAPzh6xcVcxOj2S_VW_r50YvZz-3Imaj46bDi8e9U=.9347534e-d482-468a-8668-132d5516bb76@github.com>
Message-ID: <8uZm9233btN0CTqlw9Na2eH1apGLJsxBO9QUUkzEcoU=.74b1734a-19b9-409e-b1d8-230121993275@github.com>

On Fri, 16 Oct 2020 15:20:03 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> This is an update to javac and javadoc, to introduce support for Preview APIs, and generally improve javac and javadoc
> behavior to more closely adhere to JEP 12.
> The notable changes are:
> 
>  * adding support for Preview APIs (javac until now supported primarily only preview language features, and APIs
>    associated with preview language features). This includes:
>      * the @PreviewFeature annotation has boolean attribute "reflective", which should be true for reflective Preview APIs,
>        false otherwise. This replaces the existing "essentialAPI" attribute with roughly inverted meaning.
>      * the preview warnings for preview APIs are auto-suppressed as described in the JEP 12. E.g. the module that declares the
>        preview API is free to use it without warnings
>  * improving error/warning messages. Please see [1] for a list of cases/examples.
>  * class files are only marked as preview if they are using a preview feature. [1] also shows if a class file is marked as
>    preview or not.
>  * the PreviewFeature annotation has been moved to jdk.internal.javac package (originally was in the jdk.internal package).
>  * Preview API in JDK's javadoc no longer needs to specify @preview tag in the source files. javadoc will auto-generate a
>    note for @PreviewFeature elements, see e.g. [2] and [3] (non-reflective and reflective API, respectively). A summary of
>    preview elements is also provided [4]. Existing uses of @preview have been updated/removed.
>  * non-JDK javadoc is also enhanced to auto-generate preview notes for uses of Preview elements, and for declaring
>    elements using preview language features [5].
>  
>  Please also see the CSR [6] for more information.
>  
>  [1] http://cr.openjdk.java.net/~jlahoda/8250768/JEP12-errors-warnings-v6.html
>  [2] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.base/java/lang/Record.html
>  [3]
>  http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.compiler/javax/lang/model/element/RecordComponentElement.html
>  [4] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/preview-list.html [5]
>  http://cr.openjdk.java.net/~jlahoda/8250768/test.javadoc.00/ [6] https://bugs.openjdk.java.net/browse/JDK-8250769

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java line 2238:

> 2236:             if (previewTree != null) {
> 2237:                 previewDiv.add(new HtmlTree(TagName.A).put(HtmlAttr.ID, "preview")
> 2238:                                                       .add(new
> RawHtml(utils.getPreviewTreeSummaryOrDetails(previewTree, false))));

The `id` attribute needs to be unique within the page, so in addition to make the value not a valid java identifier (as
@jonathan-gibbons pointed out in a comment elsewhere) we need to support multiple preview ids per page. One way to do
this would be to add the element name to the id value, e.g. `preview-<element name>`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/703

From herrick at openjdk.java.net  Mon Oct 19 14:17:09 2020
From: herrick at openjdk.java.net (Andy Herrick)
Date: Mon, 19 Oct 2020 14:17:09 GMT
Subject: RFR: JDK-8254783: jpackage fails on Windows when application name
 differs =?UTF-8?B?4oCm?=
In-Reply-To: <Iw__2RxZr9CLXc4FBRkyJhVIE_lJeiasK4f34j20l5k=.04eb7da6-3d55-40e8-94a3-a728fb682258@github.com>
References: <r6qCtHMkiKtZiotu5BHVP84rqeUL_5mkVyFlBeCqC7A=.45656321-6f24-4fa1-b82d-2c9797c511cf@github.com>
 <Iw__2RxZr9CLXc4FBRkyJhVIE_lJeiasK4f34j20l5k=.04eb7da6-3d55-40e8-94a3-a728fb682258@github.com>
Message-ID: <tjY6YsGCbgcdTmGl9N76vLN0gY_AUWogOW2dbpcR-Ps=.bdbc21a9-a781-4802-93d3-3be7ceda8a73@github.com>

On Mon, 19 Oct 2020 10:55:30 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> 
> 
> I think we need a test for this use case.

The automated test is complicated by the same incorrect assumptions in the test infrastructure (that installer name and
app name are the same) . I am working on this .

-------------

PR: https://git.openjdk.java.net/jdk/pull/720

From hannesw at openjdk.java.net  Mon Oct 19 14:25:11 2020
From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Mon, 19 Oct 2020 14:25:11 GMT
Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12
In-Reply-To: <8uZm9233btN0CTqlw9Na2eH1apGLJsxBO9QUUkzEcoU=.74b1734a-19b9-409e-b1d8-230121993275@github.com>
References: <RRMAPzh6xcVcxOj2S_VW_r50YvZz-3Imaj46bDi8e9U=.9347534e-d482-468a-8668-132d5516bb76@github.com>
 <8uZm9233btN0CTqlw9Na2eH1apGLJsxBO9QUUkzEcoU=.74b1734a-19b9-409e-b1d8-230121993275@github.com>
Message-ID: <z0jHVeZkegkeaLe1frPdf4yWfxCbVyw5Ajd5zlJfVGM=.bc524d6a-e39e-4cd6-a729-939da76727f5@github.com>

On Mon, 19 Oct 2020 14:09:51 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> This is an update to javac and javadoc, to introduce support for Preview APIs, and generally improve javac and javadoc
>> behavior to more closely adhere to JEP 12.
>> The notable changes are:
>> 
>>  * adding support for Preview APIs (javac until now supported primarily only preview language features, and APIs
>>    associated with preview language features). This includes:
>>      * the @PreviewFeature annotation has boolean attribute "reflective", which should be true for reflective Preview APIs,
>>        false otherwise. This replaces the existing "essentialAPI" attribute with roughly inverted meaning.
>>      * the preview warnings for preview APIs are auto-suppressed as described in the JEP 12. E.g. the module that declares the
>>        preview API is free to use it without warnings
>>  * improving error/warning messages. Please see [1] for a list of cases/examples.
>>  * class files are only marked as preview if they are using a preview feature. [1] also shows if a class file is marked as
>>    preview or not.
>>  * the PreviewFeature annotation has been moved to jdk.internal.javac package (originally was in the jdk.internal package).
>>  * Preview API in JDK's javadoc no longer needs to specify @preview tag in the source files. javadoc will auto-generate a
>>    note for @PreviewFeature elements, see e.g. [2] and [3] (non-reflective and reflective API, respectively). A summary of
>>    preview elements is also provided [4]. Existing uses of @preview have been updated/removed.
>>  * non-JDK javadoc is also enhanced to auto-generate preview notes for uses of Preview elements, and for declaring
>>    elements using preview language features [5].
>>  
>>  Please also see the CSR [6] for more information.
>>  
>>  [1] http://cr.openjdk.java.net/~jlahoda/8250768/JEP12-errors-warnings-v6.html
>>  [2] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.base/java/lang/Record.html
>>  [3]
>>  http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.compiler/javax/lang/model/element/RecordComponentElement.html
>>  [4] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/preview-list.html [5]
>>  http://cr.openjdk.java.net/~jlahoda/8250768/test.javadoc.00/ [6] https://bugs.openjdk.java.net/browse/JDK-8250769
>
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java line 2238:
> 
>> 2236:             if (previewTree != null) {
>> 2237:                 previewDiv.add(new HtmlTree(TagName.A).put(HtmlAttr.ID, "preview")
>> 2238:                                                       .add(new
>> RawHtml(utils.getPreviewTreeSummaryOrDetails(previewTree, false))));
> 
> The `id` attribute needs to be unique within the page, so in addition to make the value not a valid java identifier (as
> @jonathan-gibbons pointed out in a comment elsewhere) we need to support multiple preview ids per page. One way to do
> this would be to add the element name to the id value, e.g. `preview-<element name>`.

Of course the element name won't do for overloaded methods and constructors... `Links#getAnchor(ExecutableElement)`
should be used for those.

-------------

PR: https://git.openjdk.java.net/jdk/pull/703

From jlahoda at openjdk.java.net  Mon Oct 19 14:52:14 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Mon, 19 Oct 2020 14:52:14 GMT
Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12
In-Reply-To: <z0jHVeZkegkeaLe1frPdf4yWfxCbVyw5Ajd5zlJfVGM=.bc524d6a-e39e-4cd6-a729-939da76727f5@github.com>
References: <RRMAPzh6xcVcxOj2S_VW_r50YvZz-3Imaj46bDi8e9U=.9347534e-d482-468a-8668-132d5516bb76@github.com>
 <8uZm9233btN0CTqlw9Na2eH1apGLJsxBO9QUUkzEcoU=.74b1734a-19b9-409e-b1d8-230121993275@github.com>
 <z0jHVeZkegkeaLe1frPdf4yWfxCbVyw5Ajd5zlJfVGM=.bc524d6a-e39e-4cd6-a729-939da76727f5@github.com>
Message-ID: <oJCmClhfwiN1Tb2XF83n6UMO_2nkSmi4HJ1-RLGa3cM=.a34113bf-08c9-4e01-966a-f665a88c0121@github.com>

On Mon, 19 Oct 2020 14:22:17 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java line 2238:
>> 
>>> 2236:             if (previewTree != null) {
>>> 2237:                 previewDiv.add(new HtmlTree(TagName.A).put(HtmlAttr.ID, "preview")
>>> 2238:                                                       .add(new
>>> RawHtml(utils.getPreviewTreeSummaryOrDetails(previewTree, false))));
>> 
>> The `id` attribute needs to be unique within the page, so in addition to make the value not a valid java identifier (as
>> @jonathan-gibbons pointed out in a comment elsewhere) we need to support multiple preview ids per page. One way to do
>> this would be to add the element name to the id value, e.g. `preview-<element name>`.
>
> Of course the element name won't do for overloaded methods and constructors... `Links#getAnchor(ExecutableElement)`
> should be used for those.

Uh, originally, there was only preview section per file, and I didn't fully realize the JDK's javadoc may have multiple
such section. I'll work on this. Thanks for the pointer!

-------------

PR: https://git.openjdk.java.net/jdk/pull/703

From github.com+70726043+rgiulietti at openjdk.java.net  Mon Oct 19 14:58:22 2020
From: github.com+70726043+rgiulietti at openjdk.java.net (Raffaello Giulietti)
Date: Mon, 19 Oct 2020 14:58:22 GMT
Subject: RFR: 8238669: Long.divideUnsigned is extremely slow for certain
 values (Needs to be Intrinsic) [v3]
In-Reply-To: <qTrgS9EALforkeYHdp592LnIrSJbqVAuv9Flfg3fbaU=.81db05a0-5847-4bfe-94ae-f4fcb922f4bc@github.com>
References: <qTrgS9EALforkeYHdp592LnIrSJbqVAuv9Flfg3fbaU=.81db05a0-5847-4bfe-94ae-f4fcb922f4bc@github.com>
Message-ID: <h_BJ873QH_bKkb-ZDGEy-ZmarUWTrU-aTlu-2prHyzM=.79a87fd0-11f4-4295-9799-3c0044d21a3a@github.com>

> This is a follow-up of the Mercurial-based workflow initiated on the core-lib-devs mailing list [0]. Not sure if this
> one is strictly necessary or if the patches sent on the list are sufficient. Anyway, I exploit this PR as a test ;-)
> [0] https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-September/068474.html

Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:

  Modified copyright year.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/31/files
  - new: https://git.openjdk.java.net/jdk/pull/31/files/e1563721..efb8c71d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=31&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=31&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/31.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/31/head:pull/31

PR: https://git.openjdk.java.net/jdk/pull/31

From mcimadamore at openjdk.java.net  Mon Oct 19 15:01:29 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 19 Oct 2020 15:01:29 GMT
Subject: RFR: 8254231: Implementation of Foreign Linker API (Incubator)
 [v6]
In-Reply-To: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
References: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
Message-ID: <ropyWfSQMyGpvc1cISXT_5lNDryU0ZBIh3RviHVE2Rg=.8be21fb2-2531-4770-a8a0-a2a2c2ecb3d0@github.com>

> This patch contains the changes associated with the first incubation round of the foreign linker access API incubation
> (see JEP 389 [1]). This work is meant to sit on top of the foreign memory access support (see JEP 393 [2] and
> associated pull request [3]).
> The main goal of this API is to provide a way to call native functions from Java code without the need of intermediate
> JNI glue code. In order to do this, native calls are modeled through the MethodHandle API. I suggest reading the
> writeup [4] I put together few weeks ago, which illustrates what the foreign linker support is, and how it should be
> used by clients.  Disclaimer: the pull request mechanism isn't great at managing *dependent* reviews. For this reasons,
> I'm attaching a webrev which contains only the differences between this PR and the memory access PR. I will be
> periodically uploading new webrevs, as new iterations come out, to try and make the life of reviewers as simple as
> possible.  A big thank to Jorn Vernee and Vladimir Ivanov - they are the main architects of all the hotspot changes you
> see here, and without their help, the foreign linker support wouldn't be what it is today. As usual, a big thank to
> Paul Sandoz, who provided many insights (often by trying the bits first hand).  Thanks Maurizio
> Webrev:
> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/webrev
> 
> Javadoc:
> 
> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/javadoc/jdk/incubator/foreign/package-summary.html
> 
> Specdiff (relative to [3]):
> 
> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/specdiff_delta/overview-summary.html
> 
> CSR:
> 
> https://bugs.openjdk.java.net/browse/JDK-8254232
> 
> 
> 
> ### API Changes
> 
> The API changes are actually rather slim:
> 
> * `LibraryLookup`
>   * This class allows clients to lookup symbols in native libraries; the interface is fairly simple; you can load a library
>     by name, or absolute path, and then lookup symbols on that library.
> * `FunctionDescriptor`
>   * This is an abstraction that is very similar, in spirit, to `MethodType`; it is, at its core, an aggregate of memory
>     layouts for the function arguments/return type. A function descriptor is used to describe the signature of a native
>     function.
> * `CLinker`
>   * This is the real star of the show. A `CLinker` has two main methods: `downcallHandle` and `upcallStub`; the first takes
>     a native symbol (as obtained from `LibraryLookup`), a `MethodType` and a `FunctionDescriptor` and returns a
>     `MethodHandle` instance which can be used to call the target native symbol. The second takes an existing method handle,
>     and a `FunctionDescriptor` and returns a new `MemorySegment` corresponding to a code stub allocated by the VM which
>     acts as a trampoline from native code to the user-provided method handle. This is very useful for implementing upcalls.
>    * This class also contains the various layout constants that should be used by clients when describing native signatures
>      (e.g. `C_LONG` and friends); these layouts contain additional ABI classfication information (in the form of layout
>      attributes) which is used by the runtime to *infer* how Java arguments should be shuffled for the native call to take
>      place.
>   * Finally, this class provides some helper functions e.g. so that clients can convert Java strings into C strings and
>     back.
> * `NativeScope`
>   * This is an helper class which allows clients to group together logically related allocations; that is, rather than
>     allocating separate memory segments using separate *try-with-resource* constructs, a `NativeScope` allows clients to
>     use a _single_ block, and allocate all the required segments there. This is not only an usability boost, but also a
>     performance boost, since not all allocation requests will be turned into `malloc` calls.
> * `MemorySegment`
>   * Only one method added here - namely `handoff(NativeScope)` which allows a segment to be transferred onto an existing
>     native scope.
> 
> ### Safety
> 
> The foreign linker API is intrinsically unsafe; many things can go wrong when requesting a native method handle. For
> instance, the description of the native signature might be wrong (e.g. have too many arguments) - and the runtime has,
> in the general case, no way to detect such mismatches. For these reasons, obtaining a `CLinker` instance is
> a *restricted* operation, which can be enabled by specifying the usual JDK property `-Dforeign.restricted=permit` (as
> it's the case for other restricted method in the foreign memory API).  ### Implementation changes  The Java changes
> associated with `LibraryLookup` are relative straightforward; the only interesting thing to note here is that library
> loading does _not_ depend on class loaders, so `LibraryLookup` is not subject to the same restrictions which apply to
> JNI library loading (e.g. same library cannot be loaded by different classloaders).  As for `NativeScope` the changes
> are again relatively straightforward; it is an API which sits neatly on top of the foreign meory access API, providing
> some kind of allocation service which shares the same underlying memory segment(s), and turns an allocation request
> into a segment slice, which is a much less expensive operation. `NativeScope` comes in two variants: there are native
> scopes for which the allocation size is known a priori, and native scopes which can grow - these two schemes are
> implemented by two separate subclasses of `AbstractNativeScopeImpl`.  Of course the bulk of the changes are to support
> the `CLinker` downcall/upcall routines. These changes cut pretty deep into the JVM; I'll briefly summarize the goal of
> some of this changes - for further details, Jorn has put together a detailed writeup which explains the rationale
> behind the VM support, with some references to the code [5].  The main idea behind foreign linker is to infer, given a
> Java method type (expressed as a `MethodType` instance) and the description of the signature of a native function
> (expressed as a `FunctionDescriptor` instance) a _recipe_ that can be used to turn a Java call into the corresponding
> native call targeting the requested native function.  This inference scheme can be defined in a pretty straightforward
> fashion by looking at the various ABI specifications (for instance, see [6] for the SysV ABI, which is the one used on
> Linux/Mac). The various `CallArranger` classes, of which we have a flavor for each supported platform, do exactly that
> kind of inference.  For the inference process to work, we need to attach extra information to memory layouts; it is no
> longer sufficient to know e.g. that a layout is 32/64 bits - we need to know whether it is meant to represent a
> floating point value, or an integral value; this knowledge is required because floating points are passed in different
> registers by most ABIs. For this reason, `CLinker` offers a set of pre-baked, platform-dependent layout constants which
> contain the required classification attributes (e.g. a `Clinker.TypeKind` enum value). The runtime extracts this
> attribute, and performs classification accordingly.  A native call is decomposed into a sequence of basic, primitive
> operations, called `Binding` (see the great javadoc on the `Binding.java` class for more info). There are many such
> bindings - for instance the `Move` binding is used to move a value into a specific machine register/stack slot. So, the
> main job of the various `CallingArranger` classes is to determine, given a Java `MethodType` and `FunctionDescriptor`
> what is the set of bindings associated with the downcall/upcall.  At the heart of the foreign linker support is the
> `ProgrammableInvoker` class. This class effectively generates a `MethodHandle` which follows the steps described by the
> various bindings obtained by `CallArranger`. There are actually various strategies to interpret these bindings - listed
> below:
> * basic intepreted mode; in this mode, all bindings are interpreted using a stack-based machine written in Java (see
>   `BindingInterpreter`), except for the `Move` bindings. For these bindings, the move is implemented by allocating
>   a *buffer* (whose size is ABI specific) and by moving all the lowered values into positions within this buffer. The
>   buffer is then passed to a piece of assembly code inside the VM which takes values from the buffer and moves them in
>   their expected registers/stack slots (note that each position in the buffer corresponds to a different register). This
>   is the most general invocation mode, the more "customizable" one, but also the slowest - since for every call there is
>   some extra allocation which takes place.
> 
> * specialized interpreted mode; same as before, but instead of interpreting the bindings with a stack-based interpreter,
>   we generate a method handle chain which effectively interprets all the bindings (again, except `Move` ones).
> 
> * intrinsified mode; this is typically used in combination with the specialized interpreted mode described above
>   (although it can also be used with the Java-based binding interpreter). The goal here is to remove the buffer
>   allocation and copy by introducing an additional JVM intrinsic. If a native call recipe is constant (e.g. the set of
>   bindings is constant, which is probably the case if the native method handle is stored in a `static`, `final` field),
>   then the VM can generate specialized assembly code which interprets the `Move` binding without the need to go for an
>   intermediate buffer. This gives us back performances that are on par with JNI.
> 
> For upcalls, the support is not (yet) as advanced, and only the basic interpreted mode is available there. We plan to
> add support for intrinsified modes there as well, which should considerably boost perfomances (probably well beyond
> what JNI can offer at the moment, since the upcall support in JNI is not very well optimized).  Again, for more
> readings on the internals of the foreign linker support, please refer to [5].
> #### Test changes
> 
> Many new tests have been added to validate the foreign linker support; we have high level tests (see `StdLibTest`)
> which aim at testing the linker from the perspective of code that clients could write. But we also have deeper
> combinatorial tests (see `TestUpcall` and `TestDowncall`) which are meant to stress every corner of the ABI
> implementation. There are also some great tests (see the `callarranger` folder) which test the various `CallArranger`s
> for all the possible platforms; these tests adopt more of a white-box approach - that is, instead of treating the
> linker machinery as a black box and verify that the support works by checking that the native call returned the results
> we expected, these tests aims at checking that the set of bindings generated by the call arranger is correct. This also
> mean that we can test the classification logic for Windows, Mac and Linux regardless of the platform we're executing
> on.  Some additional microbenchmarks have been added to compare the performances of downcall/upcall with JNI.  [1] -
> https://openjdk.java.net/jeps/389 [2] - https://openjdk.java.net/jeps/393 [3] -
> https://git.openjdk.java.net/jdk/pull/548 [4] -
> https://github.com/openjdk/panama-foreign/blob/foreign-jextract/doc/panama_ffi.md [5] -
> http://cr.openjdk.java.net/~jvernee/docs/Foreign-abi%20downcall%20intrinsics%20technical%20description.html

Maurizio Cimadamore has updated the pull request incrementally with two additional commits since the last revision:

 - Fix incorrect capitalization in one copyright header
 - Update copyright years, and add classpath exception to files that were missing it

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/634/files
  - new: https://git.openjdk.java.net/jdk/pull/634/files/c595a8dd..7d6eadc7

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=634&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=634&range=04-05

  Stats: 117 lines in 56 files changed: 56 ins; 0 del; 61 mod
  Patch: https://git.openjdk.java.net/jdk/pull/634.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/634/head:pull/634

PR: https://git.openjdk.java.net/jdk/pull/634

From github.com+70726043+rgiulietti at openjdk.java.net  Mon Oct 19 15:22:15 2020
From: github.com+70726043+rgiulietti at openjdk.java.net (Raffaello Giulietti)
Date: Mon, 19 Oct 2020 15:22:15 GMT
Subject: RFR: 8238669: Long.divideUnsigned is extremely slow for certain
 values (Needs to be Intrinsic) [v2]
In-Reply-To: <2VxJg6afuoPHO_LhlG3bImwC-F5WDAj2ZUArlGR8JeM=.4e782633-36de-40dc-ac27-7ff85f2b3325@github.com>
References: <qTrgS9EALforkeYHdp592LnIrSJbqVAuv9Flfg3fbaU=.81db05a0-5847-4bfe-94ae-f4fcb922f4bc@github.com>
 <1afMfHAUJEnM5nUkl-LbkSxjYOZwjKgWu2NDIfhbc5U=.bbeab3f9-1278-4103-b5b3-dd9a2ae745a8@github.com>
 <sqDr0vszrj6-PWBC8Oo9kTu4r72yLJwkWjly0yH3I1E=.1409e303-a261-4df5-9f58-b2945843f870@github.com>
 <NnKxMnr2bpd4fh6bj44aF-CNjRVYFvH7JvvbPbGs26E=.a2a1f5db-777b-435e-9f18-9b198c4a2d38@github.com>
 <_0eIOqisk_pEhQy1ekXy-I2-YxtB9Vs-4kjLrzBevKk=.dbe46c8a-d0f4-4919-87ec-7fa1ab74b8ce@github.com>
 <meO7jZ6tlDQdl-mBRW52wdsS1OzS2poucMTrRuu0TZI=.ace180df-9094-4602-b8c8-9975816229ad@github.com>
 <2VxJg6afuoPHO_LhlG3bImwC-F5WDAj2ZUArlGR8JeM=.4e782633-36de-40dc-ac27-7ff85f2b3325@github.com>
Message-ID: <DC0c_umSHh9sfI5Mai6dOmHopfpwSYiy003UFYQa7Gs=.762546c6-50d4-4974-89a8-4e9e9c187326@github.com>

On Sat, 17 Oct 2020 00:16:57 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Hello,
>> 
>> a reminder that this issue has not been formally reviewed.
>> Estimated time: 10-15 min with "Hacker's delight" on the desk.
>> 
>> Greetings
>> Raffaello
>
> I think the change looks good.
> 
> Before the project was on GitHub, there was a change to the test posted in
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2020-September/068504.html to address the comment in
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2020-September/068484.html. I think the test is all right but
> perhaps someone else still has a comment. The copyright year in any case needs to be adjusted.  I can sponsor this
> change if you like.

@bpb Since the switch to Skara, the test is on GitHub as well.
I just modified the copyright year some minutes ago.

-------------

PR: https://git.openjdk.java.net/jdk/pull/31

From ccheung at openjdk.java.net  Mon Oct 19 16:04:31 2020
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Mon, 19 Oct 2020 16:04:31 GMT
Subject: RFR: 8247666: Support Lambda proxy classes in static CDS archive
 [v9]
In-Reply-To: <ynh4JzHY75GjEn5_oCtmRNy9HMFsU34O2PlhSwD41tU=.1a3770f9-9091-429f-8d03-31b826f9b093@github.com>
References: <ynh4JzHY75GjEn5_oCtmRNy9HMFsU34O2PlhSwD41tU=.1a3770f9-9091-429f-8d03-31b826f9b093@github.com>
Message-ID: <puhJ2MtsfhHHloI807LpDD0dX0AJBxG1lIAkVQTstWQ=.fe4f15f2-b12d-4fc2-a835-fb94128adecb@github.com>

> Following up on archiving lambda proxy classes in dynamic CDS archive
> ([JDK-8198698](https://bugs.openjdk.java.net/browse/JDK-8198698)), this RFE adds the functionality of archiving of
> lambda proxy classes in static CDS archive.
> When the -XX:DumpLoadedClassList is enabled, the constant pool index related to LambdaMetafactory that are resolved
> during application execution will be included in the classlist. The entry for a lambda proxy class in a class list will
> be of the following format:
> `@lambda-proxy: <classname> <cp index>`
> 
> e.g.
> `@lambda-proxy: test/java/lang/invoke/MethodHandlesGeneralTest 233`
> `@lambda-proxy: test/java/lang/invoke/MethodHandlesGeneralTest 355`
> 
> When dumping a CDS archive using the -Xshare:dump and -XX:ExtraSharedClassListFile options, when the above
> `@lambda-proxy` entry is encountered while parsing the classlist, we will resolve the corresponding constant pool
> indices (233 and 355 in the above example). As a result, lambda proxy classes will be generated for the constant pool
> entries, and will be cached using a similar mechanism to JDK-8198698.  During dumping, there is check on the cp index
> and on the created BootstrapInfo using the cp index. VM will exit with an error message if the check has failed.
> During runtime when looking up a lambda proxy class, the lookup will be perform on the static CDS archive and if not
> found, then lookup from the dynamic archive if one is specified.  (Only name change (IsDynamicDumpingEnabled ->
> IsCDSDumpingEnabled) is involved in the core-libs code.)
> Testing: tiers 1,2,3,4.
> 
> Performance results (javac on HelloWorld on linux-x64):
> Results of " perf stat -r 40 bin/javac -J-Xshare:on -J-XX:SharedArchiveFile=javac2.jsa Bench_HelloWorld.java "
>    1:   2228016795  2067752708 (-160264087)      -----    377.760   349.110 (-28.650)      -----
>    2:   2223051476  2063016483 (-160034993)      -----    374.580   350.620 (-23.960)      ----
>    3:   2225908334  2067673847 (-158234487)      -----    375.220   350.990 (-24.230)      ----
>    4:   2225835999  2064596883 (-161239116)      -----    374.670   349.840 (-24.830)      ----
>    5:   2226005510  2061694332 (-164311178)      -----    373.512   351.120 (-22.392)      ----
>    6:   2225574949  2062657482 (-162917467)      -----    374.710   348.380 (-26.330)      -----
>    7:   2224702424  2064634122 (-160068302)      -----    373.670   349.510 (-24.160)      ----
>    8:   2226662277  2066301134 (-160361143)      -----    375.350   349.790 (-25.560)      ----
>    9:   2226761470  2063162795 (-163598675)      -----    374.260   351.290 (-22.970)      ----
>   10:   2230149089  2066203307 (-163945782)      -----    374.760   350.620 (-24.140)      ----
> ============================================================
>         2226266109  2064768307 (-161497801)      -----    374.848   350.126 (-24.722)      ----
> instr delta =   -161497801    -7.2542%
> time  delta =      -24.722 ms -6.5951%

Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:

  store symbolic name of ref kind (e.g. REF_invokeStatic) in classlist

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/364/files
  - new: https://git.openjdk.java.net/jdk/pull/364/files/dd6d440b..dbf3b961

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=364&range=08
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=364&range=07-08

  Stats: 14 lines in 1 file changed: 10 ins; 1 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/364.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/364/head:pull/364

PR: https://git.openjdk.java.net/jdk/pull/364

From mchung at openjdk.java.net  Mon Oct 19 16:18:13 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Mon, 19 Oct 2020 16:18:13 GMT
Subject: RFR: 8247666: Support Lambda proxy classes in static CDS archive
 [v9]
In-Reply-To: <puhJ2MtsfhHHloI807LpDD0dX0AJBxG1lIAkVQTstWQ=.fe4f15f2-b12d-4fc2-a835-fb94128adecb@github.com>
References: <ynh4JzHY75GjEn5_oCtmRNy9HMFsU34O2PlhSwD41tU=.1a3770f9-9091-429f-8d03-31b826f9b093@github.com>
 <puhJ2MtsfhHHloI807LpDD0dX0AJBxG1lIAkVQTstWQ=.fe4f15f2-b12d-4fc2-a835-fb94128adecb@github.com>
Message-ID: <duX1QSe6-BnnGvJQ5sl61O-LW9MXR-VEBTjqXrdScgM=.34b4b7d7-f555-4407-82c5-5f074d3347c9@github.com>

On Mon, 19 Oct 2020 16:04:31 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> Following up on archiving lambda proxy classes in dynamic CDS archive
>> ([JDK-8198698](https://bugs.openjdk.java.net/browse/JDK-8198698)), this RFE adds the functionality of archiving of
>> lambda proxy classes in static CDS archive.
>> When the -XX:DumpLoadedClassList is enabled, the constant pool index related to LambdaMetafactory that are resolved
>> during application execution will be included in the classlist. The entry for a lambda proxy class in a class list will
>> be of the following format:
>> `@lambda-proxy: <classname> <cp index>`
>> 
>> e.g.
>> `@lambda-proxy: test/java/lang/invoke/MethodHandlesGeneralTest 233`
>> `@lambda-proxy: test/java/lang/invoke/MethodHandlesGeneralTest 355`
>> 
>> When dumping a CDS archive using the -Xshare:dump and -XX:ExtraSharedClassListFile options, when the above
>> `@lambda-proxy` entry is encountered while parsing the classlist, we will resolve the corresponding constant pool
>> indices (233 and 355 in the above example). As a result, lambda proxy classes will be generated for the constant pool
>> entries, and will be cached using a similar mechanism to JDK-8198698.  During dumping, there is check on the cp index
>> and on the created BootstrapInfo using the cp index. VM will exit with an error message if the check has failed.
>> During runtime when looking up a lambda proxy class, the lookup will be perform on the static CDS archive and if not
>> found, then lookup from the dynamic archive if one is specified.  (Only name change (IsDynamicDumpingEnabled ->
>> IsCDSDumpingEnabled) is involved in the core-libs code.)
>> Testing: tiers 1,2,3,4.
>> 
>> Performance results (javac on HelloWorld on linux-x64):
>> Results of " perf stat -r 40 bin/javac -J-Xshare:on -J-XX:SharedArchiveFile=javac2.jsa Bench_HelloWorld.java "
>>    1:   2228016795  2067752708 (-160264087)      -----    377.760   349.110 (-28.650)      -----
>>    2:   2223051476  2063016483 (-160034993)      -----    374.580   350.620 (-23.960)      ----
>>    3:   2225908334  2067673847 (-158234487)      -----    375.220   350.990 (-24.230)      ----
>>    4:   2225835999  2064596883 (-161239116)      -----    374.670   349.840 (-24.830)      ----
>>    5:   2226005510  2061694332 (-164311178)      -----    373.512   351.120 (-22.392)      ----
>>    6:   2225574949  2062657482 (-162917467)      -----    374.710   348.380 (-26.330)      -----
>>    7:   2224702424  2064634122 (-160068302)      -----    373.670   349.510 (-24.160)      ----
>>    8:   2226662277  2066301134 (-160361143)      -----    375.350   349.790 (-25.560)      ----
>>    9:   2226761470  2063162795 (-163598675)      -----    374.260   351.290 (-22.970)      ----
>>   10:   2230149089  2066203307 (-163945782)      -----    374.760   350.620 (-24.140)      ----
>> ============================================================
>>         2226266109  2064768307 (-161497801)      -----    374.848   350.126 (-24.722)      ----
>> instr delta =   -161497801    -7.2542%
>> time  delta =      -24.722 ms -6.5951%
>
> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   store symbolic name of ref kind (e.g. REF_invokeStatic) in classlist

I reviewed the java.base changes and have no additional comment.

-------------

Marked as reviewed by mchung (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/364

From dfuchs at openjdk.java.net  Mon Oct 19 16:55:28 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Mon, 19 Oct 2020 16:55:28 GMT
Subject: RFR: 8251989: Hex formatting and parsing utility [v5]
In-Reply-To: <-Y_CD_hhxBgqmlaQnSxkXPh_88f03wak3HIb1IgnfNY=.ec1f8832-ddbc-4ccd-8b09-08ee8da3f8bd@github.com>
References: <HSEn47GMS1K3g57mrTZeQk-WZHl3pKGHpX_OOf8VnsU=.740863c2-f9e4-43c4-b500-614aab4078b1@github.com>
 <-Y_CD_hhxBgqmlaQnSxkXPh_88f03wak3HIb1IgnfNY=.ec1f8832-ddbc-4ccd-8b09-08ee8da3f8bd@github.com>
Message-ID: <bGQJd6w1ihLR_9NRFcUHYivdy3hDuj1KqhT_76bUC2I=.aecf0e03-6103-4401-b23f-a55627660353@github.com>

On Fri, 16 Oct 2020 19:56:30 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> java.util.HexFormat utility:
>> 
>>  - Format and parse hexadecimal strings, with parameters for delimiter, prefix, suffix and upper/lowercase
>>  - Static factories and builder methods to create HexFormat copies with modified parameters.
>>  - Consistent naming of methods for conversion of byte arrays to formatted strings and back: formatHex and parseHex
>>  - Consistent naming of methods for conversion of primitive types: toHexDigits... and fromHexDigits...
>>  - Prefix and suffixes now apply to each formatted value, not the string as a whole
>>  - Using java.util.Appendable as a target for buffered conversions so output to Writers and PrintStreams
>>    like System.out are supported in addition to StringBuilder. (IOExceptions are converted to unchecked exceptions)
>>  - Immutable and thread safe, a "value-based" class
>> 
>> See the [HexFormat
>> javadoc](http://cr.openjdk.java.net/~rriggs/8251989-hex-formatter/java.base/java/util/HexFormat.html) for details.
>> Review comments and suggestions welcome.
>
> Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev
> excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since
> the last revision:
>  - Merge branch 'master' into 8251989-hex-formatter
>  - Test enhancements from Chris Hegarty
>  - Expanded test coverage and fixed related bugs; Added static imports for TestNG; Corrected declaration of return type of
>    tohexDigits(Appendable...)
>  - Merge branch 'master' into 8251989-hex-formatter
>  - Cleanup of javadoc markup
>  - Added assertions to testVariableLength and samples
>  - Merge branch 'master' into 8251989-hex-formatter
>  - temp updates
>  - Various code review comments, rename UpperCase and LowerCase methods to match Character, remove unnecessary Class name
>    qualifications, etc.
>  - 8251989: Hex formatting and parsing utility

Changes requested by dfuchs (Reviewer).

src/java.base/share/classes/java/util/HexFormat.java line 332:

> 330:         if (s == null) {
> 331:             StringBuilder sb = new StringBuilder(length *
> 332:                     (delimiter.length() + prefix.length() + suffix.length()) - delimiter.length());

should that be:
length * (delimiter.length() + prefix.length() + suffix.length() + 2) - delimiter.length());
It seems to me that otherwise, if you have no delimiter, no prefix, and no suffix, then your computed size will be 0,
which seems wrong.

src/java.base/share/classes/java/util/HexFormat.java line 569:

> 567:         }
> 568:         for (int i = 0; i < literal.length(); i++) {
> 569:             if (string.charAt(index + i) != literal.charAt(i)) {

There should probably be a check to verify that `string` contains at least `index + literal.length()` characters.
Otherwise AIOBE might be thrown by `string.charAt(index + i)` ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/482

From iklam at openjdk.java.net  Mon Oct 19 16:59:14 2020
From: iklam at openjdk.java.net (Ioi Lam)
Date: Mon, 19 Oct 2020 16:59:14 GMT
Subject: RFR: 8247666: Support Lambda proxy classes in static CDS archive
 [v9]
In-Reply-To: <puhJ2MtsfhHHloI807LpDD0dX0AJBxG1lIAkVQTstWQ=.fe4f15f2-b12d-4fc2-a835-fb94128adecb@github.com>
References: <ynh4JzHY75GjEn5_oCtmRNy9HMFsU34O2PlhSwD41tU=.1a3770f9-9091-429f-8d03-31b826f9b093@github.com>
 <puhJ2MtsfhHHloI807LpDD0dX0AJBxG1lIAkVQTstWQ=.fe4f15f2-b12d-4fc2-a835-fb94128adecb@github.com>
Message-ID: <2yXKGk7mfEX6pR2AfBxq4eFs821CVYrxSBe_Wy3i2_A=.d3220e17-317a-4c05-a1e5-300ef460ff23@github.com>

On Mon, 19 Oct 2020 16:04:31 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> Following up on archiving lambda proxy classes in dynamic CDS archive
>> ([JDK-8198698](https://bugs.openjdk.java.net/browse/JDK-8198698)), this RFE adds the functionality of archiving of
>> lambda proxy classes in static CDS archive.
>> When the -XX:DumpLoadedClassList is enabled, the constant pool index related to LambdaMetafactory that are resolved
>> during application execution will be included in the classlist. The entry for a lambda proxy class in a class list will
>> be of the following format:
>> `@lambda-proxy: <classname> <cp index>`
>> 
>> e.g.
>> `@lambda-proxy: test/java/lang/invoke/MethodHandlesGeneralTest 233`
>> `@lambda-proxy: test/java/lang/invoke/MethodHandlesGeneralTest 355`
>> 
>> When dumping a CDS archive using the -Xshare:dump and -XX:ExtraSharedClassListFile options, when the above
>> `@lambda-proxy` entry is encountered while parsing the classlist, we will resolve the corresponding constant pool
>> indices (233 and 355 in the above example). As a result, lambda proxy classes will be generated for the constant pool
>> entries, and will be cached using a similar mechanism to JDK-8198698.  During dumping, there is check on the cp index
>> and on the created BootstrapInfo using the cp index. VM will exit with an error message if the check has failed.
>> During runtime when looking up a lambda proxy class, the lookup will be perform on the static CDS archive and if not
>> found, then lookup from the dynamic archive if one is specified.  (Only name change (IsDynamicDumpingEnabled ->
>> IsCDSDumpingEnabled) is involved in the core-libs code.)
>> Testing: tiers 1,2,3,4.
>> 
>> Performance results (javac on HelloWorld on linux-x64):
>> Results of " perf stat -r 40 bin/javac -J-Xshare:on -J-XX:SharedArchiveFile=javac2.jsa Bench_HelloWorld.java "
>>    1:   2228016795  2067752708 (-160264087)      -----    377.760   349.110 (-28.650)      -----
>>    2:   2223051476  2063016483 (-160034993)      -----    374.580   350.620 (-23.960)      ----
>>    3:   2225908334  2067673847 (-158234487)      -----    375.220   350.990 (-24.230)      ----
>>    4:   2225835999  2064596883 (-161239116)      -----    374.670   349.840 (-24.830)      ----
>>    5:   2226005510  2061694332 (-164311178)      -----    373.512   351.120 (-22.392)      ----
>>    6:   2225574949  2062657482 (-162917467)      -----    374.710   348.380 (-26.330)      -----
>>    7:   2224702424  2064634122 (-160068302)      -----    373.670   349.510 (-24.160)      ----
>>    8:   2226662277  2066301134 (-160361143)      -----    375.350   349.790 (-25.560)      ----
>>    9:   2226761470  2063162795 (-163598675)      -----    374.260   351.290 (-22.970)      ----
>>   10:   2230149089  2066203307 (-163945782)      -----    374.760   350.620 (-24.140)      ----
>> ============================================================
>>         2226266109  2064768307 (-161497801)      -----    374.848   350.126 (-24.722)      ----
>> instr delta =   -161497801    -7.2542%
>> time  delta =      -24.722 ms -6.5951%
>
> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   store symbolic name of ref kind (e.g. REF_invokeStatic) in classlist

LGTM

-------------

Marked as reviewed by iklam (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/364

From bpb at openjdk.java.net  Mon Oct 19 17:06:12 2020
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Mon, 19 Oct 2020 17:06:12 GMT
Subject: RFR: 8238669: Long.divideUnsigned is extremely slow for certain
 values (Needs to be Intrinsic) [v2]
In-Reply-To: <DC0c_umSHh9sfI5Mai6dOmHopfpwSYiy003UFYQa7Gs=.762546c6-50d4-4974-89a8-4e9e9c187326@github.com>
References: <qTrgS9EALforkeYHdp592LnIrSJbqVAuv9Flfg3fbaU=.81db05a0-5847-4bfe-94ae-f4fcb922f4bc@github.com>
 <1afMfHAUJEnM5nUkl-LbkSxjYOZwjKgWu2NDIfhbc5U=.bbeab3f9-1278-4103-b5b3-dd9a2ae745a8@github.com>
 <sqDr0vszrj6-PWBC8Oo9kTu4r72yLJwkWjly0yH3I1E=.1409e303-a261-4df5-9f58-b2945843f870@github.com>
 <NnKxMnr2bpd4fh6bj44aF-CNjRVYFvH7JvvbPbGs26E=.a2a1f5db-777b-435e-9f18-9b198c4a2d38@github.com>
 <_0eIOqisk_pEhQy1ekXy-I2-YxtB9Vs-4kjLrzBevKk=.dbe46c8a-d0f4-4919-87ec-7fa1ab74b8ce@github.com>
 <meO7jZ6tlDQdl-mBRW52wdsS1OzS2poucMTrRuu0TZI=.ace180df-9094-4602-b8c8-9975816229ad@github.com>
 <2VxJg6afuoPHO_LhlG3bImwC-F5WDAj2ZUArlGR8JeM=.4e782633-36de-40dc-ac27-7ff85f2b3325@github.com>
 <DC0c_umSHh9sfI5Mai6dOmHopfpwSYiy003UFYQa7Gs=.762546c6-50d4-4974-89a8-4e9e9c187326@github.com>
Message-ID: <m_0rLfvrSgWyYhVOFru5PlafArCIeUbmo170YN6u_eo=.06987c3b-10d6-4af2-8922-7ccc5f50ff70@github.com>

On Mon, 19 Oct 2020 15:18:58 GMT, Raffaello Giulietti <github.com+70726043+rgiulietti at openjdk.org> wrote:

>> I think the change looks good.
>> 
>> Before the project was on GitHub, there was a change to the test posted in
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2020-September/068504.html to address the comment in
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2020-September/068484.html. I think the test is all right but
>> perhaps someone else still has a comment. The copyright year in any case needs to be adjusted.  I can sponsor this
>> change if you like.
>
> @bpb Since the switch to Skara, the test is on GitHub as well.
> I just modified the copyright year some minutes ago.

OK, looks good. Let's leave the PR open for a day or two and then move forward. Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/31

From dfuchs at openjdk.java.net  Mon Oct 19 17:30:15 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Mon, 19 Oct 2020 17:30:15 GMT
Subject: RFR: 8247402: Documentation for Map::compute contains confusing
 implementation requirements
In-Reply-To: <ZQNheDIQUwvUufEkds2N7kkr0kV6No0Cc9qIzX_FY04=.6624b5ff-dad7-4fd1-8677-51da85a5b149@github.com>
References: <ZQNheDIQUwvUufEkds2N7kkr0kV6No0Cc9qIzX_FY04=.6624b5ff-dad7-4fd1-8677-51da85a5b149@github.com>
Message-ID: <p-8_7BL98mDBPIliaMq9DIvIe0pzeV_D6aE0js-D2Rc=.3a44e9bc-24a8-4496-9d07-f77191c9b029@github.com>

On Sat, 17 Oct 2020 02:50:28 GMT, John Lin <github.com+1290376+johnlinp at openjdk.org> wrote:

> This is from the mailing list: http://mail.openjdk.java.net/pipermail/core-libs-dev/2020-June/067190.html
> 
> ---------
> ### Progress
> - [x] Change must not contain extraneous whitespace
> - [x] Commit message must refer to an issue
> - [ ] Change must be properly reviewed
> 
> ### Testing
> 
> |     | Linux x64 | Windows x64 | macOS x64 |
> | --- | ----- | ----- | ----- |
> | Build | ?? (5/5 passed) | ?? (2/2 passed) | ?? (2/2 passed) |
> | Test (tier1) | ?? (9/9 passed) | ?? (9/9 passed) | ?? (9/9 passed) |
> 
> 
> 
> ### Download
> `$ git fetch https://git.openjdk.java.net/jdk pull/714/head:pull/714`
> `$ git checkout pull/714`

Hi Jon,

Can you explain what this change is about: e.g. something like:

> Updates the documentation of `Map::compute` to match its default implementation:
> The documentation of the default implementation of `Map::compute` was both wrong and confusing.
> This change updates the documentation to match the behaviour of the implementation.

because now I am confused. I believe what you are trying to do is what I have written above. Can you confirm?
This will need a CSR.

And are you going to withdraw https://github.com/openjdk/jdk/pull/451 now?

best regards,
-- daniel

-------------

PR: https://git.openjdk.java.net/jdk/pull/714

From kvn at openjdk.java.net  Mon Oct 19 18:17:18 2020
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Mon, 19 Oct 2020 18:17:18 GMT
Subject: RFR: 8253525: Implement getInstanceSize/sizeOf intrinsics [v3]
In-Reply-To: <WBF6B2x9DbvEX2SXbhPHcCsQrJ2q9zIblQJ0-S1bSiA=.b9005c9b-ad7d-409f-a114-28f6b90afcd6@github.com>
References: <e93rUplFjEg-aHNsK_erFVgID73Egxk_x2Z82nOln1Q=.8fd819d9-b20b-4b54-98f9-6596c1933518@github.com>
 <WBF6B2x9DbvEX2SXbhPHcCsQrJ2q9zIblQJ0-S1bSiA=.b9005c9b-ad7d-409f-a114-28f6b90afcd6@github.com>
Message-ID: <G12eddHXh2P9i2Gr6p1Lcq1wnh5Pizyj5Dg4gGPiQ8E=.50973ea6-1da6-4c34-beac-eeeaf220ad02@github.com>

On Mon, 19 Oct 2020 06:57:24 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> This is fork off the SizeOf JEP, JDK-8249196. There is already the entry point in JDK that can use the intrinsic like
>> this: `Instrumentation.getInstanceSize`. Therefore, we can implement the C1/C2 intrinsic now, hook it up to
>> `Instrumentation`, and let the tools use that fast path today.  With this patch, JOL is able to be close to
>> `deepSizeOf` implementation from SizeOf JEP.
>> Example performance improvements for sizing up a custom linked list:
>> 
>> Benchmark                     (size)  Mode  Cnt       Score      Error  Units
>> 
>> # Default
>> LinkedChainBench.linkedChain       1  avgt    5     705.835 ?    8.051  ns/op
>> LinkedChainBench.linkedChain      10  avgt    5    3148.874 ?   37.856  ns/op
>> LinkedChainBench.linkedChain     100  avgt    5   28693.256 ?  142.254  ns/op
>> LinkedChainBench.linkedChain    1000  avgt    5  290161.590 ? 4594.631  ns/op
>> 
>> # Instrumentation attached, no intrinsics
>> LinkedChainBench.linkedChain       1  avgt    5    159.659 ?   19.238  ns/op
>> LinkedChainBench.linkedChain      10  avgt    5    717.659 ?   22.540  ns/op
>> LinkedChainBench.linkedChain     100  avgt    5   7739.394 ?  111.683  ns/op
>> LinkedChainBench.linkedChain    1000  avgt    5  80724.238 ? 2887.794  ns/op
>> 
>> # Instrumentation attached, new intrinsics
>> LinkedChainBench.linkedChain       1  avgt    5     95.254 ?   0.808  ns/op
>> LinkedChainBench.linkedChain      10  avgt    5    261.564 ?   8.524  ns/op
>> LinkedChainBench.linkedChain     100  avgt    5   3367.192 ?  21.128  ns/op
>> LinkedChainBench.linkedChain    1000  avgt    5  34148.851 ? 373.080  ns/op
>
> Aleksey Shipilev 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.

Always run graalunit testing with new intrinsics.
You need to adjust Graal test:
src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/CheckGraalIntrinsics.java

-------------

Changes requested by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/650

From ccheung at openjdk.java.net  Mon Oct 19 18:19:31 2020
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Mon, 19 Oct 2020 18:19:31 GMT
Subject: RFR: 8247666: Support Lambda proxy classes in static CDS archive
 [v10]
In-Reply-To: <ynh4JzHY75GjEn5_oCtmRNy9HMFsU34O2PlhSwD41tU=.1a3770f9-9091-429f-8d03-31b826f9b093@github.com>
References: <ynh4JzHY75GjEn5_oCtmRNy9HMFsU34O2PlhSwD41tU=.1a3770f9-9091-429f-8d03-31b826f9b093@github.com>
Message-ID: <UgWjuPaEzzWGoGInpMjUdKNLZmwqWkxm0y_iowl5PMc=.1dd3b6a7-7e37-4622-95b7-f48ba5777882@github.com>

> Following up on archiving lambda proxy classes in dynamic CDS archive
> ([JDK-8198698](https://bugs.openjdk.java.net/browse/JDK-8198698)), this RFE adds the functionality of archiving of
> lambda proxy classes in static CDS archive.
> When the -XX:DumpLoadedClassList is enabled, the constant pool index related to LambdaMetafactory that are resolved
> during application execution will be included in the classlist. The entry for a lambda proxy class in a class list will
> be of the following format:
> `@lambda-proxy: <classname> <cp index>`
> 
> e.g.
> `@lambda-proxy: test/java/lang/invoke/MethodHandlesGeneralTest 233`
> `@lambda-proxy: test/java/lang/invoke/MethodHandlesGeneralTest 355`
> 
> When dumping a CDS archive using the -Xshare:dump and -XX:ExtraSharedClassListFile options, when the above
> `@lambda-proxy` entry is encountered while parsing the classlist, we will resolve the corresponding constant pool
> indices (233 and 355 in the above example). As a result, lambda proxy classes will be generated for the constant pool
> entries, and will be cached using a similar mechanism to JDK-8198698.  During dumping, there is check on the cp index
> and on the created BootstrapInfo using the cp index. VM will exit with an error message if the check has failed.
> During runtime when looking up a lambda proxy class, the lookup will be perform on the static CDS archive and if not
> found, then lookup from the dynamic archive if one is specified.  (Only name change (IsDynamicDumpingEnabled ->
> IsCDSDumpingEnabled) is involved in the core-libs code.)
> Testing: tiers 1,2,3,4.
> 
> Performance results (javac on HelloWorld on linux-x64):
> Results of " perf stat -r 40 bin/javac -J-Xshare:on -J-XX:SharedArchiveFile=javac2.jsa Bench_HelloWorld.java "
>    1:   2228016795  2067752708 (-160264087)      -----    377.760   349.110 (-28.650)      -----
>    2:   2223051476  2063016483 (-160034993)      -----    374.580   350.620 (-23.960)      ----
>    3:   2225908334  2067673847 (-158234487)      -----    375.220   350.990 (-24.230)      ----
>    4:   2225835999  2064596883 (-161239116)      -----    374.670   349.840 (-24.830)      ----
>    5:   2226005510  2061694332 (-164311178)      -----    373.512   351.120 (-22.392)      ----
>    6:   2225574949  2062657482 (-162917467)      -----    374.710   348.380 (-26.330)      -----
>    7:   2224702424  2064634122 (-160068302)      -----    373.670   349.510 (-24.160)      ----
>    8:   2226662277  2066301134 (-160361143)      -----    375.350   349.790 (-25.560)      ----
>    9:   2226761470  2063162795 (-163598675)      -----    374.260   351.290 (-22.970)      ----
>   10:   2230149089  2066203307 (-163945782)      -----    374.760   350.620 (-24.140)      ----
> ============================================================
>         2226266109  2064768307 (-161497801)      -----    374.848   350.126 (-24.722)      ----
> instr delta =   -161497801    -7.2542%
> time  delta =      -24.722 ms -6.5951%

Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:

  correct the classlist in the LambdaProxyClasslist.java test

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/364/files
  - new: https://git.openjdk.java.net/jdk/pull/364/files/dbf3b961..52d7e5fe

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=364&range=09
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=364&range=08-09

  Stats: 9 lines in 1 file changed: 0 ins; 0 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/364.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/364/head:pull/364

PR: https://git.openjdk.java.net/jdk/pull/364

From smarks at openjdk.java.net  Mon Oct 19 18:21:17 2020
From: smarks at openjdk.java.net (Stuart Marks)
Date: Mon, 19 Oct 2020 18:21:17 GMT
Subject: RFR: 8255016: ConstantDescs.FALSE claims it represents TRUE
Message-ID: <ioNtsEkS1sqKPpQ10D7APg8upnk-JmNK5Moj3M6tW5A=.32667e56-b15c-4159-993c-6e96eb424d78@github.com>

This is a fix for "just a typo" or copy/paste error, but it probably requires a CSR since it changes a normative
portion of the spec.

-------------

Commit messages:
 - 8255016: ConstantDescs.FALSE claims it represents TRUE

Changes: https://git.openjdk.java.net/jdk/pull/744/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=744&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8255016
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/744.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/744/head:pull/744

PR: https://git.openjdk.java.net/jdk/pull/744

From ccheung at openjdk.java.net  Mon Oct 19 18:27:20 2020
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Mon, 19 Oct 2020 18:27:20 GMT
Subject: RFR: 8247666: Support Lambda proxy classes in static CDS archive
 [v9]
In-Reply-To: <2yXKGk7mfEX6pR2AfBxq4eFs821CVYrxSBe_Wy3i2_A=.d3220e17-317a-4c05-a1e5-300ef460ff23@github.com>
References: <ynh4JzHY75GjEn5_oCtmRNy9HMFsU34O2PlhSwD41tU=.1a3770f9-9091-429f-8d03-31b826f9b093@github.com>
 <puhJ2MtsfhHHloI807LpDD0dX0AJBxG1lIAkVQTstWQ=.fe4f15f2-b12d-4fc2-a835-fb94128adecb@github.com>
 <2yXKGk7mfEX6pR2AfBxq4eFs821CVYrxSBe_Wy3i2_A=.d3220e17-317a-4c05-a1e5-300ef460ff23@github.com>
Message-ID: <HruJ3CyqSpeMMy93vw5A1a2uLyqX3FHdoid1y-qpG4M=.61b21c90-ef60-4019-8ba0-193dfc105a9b@github.com>

On Mon, 19 Oct 2020 16:56:19 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   store symbolic name of ref kind (e.g. REF_invokeStatic) in classlist
>
> LGTM

@iklam and @mlchung, thanks again for the review and discussions.

-------------

PR: https://git.openjdk.java.net/jdk/pull/364

From rriggs at openjdk.java.net  Mon Oct 19 18:28:20 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Mon, 19 Oct 2020 18:28:20 GMT
Subject: RFR: 8251989: Hex formatting and parsing utility [v5]
In-Reply-To: <bGQJd6w1ihLR_9NRFcUHYivdy3hDuj1KqhT_76bUC2I=.aecf0e03-6103-4401-b23f-a55627660353@github.com>
References: <HSEn47GMS1K3g57mrTZeQk-WZHl3pKGHpX_OOf8VnsU=.740863c2-f9e4-43c4-b500-614aab4078b1@github.com>
 <-Y_CD_hhxBgqmlaQnSxkXPh_88f03wak3HIb1IgnfNY=.ec1f8832-ddbc-4ccd-8b09-08ee8da3f8bd@github.com>
 <bGQJd6w1ihLR_9NRFcUHYivdy3hDuj1KqhT_76bUC2I=.aecf0e03-6103-4401-b23f-a55627660353@github.com>
Message-ID: <AzKr2le555LOrJXP1LM42UTEMzAovmk5GeCVE6ZdlyU=.017fc1c3-db37-430f-bf53-721486cba316@github.com>

On Mon, 19 Oct 2020 16:35:19 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev
>> excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since
>> the last revision:
>>  - Merge branch 'master' into 8251989-hex-formatter
>>  - Test enhancements from Chris Hegarty
>>  - Expanded test coverage and fixed related bugs; Added static imports for TestNG; Corrected declaration of return type of
>>    tohexDigits(Appendable...)
>>  - Merge branch 'master' into 8251989-hex-formatter
>>  - Cleanup of javadoc markup
>>  - Added assertions to testVariableLength and samples
>>  - Merge branch 'master' into 8251989-hex-formatter
>>  - temp updates
>>  - Various code review comments, rename UpperCase and LowerCase methods to match Character, remove unnecessary Class name
>>    qualifications, etc.
>>  - 8251989: Hex formatting and parsing utility
>
> src/java.base/share/classes/java/util/HexFormat.java line 332:
> 
>> 330:         if (s == null) {
>> 331:             StringBuilder sb = new StringBuilder(length *
>> 332:                     (delimiter.length() + prefix.length() + suffix.length()) - delimiter.length());
> 
> should that be:
> length * (delimiter.length() + prefix.length() + suffix.length() + 2) - delimiter.length());
> It seems to me that otherwise, if you have no delimiter, no prefix, and no suffix, then your computed size will be 0,
> which seems wrong.

Agreed, will fix.

> src/java.base/share/classes/java/util/HexFormat.java line 569:
> 
>> 567:         }
>> 568:         for (int i = 0; i < literal.length(); i++) {
>> 569:             if (string.charAt(index + i) != literal.charAt(i)) {
> 
> There should probably be a check to verify that `string` contains at least `index + literal.length()` characters.
> Otherwise AIOBE might be thrown by `string.charAt(index + i)` ?

The method is only called when the precondition `index + literal.length() <= string.length()`.
I'll add a comment and an assert.

-------------

PR: https://git.openjdk.java.net/jdk/pull/482

From bpb at openjdk.java.net  Mon Oct 19 18:31:15 2020
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Mon, 19 Oct 2020 18:31:15 GMT
Subject: RFR: 8255016: ConstantDescs.FALSE claims it represents TRUE
In-Reply-To: <ioNtsEkS1sqKPpQ10D7APg8upnk-JmNK5Moj3M6tW5A=.32667e56-b15c-4159-993c-6e96eb424d78@github.com>
References: <ioNtsEkS1sqKPpQ10D7APg8upnk-JmNK5Moj3M6tW5A=.32667e56-b15c-4159-993c-6e96eb424d78@github.com>
Message-ID: <G5QDgERBTWnqlNfzhGF9VP2VNiHNfTnx7vq1UhiQi6A=.41f6428e-7ad8-4165-8052-10490b04650b@github.com>

On Mon, 19 Oct 2020 18:08:28 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> This is a fix for "just a typo" or copy/paste error, but it probably requires a CSR since it changes a normative
> portion of the spec.

Looks OK.

-------------

PR: https://git.openjdk.java.net/jdk/pull/744

From ccheung at openjdk.java.net  Mon Oct 19 18:34:15 2020
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Mon, 19 Oct 2020 18:34:15 GMT
Subject: Integrated: 8247666: Support Lambda proxy classes in static CDS
 archive
In-Reply-To: <ynh4JzHY75GjEn5_oCtmRNy9HMFsU34O2PlhSwD41tU=.1a3770f9-9091-429f-8d03-31b826f9b093@github.com>
References: <ynh4JzHY75GjEn5_oCtmRNy9HMFsU34O2PlhSwD41tU=.1a3770f9-9091-429f-8d03-31b826f9b093@github.com>
Message-ID: <QKZpSaHFvDAhz7Ho9VAhuxatwgwWGcEyp9I20KgrA_0=.623c43be-163a-467b-8273-d7693d94213f@github.com>

On Fri, 25 Sep 2020 17:52:24 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> Following up on archiving lambda proxy classes in dynamic CDS archive
> ([JDK-8198698](https://bugs.openjdk.java.net/browse/JDK-8198698)), this RFE adds the functionality of archiving of
> lambda proxy classes in static CDS archive.
> When the -XX:DumpLoadedClassList is enabled, the constant pool index related to LambdaMetafactory that are resolved
> during application execution will be included in the classlist. The entry for a lambda proxy class in a class list will
> be of the following format:
> `@lambda-proxy: <classname> <cp index>`
> 
> e.g.
> `@lambda-proxy: test/java/lang/invoke/MethodHandlesGeneralTest 233`
> `@lambda-proxy: test/java/lang/invoke/MethodHandlesGeneralTest 355`
> 
> When dumping a CDS archive using the -Xshare:dump and -XX:ExtraSharedClassListFile options, when the above
> `@lambda-proxy` entry is encountered while parsing the classlist, we will resolve the corresponding constant pool
> indices (233 and 355 in the above example). As a result, lambda proxy classes will be generated for the constant pool
> entries, and will be cached using a similar mechanism to JDK-8198698.  During dumping, there is check on the cp index
> and on the created BootstrapInfo using the cp index. VM will exit with an error message if the check has failed.
> During runtime when looking up a lambda proxy class, the lookup will be perform on the static CDS archive and if not
> found, then lookup from the dynamic archive if one is specified.  (Only name change (IsDynamicDumpingEnabled ->
> IsCDSDumpingEnabled) is involved in the core-libs code.)
> Testing: tiers 1,2,3,4.
> 
> Performance results (javac on HelloWorld on linux-x64):
> Results of " perf stat -r 40 bin/javac -J-Xshare:on -J-XX:SharedArchiveFile=javac2.jsa Bench_HelloWorld.java "
>    1:   2228016795  2067752708 (-160264087)      -----    377.760   349.110 (-28.650)      -----
>    2:   2223051476  2063016483 (-160034993)      -----    374.580   350.620 (-23.960)      ----
>    3:   2225908334  2067673847 (-158234487)      -----    375.220   350.990 (-24.230)      ----
>    4:   2225835999  2064596883 (-161239116)      -----    374.670   349.840 (-24.830)      ----
>    5:   2226005510  2061694332 (-164311178)      -----    373.512   351.120 (-22.392)      ----
>    6:   2225574949  2062657482 (-162917467)      -----    374.710   348.380 (-26.330)      -----
>    7:   2224702424  2064634122 (-160068302)      -----    373.670   349.510 (-24.160)      ----
>    8:   2226662277  2066301134 (-160361143)      -----    375.350   349.790 (-25.560)      ----
>    9:   2226761470  2063162795 (-163598675)      -----    374.260   351.290 (-22.970)      ----
>   10:   2230149089  2066203307 (-163945782)      -----    374.760   350.620 (-24.140)      ----
> ============================================================
>         2226266109  2064768307 (-161497801)      -----    374.848   350.126 (-24.722)      ----
> instr delta =   -161497801    -7.2542%
> time  delta =      -24.722 ms -6.5951%

This pull request has now been integrated.

Changeset: 74ac77e2
Author:    Calvin Cheung <ccheung at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/74ac77e2
Stats:     2026 lines in 38 files changed: 1896 ins; 66 del; 64 mod

8247666: Support Lambda proxy classes in static CDS archive

Reviewed-by: iklam, mchung

-------------

PR: https://git.openjdk.java.net/jdk/pull/364

From bpb at openjdk.java.net  Mon Oct 19 18:41:10 2020
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Mon, 19 Oct 2020 18:41:10 GMT
Subject: RFR: 8255016: ConstantDescs.FALSE claims it represents TRUE
In-Reply-To: <ioNtsEkS1sqKPpQ10D7APg8upnk-JmNK5Moj3M6tW5A=.32667e56-b15c-4159-993c-6e96eb424d78@github.com>
References: <ioNtsEkS1sqKPpQ10D7APg8upnk-JmNK5Moj3M6tW5A=.32667e56-b15c-4159-993c-6e96eb424d78@github.com>
Message-ID: <tf1rxLgXbM_VckWW9neC9mR9nf6tgFWg_H2X5HnLE5I=.7089bcf3-e052-4477-ac83-32ba965ced6d@github.com>

On Mon, 19 Oct 2020 18:08:28 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> This is a fix for "just a typo" or copy/paste error, but it probably requires a CSR since it changes a normative
> portion of the spec.

Approved.

-------------

Marked as reviewed by bpb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/744

From rrich at openjdk.java.net  Mon Oct 19 18:48:29 2020
From: rrich at openjdk.java.net (Richard Reingruber)
Date: Mon, 19 Oct 2020 18:48:29 GMT
Subject: RFR: 8227745: Enable Escape Analysis for Better Performance in
 the Presence of JVMTI Agents [v14]
In-Reply-To: <Ll2RereRbuQLgFtIjv9pS92kPvCVuo-BI0cP1zGjVbo=.dad3a33c-0fc3-44fd-810a-f01448cf564c@github.com>
References: <Ll2RereRbuQLgFtIjv9pS92kPvCVuo-BI0cP1zGjVbo=.dad3a33c-0fc3-44fd-810a-f01448cf564c@github.com>
Message-ID: <I9PXV_ClC5ZJmMvTETEMq0SL3P8JCmdD1mHD0Zav6Z8=.8bf18612-19a8-4afb-a0bd-bba4c4964671@github.com>

> Hi,
> 
> this is the continuation of the review of the implementation for:
> 
> https://bugs.openjdk.java.net/browse/JDK-8227745
> https://bugs.openjdk.java.net/browse/JDK-8233915
> 
> It allows for JIT optimizations based on escape analysis even if JVMTI agents acquire capabilities to access references
> to objects that are subject to such optimizations, e.g. scalar replacement. The implementation reverts such
> optimizations just before access very much as when switching from JIT compiled execution to the interpreter, aka
> "deoptimization".  Webrev.8 was the last one before before the transition to Git/Github:
> 
> http://cr.openjdk.java.net/~rrich/webrevs/8227745/webrev.8/
> 
> Thanks, Richard.

Richard Reingruber has updated the pull request with a new target base due to a merge or a rebase. The pull request now
contains 29 commits:

 - Merge branch 'master' into JDK-8227745
 - Removed cross_modify_fence from JT::wait_for_object_deoptimization(). See JDK-8254264.
 - handle_special_runtime_exit_condition(): wait (blocked) for obj. deoptimization _before_ async ex. check.
 - Removed unused parameter from EscapeBarrierSuspendHandshake.
 - Adaptations to JDK-8254263: Remove special_runtime_exit_condition() check from ~ThreadInVMForHandshake()
   
   With JDK-8254263 the special_runtime_exit_condition() check was removed from
   ~ThreadInVMForHandshake() because now a thread never becomes unsafe when
   processing its own handshakes. EscapeBarrier uses handshakes to sync with the
   target thread for object deoptimization so we add a check for object
   deoptimization to ThreadSafepointState::handle_polling_page_exception().
   
   In JavaThread::wait_for_object_deoptimization() we must check
   is_obj_deopt_suspend() again after handshake/safepoint processing because a
   handshake for obj. deopt suspend could have been processed.
 - Adaptions to lazy/concurrent thread stack processing for ZGC (JEP 376)
 - EATests.java improvements
 - Merge branch 'master' into JDK-8227745
 - The constructor of StackFrameStream takes more parameters after JDK-8253180
 - Merge branch 'master' into JDK-8227745
 - ... and 19 more: https://git.openjdk.java.net/jdk/compare/1da28de8...8d09747b

-------------

Changes: https://git.openjdk.java.net/jdk/pull/119/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=119&range=13
  Stats: 5860 lines in 53 files changed: 5642 ins; 116 del; 102 mod
  Patch: https://git.openjdk.java.net/jdk/pull/119.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/119/head:pull/119

PR: https://git.openjdk.java.net/jdk/pull/119

From psandoz at openjdk.java.net  Mon Oct 19 18:52:20 2020
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Mon, 19 Oct 2020 18:52:20 GMT
Subject: RFR: 8255020: Minor updates to docs jdk.incubator.vector
Message-ID: <7RW0iLu-6iYgN9vkSAcc5LroxcSyfNfTaHzUHCdBQJ4=.c434b413-c040-4bff-bc6f-1e12f9458db3@github.com>

Minor updates, with no specification changes, to the documentation of Vector API.

The compilation of the Vector module was updated to turn on doclint errors for >= protected documentation.

-------------

Commit messages:
 - 8255020:Minor updates to docs jdk.incubator.vector

Changes: https://git.openjdk.java.net/jdk/pull/746/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=746&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8255020
  Stats: 24 lines in 4 files changed: 15 ins; 0 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/746.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/746/head:pull/746

PR: https://git.openjdk.java.net/jdk/pull/746

From kravikumar at openjdk.java.net  Mon Oct 19 18:54:16 2020
From: kravikumar at openjdk.java.net (Kiran Sidhartha Ravikumar)
Date: Mon, 19 Oct 2020 18:54:16 GMT
Subject: RFR: 8254982: (tz) Upgrade time-zone data to tzdata2020c
Message-ID: <rQR51lGOpSaH5qywIqXV9ymJ36TbsUYzcurNCsvZ7OE=.21381473-7776-4ea5-8a03-734e1b3b11d9@github.com>

Hi Guys,

Please review the integration of tzdata2020c to JDK.

Details regarding the change can be viewed at - https://mm.icann.org/pipermail/tz-announce/2020-October/000060.html
Bug: https://bugs.openjdk.java.net/browse/JDK-8254982

Along with it, there is a test fix for https://bugs.openjdk.java.net/browse/JDK-8254865, With tzdata2020b, the test
fails for the mentioned zones expecting "PST" but JDK has Zone names for "MST" for JRE locale provider. Since the
purpose of the test is to get any GMT-08:00 time zone, I have excluded those zones from the test.

Please let me know if the changes are good to push.

Thanks,
Kiran

-------------

Commit messages:
 - 8254982: (tz) Upgrade time-zone data to tzdata2020c

Changes: https://git.openjdk.java.net/jdk/pull/747/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=747&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8254982
  Stats: 30 lines in 4 files changed: 27 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/747.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/747/head:pull/747

PR: https://git.openjdk.java.net/jdk/pull/747

From jvernee at openjdk.java.net  Mon Oct 19 18:59:20 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Mon, 19 Oct 2020 18:59:20 GMT
Subject: RFR: 8255016: ConstantDescs.FALSE claims it represents TRUE
In-Reply-To: <ioNtsEkS1sqKPpQ10D7APg8upnk-JmNK5Moj3M6tW5A=.32667e56-b15c-4159-993c-6e96eb424d78@github.com>
References: <ioNtsEkS1sqKPpQ10D7APg8upnk-JmNK5Moj3M6tW5A=.32667e56-b15c-4159-993c-6e96eb424d78@github.com>
Message-ID: <Mwd5tbKdfBDliDZ1mR0AItBkHS_gb8ZRv78T0wY_X08=.09c67126-4425-48f4-b99b-4e5ba0afe8ca@github.com>

On Mon, 19 Oct 2020 18:08:28 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> This is a fix for "just a typo" or copy/paste error, but it probably requires a CSR since it changes a normative
> portion of the spec.

Looks good, though I'm not a Reviewer?, I'm the one who introduced this code. It is indeed a typo. Thanks for fixing!

-------------

Marked as reviewed by jvernee (Committer).

PR: https://git.openjdk.java.net/jdk/pull/744

From erikj at openjdk.java.net  Mon Oct 19 19:01:15 2020
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Mon, 19 Oct 2020 19:01:15 GMT
Subject: RFR: 8255020: Minor updates to docs jdk.incubator.vector
In-Reply-To: <7RW0iLu-6iYgN9vkSAcc5LroxcSyfNfTaHzUHCdBQJ4=.c434b413-c040-4bff-bc6f-1e12f9458db3@github.com>
References: <7RW0iLu-6iYgN9vkSAcc5LroxcSyfNfTaHzUHCdBQJ4=.c434b413-c040-4bff-bc6f-1e12f9458db3@github.com>
Message-ID: <A1oBBmnzbvjKBW7RvuNQSY06fZwnbCyJuyC0a9mySyQ=.d0dfa16f-31c7-41fb-83aa-b65402cd0ef9@github.com>

On Mon, 19 Oct 2020 18:41:31 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> Minor updates, with no specification changes, to the documentation of Vector API.
> 
> The compilation of the Vector module was updated to turn on doclint errors for >= protected documentation.

Build change looks ok.

-------------

Marked as reviewed by erikj (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/746

From erikj at openjdk.java.net  Mon Oct 19 19:02:13 2020
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Mon, 19 Oct 2020 19:02:13 GMT
Subject: RFR: 8254982: (tz) Upgrade time-zone data to tzdata2020c
In-Reply-To: <rQR51lGOpSaH5qywIqXV9ymJ36TbsUYzcurNCsvZ7OE=.21381473-7776-4ea5-8a03-734e1b3b11d9@github.com>
References: <rQR51lGOpSaH5qywIqXV9ymJ36TbsUYzcurNCsvZ7OE=.21381473-7776-4ea5-8a03-734e1b3b11d9@github.com>
Message-ID: <svjctHrsWeWeRI1xF1reU5VxO2tGEdHsEzB1b_iuNZk=.21f03395-9be3-494c-8346-6887b8d65fbe@github.com>

On Mon, 19 Oct 2020 18:44:28 GMT, Kiran Sidhartha Ravikumar <kravikumar at openjdk.org> wrote:

> Hi Guys,
> 
> Please review the integration of tzdata2020c to JDK.
> 
> Details regarding the change can be viewed at - https://mm.icann.org/pipermail/tz-announce/2020-October/000060.html
> Bug: https://bugs.openjdk.java.net/browse/JDK-8254982
> 
> Along with it, there is a test fix for https://bugs.openjdk.java.net/browse/JDK-8254865, With tzdata2020b, the test
> fails for the mentioned zones expecting "PST" but JDK has Zone names for "MST" for JRE locale provider. Since the
> purpose of the test is to get any GMT-08:00 time zone, I have excluded those zones from the test.  Please let me know
> if the changes are good to push.
> Thanks,
> Kiran

Build change looks ok.

-------------

Marked as reviewed by erikj (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/747

From mchung at openjdk.java.net  Mon Oct 19 19:07:15 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Mon, 19 Oct 2020 19:07:15 GMT
Subject: RFR: 8255016: ConstantDescs.FALSE claims it represents TRUE
In-Reply-To: <ioNtsEkS1sqKPpQ10D7APg8upnk-JmNK5Moj3M6tW5A=.32667e56-b15c-4159-993c-6e96eb424d78@github.com>
References: <ioNtsEkS1sqKPpQ10D7APg8upnk-JmNK5Moj3M6tW5A=.32667e56-b15c-4159-993c-6e96eb424d78@github.com>
Message-ID: <wdr-JLLu9wHtN4UvBlzeNkLYmeFzJ-AGdKBK1Y80K0w=.dc566495-360d-4c51-93ee-03b764e67b73@github.com>

On Mon, 19 Oct 2020 18:08:28 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> This is a fix for "just a typo" or copy/paste error, but it probably requires a CSR since it changes a normative
> portion of the spec.

+1

-------------

Marked as reviewed by mchung (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/744

From rriggs at openjdk.java.net  Mon Oct 19 19:16:17 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Mon, 19 Oct 2020 19:16:17 GMT
Subject: RFR: 8255016: ConstantDescs.FALSE claims it represents TRUE
In-Reply-To: <ioNtsEkS1sqKPpQ10D7APg8upnk-JmNK5Moj3M6tW5A=.32667e56-b15c-4159-993c-6e96eb424d78@github.com>
References: <ioNtsEkS1sqKPpQ10D7APg8upnk-JmNK5Moj3M6tW5A=.32667e56-b15c-4159-993c-6e96eb424d78@github.com>
Message-ID: <wlrNieEp2RqV_9BU3vm8OpO0jhrsPesjuM807qwVmpM=.87adac76-c87a-4b26-9dbd-85295c9f6c90@github.com>

On Mon, 19 Oct 2020 18:08:28 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> This is a fix for "just a typo" or copy/paste error, but it probably requires a CSR since it changes a normative
> portion of the spec.

Marked as reviewed by rriggs (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/744

From rrich at openjdk.java.net  Mon Oct 19 19:41:14 2020
From: rrich at openjdk.java.net (Richard Reingruber)
Date: Mon, 19 Oct 2020 19:41:14 GMT
Subject: RFR: 8227745: Enable Escape Analysis for Better Performance in
 the Presence of JVMTI Agents [v10]
In-Reply-To: <PrlpMaxn0QM4FaL46JOMJQ_kyHQb7Qc6wOvY48BXrG0=.c813267c-53e9-486c-ade2-8017d820c579@github.com>
References: <Ll2RereRbuQLgFtIjv9pS92kPvCVuo-BI0cP1zGjVbo=.dad3a33c-0fc3-44fd-810a-f01448cf564c@github.com>
 <XaPrmpfi96mMRQnto6zzZlsZeDP0jMR7LAosjDmm0Zw=.12c89fb1-a267-468b-966b-065f97aa2f28@github.com>
 <buqJ9cqD9APRW862aGoAk9IyvYvshoItGVRgeNqQTds=.4fc25be1-3e79-4ac8-a174-0e08cdc9fc10@github.com>
 <PrlpMaxn0QM4FaL46JOMJQ_kyHQb7Qc6wOvY48BXrG0=.c813267c-53e9-486c-ade2-8017d820c579@github.com>
Message-ID: <hR2hoa3_hcnnNga3WttyP6swYGpNTdZmI2FRdJbwJrM=.9d133715-8a0b-47a6-a890-1be3a92f8876@github.com>

On Wed, 14 Oct 2020 20:50:45 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> Good.
>
>> 
>> 
>> Good.
> 
> Thanks for the review, Vladimir (@vnkozlov)!
> I'm still (stress) testing adaptations to lazy/concurrent thread stack processing for ZGC.
> --Richard.

Thanks once more @TheRealMDoerr,  @GoeLin, @dholmes-ora, @sspitsyn, @vnkozlov, @robehn, @pchilano for feedback and
reviews.

-------------

PR: https://git.openjdk.java.net/jdk/pull/119

From naoto at openjdk.java.net  Mon Oct 19 19:43:20 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 19 Oct 2020 19:43:20 GMT
Subject: RFR: 8254982: (tz) Upgrade time-zone data to tzdata2020c
In-Reply-To: <rQR51lGOpSaH5qywIqXV9ymJ36TbsUYzcurNCsvZ7OE=.21381473-7776-4ea5-8a03-734e1b3b11d9@github.com>
References: <rQR51lGOpSaH5qywIqXV9ymJ36TbsUYzcurNCsvZ7OE=.21381473-7776-4ea5-8a03-734e1b3b11d9@github.com>
Message-ID: <HyFEzz92nHPAazgKRXaCos1D4SBF4XVwQSy-MwXlALs=.9c93b278-49cc-4b8e-bd59-184c8983d000@github.com>

On Mon, 19 Oct 2020 18:44:28 GMT, Kiran Sidhartha Ravikumar <kravikumar at openjdk.org> wrote:

> Hi Guys,
> 
> Please review the integration of tzdata2020c to JDK.
> 
> Details regarding the change can be viewed at - https://mm.icann.org/pipermail/tz-announce/2020-October/000060.html
> Bug: https://bugs.openjdk.java.net/browse/JDK-8254982
> 
> Along with it, there is a test fix for https://bugs.openjdk.java.net/browse/JDK-8254865, With tzdata2020b, the test
> fails for the mentioned zones expecting "PST" but JDK has Zone names for "MST" for JRE locale provider. Since the
> purpose of the test is to get any GMT-08:00 time zone, I have excluded those zones from the test.  Please let me know
> if the changes are good to push.
> Thanks,
> Kiran

test/jdk/java/util/Formatter/BasicDateTime.java line 1695:

> 1693:         list.remove("America/Dawson");
> 1694:         list.remove("America/WhiteHorse");
> 1695:         list.remove("Canada/Yukon");

I'd explicitly mention why these time zones are removed from the test.

-------------

PR: https://git.openjdk.java.net/jdk/pull/747

From darcy at openjdk.java.net  Mon Oct 19 19:52:10 2020
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 19 Oct 2020 19:52:10 GMT
Subject: RFR: 8255020: Minor updates to docs jdk.incubator.vector
In-Reply-To: <7RW0iLu-6iYgN9vkSAcc5LroxcSyfNfTaHzUHCdBQJ4=.c434b413-c040-4bff-bc6f-1e12f9458db3@github.com>
References: <7RW0iLu-6iYgN9vkSAcc5LroxcSyfNfTaHzUHCdBQJ4=.c434b413-c040-4bff-bc6f-1e12f9458db3@github.com>
Message-ID: <oyoBhjDgfAnFfNuouaBaVg-6KWrUPNXO037s1DgLeeI=.21d7c2fb-64b0-49e3-afbe-8dbba9b536a2@github.com>

On Mon, 19 Oct 2020 18:41:31 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> Minor updates, with no specification changes, to the documentation of Vector API.
> 
> The compilation of the Vector module was updated to turn on doclint errors for >= protected documentation.

Marked as reviewed by darcy (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/746

From psandoz at openjdk.java.net  Mon Oct 19 20:07:22 2020
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Mon, 19 Oct 2020 20:07:22 GMT
Subject: RFR: 8255022: Documentation missing for Vector API zero methods
Message-ID: <WKOOZsYoqfzmWyAfFbtHKUYgxax7JsQi3bn7IZ-R3D0=.76ad983a-e525-4f8c-a293-0ef3b4b7a987@github.com>

The zero methods on `IntVector` and all other specializations are missing documentation.

-------------

Commit messages:
 - 8255022: Documentation missing for Vector API zero methods

Changes: https://git.openjdk.java.net/jdk/pull/748/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=748&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8255022
  Stats: 42 lines in 7 files changed: 35 ins; 0 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/748.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/748/head:pull/748

PR: https://git.openjdk.java.net/jdk/pull/748

From kvn at openjdk.java.net  Mon Oct 19 20:29:18 2020
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Mon, 19 Oct 2020 20:29:18 GMT
Subject: RFR: 8252204: AArch64: Implement SHA3 accelerator/intrinsic [v9]
In-Reply-To: <tk-ljSMdkVcSl3FVQkWxQ66tX2e8Fpv96NUlr1iBgTA=.f6734f3c-74db-4f22-8754-974ba665e8b7@github.com>
References: <PJVtIubjiGKhCK81PIMhWuYxnR84DNieMDUGHdhHYZM=.ad903c93-c5e3-4614-9af1-d36bc33f735d@github.com>
 <tk-ljSMdkVcSl3FVQkWxQ66tX2e8Fpv96NUlr1iBgTA=.f6734f3c-74db-4f22-8754-974ba665e8b7@github.com>
Message-ID: <IEAI7ydU-L-aY41FOEjkKDcYWaPO6j4XyQPx1g7ba0E=.b2fe738c-3140-48a3-8cf6-da1dac0200ba@github.com>

On Mon, 19 Oct 2020 11:14:22 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Contributed-by: ard.biesheuvel at linaro.org, dongbo4 at huawei.com
>> 
>> This added an intrinsic for SHA3 using aarch64 v8.2 SHA3 Crypto Extensions.
>> Reference implementation for core SHA-3 transform using ARMv8.2 Crypto Extensions:
>> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm64/crypto/sha3-ce-core.S?h=v5.4.52
>> 
>> Trivial adaptation in SHA3. implCompress is needed for the purpose of adding the intrinsic.
>> For SHA3, we need to pass one extra parameter "digestLength" to the stub for the calculation of block size.
>> "digestLength" is also used in for the EOR loop before keccak to differentiate different SHA3 variants.
>> 
>> We added jtreg tests for SHA3 and used QEMU system emulator which supports SHA3 instructions to test the functionality.
>> Patch passed jtreg tier1-3 tests with QEMU system emulator.
>> Also verified with jtreg tier1-3 tests without SHA3 instructions on aarch64-linux-gnu and x86_64-linux-gnu, to make
>> sure that there's no regression.
>> We used one existing JMH test for performance test: test/micro/org/openjdk/bench/java/security/MessageDigests.java
>> We measured the performance benefit with an aarch64 cycle-accurate simulator.
>> Patch delivers 20% - 40% performance improvement depending on specific SHA3 digest length and size of the message.
>> 
>> For now, this feature will not be enabled automatically for aarch64. We can auto-enable this when it is fully tested on
>> real hardware.  But for the above testing purposes, this is auto-enabled when the corresponding hardware feature is
>> detected.
>
> Fei Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains
> 11 commits:
>  - Merge master
>  - Remove unnecessary code changes in vm_version_aarch64.cpp
>  - Merge master
>  - Merge master
>  - Merge master
>  - Merge master
>  - Add sha3 instructions to cpu/aarch64/aarch64-asmtest.py and regenerate the test in assembler_aarch64.cpp:asm_check
>  - Rebase
>  - Merge master
>  - Fix trailing whitespace issue
>  - ... and 1 more: https://git.openjdk.java.net/jdk/compare/e9be2db7...05551701

Always run graalunit testing with new intrinsics. You need to adjust Graal test:
src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/CheckGraalIntrinsics.java

-------------

Changes requested by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/207

From psandoz at openjdk.java.net  Mon Oct 19 20:41:13 2020
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Mon, 19 Oct 2020 20:41:13 GMT
Subject: Integrated: 8255020: Minor updates to docs jdk.incubator.vector
In-Reply-To: <7RW0iLu-6iYgN9vkSAcc5LroxcSyfNfTaHzUHCdBQJ4=.c434b413-c040-4bff-bc6f-1e12f9458db3@github.com>
References: <7RW0iLu-6iYgN9vkSAcc5LroxcSyfNfTaHzUHCdBQJ4=.c434b413-c040-4bff-bc6f-1e12f9458db3@github.com>
Message-ID: <f7M_8wLTtF3WhHCvaOCHf1JcGI4rhE0psh2BthxZIew=.578dfbc9-267a-47e7-b2ee-3b43288bd722@github.com>

On Mon, 19 Oct 2020 18:41:31 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> Minor updates, with no specification changes, to the documentation of Vector API.
> 
> The compilation of the Vector module was updated to turn on doclint errors for >= protected documentation.

This pull request has now been integrated.

Changeset: 00014350
Author:    Paul Sandoz <psandoz at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/00014350
Stats:     24 lines in 4 files changed: 15 ins; 0 del; 9 mod

8255020: Minor updates to docs jdk.incubator.vector

Reviewed-by: erikj, darcy

-------------

PR: https://git.openjdk.java.net/jdk/pull/746

From david.holmes at oracle.com  Mon Oct 19 21:52:19 2020
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 20 Oct 2020 07:52:19 +1000
Subject: RFR: 8188055: (ref) Add Reference::refersTo predicate [v5]
In-Reply-To: <DEA2CA91-03D4-4EB0-97ED-860D0CC51114@oracle.com>
References: <D4HSg8FT20Eaxk5KJkkw0GgETSxRkBn1ipS3Dt0kPto=.e4bab078-2e04-4413-90cb-9bfafb2a6831@github.com>
 <FHx-oBhE254DZWHhg2RTKjZn_-yYN5xadTW7GXhTxzM=.7e6a46fa-5259-428c-b725-81b4fe48b8f7@github.com>
 <3L0hT4NZvzC8V2D7WfDFdv1T7FRdTPMPOWWGnHoKxB0=.3f962415-7d0d-40ae-b5ed-a0a1f9da11be@github.com>
 <VZRnbCYjfDq8Bo94vjB9jJKt4_tDFelcEHNiOB4VHuM=.023edb69-a402-44c9-904c-bda9a8349263@github.com>
 <5f8f5c3c-6c1a-a426-b2d4-df94885e76cc@oracle.com>
 <DEA2CA91-03D4-4EB0-97ED-860D0CC51114@oracle.com>
Message-ID: <f3ee37a4-f8f8-e9f6-3022-6f3ac94ecb88@oracle.com>

Hi Kim,

On 19/10/2020 9:29 pm, Kim Barrett wrote:
>> On Oct 18, 2020, at 5:36 PM, David Holmes <david.holmes at oracle.com> wrote:
>>
>> On 17/10/2020 1:23 am, Kim Barrett wrote:
>>>> src/java.base/share/classes/java/lang/ref/Reference.java line 348:
>>>>
>>>>> 346:      * Tests if this reference object refers to {@code obj}.  If {@code obj} is
>>>>> 347:      * {@code null}, this method returns {@code true} if this reference object
>>>>> 348:      * refers to {@code null} or has been cleared.
>>>>
>>>> Is there actually a distinction between clearing and referring to null?
>>> A (not very useful) Reference can be created with a null referent.
>>
>> Yes but you cannot distinguish between the two cases yet this wording is trying to make that distinction. My concern is interaction with the wording here:
>>
>>   * @return  {@code true} if and only if {@code obj} is the referent
>>   *          of this reference object
>>
>> As written it implies to me that given:
>>
>> Object o = new Object();
>> PhantomReference r = new PhantomReference(o);
>> r.clear();
>> assert(r.refersTo(null)); // pass or fail?
>>
>> then the assert should fail because "null" was not the referent, as r has been cleared - which are two distinct cases according to the initial java doc. The initial doc would be clearer if it stated words to the effect of:
>>
>> "returns {@code true} if this reference object refers to {@code null} (either because it was constructed that way, or it has been cleared)."
>>
>> or else the @return doc needs to account for the null case more explicitly.
> 
> I don't see how you arrive at the assert failing. The referent is what get
> would return, by definition. And get returns null for a cleared reference.

That's the crux of it: what exactly is meant by "the referent"? Does it 
mean the original object that was used as the referent, or does it mean 
the current value of the "referent" field inside the Reference (as get 
might return)?

> The wording in the initial javadoc is the result of offline requests from
> Mandy from before the first public version.  Before that I had just
> 
> * Tests if {@code obj} is the referent of this reference object.
> 
> My recollection (the discussion is lost - darn slack retention limits) is

I had some input in the early days too, but then missed the CSR and 
related discussion - apologies for that.

> that Mandy felt the reliance on the meaning of "referent" from get was too
> indirect, and that some additional discussion of the null case was needed
> for refersTo. Personally, I'd be happy with deleting that 2nd sentence, and
> even reverting to my original description, but Mandy (and others) might not
> agree.

I think we've ended up with the main doc and the @return being 
inconsistent in that regard. They should either both talk about 
"referent" or both be expressed in terms of "refers to" (the latter more 
clearly indicates we are talking about the value of a field, or what 
get() might return).

> 
> Maybe something like the following?
> 
> * Tests if {@code obj} is the referent of this reference object.
> * If {@code obj} is {@code null}, this method returns {@code true} if
> * this reference object was constructed with a {@code null} referent
> * or has been cleared.

That reads well to me and is more consistent with the @return wording. I 
personally prefer the "refers to" terminology, but either way is fine as 
long as the two parts are consistent.

>> Also why the "if and only if" in the @return doc versus a simple "if"? What is being emphasized by using "if and only if"?
> 
> "if and only if" is the same phrasing used by isEnqueued; I just followed
> that, perhaps overly slavishly.  It seems like that's pretty common usage
> elsewhere too.  But I don't have any objection to removing "and only if" if
> that's what the experts want.  (I'm not really a Java programmer.)

To me the "if and only if" is emphasizing something - it suggests that 
simply using "if" allows a possibility that might be surprising. In this 
case it suggested to me a distinction between being the original (null) 
referent, and just happening to be null due to clearing (in part because 
the main doc comment seemed to be making that distinction).

Specs are tricky and it can get quite pedantic and finicky. Someone, at 
some point will be given this API description and asked to write 
conformance tests, so it needs to be clear and unambiguous.

Hopefully Mandy will re-engage on this aspect.

Just to be clear, the current wording is not terrible, I'm just looking 
at potential improvement.

Thanks,
David
-----

> 

From mathias.ricken at oracle.com  Mon Oct 19 22:43:56 2020
From: mathias.ricken at oracle.com (Mathias Ricken)
Date: Mon, 19 Oct 2020 15:43:56 -0700
Subject: Question about InputStream.reset Contract and Behavior
Message-ID: <CE96B27C-40CA-46AF-8E56-948BDB1F64C7@oracle.com>

Hi,

 

My team at OCI is trying to correctly implement retries for stream uploads, and we?ve come across the following comment in InputStream.reset():

 

https://docs.oracle.com/javase/7/docs/api/java/io/InputStream.html#reset()

 

If the method markSupported returns true, then: 

?         If the method mark has not been called since the stream was created, or the number of bytes read from the stream since mark was last called is larger than the argument to mark at that last call, then an IOException might be thrown. 

?         If such an IOException is not thrown, then the stream is reset to a state such that all the bytes read since the most recent call to mark (or since the start of the file, if mark has not been called) will be resupplied to subsequent callers of the read method, followed by any bytes that otherwise would have been the next input data as of the time of the call to reset. 

 

(emphasis mine)

 
We would like to know if not getting an IOException guarantees that the stream was successfully reset (as the 2nd bullet point implies).
That probably leads to this interpretation of the ?might?: There are situations where (1) mark was called, (2) more bytes were read from the stream than the argument to mark, meaning (3) it wasn?t guaranteed that the stream could be correctly reset, but (4) the stream was in fact reset successfully, and that?s why no IOException was thrown (which is one interpretation of the ?might? in the first bullet point).
Or is there a case in which (1) mark was called, (2) more bytes were read from the stream than the argument to mark, meaning (3) the stream could not be correctly reset, but (4) no IOException is thrown (which is another interpretation of the ?might? in the first bullet point).
 

I understand that this is a publicly-extendable class, so there might be bad implementations. But what was the intention, and what do official Oracle implementations of InputStream do?

 

We need to understand the contract in order to implement a correctly behaving stream retry mechanism, or to at least fail visibly (a silent failure as (2) above would make possible could lead to silent data corruption).

 

Thanks for your help.

 

Mathias Ricken

Consultant Member of Technical Staff

Oracle Cloud Infrastructure


From rriggs at openjdk.java.net  Mon Oct 19 22:52:31 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Mon, 19 Oct 2020 22:52:31 GMT
Subject: RFR: 8251989: Hex formatting and parsing utility [v6]
In-Reply-To: <HSEn47GMS1K3g57mrTZeQk-WZHl3pKGHpX_OOf8VnsU=.740863c2-f9e4-43c4-b500-614aab4078b1@github.com>
References: <HSEn47GMS1K3g57mrTZeQk-WZHl3pKGHpX_OOf8VnsU=.740863c2-f9e4-43c4-b500-614aab4078b1@github.com>
Message-ID: <seKMG87WLCuFuqEZuua-7hrmYxXeSYsoFATrMAqZMs4=.b4d97cb5-d84a-427c-9994-9292fa127e35@github.com>

> java.util.HexFormat utility:
> 
>  - Format and parse hexadecimal strings, with parameters for delimiter, prefix, suffix and upper/lowercase
>  - Static factories and builder methods to create HexFormat copies with modified parameters.
>  - Consistent naming of methods for conversion of byte arrays to formatted strings and back: formatHex and parseHex
>  - Consistent naming of methods for conversion of primitive types: toHexDigits... and fromHexDigits...
>  - Prefix and suffixes now apply to each formatted value, not the string as a whole
>  - Using java.util.Appendable as a target for buffered conversions so output to Writers and PrintStreams
>    like System.out are supported in addition to StringBuilder. (IOExceptions are converted to unchecked exceptions)
>  - Immutable and thread safe, a "value-based" class
> 
> See the [HexFormat
> javadoc](http://cr.openjdk.java.net/~rriggs/8251989-hex-formatter/java.base/java/util/HexFormat.html) for details.
> Review comments and suggestions welcome.

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Correct length of StringBuilder in formatHex;
  Correct bug in formatHex(char[], 2, 3) and add test for subranges of char[]

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/482/files
  - new: https://git.openjdk.java.net/jdk/pull/482/files/d9f2b6e4..1d2c26f2

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=482&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=482&range=04-05

  Stats: 28 lines in 2 files changed: 26 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/482.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/482/head:pull/482

PR: https://git.openjdk.java.net/jdk/pull/482

From mchung at openjdk.java.net  Mon Oct 19 23:13:21 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Mon, 19 Oct 2020 23:13:21 GMT
Subject: RFR: 8188055: (ref) Add Reference::refersTo predicate [v5]
In-Reply-To: <Ch2xqBrcg76WqiK0RVUEl_XcN4o7X4bvo44RPDDi3O8=.852fb1b6-77f5-4aaa-9ed6-bdee28ec8eb3@github.com>
References: <D4HSg8FT20Eaxk5KJkkw0GgETSxRkBn1ipS3Dt0kPto=.e4bab078-2e04-4413-90cb-9bfafb2a6831@github.com>
 <FHx-oBhE254DZWHhg2RTKjZn_-yYN5xadTW7GXhTxzM=.7e6a46fa-5259-428c-b725-81b4fe48b8f7@github.com>
 <Ch2xqBrcg76WqiK0RVUEl_XcN4o7X4bvo44RPDDi3O8=.852fb1b6-77f5-4aaa-9ed6-bdee28ec8eb3@github.com>
Message-ID: <E8OiCIWFPwu7ircN0UQiSG8yJ2QrbFNdYT_MHLHtKcQ=.85cd2acb-d656-4398-b7bf-1f2e9cc6bc58@github.com>

On Fri, 16 Oct 2020 17:04:51 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev
>> excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since
>> the last revision:
>>  - Merge branch 'master' into refersto
>>  - More explicit refersTo0 comment.
>>  - simplify test
>>  - cleanup nits from Mandy
>>  - use Object instead of TestObject
>>  - improve refersTo0 descriptions
>>  - basic functional test
>>  - change referent access
>>  - expand test
>>  - remove CMS comment
>>  - ... and 1 more: https://git.openjdk.java.net/jdk/compare/6bb7151b...ab4e519b
>
> Looks good.

> That's the crux of it: what exactly is meant by "the referent"? Does it
> mean the original object that was used as the referent, or does it mean
> the current value of the "referent" field inside the Reference (as get
> might return)?

"the referent" is the object a `Reference` object refers to.

as it's described in java.lang.ref package description:

> Each reference-object type is implemented by a subclass of the abstract base Reference class. An instance of one of
> these subclasses encapsulates a single reference to a particular object, called the referent.

See also `@return` in `Reference::get`:
> @return The object to which this reference refers, or null if this reference object has been cleared

-------------

PR: https://git.openjdk.java.net/jdk/pull/498

From mchung at openjdk.java.net  Mon Oct 19 23:20:14 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Mon, 19 Oct 2020 23:20:14 GMT
Subject: RFR: 8188055: (ref) Add Reference::refersTo predicate [v5]
In-Reply-To: <E8OiCIWFPwu7ircN0UQiSG8yJ2QrbFNdYT_MHLHtKcQ=.85cd2acb-d656-4398-b7bf-1f2e9cc6bc58@github.com>
References: <D4HSg8FT20Eaxk5KJkkw0GgETSxRkBn1ipS3Dt0kPto=.e4bab078-2e04-4413-90cb-9bfafb2a6831@github.com>
 <FHx-oBhE254DZWHhg2RTKjZn_-yYN5xadTW7GXhTxzM=.7e6a46fa-5259-428c-b725-81b4fe48b8f7@github.com>
 <Ch2xqBrcg76WqiK0RVUEl_XcN4o7X4bvo44RPDDi3O8=.852fb1b6-77f5-4aaa-9ed6-bdee28ec8eb3@github.com>
 <E8OiCIWFPwu7ircN0UQiSG8yJ2QrbFNdYT_MHLHtKcQ=.85cd2acb-d656-4398-b7bf-1f2e9cc6bc58@github.com>
Message-ID: <rDPsYfi057gmn-cIG04-EwHqFKj2vST5h-_PsJpnFj4=.0ecbdd68-329b-4376-a7ea-1be23206aa9b@github.com>

On Mon, 19 Oct 2020 23:10:23 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Looks good.
>
>> That's the crux of it: what exactly is meant by "the referent"? Does it
>> mean the original object that was used as the referent, or does it mean
>> the current value of the "referent" field inside the Reference (as get
>> might return)?
> 
> "the referent" is the object a `Reference` object refers to.
> 
> as it's described in java.lang.ref package description:
> 
>> Each reference-object type is implemented by a subclass of the abstract base Reference class. An instance of one of
>> these subclasses encapsulates a single reference to a particular object, called the referent.
> 
> See also `@return` in `Reference::get`:
>> @return The object to which this reference refers, or null if this reference object has been cleared

I also personally prefer to use the "refers to" wording in the specification as well (IIRC I suggested that wordings).
What about:

* Tests if this reference object refers to {@code obj}.
* If {@code obj} is {@code null}, this method returns {@code true} if
* this reference object was constructed with a {@code null} referent
* or has been cleared.
and
@return {@code true} if {@code obj} is the object to which this reference refers,
              or if {@code obj} is {@code null} and this reference has been cleared.

-------------

PR: https://git.openjdk.java.net/jdk/pull/498

From smarks at openjdk.java.net  Mon Oct 19 23:56:10 2020
From: smarks at openjdk.java.net (Stuart Marks)
Date: Mon, 19 Oct 2020 23:56:10 GMT
Subject: Integrated: 8255016: ConstantDescs.FALSE claims it represents TRUE
In-Reply-To: <ioNtsEkS1sqKPpQ10D7APg8upnk-JmNK5Moj3M6tW5A=.32667e56-b15c-4159-993c-6e96eb424d78@github.com>
References: <ioNtsEkS1sqKPpQ10D7APg8upnk-JmNK5Moj3M6tW5A=.32667e56-b15c-4159-993c-6e96eb424d78@github.com>
Message-ID: <CLvY1bHq6y1cj1YjkNn_xPaRQKT-qDqjUTfWhklTaGM=.dcc67fc8-c11a-4d68-a318-6d2e7ffac98d@github.com>

On Mon, 19 Oct 2020 18:08:28 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> This is a fix for "just a typo" or copy/paste error, but it probably requires a CSR since it changes a normative
> portion of the spec.

This pull request has now been integrated.

Changeset: bf19581a
Author:    Stuart Marks <smarks at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/bf19581a
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8255016: ConstantDescs.FALSE claims it represents TRUE

Reviewed-by: bpb, jvernee, mchung, rriggs

-------------

PR: https://git.openjdk.java.net/jdk/pull/744

From sandhya.viswanathan at intel.com  Tue Oct 20 00:38:24 2020
From: sandhya.viswanathan at intel.com (Viswanathan, Sandhya)
Date: Tue, 20 Oct 2020 00:38:24 +0000
Subject: Howto replicate failure of 8254790?
In-Reply-To: <efc3cbff-2e42-cf57-c753-f9d30b68d394@oracle.com>
References: <4bd7e9f73ea24ae09f1bb0f1808ce5a7@EX13D46EUB003.ant.amazon.com>
 <661485ab-7de7-26cb-b2b1-3a4f643125eb@oracle.com>
 <617f010e-629d-7329-ac72-dce797bf3075@oracle.com>
 <d6061b53d0854305a1fdb1a5ea7a019c@EX13D46EUB003.ant.amazon.com>
 <efc3cbff-2e42-cf57-c753-f9d30b68d394@oracle.com>
Message-ID: <BYAPR11MB35434D70D8B62F45068ADA7AEF1F0@BYAPR11MB3543.namprd11.prod.outlook.com>

Hi Jason,

I think I found the problem looking at the error log from Vladimir Kozlov. In stringL_indexof_char() function, the following snippet is the cause of problem:

2807   bind(FOUND_CHAR);
2808   if (UseAVX >= 2) {
2809     vpmovmskb(tmp, vec3);
2810   } else {
2811     pmovmskb(tmp, vec3);
2812   }
2813   bsfl(ch, tmp);
2814   addl(result, ch);                         <====   The problem is here
2815
2816   bind(FOUND_SEQ_CHAR);
2817   subptr(result, str1);

The line addl(result, ch) should have been addptr(result, ch).

The same problem exists in the Unicode string index of char intrinsic as well and need to be fixed.

Hope this helps.

Best Regards,
Sandhya

-----Original Message-----
From: hotspot-compiler-dev <hotspot-compiler-dev-retn at openjdk.java.net> On Behalf Of Vladimir Kozlov
Sent: Thursday, October 15, 2020 3:59 PM
To: Tatton, Jason <jptatton at amazon.com>; David Holmes <david.holmes at oracle.com>; hotspot-compiler-dev at openjdk.java.net; core-libs-dev at openjdk.java.net
Subject: Re: Howto replicate failure of 8254790?

Hi Jason,

I added surrounding instructions dump from hs_err file we have so you can reconstruct x86 assembler from it.

If you look on si_addr: 0x00000000e41d2718 which case memory map failure, it looks like R8 =0x00000007e41d2700 is an
oop: [B with upper 32-bits zeroed. It seems uppers 32-bits of address were cut.

But I don't see it can happens in stringL_indexof_char() sub. You correctly used movptr() and addptr() instructions.

Vladimir K

On 10/15/20 2:10 PM, Tatton, Jason wrote:
> Thanks Vladimir and David, I have access to a new macbook with an Intel i7-9750H (supports AVX2) so I will try on that.
> 
> -----Original Message-----
> From: Vladimir Kozlov <vladimir.kozlov at oracle.com>
> Sent: 15 October 2020 20:25
> To: David Holmes <david.holmes at oracle.com>; Tatton, Jason 
> <jptatton at amazon.com>; hotspot-compiler-dev at openjdk.java.net; 
> core-libs-dev at openjdk.java.net
> Subject: RE: [EXTERNAL] Howto replicate failure of 8254790?
> 
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
> 
> 
> 
> Note, we have old Mac machines in our testing env:
> cx8, cmov, fxsr, ht, mmx, 3dnowpref, sse, sse2, sse3, ssse3, sse4.1, 
> sse4.2, popcnt, lzcnt, tsc, tscinvbit, avx, avx2, aes, erms, clmul, 
> bmi1, bmi2, rtm, adx, fma, vzeroupper, clflush, clflushopt
> 
> Use -XX:UseAVX=2
> 
> But I was not able reproduce failure on my Skylake Linux machine even with -XX:UseAVX=2. Maybe there are other factors on MacOS.
> 
> Regards,
> Vladimir K
> 
> On 10/14/20 5:48 PM, David Holmes wrote:
>> Hi Jason,
>>
>> On 15/10/2020 10:42 am, Tatton, Jason wrote:
>>> Hi all,
>>>
>>>
>>>
>>> I am trying to replicate the failure of the tier2 test mentioned in 
>>> 8254790<https://bugs.openjdk.java.net/browse/JDK-8254790> but I am 
>>> only seeing it pass under an x86 linux machine. Are there any specific architectural constraints under which this test should be run in order to make it fail?
>>
>> It failed on a Mac, not Linux.
>>
>> Cheers,
>> David
>>
>>>
>>>
>>> I am running the test via: make test TEST="test/jdk/javax/xml/crypto/dsig/GenerationTests.java"
>>>
>>>
>>>
>>> Note that I am running the test against master without the commit:
>>> "8254792: Disable intrinsic StringLatin1.indexOf until 8254790 is fixed" which disables the intrinsic that is causing the test to fail.
>>>
>>>
>>>
>>> Thanks
>>> --
>>> Jason
>>>

From david.holmes at oracle.com  Tue Oct 20 01:00:41 2020
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 20 Oct 2020 11:00:41 +1000
Subject: RFR: 8188055: (ref) Add Reference::refersTo predicate [v5]
In-Reply-To: <rDPsYfi057gmn-cIG04-EwHqFKj2vST5h-_PsJpnFj4=.0ecbdd68-329b-4376-a7ea-1be23206aa9b@github.com>
References: <D4HSg8FT20Eaxk5KJkkw0GgETSxRkBn1ipS3Dt0kPto=.e4bab078-2e04-4413-90cb-9bfafb2a6831@github.com>
 <FHx-oBhE254DZWHhg2RTKjZn_-yYN5xadTW7GXhTxzM=.7e6a46fa-5259-428c-b725-81b4fe48b8f7@github.com>
 <Ch2xqBrcg76WqiK0RVUEl_XcN4o7X4bvo44RPDDi3O8=.852fb1b6-77f5-4aaa-9ed6-bdee28ec8eb3@github.com>
 <E8OiCIWFPwu7ircN0UQiSG8yJ2QrbFNdYT_MHLHtKcQ=.85cd2acb-d656-4398-b7bf-1f2e9cc6bc58@github.com>
 <rDPsYfi057gmn-cIG04-EwHqFKj2vST5h-_PsJpnFj4=.0ecbdd68-329b-4376-a7ea-1be23206aa9b@github.com>
Message-ID: <616d5507-d220-cb75-76e3-36067818eafe@oracle.com>

Hi Mandy,

On 20/10/2020 9:20 am, Mandy Chung wrote:
> On Mon, 19 Oct 2020 23:10:23 GMT, Mandy Chung <mchung at openjdk.org> wrote:
> 
>>> Looks good.
>>
>>> That's the crux of it: what exactly is meant by "the referent"? Does it
>>> mean the original object that was used as the referent, or does it mean
>>> the current value of the "referent" field inside the Reference (as get
>>> might return)?
>>
>> "the referent" is the object a `Reference` object refers to.
>>
>> as it's described in java.lang.ref package description:
>>
>>> Each reference-object type is implemented by a subclass of the abstract base Reference class. An instance of one of
>>> these subclasses encapsulates a single reference to a particular object, called the referent.
>>
>> See also `@return` in `Reference::get`:
>>> @return The object to which this reference refers, or null if this reference object has been cleared
> 
> I also personally prefer to use the "refers to" wording in the specification as well (IIRC I suggested that wordings).
> What about:
> 
> * Tests if this reference object refers to {@code obj}.
> * If {@code obj} is {@code null}, this method returns {@code true} if
> * this reference object was constructed with a {@code null} referent
> * or has been cleared.
> and
> @return {@code true} if {@code obj} is the object to which this reference refers,
>                or if {@code obj} is {@code null} and this reference has been cleared.

That looks good to me.

The CSR will need to be re-opened and updated unfortunately.

Thanks,
David

> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/498
> 

From kim.barrett at oracle.com  Tue Oct 20 02:40:46 2020
From: kim.barrett at oracle.com (Kim Barrett)
Date: Mon, 19 Oct 2020 22:40:46 -0400
Subject: RFR: 8188055: (ref) Add Reference::refersTo predicate [v5]
In-Reply-To: <rDPsYfi057gmn-cIG04-EwHqFKj2vST5h-_PsJpnFj4=.0ecbdd68-329b-4376-a7ea-1be23206aa9b@github.com>
References: <D4HSg8FT20Eaxk5KJkkw0GgETSxRkBn1ipS3Dt0kPto=.e4bab078-2e04-4413-90cb-9bfafb2a6831@github.com>
 <FHx-oBhE254DZWHhg2RTKjZn_-yYN5xadTW7GXhTxzM=.7e6a46fa-5259-428c-b725-81b4fe48b8f7@github.com>
 <Ch2xqBrcg76WqiK0RVUEl_XcN4o7X4bvo44RPDDi3O8=.852fb1b6-77f5-4aaa-9ed6-bdee28ec8eb3@github.com>
 <E8OiCIWFPwu7ircN0UQiSG8yJ2QrbFNdYT_MHLHtKcQ=.85cd2acb-d656-4398-b7bf-1f2e9cc6bc58@github.com>
 <rDPsYfi057gmn-cIG04-EwHqFKj2vST5h-_PsJpnFj4=.0ecbdd68-329b-4376-a7ea-1be23206aa9b@github.com>
Message-ID: <4AB0E5C0-7BF8-4C31-A5FA-064183AD192D@oracle.com>

> On Oct 19, 2020, at 7:20 PM, Mandy Chung <mchung at openjdk.java.net> wrote:
> 
> On Mon, 19 Oct 2020 23:10:23 GMT, Mandy Chung <mchung at openjdk.org> wrote:
> 
>>> Looks good.
>> 
>>> That's the crux of it: what exactly is meant by "the referent"? Does it
>>> mean the original object that was used as the referent, or does it mean
>>> the current value of the "referent" field inside the Reference (as get
>>> might return)?
>> 
>> "the referent" is the object a `Reference` object refers to.
>> 
>> as it's described in java.lang.ref package description:
>> 
>>> Each reference-object type is implemented by a subclass of the abstract base Reference class. An instance of one of
>>> these subclasses encapsulates a single reference to a particular object, called the referent.
>> 
>> See also `@return` in `Reference::get`:
>>> @return The object to which this reference refers, or null if this reference object has been cleared

In light of David's comments, I now think get's @return text is inconsistent
with the rest of get's description, which starts off with

* Returns this reference object's referent.

That seems definitional to me.  It then goes on to say

* If this reference object has
* been cleared, either by the program or by the garbage collector, then
* this method returns {@code null}.

which is just noting that the referent is null after clearing.

But the @return seems to be suggesting some distinction between the referent
and the post-clear result of calling get. If there is such a distinction
then the first sentence of the description is factually false. I think this
would be improved by changing "or" to "which is" in the @return description.

> I also personally prefer to use the "refers to" wording in the specification as well (IIRC I suggested that wordings).
> What about:
> 
> * Tests if this reference object refers to {@code obj}.
> * If {@code obj} is {@code null}, this method returns {@code true} if
> * this reference object was constructed with a {@code null} referent
> * or has been cleared.
> and
> @return {@code true} if {@code obj} is the object to which this reference refers,
>              or if {@code obj} is {@code null} and this reference has been cleared.

I think the @param description of refersTo has the same problem. I don't
think there's any need to mention null at all in the description of
refersTo. I originally thought, and still think, the following is sufficient
and accurate, (esp. with the above wording tweak for get's @return text).

/**
 * Tests if the referent of this reference object is {@code obj}.
 *
 * @param  obj the object to compare with this reference object's referent
 * @return {@code true} if {@code obj} is the referent of this reference object
 * @since 16
 */

Mandy asked for additional discussion around null, but I've come around to
agreeing the current text isn't ideal. Rather than just rewording the
current @return text though, how about this:

/**
 * Tests if the referent of this reference object is {@code obj}.
 * Using a {@code null} {@code obj} allows detection of a reference that 
 * has been cleared, if it initially had some other referent value. 
 *
 * @param  obj the object to compare with this reference object's referent
 * @return {@code true} if {@code obj} is the referent of this reference object
 * @since 16
 */



From vromero at openjdk.java.net  Tue Oct 20 03:19:16 2020
From: vromero at openjdk.java.net (Vicente Romero)
Date: Tue, 20 Oct 2020 03:19:16 GMT
Subject: RFR: 8250625: Compiler implementation of Pattern Matching for
 instanceof (Final)
In-Reply-To: <0uEby0-y3KVBLA1VxxdD5hCMlLhPCKB3w0mpihs9dsY=.181f22cd-7cf7-4941-b2d1-2ba4228d11d5@github.com>
References: <0uEby0-y3KVBLA1VxxdD5hCMlLhPCKB3w0mpihs9dsY=.181f22cd-7cf7-4941-b2d1-2ba4228d11d5@github.com>
Message-ID: <sQv_ZdanJ0-lLBox6CKwXxIXFrWSVNyWcN3sQZ5U1Bw=.1c5793db-f4e2-4ffd-9ed9-e93703e6107e@github.com>

On Thu, 8 Oct 2020 11:49:17 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> This is the current proposed patch for the upcoming JEP 394, for pattern matching for instanceof.
> 
> A summary of changes:
> -making the feature permanent (non-preview)
> -making the binding variables non-final (as per current specification proposal)
> -producing a compile-time error for the case where the expression's type is a subtype of the type test pattern's type
>  (as per current specification proposal)
> -changing the AST structure so that the binding variable has a VariableTree in the AST. BindingPatternTree is preserved
>  and encloses the VariableTree. The reason is better consistency in the API, with nodes like CatchTree, EnhancedForLoop
>  Tree, etc.
> 
> This change will not be integrated until JEP 394 is targetted.

Changes requested by vromero (Reviewer).

test/langtools/tools/javac/patterns/BindingsTest1.java line 28:

> 26:  * @bug 8231827
> 27:  * @summary Basic tests for bindings from instanceof
> 28:  * @compile BindingsTest1.java

the @compile can be removed

test/langtools/tools/javac/patterns/BindingsTest1.java line 29:

> 27:  * @summary Basic tests for bindings from instanceof
> 28:  * @compile BindingsTest1.java
> 29:  * @run main BindingsTest1

and this line too

test/langtools/tools/javac/patterns/ExamplesFromProposal.java line 29:

> 27:  * @summary All example code from "Pattern Matching for Java" document, released April 2017, adjusted to current
> state (no switches, etc) 28:  * @compile ExamplesFromProposal.java
> 29:  * @run main ExamplesFromProposal

these two lines can be removed now, there are other tests in this commit in which they can also be eliminated

test/langtools/tools/javac/patterns/LocalVariableTable.java line 29:

> 27:  * @summary Ensure the LV table entries are generated for bindings
> 28:  * @modules jdk.jdeps/com.sun.tools.classfile
> 29:  * @compile -g LocalVariableTable.java

I believe all tests are always compiled with `-g` option set, not related to your patch but we could probably remove
that line as superfluous

test/langtools/tools/javac/patterns/PatternsSimpleVisitorTest.java line 108:

> 106:         StringWriter out = new StringWriter();
> 107:         JavacTask ct = (JavacTask) tool.getTask(out, null, noErrors,
> 108:             List.of(), null,

nit: what about passing `null` instead of `List.of()`?

-------------

PR: https://git.openjdk.java.net/jdk/pull/559

From mchung at openjdk.java.net  Tue Oct 20 03:28:11 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 20 Oct 2020 03:28:11 GMT
Subject: RFR: 8188055: (ref) Add Reference::refersTo predicate [v5]
In-Reply-To: <rDPsYfi057gmn-cIG04-EwHqFKj2vST5h-_PsJpnFj4=.0ecbdd68-329b-4376-a7ea-1be23206aa9b@github.com>
References: <D4HSg8FT20Eaxk5KJkkw0GgETSxRkBn1ipS3Dt0kPto=.e4bab078-2e04-4413-90cb-9bfafb2a6831@github.com>
 <FHx-oBhE254DZWHhg2RTKjZn_-yYN5xadTW7GXhTxzM=.7e6a46fa-5259-428c-b725-81b4fe48b8f7@github.com>
 <Ch2xqBrcg76WqiK0RVUEl_XcN4o7X4bvo44RPDDi3O8=.852fb1b6-77f5-4aaa-9ed6-bdee28ec8eb3@github.com>
 <E8OiCIWFPwu7ircN0UQiSG8yJ2QrbFNdYT_MHLHtKcQ=.85cd2acb-d656-4398-b7bf-1f2e9cc6bc58@github.com>
 <rDPsYfi057gmn-cIG04-EwHqFKj2vST5h-_PsJpnFj4=.0ecbdd68-329b-4376-a7ea-1be23206aa9b@github.com>
Message-ID: <Nks-e8NMGE0VeZQF4zKg73QJt_Da3mm_Vom49v9odio=.ba79800e-3e32-465b-a516-2316b2bc4169@github.com>

On Mon, 19 Oct 2020 23:17:32 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>>> That's the crux of it: what exactly is meant by "the referent"? Does it
>>> mean the original object that was used as the referent, or does it mean
>>> the current value of the "referent" field inside the Reference (as get
>>> might return)?
>> 
>> "the referent" is the object a `Reference` object refers to.
>> 
>> as it's described in java.lang.ref package description:
>> 
>>> Each reference-object type is implemented by a subclass of the abstract base Reference class. An instance of one of
>>> these subclasses encapsulates a single reference to a particular object, called the referent.
>> 
>> See also `@return` in `Reference::get`:
>>> @return The object to which this reference refers, or null if this reference object has been cleared
>
> I also personally prefer to use the "refers to" wording in the specification as well (IIRC I suggested that wordings).
> What about:
> * Tests if this reference object refers to {@code obj}.
> * If {@code obj} is {@code null}, this method returns {@code true} if
> * this reference object was constructed with a {@code null} referent
> * or has been cleared.
> and
> @return {@code true} if {@code obj} is the object to which this reference refers,
>               or if {@code obj} is {@code null} and this reference has been cleared.

@kimbarrett  your reworded text is okay.  I think "if it initially had some other referent value" can be dropped.

For a `Reference` constructed with a `null` referent, we can clarify in the spec that such reference object will never
get cleared and enqueued.  I suggest to file a separate issue to follow up.

-------------

PR: https://git.openjdk.java.net/jdk/pull/498

From david.holmes at oracle.com  Tue Oct 20 03:49:00 2020
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 20 Oct 2020 13:49:00 +1000
Subject: RFR: 8188055: (ref) Add Reference::refersTo predicate [v5]
In-Reply-To: <4AB0E5C0-7BF8-4C31-A5FA-064183AD192D@oracle.com>
References: <D4HSg8FT20Eaxk5KJkkw0GgETSxRkBn1ipS3Dt0kPto=.e4bab078-2e04-4413-90cb-9bfafb2a6831@github.com>
 <FHx-oBhE254DZWHhg2RTKjZn_-yYN5xadTW7GXhTxzM=.7e6a46fa-5259-428c-b725-81b4fe48b8f7@github.com>
 <Ch2xqBrcg76WqiK0RVUEl_XcN4o7X4bvo44RPDDi3O8=.852fb1b6-77f5-4aaa-9ed6-bdee28ec8eb3@github.com>
 <E8OiCIWFPwu7ircN0UQiSG8yJ2QrbFNdYT_MHLHtKcQ=.85cd2acb-d656-4398-b7bf-1f2e9cc6bc58@github.com>
 <rDPsYfi057gmn-cIG04-EwHqFKj2vST5h-_PsJpnFj4=.0ecbdd68-329b-4376-a7ea-1be23206aa9b@github.com>
 <4AB0E5C0-7BF8-4C31-A5FA-064183AD192D@oracle.com>
Message-ID: <62979ff2-de80-8780-3aa6-2283cd16a044@oracle.com>

On 20/10/2020 12:40 pm, Kim Barrett wrote:
>> On Oct 19, 2020, at 7:20 PM, Mandy Chung <mchung at openjdk.java.net> wrote:
>>
>> On Mon, 19 Oct 2020 23:10:23 GMT, Mandy Chung <mchung at openjdk.org> wrote:
>>
>>>> Looks good.
>>>
>>>> That's the crux of it: what exactly is meant by "the referent"? Does it
>>>> mean the original object that was used as the referent, or does it mean
>>>> the current value of the "referent" field inside the Reference (as get
>>>> might return)?
>>>
>>> "the referent" is the object a `Reference` object refers to.
>>>
>>> as it's described in java.lang.ref package description:
>>>
>>>> Each reference-object type is implemented by a subclass of the abstract base Reference class. An instance of one of
>>>> these subclasses encapsulates a single reference to a particular object, called the referent.
>>>
>>> See also `@return` in `Reference::get`:
>>>> @return The object to which this reference refers, or null if this reference object has been cleared
> 
> In light of David's comments, I now think get's @return text is inconsistent
> with the rest of get's description, which starts off with
> 
> * Returns this reference object's referent.
> 
> That seems definitional to me.  It then goes on to say
> 
> * If this reference object has
> * been cleared, either by the program or by the garbage collector, then
> * this method returns {@code null}.
> 
> which is just noting that the referent is null after clearing.
> 
> But the @return seems to be suggesting some distinction between the referent
> and the post-clear result of calling get. If there is such a distinction
> then the first sentence of the description is factually false. I think this
> would be improved by changing "or" to "which is" in the @return description.
> 
>> I also personally prefer to use the "refers to" wording in the specification as well (IIRC I suggested that wordings).
>> What about:
>>
>> * Tests if this reference object refers to {@code obj}.
>> * If {@code obj} is {@code null}, this method returns {@code true} if
>> * this reference object was constructed with a {@code null} referent
>> * or has been cleared.
>> and
>> @return {@code true} if {@code obj} is the object to which this reference refers,
>>               or if {@code obj} is {@code null} and this reference has been cleared.
> 
> I think the @param description of refersTo has the same problem. I don't
> think there's any need to mention null at all in the description of
> refersTo. I originally thought, and still think, the following is sufficient
> and accurate, (esp. with the above wording tweak for get's @return text).
> 
> /**
>   * Tests if the referent of this reference object is {@code obj}.
>   *
>   * @param  obj the object to compare with this reference object's referent
>   * @return {@code true} if {@code obj} is the referent of this reference object
>   * @since 16
>   */
> 
> Mandy asked for additional discussion around null, but I've come around to
> agreeing the current text isn't ideal. Rather than just rewording the
> current @return text though, how about this:
> 
> /**
>   * Tests if the referent of this reference object is {@code obj}.
>   * Using a {@code null} {@code obj} allows detection of a reference that
>   * has been cleared, if it initially had some other referent value.
>   *
>   * @param  obj the object to compare with this reference object's referent
>   * @return {@code true} if {@code obj} is the referent of this reference object
>   * @since 16
>   */

I'm okay with that version too. Like Mandy I think the "if it initially 
..." can be dropped.

Thanks,
David
-----

> 

From kbarrett at openjdk.java.net  Tue Oct 20 05:26:18 2020
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Tue, 20 Oct 2020 05:26:18 GMT
Subject: RFR: 8188055: (ref) Add Reference::refersTo predicate [v5]
In-Reply-To: <Nks-e8NMGE0VeZQF4zKg73QJt_Da3mm_Vom49v9odio=.ba79800e-3e32-465b-a516-2316b2bc4169@github.com>
References: <D4HSg8FT20Eaxk5KJkkw0GgETSxRkBn1ipS3Dt0kPto=.e4bab078-2e04-4413-90cb-9bfafb2a6831@github.com>
 <FHx-oBhE254DZWHhg2RTKjZn_-yYN5xadTW7GXhTxzM=.7e6a46fa-5259-428c-b725-81b4fe48b8f7@github.com>
 <Ch2xqBrcg76WqiK0RVUEl_XcN4o7X4bvo44RPDDi3O8=.852fb1b6-77f5-4aaa-9ed6-bdee28ec8eb3@github.com>
 <E8OiCIWFPwu7ircN0UQiSG8yJ2QrbFNdYT_MHLHtKcQ=.85cd2acb-d656-4398-b7bf-1f2e9cc6bc58@github.com>
 <rDPsYfi057gmn-cIG04-EwHqFKj2vST5h-_PsJpnFj4=.0ecbdd68-329b-4376-a7ea-1be23206aa9b@github.com>
 <Nks-e8NMGE0VeZQF4zKg73QJt_Da3mm_Vom49v9odio=.ba79800e-3e32-465b-a516-2316b2bc4169@github.com>
Message-ID: <VcqdD5owO8PgUmW8zfisLrc1eFYAeNOonJ6UtYt3YKI=.42cae436-5ce7-4f51-9513-c28164242328@github.com>

On Tue, 20 Oct 2020 03:25:45 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> @kimbarrett your reworded text is okay. I think "if it initially had some other referent value" can be dropped.
> 
> For a `Reference` constructed with a `null` referent, we can clarify in the spec that such reference object will never
> get cleared and enqueued. I suggest to file a separate issue to follow up.

I don't think that clause can be dropped, because of explicit clearing (by clear() or enqueue()) rather than by the
GC.  If the reference was constructed with a null referent, ref.refersTo(null) cannot tell whether ref.clear() has been
called.

-------------

PR: https://git.openjdk.java.net/jdk/pull/498

From david.holmes at oracle.com  Tue Oct 20 06:09:05 2020
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 20 Oct 2020 16:09:05 +1000
Subject: RFR: 8188055: (ref) Add Reference::refersTo predicate [v5]
In-Reply-To: <VcqdD5owO8PgUmW8zfisLrc1eFYAeNOonJ6UtYt3YKI=.42cae436-5ce7-4f51-9513-c28164242328@github.com>
References: <D4HSg8FT20Eaxk5KJkkw0GgETSxRkBn1ipS3Dt0kPto=.e4bab078-2e04-4413-90cb-9bfafb2a6831@github.com>
 <FHx-oBhE254DZWHhg2RTKjZn_-yYN5xadTW7GXhTxzM=.7e6a46fa-5259-428c-b725-81b4fe48b8f7@github.com>
 <Ch2xqBrcg76WqiK0RVUEl_XcN4o7X4bvo44RPDDi3O8=.852fb1b6-77f5-4aaa-9ed6-bdee28ec8eb3@github.com>
 <E8OiCIWFPwu7ircN0UQiSG8yJ2QrbFNdYT_MHLHtKcQ=.85cd2acb-d656-4398-b7bf-1f2e9cc6bc58@github.com>
 <rDPsYfi057gmn-cIG04-EwHqFKj2vST5h-_PsJpnFj4=.0ecbdd68-329b-4376-a7ea-1be23206aa9b@github.com>
 <Nks-e8NMGE0VeZQF4zKg73QJt_Da3mm_Vom49v9odio=.ba79800e-3e32-465b-a516-2316b2bc4169@github.com>
 <VcqdD5owO8PgUmW8zfisLrc1eFYAeNOonJ6UtYt3YKI=.42cae436-5ce7-4f51-9513-c28164242328@github.com>
Message-ID: <026931d4-53a6-8348-5357-a7bef2d4fed0@oracle.com>

On 20/10/2020 3:26 pm, Kim Barrett wrote:
> On Tue, 20 Oct 2020 03:25:45 GMT, Mandy Chung <mchung at openjdk.org> wrote:
> 
>> @kimbarrett your reworded text is okay. I think "if it initially had some other referent value" can be dropped.
>>
>> For a `Reference` constructed with a `null` referent, we can clarify in the spec that such reference object will never
>> get cleared and enqueued. I suggest to file a separate issue to follow up.
> 
> I don't think that clause can be dropped, because of explicit clearing (by clear() or enqueue()) rather than by the
> GC.  If the reference was constructed with a null referent, ref.refersTo(null) cannot tell whether ref.clear() has been
> called.

I think that can be addressed by considering a Reference created with a 
null referent to be immediately cleared.

But the more we discuss this the more I think allowing an initial null 
referent was a mistake in the first place. :(

Cheers,
David

> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/498
> 

From kim.barrett at oracle.com  Tue Oct 20 07:01:34 2020
From: kim.barrett at oracle.com (Kim Barrett)
Date: Tue, 20 Oct 2020 03:01:34 -0400
Subject: RFR: 8188055: (ref) Add Reference::refersTo predicate [v5]
In-Reply-To: <026931d4-53a6-8348-5357-a7bef2d4fed0@oracle.com>
References: <D4HSg8FT20Eaxk5KJkkw0GgETSxRkBn1ipS3Dt0kPto=.e4bab078-2e04-4413-90cb-9bfafb2a6831@github.com>
 <FHx-oBhE254DZWHhg2RTKjZn_-yYN5xadTW7GXhTxzM=.7e6a46fa-5259-428c-b725-81b4fe48b8f7@github.com>
 <Ch2xqBrcg76WqiK0RVUEl_XcN4o7X4bvo44RPDDi3O8=.852fb1b6-77f5-4aaa-9ed6-bdee28ec8eb3@github.com>
 <E8OiCIWFPwu7ircN0UQiSG8yJ2QrbFNdYT_MHLHtKcQ=.85cd2acb-d656-4398-b7bf-1f2e9cc6bc58@github.com>
 <rDPsYfi057gmn-cIG04-EwHqFKj2vST5h-_PsJpnFj4=.0ecbdd68-329b-4376-a7ea-1be23206aa9b@github.com>
 <Nks-e8NMGE0VeZQF4zKg73QJt_Da3mm_Vom49v9odio=.ba79800e-3e32-465b-a516-2316b2bc4169@github.com>
 <VcqdD5owO8PgUmW8zfisLrc1eFYAeNOonJ6UtYt3YKI=.42cae436-5ce7-4f51-9513-c28164242328@github.com>
 <026931d4-53a6-8348-5357-a7bef2d4fed0@oracle.com>
Message-ID: <6666BA12-766B-4812-A65A-FD88030A91C4@oracle.com>

> On Oct 20, 2020, at 2:09 AM, David Holmes <david.holmes at oracle.com> wrote:
> 
> On 20/10/2020 3:26 pm, Kim Barrett wrote:
>> On Tue, 20 Oct 2020 03:25:45 GMT, Mandy Chung <mchung at openjdk.org> wrote:
>>> @kimbarrett your reworded text is okay. I think "if it initially had some other referent value" can be dropped.
>>> 
>>> For a `Reference` constructed with a `null` referent, we can clarify in the spec that such reference object will never
>>> get cleared and enqueued. I suggest to file a separate issue to follow up.
>> I don't think that clause can be dropped, because of explicit clearing (by clear() or enqueue()) rather than by the
>> GC.  If the reference was constructed with a null referent, ref.refersTo(null) cannot tell whether ref.clear() has been
>> called.
> 
> I think that can be addressed by considering a Reference created with a null referent to be immediately cleared.

I think if it?s treated as immediately cleared then it should also be immediately enqueued.  But immediate
enqueue has problems; it can?t be done by the Reference constructor because the derived constructors
have not yet completed, and exposing the possibly incompletely constructed object to the queue processor
is problematic.  And if it can?t be done by the constructor, it?s not clear who would do it.

> But the more we discuss this the more I think allowing an initial null referent was a mistake in the first place. :(

I agree, but here we are.  Very hard to know what the compatibility impact of changing that would be.


From github.com+1290376+johnlinp at openjdk.java.net  Tue Oct 20 07:08:28 2020
From: github.com+1290376+johnlinp at openjdk.java.net (John Lin)
Date: Tue, 20 Oct 2020 07:08:28 GMT
Subject: Withdrawn: 8247402: rewrite the implementation requirements for
 Map::compute()
In-Reply-To: <as4mWIy4TmbEz5C238FHXEL6-gynMYyxaQLQqGV_wVM=.6bac3533-5459-4ad7-8d45-c00e3bfdd121@github.com>
References: <as4mWIy4TmbEz5C238FHXEL6-gynMYyxaQLQqGV_wVM=.6bac3533-5459-4ad7-8d45-c00e3bfdd121@github.com>
Message-ID: <2BeLLVhuWHIzSJgC_M9qLoEk-UKtRgkoPbjc8vNO-80=.41230ea0-ff23-404c-acb1-dc4c9dea73e2@github.com>

On Thu, 1 Oct 2020 07:07:24 GMT, John Lin <github.com+1290376+johnlinp at openjdk.org> wrote:

> This is from the mailing list: http://mail.openjdk.java.net/pipermail/core-libs-dev/2020-June/067213.html

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/451

From david.holmes at oracle.com  Tue Oct 20 07:21:43 2020
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 20 Oct 2020 17:21:43 +1000
Subject: RFR: 8188055: (ref) Add Reference::refersTo predicate [v5]
In-Reply-To: <6666BA12-766B-4812-A65A-FD88030A91C4@oracle.com>
References: <D4HSg8FT20Eaxk5KJkkw0GgETSxRkBn1ipS3Dt0kPto=.e4bab078-2e04-4413-90cb-9bfafb2a6831@github.com>
 <FHx-oBhE254DZWHhg2RTKjZn_-yYN5xadTW7GXhTxzM=.7e6a46fa-5259-428c-b725-81b4fe48b8f7@github.com>
 <Ch2xqBrcg76WqiK0RVUEl_XcN4o7X4bvo44RPDDi3O8=.852fb1b6-77f5-4aaa-9ed6-bdee28ec8eb3@github.com>
 <E8OiCIWFPwu7ircN0UQiSG8yJ2QrbFNdYT_MHLHtKcQ=.85cd2acb-d656-4398-b7bf-1f2e9cc6bc58@github.com>
 <rDPsYfi057gmn-cIG04-EwHqFKj2vST5h-_PsJpnFj4=.0ecbdd68-329b-4376-a7ea-1be23206aa9b@github.com>
 <Nks-e8NMGE0VeZQF4zKg73QJt_Da3mm_Vom49v9odio=.ba79800e-3e32-465b-a516-2316b2bc4169@github.com>
 <VcqdD5owO8PgUmW8zfisLrc1eFYAeNOonJ6UtYt3YKI=.42cae436-5ce7-4f51-9513-c28164242328@github.com>
 <026931d4-53a6-8348-5357-a7bef2d4fed0@oracle.com>
 <6666BA12-766B-4812-A65A-FD88030A91C4@oracle.com>
Message-ID: <3c9ec10a-174f-4820-a11e-64fb27db9ba6@oracle.com>

On 20/10/2020 5:01 pm, Kim Barrett wrote:
>> On Oct 20, 2020, at 2:09 AM, David Holmes <david.holmes at oracle.com> wrote:
>>
>> On 20/10/2020 3:26 pm, Kim Barrett wrote:
>>> On Tue, 20 Oct 2020 03:25:45 GMT, Mandy Chung <mchung at openjdk.org> wrote:
>>>> @kimbarrett your reworded text is okay. I think "if it initially had some other referent value" can be dropped.
>>>>
>>>> For a `Reference` constructed with a `null` referent, we can clarify in the spec that such reference object will never
>>>> get cleared and enqueued. I suggest to file a separate issue to follow up.
>>> I don't think that clause can be dropped, because of explicit clearing (by clear() or enqueue()) rather than by the
>>> GC.  If the reference was constructed with a null referent, ref.refersTo(null) cannot tell whether ref.clear() has been
>>> called.
>>
>> I think that can be addressed by considering a Reference created with a null referent to be immediately cleared.
> 
> I think if it?s treated as immediately cleared then it should also be immediately enqueued.  But immediate

Mandy's comment implied that references with a null referent never get 
enqueued. Otherwise when would they get enqueued? There would be nothing 
to trigger it.

David
-----

> enqueue has problems; it can?t be done by the Reference constructor because the derived constructors
> have not yet completed, and exposing the possibly incompletely constructed object to the queue processor
> is problematic.  And if it can?t be done by the constructor, it?s not clear who would do it.
> 
>> But the more we discuss this the more I think allowing an initial null referent was a mistake in the first place. :(
> 
> I agree, but here we are.  Very hard to know what the compatibility impact of changing that would be.
> 

From kim.barrett at oracle.com  Tue Oct 20 07:51:48 2020
From: kim.barrett at oracle.com (Kim Barrett)
Date: Tue, 20 Oct 2020 03:51:48 -0400
Subject: RFR: 8188055: (ref) Add Reference::refersTo predicate [v5]
In-Reply-To: <3c9ec10a-174f-4820-a11e-64fb27db9ba6@oracle.com>
References: <D4HSg8FT20Eaxk5KJkkw0GgETSxRkBn1ipS3Dt0kPto=.e4bab078-2e04-4413-90cb-9bfafb2a6831@github.com>
 <FHx-oBhE254DZWHhg2RTKjZn_-yYN5xadTW7GXhTxzM=.7e6a46fa-5259-428c-b725-81b4fe48b8f7@github.com>
 <Ch2xqBrcg76WqiK0RVUEl_XcN4o7X4bvo44RPDDi3O8=.852fb1b6-77f5-4aaa-9ed6-bdee28ec8eb3@github.com>
 <E8OiCIWFPwu7ircN0UQiSG8yJ2QrbFNdYT_MHLHtKcQ=.85cd2acb-d656-4398-b7bf-1f2e9cc6bc58@github.com>
 <rDPsYfi057gmn-cIG04-EwHqFKj2vST5h-_PsJpnFj4=.0ecbdd68-329b-4376-a7ea-1be23206aa9b@github.com>
 <Nks-e8NMGE0VeZQF4zKg73QJt_Da3mm_Vom49v9odio=.ba79800e-3e32-465b-a516-2316b2bc4169@github.com>
 <VcqdD5owO8PgUmW8zfisLrc1eFYAeNOonJ6UtYt3YKI=.42cae436-5ce7-4f51-9513-c28164242328@github.com>
 <026931d4-53a6-8348-5357-a7bef2d4fed0@oracle.com>
 <6666BA12-766B-4812-A65A-FD88030A91C4@oracle.com>
 <3c9ec10a-174f-4820-a11e-64fb27db9ba6@oracle.com>
Message-ID: <A9285A8B-F37C-45D2-B9A3-C63819C95C7F@oracle.com>

> On Oct 20, 2020, at 3:21 AM, David Holmes <david.holmes at oracle.com> wrote:
> 
> On 20/10/2020 5:01 pm, Kim Barrett wrote:
>>> On Oct 20, 2020, at 2:09 AM, David Holmes <david.holmes at oracle.com> wrote:
>>> 
>>> I think that can be addressed by considering a Reference created with a null referent to be immediately cleared.
>> I think if it?s treated as immediately cleared then it should also be immediately enqueued.  But immediate
> 
> Mandy's comment implied that references with a null referent never get enqueued. Otherwise when would they get enqueued? There would be nothing to trigger it.

You said ?immediately cleared?; that?s the trigger.  Mandy said ?never cleared or enqueued?, which is different.


From fyang at openjdk.java.net  Tue Oct 20 08:07:24 2020
From: fyang at openjdk.java.net (Fei Yang)
Date: Tue, 20 Oct 2020 08:07:24 GMT
Subject: RFR: 8252204: AArch64: Implement SHA3 accelerator/intrinsic [v9]
In-Reply-To: <IEAI7ydU-L-aY41FOEjkKDcYWaPO6j4XyQPx1g7ba0E=.b2fe738c-3140-48a3-8cf6-da1dac0200ba@github.com>
References: <PJVtIubjiGKhCK81PIMhWuYxnR84DNieMDUGHdhHYZM=.ad903c93-c5e3-4614-9af1-d36bc33f735d@github.com>
 <tk-ljSMdkVcSl3FVQkWxQ66tX2e8Fpv96NUlr1iBgTA=.f6734f3c-74db-4f22-8754-974ba665e8b7@github.com>
 <IEAI7ydU-L-aY41FOEjkKDcYWaPO6j4XyQPx1g7ba0E=.b2fe738c-3140-48a3-8cf6-da1dac0200ba@github.com>
Message-ID: <tmxB5PK1SY9hVryLvmrdNdmxcUMPeqFgqMoDVTU-C5Q=.0a8c048d-4f20-44d3-8b6e-73079947bce8@github.com>

On Mon, 19 Oct 2020 20:26:22 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Always run graalunit testing with new intrinsics. You need to adjust Graal test:
> src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/CheckGraalIntrinsics.java

Thanks for looking at this. We did run graalunit testing and added the following change in our first commit:

diff --git
a/src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/CheckGraalIntrinsics.java
b/src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/CheckGraalIntrinsics.java
index f0e17947460..8f3f4ed9323 100644
--- a/src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/CheckGraalIntrinsics.java
+++
b/src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/CheckGraalIntrinsics.java
@@ -601,6 +601,7 @@ public class CheckGraalIntrinsics extends GraalTest {
          if (!config.useSHA512Intrinsics()) {
              add(ignore, "sun/security/provider/SHA5." + shaCompressName + "([BI)V");
          }
+        add(toBeInvestigated, "sun/security/provider/SHA3." + shaCompressName + "([BI)V");
      }

-------------

PR: https://git.openjdk.java.net/jdk/pull/207

From serb at openjdk.java.net  Tue Oct 20 08:41:19 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 20 Oct 2020 08:41:19 GMT
Subject: RFR: 8255043: Incorrectly styled copyright text
Message-ID: <gmKuCsi5-p4TN8bZ4CswPyFBokCuuyLRwWNAGNktarI=.c88a1093-9525-40ca-9a37-0d780240b41a@github.com>

In some files, the copyright text is styled as a JavaDoc comment.
Most of the affected files are tests, only one product file is affected:
src/java.sql/share/classes/javax/sql/package-info.java

The chenge is trivial:
 - /**
 + /*
    * Copyright (c)

-------------

Commit messages:
 - Initial fix

Changes: https://git.openjdk.java.net/jdk/pull/759/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=759&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8255043
  Stats: 49 lines in 49 files changed: 0 ins; 0 del; 49 mod
  Patch: https://git.openjdk.java.net/jdk/pull/759.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/759/head:pull/759

PR: https://git.openjdk.java.net/jdk/pull/759

From shade at openjdk.java.net  Tue Oct 20 09:45:20 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 20 Oct 2020 09:45:20 GMT
Subject: RFR: 8253525: Implement getInstanceSize/sizeOf intrinsics [v3]
In-Reply-To: <G12eddHXh2P9i2Gr6p1Lcq1wnh5Pizyj5Dg4gGPiQ8E=.50973ea6-1da6-4c34-beac-eeeaf220ad02@github.com>
References: <e93rUplFjEg-aHNsK_erFVgID73Egxk_x2Z82nOln1Q=.8fd819d9-b20b-4b54-98f9-6596c1933518@github.com>
 <WBF6B2x9DbvEX2SXbhPHcCsQrJ2q9zIblQJ0-S1bSiA=.b9005c9b-ad7d-409f-a114-28f6b90afcd6@github.com>
 <G12eddHXh2P9i2Gr6p1Lcq1wnh5Pizyj5Dg4gGPiQ8E=.50973ea6-1da6-4c34-beac-eeeaf220ad02@github.com>
Message-ID: <TM38eiNhAjGNNIRSoAavOVqtWwNrJNjjDGvqwP9qXec=.2eb7c3a9-217b-4f44-aaae-8b89e377bd58@github.com>

On Mon, 19 Oct 2020 18:13:59 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Aleksey Shipilev 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.
>
> Always run graalunit testing with new intrinsics.
> You need to adjust Graal test:
> src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/CheckGraalIntrinsics.java

I just ran `CONF=linux-x86_64-server-fastdebug make clean run-test TEST=compiler/graalunit` without problems even
without the `CheckGraalIntrinsics.java` changes. Does the test actually work?

-------------

PR: https://git.openjdk.java.net/jdk/pull/650

From jlahoda at openjdk.java.net  Tue Oct 20 10:09:25 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Tue, 20 Oct 2020 10:09:25 GMT
Subject: RFR: 8250625: Compiler implementation of Pattern Matching for
 instanceof (Final)
In-Reply-To: <sQv_ZdanJ0-lLBox6CKwXxIXFrWSVNyWcN3sQZ5U1Bw=.1c5793db-f4e2-4ffd-9ed9-e93703e6107e@github.com>
References: <0uEby0-y3KVBLA1VxxdD5hCMlLhPCKB3w0mpihs9dsY=.181f22cd-7cf7-4941-b2d1-2ba4228d11d5@github.com>
 <sQv_ZdanJ0-lLBox6CKwXxIXFrWSVNyWcN3sQZ5U1Bw=.1c5793db-f4e2-4ffd-9ed9-e93703e6107e@github.com>
Message-ID: <A9SY4hIbFN-9hx4vKajkewIdLOhX92fyAGc-PM1e7ew=.e0e05782-2e73-405f-bbb8-4c057dbf2af8@github.com>

On Tue, 20 Oct 2020 03:02:03 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> This is the current proposed patch for the upcoming JEP 394, for pattern matching for instanceof.
>> 
>> A summary of changes:
>> -making the feature permanent (non-preview)
>> -making the binding variables non-final (as per current specification proposal)
>> -producing a compile-time error for the case where the expression's type is a subtype of the type test pattern's type
>>  (as per current specification proposal)
>> -changing the AST structure so that the binding variable has a VariableTree in the AST. BindingPatternTree is preserved
>>  and encloses the VariableTree. The reason is better consistency in the API, with nodes like CatchTree, EnhancedForLoop
>>  Tree, etc.
>> 
>> This change will not be integrated until JEP 394 is targetted.
>
> test/langtools/tools/javac/patterns/BindingsTest1.java line 28:
> 
>> 26:  * @bug 8231827
>> 27:  * @summary Basic tests for bindings from instanceof
>> 28:  * @compile BindingsTest1.java
> 
> the @compile can be removed

I guess I prefer to keep @compile for javac non-programatic tests. The reason is that, for these tests, we can expect
we modify javac, but not the test. And if @build (implicit or explicit) is used, the test will not be re-compiled
unless their timestamp changes. So we can actually execute an older (already built) version of the test's class file,
instead of a newly built class file, which would reflect the changes in javac. So, for tests like this, I prefer to
have an explicit @compile, as that ensures the file is compiled every time, regardless how the working directories are
set-up, etc.

-------------

PR: https://git.openjdk.java.net/jdk/pull/559

From chegar at openjdk.java.net  Tue Oct 20 10:33:27 2020
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Tue, 20 Oct 2020 10:33:27 GMT
Subject: RFR: 8251989: Hex formatting and parsing utility [v6]
In-Reply-To: <seKMG87WLCuFuqEZuua-7hrmYxXeSYsoFATrMAqZMs4=.b4d97cb5-d84a-427c-9994-9292fa127e35@github.com>
References: <HSEn47GMS1K3g57mrTZeQk-WZHl3pKGHpX_OOf8VnsU=.740863c2-f9e4-43c4-b500-614aab4078b1@github.com>
 <seKMG87WLCuFuqEZuua-7hrmYxXeSYsoFATrMAqZMs4=.b4d97cb5-d84a-427c-9994-9292fa127e35@github.com>
Message-ID: <yTU1KThBgWoep1dgs5_JnxJm7Gh82hsXWDNx-vNFF04=.8877db35-776f-413f-87f5-0d5d83ee0f8b@github.com>

On Mon, 19 Oct 2020 22:52:31 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> java.util.HexFormat utility:
>> 
>>  - Format and parse hexadecimal strings, with parameters for delimiter, prefix, suffix and upper/lowercase
>>  - Static factories and builder methods to create HexFormat copies with modified parameters.
>>  - Consistent naming of methods for conversion of byte arrays to formatted strings and back: formatHex and parseHex
>>  - Consistent naming of methods for conversion of primitive types: toHexDigits... and fromHexDigits...
>>  - Prefix and suffixes now apply to each formatted value, not the string as a whole
>>  - Using java.util.Appendable as a target for buffered conversions so output to Writers and PrintStreams
>>    like System.out are supported in addition to StringBuilder. (IOExceptions are converted to unchecked exceptions)
>>  - Immutable and thread safe, a "value-based" class
>> 
>> See the [HexFormat
>> javadoc](http://cr.openjdk.java.net/~rriggs/8251989-hex-formatter/java.base/java/util/HexFormat.html) for details.
>> Review comments and suggestions welcome.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Correct length of StringBuilder in formatHex;
>   Correct bug in formatHex(char[], 2, 3) and add test for subranges of char[]

Changes requested by chegar (Reviewer).

src/java.base/share/classes/java/util/HexFormat.java line 52:

> 50:  * {@link #toHexDigits(long)}, etc.
> 51:  * For conversions producing uppercase hexadecimal strings use {@link #withUpperCase()}.
> 52:  *

A previous iteration had class-level text describing the range of valid hexadecimal characters. It seems to have gotten
dropped.

src/java.base/share/classes/java/util/HexFormat.java line 46:

> 44:  * {@link #withPrefix(String)}, {@link #withSuffix(String)}, {@link #withDelimiter(String)}
> 45:  * or choice of {@link #withUpperCase()} or {@link #withLowerCase()} parameters using
> 46:  * a fluent builder style.

I'm not sure that "fluent builder style" adds anything here. In fact, I'm still searching for the `build` method! ;-)

src/java.base/share/classes/java/util/HexFormat.java line 64:

> 62:  * and {@link #formatHex(Appendable, byte[]) formatHex(Appendable, byte[])}.
> 63:  * The formatted output can be appended to {@link StringBuilder}, {@link System#out},
> 64:  * {@link java.io.Writer}, and {@link java.io.PrintStream}, all of which are {@link Appendable}.

This seems like an arbitrary list of Appendables. Suggest to restructure the sentence to make it clear that these are
just some common examples, and maybe drop a few.

src/java.base/share/classes/java/util/HexFormat.java line 68:

> 66:  * uppercase or lowercase digits, and the suffix.
> 67:  * A delimiter appears after each formatted value, except the last.
> 68:  * For conversions producing uppercase hexadecimal strings use {@link #withUpperCase()}.

I was curious why (only) uppercase is called out here, but I see now that is because lowercase is the default. It's
confusing to call out withUpperCase here, without prior context that lowercase is the default. Maybe just drop it,
since the previous sentence says that both are possible.

src/java.base/share/classes/java/util/HexFormat.java line 127:

> 125:  *
> 126:  * @implSpec
> 127:  * This class is immutable and thread-safe.

I'm curious why this is an implSpec, and not just a normative statement? HexFormat is a final class after all, there is
just one implementation.

src/java.base/share/classes/java/util/HexFormat.java line 90:

> 88:  *     assert(byteStr.equals("7f"));
> 89:  *     assert(b == byteVal);
> 90:  *

I understand why this is the case, but the example is highlighting that a roundtrip from byte is not possible :-(

-------------

PR: https://git.openjdk.java.net/jdk/pull/482

From chegar at openjdk.java.net  Tue Oct 20 10:33:28 2020
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Tue, 20 Oct 2020 10:33:28 GMT
Subject: RFR: 8251989: Hex formatting and parsing utility [v6]
In-Reply-To: <lv3X2v4KfUM8fxWZyX8_rwGa5wVnysBQjvqnAJaDYUU=.2b36709d-5547-411d-a609-fa465c4ce17f@github.com>
References: <HSEn47GMS1K3g57mrTZeQk-WZHl3pKGHpX_OOf8VnsU=.740863c2-f9e4-43c4-b500-614aab4078b1@github.com>
 <lv3X2v4KfUM8fxWZyX8_rwGa5wVnysBQjvqnAJaDYUU=.2b36709d-5547-411d-a609-fa465c4ce17f@github.com>
Message-ID: <syCWbVRrevooHR-PByCqiYFTC_hMivTtuaznNU-D6oE=.e157fa55-ea7f-4393-b8bc-fdfd9eba7699@github.com>

On Mon, 12 Oct 2020 22:17:58 GMT, Marcono1234 <github.com+11685886+Marcono1234 at openjdk.org> wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Correct length of StringBuilder in formatHex;
>>   Correct bug in formatHex(char[], 2, 3) and add test for subranges of char[]
>
> src/java.base/share/classes/java/util/HexFormat.java line 836:
> 
>> 834:      *          otherwise {@code false}
>> 835:      */
>> 836:     public boolean isHexDigit(int ch) {
> 
> Should this method be `static`? Or otherwise should it consider the `uppercase()` setting?
> (Same for `fromHexDigit` and all the other subsequent methods)
> 
> These methods being instance methods is likely pretty confusing because they are unrelated to the HexFormat instance
> and makes using them cumbersome because the user has to create a HexFormat instance first.

Agree. I had the very same thought. In fact, these format agnostic methods have little to do with formatting.

-------------

PR: https://git.openjdk.java.net/jdk/pull/482

From jlahoda at openjdk.java.net  Tue Oct 20 11:39:19 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Tue, 20 Oct 2020 11:39:19 GMT
Subject: RFR: 8250625: Compiler implementation of Pattern Matching for
 instanceof (Final)
In-Reply-To: <sQv_ZdanJ0-lLBox6CKwXxIXFrWSVNyWcN3sQZ5U1Bw=.1c5793db-f4e2-4ffd-9ed9-e93703e6107e@github.com>
References: <0uEby0-y3KVBLA1VxxdD5hCMlLhPCKB3w0mpihs9dsY=.181f22cd-7cf7-4941-b2d1-2ba4228d11d5@github.com>
 <sQv_ZdanJ0-lLBox6CKwXxIXFrWSVNyWcN3sQZ5U1Bw=.1c5793db-f4e2-4ffd-9ed9-e93703e6107e@github.com>
Message-ID: <rCOM4p8lSaD9EheSPUJkvQovRVNaLfzWoYUlVeTbhew=.154bf6a2-57ed-4c8f-813c-d3784704b740@github.com>

On Tue, 20 Oct 2020 03:09:27 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> This is the current proposed patch for the upcoming JEP 394, for pattern matching for instanceof.
>> 
>> A summary of changes:
>> -making the feature permanent (non-preview)
>> -making the binding variables non-final (as per current specification proposal)
>> -producing a compile-time error for the case where the expression's type is a subtype of the type test pattern's type
>>  (as per current specification proposal)
>> -changing the AST structure so that the binding variable has a VariableTree in the AST. BindingPatternTree is preserved
>>  and encloses the VariableTree. The reason is better consistency in the API, with nodes like CatchTree, EnhancedForLoop
>>  Tree, etc.
>> 
>> This change will not be integrated until JEP 394 is targetted.
>
> test/langtools/tools/javac/patterns/LocalVariableTable.java line 29:
> 
>> 27:  * @summary Ensure the LV table entries are generated for bindings
>> 28:  * @modules jdk.jdeps/com.sun.tools.classfile
>> 29:  * @compile -g LocalVariableTable.java
> 
> I believe all tests are always compiled with `-g` option set, not related to your patch but we could probably remove
> that line as superfluous

I believe plain jtreg invocations may not be always setting "-g". So probably better to be explicitly clear we need -g,
as the test itself requires the debugging info/LocalVariableTable?

-------------

PR: https://git.openjdk.java.net/jdk/pull/559

From kravikumar at openjdk.java.net  Tue Oct 20 11:39:36 2020
From: kravikumar at openjdk.java.net (Kiran Sidhartha Ravikumar)
Date: Tue, 20 Oct 2020 11:39:36 GMT
Subject: RFR: 8254982: (tz) Upgrade time-zone data to tzdata2020c [v2]
In-Reply-To: <rQR51lGOpSaH5qywIqXV9ymJ36TbsUYzcurNCsvZ7OE=.21381473-7776-4ea5-8a03-734e1b3b11d9@github.com>
References: <rQR51lGOpSaH5qywIqXV9ymJ36TbsUYzcurNCsvZ7OE=.21381473-7776-4ea5-8a03-734e1b3b11d9@github.com>
Message-ID: <Rss6QPAz7tyhWg3P2UDhp_5TEfNvndQ4pko5H4QSNeg=.34d143c9-416c-47e6-a766-175c31c410fa@github.com>

> Hi Guys,
> 
> Please review the integration of tzdata2020c to JDK.
> 
> Details regarding the change can be viewed at - https://mm.icann.org/pipermail/tz-announce/2020-October/000060.html
> Bug: https://bugs.openjdk.java.net/browse/JDK-8254982
> 
> Along with it, there is a test fix for https://bugs.openjdk.java.net/browse/JDK-8254865, With tzdata2020b, the test
> fails for the mentioned zones expecting "PST" but JDK has Zone names for "MST" for JRE locale provider. Since the
> purpose of the test is to get any GMT-08:00 time zone, I have excluded those zones from the test.  Please let me know
> if the changes are good to push.
> Thanks,
> Kiran

Kiran Sidhartha Ravikumar has updated the pull request with a new target base due to a merge or a rebase. The
incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three
additional commits since the last revision:

 - 8254982: Adding comments for removal of zones in BasicDateTime.java
 - Merge remote-tracking branch 'origin/master' into JDK-8254982
 - 8254982: (tz) Upgrade time-zone data to tzdata2020c

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/747/files
  - new: https://git.openjdk.java.net/jdk/pull/747/files/7bd51537..7434663a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=747&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=747&range=00-01

  Stats: 26902 lines in 293 files changed: 17268 ins; 8054 del; 1580 mod
  Patch: https://git.openjdk.java.net/jdk/pull/747.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/747/head:pull/747

PR: https://git.openjdk.java.net/jdk/pull/747

From kravikumar at openjdk.java.net  Tue Oct 20 11:39:38 2020
From: kravikumar at openjdk.java.net (Kiran Sidhartha Ravikumar)
Date: Tue, 20 Oct 2020 11:39:38 GMT
Subject: RFR: 8254982: (tz) Upgrade time-zone data to tzdata2020c [v2]
In-Reply-To: <HyFEzz92nHPAazgKRXaCos1D4SBF4XVwQSy-MwXlALs=.9c93b278-49cc-4b8e-bd59-184c8983d000@github.com>
References: <rQR51lGOpSaH5qywIqXV9ymJ36TbsUYzcurNCsvZ7OE=.21381473-7776-4ea5-8a03-734e1b3b11d9@github.com>
 <HyFEzz92nHPAazgKRXaCos1D4SBF4XVwQSy-MwXlALs=.9c93b278-49cc-4b8e-bd59-184c8983d000@github.com>
Message-ID: <GReRISl8rbK_8UZSN9J7q1XgTsMAt53I3ps69QCgd4U=.29c79659-7120-43e2-b267-867aabe47b5f@github.com>

On Mon, 19 Oct 2020 19:38:57 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Kiran Sidhartha Ravikumar has updated the pull request with a new target base due to a merge or a rebase. The
>> incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three
>> additional commits since the last revision:
>>  - 8254982: Adding comments for removal of zones in BasicDateTime.java
>>  - Merge remote-tracking branch 'origin/master' into JDK-8254982
>>  - 8254982: (tz) Upgrade time-zone data to tzdata2020c
>
> test/jdk/java/util/Formatter/BasicDateTime.java line 1695:
> 
>> 1693:         list.remove("America/Dawson");
>> 1694:         list.remove("America/WhiteHorse");
>> 1695:         list.remove("Canada/Yukon");
> 
> I'd explicitly mention why these time zones are removed from the test.

Thanks, Naoto, I have added the information.

-------------

PR: https://git.openjdk.java.net/jdk/pull/747

From david.holmes at oracle.com  Tue Oct 20 11:45:14 2020
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 20 Oct 2020 21:45:14 +1000
Subject: RFR: 8188055: (ref) Add Reference::refersTo predicate [v5]
In-Reply-To: <A9285A8B-F37C-45D2-B9A3-C63819C95C7F@oracle.com>
References: <D4HSg8FT20Eaxk5KJkkw0GgETSxRkBn1ipS3Dt0kPto=.e4bab078-2e04-4413-90cb-9bfafb2a6831@github.com>
 <FHx-oBhE254DZWHhg2RTKjZn_-yYN5xadTW7GXhTxzM=.7e6a46fa-5259-428c-b725-81b4fe48b8f7@github.com>
 <Ch2xqBrcg76WqiK0RVUEl_XcN4o7X4bvo44RPDDi3O8=.852fb1b6-77f5-4aaa-9ed6-bdee28ec8eb3@github.com>
 <E8OiCIWFPwu7ircN0UQiSG8yJ2QrbFNdYT_MHLHtKcQ=.85cd2acb-d656-4398-b7bf-1f2e9cc6bc58@github.com>
 <rDPsYfi057gmn-cIG04-EwHqFKj2vST5h-_PsJpnFj4=.0ecbdd68-329b-4376-a7ea-1be23206aa9b@github.com>
 <Nks-e8NMGE0VeZQF4zKg73QJt_Da3mm_Vom49v9odio=.ba79800e-3e32-465b-a516-2316b2bc4169@github.com>
 <VcqdD5owO8PgUmW8zfisLrc1eFYAeNOonJ6UtYt3YKI=.42cae436-5ce7-4f51-9513-c28164242328@github.com>
 <026931d4-53a6-8348-5357-a7bef2d4fed0@oracle.com>
 <6666BA12-766B-4812-A65A-FD88030A91C4@oracle.com>
 <3c9ec10a-174f-4820-a11e-64fb27db9ba6@oracle.com>
 <A9285A8B-F37C-45D2-B9A3-C63819C95C7F@oracle.com>
Message-ID: <bc6b6b3f-a31b-24d7-a475-3a3d877dd9b9@oracle.com>

On 20/10/2020 5:51 pm, Kim Barrett wrote:
>> On Oct 20, 2020, at 3:21 AM, David Holmes <david.holmes at oracle.com> wrote:
>>
>> On 20/10/2020 5:01 pm, Kim Barrett wrote:
>>>> On Oct 20, 2020, at 2:09 AM, David Holmes <david.holmes at oracle.com> wrote:
>>>>
>>>> I think that can be addressed by considering a Reference created with a null referent to be immediately cleared.
>>> I think if it?s treated as immediately cleared then it should also be immediately enqueued.  But immediate
>>
>> Mandy's comment implied that references with a null referent never get enqueued. Otherwise when would they get enqueued? There would be nothing to trigger it.
> 
> You said ?immediately cleared?; that?s the trigger.  Mandy said ?never cleared or enqueued?, which is different.

Mandy said never enqueued and that is what I would expect even if 
considered "immediately cleared". A reference set with null is never 
cleared by the GC, nor ever enqueued, but it is implicitly and trivially 
"cleared" at construction.

"cleared" is just a synonym for "referent == null".

David


From dholmes at openjdk.java.net  Tue Oct 20 11:50:12 2020
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 20 Oct 2020 11:50:12 GMT
Subject: RFR: 8255043: Incorrectly styled copyright text
In-Reply-To: <gmKuCsi5-p4TN8bZ4CswPyFBokCuuyLRwWNAGNktarI=.c88a1093-9525-40ca-9a37-0d780240b41a@github.com>
References: <gmKuCsi5-p4TN8bZ4CswPyFBokCuuyLRwWNAGNktarI=.c88a1093-9525-40ca-9a37-0d780240b41a@github.com>
Message-ID: <oAJyHuvaVS9H-Y8Z8vDnqML0RsSK5WmSrxKR9O2GYgw=.93275630-0b8e-4d4d-9f29-91e9d61ba7a0@github.com>

On Tue, 20 Oct 2020 08:17:27 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> In some files, the copyright text is styled as a JavaDoc comment.
> Most of the affected files are tests, only one product file is affected:
> src/java.sql/share/classes/javax/sql/package-info.java
> 
> The chenge is trivial:
>  - /**
>  + /*
>     * Copyright (c)

Seems trivially fine.

Thanks,
David

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/759

From jlahoda at openjdk.java.net  Tue Oct 20 12:15:23 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Tue, 20 Oct 2020 12:15:23 GMT
Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12
 [v2]
In-Reply-To: <RRMAPzh6xcVcxOj2S_VW_r50YvZz-3Imaj46bDi8e9U=.9347534e-d482-468a-8668-132d5516bb76@github.com>
References: <RRMAPzh6xcVcxOj2S_VW_r50YvZz-3Imaj46bDi8e9U=.9347534e-d482-468a-8668-132d5516bb76@github.com>
Message-ID: <LIb9tG4MMzEQmWmOh26MHVMLJWnyWR6NTsBIgWsi0DA=.ee56fde6-defe-4df8-88a9-81b5882f3db0@github.com>

> This is an update to javac and javadoc, to introduce support for Preview APIs, and generally improve javac and javadoc
> behavior to more closely adhere to JEP 12.
> The notable changes are:
> 
>  * adding support for Preview APIs (javac until now supported primarily only preview language features, and APIs
>    associated with preview language features). This includes:
>      * the @PreviewFeature annotation has boolean attribute "reflective", which should be true for reflective Preview APIs,
>        false otherwise. This replaces the existing "essentialAPI" attribute with roughly inverted meaning.
>      * the preview warnings for preview APIs are auto-suppressed as described in the JEP 12. E.g. the module that declares the
>        preview API is free to use it without warnings
>  * improving error/warning messages. Please see [1] for a list of cases/examples.
>  * class files are only marked as preview if they are using a preview feature. [1] also shows if a class file is marked as
>    preview or not.
>  * the PreviewFeature annotation has been moved to jdk.internal.javac package (originally was in the jdk.internal package).
>  * Preview API in JDK's javadoc no longer needs to specify @preview tag in the source files. javadoc will auto-generate a
>    note for @PreviewFeature elements, see e.g. [2] and [3] (non-reflective and reflective API, respectively). A summary of
>    preview elements is also provided [4]. Existing uses of @preview have been updated/removed.
>  * non-JDK javadoc is also enhanced to auto-generate preview notes for uses of Preview elements, and for declaring
>    elements using preview language features [5].
>  
>  Please also see the CSR [6] for more information.
>  
>  [1] http://cr.openjdk.java.net/~jlahoda/8250768/JEP12-errors-warnings-v6.html
>  [2] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.base/java/lang/Record.html
>  [3]
>  http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.compiler/javax/lang/model/element/RecordComponentElement.html
>  [4] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/preview-list.html [5]
>  http://cr.openjdk.java.net/~jlahoda/8250768/test.javadoc.00/ [6] https://bugs.openjdk.java.net/browse/JDK-8250769

Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now
contains 35 commits:

 - Merge branch 'JDK-8250768-dev' of https://github.com/lahodaj/jdk into JDK-8250768
 - More fixing tests.
 - Fixing tests.
 - Using unique sections for preview warning sections, as suggested.
 - Merge branch 'master' into JDK-8250768
 - Reflecting review comments.
 - Fixing tests.
 - Various cleanup.
 - The Preview taglet is not needed anymore.
 - There is not jdk.internal package anymore
 - ... and 25 more: https://git.openjdk.java.net/jdk/compare/98ec4a67...be1d8651

-------------

Changes: https://git.openjdk.java.net/jdk/pull/703/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=703&range=01
  Stats: 3206 lines in 156 files changed: 2515 ins; 409 del; 282 mod
  Patch: https://git.openjdk.java.net/jdk/pull/703.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/703/head:pull/703

PR: https://git.openjdk.java.net/jdk/pull/703

From jlahoda at openjdk.java.net  Tue Oct 20 12:19:12 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Tue, 20 Oct 2020 12:19:12 GMT
Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12
 [v2]
In-Reply-To: <P5BfFxsebzKxmkt3Ds_wM1YmmbbqtCoCJ3l2VzqajDk=.279a85d1-7ee4-4522-a92a-564ee55e5663@github.com>
References: <RRMAPzh6xcVcxOj2S_VW_r50YvZz-3Imaj46bDi8e9U=.9347534e-d482-468a-8668-132d5516bb76@github.com>
 <P5BfFxsebzKxmkt3Ds_wM1YmmbbqtCoCJ3l2VzqajDk=.279a85d1-7ee4-4522-a92a-564ee55e5663@github.com>
Message-ID: <S0YntICU0MFSdanHUbB8Zv4cS9lrbQnMY4pSeBXCepA=.2306c9c5-d822-402a-b362-02c3c5d67d7e@github.com>

On Fri, 16 Oct 2020 16:47:25 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now
>> contains 35 commits:
>>  - Merge branch 'JDK-8250768-dev' of https://github.com/lahodaj/jdk into JDK-8250768
>>  - More fixing tests.
>>  - Fixing tests.
>>  - Using unique sections for preview warning sections, as suggested.
>>  - Merge branch 'master' into JDK-8250768
>>  - Reflecting review comments.
>>  - Fixing tests.
>>  - Various cleanup.
>>  - The Preview taglet is not needed anymore.
>>  - There is not jdk.internal package anymore
>>  - ... and 25 more: https://git.openjdk.java.net/jdk/compare/98ec4a67...be1d8651
>
> Build changes look good.

I've updated the patch based on the comments: mostly updating the anchors in the javadoc, but also removing the updates
to JavacParser, which are only loosely related to the primary focus of this patch, and should possibly be done
separately.

-------------

PR: https://git.openjdk.java.net/jdk/pull/703

From mcimadamore at openjdk.java.net  Tue Oct 20 13:40:22 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 20 Oct 2020 13:40:22 GMT
Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12
 [v2]
In-Reply-To: <LIb9tG4MMzEQmWmOh26MHVMLJWnyWR6NTsBIgWsi0DA=.ee56fde6-defe-4df8-88a9-81b5882f3db0@github.com>
References: <RRMAPzh6xcVcxOj2S_VW_r50YvZz-3Imaj46bDi8e9U=.9347534e-d482-468a-8668-132d5516bb76@github.com>
 <LIb9tG4MMzEQmWmOh26MHVMLJWnyWR6NTsBIgWsi0DA=.ee56fde6-defe-4df8-88a9-81b5882f3db0@github.com>
Message-ID: <b08WGx066cYDBBRqx3BkoWYu-45mcH1DIstmoOuUVlQ=.26a81bf3-7004-4ad9-9dfe-75aab0b5f6c1@github.com>

On Tue, 20 Oct 2020 12:15:23 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is an update to javac and javadoc, to introduce support for Preview APIs, and generally improve javac and javadoc
>> behavior to more closely adhere to JEP 12.
>> The notable changes are:
>> 
>>  * adding support for Preview APIs (javac until now supported primarily only preview language features, and APIs
>>    associated with preview language features). This includes:
>>      * the @PreviewFeature annotation has boolean attribute "reflective", which should be true for reflective Preview APIs,
>>        false otherwise. This replaces the existing "essentialAPI" attribute with roughly inverted meaning.
>>      * the preview warnings for preview APIs are auto-suppressed as described in the JEP 12. E.g. the module that declares the
>>        preview API is free to use it without warnings
>>  * improving error/warning messages. Please see [1] for a list of cases/examples.
>>  * class files are only marked as preview if they are using a preview feature. [1] also shows if a class file is marked as
>>    preview or not.
>>  * the PreviewFeature annotation has been moved to jdk.internal.javac package (originally was in the jdk.internal package).
>>  * Preview API in JDK's javadoc no longer needs to specify @preview tag in the source files. javadoc will auto-generate a
>>    note for @PreviewFeature elements, see e.g. [2] and [3] (non-reflective and reflective API, respectively). A summary of
>>    preview elements is also provided [4]. Existing uses of @preview have been updated/removed.
>>  * non-JDK javadoc is also enhanced to auto-generate preview notes for uses of Preview elements, and for declaring
>>    elements using preview language features [5].
>>  
>>  Please also see the CSR [6] for more information.
>>  
>>  [1] http://cr.openjdk.java.net/~jlahoda/8250768/JEP12-errors-warnings-v6.html
>>  [2] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.base/java/lang/Record.html
>>  [3]
>>  http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.compiler/javax/lang/model/element/RecordComponentElement.html
>>  [4] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/preview-list.html [5]
>>  http://cr.openjdk.java.net/~jlahoda/8250768/test.javadoc.00/ [6] https://bugs.openjdk.java.net/browse/JDK-8250769
>
> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now
> contains 35 commits:
>  - Merge branch 'JDK-8250768-dev' of https://github.com/lahodaj/jdk into JDK-8250768
>  - More fixing tests.
>  - Fixing tests.
>  - Using unique sections for preview warning sections, as suggested.
>  - Merge branch 'master' into JDK-8250768
>  - Reflecting review comments.
>  - Fixing tests.
>  - Various cleanup.
>  - The Preview taglet is not needed anymore.
>  - There is not jdk.internal package anymore
>  - ... and 25 more: https://git.openjdk.java.net/jdk/compare/98ec4a67...be1d8651

javac changes look good

-------------

Marked as reviewed by mcimadamore (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/703

From fyang at openjdk.java.net  Tue Oct 20 13:42:27 2020
From: fyang at openjdk.java.net (Fei Yang)
Date: Tue, 20 Oct 2020 13:42:27 GMT
Subject: RFR: 8252204: AArch64: Implement SHA3 accelerator/intrinsic [v10]
In-Reply-To: <PJVtIubjiGKhCK81PIMhWuYxnR84DNieMDUGHdhHYZM=.ad903c93-c5e3-4614-9af1-d36bc33f735d@github.com>
References: <PJVtIubjiGKhCK81PIMhWuYxnR84DNieMDUGHdhHYZM=.ad903c93-c5e3-4614-9af1-d36bc33f735d@github.com>
Message-ID: <kIpiKx8ovndJoa7alAki42vJ4H2lBJ4wN7MFqH5MORg=.57966a12-aa0c-40fb-815b-8bec9c7e8eda@github.com>

> Contributed-by: ard.biesheuvel at linaro.org, dongbo4 at huawei.com
> 
> This added an intrinsic for SHA3 using aarch64 v8.2 SHA3 Crypto Extensions.
> Reference implementation for core SHA-3 transform using ARMv8.2 Crypto Extensions:
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm64/crypto/sha3-ce-core.S?h=v5.4.52
> 
> Trivial adaptation in SHA3. implCompress is needed for the purpose of adding the intrinsic.
> For SHA3, we need to pass one extra parameter "digestLength" to the stub for the calculation of block size.
> "digestLength" is also used in for the EOR loop before keccak to differentiate different SHA3 variants.
> 
> We added jtreg tests for SHA3 and used QEMU system emulator which supports SHA3 instructions to test the functionality.
> Patch passed jtreg tier1-3 tests with QEMU system emulator.
> Also verified with jtreg tier1-3 tests without SHA3 instructions on aarch64-linux-gnu and x86_64-linux-gnu, to make
> sure that there's no regression.
> We used one existing JMH test for performance test: test/micro/org/openjdk/bench/java/security/MessageDigests.java
> We measured the performance benefit with an aarch64 cycle-accurate simulator.
> Patch delivers 20% - 40% performance improvement depending on specific SHA3 digest length and size of the message.
> 
> For now, this feature will not be enabled automatically for aarch64. We can auto-enable this when it is fully tested on
> real hardware.  But for the above testing purposes, this is auto-enabled when the corresponding hardware feature is
> detected.

Fei Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains
13 commits:

 - Fix trailing whitespace issue reported by jcheck
 - Merge master
 - Merge master
 - Remove unnecessary code changes in vm_version_aarch64.cpp
 - Merge master
 - Merge master
 - Merge master
 - Merge master
 - Add sha3 instructions to cpu/aarch64/aarch64-asmtest.py and regenerate the test in assembler_aarch64.cpp:asm_check
 - Rebase
 - ... and 3 more: https://git.openjdk.java.net/jdk/compare/cdc8c401...d32c8ad7

-------------

Changes: https://git.openjdk.java.net/jdk/pull/207/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=207&range=09
  Stats: 1262 lines in 36 files changed: 1007 ins; 22 del; 233 mod
  Patch: https://git.openjdk.java.net/jdk/pull/207.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/207/head:pull/207

PR: https://git.openjdk.java.net/jdk/pull/207

From herrick at openjdk.java.net  Tue Oct 20 13:44:17 2020
From: herrick at openjdk.java.net (Andy Herrick)
Date: Tue, 20 Oct 2020 13:44:17 GMT
Subject: RFR: JDK-8254783: jpackage fails on Windows when application name
 differs =?UTF-8?B?4oCm?=
In-Reply-To: <tjY6YsGCbgcdTmGl9N76vLN0gY_AUWogOW2dbpcR-Ps=.bdbc21a9-a781-4802-93d3-3be7ceda8a73@github.com>
References: <r6qCtHMkiKtZiotu5BHVP84rqeUL_5mkVyFlBeCqC7A=.45656321-6f24-4fa1-b82d-2c9797c511cf@github.com>
 <Iw__2RxZr9CLXc4FBRkyJhVIE_lJeiasK4f34j20l5k=.04eb7da6-3d55-40e8-94a3-a728fb682258@github.com>
 <tjY6YsGCbgcdTmGl9N76vLN0gY_AUWogOW2dbpcR-Ps=.bdbc21a9-a781-4802-93d3-3be7ceda8a73@github.com>
Message-ID: <nIrTUpjQtSeP3xIjJlRLrBrC-qLrfX6H6HnjifZh-9Y=.059e34c2-918b-4ea8-95dd-c9d265cdb3d4@github.com>

On Mon, 19 Oct 2020 14:14:50 GMT, Andy Herrick <herrick at openjdk.org> wrote:

>> I think we need a test for this use case.
>
>> 
>> 
>> I think we need a test for this use case.
> 
> The automated test is complicated by the same incorrect assumptions in the test infrastructure (that installer name and
> app name are the same) . I am working on this .

@alexeysemenyukoracle
> 
> I think we need a test for this use case.

I have filed JDK-8255055 to address the test case, since it needs more extensive changes than the fix itself.

-------------

PR: https://git.openjdk.java.net/jdk/pull/720

From rriggs at openjdk.java.net  Tue Oct 20 14:35:26 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 20 Oct 2020 14:35:26 GMT
Subject: RFR: 8251989: Hex formatting and parsing utility [v6]
In-Reply-To: <yTU1KThBgWoep1dgs5_JnxJm7Gh82hsXWDNx-vNFF04=.8877db35-776f-413f-87f5-0d5d83ee0f8b@github.com>
References: <HSEn47GMS1K3g57mrTZeQk-WZHl3pKGHpX_OOf8VnsU=.740863c2-f9e4-43c4-b500-614aab4078b1@github.com>
 <seKMG87WLCuFuqEZuua-7hrmYxXeSYsoFATrMAqZMs4=.b4d97cb5-d84a-427c-9994-9292fa127e35@github.com>
 <yTU1KThBgWoep1dgs5_JnxJm7Gh82hsXWDNx-vNFF04=.8877db35-776f-413f-87f5-0d5d83ee0f8b@github.com>
Message-ID: <7TIYWy2ZWX1XkSvk5xrI-JO3pVfHBuQS88WP3891u8c=.94d0b2c5-fca4-4e5b-8674-d849a17e87e7@github.com>

On Tue, 20 Oct 2020 09:37:23 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Correct length of StringBuilder in formatHex;
>>   Correct bug in formatHex(char[], 2, 3) and add test for subranges of char[]
>
> src/java.base/share/classes/java/util/HexFormat.java line 52:
> 
>> 50:  * {@link #toHexDigits(long)}, etc.
>> 51:  * For conversions producing uppercase hexadecimal strings use {@link #withUpperCase()}.
>> 52:  *
> 
> A previous iteration had class-level text describing the range of valid hexadecimal characters. It seems to have gotten
> dropped.

The details were moved to the `toHexDigits` and `fromHexDigits` methods.
I can add a summary.

-------------

PR: https://git.openjdk.java.net/jdk/pull/482

From trebari at openjdk.java.net  Tue Oct 20 14:36:16 2020
From: trebari at openjdk.java.net (Tejpal Rebari)
Date: Tue, 20 Oct 2020 14:36:16 GMT
Subject: RFR: 8255043: Incorrectly styled copyright text
In-Reply-To: <gmKuCsi5-p4TN8bZ4CswPyFBokCuuyLRwWNAGNktarI=.c88a1093-9525-40ca-9a37-0d780240b41a@github.com>
References: <gmKuCsi5-p4TN8bZ4CswPyFBokCuuyLRwWNAGNktarI=.c88a1093-9525-40ca-9a37-0d780240b41a@github.com>
Message-ID: <CtA6WT7xZga1jTihp34QUNkSDWGbmKjloVbK2WKVeqc=.35ba1bd5-2a32-4f82-a361-fdb857d5b2ef@github.com>

On Tue, 20 Oct 2020 08:17:27 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> In some files, the copyright text is styled as a JavaDoc comment.
> Most of the affected files are tests, only one product file is affected:
> src/java.sql/share/classes/javax/sql/package-info.java
> 
> The chenge is trivial:
>  - /**
>  + /*
>     * Copyright (c)

Marked as reviewed by trebari (Committer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/759

From rriggs at openjdk.java.net  Tue Oct 20 14:40:24 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 20 Oct 2020 14:40:24 GMT
Subject: RFR: 8251989: Hex formatting and parsing utility [v6]
In-Reply-To: <yTU1KThBgWoep1dgs5_JnxJm7Gh82hsXWDNx-vNFF04=.8877db35-776f-413f-87f5-0d5d83ee0f8b@github.com>
References: <HSEn47GMS1K3g57mrTZeQk-WZHl3pKGHpX_OOf8VnsU=.740863c2-f9e4-43c4-b500-614aab4078b1@github.com>
 <seKMG87WLCuFuqEZuua-7hrmYxXeSYsoFATrMAqZMs4=.b4d97cb5-d84a-427c-9994-9292fa127e35@github.com>
 <yTU1KThBgWoep1dgs5_JnxJm7Gh82hsXWDNx-vNFF04=.8877db35-776f-413f-87f5-0d5d83ee0f8b@github.com>
Message-ID: <-Wba6yvKoGM96GeaL5kpA0xb7jRx4sohJ9qeeCDLVAY=.8545839a-c5d9-41e1-ae2c-2b6da1931560@github.com>

On Tue, 20 Oct 2020 09:44:51 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Correct length of StringBuilder in formatHex;
>>   Correct bug in formatHex(char[], 2, 3) and add test for subranges of char[]
>
> src/java.base/share/classes/java/util/HexFormat.java line 64:
> 
>> 62:  * and {@link #formatHex(Appendable, byte[]) formatHex(Appendable, byte[])}.
>> 63:  * The formatted output can be appended to {@link StringBuilder}, {@link System#out},
>> 64:  * {@link java.io.Writer}, and {@link java.io.PrintStream}, all of which are {@link Appendable}.
> 
> This seems like an arbitrary list of Appendables. Suggest to restructure the sentence to make it clear that these are
> just some common examples, and maybe drop a few.

Will re-phrase to include a list of typical Appendable classes.

> src/java.base/share/classes/java/util/HexFormat.java line 127:
> 
>> 125:  *
>> 126:  * @implSpec
>> 127:  * This class is immutable and thread-safe.
> 
> I'm curious why this is an implSpec, and not just a normative statement? HexFormat is a final class after all, there is
> just one implementation.

Good point, will remove @ImplSpec.

-------------

PR: https://git.openjdk.java.net/jdk/pull/482

From rriggs at openjdk.java.net  Tue Oct 20 14:45:25 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 20 Oct 2020 14:45:25 GMT
Subject: RFR: 8251989: Hex formatting and parsing utility [v6]
In-Reply-To: <yTU1KThBgWoep1dgs5_JnxJm7Gh82hsXWDNx-vNFF04=.8877db35-776f-413f-87f5-0d5d83ee0f8b@github.com>
References: <HSEn47GMS1K3g57mrTZeQk-WZHl3pKGHpX_OOf8VnsU=.740863c2-f9e4-43c4-b500-614aab4078b1@github.com>
 <seKMG87WLCuFuqEZuua-7hrmYxXeSYsoFATrMAqZMs4=.b4d97cb5-d84a-427c-9994-9292fa127e35@github.com>
 <yTU1KThBgWoep1dgs5_JnxJm7Gh82hsXWDNx-vNFF04=.8877db35-776f-413f-87f5-0d5d83ee0f8b@github.com>
Message-ID: <AhcxJ93QyJoBLcVd2lOPCpBKo6VBNMOeRlh8F8j8EdA=.a6c05e25-a350-4398-801d-f8832b7a09f2@github.com>

On Tue, 20 Oct 2020 10:26:59 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Correct length of StringBuilder in formatHex;
>>   Correct bug in formatHex(char[], 2, 3) and add test for subranges of char[]
>
> src/java.base/share/classes/java/util/HexFormat.java line 90:
> 
>> 88:  *     assert(byteStr.equals("7f"));
>> 89:  *     assert(b == byteVal);
>> 90:  *
> 
> I understand why this is the case, but the example is highlighting that a roundtrip from byte is not possible :-(

In the string form, the value is unsigned and not known to be a byte.
The example should reinforce that point by being explicit about casting the value back to a byte.
            byte byteVal = (byte)hex.fromHexDigits(byteStr);
            assert(byteStr.equals("7f"));
            assert(b == byteVal);```

-------------

PR: https://git.openjdk.java.net/jdk/pull/482

From jdv at openjdk.java.net  Tue Oct 20 15:43:14 2020
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Tue, 20 Oct 2020 15:43:14 GMT
Subject: RFR: 8255043: Incorrectly styled copyright text
In-Reply-To: <gmKuCsi5-p4TN8bZ4CswPyFBokCuuyLRwWNAGNktarI=.c88a1093-9525-40ca-9a37-0d780240b41a@github.com>
References: <gmKuCsi5-p4TN8bZ4CswPyFBokCuuyLRwWNAGNktarI=.c88a1093-9525-40ca-9a37-0d780240b41a@github.com>
Message-ID: <3HXa_fWqHw4PKAfkD6oo5xKl8gR5ss7yhfl87HdSuGI=.fd3fa01c-a7a1-4e13-ab60-9852ff93162d@github.com>

On Tue, 20 Oct 2020 08:17:27 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> In some files, the copyright text is styled as a JavaDoc comment.
> Most of the affected files are tests, only one product file is affected:
> src/java.sql/share/classes/javax/sql/package-info.java
> 
> The chenge is trivial:
>  - /**
>  + /*
>     * Copyright (c)

Marked as reviewed by jdv (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/759

From naoto at openjdk.java.net  Tue Oct 20 16:18:25 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 20 Oct 2020 16:18:25 GMT
Subject: RFR: 8254982: (tz) Upgrade time-zone data to tzdata2020c [v2]
In-Reply-To: <Rss6QPAz7tyhWg3P2UDhp_5TEfNvndQ4pko5H4QSNeg=.34d143c9-416c-47e6-a766-175c31c410fa@github.com>
References: <rQR51lGOpSaH5qywIqXV9ymJ36TbsUYzcurNCsvZ7OE=.21381473-7776-4ea5-8a03-734e1b3b11d9@github.com>
 <Rss6QPAz7tyhWg3P2UDhp_5TEfNvndQ4pko5H4QSNeg=.34d143c9-416c-47e6-a766-175c31c410fa@github.com>
Message-ID: <u1E_ohihA7QJqWM-i5w6IW0UlOvACuBbRSI9gbcmon8=.7982aa21-1d75-4422-ae27-b76b46cc0fcd@github.com>

On Tue, 20 Oct 2020 11:39:36 GMT, Kiran Sidhartha Ravikumar <kravikumar at openjdk.org> wrote:

>> Hi Guys,
>> 
>> Please review the integration of tzdata2020c to JDK.
>> 
>> Details regarding the change can be viewed at - https://mm.icann.org/pipermail/tz-announce/2020-October/000060.html
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8254982
>> 
>> Along with it, there is a test fix for https://bugs.openjdk.java.net/browse/JDK-8254865, With tzdata2020b, the test
>> fails for the mentioned zones expecting "PST" but JDK has Zone names for "MST" for JRE locale provider. Since the
>> purpose of the test is to get any GMT-08:00 time zone, I have excluded those zones from the test.  Please let me know
>> if the changes are good to push.
>> Thanks,
>> Kiran
>
> Kiran Sidhartha Ravikumar has updated the pull request with a new target base due to a merge or a rebase. The
> incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three
> additional commits since the last revision:
>  - 8254982: Adding comments for removal of zones in BasicDateTime.java
>  - Merge remote-tracking branch 'origin/master' into JDK-8254982
>  - 8254982: (tz) Upgrade time-zone data to tzdata2020c

Looks good. Thank you for the changes.

-------------

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/747

From psandoz at openjdk.java.net  Tue Oct 20 16:20:19 2020
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Tue, 20 Oct 2020 16:20:19 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v4]
In-Reply-To: <gC1r5U7FYGeYMGD5Kv0z9cUsqJ1P5mQRbXwbAP6MQ78=.5bfa32b0-8afa-492d-9499-2cfabf0f9352@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <45FtTQB1m6HyZSASY42STMkQffIWlVPibWn9_r00xYs=.daad2653-2571-491f-8dd7-5954fe4ece00@github.com>
 <u6HLR2PyvWgYbA58W3bCF4n38tpwQu2-ujPMvGpyyuo=.5a80f17c-83d5-4dc9-bad0-00e679fdd4be@github.com>
 <7-p-Kc9lQyyuoWdNtmgbXbwkxsgk4oQGKmFSCcMpvnU=.97810c01-3200-4767-bbd4-35d53c2bc5ca@github.com>
 <6Voyfr_s-ieyRA-8Rtvvpz7tkhhicA8sY2d2KTp3Kmw=.fa256bae-2143-4b43-bfea-5837ad31eb6a@github.com>
 <fFQfDMqdwosVGzcaJfblklUy1nPsEdZJI7ALmKq9XJs=.e869160e-76e7-4a6b-b45b-e9763d1ad06f@github.com>
 <vKcE4CeascBAQGeyu6is0Va0_k4aTrvgU41cjhG6Wdo=.4078814f-06ed-4978-9fcd-a4a5148c2bdc@github.com>
 <wQ6YtDhYzmcgpTUP4uFfBCo8UFWZENtTARWt_LTqPug=.30bc3fdb-f963-4918-ae4b-0fe174c38a23@github.com>
 <jqzI94j7kygJyD9HWwq5d3q3LGztS5FAdYm5Ix1QdjE=.808de4e6-0f6d-4e17-b807-25ef89e92541@github.com>
 <7XjzEn5DggliDrvjhrGwXZL5r4lsqeGF9SGLmRr5L84=.a4481a62-4ecf-4e3f-98f3-70e548c67b52@github.com>
 <9y5m4zfsDZMdIZ6CT38BzO0tpFMuFxUswAb
 pjfDny-w=.44c7ada7-bf77-45f1-b5a6-b542731d6685@github.com>
 <gC1r5U7FYGeYMGD5Kv0z9cUsqJ1P5mQRbXwbAP6MQ78=.5bfa32b0-8afa-492d-9499-2cfabf0f9352@github.com>
Message-ID: <AzmoRxvROeSYxkNZG2UeaQkmIVdhbFve7-NMC2bvJOk=.f92a94a2-eb5e-48cf-a298-81a334ad5eee@github.com>

On Thu, 15 Oct 2020 17:58:29 GMT, CoreyAshford <github.com+51754783+CoreyAshford at openjdk.org> wrote:

>> Please update
>> [compiler/graalunit/HotspotTest.java](https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/compiler/graalunit/HotspotTest.java),
>> and add the intrinsic signature.
>
>> Please update
>> [compiler/graalunit/HotspotTest.java](https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/compiler/graalunit/HotspotTest.java),
>> and add the intrinsic signature.
> 
> It looks like that is auto-generated, but I will figure out what to modify so that the signature is added.

@CoreyAshford apologies i pointed to the "umbrella" test that runs Graal unit tests, the actual test is
[CheckGraalIntrinsics](https://github.com/openjdk/jdk/blob/master/src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/CheckGraalIntrinsics.java)

See this PR for an example: https://github.com/openjdk/jdk/pull/762

-------------

PR: https://git.openjdk.java.net/jdk/pull/293

From mchung at openjdk.java.net  Tue Oct 20 16:38:31 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 20 Oct 2020 16:38:31 GMT
Subject: RFR: 8188055: (ref) Add Reference::refersTo predicate [v5]
In-Reply-To: <VcqdD5owO8PgUmW8zfisLrc1eFYAeNOonJ6UtYt3YKI=.42cae436-5ce7-4f51-9513-c28164242328@github.com>
References: <D4HSg8FT20Eaxk5KJkkw0GgETSxRkBn1ipS3Dt0kPto=.e4bab078-2e04-4413-90cb-9bfafb2a6831@github.com>
 <FHx-oBhE254DZWHhg2RTKjZn_-yYN5xadTW7GXhTxzM=.7e6a46fa-5259-428c-b725-81b4fe48b8f7@github.com>
 <Ch2xqBrcg76WqiK0RVUEl_XcN4o7X4bvo44RPDDi3O8=.852fb1b6-77f5-4aaa-9ed6-bdee28ec8eb3@github.com>
 <E8OiCIWFPwu7ircN0UQiSG8yJ2QrbFNdYT_MHLHtKcQ=.85cd2acb-d656-4398-b7bf-1f2e9cc6bc58@github.com>
 <rDPsYfi057gmn-cIG04-EwHqFKj2vST5h-_PsJpnFj4=.0ecbdd68-329b-4376-a7ea-1be23206aa9b@github.com>
 <Nks-e8NMGE0VeZQF4zKg73QJt_Da3mm_Vom49v9odio=.ba79800e-3e32-465b-a516-2316b2bc4169@github.com>
 <VcqdD5owO8PgUmW8zfisLrc1eFYAeNOonJ6UtYt3YKI=.42cae436-5ce7-4f51-9513-c28164242328@github.com>
Message-ID: <FCKXn6qliafrA3jrNwx6yosTt0H_cDmU-j54yiNtyuw=.d5752bd9-74e0-4c15-b140-e98dd1b82804@github.com>

On Tue, 20 Oct 2020 05:22:57 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> @kimbarrett  your reworded text is okay.  I think "if it initially had some other referent value" can be dropped.
>> 
>> For a `Reference` constructed with a `null` referent, we can clarify in the spec that such reference object will never
>> get cleared and enqueued.  I suggest to file a separate issue to follow up.
>
>> @kimbarrett your reworded text is okay. I think "if it initially had some other referent value" can be dropped.
>> 
>> For a `Reference` constructed with a `null` referent, we can clarify in the spec that such reference object will never
>> get cleared and enqueued. I suggest to file a separate issue to follow up.
> 
> I don't think that clause can be dropped, because of explicit clearing (by clear() or enqueue()) rather than by the
> GC.  If the reference was constructed with a null referent, ref.refersTo(null) cannot tell whether ref.clear() has been
> called.

> Mandy's comment implied that references with a null referent never get enqueued. Otherwise when would they get
> enqueued? There would be nothing to trigger it.

Sorry I should have been clearer.    What I try to say is that `Reference(null)`
will never be cleared and enqueued by GC since its referent is `null`.
Kim is right that `Reference(null)` can be explicitly cleared and enqueued
via `Reference::enqueue`.    `Reference::clear` on such an "empty" reference
object is essentially a no-op.

> > But the more we discuss this the more I think allowing an initial null referent was a mistake in the first place. :(
> 
> I agree, but here we are. Very hard to know what the compatibility impact of changing that would be.

There are existing use cases depending on `Reference(null)` for example as a special
instance be an empty reference or the head of a doubly-linked list of references.
This was discussed two years ago [1].

[1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2018-July/054325.html

-------------

PR: https://git.openjdk.java.net/jdk/pull/498

From github.com+51754783+coreyashford at openjdk.java.net  Tue Oct 20 16:45:23 2020
From: github.com+51754783+coreyashford at openjdk.java.net (CoreyAshford)
Date: Tue, 20 Oct 2020 16:45:23 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v4]
In-Reply-To: <AzmoRxvROeSYxkNZG2UeaQkmIVdhbFve7-NMC2bvJOk=.f92a94a2-eb5e-48cf-a298-81a334ad5eee@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <45FtTQB1m6HyZSASY42STMkQffIWlVPibWn9_r00xYs=.daad2653-2571-491f-8dd7-5954fe4ece00@github.com>
 <u6HLR2PyvWgYbA58W3bCF4n38tpwQu2-ujPMvGpyyuo=.5a80f17c-83d5-4dc9-bad0-00e679fdd4be@github.com>
 <7-p-Kc9lQyyuoWdNtmgbXbwkxsgk4oQGKmFSCcMpvnU=.97810c01-3200-4767-bbd4-35d53c2bc5ca@github.com>
 <6Voyfr_s-ieyRA-8Rtvvpz7tkhhicA8sY2d2KTp3Kmw=.fa256bae-2143-4b43-bfea-5837ad31eb6a@github.com>
 <fFQfDMqdwosVGzcaJfblklUy1nPsEdZJI7ALmKq9XJs=.e869160e-76e7-4a6b-b45b-e9763d1ad06f@github.com>
 <vKcE4CeascBAQGeyu6is0Va0_k4aTrvgU41cjhG6Wdo=.4078814f-06ed-4978-9fcd-a4a5148c2bdc@github.com>
 <wQ6YtDhYzmcgpTUP4uFfBCo8UFWZENtTARWt_LTqPug=.30bc3fdb-f963-4918-ae4b-0fe174c38a23@github.com>
 <jqzI94j7kygJyD9HWwq5d3q3LGztS5FAdYm5Ix1QdjE=.808de4e6-0f6d-4e17-b807-25ef89e92541@github.com>
 <7XjzEn5DggliDrvjhrGwXZL5r4lsqeGF9SGLmRr5L84=.a4481a62-4ecf-4e3f-98f3-70e548c67b52@github.com>
 <9y5m4zfsDZMdIZ6CT38BzO0tpFMuFxUswAb
 pjfDny-w=.44c7ada7-bf77-45f1-b5a6-b542731d6685@github.com>
 <gC1r5U7FYGeYMGD5Kv0z9cUsqJ1P5mQRbXwbAP6MQ78=.5bfa32b0-8afa-492d-9499-2cfabf0f9352@github.com>
 <AzmoRxvROeSYxkNZG2UeaQkmIVdhbFve7-NMC2bvJOk=.f92a94a2-eb5e-48cf-a298-81a334ad5eee@github.com>
Message-ID: <_Kp2I32RPuFG2TsngEkrL1CEHpYFbT5k2yLSpJ1r4-w=.d6734741-0392-4cc7-acef-81367a598ff4@github.com>

On Tue, 20 Oct 2020 16:17:15 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>>> Please update
>>> [compiler/graalunit/HotspotTest.java](https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/compiler/graalunit/HotspotTest.java),
>>> and add the intrinsic signature.
>> 
>> It looks like that is auto-generated, but I will figure out what to modify so that the signature is added.
>
> @CoreyAshford apologies i pointed to the "umbrella" test that runs Graal unit tests, the actual test is
> [CheckGraalIntrinsics](https://github.com/openjdk/jdk/blob/master/src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/CheckGraalIntrinsics.java)
> See this PR for an example: https://github.com/openjdk/jdk/pull/762

> @CoreyAshford apologies i pointed to the "umbrella" test that runs Graal unit tests, the actual test is
> [CheckGraalIntrinsics](https://github.com/openjdk/jdk/blob/master/src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/CheckGraalIntrinsics.java)
> See this PR for an example: #762

Thank you for providing the more accurate location.  I will push commits to fix this a bit later today.

-------------

PR: https://git.openjdk.java.net/jdk/pull/293

From vladimir.kozlov at oracle.com  Tue Oct 20 17:01:12 2020
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 20 Oct 2020 10:01:12 -0700
Subject: Howto replicate failure of 8254790?
In-Reply-To: <BYAPR11MB35434D70D8B62F45068ADA7AEF1F0@BYAPR11MB3543.namprd11.prod.outlook.com>
References: <4bd7e9f73ea24ae09f1bb0f1808ce5a7@EX13D46EUB003.ant.amazon.com>
 <661485ab-7de7-26cb-b2b1-3a4f643125eb@oracle.com>
 <617f010e-629d-7329-ac72-dce797bf3075@oracle.com>
 <d6061b53d0854305a1fdb1a5ea7a019c@EX13D46EUB003.ant.amazon.com>
 <efc3cbff-2e42-cf57-c753-f9d30b68d394@oracle.com>
 <BYAPR11MB35434D70D8B62F45068ADA7AEF1F0@BYAPR11MB3543.namprd11.prod.outlook.com>
Message-ID: <0a0481a0-5f2d-e594-dd71-aa84103bb4d4@oracle.com>

Yes, I saw it too but I was not sure because we never hit the issue with Unicode string index intrinsic.
An other thing is we see the failure only on MacOS.

I also want someone to decode asm dump I provided in bug to see actual instructions where it happened.

Vladimir K

On 10/19/20 5:38 PM, Viswanathan, Sandhya wrote:
> Hi Jason,
> 
> I think I found the problem looking at the error log from Vladimir Kozlov. In stringL_indexof_char() function, the following snippet is the cause of problem:
> 
> 2807   bind(FOUND_CHAR);
> 2808   if (UseAVX >= 2) {
> 2809     vpmovmskb(tmp, vec3);
> 2810   } else {
> 2811     pmovmskb(tmp, vec3);
> 2812   }
> 2813   bsfl(ch, tmp);
> 2814   addl(result, ch);                         <====   The problem is here
> 2815
> 2816   bind(FOUND_SEQ_CHAR);
> 2817   subptr(result, str1);
> 
> The line addl(result, ch) should have been addptr(result, ch).
> 
> The same problem exists in the Unicode string index of char intrinsic as well and need to be fixed.
> 
> Hope this helps.
> 
> Best Regards,
> Sandhya
> 
> -----Original Message-----
> From: hotspot-compiler-dev <hotspot-compiler-dev-retn at openjdk.java.net> On Behalf Of Vladimir Kozlov
> Sent: Thursday, October 15, 2020 3:59 PM
> To: Tatton, Jason <jptatton at amazon.com>; David Holmes <david.holmes at oracle.com>; hotspot-compiler-dev at openjdk.java.net; core-libs-dev at openjdk.java.net
> Subject: Re: Howto replicate failure of 8254790?
> 
> Hi Jason,
> 
> I added surrounding instructions dump from hs_err file we have so you can reconstruct x86 assembler from it.
> 
> If you look on si_addr: 0x00000000e41d2718 which case memory map failure, it looks like R8 =0x00000007e41d2700 is an
> oop: [B with upper 32-bits zeroed. It seems uppers 32-bits of address were cut.
> 
> But I don't see it can happens in stringL_indexof_char() sub. You correctly used movptr() and addptr() instructions.
> 
> Vladimir K
> 
> On 10/15/20 2:10 PM, Tatton, Jason wrote:
>> Thanks Vladimir and David, I have access to a new macbook with an Intel i7-9750H (supports AVX2) so I will try on that.
>>
>> -----Original Message-----
>> From: Vladimir Kozlov <vladimir.kozlov at oracle.com>
>> Sent: 15 October 2020 20:25
>> To: David Holmes <david.holmes at oracle.com>; Tatton, Jason
>> <jptatton at amazon.com>; hotspot-compiler-dev at openjdk.java.net;
>> core-libs-dev at openjdk.java.net
>> Subject: RE: [EXTERNAL] Howto replicate failure of 8254790?
>>
>> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
>>
>>
>>
>> Note, we have old Mac machines in our testing env:
>> cx8, cmov, fxsr, ht, mmx, 3dnowpref, sse, sse2, sse3, ssse3, sse4.1,
>> sse4.2, popcnt, lzcnt, tsc, tscinvbit, avx, avx2, aes, erms, clmul,
>> bmi1, bmi2, rtm, adx, fma, vzeroupper, clflush, clflushopt
>>
>> Use -XX:UseAVX=2
>>
>> But I was not able reproduce failure on my Skylake Linux machine even with -XX:UseAVX=2. Maybe there are other factors on MacOS.
>>
>> Regards,
>> Vladimir K
>>
>> On 10/14/20 5:48 PM, David Holmes wrote:
>>> Hi Jason,
>>>
>>> On 15/10/2020 10:42 am, Tatton, Jason wrote:
>>>> Hi all,
>>>>
>>>>
>>>>
>>>> I am trying to replicate the failure of the tier2 test mentioned in
>>>> 8254790<https://bugs.openjdk.java.net/browse/JDK-8254790> but I am
>>>> only seeing it pass under an x86 linux machine. Are there any specific architectural constraints under which this test should be run in order to make it fail?
>>>
>>> It failed on a Mac, not Linux.
>>>
>>> Cheers,
>>> David
>>>
>>>>
>>>>
>>>> I am running the test via: make test TEST="test/jdk/javax/xml/crypto/dsig/GenerationTests.java"
>>>>
>>>>
>>>>
>>>> Note that I am running the test against master without the commit:
>>>> "8254792: Disable intrinsic StringLatin1.indexOf until 8254790 is fixed" which disables the intrinsic that is causing the test to fail.
>>>>
>>>>
>>>>
>>>> Thanks
>>>> --
>>>> Jason
>>>>

From vlivanov at openjdk.java.net  Tue Oct 20 17:16:11 2020
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Tue, 20 Oct 2020 17:16:11 GMT
Subject: RFR: 8255022: Documentation missing for Vector API zero methods
In-Reply-To: <WKOOZsYoqfzmWyAfFbtHKUYgxax7JsQi3bn7IZ-R3D0=.76ad983a-e525-4f8c-a293-0ef3b4b7a987@github.com>
References: <WKOOZsYoqfzmWyAfFbtHKUYgxax7JsQi3bn7IZ-R3D0=.76ad983a-e525-4f8c-a293-0ef3b4b7a987@github.com>
Message-ID: <OXUgnFLxYkCA7R1RzmoHfxtgxWw3ybOm2xHDW3gRuXo=.b633d4e6-bbc2-484d-b573-0469deb25ca5@github.com>

On Mon, 19 Oct 2020 19:43:13 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> The zero methods on `IntVector` and all other specializations are missing documentation.

Looks good.

-------------

Marked as reviewed by vlivanov (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/748

From mcimadamore at openjdk.java.net  Tue Oct 20 17:23:26 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 20 Oct 2020 17:23:26 GMT
Subject: RFR: 8254231: Implementation of Foreign Linker API (Incubator)
 [v7]
In-Reply-To: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
References: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
Message-ID: <Rxu6c37o5dBPtGxju77Y5NfjLQNIE1yRZw-bnQz1n0k=.7c929e86-7513-49d7-90fa-1d997963050f@github.com>

> This patch contains the changes associated with the first incubation round of the foreign linker access API incubation
> (see JEP 389 [1]). This work is meant to sit on top of the foreign memory access support (see JEP 393 [2] and
> associated pull request [3]).
> The main goal of this API is to provide a way to call native functions from Java code without the need of intermediate
> JNI glue code. In order to do this, native calls are modeled through the MethodHandle API. I suggest reading the
> writeup [4] I put together few weeks ago, which illustrates what the foreign linker support is, and how it should be
> used by clients.  Disclaimer: the pull request mechanism isn't great at managing *dependent* reviews. For this reasons,
> I'm attaching a webrev which contains only the differences between this PR and the memory access PR. I will be
> periodically uploading new webrevs, as new iterations come out, to try and make the life of reviewers as simple as
> possible.  A big thank to Jorn Vernee and Vladimir Ivanov - they are the main architects of all the hotspot changes you
> see here, and without their help, the foreign linker support wouldn't be what it is today. As usual, a big thank to
> Paul Sandoz, who provided many insights (often by trying the bits first hand).  Thanks Maurizio
> Webrev:
> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/webrev
> 
> Javadoc:
> 
> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/javadoc/jdk/incubator/foreign/package-summary.html
> 
> Specdiff (relative to [3]):
> 
> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/specdiff_delta/overview-summary.html
> 
> CSR:
> 
> https://bugs.openjdk.java.net/browse/JDK-8254232
> 
> 
> 
> ### API Changes
> 
> The API changes are actually rather slim:
> 
> * `LibraryLookup`
>   * This class allows clients to lookup symbols in native libraries; the interface is fairly simple; you can load a library
>     by name, or absolute path, and then lookup symbols on that library.
> * `FunctionDescriptor`
>   * This is an abstraction that is very similar, in spirit, to `MethodType`; it is, at its core, an aggregate of memory
>     layouts for the function arguments/return type. A function descriptor is used to describe the signature of a native
>     function.
> * `CLinker`
>   * This is the real star of the show. A `CLinker` has two main methods: `downcallHandle` and `upcallStub`; the first takes
>     a native symbol (as obtained from `LibraryLookup`), a `MethodType` and a `FunctionDescriptor` and returns a
>     `MethodHandle` instance which can be used to call the target native symbol. The second takes an existing method handle,
>     and a `FunctionDescriptor` and returns a new `MemorySegment` corresponding to a code stub allocated by the VM which
>     acts as a trampoline from native code to the user-provided method handle. This is very useful for implementing upcalls.
>    * This class also contains the various layout constants that should be used by clients when describing native signatures
>      (e.g. `C_LONG` and friends); these layouts contain additional ABI classfication information (in the form of layout
>      attributes) which is used by the runtime to *infer* how Java arguments should be shuffled for the native call to take
>      place.
>   * Finally, this class provides some helper functions e.g. so that clients can convert Java strings into C strings and
>     back.
> * `NativeScope`
>   * This is an helper class which allows clients to group together logically related allocations; that is, rather than
>     allocating separate memory segments using separate *try-with-resource* constructs, a `NativeScope` allows clients to
>     use a _single_ block, and allocate all the required segments there. This is not only an usability boost, but also a
>     performance boost, since not all allocation requests will be turned into `malloc` calls.
> * `MemorySegment`
>   * Only one method added here - namely `handoff(NativeScope)` which allows a segment to be transferred onto an existing
>     native scope.
> 
> ### Safety
> 
> The foreign linker API is intrinsically unsafe; many things can go wrong when requesting a native method handle. For
> instance, the description of the native signature might be wrong (e.g. have too many arguments) - and the runtime has,
> in the general case, no way to detect such mismatches. For these reasons, obtaining a `CLinker` instance is
> a *restricted* operation, which can be enabled by specifying the usual JDK property `-Dforeign.restricted=permit` (as
> it's the case for other restricted method in the foreign memory API).  ### Implementation changes  The Java changes
> associated with `LibraryLookup` are relative straightforward; the only interesting thing to note here is that library
> loading does _not_ depend on class loaders, so `LibraryLookup` is not subject to the same restrictions which apply to
> JNI library loading (e.g. same library cannot be loaded by different classloaders).  As for `NativeScope` the changes
> are again relatively straightforward; it is an API which sits neatly on top of the foreign meory access API, providing
> some kind of allocation service which shares the same underlying memory segment(s), and turns an allocation request
> into a segment slice, which is a much less expensive operation. `NativeScope` comes in two variants: there are native
> scopes for which the allocation size is known a priori, and native scopes which can grow - these two schemes are
> implemented by two separate subclasses of `AbstractNativeScopeImpl`.  Of course the bulk of the changes are to support
> the `CLinker` downcall/upcall routines. These changes cut pretty deep into the JVM; I'll briefly summarize the goal of
> some of this changes - for further details, Jorn has put together a detailed writeup which explains the rationale
> behind the VM support, with some references to the code [5].  The main idea behind foreign linker is to infer, given a
> Java method type (expressed as a `MethodType` instance) and the description of the signature of a native function
> (expressed as a `FunctionDescriptor` instance) a _recipe_ that can be used to turn a Java call into the corresponding
> native call targeting the requested native function.  This inference scheme can be defined in a pretty straightforward
> fashion by looking at the various ABI specifications (for instance, see [6] for the SysV ABI, which is the one used on
> Linux/Mac). The various `CallArranger` classes, of which we have a flavor for each supported platform, do exactly that
> kind of inference.  For the inference process to work, we need to attach extra information to memory layouts; it is no
> longer sufficient to know e.g. that a layout is 32/64 bits - we need to know whether it is meant to represent a
> floating point value, or an integral value; this knowledge is required because floating points are passed in different
> registers by most ABIs. For this reason, `CLinker` offers a set of pre-baked, platform-dependent layout constants which
> contain the required classification attributes (e.g. a `Clinker.TypeKind` enum value). The runtime extracts this
> attribute, and performs classification accordingly.  A native call is decomposed into a sequence of basic, primitive
> operations, called `Binding` (see the great javadoc on the `Binding.java` class for more info). There are many such
> bindings - for instance the `Move` binding is used to move a value into a specific machine register/stack slot. So, the
> main job of the various `CallingArranger` classes is to determine, given a Java `MethodType` and `FunctionDescriptor`
> what is the set of bindings associated with the downcall/upcall.  At the heart of the foreign linker support is the
> `ProgrammableInvoker` class. This class effectively generates a `MethodHandle` which follows the steps described by the
> various bindings obtained by `CallArranger`. There are actually various strategies to interpret these bindings - listed
> below:
> * basic intepreted mode; in this mode, all bindings are interpreted using a stack-based machine written in Java (see
>   `BindingInterpreter`), except for the `Move` bindings. For these bindings, the move is implemented by allocating
>   a *buffer* (whose size is ABI specific) and by moving all the lowered values into positions within this buffer. The
>   buffer is then passed to a piece of assembly code inside the VM which takes values from the buffer and moves them in
>   their expected registers/stack slots (note that each position in the buffer corresponds to a different register). This
>   is the most general invocation mode, the more "customizable" one, but also the slowest - since for every call there is
>   some extra allocation which takes place.
> 
> * specialized interpreted mode; same as before, but instead of interpreting the bindings with a stack-based interpreter,
>   we generate a method handle chain which effectively interprets all the bindings (again, except `Move` ones).
> 
> * intrinsified mode; this is typically used in combination with the specialized interpreted mode described above
>   (although it can also be used with the Java-based binding interpreter). The goal here is to remove the buffer
>   allocation and copy by introducing an additional JVM intrinsic. If a native call recipe is constant (e.g. the set of
>   bindings is constant, which is probably the case if the native method handle is stored in a `static`, `final` field),
>   then the VM can generate specialized assembly code which interprets the `Move` binding without the need to go for an
>   intermediate buffer. This gives us back performances that are on par with JNI.
> 
> For upcalls, the support is not (yet) as advanced, and only the basic interpreted mode is available there. We plan to
> add support for intrinsified modes there as well, which should considerably boost perfomances (probably well beyond
> what JNI can offer at the moment, since the upcall support in JNI is not very well optimized).  Again, for more
> readings on the internals of the foreign linker support, please refer to [5].
> #### Test changes
> 
> Many new tests have been added to validate the foreign linker support; we have high level tests (see `StdLibTest`)
> which aim at testing the linker from the perspective of code that clients could write. But we also have deeper
> combinatorial tests (see `TestUpcall` and `TestDowncall`) which are meant to stress every corner of the ABI
> implementation. There are also some great tests (see the `callarranger` folder) which test the various `CallArranger`s
> for all the possible platforms; these tests adopt more of a white-box approach - that is, instead of treating the
> linker machinery as a black box and verify that the support works by checking that the native call returned the results
> we expected, these tests aims at checking that the set of bindings generated by the call arranger is correct. This also
> mean that we can test the classification logic for Windows, Mac and Linux regardless of the platform we're executing
> on.  Some additional microbenchmarks have been added to compare the performances of downcall/upcall with JNI.  [1] -
> https://openjdk.java.net/jeps/389 [2] - https://openjdk.java.net/jeps/393 [3] -
> https://git.openjdk.java.net/jdk/pull/548 [4] -
> https://github.com/openjdk/panama-foreign/blob/foreign-jextract/doc/panama_ffi.md [5] -
> http://cr.openjdk.java.net/~jvernee/docs/Foreign-abi%20downcall%20intrinsics%20technical%20description.html

Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request
now contains 25 commits:

 - Merge branch 'master' into 8254231_linker
 - Fix incorrect capitalization in one copyright header
 - Update copyright years, and add classpath exception to files that were missing it
 - Use separate constants for native invoker code size
 - Re-add file erroneously deleted (detected as rename)
 - Re-add erroneously removed files
 - Merge branch 'master' into 8254231_linker
   
   - Fix tests
 - Fix more whitespaces
 - Fix whitespaces
 - Remove rejected file
 - ... and 15 more: https://git.openjdk.java.net/jdk/compare/cb6167b2...502bd980

-------------

Changes: https://git.openjdk.java.net/jdk/pull/634/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=634&range=06
  Stats: 75609 lines in 264 files changed: 72724 ins; 1608 del; 1277 mod
  Patch: https://git.openjdk.java.net/jdk/pull/634.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/634/head:pull/634

PR: https://git.openjdk.java.net/jdk/pull/634

From sandhya.viswanathan at intel.com  Tue Oct 20 17:27:10 2020
From: sandhya.viswanathan at intel.com (Viswanathan, Sandhya)
Date: Tue, 20 Oct 2020 17:27:10 +0000
Subject: Howto replicate failure of 8254790?
In-Reply-To: <0a0481a0-5f2d-e594-dd71-aa84103bb4d4@oracle.com>
References: <4bd7e9f73ea24ae09f1bb0f1808ce5a7@EX13D46EUB003.ant.amazon.com>
 <661485ab-7de7-26cb-b2b1-3a4f643125eb@oracle.com>
 <617f010e-629d-7329-ac72-dce797bf3075@oracle.com>
 <d6061b53d0854305a1fdb1a5ea7a019c@EX13D46EUB003.ant.amazon.com>
 <efc3cbff-2e42-cf57-c753-f9d30b68d394@oracle.com>
 <BYAPR11MB35434D70D8B62F45068ADA7AEF1F0@BYAPR11MB3543.namprd11.prod.outlook.com>
 <0a0481a0-5f2d-e594-dd71-aa84103bb4d4@oracle.com>
Message-ID: <BYAPR11MB3543DA6BACC9E5EDFAA04F24EF1F0@BYAPR11MB3543.namprd11.prod.outlook.com>

 Hi Vladimir,

I analyzed the instruction dump yesterday to find out where the issue is. I have attached it to the bug report as 8254790.asm:
https://bugs.openjdk.java.net/browse/JDK-8254790

The crash is reported at:
100:       450FB64C1810             movzx r9d, byte ptr [r8+rbx*1+0x10]

Which is just after the intrinsics and uses the rbx register (containing the index of char from the intrinsic).

RBX has the large value 0xfffffff900000008 instead of 8.  The length of the string is 34 bytes. The match is found in first 32 bytes at index 8.
After doing the 32 bytes with the following instructions:
6b:       C5FE6F13                 vmovdqu ymm2, ymmword ptr [rbx]
6f:       C5ED74D1                 vpcmpeqb ymm2, ymm2, ymm1
73:       C4E27D17C2               vptest ymm0, ymm2
78:       0F8369000000             jnb 0xe7
The control goes to 0xe7.

The code snippet at 0xe7 is:
e7:       C5FDD7CA                 vpmovmskb ecx, ymm2
eb:       0FBCC1                   bsf eax, ecx
ee:       03D8                     add ebx, eax
f0:       482BDF                   sub rbx, rdi
f3:       0F1F4000                 nop dword ptr [rax], eax
f7:       413BDB                   cmp ebx, r11d
fa:       0F83DF290000             jnb 0x2adf
100:       450FB64C1810             movzx r9d, byte ptr [r8+rbx*1+0x10]

After vpmovmskb, the bit mask in ecx is 0x1100, showing the match at 8th and 9th byte.
The register rbx at this point must be holding address to the base of array: 0x00000007e41d2700 same as rdi.
Bsf puts 8 in eax. 
Then 8 is added to ebx instead of rbx using 32-bit add, making upper 32 bits as 0, resulting in rbx = 0xe41d2708. 
If the add was 64-bit add, everything would have worked well.
Then sub rbx, rdi results in 0xe41d2708 - 0x00000007e41d2700 = 0xFFFFFFF900000008 being loaded in rbx.
This is the value we see at crash.

Best Regards,
Sandhya


-----Original Message-----
From: Vladimir Kozlov <vladimir.kozlov at oracle.com> 
Sent: Tuesday, October 20, 2020 10:01 AM
To: Viswanathan, Sandhya <sandhya.viswanathan at intel.com>; Tatton, Jason <jptatton at amazon.com>; David Holmes <david.holmes at oracle.com>; hotspot-compiler-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; Hohensee, Paul <hohensee at amazon.com>
Subject: Re: Howto replicate failure of 8254790?

Yes, I saw it too but I was not sure because we never hit the issue with Unicode string index intrinsic.
An other thing is we see the failure only on MacOS.

I also want someone to decode asm dump I provided in bug to see actual instructions where it happened.

Vladimir K

On 10/19/20 5:38 PM, Viswanathan, Sandhya wrote:
> Hi Jason,
> 
> I think I found the problem looking at the error log from Vladimir Kozlov. In stringL_indexof_char() function, the following snippet is the cause of problem:
> 
> 2807   bind(FOUND_CHAR);
> 2808   if (UseAVX >= 2) {
> 2809     vpmovmskb(tmp, vec3);
> 2810   } else {
> 2811     pmovmskb(tmp, vec3);
> 2812   }
> 2813   bsfl(ch, tmp);
> 2814   addl(result, ch);                         <====   The problem is here
> 2815
> 2816   bind(FOUND_SEQ_CHAR);
> 2817   subptr(result, str1);
> 
> The line addl(result, ch) should have been addptr(result, ch).
> 
> The same problem exists in the Unicode string index of char intrinsic as well and need to be fixed.
> 
> Hope this helps.
> 
> Best Regards,
> Sandhya
> 
> -----Original Message-----
> From: hotspot-compiler-dev 
> <hotspot-compiler-dev-retn at openjdk.java.net> On Behalf Of Vladimir 
> Kozlov
> Sent: Thursday, October 15, 2020 3:59 PM
> To: Tatton, Jason <jptatton at amazon.com>; David Holmes 
> <david.holmes at oracle.com>; hotspot-compiler-dev at openjdk.java.net; 
> core-libs-dev at openjdk.java.net
> Subject: Re: Howto replicate failure of 8254790?
> 
> Hi Jason,
> 
> I added surrounding instructions dump from hs_err file we have so you can reconstruct x86 assembler from it.
> 
> If you look on si_addr: 0x00000000e41d2718 which case memory map 
> failure, it looks like R8 =0x00000007e41d2700 is an
> oop: [B with upper 32-bits zeroed. It seems uppers 32-bits of address were cut.
> 
> But I don't see it can happens in stringL_indexof_char() sub. You correctly used movptr() and addptr() instructions.
> 
> Vladimir K
> 
> On 10/15/20 2:10 PM, Tatton, Jason wrote:
>> Thanks Vladimir and David, I have access to a new macbook with an Intel i7-9750H (supports AVX2) so I will try on that.
>>
>> -----Original Message-----
>> From: Vladimir Kozlov <vladimir.kozlov at oracle.com>
>> Sent: 15 October 2020 20:25
>> To: David Holmes <david.holmes at oracle.com>; Tatton, Jason 
>> <jptatton at amazon.com>; hotspot-compiler-dev at openjdk.java.net;
>> core-libs-dev at openjdk.java.net
>> Subject: RE: [EXTERNAL] Howto replicate failure of 8254790?
>>
>> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
>>
>>
>>
>> Note, we have old Mac machines in our testing env:
>> cx8, cmov, fxsr, ht, mmx, 3dnowpref, sse, sse2, sse3, ssse3, sse4.1, 
>> sse4.2, popcnt, lzcnt, tsc, tscinvbit, avx, avx2, aes, erms, clmul, 
>> bmi1, bmi2, rtm, adx, fma, vzeroupper, clflush, clflushopt
>>
>> Use -XX:UseAVX=2
>>
>> But I was not able reproduce failure on my Skylake Linux machine even with -XX:UseAVX=2. Maybe there are other factors on MacOS.
>>
>> Regards,
>> Vladimir K
>>
>> On 10/14/20 5:48 PM, David Holmes wrote:
>>> Hi Jason,
>>>
>>> On 15/10/2020 10:42 am, Tatton, Jason wrote:
>>>> Hi all,
>>>>
>>>>
>>>>
>>>> I am trying to replicate the failure of the tier2 test mentioned in 
>>>> 8254790<https://bugs.openjdk.java.net/browse/JDK-8254790> but I am 
>>>> only seeing it pass under an x86 linux machine. Are there any specific architectural constraints under which this test should be run in order to make it fail?
>>>
>>> It failed on a Mac, not Linux.
>>>
>>> Cheers,
>>> David
>>>
>>>>
>>>>
>>>> I am running the test via: make test TEST="test/jdk/javax/xml/crypto/dsig/GenerationTests.java"
>>>>
>>>>
>>>>
>>>> Note that I am running the test against master without the commit:
>>>> "8254792: Disable intrinsic StringLatin1.indexOf until 8254790 is fixed" which disables the intrinsic that is causing the test to fail.
>>>>
>>>>
>>>>
>>>> Thanks
>>>> --
>>>> Jason
>>>>

From mchung at openjdk.java.net  Tue Oct 20 18:19:17 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 20 Oct 2020 18:19:17 GMT
Subject: RFR: 8254975: lambda proxy fails to access a protected member
 inherited from a split package
Message-ID: <8QLuT7jhXUHtB8Ce1Eb15D4LuEZkAEGWPr4k7LetMcI=.bbda143d-7c36-4da9-8e04-f359b19a7aed@github.com>

It's a bug in determining if a protected member inherited from a superclass is in
a split package as its host class that it only checks on the package name.

The fix is simple and compare the runtime package of the lambda class (which
is in the same runtime package as the host class) with that of the declaring class
of the protected member being accessed.

-------------

Commit messages:
 - Merge branch 'master' of https://github.com/openjdk/jdk into hidden-classes
 - Fix copyright year
 - 8254975: lambda proxy fails to access a protected member inherited from a split package

Changes: https://git.openjdk.java.net/jdk/pull/767/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=767&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8254975
  Stats: 86 lines in 2 files changed: 77 ins; 1 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/767.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/767/head:pull/767

PR: https://git.openjdk.java.net/jdk/pull/767

From dfuchs at openjdk.java.net  Tue Oct 20 18:20:26 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Tue, 20 Oct 2020 18:20:26 GMT
Subject: RFR: 8251989: Hex formatting and parsing utility [v6]
In-Reply-To: <seKMG87WLCuFuqEZuua-7hrmYxXeSYsoFATrMAqZMs4=.b4d97cb5-d84a-427c-9994-9292fa127e35@github.com>
References: <HSEn47GMS1K3g57mrTZeQk-WZHl3pKGHpX_OOf8VnsU=.740863c2-f9e4-43c4-b500-614aab4078b1@github.com>
 <seKMG87WLCuFuqEZuua-7hrmYxXeSYsoFATrMAqZMs4=.b4d97cb5-d84a-427c-9994-9292fa127e35@github.com>
Message-ID: <XP9bjD0pchTtNG5pMckB8z1B8lhs2aipwfLiJbZMfzk=.0519c7c2-9626-4c17-9823-7020caa11be0@github.com>

On Mon, 19 Oct 2020 22:52:31 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> java.util.HexFormat utility:
>> 
>>  - Format and parse hexadecimal strings, with parameters for delimiter, prefix, suffix and upper/lowercase
>>  - Static factories and builder methods to create HexFormat copies with modified parameters.
>>  - Consistent naming of methods for conversion of byte arrays to formatted strings and back: formatHex and parseHex
>>  - Consistent naming of methods for conversion of primitive types: toHexDigits... and fromHexDigits...
>>  - Prefix and suffixes now apply to each formatted value, not the string as a whole
>>  - Using java.util.Appendable as a target for buffered conversions so output to Writers and PrintStreams
>>    like System.out are supported in addition to StringBuilder. (IOExceptions are converted to unchecked exceptions)
>>  - Immutable and thread safe, a "value-based" class
>> 
>> See the [HexFormat
>> javadoc](http://cr.openjdk.java.net/~rriggs/8251989-hex-formatter/java.base/java/util/HexFormat.html) for details.
>> Review comments and suggestions welcome.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Correct length of StringBuilder in formatHex;
>   Correct bug in formatHex(char[], 2, 3) and add test for subranges of char[]

src/java.base/share/classes/java/util/HexFormat.java line 565:

> 563:      */
> 564:     private static void checkLiteral(CharSequence string, int index, String literal) {
> 565:         assert index + literal.length() <= string.length() : "pre-checked invariant error";

or possibly:
`assert index <= string.length() - literal.length() : ...`

-------------

PR: https://git.openjdk.java.net/jdk/pull/482

From Roger.Riggs at oracle.com  Tue Oct 20 19:32:37 2020
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Tue, 20 Oct 2020 15:32:37 -0400
Subject: RFR: 8251989: Hex formatting and parsing utility
In-Reply-To: <lv3X2v4KfUM8fxWZyX8_rwGa5wVnysBQjvqnAJaDYUU=.2b36709d-5547-411d-a609-fa465c4ce17f@github.com>
References: <HSEn47GMS1K3g57mrTZeQk-WZHl3pKGHpX_OOf8VnsU=.740863c2-f9e4-43c4-b500-614aab4078b1@github.com>
 <lv3X2v4KfUM8fxWZyX8_rwGa5wVnysBQjvqnAJaDYUU=.2b36709d-5547-411d-a609-fa465c4ce17f@github.com>
Message-ID: <f9f0092f-d0c5-5e12-74a8-336a60d8f277@oracle.com>

On 10/12/20 7:08 PM, Marcono1234 wrote:
> src/java.base/share/classes/java/util/HexFormat.java line 836:
>
>> 834:      *          otherwise {@code false}
>> 835:      */
>> 836:     public boolean isHexDigit(int ch) {
> Should this method be `static`? Or otherwise should it consider the `uppercase()` setting?
> (Same for `fromHexDigit` and all the other subsequent methods)
>
> These methods being instance methods is likely pretty confusing because they are unrelated to the HexFormat instance
> and makes using them cumbersome because the user has to create a HexFormat instance first.
All of the functions that convert binary to strings are formatting, 
though a simpler term could be used.

As for static vs instance methods, there are a number of competing 
interests.

 ?- Asymmetry between toHex and fromHex methods if the former were 
instance and the later were static methods.
 ?- The HexFormat context is needed for the prefix, suffix, and 
delimiter for the byte array versions vs the primitive value versions.
 ?- If the fromHex methods are static, and the toHex methods remain 
instance methods due to the uppercase/lowercase paramter, that's another 
kind of asymmetry.
 ?- Invoking and imports for static methods pushes the code to take on a 
different shape that is less appealing when mixed. (IMHO)

As the design was maturing, the choice was to keep all of the methods 
related to the parameters via the HexFormat instance.
Though there are no forseen future enhancments, keeping all the methods 
as instance methods would allow possible extensions to consistently 
apply to all formatting and parsing methods.

Are there other considerations that should be taken into account?

Regards, Roger

From asemenyuk at openjdk.java.net  Tue Oct 20 20:24:14 2020
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Tue, 20 Oct 2020 20:24:14 GMT
Subject: RFR: JDK-8254783: jpackage fails on Windows when application name
 differs =?UTF-8?B?4oCm?=
In-Reply-To: <r6qCtHMkiKtZiotu5BHVP84rqeUL_5mkVyFlBeCqC7A=.45656321-6f24-4fa1-b82d-2c9797c511cf@github.com>
References: <r6qCtHMkiKtZiotu5BHVP84rqeUL_5mkVyFlBeCqC7A=.45656321-6f24-4fa1-b82d-2c9797c511cf@github.com>
Message-ID: <5Q2ubGCFXv-EC0perzfUB4qVNoEwNUVglLzUJV-L9RE=.4de160cb-1d0b-402c-8df2-8c1841ac03ac@github.com>

On Sat, 17 Oct 2020 14:01:22 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> ?from installer name
> JDK-8254783: jpackage fails on Windows when application name differs from installer name
> When using --app-image, to create MSI installer, use the application name from AppImageData instead of the Msi
> installer name if possible.

Marked as reviewed by asemenyuk (Committer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/720

From kizune at openjdk.java.net  Tue Oct 20 21:21:12 2020
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Tue, 20 Oct 2020 21:21:12 GMT
Subject: RFR: JDK-8254783: jpackage fails on Windows when application name
 differs =?UTF-8?B?4oCm?=
In-Reply-To: <r6qCtHMkiKtZiotu5BHVP84rqeUL_5mkVyFlBeCqC7A=.45656321-6f24-4fa1-b82d-2c9797c511cf@github.com>
References: <r6qCtHMkiKtZiotu5BHVP84rqeUL_5mkVyFlBeCqC7A=.45656321-6f24-4fa1-b82d-2c9797c511cf@github.com>
Message-ID: <k75VBmkh2FPsFioXQIG2b_h2ESCZqPhsM_nnV3DW4-0=.a2272207-367f-4876-aaf9-ced54a7e08c9@github.com>

On Sat, 17 Oct 2020 14:01:22 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> ?from installer name
> JDK-8254783: jpackage fails on Windows when application name differs from installer name
> When using --app-image, to create MSI installer, use the application name from AppImageData instead of the Msi
> installer name if possible.

Looks good.

-------------

Marked as reviewed by kizune (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/720

From kizune at openjdk.java.net  Tue Oct 20 21:23:11 2020
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Tue, 20 Oct 2020 21:23:11 GMT
Subject: RFR: JDK-8254843: Exception launching app on windows in some cases
In-Reply-To: <TPcZJguZshLTz6DP1TeLYnmI7d2lMrI89UBYXOF0How=.91e29d6f-1b4e-4f5d-bb4d-345d7be2866f@github.com>
References: <TPcZJguZshLTz6DP1TeLYnmI7d2lMrI89UBYXOF0How=.91e29d6f-1b4e-4f5d-bb4d-345d7be2866f@github.com>
Message-ID: <qHaP4rnhBnyWEHi2EQhW0ldyTK2LYF1akmZdndvhQQY=.ef956109-8247-4b5b-9b70-73547cc700df@github.com>

On Fri, 16 Oct 2020 17:59:14 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> JDK-8254843: Exception launching app on windows in some cases
> loading splashscreen.dll in WinLaunchercpp would load java.dll from path instead of runtime/bin causing jni launcher to
> crash. instead we just use what used to be the fallback, using loadDllWithAddDllDirectory().

Looks fine to me.

-------------

Marked as reviewed by kizune (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/706

From herrick at openjdk.java.net  Tue Oct 20 21:34:12 2020
From: herrick at openjdk.java.net (Andy Herrick)
Date: Tue, 20 Oct 2020 21:34:12 GMT
Subject: Integrated: JDK-8254843: Exception launching app on windows in some
 cases
In-Reply-To: <TPcZJguZshLTz6DP1TeLYnmI7d2lMrI89UBYXOF0How=.91e29d6f-1b4e-4f5d-bb4d-345d7be2866f@github.com>
References: <TPcZJguZshLTz6DP1TeLYnmI7d2lMrI89UBYXOF0How=.91e29d6f-1b4e-4f5d-bb4d-345d7be2866f@github.com>
Message-ID: <HgsJ8JJRjtQ8A1-HZB7QpYhWqq6zzbn_jRZV4_XxI4k=.74518693-b3aa-4447-88f6-263908f01f98@github.com>

On Fri, 16 Oct 2020 17:59:14 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> JDK-8254843: Exception launching app on windows in some cases
> loading splashscreen.dll in WinLaunchercpp would load java.dll from path instead of runtime/bin causing jni launcher to
> crash. instead we just use what used to be the fallback, using loadDllWithAddDllDirectory().

This pull request has now been integrated.

Changeset: acacae5e
Author:    Andy Herrick <herrick at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/acacae5e
Stats:     15 lines in 1 file changed: 0 ins; 10 del; 5 mod

8254843: Exception launching app on windows in some cases

Reviewed-by: asemenyuk, kcr, almatvee, kizune

-------------

PR: https://git.openjdk.java.net/jdk/pull/706

From vladimir.kozlov at oracle.com  Tue Oct 20 21:39:52 2020
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 20 Oct 2020 14:39:52 -0700
Subject: Howto replicate failure of 8254790?
In-Reply-To: <BYAPR11MB3543DA6BACC9E5EDFAA04F24EF1F0@BYAPR11MB3543.namprd11.prod.outlook.com>
References: <4bd7e9f73ea24ae09f1bb0f1808ce5a7@EX13D46EUB003.ant.amazon.com>
 <661485ab-7de7-26cb-b2b1-3a4f643125eb@oracle.com>
 <617f010e-629d-7329-ac72-dce797bf3075@oracle.com>
 <d6061b53d0854305a1fdb1a5ea7a019c@EX13D46EUB003.ant.amazon.com>
 <efc3cbff-2e42-cf57-c753-f9d30b68d394@oracle.com>
 <BYAPR11MB35434D70D8B62F45068ADA7AEF1F0@BYAPR11MB3543.namprd11.prod.outlook.com>
 <0a0481a0-5f2d-e594-dd71-aa84103bb4d4@oracle.com>
 <BYAPR11MB3543DA6BACC9E5EDFAA04F24EF1F0@BYAPR11MB3543.namprd11.prod.outlook.com>
Message-ID: <98c245f6-6f58-4aff-97f0-fa2ef122c3b2@oracle.com>

Thank you, Sandhya

Very nice analysis.

I just finished running dsig/GenerationTests.java test multiply runs (to besure) on our systems and confirmed your 
proposed fix:

    bsfl(ch, tmp);
+  if (UseNewCode) {
+    addptr(result, ch);
+  } else {
      addl(result, ch);
+  }

It always fails with addl() and always passed with addptr(). I will assign bug to me and file PR now.
I will also fix Unicode string index instrinsic code.

Thanks,
Vladimir


On 10/20/20 10:27 AM, Viswanathan, Sandhya wrote:
>   Hi Vladimir,
> 
> I analyzed the instruction dump yesterday to find out where the issue is. I have attached it to the bug report as 8254790.asm:
> https://bugs.openjdk.java.net/browse/JDK-8254790
> 
> The crash is reported at:
> 100:       450FB64C1810             movzx r9d, byte ptr [r8+rbx*1+0x10]
> 
> Which is just after the intrinsics and uses the rbx register (containing the index of char from the intrinsic).
> 
> RBX has the large value 0xfffffff900000008 instead of 8.  The length of the string is 34 bytes. The match is found in first 32 bytes at index 8.
> After doing the 32 bytes with the following instructions:
> 6b:       C5FE6F13                 vmovdqu ymm2, ymmword ptr [rbx]
> 6f:       C5ED74D1                 vpcmpeqb ymm2, ymm2, ymm1
> 73:       C4E27D17C2               vptest ymm0, ymm2
> 78:       0F8369000000             jnb 0xe7
> The control goes to 0xe7.
> 
> The code snippet at 0xe7 is:
> e7:       C5FDD7CA                 vpmovmskb ecx, ymm2
> eb:       0FBCC1                   bsf eax, ecx
> ee:       03D8                     add ebx, eax
> f0:       482BDF                   sub rbx, rdi
> f3:       0F1F4000                 nop dword ptr [rax], eax
> f7:       413BDB                   cmp ebx, r11d
> fa:       0F83DF290000             jnb 0x2adf
> 100:       450FB64C1810             movzx r9d, byte ptr [r8+rbx*1+0x10]
> 
> After vpmovmskb, the bit mask in ecx is 0x1100, showing the match at 8th and 9th byte.
> The register rbx at this point must be holding address to the base of array: 0x00000007e41d2700 same as rdi.
> Bsf puts 8 in eax.
> Then 8 is added to ebx instead of rbx using 32-bit add, making upper 32 bits as 0, resulting in rbx = 0xe41d2708.
> If the add was 64-bit add, everything would have worked well.
> Then sub rbx, rdi results in 0xe41d2708 - 0x00000007e41d2700 = 0xFFFFFFF900000008 being loaded in rbx.
> This is the value we see at crash.
> 
> Best Regards,
> Sandhya
> 
> 
> -----Original Message-----
> From: Vladimir Kozlov <vladimir.kozlov at oracle.com>
> Sent: Tuesday, October 20, 2020 10:01 AM
> To: Viswanathan, Sandhya <sandhya.viswanathan at intel.com>; Tatton, Jason <jptatton at amazon.com>; David Holmes <david.holmes at oracle.com>; hotspot-compiler-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; Hohensee, Paul <hohensee at amazon.com>
> Subject: Re: Howto replicate failure of 8254790?
> 
> Yes, I saw it too but I was not sure because we never hit the issue with Unicode string index intrinsic.
> An other thing is we see the failure only on MacOS.
> 
> I also want someone to decode asm dump I provided in bug to see actual instructions where it happened.
> 
> Vladimir K
> 
> On 10/19/20 5:38 PM, Viswanathan, Sandhya wrote:
>> Hi Jason,
>>
>> I think I found the problem looking at the error log from Vladimir Kozlov. In stringL_indexof_char() function, the following snippet is the cause of problem:
>>
>> 2807   bind(FOUND_CHAR);
>> 2808   if (UseAVX >= 2) {
>> 2809     vpmovmskb(tmp, vec3);
>> 2810   } else {
>> 2811     pmovmskb(tmp, vec3);
>> 2812   }
>> 2813   bsfl(ch, tmp);
>> 2814   addl(result, ch);                         <====   The problem is here
>> 2815
>> 2816   bind(FOUND_SEQ_CHAR);
>> 2817   subptr(result, str1);
>>
>> The line addl(result, ch) should have been addptr(result, ch).
>>
>> The same problem exists in the Unicode string index of char intrinsic as well and need to be fixed.
>>
>> Hope this helps.
>>
>> Best Regards,
>> Sandhya
>>
>> -----Original Message-----
>> From: hotspot-compiler-dev
>> <hotspot-compiler-dev-retn at openjdk.java.net> On Behalf Of Vladimir
>> Kozlov
>> Sent: Thursday, October 15, 2020 3:59 PM
>> To: Tatton, Jason <jptatton at amazon.com>; David Holmes
>> <david.holmes at oracle.com>; hotspot-compiler-dev at openjdk.java.net;
>> core-libs-dev at openjdk.java.net
>> Subject: Re: Howto replicate failure of 8254790?
>>
>> Hi Jason,
>>
>> I added surrounding instructions dump from hs_err file we have so you can reconstruct x86 assembler from it.
>>
>> If you look on si_addr: 0x00000000e41d2718 which case memory map
>> failure, it looks like R8 =0x00000007e41d2700 is an
>> oop: [B with upper 32-bits zeroed. It seems uppers 32-bits of address were cut.
>>
>> But I don't see it can happens in stringL_indexof_char() sub. You correctly used movptr() and addptr() instructions.
>>
>> Vladimir K
>>
>> On 10/15/20 2:10 PM, Tatton, Jason wrote:
>>> Thanks Vladimir and David, I have access to a new macbook with an Intel i7-9750H (supports AVX2) so I will try on that.
>>>
>>> -----Original Message-----
>>> From: Vladimir Kozlov <vladimir.kozlov at oracle.com>
>>> Sent: 15 October 2020 20:25
>>> To: David Holmes <david.holmes at oracle.com>; Tatton, Jason
>>> <jptatton at amazon.com>; hotspot-compiler-dev at openjdk.java.net;
>>> core-libs-dev at openjdk.java.net
>>> Subject: RE: [EXTERNAL] Howto replicate failure of 8254790?
>>>
>>> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
>>>
>>>
>>>
>>> Note, we have old Mac machines in our testing env:
>>> cx8, cmov, fxsr, ht, mmx, 3dnowpref, sse, sse2, sse3, ssse3, sse4.1,
>>> sse4.2, popcnt, lzcnt, tsc, tscinvbit, avx, avx2, aes, erms, clmul,
>>> bmi1, bmi2, rtm, adx, fma, vzeroupper, clflush, clflushopt
>>>
>>> Use -XX:UseAVX=2
>>>
>>> But I was not able reproduce failure on my Skylake Linux machine even with -XX:UseAVX=2. Maybe there are other factors on MacOS.
>>>
>>> Regards,
>>> Vladimir K
>>>
>>> On 10/14/20 5:48 PM, David Holmes wrote:
>>>> Hi Jason,
>>>>
>>>> On 15/10/2020 10:42 am, Tatton, Jason wrote:
>>>>> Hi all,
>>>>>
>>>>>
>>>>>
>>>>> I am trying to replicate the failure of the tier2 test mentioned in
>>>>> 8254790<https://bugs.openjdk.java.net/browse/JDK-8254790> but I am
>>>>> only seeing it pass under an x86 linux machine. Are there any specific architectural constraints under which this test should be run in order to make it fail?
>>>>
>>>> It failed on a Mac, not Linux.
>>>>
>>>> Cheers,
>>>> David
>>>>
>>>>>
>>>>>
>>>>> I am running the test via: make test TEST="test/jdk/javax/xml/crypto/dsig/GenerationTests.java"
>>>>>
>>>>>
>>>>>
>>>>> Note that I am running the test against master without the commit:
>>>>> "8254792: Disable intrinsic StringLatin1.indexOf until 8254790 is fixed" which disables the intrinsic that is causing the test to fail.
>>>>>
>>>>>
>>>>>
>>>>> Thanks
>>>>> --
>>>>> Jason
>>>>>

From sandhya.viswanathan at intel.com  Tue Oct 20 21:44:10 2020
From: sandhya.viswanathan at intel.com (Viswanathan, Sandhya)
Date: Tue, 20 Oct 2020 21:44:10 +0000
Subject: Howto replicate failure of 8254790?
In-Reply-To: <98c245f6-6f58-4aff-97f0-fa2ef122c3b2@oracle.com>
References: <4bd7e9f73ea24ae09f1bb0f1808ce5a7@EX13D46EUB003.ant.amazon.com>
 <661485ab-7de7-26cb-b2b1-3a4f643125eb@oracle.com>
 <617f010e-629d-7329-ac72-dce797bf3075@oracle.com>
 <d6061b53d0854305a1fdb1a5ea7a019c@EX13D46EUB003.ant.amazon.com>
 <efc3cbff-2e42-cf57-c753-f9d30b68d394@oracle.com>
 <BYAPR11MB35434D70D8B62F45068ADA7AEF1F0@BYAPR11MB3543.namprd11.prod.outlook.com>
 <0a0481a0-5f2d-e594-dd71-aa84103bb4d4@oracle.com>
 <BYAPR11MB3543DA6BACC9E5EDFAA04F24EF1F0@BYAPR11MB3543.namprd11.prod.outlook.com>
 <98c245f6-6f58-4aff-97f0-fa2ef122c3b2@oracle.com>
Message-ID: <BYAPR11MB354340AF9F56D5FC7823E046EF1F0@BYAPR11MB3543.namprd11.prod.outlook.com>

Hi Vladimir,

I submitted a pull request an hour or so ago as this was a P1 bug, feel free to use that or ignore.
https://git.openjdk.java.net/jdk/pull/772

Best Regards,
Sandhya

-----Original Message-----
From: Vladimir Kozlov <vladimir.kozlov at oracle.com> 
Sent: Tuesday, October 20, 2020 2:40 PM
To: Viswanathan, Sandhya <sandhya.viswanathan at intel.com>; Tatton, Jason <jptatton at amazon.com>; David Holmes <david.holmes at oracle.com>; hotspot-compiler-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; Hohensee, Paul <hohensee at amazon.com>
Subject: Re: Howto replicate failure of 8254790?

Thank you, Sandhya

Very nice analysis.

I just finished running dsig/GenerationTests.java test multiply runs (to besure) on our systems and confirmed your proposed fix:

    bsfl(ch, tmp);
+  if (UseNewCode) {
+    addptr(result, ch);
+  } else {
      addl(result, ch);
+  }

It always fails with addl() and always passed with addptr(). I will assign bug to me and file PR now.
I will also fix Unicode string index instrinsic code.

Thanks,
Vladimir


On 10/20/20 10:27 AM, Viswanathan, Sandhya wrote:
>   Hi Vladimir,
> 
> I analyzed the instruction dump yesterday to find out where the issue is. I have attached it to the bug report as 8254790.asm:
> https://bugs.openjdk.java.net/browse/JDK-8254790
> 
> The crash is reported at:
> 100:       450FB64C1810             movzx r9d, byte ptr [r8+rbx*1+0x10]
> 
> Which is just after the intrinsics and uses the rbx register (containing the index of char from the intrinsic).
> 
> RBX has the large value 0xfffffff900000008 instead of 8.  The length of the string is 34 bytes. The match is found in first 32 bytes at index 8.
> After doing the 32 bytes with the following instructions:
> 6b:       C5FE6F13                 vmovdqu ymm2, ymmword ptr [rbx]
> 6f:       C5ED74D1                 vpcmpeqb ymm2, ymm2, ymm1
> 73:       C4E27D17C2               vptest ymm0, ymm2
> 78:       0F8369000000             jnb 0xe7
> The control goes to 0xe7.
> 
> The code snippet at 0xe7 is:
> e7:       C5FDD7CA                 vpmovmskb ecx, ymm2
> eb:       0FBCC1                   bsf eax, ecx
> ee:       03D8                     add ebx, eax
> f0:       482BDF                   sub rbx, rdi
> f3:       0F1F4000                 nop dword ptr [rax], eax
> f7:       413BDB                   cmp ebx, r11d
> fa:       0F83DF290000             jnb 0x2adf
> 100:       450FB64C1810             movzx r9d, byte ptr [r8+rbx*1+0x10]
> 
> After vpmovmskb, the bit mask in ecx is 0x1100, showing the match at 8th and 9th byte.
> The register rbx at this point must be holding address to the base of array: 0x00000007e41d2700 same as rdi.
> Bsf puts 8 in eax.
> Then 8 is added to ebx instead of rbx using 32-bit add, making upper 32 bits as 0, resulting in rbx = 0xe41d2708.
> If the add was 64-bit add, everything would have worked well.
> Then sub rbx, rdi results in 0xe41d2708 - 0x00000007e41d2700 = 0xFFFFFFF900000008 being loaded in rbx.
> This is the value we see at crash.
> 
> Best Regards,
> Sandhya
> 
> 
> -----Original Message-----
> From: Vladimir Kozlov <vladimir.kozlov at oracle.com>
> Sent: Tuesday, October 20, 2020 10:01 AM
> To: Viswanathan, Sandhya <sandhya.viswanathan at intel.com>; Tatton, 
> Jason <jptatton at amazon.com>; David Holmes <david.holmes at oracle.com>; 
> hotspot-compiler-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; 
> Hohensee, Paul <hohensee at amazon.com>
> Subject: Re: Howto replicate failure of 8254790?
> 
> Yes, I saw it too but I was not sure because we never hit the issue with Unicode string index intrinsic.
> An other thing is we see the failure only on MacOS.
> 
> I also want someone to decode asm dump I provided in bug to see actual instructions where it happened.
> 
> Vladimir K
> 
> On 10/19/20 5:38 PM, Viswanathan, Sandhya wrote:
>> Hi Jason,
>>
>> I think I found the problem looking at the error log from Vladimir Kozlov. In stringL_indexof_char() function, the following snippet is the cause of problem:
>>
>> 2807   bind(FOUND_CHAR);
>> 2808   if (UseAVX >= 2) {
>> 2809     vpmovmskb(tmp, vec3);
>> 2810   } else {
>> 2811     pmovmskb(tmp, vec3);
>> 2812   }
>> 2813   bsfl(ch, tmp);
>> 2814   addl(result, ch);                         <====   The problem is here
>> 2815
>> 2816   bind(FOUND_SEQ_CHAR);
>> 2817   subptr(result, str1);
>>
>> The line addl(result, ch) should have been addptr(result, ch).
>>
>> The same problem exists in the Unicode string index of char intrinsic as well and need to be fixed.
>>
>> Hope this helps.
>>
>> Best Regards,
>> Sandhya
>>
>> -----Original Message-----
>> From: hotspot-compiler-dev
>> <hotspot-compiler-dev-retn at openjdk.java.net> On Behalf Of Vladimir 
>> Kozlov
>> Sent: Thursday, October 15, 2020 3:59 PM
>> To: Tatton, Jason <jptatton at amazon.com>; David Holmes 
>> <david.holmes at oracle.com>; hotspot-compiler-dev at openjdk.java.net;
>> core-libs-dev at openjdk.java.net
>> Subject: Re: Howto replicate failure of 8254790?
>>
>> Hi Jason,
>>
>> I added surrounding instructions dump from hs_err file we have so you can reconstruct x86 assembler from it.
>>
>> If you look on si_addr: 0x00000000e41d2718 which case memory map 
>> failure, it looks like R8 =0x00000007e41d2700 is an
>> oop: [B with upper 32-bits zeroed. It seems uppers 32-bits of address were cut.
>>
>> But I don't see it can happens in stringL_indexof_char() sub. You correctly used movptr() and addptr() instructions.
>>
>> Vladimir K
>>
>> On 10/15/20 2:10 PM, Tatton, Jason wrote:
>>> Thanks Vladimir and David, I have access to a new macbook with an Intel i7-9750H (supports AVX2) so I will try on that.
>>>
>>> -----Original Message-----
>>> From: Vladimir Kozlov <vladimir.kozlov at oracle.com>
>>> Sent: 15 October 2020 20:25
>>> To: David Holmes <david.holmes at oracle.com>; Tatton, Jason 
>>> <jptatton at amazon.com>; hotspot-compiler-dev at openjdk.java.net;
>>> core-libs-dev at openjdk.java.net
>>> Subject: RE: [EXTERNAL] Howto replicate failure of 8254790?
>>>
>>> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
>>>
>>>
>>>
>>> Note, we have old Mac machines in our testing env:
>>> cx8, cmov, fxsr, ht, mmx, 3dnowpref, sse, sse2, sse3, ssse3, sse4.1, 
>>> sse4.2, popcnt, lzcnt, tsc, tscinvbit, avx, avx2, aes, erms, clmul, 
>>> bmi1, bmi2, rtm, adx, fma, vzeroupper, clflush, clflushopt
>>>
>>> Use -XX:UseAVX=2
>>>
>>> But I was not able reproduce failure on my Skylake Linux machine even with -XX:UseAVX=2. Maybe there are other factors on MacOS.
>>>
>>> Regards,
>>> Vladimir K
>>>
>>> On 10/14/20 5:48 PM, David Holmes wrote:
>>>> Hi Jason,
>>>>
>>>> On 15/10/2020 10:42 am, Tatton, Jason wrote:
>>>>> Hi all,
>>>>>
>>>>>
>>>>>
>>>>> I am trying to replicate the failure of the tier2 test mentioned 
>>>>> in 8254790<https://bugs.openjdk.java.net/browse/JDK-8254790> but I 
>>>>> am only seeing it pass under an x86 linux machine. Are there any specific architectural constraints under which this test should be run in order to make it fail?
>>>>
>>>> It failed on a Mac, not Linux.
>>>>
>>>> Cheers,
>>>> David
>>>>
>>>>>
>>>>>
>>>>> I am running the test via: make test TEST="test/jdk/javax/xml/crypto/dsig/GenerationTests.java"
>>>>>
>>>>>
>>>>>
>>>>> Note that I am running the test against master without the commit:
>>>>> "8254792: Disable intrinsic StringLatin1.indexOf until 8254790 is fixed" which disables the intrinsic that is causing the test to fail.
>>>>>
>>>>>
>>>>>
>>>>> Thanks
>>>>> --
>>>>> Jason
>>>>>

From bchristi at openjdk.java.net  Tue Oct 20 21:54:15 2020
From: bchristi at openjdk.java.net (Brent Christian)
Date: Tue, 20 Oct 2020 21:54:15 GMT
Subject: RFR: 8255031 : Update java/util/prefs/AddNodeChangeListener.java to
 report more failure info
Message-ID: <WdQlv9nOZU91fs2chRaHhYRTVnuMwcB297XumQEUW7k=.9f8d9fe3-4418-4d8b-95db-2cc31ab34ebf@github.com>

Hi,

The java/util/prefs/AddNodeChangeListener.java test fails once in a while in the automated test system.  Previous
failures were traced to machine configuration errors, but that does not appear to be the case this time.

My efforts to reproduce this failure have been unsuccessful.  The only useful infformation I've gleaned so far from the
test failure logs is that the overall duration for running tier1 is longer than usual when the test failure happens.

I would like to make the following updates to the test, in hopes of learning more if and when this test fails again:

* fail faster, to report if it is addNode() or removeNode() that is failing
* make multiple attempts to sleep+check the NodeChangeListener.  (If the test fails after a single sleep, but passes
  after waiting longer, maybe we just need to sleep for longer to account for the occasional slower tier1 test run).
* a few indentations fixes

Thanks,
-Brent

-------------

Commit messages:
 - remove trailing spaces
 - update test: fail eariler, repeat sleep+check

Changes: https://git.openjdk.java.net/jdk/pull/773/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=773&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8255031
  Stats: 52 lines in 1 file changed: 33 ins; 3 del; 16 mod
  Patch: https://git.openjdk.java.net/jdk/pull/773.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/773/head:pull/773

PR: https://git.openjdk.java.net/jdk/pull/773

From vladimir.kozlov at oracle.com  Tue Oct 20 21:55:40 2020
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 20 Oct 2020 14:55:40 -0700
Subject: Howto replicate failure of 8254790?
In-Reply-To: <BYAPR11MB354340AF9F56D5FC7823E046EF1F0@BYAPR11MB3543.namprd11.prod.outlook.com>
References: <4bd7e9f73ea24ae09f1bb0f1808ce5a7@EX13D46EUB003.ant.amazon.com>
 <661485ab-7de7-26cb-b2b1-3a4f643125eb@oracle.com>
 <617f010e-629d-7329-ac72-dce797bf3075@oracle.com>
 <d6061b53d0854305a1fdb1a5ea7a019c@EX13D46EUB003.ant.amazon.com>
 <efc3cbff-2e42-cf57-c753-f9d30b68d394@oracle.com>
 <BYAPR11MB35434D70D8B62F45068ADA7AEF1F0@BYAPR11MB3543.namprd11.prod.outlook.com>
 <0a0481a0-5f2d-e594-dd71-aa84103bb4d4@oracle.com>
 <BYAPR11MB3543DA6BACC9E5EDFAA04F24EF1F0@BYAPR11MB3543.namprd11.prod.outlook.com>
 <98c245f6-6f58-4aff-97f0-fa2ef122c3b2@oracle.com>
 <BYAPR11MB354340AF9F56D5FC7823E046EF1F0@BYAPR11MB3543.namprd11.prod.outlook.com>
Message-ID: <8c90a8e9-3901-c58f-3c8a-069ade732deb@oracle.com>

Perfect - exactly as my local fix. I assigned bug to you and will do review of your PR.

I am running tier1-3 testing and let you know results. Please, wait before integration.

Thanks,
Vladimir K

On 10/20/20 2:44 PM, Viswanathan, Sandhya wrote:
> Hi Vladimir,
> 
> I submitted a pull request an hour or so ago as this was a P1 bug, feel free to use that or ignore.
> https://git.openjdk.java.net/jdk/pull/772
> 
> Best Regards,
> Sandhya
> 
> -----Original Message-----
> From: Vladimir Kozlov <vladimir.kozlov at oracle.com>
> Sent: Tuesday, October 20, 2020 2:40 PM
> To: Viswanathan, Sandhya <sandhya.viswanathan at intel.com>; Tatton, Jason <jptatton at amazon.com>; David Holmes <david.holmes at oracle.com>; hotspot-compiler-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; Hohensee, Paul <hohensee at amazon.com>
> Subject: Re: Howto replicate failure of 8254790?
> 
> Thank you, Sandhya
> 
> Very nice analysis.
> 
> I just finished running dsig/GenerationTests.java test multiply runs (to besure) on our systems and confirmed your proposed fix:
> 
>      bsfl(ch, tmp);
> +  if (UseNewCode) {
> +    addptr(result, ch);
> +  } else {
>        addl(result, ch);
> +  }
> 
> It always fails with addl() and always passed with addptr(). I will assign bug to me and file PR now.
> I will also fix Unicode string index instrinsic code.
> 
> Thanks,
> Vladimir
> 
> 
> On 10/20/20 10:27 AM, Viswanathan, Sandhya wrote:
>>    Hi Vladimir,
>>
>> I analyzed the instruction dump yesterday to find out where the issue is. I have attached it to the bug report as 8254790.asm:
>> https://bugs.openjdk.java.net/browse/JDK-8254790
>>
>> The crash is reported at:
>> 100:       450FB64C1810             movzx r9d, byte ptr [r8+rbx*1+0x10]
>>
>> Which is just after the intrinsics and uses the rbx register (containing the index of char from the intrinsic).
>>
>> RBX has the large value 0xfffffff900000008 instead of 8.  The length of the string is 34 bytes. The match is found in first 32 bytes at index 8.
>> After doing the 32 bytes with the following instructions:
>> 6b:       C5FE6F13                 vmovdqu ymm2, ymmword ptr [rbx]
>> 6f:       C5ED74D1                 vpcmpeqb ymm2, ymm2, ymm1
>> 73:       C4E27D17C2               vptest ymm0, ymm2
>> 78:       0F8369000000             jnb 0xe7
>> The control goes to 0xe7.
>>
>> The code snippet at 0xe7 is:
>> e7:       C5FDD7CA                 vpmovmskb ecx, ymm2
>> eb:       0FBCC1                   bsf eax, ecx
>> ee:       03D8                     add ebx, eax
>> f0:       482BDF                   sub rbx, rdi
>> f3:       0F1F4000                 nop dword ptr [rax], eax
>> f7:       413BDB                   cmp ebx, r11d
>> fa:       0F83DF290000             jnb 0x2adf
>> 100:       450FB64C1810             movzx r9d, byte ptr [r8+rbx*1+0x10]
>>
>> After vpmovmskb, the bit mask in ecx is 0x1100, showing the match at 8th and 9th byte.
>> The register rbx at this point must be holding address to the base of array: 0x00000007e41d2700 same as rdi.
>> Bsf puts 8 in eax.
>> Then 8 is added to ebx instead of rbx using 32-bit add, making upper 32 bits as 0, resulting in rbx = 0xe41d2708.
>> If the add was 64-bit add, everything would have worked well.
>> Then sub rbx, rdi results in 0xe41d2708 - 0x00000007e41d2700 = 0xFFFFFFF900000008 being loaded in rbx.
>> This is the value we see at crash.
>>
>> Best Regards,
>> Sandhya
>>
>>
>> -----Original Message-----
>> From: Vladimir Kozlov <vladimir.kozlov at oracle.com>
>> Sent: Tuesday, October 20, 2020 10:01 AM
>> To: Viswanathan, Sandhya <sandhya.viswanathan at intel.com>; Tatton,
>> Jason <jptatton at amazon.com>; David Holmes <david.holmes at oracle.com>;
>> hotspot-compiler-dev at openjdk.java.net; core-libs-dev at openjdk.java.net;
>> Hohensee, Paul <hohensee at amazon.com>
>> Subject: Re: Howto replicate failure of 8254790?
>>
>> Yes, I saw it too but I was not sure because we never hit the issue with Unicode string index intrinsic.
>> An other thing is we see the failure only on MacOS.
>>
>> I also want someone to decode asm dump I provided in bug to see actual instructions where it happened.
>>
>> Vladimir K
>>
>> On 10/19/20 5:38 PM, Viswanathan, Sandhya wrote:
>>> Hi Jason,
>>>
>>> I think I found the problem looking at the error log from Vladimir Kozlov. In stringL_indexof_char() function, the following snippet is the cause of problem:
>>>
>>> 2807   bind(FOUND_CHAR);
>>> 2808   if (UseAVX >= 2) {
>>> 2809     vpmovmskb(tmp, vec3);
>>> 2810   } else {
>>> 2811     pmovmskb(tmp, vec3);
>>> 2812   }
>>> 2813   bsfl(ch, tmp);
>>> 2814   addl(result, ch);                         <====   The problem is here
>>> 2815
>>> 2816   bind(FOUND_SEQ_CHAR);
>>> 2817   subptr(result, str1);
>>>
>>> The line addl(result, ch) should have been addptr(result, ch).
>>>
>>> The same problem exists in the Unicode string index of char intrinsic as well and need to be fixed.
>>>
>>> Hope this helps.
>>>
>>> Best Regards,
>>> Sandhya
>>>
>>> -----Original Message-----
>>> From: hotspot-compiler-dev
>>> <hotspot-compiler-dev-retn at openjdk.java.net> On Behalf Of Vladimir
>>> Kozlov
>>> Sent: Thursday, October 15, 2020 3:59 PM
>>> To: Tatton, Jason <jptatton at amazon.com>; David Holmes
>>> <david.holmes at oracle.com>; hotspot-compiler-dev at openjdk.java.net;
>>> core-libs-dev at openjdk.java.net
>>> Subject: Re: Howto replicate failure of 8254790?
>>>
>>> Hi Jason,
>>>
>>> I added surrounding instructions dump from hs_err file we have so you can reconstruct x86 assembler from it.
>>>
>>> If you look on si_addr: 0x00000000e41d2718 which case memory map
>>> failure, it looks like R8 =0x00000007e41d2700 is an
>>> oop: [B with upper 32-bits zeroed. It seems uppers 32-bits of address were cut.
>>>
>>> But I don't see it can happens in stringL_indexof_char() sub. You correctly used movptr() and addptr() instructions.
>>>
>>> Vladimir K
>>>
>>> On 10/15/20 2:10 PM, Tatton, Jason wrote:
>>>> Thanks Vladimir and David, I have access to a new macbook with an Intel i7-9750H (supports AVX2) so I will try on that.
>>>>
>>>> -----Original Message-----
>>>> From: Vladimir Kozlov <vladimir.kozlov at oracle.com>
>>>> Sent: 15 October 2020 20:25
>>>> To: David Holmes <david.holmes at oracle.com>; Tatton, Jason
>>>> <jptatton at amazon.com>; hotspot-compiler-dev at openjdk.java.net;
>>>> core-libs-dev at openjdk.java.net
>>>> Subject: RE: [EXTERNAL] Howto replicate failure of 8254790?
>>>>
>>>> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
>>>>
>>>>
>>>>
>>>> Note, we have old Mac machines in our testing env:
>>>> cx8, cmov, fxsr, ht, mmx, 3dnowpref, sse, sse2, sse3, ssse3, sse4.1,
>>>> sse4.2, popcnt, lzcnt, tsc, tscinvbit, avx, avx2, aes, erms, clmul,
>>>> bmi1, bmi2, rtm, adx, fma, vzeroupper, clflush, clflushopt
>>>>
>>>> Use -XX:UseAVX=2
>>>>
>>>> But I was not able reproduce failure on my Skylake Linux machine even with -XX:UseAVX=2. Maybe there are other factors on MacOS.
>>>>
>>>> Regards,
>>>> Vladimir K
>>>>
>>>> On 10/14/20 5:48 PM, David Holmes wrote:
>>>>> Hi Jason,
>>>>>
>>>>> On 15/10/2020 10:42 am, Tatton, Jason wrote:
>>>>>> Hi all,
>>>>>>
>>>>>>
>>>>>>
>>>>>> I am trying to replicate the failure of the tier2 test mentioned
>>>>>> in 8254790<https://bugs.openjdk.java.net/browse/JDK-8254790> but I
>>>>>> am only seeing it pass under an x86 linux machine. Are there any specific architectural constraints under which this test should be run in order to make it fail?
>>>>>
>>>>> It failed on a Mac, not Linux.
>>>>>
>>>>> Cheers,
>>>>> David
>>>>>
>>>>>>
>>>>>>
>>>>>> I am running the test via: make test TEST="test/jdk/javax/xml/crypto/dsig/GenerationTests.java"
>>>>>>
>>>>>>
>>>>>>
>>>>>> Note that I am running the test against master without the commit:
>>>>>> "8254792: Disable intrinsic StringLatin1.indexOf until 8254790 is fixed" which disables the intrinsic that is causing the test to fail.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Thanks
>>>>>> --
>>>>>> Jason
>>>>>>

From almatvee at openjdk.java.net  Tue Oct 20 21:57:12 2020
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Tue, 20 Oct 2020 21:57:12 GMT
Subject: RFR: JDK-8254783: jpackage fails on Windows when application name
 differs =?UTF-8?B?4oCm?=
In-Reply-To: <r6qCtHMkiKtZiotu5BHVP84rqeUL_5mkVyFlBeCqC7A=.45656321-6f24-4fa1-b82d-2c9797c511cf@github.com>
References: <r6qCtHMkiKtZiotu5BHVP84rqeUL_5mkVyFlBeCqC7A=.45656321-6f24-4fa1-b82d-2c9797c511cf@github.com>
Message-ID: <LGoFgWqgRsQdICeYwxfjd1moBrjGOJHvxwYZ47rCHYA=.6c31cf64-80cf-4651-8f58-9fe5c6732237@github.com>

On Sat, 17 Oct 2020 14:01:22 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> ?from installer name
> JDK-8254783: jpackage fails on Windows when application name differs from installer name
> When using --app-image, to create MSI installer, use the application name from AppImageData instead of the Msi
> installer name if possible.

Marked as reviewed by almatvee (Committer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/720

From herrick at openjdk.java.net  Tue Oct 20 23:00:14 2020
From: herrick at openjdk.java.net (Andy Herrick)
Date: Tue, 20 Oct 2020 23:00:14 GMT
Subject: Integrated: JDK-8254783: jpackage fails on Windows when application
 name differs from installer name
In-Reply-To: <r6qCtHMkiKtZiotu5BHVP84rqeUL_5mkVyFlBeCqC7A=.45656321-6f24-4fa1-b82d-2c9797c511cf@github.com>
References: <r6qCtHMkiKtZiotu5BHVP84rqeUL_5mkVyFlBeCqC7A=.45656321-6f24-4fa1-b82d-2c9797c511cf@github.com>
Message-ID: <RjAVaQJsMYEpnIj_dDovsw3OqcLLJUlZZ63l1JQJb_I=.f779015d-1887-4c85-8e91-23b6c9e97cd3@github.com>

On Sat, 17 Oct 2020 14:01:22 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> ?from installer name
> JDK-8254783: jpackage fails on Windows when application name differs from installer name
> When using --app-image, to create MSI installer, use the application name from AppImageData instead of the Msi
> installer name if possible.

This pull request has now been integrated.

Changeset: afc967fc
Author:    Andy Herrick <herrick at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/afc967fc
Stats:     8 lines in 1 file changed: 7 ins; 0 del; 1 mod

8254783: jpackage fails on Windows when application name differs from installer name

Reviewed-by: asemenyuk, kizune, almatvee

-------------

PR: https://git.openjdk.java.net/jdk/pull/720

From kvn at openjdk.java.net  Tue Oct 20 23:11:19 2020
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Tue, 20 Oct 2020 23:11:19 GMT
Subject: RFR: 8252204: AArch64: Implement SHA3 accelerator/intrinsic [v10]
In-Reply-To: <kIpiKx8ovndJoa7alAki42vJ4H2lBJ4wN7MFqH5MORg=.57966a12-aa0c-40fb-815b-8bec9c7e8eda@github.com>
References: <PJVtIubjiGKhCK81PIMhWuYxnR84DNieMDUGHdhHYZM=.ad903c93-c5e3-4614-9af1-d36bc33f735d@github.com>
 <kIpiKx8ovndJoa7alAki42vJ4H2lBJ4wN7MFqH5MORg=.57966a12-aa0c-40fb-815b-8bec9c7e8eda@github.com>
Message-ID: <BtDcca4uUEPGQRwcPjA_ckSsCEX7u_chBB7Qe6P6Wp8=.40f38c07-d6db-41f2-bfa4-a7df321786f2@github.com>

On Tue, 20 Oct 2020 13:42:27 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Contributed-by: ard.biesheuvel at linaro.org, dongbo4 at huawei.com
>> 
>> This added an intrinsic for SHA3 using aarch64 v8.2 SHA3 Crypto Extensions.
>> Reference implementation for core SHA-3 transform using ARMv8.2 Crypto Extensions:
>> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm64/crypto/sha3-ce-core.S?h=v5.4.52
>> 
>> Trivial adaptation in SHA3. implCompress is needed for the purpose of adding the intrinsic.
>> For SHA3, we need to pass one extra parameter "digestLength" to the stub for the calculation of block size.
>> "digestLength" is also used in for the EOR loop before keccak to differentiate different SHA3 variants.
>> 
>> We added jtreg tests for SHA3 and used QEMU system emulator which supports SHA3 instructions to test the functionality.
>> Patch passed jtreg tier1-3 tests with QEMU system emulator.
>> Also verified with jtreg tier1-3 tests without SHA3 instructions on aarch64-linux-gnu and x86_64-linux-gnu, to make
>> sure that there's no regression.
>> We used one existing JMH test for performance test: test/micro/org/openjdk/bench/java/security/MessageDigests.java
>> We measured the performance benefit with an aarch64 cycle-accurate simulator.
>> Patch delivers 20% - 40% performance improvement depending on specific SHA3 digest length and size of the message.
>> 
>> For now, this feature will not be enabled automatically for aarch64. We can auto-enable this when it is fully tested on
>> real hardware.  But for the above testing purposes, this is auto-enabled when the corresponding hardware feature is
>> detected.
>
> Fei Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains
> 13 commits:
>  - Fix trailing whitespace issue reported by jcheck
>  - Merge master
>  - Merge master
>  - Remove unnecessary code changes in vm_version_aarch64.cpp
>  - Merge master
>  - Merge master
>  - Merge master
>  - Merge master
>  - Add sha3 instructions to cpu/aarch64/aarch64-asmtest.py and regenerate the test in assembler_aarch64.cpp:asm_check
>  - Rebase
>  - ... and 3 more: https://git.openjdk.java.net/jdk/compare/cdc8c401...d32c8ad7

Someone in Oracle have to run tier1-tier3 testing with these changes to make sure nothing is broken. I don't want to
repeat 8254790.

src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/CheckGraalIntrinsics.java
line 604:

> 602:             add(ignore, "sun/security/provider/SHA5." + shaCompressName + "([BI)V");
> 603:         }
> 604:         add(toBeInvestigated, "sun/security/provider/SHA3." + shaCompressName + "([BI)V");

This should be under `if (isJDK16OrHigher())` check. Something like this:
https://github.com/openjdk/jdk/pull/650/files#diff-d1f378fc1b7fe041309e854d40b3a95a91e63fdecf0ecd9826b7c95eaeba314eR527
You can wait when Aleksey push it and update your changes

-------------

Changes requested by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/207

From bpb at openjdk.java.net  Tue Oct 20 23:28:13 2020
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Tue, 20 Oct 2020 23:28:13 GMT
Subject: RFR: 8255031 : Update java/util/prefs/AddNodeChangeListener.java
 to report more failure info
In-Reply-To: <WdQlv9nOZU91fs2chRaHhYRTVnuMwcB297XumQEUW7k=.9f8d9fe3-4418-4d8b-95db-2cc31ab34ebf@github.com>
References: <WdQlv9nOZU91fs2chRaHhYRTVnuMwcB297XumQEUW7k=.9f8d9fe3-4418-4d8b-95db-2cc31ab34ebf@github.com>
Message-ID: <ZRV3SOkJEwknALGlWvNjoTzp0B7njS082WWSfN0jaqw=.2be56475-f32b-45f7-b800-3681b9834776@github.com>

On Tue, 20 Oct 2020 21:49:37 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> Hi,
> 
> The java/util/prefs/AddNodeChangeListener.java test fails once in a while in the automated test system.  Previous
> failures were traced to machine configuration errors, but that does not appear to be the case this time.
> My efforts to reproduce this failure have been unsuccessful.  The only useful information I've gleaned so far from the
> test failure logs is that the overall duration for running tier1 is longer than usual when the test failure happens.
> I would like to make the following updates to the test, in hopes of learning more if and when this test fails again:
> 
> * fail faster, to report if it is addNode() or removeNode() that is failing
> * make multiple attempts to sleep+check the NodeChangeListener.  (If the test fails after a single sleep, but passes
>   after waiting longer, maybe we just need to sleep for longer to account for the occasional slower tier1 test run).
> * a few indentations fixes
> 
> Thanks,
> -Brent

test/jdk/java/util/prefs/AddNodeChangeListener.java line 65:

> 63:
> 64:         for (int i = 0; i < SLEEP_ITRS; i++) {
> 65:             Thread.sleep(3000);

Would there be any value in printing the iteration number here and in the analogous location in removeNode() in case
the test times out?

-------------

PR: https://git.openjdk.java.net/jdk/pull/773

From mchung at openjdk.java.net  Tue Oct 20 23:45:17 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 20 Oct 2020 23:45:17 GMT
Subject: RFR: 8159746: (proxy) Support for default methods
In-Reply-To: <NMXKaHql9XjndqPgyoN1Lasa9H8ugl8-ltD1j2XiT9Y=.3ff8871e-0f9d-40ea-8f35-e804a9afcbd5@github.com>
References: <kw2VXh3vTFf1zgfd4biXA41OKffZ5oU7KT23tXAxgUA=.bcf14ffc-4dba-4c9c-8754-184172c5acbd@github.com>
 <U-6RiCpFVIrhLztPN6opiPcpFtxValDzU-K7WWFZM-4=.6bc8aaa4-636a-4664-b380-4c4af00513bd@github.com>
 <-cLIJ8pFHtnNoJMHV3aXI7XMJWp4Jrutc8Xn5PG0OK8=.d2cd87ab-3592-4524-ad85-05444c43689b@github.com>
 <r0UK2qjnmgeTNDDSWaSLPAj3QRgx_4YB82ielllO7jM=.fa615bc0-db49-4a74-b842-793f8f5209bb@github.com>
 <1T8kXDZN1bhHr4c8v4SQsImeBySCqTfX-u3_jzvyocA=.b4957400-9a33-4b6e-8475-329642a5888c@github.com>
 <XIux-dY0JXHRafHk48kVNXId9r-HSceNSytBojDxelY=.872e74cb-b064-406e-b71f-13c90ec7fbbc@github.com>
 <j4t2vT0SnwnU7lhKRlXtk967d-K6nA0EqHrqNbba7W0=.dc05dba6-bf7e-4606-8a02-9c2bad4b3b58@github.com>
 <fmVtPcBdgMuZOPm2qx3Q3znVZM7JgQPkhPAVLtwkOhE=.2d8b8447-cfae-4cb3-9a7c-6567a881231f@github.com>
 <GSeWP29fAIUFSk0CYsC557w52CuLqeUWwHNK9maltwI=.3d5f002e-6b74-4a57-a5d8-244d27da9dde@github.com>
 <GF8iEOkMUEL2dYB0HytFIc9gyeeUJ_KP0ImlqFsul2Y=.894afc05-9310-43e1-a308-8f7d71dc572b@github.com>
 <HvtDex3cmiv7XeTMITOroYfu74amSGQavQ_
 BAmVzmXw=.223be989-7c20-4ba4-ac0d-013d2b75a8cb@github.com>
 <IqRiLphFPBpGiKAnMJXqxjie9YeZ03rcE-qG1s92BLw=.d4fd5e92-5067-40df-8a0b-1dfd3d6e23af@github.com>
 <Y0hE51G3YefI6NY1O_E6VoZSKwxE78S1hv6fEatmOG8=.0a2c686c-d9ad-418c-8c1b-49addb8a54b1@github.com>
 <QrNk57L2PWQhJjzYiGTsvYyGIPAfK7bP_kANtTR-2uM=.3e5ce990-f8ea-4751-8147-27a8a9dad40d@github.com>
 <9JNNUzfV3PSvKtSg2a_zyYJmgEn3sZL9cb5sfqemk2o=.f1ef7fb7-bdd5-44ed-98c8-59213e9094f9@github.com>
 <zWGhaC8YB5I0XgffiR7o_YT5gSp9Gbj8Drtt23brl-c=.1e59f0e4-bbe3-4fb2-94dc-c55fc862f091@github.com>
 <LljojgqBhEi6tFptsbmu1jS-Xx7lYEXm9tRkkPqDGzE=.3d7d6a37-1042-4539-88d1-9f4cf5378128@github.com>
 <Gn33ydZNxqOpWUrmYiWJadMF0mukI2MR85EtgrV4D1I=.958521f2-1167-4a68-b513-e10bba37ae18@github.com>
 <NMXKaHql9XjndqPgyoN1Lasa9H8ugl8-ltD1j2XiT9Y=.3ff8871e-0f9d-40ea-8f35-e804a9afcbd5@github.com>
Message-ID: <yzFe02HJ2qt5tT8tY9ZOofnKld93x1PM5U7AToTABJs=.439c213b-94b9-488f-bb6d-a835a86c527f@github.com>

On Sun, 18 Oct 2020 15:09:31 GMT, Peter Levart <plevart at openjdk.org> wrote:

>> Hi Peter,
>> 
>> This seems an attracting idea to keep the possibility of using lambdas.  However, the full privileged lookup of the
>> proxy class will be leaked to `InvocationHandlerWithLookup` implementation which imposes security concerns.   This
>> full-privileged lookup has access to other proxy classes in that module including private members that we don't want to
>> hand out to user code.  Other than this security concern, we will also need to consider the inconsistency having
>> `java.lang.reflect` API to reference `Lookup`.
>
> Hi Mandy,
> 
> You're right. I haven't thought of what one can do with a Lookup for one proxy class when other proxy classes are
> co-located in the same module and/or package. So instead of a Lookup, we could use some other more targeted
> "capability". Here's alternative API no.2 that uses special SuperInvoker callback interface passed as argument to
> invocation handler:  https://github.com/mlchung/jdk/pull/4
> Each proxy class has its own SuperInvoker instance, assigned to static final field of generated proxy class like Method
> objects, which is passed to invocation handler in the same way as the selected Method object. Invocation handler can
> use this SuperInvoker instance to invoke the super default method on the proxy. SuperInvoker can verify that the
> passed-in proxy is of the correct class very quickly. Also the cache of transformed method handles per Method is
> embedded in the SuperInvoker itself instead of using ClassValue to hold it, so overhead for super invocations is
> further reduced:  Mandy's original:  Benchmark             Mode  Cnt    Score    Error  Units ProxyBench.implClass
> avgt    5    3.709 ?  0.026  ns/op ProxyBench.implProxy  avgt    5  926.215 ? 11.835  ns/op
> 
> 
> Peter's performance patch:
> 
> Benchmark             Mode  Cnt   Score   Error  Units
> ProxyBench.implClass  avgt    5   3.777 ? 0.005  ns/op
> ProxyBench.implProxy  avgt    5  27.579 ? 0.250  ns/op
> 
> 
> Static method moved to InvocationHandler + added access check
> 
> Benchmark               Mode  Cnt    Score   Error  Units
> ProxyBench.implClass    avgt    5    3.740 ? 0.004  ns/op
> ProxyBench.implProxy    avgt    5   34.226 ? 0.125  ns/op
> ProxyBench.ppImplClass  avgt    5    3.780 ? 0.004  ns/op
> ProxyBench.ppImplProxy  avgt    5  147.318 ? 1.422  ns/op
> 
> 
> Alternative API #1 with access check in newProxyInstance and Lookup parameter
> 
> Benchmark               Mode  Cnt   Score   Error  Units
> ProxyBench.implClass    avgt    5   3.782 ? 0.013  ns/op
> ProxyBench.implProxy    avgt    5  32.493 ? 0.192  ns/op
> ProxyBench.ppImplClass  avgt    5   3.749 ? 0.002  ns/op
> ProxyBench.ppImplProxy  avgt    5  30.565 ? 0.190  ns/op
> 
> 
> Alternative API #2 with SuperInvoker parameter
> 
> Benchmark               Mode  Cnt   Score   Error  Units
> ProxyBench.implClass    avgt    5   3.777 ? 0.003  ns/op
> ProxyBench.implProxy    avgt    5  20.282 ? 0.585  ns/op
> ProxyBench.ppImplClass  avgt    5   3.752 ? 0.002  ns/op
> ProxyBench.ppImplProxy  avgt    5  19.790 ? 0.335  ns/op
> 
> So what do you think about this one?

Hi Peter, thanks for coming with these alternatives.   The need for new `InvocationHandler2` and
`InvocationHandler2.SuperInvoker` APIs and the complexity of `plevart:proxy-default-method-alt-api2` look unpleasing in
order to keep the invocation of default methods in lambdas.  I prefer the `DelegatingInvocationHandler` abstract class
approach without caller-sensitive method.

-------------

PR: https://git.openjdk.java.net/jdk/pull/313

From lancea at openjdk.java.net  Tue Oct 20 23:51:21 2020
From: lancea at openjdk.java.net (Lance Andersen)
Date: Tue, 20 Oct 2020 23:51:21 GMT
Subject: RFR: JDK-8253936 Replace <code>...</code> with {@code ...} for
 java.sql
In-Reply-To: <zr8HOhlJbmboYIC-rVP0S3Mj5FeXOI4lzlUXvL2XMoc=.f173b3a1-f879-458c-9450-c432cecb6d6f@github.com>
References: <zr8HOhlJbmboYIC-rVP0S3Mj5FeXOI4lzlUXvL2XMoc=.f173b3a1-f879-458c-9450-c432cecb6d6f@github.com>
Message-ID: <AyS4mFs0zXTVMLUyKI6Qzw2DxTHHt6l4S1DpHEKze6k=.41fdb6eb-8ea0-4521-aa1b-9e173fa705d5@github.com>

On Fri, 16 Oct 2020 19:38:45 GMT, Vipin Sharma <vsharma at openjdk.org> wrote:

> <code>...</code> is replaced with {@code ...} in java.sql classes.
> Please review and sponsor this change.

Hi Vipin

Thank you for tackling this update.  There are a few required changes below.  I will also be going through the
generated javadoc to see if anything jumps out as well.

Best
Lance

src/java.sql/share/classes/java/sql/BatchUpdateException.java line 281:

> 279:    * @param reason a description of the exception
> 280:    * @param updateCounts an array of <code>int</code>, with each element
> 281:    *indicating the update count, <code>Statement.SUCCESS_NO_INFO</code> or

Please add a space before indicating

src/java.sql/share/classes/java/sql/DataTruncation.java line 2:

> 1: /*
> 2:  * Copyright (c) 1996, 2013, 2020, Oracle and/or its affiliates. All rights reserved.

The copyright update is incorrect, it should be 1996, 2020

src/java.sql/share/classes/java/sql/DriverPropertyInfo.java line 2:

> 1: /*
> 2:  * Copyright (c) 1996, 2013, 2020, Oracle and/or its affiliates. All rights reserved.

Please correct the copyright as mentioned above

src/java.sql/share/classes/java/sql/NClob.java line 2:

> 1: /*
> 2:  * Copyright (c) 2005, 2013, 2020, Oracle and/or its affiliates. All rights reserved.

Please fix the copyright

src/java.sql/share/classes/java/sql/ResultSet.java line 2001:

> 1999:
> 2000:     /**
> 2001:      * Updates the designated column with a {@code float } value.

Please remove the space after float

src/java.sql/share/classes/java/sql/RowId.java line 2:

> 1: /*
> 2:  * Copyright (c) 2005, 2006, 2020, Oracle and/or its affiliates. All rights reserved.

Please fix the copyright

src/java.sql/share/classes/java/sql/SQLClientInfoException.java line 38:

> 36:  * atomically.  For those databases, it is possible that some of the client
> 37:  * info properties had been set even though the {@code Connection.setClientInfo}
> 38:  * method threw an exception.  An application can use the {@code getFailedProperties }

Please remove the extra space after getFailedProperties

src/java.sql/share/classes/java/sql/SQLDataException.java line 2:

> 1: /*
> 2:  * Copyright (c) 2005, 2010, 2020, Oracle and/or its affiliates. All rights reserved.

Please fix the copyright

src/java.sql/share/classes/java/sql/SQLException.java line 2:

> 1: /*
> 2:  * Copyright (c) 1996, 2014, 2020, Oracle and/or its affiliates. All rights reserved.

please fix the copyright

src/java.sql/share/classes/java/sql/SQLFeatureNotSupportedException.java line 2:

> 1: /*
> 2:  * Copyright (c) 2005, 2013, 2020, Oracle and/or its affiliates. All rights reserved.

please fix the copyright

src/java.sql/share/classes/java/sql/SQLIntegrityConstraintViolationException.java line 2:

> 1: /*
> 2:  * Copyright (c) 2005, 2013, 2020, Oracle and/or its affiliates. All rights reserved.

please fix the copyright

src/java.sql/share/classes/java/sql/SQLInvalidAuthorizationSpecException.java line 2:

> 1: /*
> 2:  * Copyright (c) 2005, 2013, 2020, Oracle and/or its affiliates. All rights reserved.

please fix the copyright

src/java.sql/share/classes/java/sql/SQLNonTransientConnectionException.java line 2:

> 1: /*
> 2:  * Copyright (c) 2005, 2013, 2020, Oracle and/or its affiliates. All rights reserved.

please fix the copyright

src/java.sql/share/classes/java/sql/SQLNonTransientConnectionException.java line 125:

> 123:
> 124:     /**
> 125:      * Constructs a {@code SQLTransientException} object

This should be SQLNonTransientConnectionException

src/java.sql/share/classes/java/sql/SQLNonTransientException.java line 2:

> 1: /*
> 2:  * Copyright (c) 2005, 2013, 2020, Oracle and/or its affiliates. All rights reserved.

please fix the copyright

src/java.sql/share/classes/java/sql/SQLNonTransientException.java line 122:

> 120:
> 121:     /**
> 122:      * Constructs a {@code SQLTransientException} object

Should be SQLNonTransiientException

src/java.sql/share/classes/java/sql/SQLPermission.java line 2:

> 1: /*
> 2:  * Copyright (c) 1999, 2017, 2020, Oracle and/or its affiliates. All rights reserved.

please fix the copyright

src/java.sql/share/classes/java/sql/SQLRecoverableException.java line 2:

> 1: /*
> 2:  * Copyright (c) 2006, 2013, 2020, Oracle and/or its affiliates. All rights reserved.

please fix the copyright

src/java.sql/share/classes/java/sql/SQLSyntaxErrorException.java line 2:

> 1: /*
> 2:  * Copyright (c) 2005, 2013, 2020, Oracle and/or its affiliates. All rights reserved.

please fix the copyright

src/java.sql/share/classes/java/sql/SQLTimeoutException.java line 2:

> 1: /*
> 2:  * Copyright (c) 1996, 2013, 2020, Oracle and/or its affiliates. All rights reserved.

please fix the copyright

src/java.sql/share/classes/java/sql/SQLTransactionRollbackException.java line 2:

> 1: /*
> 2:  * Copyright (c) 2005, 2013, 2020, Oracle and/or its affiliates. All rights reserved.

please fix the copyright

src/java.sql/share/classes/java/sql/SQLTransientConnectionException.java line 2:

> 1: /*
> 2:  * Copyright (c) 2005, 2013, 2020, Oracle and/or its affiliates. All rights reserved.

please fix the copyright

src/java.sql/share/classes/java/sql/SQLTransientException.java line 2:

> 1: /*
> 2:  * Copyright (c) 2005, 2013, 2020, Oracle and/or its affiliates. All rights reserved.

please fix the copyright

src/java.sql/share/classes/java/sql/SQLWarning.java line 2:

> 1: /*
> 2:  * Copyright (c) 1996, 2013, 2020, Oracle and/or its affiliates. All rights reserved.

please fix the copyright

src/java.sql/share/classes/java/sql/Types.java line 2:

> 1: /*
> 2:  * Copyright (c) 1996, 2014, 2020, Oracle and/or its affiliates. All rights reserved.

please fix the copyright

src/java.sql/share/classes/java/sql/Wrapper.java line 2:

> 1: /*
> 2:  * Copyright (c) 2005, 2013, 2020, Oracle and/or its affiliates. All rights reserved.

please fix the copyright

src/java.sql/share/classes/javax/sql/ConnectionEvent.java line 2:

> 1: /*
> 2:  * Copyright (c) 2000, 2006, 2020, Oracle and/or its affiliates. All rights reserved.

please fix the copyright

src/java.sql/share/classes/javax/sql/ConnectionEventListener.java line 2:

> 1: /*
> 2:  * Copyright (c) 2000, 2001, 2020, Oracle and/or its affiliates. All rights reserved.

please fix the copyright

src/java.sql/share/classes/javax/sql/RowSetEvent.java line 2:

> 1: /*
> 2:  * Copyright (c) 2000, 2006, 2020, Oracle and/or its affiliates. All rights reserved.

please fix the copyright

src/java.sql/share/classes/javax/sql/RowSetListener.java line 2:

> 1: /*
> 2:  * Copyright (c) 2000, 2001, 2020, Oracle and/or its affiliates. All rights reserved.

please fix the copyright

src/java.sql/share/classes/javax/sql/StatementEventListener.java line 2:

> 1: /*
> 2:  * Copyright (c) 2005, 2014, 2020, Oracle and/or its affiliates. All rights reserved.

please fix the copyright

-------------

Changes requested by lancea (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/707

From github.com+1290376+johnlinp at openjdk.java.net  Tue Oct 20 23:57:09 2020
From: github.com+1290376+johnlinp at openjdk.java.net (John Lin)
Date: Tue, 20 Oct 2020 23:57:09 GMT
Subject: RFR: 8247402: Documentation for Map::compute contains confusing
 implementation requirements
In-Reply-To: <p-8_7BL98mDBPIliaMq9DIvIe0pzeV_D6aE0js-D2Rc=.3a44e9bc-24a8-4496-9d07-f77191c9b029@github.com>
References: <ZQNheDIQUwvUufEkds2N7kkr0kV6No0Cc9qIzX_FY04=.6624b5ff-dad7-4fd1-8677-51da85a5b149@github.com>
 <p-8_7BL98mDBPIliaMq9DIvIe0pzeV_D6aE0js-D2Rc=.3a44e9bc-24a8-4496-9d07-f77191c9b029@github.com>
Message-ID: <pKnptPtrKVL4BIZV1gAM9EjAIzBlNgc38GRuOkx4dqo=.d8546d8d-68d8-42c9-9c7d-e153a0b4b1f6@github.com>

On Mon, 19 Oct 2020 17:26:56 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> This is from the mailing list: http://mail.openjdk.java.net/pipermail/core-libs-dev/2020-June/067190.html
>> 
>> ---------
>> ### Progress
>> - [x] Change must not contain extraneous whitespace
>> - [x] Commit message must refer to an issue
>> - [ ] Change must be properly reviewed
>> 
>> ### Testing
>> 
>> |     | Linux x64 | Windows x64 | macOS x64 |
>> | --- | ----- | ----- | ----- |
>> | Build | ?? (5/5 passed) | ?? (2/2 passed) | ?? (2/2 passed) |
>> | Test (tier1) | ?? (9/9 passed) | ?? (9/9 passed) | ?? (9/9 passed) |
>> 
>> 
>> 
>> ### Download
>> `$ git fetch https://git.openjdk.java.net/jdk pull/714/head:pull/714`
>> `$ git checkout pull/714`
>
> Hi Jon,
> 
> Can you explain what this change is about: e.g. something like:
> 
>> Updates the documentation of `Map::compute` to match its default implementation:
>> The documentation of the default implementation of `Map::compute` was both wrong and confusing.
>> This change updates the documentation to match the behaviour of the implementation.
> 
> because now I am confused. I believe what you are trying to do is what I have written above. Can you confirm?
> This will need a CSR.
> 
> And are you going to withdraw https://github.com/openjdk/jdk/pull/451 now?
> 
> best regards,
> -- daniel

Hi @dfuch,

Thanks for reviewing my PR. You're absolutely correct about what this PR is about. Besides, I already closed #451.

-------------

PR: https://git.openjdk.java.net/jdk/pull/714

From github.com+1290376+johnlinp at openjdk.java.net  Wed Oct 21 00:14:10 2020
From: github.com+1290376+johnlinp at openjdk.java.net (John Lin)
Date: Wed, 21 Oct 2020 00:14:10 GMT
Subject: RFR: 8247402: Documentation for Map::compute contains confusing
 implementation requirements
In-Reply-To: <pKnptPtrKVL4BIZV1gAM9EjAIzBlNgc38GRuOkx4dqo=.d8546d8d-68d8-42c9-9c7d-e153a0b4b1f6@github.com>
References: <ZQNheDIQUwvUufEkds2N7kkr0kV6No0Cc9qIzX_FY04=.6624b5ff-dad7-4fd1-8677-51da85a5b149@github.com>
 <p-8_7BL98mDBPIliaMq9DIvIe0pzeV_D6aE0js-D2Rc=.3a44e9bc-24a8-4496-9d07-f77191c9b029@github.com>
 <pKnptPtrKVL4BIZV1gAM9EjAIzBlNgc38GRuOkx4dqo=.d8546d8d-68d8-42c9-9c7d-e153a0b4b1f6@github.com>
Message-ID: <cXi4c8cnu_udIQ3Qeo29_I7hH5zvrri6LxaW-wN1ZEI=.ffb077b1-179b-4082-b0fb-fd3b3d400e93@github.com>

On Tue, 20 Oct 2020 23:54:08 GMT, John Lin <github.com+1290376+johnlinp at openjdk.org> wrote:

>> Hi Jon,
>> 
>> Can you explain what this change is about: e.g. something like:
>> 
>>> Updates the documentation of `Map::compute` to match its default implementation:
>>> The documentation of the default implementation of `Map::compute` was both wrong and confusing.
>>> This change updates the documentation to match the behaviour of the implementation.
>> 
>> because now I am confused. I believe what you are trying to do is what I have written above. Can you confirm?
>> This will need a CSR.
>> 
>> And are you going to withdraw https://github.com/openjdk/jdk/pull/451 now?
>> 
>> best regards,
>> -- daniel
>
> Hi @dfuch,
> 
> Thanks for reviewing my PR. You're absolutely correct about what this PR is about. Besides, I already closed #451.

@dfuch May I ask how can I create a CSR? I checked https://wiki.openjdk.java.net/display/csr/CSR+FAQs and it says:

> Q: How do I create a CSR ?
> A: Do not directly create a CSR from the Create Menu. JIRA will let you do this right up until the moment you try to
> save it and find your typing was in vain. Instead you should go to the target bug, select "More", and from the drop
> down menu select "Create CSR". This is required to properly associate the CSR with the main bug, just as is done for
> backports.

However, I don't have an account at https://bugs.openjdk.java.net/ yet. Therefore, I don't see the "More" button on
https://bugs.openjdk.java.net/browse/JDK-8247402. Could you please tell me how do I proceed? Thank you.

-------------

PR: https://git.openjdk.java.net/jdk/pull/714

From vromero at openjdk.java.net  Wed Oct 21 00:21:22 2020
From: vromero at openjdk.java.net (Vicente Romero)
Date: Wed, 21 Oct 2020 00:21:22 GMT
Subject: RFR: 8250625: Compiler implementation of Pattern Matching for
 instanceof (Final) [v2]
In-Reply-To: <rYOjux1Z6MNttDR7kuCqksinlB_n8gWAX_2ttvSrBRo=.68b4e032-f689-4ff1-b7a8-49937f7a85ad@github.com>
References: <0uEby0-y3KVBLA1VxxdD5hCMlLhPCKB3w0mpihs9dsY=.181f22cd-7cf7-4941-b2d1-2ba4228d11d5@github.com>
 <rYOjux1Z6MNttDR7kuCqksinlB_n8gWAX_2ttvSrBRo=.68b4e032-f689-4ff1-b7a8-49937f7a85ad@github.com>
Message-ID: <0SU2aKGcx0k7_gdxnWAAlfXorDf-jCjSLw3k6ucqhjg=.8c4832df-512e-4017-a2b6-fab5d4e1caec@github.com>

On Tue, 20 Oct 2020 12:03:39 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is the current proposed patch for the upcoming JEP 394, for pattern matching for instanceof.
>> 
>> A summary of changes:
>> -making the feature permanent (non-preview)
>> -making the binding variables non-final (as per current specification proposal)
>> -producing a compile-time error for the case where the expression's type is a subtype of the type test pattern's type
>>  (as per current specification proposal)
>> -changing the AST structure so that the binding variable has a VariableTree in the AST. BindingPatternTree is preserved
>>  and encloses the VariableTree. The reason is better consistency in the API, with nodes like CatchTree, EnhancedForLoop
>>  Tree, etc.
>> 
>> This change will not be integrated until JEP 394 is targetted.
>
> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev
> excludes the unrelated changes brought in by the merge/rebase. The pull request contains 15 additional commits since
> the last revision:
>  - Cleanup: using a null instead of List.of() as a parameter to JavaCompiler.getTask
>  - Merge branch 'master' into patterns-instanceof3
>  - Fixing more tests.
>  - Correcting positions.
>  - Improve the AST model.
>  - Merge branch 'master' into patterns-instanceof3
>  - Updating @since tags.
>  - Merge branch 'master' into patterns-instanceof3
>  - Cleaning up preview comments in javadoc.
>  - Merge branch 'master' into patterns-instanceof3
>  - ... and 5 more: https://git.openjdk.java.net/jdk/compare/3b3bcc2a...5978bca0

src/jdk.compiler/share/classes/com/sun/source/tree/BindingPatternTree.java line 48:

> 46:      * @deprecated Use getVariable().getType()
> 47:      */
> 48:     @Deprecated

shouldn't we use `@Deprecated(since=versionNumber)`

-------------

PR: https://git.openjdk.java.net/jdk/pull/559

From github.com+51754783+coreyashford at openjdk.java.net  Wed Oct 21 00:54:17 2020
From: github.com+51754783+coreyashford at openjdk.java.net (CoreyAshford)
Date: Wed, 21 Oct 2020 00:54:17 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v4]
In-Reply-To: <_Kp2I32RPuFG2TsngEkrL1CEHpYFbT5k2yLSpJ1r4-w=.d6734741-0392-4cc7-acef-81367a598ff4@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <45FtTQB1m6HyZSASY42STMkQffIWlVPibWn9_r00xYs=.daad2653-2571-491f-8dd7-5954fe4ece00@github.com>
 <u6HLR2PyvWgYbA58W3bCF4n38tpwQu2-ujPMvGpyyuo=.5a80f17c-83d5-4dc9-bad0-00e679fdd4be@github.com>
 <7-p-Kc9lQyyuoWdNtmgbXbwkxsgk4oQGKmFSCcMpvnU=.97810c01-3200-4767-bbd4-35d53c2bc5ca@github.com>
 <6Voyfr_s-ieyRA-8Rtvvpz7tkhhicA8sY2d2KTp3Kmw=.fa256bae-2143-4b43-bfea-5837ad31eb6a@github.com>
 <fFQfDMqdwosVGzcaJfblklUy1nPsEdZJI7ALmKq9XJs=.e869160e-76e7-4a6b-b45b-e9763d1ad06f@github.com>
 <vKcE4CeascBAQGeyu6is0Va0_k4aTrvgU41cjhG6Wdo=.4078814f-06ed-4978-9fcd-a4a5148c2bdc@github.com>
 <wQ6YtDhYzmcgpTUP4uFfBCo8UFWZENtTARWt_LTqPug=.30bc3fdb-f963-4918-ae4b-0fe174c38a23@github.com>
 <jqzI94j7kygJyD9HWwq5d3q3LGztS5FAdYm5Ix1QdjE=.808de4e6-0f6d-4e17-b807-25ef89e92541@github.com>
 <7XjzEn5DggliDrvjhrGwXZL5r4lsqeGF9SGLmRr5L84=.a4481a62-4ecf-4e3f-98f3-70e548c67b52@github.com>
 <9y5m4zfsDZMdIZ6CT38BzO0tpFMuFxUswAb
 pjfDny-w=.44c7ada7-bf77-45f1-b5a6-b542731d6685@github.com>
 <gC1r5U7FYGeYMGD5Kv0z9cUsqJ1P5mQRbXwbAP6MQ78=.5bfa32b0-8afa-492d-9499-2cfabf0f9352@github.com>
 <AzmoRxvROeSYxkNZG2UeaQkmIVdhbFve7-NMC2bvJOk=.f92a94a2-eb5e-48cf-a298-81a334ad5eee@github.com>
 <_Kp2I32RPuFG2TsngEkrL1CEHpYFbT5k2yLSpJ1r4-w=.d6734741-0392-4cc7-acef-81367a598ff4@github.com>
Message-ID: <iDmBTppSqRzPEsYyYHaPi5frU3au8QJ9BANrbRAWyHw=.7c7e53c5-fdfa-4e0a-aa3f-4445de101ad8@github.com>

On Tue, 20 Oct 2020 16:42:46 GMT, CoreyAshford <github.com+51754783+CoreyAshford at openjdk.org> wrote:

> @CoreyAshford apologies i pointed to the "umbrella" test that runs Graal unit tests, the actual test is
> [CheckGraalIntrinsics](https://github.com/openjdk/jdk/blob/master/src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/CheckGraalIntrinsics.java)
> See this PR for an example: #762

I believe I have a fix for this, but I'm having trouble running the test case.  I wasn't even aware of this test suite
before, so I've been trying to figure out how to correctly run it.  Here's what I'm seeing:

% pwd


% ~/git-trees/mx/mx --java-home /home/cjashfor/git-trees/jdk/build/linux-x86_64-server-slowdebug/jdk -v unittest
CheckGraalIntrinsics Setting environment variable
JAVA_HOME=/home/cjashfor/git-trees/jdk/build/linux-x86_64-server-slowdebug/jdk from --java-home env
JAVA_HOME=/home/cjashfor/git-trees/jdk/build/linux-x86_64-server-slowdebug/jdk
MX_SUBPROCESS_COMMAND_FILE=/tmp/mx_subprocess_command.LLxLCx MX_HOME=/home/cjashfor/git-trees/mx
MX_PRIMARY_SUITE_PATH=/home/cjashfor/git-trees/jdk/src/hotspot MX__SUITEMODEL=sibling \

[all files are up to date - skipping com.oracle.mxtool.junit.jdk9]
[all files are up to date - skipping com.oracle.mxtool.junit]
[skipping JUNIT_TOOL]
Traceback (most recent call last):
  File "/home/cjashfor/git-trees/mx/mx.py", line 17030, in <module>
    main()
  File "/home/cjashfor/git-trees/mx/mx.py", line 17011, in main
    retcode = c(command_args)
  File "/home/cjashfor/git-trees/mx/mx_commands.py", line 147, in __call__
    return self.command_function(*args, **kwargs)
  File "/home/cjashfor/git-trees/mx/mx_unittest.py", line 487, in unittest
    _unittest(args, ['@Test', '@Parameters'], junit_args, **parsed_args.__dict__)
  File "/home/cjashfor/git-trees/mx/mx_unittest.py", line 319, in _unittest
    _run_tests(args, harness, vmLauncher, annotations, testfile, blacklist, whitelist, regex, mx.suite(suite) if suite else
    None)
  File "/home/cjashfor/git-trees/mx/mx_unittest.py", line 179, in _run_tests
    if vmLauncher.jdk().javaCompliance < p.javaCompliance:
AttributeError: 'NoneType' object has no attribute 'javaCompliance'

Any ideas?

-------------

PR: https://git.openjdk.java.net/jdk/pull/293

From kvn at openjdk.java.net  Wed Oct 21 01:28:16 2020
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 21 Oct 2020 01:28:16 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v5]
In-Reply-To: <O4v-ldD7_Ya-1ILjIukRaAbhORzBPBiGZeI2mrnttNc=.b025900d-d284-40b3-814f-9fc8b6f75f46@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <O4v-ldD7_Ya-1ILjIukRaAbhORzBPBiGZeI2mrnttNc=.b025900d-d284-40b3-814f-9fc8b6f75f46@github.com>
Message-ID: <CXAVDgYpcgv8MB11hUIAtJ6Ay4qimPkk9VQytR13EpM=.df84e9cd-e8fd-4229-9d01-a3bfbda10da8@github.com>

On Mon, 12 Oct 2020 21:41:37 GMT, CoreyAshford <github.com+51754783+CoreyAshford at openjdk.org> wrote:

>> This patch set encompasses the following commits:
>> 
>> - Adds a new HotSpot intrinsic candidate to the java.lang.Base64 class - decodeBlock(), and provides a flexible API for
>>   the intrinsic.  The API is similar to the existing encodeBlock intrinsic.
>> - Adds the code in HotSpot to check and martial the new intrinsic's arguments to the arch-specific intrinsic
>>   implementation
>> - Adds a Power64LE-specific implementation of the decodeBlock intrinsic.
>> - Adds a JMH microbenchmark for both Base64 encoding and encoding.
>> - Enhances the JTReg hotspot intrinsic "TestBase64.java" regression test to more fully test both decoding and encoding.
>
> CoreyAshford has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Per Martin Doerr's v4 review: fix regression, and speed up return time for buffers that are too small
>   
>    - Check for case where the result of subtacting 12 off of the source
>      length produces a negative number.  To do this efficiently, I added the
>      instruction definition for mcrxrx, which is implemented on Power9+.
>   
>    - Rearrange the code so that minimal initialization is performed before
>      checking the size, so that the intrinsic can return quickly in the event
>      that the buffer is too small to process.

Please, update
src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/CheckGraalIntrinsics.java

-------------

Changes requested by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/293

From github.com+51754783+coreyashford at openjdk.java.net  Wed Oct 21 01:39:29 2020
From: github.com+51754783+coreyashford at openjdk.java.net (CoreyAshford)
Date: Wed, 21 Oct 2020 01:39:29 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v6]
In-Reply-To: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
Message-ID: <axdeFnVrDqoTybdr6mZDLgYOLRBHMOtIsCcnOI5IKU4=.ef8e57db-ca8a-48ab-a772-f599cbdec5e3@github.com>

> This patch set encompasses the following commits:
> 
> - Adds a new HotSpot intrinsic candidate to the java.lang.Base64 class - decodeBlock(), and provides a flexible API for
>   the intrinsic.  The API is similar to the existing encodeBlock intrinsic.
> - Adds the code in HotSpot to check and martial the new intrinsic's arguments to the arch-specific intrinsic
>   implementation
> - Adds a Power64LE-specific implementation of the decodeBlock intrinsic.
> - Adds a JMH microbenchmark for both Base64 encoding and encoding.
> - Enhances the JTReg hotspot intrinsic "TestBase64.java" regression test to more fully test both decoding and encoding.

CoreyAshford has updated the pull request with a new target base due to a merge or a rebase. The pull request now
contains 22 commits:

 - CheckGraalIntrinsics.java: Disable testing of decodeBlock intrinsic until implemented for AMD64/x86
 - Merge branch 'master' of https://git.openjdk.java.net/jdk into base64_decode_intrinsic
 - stubGenerator_ppc.cpp: remove unnecessary complexity for checking < 0 after srawi.
 - Per Martin Doerr's v4 review: fix regression, and speed up return time for buffers that are too small
   
    - Check for case where the result of subtacting 12 off of the source
      length produces a negative number.  To do this efficiently, I added the
      instruction definition for mcrxrx, which is implemented on Power9+.
   
    - Rearrange the code so that minimal initialization is performed before
      checking the size, so that the intrinsic can return quickly in the event
      that the buffer is too small to process.
 - TestBase64.java: fix comment to correctly reflect actual intrinsic names.
   
   The intrinsic names that are visible with -XX:+PrintCompilation are encode
   and decode, rather than encodeBlock and decodeBlock.
 - stubGenerator_ppc.cpp: fix regression caused by change to using loop counter
   
   My original fix didn't account for the case where sl < block_size.  In the
   event sl < block_size, the shifted sl will become zero, so it should
   jump to the code that computes how much data was processed - 0 - and return.
 - stubGenerator_ppc.cpp: Fix multiple issues as per Martin Doerr's v2 review
   
    * Remove extraneous comma from SAP copyright notice
    * Move align(32) to the head of the loop rather than the beginning of the unwound code
    * Simplified looping condition to use a loop counter instead of a final
      address.  This eliminated the need for the "end" variable, and
      essentially replaced it with CTR, which is computed using a simple
      bitwise shift of the size.
    * Re-ran benchmarks against loop_unrolls values: 1, 2, 4, 8, 16 to find
      optimal value, now 4.
    * Corrected a typo in the word "elements"
 - vm_version_ppc.cpp: per Martin Doerr's review of v2: fix copy/paste error
 - vmIntrinsics.cpp: Per Martin Doerr's v2 review: rearrange order of case statement to be consistent with others.
 - runtime.cpp: per Martin Doerr's review of v2, correct comment as per current semantics of decodeBlock()
   
     * The reference to "ofs" seems to be a copy/paste error.
     * -1 is no longer returned from decodeBlock() in the event of a
       non-base64 character being encountered; only a count of bytes written
       to dst.
 - ... and 12 more: https://git.openjdk.java.net/jdk/compare/3ccf4877...dcd15d57

-------------

Changes: https://git.openjdk.java.net/jdk/pull/293/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=293&range=05
  Stats: 1894 lines in 25 files changed: 1866 ins; 4 del; 24 mod
  Patch: https://git.openjdk.java.net/jdk/pull/293.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/293/head:pull/293

PR: https://git.openjdk.java.net/jdk/pull/293

From github.com+51754783+coreyashford at openjdk.java.net  Wed Oct 21 01:39:29 2020
From: github.com+51754783+coreyashford at openjdk.java.net (CoreyAshford)
Date: Wed, 21 Oct 2020 01:39:29 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v5]
In-Reply-To: <CXAVDgYpcgv8MB11hUIAtJ6Ay4qimPkk9VQytR13EpM=.df84e9cd-e8fd-4229-9d01-a3bfbda10da8@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <O4v-ldD7_Ya-1ILjIukRaAbhORzBPBiGZeI2mrnttNc=.b025900d-d284-40b3-814f-9fc8b6f75f46@github.com>
 <CXAVDgYpcgv8MB11hUIAtJ6Ay4qimPkk9VQytR13EpM=.df84e9cd-e8fd-4229-9d01-a3bfbda10da8@github.com>
Message-ID: <kaZ8GgvUgzXnkloAN5g-Z1yNwJTTE5jXhz31_eF66V0=.c8f667d4-85a1-4216-8236-90be64010343@github.com>

On Wed, 21 Oct 2020 01:25:33 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Please, update
> src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/CheckGraalIntrinsics.java

I will push the code, but I haven't been successful in running the test (see
https://github.com/openjdk/jdk/pull/293#issuecomment-713223068 )

-------------

PR: https://git.openjdk.java.net/jdk/pull/293

From github.com+51754783+coreyashford at openjdk.java.net  Wed Oct 21 01:51:26 2020
From: github.com+51754783+coreyashford at openjdk.java.net (CoreyAshford)
Date: Wed, 21 Oct 2020 01:51:26 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v7]
In-Reply-To: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
Message-ID: <7Dgp_C-H8LsbF3tPHinVmb5bT_LoLZLYZUx9eSqigCA=.894148e4-a3f2-42c3-ab19-13e134e66853@github.com>

> This patch set encompasses the following commits:
> 
> - Adds a new HotSpot intrinsic candidate to the java.lang.Base64 class - decodeBlock(), and provides a flexible API for
>   the intrinsic.  The API is similar to the existing encodeBlock intrinsic.
> - Adds the code in HotSpot to check and martial the new intrinsic's arguments to the arch-specific intrinsic
>   implementation
> - Adds a Power64LE-specific implementation of the decodeBlock intrinsic.
> - Adds a JMH microbenchmark for both Base64 encoding and encoding.
> - Enhances the JTReg hotspot intrinsic "TestBase64.java" regression test to more fully test both decoding and encoding.

CoreyAshford has updated the pull request incrementally with one additional commit since the last revision:

  CheckGraalIntrinsics.java: fix copy/paste error

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/293/files
  - new: https://git.openjdk.java.net/jdk/pull/293/files/dcd15d57..f93614dc

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=293&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=293&range=05-06

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/293.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/293/head:pull/293

PR: https://git.openjdk.java.net/jdk/pull/293

From kbarrett at openjdk.java.net  Wed Oct 21 02:28:30 2020
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Wed, 21 Oct 2020 02:28:30 GMT
Subject: RFR: 8188055: (ref) Add Reference::refersTo predicate [v5]
In-Reply-To: <FCKXn6qliafrA3jrNwx6yosTt0H_cDmU-j54yiNtyuw=.d5752bd9-74e0-4c15-b140-e98dd1b82804@github.com>
References: <D4HSg8FT20Eaxk5KJkkw0GgETSxRkBn1ipS3Dt0kPto=.e4bab078-2e04-4413-90cb-9bfafb2a6831@github.com>
 <FHx-oBhE254DZWHhg2RTKjZn_-yYN5xadTW7GXhTxzM=.7e6a46fa-5259-428c-b725-81b4fe48b8f7@github.com>
 <Ch2xqBrcg76WqiK0RVUEl_XcN4o7X4bvo44RPDDi3O8=.852fb1b6-77f5-4aaa-9ed6-bdee28ec8eb3@github.com>
 <E8OiCIWFPwu7ircN0UQiSG8yJ2QrbFNdYT_MHLHtKcQ=.85cd2acb-d656-4398-b7bf-1f2e9cc6bc58@github.com>
 <rDPsYfi057gmn-cIG04-EwHqFKj2vST5h-_PsJpnFj4=.0ecbdd68-329b-4376-a7ea-1be23206aa9b@github.com>
 <Nks-e8NMGE0VeZQF4zKg73QJt_Da3mm_Vom49v9odio=.ba79800e-3e32-465b-a516-2316b2bc4169@github.com>
 <VcqdD5owO8PgUmW8zfisLrc1eFYAeNOonJ6UtYt3YKI=.42cae436-5ce7-4f51-9513-c28164242328@github.com>
 <FCKXn6qliafrA3jrNwx6yosTt0H_cDmU-j54yiNtyuw=.d5752bd9-74e0-4c15-b140-e98dd1b82804@github.com>
Message-ID: <ndjq1CCCksdsv6xz_5leQFLDqt2_NWUI0oVxUFuBKo0=.8ac4d424-013d-4f62-b30f-efd7f0b5168b@github.com>

On Tue, 20 Oct 2020 16:35:02 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>>> @kimbarrett your reworded text is okay. I think "if it initially had some other referent value" can be dropped.
>>> 
>>> For a `Reference` constructed with a `null` referent, we can clarify in the spec that such reference object will never
>>> get cleared and enqueued. I suggest to file a separate issue to follow up.
>> 
>> I don't think that clause can be dropped, because of explicit clearing (by clear() or enqueue()) rather than by the
>> GC.  If the reference was constructed with a null referent, ref.refersTo(null) cannot tell whether ref.clear() has been
>> called.
>
>> Mandy's comment implied that references with a null referent never get enqueued. Otherwise when would they get
>> enqueued? There would be nothing to trigger it.
> 
> Sorry I should have been clearer.    What I try to say is that `Reference(null)`
> will never be cleared and enqueued by GC since its referent is `null`.
> 
> Kim is right that `Reference(null)` can be explicitly cleared and enqueued
> via `Reference::enqueue`.    `Reference::clear` on such an "empty" reference
> object is essentially a no-op.    Whoever creates an "empty" reference would
> not intend to be cleared.
> 
>> > But the more we discuss this the more I think allowing an initial null referent was a mistake in the first place. :(
>> 
>> I agree, but here we are. Very hard to know what the compatibility impact of changing that would be.
> 
> There are existing use cases depending on `Reference(null)` for example as a special
> instance be an empty reference or the head of a doubly-linked list of references.
> This was discussed two years ago [1].
> 
> [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2018-July/054325.html

David, Mandy, and I discussed the wording in refersTo javadoc and reached a consensus that is reflected in 3a15b6a.

-------------

PR: https://git.openjdk.java.net/jdk/pull/498

From kbarrett at openjdk.java.net  Wed Oct 21 02:28:30 2020
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Wed, 21 Oct 2020 02:28:30 GMT
Subject: RFR: 8188055: (ref) Add Reference::refersTo predicate [v6]
In-Reply-To: <D4HSg8FT20Eaxk5KJkkw0GgETSxRkBn1ipS3Dt0kPto=.e4bab078-2e04-4413-90cb-9bfafb2a6831@github.com>
References: <D4HSg8FT20Eaxk5KJkkw0GgETSxRkBn1ipS3Dt0kPto=.e4bab078-2e04-4413-90cb-9bfafb2a6831@github.com>
Message-ID: <0dhF_xxcp1VoUowwdZenB2qWa9ILcZjTMe3lsaRrg7k=.3c633db8-f745-4353-ad34-a64fbc96d4e0@github.com>

> Finally returning to this review that was started in April 2020.  I've
> recast it as a github PR.  I think the security concern raised by Gil
> has been adequately answered.
> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-April/029203.html
> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-July/030401.html
> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-August/030677.html
> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-September/030793.html
> 
> Please review a new function: java.lang.ref.Reference.refersTo.
> 
> This function is needed to test the referent of a Reference object without
> artificially extending the lifetime of the referent object, as may happen
> when calling Reference.get.  Some garbage collectors require extending the
> lifetime of a weak referent when accessed, in order to maintain collector
> invariants.  Lifetime extension may occur with any collector when the
> Reference is a SoftReference, as calling get indicates recent access.  This
> new function also allows testing the referent of a PhantomReference, which
> can't be accessed by calling get.
> 
> The new function uses native methods whose implementations are in the VM so
> they can use the Access API.  It is the intent that these methods will be
> intrinsified by optimizing compilers like C2 or graal, but that hasn't been
> implemented yet.  Bear that in mind before rushing off to change existing
> uses of Reference.get.
> 
> There are two native methods involved, one in Reference and an override in
> PhantomReference, both package private in java.lang.ref. The reason for this
> split is to simplify the intrinsification. This is a change from the version
> from April 2020; that version had a single native method in Reference,
> implemented using the ON_UNKNOWN_OOP_REF Access reference strength category.
> However, adding support for that category in the compilers adds significant
> implementation effort and complexity. Splitting avoids that complexity.
> 
> Testing:
> mach5 tier1
> Locally (linux-x64) verified the new test passes with various garbage collectors.

Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:

  improve wording in refersTo javadoc

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/498/files
  - new: https://git.openjdk.java.net/jdk/pull/498/files/ab4e519b..3a15b6a9

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=498&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=498&range=04-05

  Stats: 7 lines in 1 file changed: 0 ins; 2 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/498.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/498/head:pull/498

PR: https://git.openjdk.java.net/jdk/pull/498

From dholmes at openjdk.java.net  Wed Oct 21 02:58:26 2020
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 21 Oct 2020 02:58:26 GMT
Subject: RFR: 8188055: (ref) Add Reference::refersTo predicate [v6]
In-Reply-To: <0dhF_xxcp1VoUowwdZenB2qWa9ILcZjTMe3lsaRrg7k=.3c633db8-f745-4353-ad34-a64fbc96d4e0@github.com>
References: <D4HSg8FT20Eaxk5KJkkw0GgETSxRkBn1ipS3Dt0kPto=.e4bab078-2e04-4413-90cb-9bfafb2a6831@github.com>
 <0dhF_xxcp1VoUowwdZenB2qWa9ILcZjTMe3lsaRrg7k=.3c633db8-f745-4353-ad34-a64fbc96d4e0@github.com>
Message-ID: <fRm7x6jF10Gyk0tZJC1PA-mstU8iapiIPmlE5l6-VeA=.7234fbb0-93ae-4e78-a7f0-4c0445a38c91@github.com>

On Wed, 21 Oct 2020 02:28:30 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Finally returning to this review that was started in April 2020.  I've
>> recast it as a github PR.  I think the security concern raised by Gil
>> has been adequately answered.
>> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-April/029203.html
>> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-July/030401.html
>> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-August/030677.html
>> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-September/030793.html
>> 
>> Please review a new function: java.lang.ref.Reference.refersTo.
>> 
>> This function is needed to test the referent of a Reference object without
>> artificially extending the lifetime of the referent object, as may happen
>> when calling Reference.get.  Some garbage collectors require extending the
>> lifetime of a weak referent when accessed, in order to maintain collector
>> invariants.  Lifetime extension may occur with any collector when the
>> Reference is a SoftReference, as calling get indicates recent access.  This
>> new function also allows testing the referent of a PhantomReference, which
>> can't be accessed by calling get.
>> 
>> The new function uses native methods whose implementations are in the VM so
>> they can use the Access API.  It is the intent that these methods will be
>> intrinsified by optimizing compilers like C2 or graal, but that hasn't been
>> implemented yet.  Bear that in mind before rushing off to change existing
>> uses of Reference.get.
>> 
>> There are two native methods involved, one in Reference and an override in
>> PhantomReference, both package private in java.lang.ref. The reason for this
>> split is to simplify the intrinsification. This is a change from the version
>> from April 2020; that version had a single native method in Reference,
>> implemented using the ON_UNKNOWN_OOP_REF Access reference strength category.
>> However, adding support for that category in the compilers adds significant
>> implementation effort and complexity. Splitting avoids that complexity.
>> 
>> Testing:
>> mach5 tier1
>> Locally (linux-x64) verified the new test passes with various garbage collectors.
>
> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
> 
>   improve wording in refersTo javadoc

Update looks good. Need to reflect the change in the CSR.

Thanks.
David

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/498

From vromero at openjdk.java.net  Wed Oct 21 03:16:23 2020
From: vromero at openjdk.java.net (Vicente Romero)
Date: Wed, 21 Oct 2020 03:16:23 GMT
Subject: RFR: 8250625: Compiler implementation of Pattern Matching for
 instanceof (Final) [v2]
In-Reply-To: <rYOjux1Z6MNttDR7kuCqksinlB_n8gWAX_2ttvSrBRo=.68b4e032-f689-4ff1-b7a8-49937f7a85ad@github.com>
References: <0uEby0-y3KVBLA1VxxdD5hCMlLhPCKB3w0mpihs9dsY=.181f22cd-7cf7-4941-b2d1-2ba4228d11d5@github.com>
 <rYOjux1Z6MNttDR7kuCqksinlB_n8gWAX_2ttvSrBRo=.68b4e032-f689-4ff1-b7a8-49937f7a85ad@github.com>
Message-ID: <9ylwnQ8cWjQeQ9hbRDScySUuctce51DiXlm9sDOrTEo=.fef60e85-cef5-46a6-9183-a1dadc2a1062@github.com>

On Tue, 20 Oct 2020 12:03:39 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is the current proposed patch for the upcoming JEP 394, for pattern matching for instanceof.
>> 
>> A summary of changes:
>> -making the feature permanent (non-preview)
>> -making the binding variables non-final (as per current specification proposal)
>> -producing a compile-time error for the case where the expression's type is a subtype of the type test pattern's type
>>  (as per current specification proposal)
>> -changing the AST structure so that the binding variable has a VariableTree in the AST. BindingPatternTree is preserved
>>  and encloses the VariableTree. The reason is better consistency in the API, with nodes like CatchTree, EnhancedForLoop
>>  Tree, etc.
>> 
>> This change will not be integrated until JEP 394 is targetted.
>
> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev
> excludes the unrelated changes brought in by the merge/rebase. The pull request contains 15 additional commits since
> the last revision:
>  - Cleanup: using a null instead of List.of() as a parameter to JavaCompiler.getTask
>  - Merge branch 'master' into patterns-instanceof3
>  - Fixing more tests.
>  - Correcting positions.
>  - Improve the AST model.
>  - Merge branch 'master' into patterns-instanceof3
>  - Updating @since tags.
>  - Merge branch 'master' into patterns-instanceof3
>  - Cleaning up preview comments in javadoc.
>  - Merge branch 'master' into patterns-instanceof3
>  - ... and 5 more: https://git.openjdk.java.net/jdk/compare/062b3b15...5978bca0

Changes requested by vromero (Reviewer).

src/jdk.compiler/share/classes/com/sun/source/tree/PatternTree.java line 34:

> 32:  * @since 16
> 33:  */
> 34: public interface PatternTree extends Tree {}

I think that this interface is there for forward compatibility, it is still weird to have an empty interface and then
an empty class in JCTree implementing this interface. Doesn't it make sense to move any method from BindingPatternTree
up to this interface? I think that if having this empty interface is deemed unavoidable then, just an idea, we should
acknowledge the fact that this is a forward looking interface.

src/jdk.compiler/share/classes/com/sun/source/tree/PatternTree.java line 29:

> 27:
> 28: /**
> 29:  * A tree node used as the base class for the different kinds of

the javadoc seems to need an update

-------------

PR: https://git.openjdk.java.net/jdk/pull/559

From vromero at openjdk.java.net  Wed Oct 21 03:30:14 2020
From: vromero at openjdk.java.net (Vicente Romero)
Date: Wed, 21 Oct 2020 03:30:14 GMT
Subject: RFR: 8250625: Compiler implementation of Pattern Matching for
 instanceof (Final) [v2]
In-Reply-To: <rCOM4p8lSaD9EheSPUJkvQovRVNaLfzWoYUlVeTbhew=.154bf6a2-57ed-4c8f-813c-d3784704b740@github.com>
References: <0uEby0-y3KVBLA1VxxdD5hCMlLhPCKB3w0mpihs9dsY=.181f22cd-7cf7-4941-b2d1-2ba4228d11d5@github.com>
 <sQv_ZdanJ0-lLBox6CKwXxIXFrWSVNyWcN3sQZ5U1Bw=.1c5793db-f4e2-4ffd-9ed9-e93703e6107e@github.com>
 <rCOM4p8lSaD9EheSPUJkvQovRVNaLfzWoYUlVeTbhew=.154bf6a2-57ed-4c8f-813c-d3784704b740@github.com>
Message-ID: <QyZ9OmnQT_SZnBaurbZgYx2WTs3P07dky7Ec748Py_4=.8da887c0-295c-4c64-9b2f-84e75495a02f@github.com>

On Tue, 20 Oct 2020 11:36:41 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> test/langtools/tools/javac/patterns/LocalVariableTable.java line 29:
>> 
>>> 27:  * @summary Ensure the LV table entries are generated for bindings
>>> 28:  * @modules jdk.jdeps/com.sun.tools.classfile
>>> 29:  * @compile -g LocalVariableTable.java
>> 
>> I believe all tests are always compiled with `-g` option set, not related to your patch but we could probably remove
>> that line as superfluous
>
> I believe plain jtreg invocations may not be always setting "-g". So probably better to be explicitly clear we need -g,
> as the test itself requires the debugging info/LocalVariableTable?

sure I understand that the `-g` option is necessary. I was just wondering if `-g` is not passed always by jtreg. If the
option is passed by default then it is superfluous, although just a comment, I understand that it is safer to pass it

-------------

PR: https://git.openjdk.java.net/jdk/pull/559

From serb at openjdk.java.net  Wed Oct 21 04:59:11 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 21 Oct 2020 04:59:11 GMT
Subject: Integrated: 8255043: Incorrectly styled copyright text
In-Reply-To: <gmKuCsi5-p4TN8bZ4CswPyFBokCuuyLRwWNAGNktarI=.c88a1093-9525-40ca-9a37-0d780240b41a@github.com>
References: <gmKuCsi5-p4TN8bZ4CswPyFBokCuuyLRwWNAGNktarI=.c88a1093-9525-40ca-9a37-0d780240b41a@github.com>
Message-ID: <uY9_C2GsjjjeRUbkkGBGaLV1-0qpYTy51mavhxfKn-8=.83430cb4-fce3-4c17-83c8-e4f35c8f5af6@github.com>

On Tue, 20 Oct 2020 08:17:27 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> In some files, the copyright text is styled as a JavaDoc comment.
> Most of the affected files are tests, only one product file is affected:
> src/java.sql/share/classes/javax/sql/package-info.java
> 
> The chenge is trivial:
>  - /**
>  + /*
>     * Copyright (c)

This pull request has now been integrated.

Changeset: 2e510e04
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/2e510e04
Stats:     49 lines in 49 files changed: 0 ins; 0 del; 49 mod

8255043: Incorrectly styled copyright text

Reviewed-by: dholmes, trebari, jdv

-------------

PR: https://git.openjdk.java.net/jdk/pull/759

From github.com+51754783+coreyashford at openjdk.java.net  Wed Oct 21 06:25:19 2020
From: github.com+51754783+coreyashford at openjdk.java.net (CoreyAshford)
Date: Wed, 21 Oct 2020 06:25:19 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v5]
In-Reply-To: <kaZ8GgvUgzXnkloAN5g-Z1yNwJTTE5jXhz31_eF66V0=.c8f667d4-85a1-4216-8236-90be64010343@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <O4v-ldD7_Ya-1ILjIukRaAbhORzBPBiGZeI2mrnttNc=.b025900d-d284-40b3-814f-9fc8b6f75f46@github.com>
 <CXAVDgYpcgv8MB11hUIAtJ6Ay4qimPkk9VQytR13EpM=.df84e9cd-e8fd-4229-9d01-a3bfbda10da8@github.com>
 <kaZ8GgvUgzXnkloAN5g-Z1yNwJTTE5jXhz31_eF66V0=.c8f667d4-85a1-4216-8236-90be64010343@github.com>
Message-ID: <9dnt9VysFlp4SZ_1AFvgcP2kekCynAXzHNHG1HWJ-jg=.6b0cec9f-aca2-465f-a224-1880e4223780@github.com>

On Wed, 21 Oct 2020 01:33:48 GMT, CoreyAshford <github.com+51754783+CoreyAshford at openjdk.org> wrote:

>> Please, update
>> src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/CheckGraalIntrinsics.java
>
>> Please, update
>> src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/CheckGraalIntrinsics.java
> 
> I will push the code, but I haven't been successful in running the test (see
> https://github.com/openjdk/jdk/pull/293#issuecomment-713223068 )

The latest push triggered a CI test run, which has a single failure on Windows x64 (hs/tier1 compiler):
https://github.com/CoreyAshford/jdk/actions/runs/318910520

I'm not sure what to make of it yet.  It doesn't look related, but I'm not sure.

-------------

PR: https://git.openjdk.java.net/jdk/pull/293

From dawid.weiss at gmail.com  Wed Oct 21 08:55:42 2020
From: dawid.weiss at gmail.com (Dawid Weiss)
Date: Wed, 21 Oct 2020 10:55:42 +0200
Subject: "loc: wrong sig" in ZipFileSystem on a valid ZIP file (extra data
 field of exactly 5 bytes)
Message-ID: <CAM21Rt8KeWyQvjE7-5pfyXYJXO3yGgGfKpBtueOV8qgNFMa+jQ@mail.gmail.com>

Hello,

We've encountered a seemingly valid ZIP file (zipinfo -v shows all its
entries are intact) that causes a runtime exception when scanning its
contents with ZipFileSystem. The exception indicates an invalid
signature when parsing EXTID_EXTT. I don't quite understand this
comment in the code:

case EXTID_EXTT:
    // spec says the Extened timestamp in cen only has mtime
    // need to read the loc to get the extra a/ctime, if flag
    // "zipinfo-time" is not specified to false;
    // there is performance cost (move up to loc and read) to
    // access the loc table foreach entry;
    if (zipfs.noExtt) {
        if (sz == 5)
            mtime = unixToJavaTime(LG(extra, pos + 1));
         break;
    }
...

but this ZIP file has the extra data block of exactly 5 bytes, as
indicated by zipinfo:

Central directory entry #6:
---------------------------
...
  file system or operating system of origin:      Unix
  version of encoding software:                   3.0
  minimum file system compatibility required:     MS-DOS, OS/2 or NT FAT
  minimum software version required to extract:   2.0
  compression method:                             deflated
...
  extended local header:                          no
  file last modified on (DOS date/time):          2018 Mar 1 04:56:20
  file last modified on (UT extra field modtime): 2018 Mar 1 05:56:19 local
  file last modified on (UT extra field modtime): 2018 Mar 1 04:56:19 UTC
...
  Unix file attributes (100000 octal):            ----------
  MS-DOS file attributes (01 hex):                read-only

  The central-directory extra field contains:
  - A subfield with ID 0x5455 (universal time) and 5 data bytes.
    The local extra field has UTC/GMT modification/access times.

The above conditional block checking for length == 5 would have worked
in ZipFileSystem but it's surrounded by a condition over an
externally-provided property - zipfs.noExtt is only set to true if:

this.noExtt = "false".equals(env.get("zipinfo-time"));

I can't share this particular ZIP file with you and I don't know how
it was created but it seems like that "zipinfo-time" flag could be
omitted if the length of the extra data field is exactly 5?

Dawid

From fyang at openjdk.java.net  Wed Oct 21 09:10:57 2020
From: fyang at openjdk.java.net (Fei Yang)
Date: Wed, 21 Oct 2020 09:10:57 GMT
Subject: RFR: 8252204: AArch64: Implement SHA3 accelerator/intrinsic [v10]
In-Reply-To: <BtDcca4uUEPGQRwcPjA_ckSsCEX7u_chBB7Qe6P6Wp8=.40f38c07-d6db-41f2-bfa4-a7df321786f2@github.com>
References: <PJVtIubjiGKhCK81PIMhWuYxnR84DNieMDUGHdhHYZM=.ad903c93-c5e3-4614-9af1-d36bc33f735d@github.com>
 <kIpiKx8ovndJoa7alAki42vJ4H2lBJ4wN7MFqH5MORg=.57966a12-aa0c-40fb-815b-8bec9c7e8eda@github.com>
 <BtDcca4uUEPGQRwcPjA_ckSsCEX7u_chBB7Qe6P6Wp8=.40f38c07-d6db-41f2-bfa4-a7df321786f2@github.com>
Message-ID: <Yn7VHV-rM6EONnmX7_qgKkmEwm09y6MmjG-0ZQsPjOk=.6b04b32e-eb70-43fd-98ea-9c7d2704f5cc@github.com>

On Tue, 20 Oct 2020 23:06:41 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Fei Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:
>> 
>>  - Fix trailing whitespace issue reported by jcheck
>>  - Merge master
>>  - Merge master
>>  - Remove unnecessary code changes in vm_version_aarch64.cpp
>>  - Merge master
>>  - Merge master
>>  - Merge master
>>  - Merge master
>>  - Add sha3 instructions to cpu/aarch64/aarch64-asmtest.py and regenerate the test in assembler_aarch64.cpp:asm_check
>>  - Rebase
>>  - ... and 3 more: https://git.openjdk.java.net/jdk/compare/cdc8c401...d32c8ad7
>
> src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/CheckGraalIntrinsics.java line 604:
> 
>> 602:             add(ignore, "sun/security/provider/SHA5." + shaCompressName + "([BI)V");
>> 603:         }
>> 604:         add(toBeInvestigated, "sun/security/provider/SHA3." + shaCompressName + "([BI)V");
> 
> This should be under `if (isJDK16OrHigher())` check. Something like this:
> https://github.com/openjdk/jdk/pull/650/files#diff-d1f378fc1b7fe041309e854d40b3a95a91e63fdecf0ecd9826b7c95eaeba314eR527
> You can wait when Aleksey push it and update your changes

OK.  Will update with the following change after Aleksey's PR is integrated:

--- a/src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/CheckGraalIntrinsics.java
+++ b/src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/CheckGraalIntrinsics.java
@@ -608,6 +608,10 @@ public class CheckGraalIntrinsics extends GraalTest {
         if (!config.useSHA512Intrinsics()) {
             add(ignore, "sun/security/provider/SHA5." + shaCompressName + "([BI)V");
         }
+
+        if (isJDK16OrHigher()) {
+            add(toBeInvestigated, "sun/security/provider/SHA3." + shaCompressName + "([BI)V");
+        }
     }

-------------

PR: https://git.openjdk.java.net/jdk/pull/207

From sgehwolf at redhat.com  Wed Oct 21 09:17:03 2020
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Wed, 21 Oct 2020 11:17:03 +0200
Subject: [11u] RFR: 8250984: Memory Docker tests fail on some Linux
 kernels w/o cgroupv1 swap limit capabilities
In-Reply-To: <6ee2cb0b8081e95781d324876dc0370405cc8171.camel@redhat.com>
References: <6ee2cb0b8081e95781d324876dc0370405cc8171.camel@redhat.com>
Message-ID: <dd0fac039c329f7335271eb3ebd4b3848b459678.camel@redhat.com>

Gentle reminder. Anyone?

On Fri, 2020-10-09 at 18:18 +0200, Severin Gehwolf wrote:
> Hi,
> 
> Please review this backport for Oracle 11.0.10 parity. The jdk-jdk
> patch needs to be significantly reworked since JDK 15+ has the cgroups
> v2 patches. The gist of the change is to only report memory values if
> swap accounting is disabled on the system (i.e. no swap memory) for
> metrics which would otherwise report values for memory + swap.
> 
> Here is the list of changes I've done as compared to the JDK 16 patch:
> 
>  * Drop ProblemList.txt hunks. The test was not problem-listed in
>    OpenJDK 11u. It's not applicable.
>  * Dropped hunk in test/hotspot/jtreg/containers/cgroup/PlainRead.java,
>    which also is not applicable (cgroups v2 and later refactorings
>    related).
>  * Moved changes from CgroupV1Subsystem.java to cgroupv1/Metrics.java
>    class. That's where the code lived prior the cgroups v2 addition.
>  * Moved code changes from CgroupV1MemorySubSystemController.java to
>    MemorySubsystem in SubSystem.java
>  * test/hotspot/jtreg/containers/docker/TestMemoryAwareness.java
>    adjusted since JDK-8226575 for JDK 11 was different to JDK 15 (no
>    new methods)
>  * MetricsMemoryTester.java the code is again different in JDK 15+
>    because of JDK-8231111. But the changes for this bug only move it
>    into a conditional testing whether swap is enabled and only test if
>    it is.
>  * MetricsTesterCgroupV1 => MetricsTester
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8250984
> webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8250984/01/webrev/
> 
> Testing: Container tests on a system with swapaccount=0 and on a system
> with it enabled on Linux x86_64. Tests mentioned in the bug failed
> before, pass after.
> 
> Thoughts?
> 
> Thanks,
> Severin


From jlahoda at openjdk.java.net  Tue Oct 20 12:03:39 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Tue, 20 Oct 2020 12:03:39 GMT
Subject: RFR: 8250625: Compiler implementation of Pattern Matching for
 instanceof (Final) [v2]
In-Reply-To: <0uEby0-y3KVBLA1VxxdD5hCMlLhPCKB3w0mpihs9dsY=.181f22cd-7cf7-4941-b2d1-2ba4228d11d5@github.com>
References: <0uEby0-y3KVBLA1VxxdD5hCMlLhPCKB3w0mpihs9dsY=.181f22cd-7cf7-4941-b2d1-2ba4228d11d5@github.com>
Message-ID: <rYOjux1Z6MNttDR7kuCqksinlB_n8gWAX_2ttvSrBRo=.68b4e032-f689-4ff1-b7a8-49937f7a85ad@github.com>

> This is the current proposed patch for the upcoming JEP 394, for pattern matching for instanceof.
> 
> A summary of changes:
> -making the feature permanent (non-preview)
> -making the binding variables non-final (as per current specification proposal)
> -producing a compile-time error for the case where the expression's type is a subtype of the type test pattern's type
>  (as per current specification proposal)
> -changing the AST structure so that the binding variable has a VariableTree in the AST. BindingPatternTree is preserved
>  and encloses the VariableTree. The reason is better consistency in the API, with nodes like CatchTree, EnhancedForLoop
>  Tree, etc.
> 
> This change will not be integrated until JEP 394 is targetted.

Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev
excludes the unrelated changes brought in by the merge/rebase. The pull request contains 15 additional commits since
the last revision:

 - Cleanup: using a null instead of List.of() as a parameter to JavaCompiler.getTask
 - Merge branch 'master' into patterns-instanceof3
 - Fixing more tests.
 - Correcting positions.
 - Improve the AST model.
 - Merge branch 'master' into patterns-instanceof3
 - Updating @since tags.
 - Merge branch 'master' into patterns-instanceof3
 - Cleaning up preview comments in javadoc.
 - Merge branch 'master' into patterns-instanceof3
 - ... and 5 more: https://git.openjdk.java.net/jdk/compare/737668da...5978bca0

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/559/files
  - new: https://git.openjdk.java.net/jdk/pull/559/files/69c7dce8..5978bca0

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=559&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=559&range=00-01

  Stats: 331339 lines in 1108 files changed: 314513 ins; 10715 del; 6111 mod
  Patch: https://git.openjdk.java.net/jdk/pull/559.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/559/head:pull/559

PR: https://git.openjdk.java.net/jdk/pull/559

From fyang at openjdk.java.net  Wed Oct 21 09:23:57 2020
From: fyang at openjdk.java.net (Fei Yang)
Date: Wed, 21 Oct 2020 09:23:57 GMT
Subject: RFR: 8252204: AArch64: Implement SHA3 accelerator/intrinsic [v10]
In-Reply-To: <BtDcca4uUEPGQRwcPjA_ckSsCEX7u_chBB7Qe6P6Wp8=.40f38c07-d6db-41f2-bfa4-a7df321786f2@github.com>
References: <PJVtIubjiGKhCK81PIMhWuYxnR84DNieMDUGHdhHYZM=.ad903c93-c5e3-4614-9af1-d36bc33f735d@github.com>
 <kIpiKx8ovndJoa7alAki42vJ4H2lBJ4wN7MFqH5MORg=.57966a12-aa0c-40fb-815b-8bec9c7e8eda@github.com>
 <BtDcca4uUEPGQRwcPjA_ckSsCEX7u_chBB7Qe6P6Wp8=.40f38c07-d6db-41f2-bfa4-a7df321786f2@github.com>
Message-ID: <Z8q57lCaAf6SukMKsmGpsr6TRJgGa4123VsAvrchYKA=.72dfc784-0637-4dbc-97e6-07efad147ebe@github.com>

On Tue, 20 Oct 2020 23:08:22 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Someone in Oracle have to run tier1-tier3 testing with these changes to make sure nothing is broken. I don't want to repeat 8254790.

That's appreciated.
On my side, I run tier1-tier3 both on aarch64 linux and x86_64 linux.
The test result on these two platforms looks good for the latest changes.

-------------

PR: https://git.openjdk.java.net/jdk/pull/207

From jlahoda at openjdk.java.net  Wed Oct 21 10:08:02 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Wed, 21 Oct 2020 10:08:02 GMT
Subject: RFR: 8250625: Compiler implementation of Pattern Matching for
 instanceof (Final) [v2]
In-Reply-To: <QyZ9OmnQT_SZnBaurbZgYx2WTs3P07dky7Ec748Py_4=.8da887c0-295c-4c64-9b2f-84e75495a02f@github.com>
References: <0uEby0-y3KVBLA1VxxdD5hCMlLhPCKB3w0mpihs9dsY=.181f22cd-7cf7-4941-b2d1-2ba4228d11d5@github.com>
 <sQv_ZdanJ0-lLBox6CKwXxIXFrWSVNyWcN3sQZ5U1Bw=.1c5793db-f4e2-4ffd-9ed9-e93703e6107e@github.com>
 <rCOM4p8lSaD9EheSPUJkvQovRVNaLfzWoYUlVeTbhew=.154bf6a2-57ed-4c8f-813c-d3784704b740@github.com>
 <QyZ9OmnQT_SZnBaurbZgYx2WTs3P07dky7Ec748Py_4=.8da887c0-295c-4c64-9b2f-84e75495a02f@github.com>
Message-ID: <_r6Ofs2YDbTpIn3oUavjOrwrItrumb8tQWczoOP8nSs=.47d03adc-fffa-4931-b513-cfea0258e998@github.com>

On Wed, 21 Oct 2020 03:26:57 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> I believe plain jtreg invocations may not be always setting "-g". So probably better to be explicitly clear we need -g, as the test itself requires the debugging info/LocalVariableTable?
>
> sure I understand that the `-g` option is necessary. I was just wondering if `-g` is not passed always by jtreg. If the option is passed by default then it is superfluous, although just a comment, I understand that it is safer to pass it

I tried with a plain jtreg invocation, and it didn't pass -g (and the test failed). But it depends on how jtreg is run, of course - some runs may have -g set.

-------------

PR: https://git.openjdk.java.net/jdk/pull/559

From jlahoda at openjdk.java.net  Wed Oct 21 10:08:01 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Wed, 21 Oct 2020 10:08:01 GMT
Subject: RFR: 8250625: Compiler implementation of Pattern Matching for
 instanceof (Final) [v2]
In-Reply-To: <9ylwnQ8cWjQeQ9hbRDScySUuctce51DiXlm9sDOrTEo=.fef60e85-cef5-46a6-9183-a1dadc2a1062@github.com>
References: <0uEby0-y3KVBLA1VxxdD5hCMlLhPCKB3w0mpihs9dsY=.181f22cd-7cf7-4941-b2d1-2ba4228d11d5@github.com>
 <rYOjux1Z6MNttDR7kuCqksinlB_n8gWAX_2ttvSrBRo=.68b4e032-f689-4ff1-b7a8-49937f7a85ad@github.com>
 <9ylwnQ8cWjQeQ9hbRDScySUuctce51DiXlm9sDOrTEo=.fef60e85-cef5-46a6-9183-a1dadc2a1062@github.com>
Message-ID: <BtihW5NpVbSTkrrC03rjvgGWLj3wiL7VARJvapwvHgM=.5f6dc1d5-2ace-4eea-8b98-50d21f119240@github.com>

On Wed, 21 Oct 2020 03:11:28 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 15 additional commits since the last revision:
>> 
>>  - Cleanup: using a null instead of List.of() as a parameter to JavaCompiler.getTask
>>  - Merge branch 'master' into patterns-instanceof3
>>  - Fixing more tests.
>>  - Correcting positions.
>>  - Improve the AST model.
>>  - Merge branch 'master' into patterns-instanceof3
>>  - Updating @since tags.
>>  - Merge branch 'master' into patterns-instanceof3
>>  - Cleaning up preview comments in javadoc.
>>  - Merge branch 'master' into patterns-instanceof3
>>  - ... and 5 more: https://git.openjdk.java.net/jdk/compare/0290d7bd...5978bca0
>
> src/jdk.compiler/share/classes/com/sun/source/tree/PatternTree.java line 34:
> 
>> 32:  * @since 16
>> 33:  */
>> 34: public interface PatternTree extends Tree {}
> 
> I think that this interface is there for forward compatibility, and I don't like empty interfaces but I found that we already did that with com.sun.source.tree.DirectiveTree

We have multiple such interfaces - like StatementTree and ExpressionTree. It is a forward-looking interface, but I think necessary: InstanceofTree.getPattern() needs to return something, and having a PatternTree is (I think) better than returning generic Tree, or BindingPatternTree (the latter is likely to be insufficient sometime soon).

-------------

PR: https://git.openjdk.java.net/jdk/pull/559

From shade at redhat.com  Wed Oct 21 10:43:43 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 21 Oct 2020 12:43:43 +0200
Subject: [11u] RFR: 8250984: Memory Docker tests fail on some Linux
 kernels w/o cgroupv1 swap limit capabilities
In-Reply-To: <dd0fac039c329f7335271eb3ebd4b3848b459678.camel@redhat.com>
References: <6ee2cb0b8081e95781d324876dc0370405cc8171.camel@redhat.com>
 <dd0fac039c329f7335271eb3ebd4b3848b459678.camel@redhat.com>
Message-ID: <a96d4ec9-c286-6078-f05f-563f92af6307@redhat.com>

On 10/21/20 11:17 AM, Severin Gehwolf wrote:
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8250984
>> webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8250984/01/webrev/

Looks fine to me.

-- 
Thanks,
-Aleksey


From mcimadamore at openjdk.java.net  Wed Oct 21 10:44:38 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 21 Oct 2020 10:44:38 GMT
Subject: RFR: 8254231: Implementation of Foreign Linker API (Incubator)
 [v8]
In-Reply-To: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
References: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
Message-ID: <663pAFJdnevrreAcN1Zg9_pkE1kt9Vxxy9unNgQMvDk=.42b1e1ad-192a-418d-9271-c1830dd9fa82@github.com>

> This patch contains the changes associated with the first incubation round of the foreign linker access API incubation
> (see JEP 389 [1]). This work is meant to sit on top of the foreign memory access support (see JEP 393 [2] and associated pull request [3]).
> 
> The main goal of this API is to provide a way to call native functions from Java code without the need of intermediate JNI glue code. In order to do this, native calls are modeled through the MethodHandle API. I suggest reading the writeup [4] I put together few weeks ago, which illustrates what the foreign linker support is, and how it should be used by clients.
> 
> Disclaimer: the pull request mechanism isn't great at managing *dependent* reviews. For this reasons, I'm attaching a webrev which contains only the differences between this PR and the memory access PR. I will be periodically uploading new webrevs, as new iterations come out, to try and make the life of reviewers as simple as possible.
> 
> A big thank to Jorn Vernee and Vladimir Ivanov - they are the main architects of all the hotspot changes you see here, and without their help, the foreign linker support wouldn't be what it is today. As usual, a big thank to Paul Sandoz, who provided many insights (often by trying the bits first hand).
> 
> Thanks
> Maurizio
> 
> Webrev:
> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/webrev
> 
> Javadoc:
> 
> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/javadoc/jdk/incubator/foreign/package-summary.html
> 
> Specdiff (relative to [3]):
> 
> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/specdiff_delta/overview-summary.html
> 
> CSR:
> 
> https://bugs.openjdk.java.net/browse/JDK-8254232
> 
> 
> 
> ### API Changes
> 
> The API changes are actually rather slim:
> 
> * `LibraryLookup`
>   * This class allows clients to lookup symbols in native libraries; the interface is fairly simple; you can load a library by name, or absolute path, and then lookup symbols on that library.
> * `FunctionDescriptor`
>   * This is an abstraction that is very similar, in spirit, to `MethodType`; it is, at its core, an aggregate of memory layouts for the function arguments/return type. A function descriptor is used to describe the signature of a native function.
> * `CLinker`
>   * This is the real star of the show. A `CLinker` has two main methods: `downcallHandle` and `upcallStub`; the first takes a native symbol (as obtained from `LibraryLookup`), a `MethodType` and a `FunctionDescriptor` and returns a `MethodHandle` instance which can be used to call the target native symbol. The second takes an existing method handle, and a `FunctionDescriptor` and returns a new `MemorySegment` corresponding to a code stub allocated by the VM which acts as a trampoline from native code to the user-provided method handle. This is very useful for implementing upcalls.
>    * This class also contains the various layout constants that should be used by clients when describing native signatures (e.g. `C_LONG` and friends); these layouts contain additional ABI classfication information (in the form of layout attributes) which is used by the runtime to *infer* how Java arguments should be shuffled for the native call to take place.
>   * Finally, this class provides some helper functions e.g. so that clients can convert Java strings into C strings and back.
> * `NativeScope`
>   * This is an helper class which allows clients to group together logically related allocations; that is, rather than allocating separate memory segments using separate *try-with-resource* constructs, a `NativeScope` allows clients to use a _single_ block, and allocate all the required segments there. This is not only an usability boost, but also a performance boost, since not all allocation requests will be turned into `malloc` calls.
> * `MemorySegment`
>   * Only one method added here - namely `handoff(NativeScope)` which allows a segment to be transferred onto an existing native scope.
> 
> ### Safety
> 
> The foreign linker API is intrinsically unsafe; many things can go wrong when requesting a native method handle. For instance, the description of the native signature might be wrong (e.g. have too many arguments) - and the runtime has, in the general case, no way to detect such mismatches. For these reasons, obtaining a `CLinker` instance is a *restricted* operation, which can be enabled by specifying the usual JDK property `-Dforeign.restricted=permit` (as it's the case for other restricted method in the foreign memory API).
> 
> ### Implementation changes
> 
> The Java changes associated with `LibraryLookup` are relative straightforward; the only interesting thing to note here is that library loading does _not_ depend on class loaders, so `LibraryLookup` is not subject to the same restrictions which apply to JNI library loading (e.g. same library cannot be loaded by different classloaders).
> 
> As for `NativeScope` the changes are again relatively straightforward; it is an API which sits neatly on top of the foreign meory access API, providing some kind of allocation service which shares the same underlying memory segment(s), and turns an allocation request into a segment slice, which is a much less expensive operation. `NativeScope` comes in two variants: there are native scopes for which the allocation size is known a priori, and native scopes which can grow - these two schemes are implemented by two separate subclasses of `AbstractNativeScopeImpl`.
> 
> Of course the bulk of the changes are to support the `CLinker` downcall/upcall routines. These changes cut pretty deep into the JVM; I'll briefly summarize the goal of some of this changes - for further details, Jorn has put together a detailed writeup which explains the rationale behind the VM support, with some references to the code [5].
> 
> The main idea behind foreign linker is to infer, given a Java method type (expressed as a `MethodType` instance) and the description of the signature of a native function (expressed as a `FunctionDescriptor` instance) a _recipe_ that can be used to turn a Java call into the corresponding native call targeting the requested native function.
> 
> This inference scheme can be defined in a pretty straightforward fashion by looking at the various ABI specifications (for instance, see [6] for the SysV ABI, which is the one used on Linux/Mac). The various `CallArranger` classes, of which we have a flavor for each supported platform, do exactly that kind of inference.
> 
> For the inference process to work, we need to attach extra information to memory layouts; it is no longer sufficient to know e.g. that a layout is 32/64 bits - we need to know whether it is meant to represent a floating point value, or an integral value; this knowledge is required because floating points are passed in different registers by most ABIs. For this reason, `CLinker` offers a set of pre-baked, platform-dependent layout constants which contain the required classification attributes (e.g. a `Clinker.TypeKind` enum value). The runtime extracts this attribute, and performs classification accordingly.
> 
> A native call is decomposed into a sequence of basic, primitive operations, called `Binding` (see the great javadoc on the `Binding.java` class for more info). There are many such bindings - for instance the `Move` binding is used to move a value into a specific machine register/stack slot. So, the main job of the various `CallingArranger` classes is to determine, given a Java `MethodType` and `FunctionDescriptor` what is the set of bindings associated with the downcall/upcall.
> 
> At the heart of the foreign linker support is the `ProgrammableInvoker` class. This class effectively generates a `MethodHandle` which follows the steps described by the various bindings obtained by `CallArranger`. There are actually various strategies to interpret these bindings - listed below:
> 
> * basic intepreted mode; in this mode, all bindings are interpreted using a stack-based machine written in Java (see `BindingInterpreter`), except for the `Move` bindings. For these bindings, the move is implemented by allocating a *buffer* (whose size is ABI specific) and by moving all the lowered values into positions within this buffer. The buffer is then passed to a piece of assembly code inside the VM which takes values from the buffer and moves them in their expected registers/stack slots (note that each position in the buffer corresponds to a different register). This is the most general invocation mode, the more "customizable" one, but also the slowest - since for every call there is some extra allocation which takes place.
> 
> * specialized interpreted mode; same as before, but instead of interpreting the bindings with a stack-based interpreter, we generate a method handle chain which effectively interprets all the bindings (again, except `Move` ones).
> 
> * intrinsified mode; this is typically used in combination with the specialized interpreted mode described above (although it can also be used with the Java-based binding interpreter). The goal here is to remove the buffer allocation and copy by introducing an additional JVM intrinsic. If a native call recipe is constant (e.g. the set of bindings is constant, which is probably the case if the native method handle is stored in a `static`, `final` field), then the VM can generate specialized assembly code which interprets the `Move` binding without the need to go for an intermediate buffer. This gives us back performances that are on par with JNI.
> 
> For upcalls, the support is not (yet) as advanced, and only the basic interpreted mode is available there. We plan to add support for intrinsified modes there as well, which should considerably boost perfomances (probably well beyond what JNI can offer at the moment, since the upcall support in JNI is not very well optimized).
> 
> Again, for more readings on the internals of the foreign linker support, please refer to [5].
> 
> #### Test changes
> 
> Many new tests have been added to validate the foreign linker support; we have high level tests (see `StdLibTest`) which aim at testing the linker from the perspective of code that clients could write. But we also have deeper combinatorial tests (see `TestUpcall` and `TestDowncall`) which are meant to stress every corner of the ABI implementation. There are also some great tests (see the `callarranger` folder) which test the various `CallArranger`s for all the possible platforms; these tests adopt more of a white-box approach - that is, instead of treating the linker machinery as a black box and verify that the support works by checking that the native call returned the results we expected, these tests aims at checking that the set of bindings generated by the call arranger is correct. This also mean that we can test the classification logic for Windows, Mac and Linux regardless of the platform we're executing on.
> 
> Some additional microbenchmarks have been added to compare the performances of downcall/upcall with JNI.
> 
> [1] - https://openjdk.java.net/jeps/389
> [2] - https://openjdk.java.net/jeps/393
> [3] - https://git.openjdk.java.net/jdk/pull/548
> [4] - https://github.com/openjdk/panama-foreign/blob/foreign-jextract/doc/panama_ffi.md
> [5] - http://cr.openjdk.java.net/~jvernee/docs/Foreign-abi%20downcall%20intrinsics%20technical%20description.html

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Don't use JNI when generating native wrappers

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/634/files
  - new: https://git.openjdk.java.net/jdk/pull/634/files/502bd980..7cef16f4

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=634&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=634&range=06-07

  Stats: 478 lines in 17 files changed: 245 ins; 140 del; 93 mod
  Patch: https://git.openjdk.java.net/jdk/pull/634.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/634/head:pull/634

PR: https://git.openjdk.java.net/jdk/pull/634

From mcimadamore at openjdk.java.net  Wed Oct 21 11:33:27 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 21 Oct 2020 11:33:27 GMT
Subject: RFR: 8254231: Implementation of Foreign Linker API (Incubator)
 [v9]
In-Reply-To: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
References: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
Message-ID: <XvFIGunZ1EjNeZNgkF_I06FjuDxHmD8jjCJ2HkpF_xE=.15ac4c1b-063a-4181-ad6b-3fd64e95b0ed@github.com>

> This patch contains the changes associated with the first incubation round of the foreign linker access API incubation
> (see JEP 389 [1]). This work is meant to sit on top of the foreign memory access support (see JEP 393 [2] and associated pull request [3]).
> 
> The main goal of this API is to provide a way to call native functions from Java code without the need of intermediate JNI glue code. In order to do this, native calls are modeled through the MethodHandle API. I suggest reading the writeup [4] I put together few weeks ago, which illustrates what the foreign linker support is, and how it should be used by clients.
> 
> Disclaimer: the pull request mechanism isn't great at managing *dependent* reviews. For this reasons, I'm attaching a webrev which contains only the differences between this PR and the memory access PR. I will be periodically uploading new webrevs, as new iterations come out, to try and make the life of reviewers as simple as possible.
> 
> A big thank to Jorn Vernee and Vladimir Ivanov - they are the main architects of all the hotspot changes you see here, and without their help, the foreign linker support wouldn't be what it is today. As usual, a big thank to Paul Sandoz, who provided many insights (often by trying the bits first hand).
> 
> Thanks
> Maurizio
> 
> Webrev:
> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/webrev
> 
> Javadoc:
> 
> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/javadoc/jdk/incubator/foreign/package-summary.html
> 
> Specdiff (relative to [3]):
> 
> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/specdiff_delta/overview-summary.html
> 
> CSR:
> 
> https://bugs.openjdk.java.net/browse/JDK-8254232
> 
> 
> 
> ### API Changes
> 
> The API changes are actually rather slim:
> 
> * `LibraryLookup`
>   * This class allows clients to lookup symbols in native libraries; the interface is fairly simple; you can load a library by name, or absolute path, and then lookup symbols on that library.
> * `FunctionDescriptor`
>   * This is an abstraction that is very similar, in spirit, to `MethodType`; it is, at its core, an aggregate of memory layouts for the function arguments/return type. A function descriptor is used to describe the signature of a native function.
> * `CLinker`
>   * This is the real star of the show. A `CLinker` has two main methods: `downcallHandle` and `upcallStub`; the first takes a native symbol (as obtained from `LibraryLookup`), a `MethodType` and a `FunctionDescriptor` and returns a `MethodHandle` instance which can be used to call the target native symbol. The second takes an existing method handle, and a `FunctionDescriptor` and returns a new `MemorySegment` corresponding to a code stub allocated by the VM which acts as a trampoline from native code to the user-provided method handle. This is very useful for implementing upcalls.
>    * This class also contains the various layout constants that should be used by clients when describing native signatures (e.g. `C_LONG` and friends); these layouts contain additional ABI classfication information (in the form of layout attributes) which is used by the runtime to *infer* how Java arguments should be shuffled for the native call to take place.
>   * Finally, this class provides some helper functions e.g. so that clients can convert Java strings into C strings and back.
> * `NativeScope`
>   * This is an helper class which allows clients to group together logically related allocations; that is, rather than allocating separate memory segments using separate *try-with-resource* constructs, a `NativeScope` allows clients to use a _single_ block, and allocate all the required segments there. This is not only an usability boost, but also a performance boost, since not all allocation requests will be turned into `malloc` calls.
> * `MemorySegment`
>   * Only one method added here - namely `handoff(NativeScope)` which allows a segment to be transferred onto an existing native scope.
> 
> ### Safety
> 
> The foreign linker API is intrinsically unsafe; many things can go wrong when requesting a native method handle. For instance, the description of the native signature might be wrong (e.g. have too many arguments) - and the runtime has, in the general case, no way to detect such mismatches. For these reasons, obtaining a `CLinker` instance is a *restricted* operation, which can be enabled by specifying the usual JDK property `-Dforeign.restricted=permit` (as it's the case for other restricted method in the foreign memory API).
> 
> ### Implementation changes
> 
> The Java changes associated with `LibraryLookup` are relative straightforward; the only interesting thing to note here is that library loading does _not_ depend on class loaders, so `LibraryLookup` is not subject to the same restrictions which apply to JNI library loading (e.g. same library cannot be loaded by different classloaders).
> 
> As for `NativeScope` the changes are again relatively straightforward; it is an API which sits neatly on top of the foreign meory access API, providing some kind of allocation service which shares the same underlying memory segment(s), and turns an allocation request into a segment slice, which is a much less expensive operation. `NativeScope` comes in two variants: there are native scopes for which the allocation size is known a priori, and native scopes which can grow - these two schemes are implemented by two separate subclasses of `AbstractNativeScopeImpl`.
> 
> Of course the bulk of the changes are to support the `CLinker` downcall/upcall routines. These changes cut pretty deep into the JVM; I'll briefly summarize the goal of some of this changes - for further details, Jorn has put together a detailed writeup which explains the rationale behind the VM support, with some references to the code [5].
> 
> The main idea behind foreign linker is to infer, given a Java method type (expressed as a `MethodType` instance) and the description of the signature of a native function (expressed as a `FunctionDescriptor` instance) a _recipe_ that can be used to turn a Java call into the corresponding native call targeting the requested native function.
> 
> This inference scheme can be defined in a pretty straightforward fashion by looking at the various ABI specifications (for instance, see [6] for the SysV ABI, which is the one used on Linux/Mac). The various `CallArranger` classes, of which we have a flavor for each supported platform, do exactly that kind of inference.
> 
> For the inference process to work, we need to attach extra information to memory layouts; it is no longer sufficient to know e.g. that a layout is 32/64 bits - we need to know whether it is meant to represent a floating point value, or an integral value; this knowledge is required because floating points are passed in different registers by most ABIs. For this reason, `CLinker` offers a set of pre-baked, platform-dependent layout constants which contain the required classification attributes (e.g. a `Clinker.TypeKind` enum value). The runtime extracts this attribute, and performs classification accordingly.
> 
> A native call is decomposed into a sequence of basic, primitive operations, called `Binding` (see the great javadoc on the `Binding.java` class for more info). There are many such bindings - for instance the `Move` binding is used to move a value into a specific machine register/stack slot. So, the main job of the various `CallingArranger` classes is to determine, given a Java `MethodType` and `FunctionDescriptor` what is the set of bindings associated with the downcall/upcall.
> 
> At the heart of the foreign linker support is the `ProgrammableInvoker` class. This class effectively generates a `MethodHandle` which follows the steps described by the various bindings obtained by `CallArranger`. There are actually various strategies to interpret these bindings - listed below:
> 
> * basic intepreted mode; in this mode, all bindings are interpreted using a stack-based machine written in Java (see `BindingInterpreter`), except for the `Move` bindings. For these bindings, the move is implemented by allocating a *buffer* (whose size is ABI specific) and by moving all the lowered values into positions within this buffer. The buffer is then passed to a piece of assembly code inside the VM which takes values from the buffer and moves them in their expected registers/stack slots (note that each position in the buffer corresponds to a different register). This is the most general invocation mode, the more "customizable" one, but also the slowest - since for every call there is some extra allocation which takes place.
> 
> * specialized interpreted mode; same as before, but instead of interpreting the bindings with a stack-based interpreter, we generate a method handle chain which effectively interprets all the bindings (again, except `Move` ones).
> 
> * intrinsified mode; this is typically used in combination with the specialized interpreted mode described above (although it can also be used with the Java-based binding interpreter). The goal here is to remove the buffer allocation and copy by introducing an additional JVM intrinsic. If a native call recipe is constant (e.g. the set of bindings is constant, which is probably the case if the native method handle is stored in a `static`, `final` field), then the VM can generate specialized assembly code which interprets the `Move` binding without the need to go for an intermediate buffer. This gives us back performances that are on par with JNI.
> 
> For upcalls, the support is not (yet) as advanced, and only the basic interpreted mode is available there. We plan to add support for intrinsified modes there as well, which should considerably boost perfomances (probably well beyond what JNI can offer at the moment, since the upcall support in JNI is not very well optimized).
> 
> Again, for more readings on the internals of the foreign linker support, please refer to [5].
> 
> #### Test changes
> 
> Many new tests have been added to validate the foreign linker support; we have high level tests (see `StdLibTest`) which aim at testing the linker from the perspective of code that clients could write. But we also have deeper combinatorial tests (see `TestUpcall` and `TestDowncall`) which are meant to stress every corner of the ABI implementation. There are also some great tests (see the `callarranger` folder) which test the various `CallArranger`s for all the possible platforms; these tests adopt more of a white-box approach - that is, instead of treating the linker machinery as a black box and verify that the support works by checking that the native call returned the results we expected, these tests aims at checking that the set of bindings generated by the call arranger is correct. This also mean that we can test the classification logic for Windows, Mac and Linux regardless of the platform we're executing on.
> 
> Some additional microbenchmarks have been added to compare the performances of downcall/upcall with JNI.
> 
> [1] - https://openjdk.java.net/jeps/389
> [2] - https://openjdk.java.net/jeps/393
> [3] - https://git.openjdk.java.net/jdk/pull/548
> [4] - https://github.com/openjdk/panama-foreign/blob/foreign-jextract/doc/panama_ffi.md
> [5] - http://cr.openjdk.java.net/~jvernee/docs/Foreign-abi%20downcall%20intrinsics%20technical%20description.html

Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 27 commits:

 - Merge branch 'master' into 8254231_linker
 - Don't use JNI when generating native wrappers
   
 - Merge branch 'master' into 8254231_linker
 - Fix incorrect capitalization in one copyright header
 - Update copyright years, and add classpath exception to files that were missing it
 - Use separate constants for native invoker code size
 - Re-add file erroneously deleted (detected as rename)
 - Re-add erroneously removed files
 - Merge branch 'master' into 8254231_linker
   
   - Fix tests
 - Fix more whitespaces
 - ... and 17 more: https://git.openjdk.java.net/jdk/compare/da97ab5c...8c7b75da

-------------

Changes: https://git.openjdk.java.net/jdk/pull/634/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=634&range=08
  Stats: 75713 lines in 267 files changed: 72828 ins; 1608 del; 1277 mod
  Patch: https://git.openjdk.java.net/jdk/pull/634.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/634/head:pull/634

PR: https://git.openjdk.java.net/jdk/pull/634

From jvernee at openjdk.java.net  Wed Oct 21 11:37:17 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Wed, 21 Oct 2020 11:37:17 GMT
Subject: RFR: 8254231: Implementation of Foreign Linker API (Incubator)
 [v4]
In-Reply-To: <1qSzjGTeTsGkvOvOIiXjY8JP944k3uLaq6KhkUP1vHE=.068f0409-ef1d-486a-8d74-c587619893e9@github.com>
References: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
 <0Zh0H5gSXzvHSstQ2w8NBM-P8yERRPouvhZJDNGvu4A=.6cde913f-7499-4c45-bc63-b717502b661e@github.com>
 <2moJ2056gzwWoleYccv21TpFYQHw5h9bA-IZCImplhs=.763198bf-06b0-4589-b01e-217ba84af94a@github.com>
 <1qSzjGTeTsGkvOvOIiXjY8JP944k3uLaq6KhkUP1vHE=.068f0409-ef1d-486a-8d74-c587619893e9@github.com>
Message-ID: <rTDlLyqRWxnG7TbgitKSIDM8qhMGj60LHaf1xvIfP0w=.3d4750fe-b718-46fc-b044-994aff38456a@github.com>

On Mon, 19 Oct 2020 11:24:45 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> I looked through some Hotspot runtime code and that looks ok.  I saw a couple of strange things on my way through the code.  See comments.
>
> Hi David, this code somewhat predates me, so I initially kept the JVM_ENTRY since that was what was already in place. IIRC the thread state transition was added later to be able to call JNI code, which checks that the thread state is native in some asserts.
> 
> I've re-written this code, per @coleenp 's suggestion, to use VM code directly to replace what we were doing with JNI, so the thread state transition is also gone.
> 
> I've looked at some of the *_ENTRY macros and the only one that seems to avoid the thread state transition is JVM_LEAF. I've switched the RegisterNatives functions we use to JVM_LEAF to avoid the redundant transitions. I also tried changing `PI_invokeNative` to JVM_LEAF, but since we can call back into Java from that, I run into a missing handle mark assert for some of the tests, so I've left that one as JVM_ENTRY (but removed some redundant braces).
> 
> I've created a separate sub-pr against this PR's branch to make it easier to see what I've changed: https://github.com/mcimadamore/jdk/pull/1 (feel free to take a look).
> 
> Thanks for the comments.

I've fixed the following issues from review comments:
- don't rely on `MethodHandles::adapter_code_size` (after private discussion)
- update copyright years
- use VM-internal API instead of JNI when parsing ABIDescriptor and BufferLayout objects while generating down/up call wrappers.

As far as I see, that covers all open review comments.

-------------

PR: https://git.openjdk.java.net/jdk/pull/634

From ihse at openjdk.java.net  Wed Oct 21 11:45:18 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Wed, 21 Oct 2020 11:45:18 GMT
Subject: RFR: 8188055: (ref) Add Reference::refersTo predicate [v6]
In-Reply-To: <0dhF_xxcp1VoUowwdZenB2qWa9ILcZjTMe3lsaRrg7k=.3c633db8-f745-4353-ad34-a64fbc96d4e0@github.com>
References: <D4HSg8FT20Eaxk5KJkkw0GgETSxRkBn1ipS3Dt0kPto=.e4bab078-2e04-4413-90cb-9bfafb2a6831@github.com>
 <0dhF_xxcp1VoUowwdZenB2qWa9ILcZjTMe3lsaRrg7k=.3c633db8-f745-4353-ad34-a64fbc96d4e0@github.com>
Message-ID: <vAOwHKeoaOkezU3tcludwEqT9Q6Xlufe0FPWKpKYMFE=.a5783084-32a2-4dda-af3d-1e612774371b@github.com>

On Wed, 21 Oct 2020 02:28:30 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Finally returning to this review that was started in April 2020.  I've
>> recast it as a github PR.  I think the security concern raised by Gil
>> has been adequately answered.
>> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-April/029203.html
>> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-July/030401.html
>> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-August/030677.html
>> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-September/030793.html
>> 
>> Please review a new function: java.lang.ref.Reference.refersTo.
>> 
>> This function is needed to test the referent of a Reference object without
>> artificially extending the lifetime of the referent object, as may happen
>> when calling Reference.get.  Some garbage collectors require extending the
>> lifetime of a weak referent when accessed, in order to maintain collector
>> invariants.  Lifetime extension may occur with any collector when the
>> Reference is a SoftReference, as calling get indicates recent access.  This
>> new function also allows testing the referent of a PhantomReference, which
>> can't be accessed by calling get.
>> 
>> The new function uses native methods whose implementations are in the VM so
>> they can use the Access API.  It is the intent that these methods will be
>> intrinsified by optimizing compilers like C2 or graal, but that hasn't been
>> implemented yet.  Bear that in mind before rushing off to change existing
>> uses of Reference.get.
>> 
>> There are two native methods involved, one in Reference and an override in
>> PhantomReference, both package private in java.lang.ref. The reason for this
>> split is to simplify the intrinsification. This is a change from the version
>> from April 2020; that version had a single native method in Reference,
>> implemented using the ON_UNKNOWN_OOP_REF Access reference strength category.
>> However, adding support for that category in the compilers adds significant
>> implementation effort and complexity. Splitting avoids that complexity.
>> 
>> Testing:
>> mach5 tier1
>> Locally (linux-x64) verified the new test passes with various garbage collectors.
>
> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
> 
>   improve wording in refersTo javadoc

Marked as reviewed by ihse (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/498

From ihse at openjdk.java.net  Wed Oct 21 11:45:19 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Wed, 21 Oct 2020 11:45:19 GMT
Subject: RFR: 8188055: (ref) Add Reference::refersTo predicate [v6]
In-Reply-To: <fRm7x6jF10Gyk0tZJC1PA-mstU8iapiIPmlE5l6-VeA=.7234fbb0-93ae-4e78-a7f0-4c0445a38c91@github.com>
References: <D4HSg8FT20Eaxk5KJkkw0GgETSxRkBn1ipS3Dt0kPto=.e4bab078-2e04-4413-90cb-9bfafb2a6831@github.com>
 <0dhF_xxcp1VoUowwdZenB2qWa9ILcZjTMe3lsaRrg7k=.3c633db8-f745-4353-ad34-a64fbc96d4e0@github.com>
 <fRm7x6jF10Gyk0tZJC1PA-mstU8iapiIPmlE5l6-VeA=.7234fbb0-93ae-4e78-a7f0-4c0445a38c91@github.com>
Message-ID: <etiaXi8M9dcgRdkgzXyeqkIL6ajDeoYCnQtpU-3XgEk=.6e71dce8-14c4-4fd1-8cc3-ff589654aef5@github.com>

On Wed, 21 Oct 2020 02:55:49 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   improve wording in refersTo javadoc
>
> Update looks good. Need to reflect the change in the CSR.
> 
> Thanks.
> David

Build changes look good.

-------------

PR: https://git.openjdk.java.net/jdk/pull/498

From jlahoda at openjdk.java.net  Wed Oct 21 12:29:38 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Wed, 21 Oct 2020 12:29:38 GMT
Subject: RFR: 8250625: Compiler implementation of Pattern Matching for
 instanceof (Final) [v3]
In-Reply-To: <0uEby0-y3KVBLA1VxxdD5hCMlLhPCKB3w0mpihs9dsY=.181f22cd-7cf7-4941-b2d1-2ba4228d11d5@github.com>
References: <0uEby0-y3KVBLA1VxxdD5hCMlLhPCKB3w0mpihs9dsY=.181f22cd-7cf7-4941-b2d1-2ba4228d11d5@github.com>
Message-ID: <Bg_8SYDj4zVlp7WDbiE3w_yhlfnE40O8YLHIVHj0Yi0=.9c068263-4f79-4b5a-88d4-c4895659db24@github.com>

> This is the current proposed patch for the upcoming JEP 394, for pattern matching for instanceof.
> 
> A summary of changes:
> -making the feature permanent (non-preview)
> -making the binding variables non-final (as per current specification proposal)
> -producing a compile-time error for the case where the expression's type is a subtype of the type test pattern's type (as per current specification proposal)
> -changing the AST structure so that the binding variable has a VariableTree in the AST. BindingPatternTree is preserved and encloses the VariableTree. The reason is better consistency in the API, with nodes like CatchTree, EnhancedForLoop Tree, etc.
> 
> This change will not be integrated until JEP 394 is targetted.

Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:

  Fixing review comments.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/559/files
  - new: https://git.openjdk.java.net/jdk/pull/559/files/5978bca0..5699194b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=559&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=559&range=01-02

  Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/559.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/559/head:pull/559

PR: https://git.openjdk.java.net/jdk/pull/559

From mdoerr at openjdk.java.net  Wed Oct 21 13:03:18 2020
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Wed, 21 Oct 2020 13:03:18 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v7]
In-Reply-To: <7Dgp_C-H8LsbF3tPHinVmb5bT_LoLZLYZUx9eSqigCA=.894148e4-a3f2-42c3-ab19-13e134e66853@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <7Dgp_C-H8LsbF3tPHinVmb5bT_LoLZLYZUx9eSqigCA=.894148e4-a3f2-42c3-ab19-13e134e66853@github.com>
Message-ID: <0ZTSXtU_wMV3g5TjwKPUfsRFzMDDnfmGfz6BoqlVbOM=.d51d1653-5249-4bdc-8ce4-76d54bb86c22@github.com>

On Wed, 21 Oct 2020 01:51:26 GMT, CoreyAshford <github.com+51754783+CoreyAshford at openjdk.org> wrote:

>> This patch set encompasses the following commits:
>> 
>> - Adds a new HotSpot intrinsic candidate to the java.lang.Base64 class - decodeBlock(), and provides a flexible API for the intrinsic.  The API is similar to the existing encodeBlock intrinsic.
>> - Adds the code in HotSpot to check and martial the new intrinsic's arguments to the arch-specific intrinsic implementation
>> - Adds a Power64LE-specific implementation of the decodeBlock intrinsic.
>> - Adds a JMH microbenchmark for both Base64 encoding and encoding.
>> - Enhances the JTReg hotspot intrinsic "TestBase64.java" regression test to more fully test both decoding and encoding.
>
> CoreyAshford has updated the pull request incrementally with one additional commit since the last revision:
> 
>   CheckGraalIntrinsics.java: fix copy/paste error

Marked as reviewed by mdoerr (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/293

From dcubed at openjdk.java.net  Wed Oct 21 13:46:22 2020
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 21 Oct 2020 13:46:22 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v7]
In-Reply-To: <0ZTSXtU_wMV3g5TjwKPUfsRFzMDDnfmGfz6BoqlVbOM=.d51d1653-5249-4bdc-8ce4-76d54bb86c22@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <7Dgp_C-H8LsbF3tPHinVmb5bT_LoLZLYZUx9eSqigCA=.894148e4-a3f2-42c3-ab19-13e134e66853@github.com>
 <0ZTSXtU_wMV3g5TjwKPUfsRFzMDDnfmGfz6BoqlVbOM=.d51d1653-5249-4bdc-8ce4-76d54bb86c22@github.com>
Message-ID: <wK-LfPnbs0nw2SuGwGFqrbSJxZZ6Fx5JtbGsmeRJi1w=.53d44e23-e9b3-4b12-8cdd-b5efa74a5702@github.com>

On Wed, 21 Oct 2020 13:00:09 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> CoreyAshford has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   CheckGraalIntrinsics.java: fix copy/paste error
>
> Marked as reviewed by mdoerr (Reviewer).

Buried in that GitHub test run link are the results for
windows-x64-debug_testlogs_hs_tier1_compiler
which includes this file (test-summary.txt):

==============================
Test summary
==============================
   TEST                                              TOTAL  PASS  FAIL ERROR   
>> jtreg:test/hotspot/jtreg:tier1_compiler             742   683    59     0 <<
==============================
TEST FAILURE
I poked around, but I don't see any logs for the individual
test failures.

-------------

PR: https://git.openjdk.java.net/jdk/pull/293

From hannesw at openjdk.java.net  Wed Oct 21 15:29:19 2020
From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Wed, 21 Oct 2020 15:29:19 GMT
Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12
 [v2]
In-Reply-To: <LIb9tG4MMzEQmWmOh26MHVMLJWnyWR6NTsBIgWsi0DA=.ee56fde6-defe-4df8-88a9-81b5882f3db0@github.com>
References: <RRMAPzh6xcVcxOj2S_VW_r50YvZz-3Imaj46bDi8e9U=.9347534e-d482-468a-8668-132d5516bb76@github.com>
 <LIb9tG4MMzEQmWmOh26MHVMLJWnyWR6NTsBIgWsi0DA=.ee56fde6-defe-4df8-88a9-81b5882f3db0@github.com>
Message-ID: <xrcJMq4CEuPF6xHY7m8CTSqbl1b4mPrhhbNra76i5II=.7b266828-c487-4f6f-9d25-9753284e8932@github.com>

On Tue, 20 Oct 2020 12:15:23 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is an update to javac and javadoc, to introduce support for Preview APIs, and generally improve javac and javadoc behavior to more closely adhere to JEP 12.
>> 
>> The notable changes are:
>> 
>>  * adding support for Preview APIs (javac until now supported primarily only preview language features, and APIs associated with preview language features). This includes:
>>      * the @PreviewFeature annotation has boolean attribute "reflective", which should be true for reflective Preview APIs, false otherwise. This replaces the existing "essentialAPI" attribute with roughly inverted meaning.
>>      * the preview warnings for preview APIs are auto-suppressed as described in the JEP 12. E.g. the module that declares the preview API is free to use it without warnings
>>  * improving error/warning messages. Please see [1] for a list of cases/examples.
>>  * class files are only marked as preview if they are using a preview feature. [1] also shows if a class file is marked as preview or not.
>>  * the PreviewFeature annotation has been moved to jdk.internal.javac package (originally was in the jdk.internal package).
>>  * Preview API in JDK's javadoc no longer needs to specify @preview tag in the source files. javadoc will auto-generate a note for @PreviewFeature elements, see e.g. [2] and [3] (non-reflective and reflective API, respectively). A summary of preview elements is also provided [4]. Existing uses of @preview have been updated/removed.
>>  * non-JDK javadoc is also enhanced to auto-generate preview notes for uses of Preview elements, and for declaring elements using preview language features [5].
>>  
>>  Please also see the CSR [6] for more information.
>>  
>>  [1] http://cr.openjdk.java.net/~jlahoda/8250768/JEP12-errors-warnings-v6.html
>>  [2] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.base/java/lang/Record.html
>>  [3] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.compiler/javax/lang/model/element/RecordComponentElement.html
>>  [4] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/preview-list.html
>>  [5] http://cr.openjdk.java.net/~jlahoda/8250768/test.javadoc.00/
>>  [6] https://bugs.openjdk.java.net/browse/JDK-8250769
>
> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 35 commits:
> 
>  - Merge branch 'JDK-8250768-dev' of https://github.com/lahodaj/jdk into JDK-8250768
>  - More fixing tests.
>  - Fixing tests.
>  - Using unique sections for preview warning sections, as suggested.
>  - Merge branch 'master' into JDK-8250768
>  - Reflecting review comments.
>  - Fixing tests.
>  - Various cleanup.
>  - The Preview taglet is not needed anymore.
>  - There is not jdk.internal package anymore
>  - ... and 25 more: https://git.openjdk.java.net/jdk/compare/98ec4a67...be1d8651

The javadoc code changes look reasonable, and the preview bits in the generated documentation look good as well. 

Apart from my inline comments which all address minor issues, there are a few things I don't like around `PreviewListWriter`: its code replication with `DeprecatedListWriter, and it adds things to HtmlDocletWriter and HtmlStyle that I don't think are strictly necessary. However, I wouldn't expect you to know how we like things done in javadoc, so maybe the simplest solution would be for one of us to go over the javadoc bits, either as part of this pull request or (if you prefer to get it integrated rather sooner) as a follow-up task.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java line 3164:

> 3162:     }
> 3163: 
> 3164:     public Set<ElementFlag> elementFlags(Element el) {

It seems like the sole use of this method and the `ElementFlag` enum below is to determine whether a preview warning note should be generated for an element. Is there something that speaks against simplifying it to reflect that purpose, e.g. change its name to `hasPreviewNote` or `hasPreviewContent` and change the return type to `boolean`?  Of course that's unless you foresee adding more `ElementFlag` values in the future.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java line 125:

> 123: import static javax.lang.model.element.ElementKind.METHOD;
> 124: import static javax.lang.model.element.ElementKind.PACKAGE;
> 125: import jdk.javadoc.internal.doclets.formats.html.markup.RawHtml;

These imports as well as HtmlAttr above aren't used.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/LinkInfoImpl.java line 247:

> 245:      * The member this link points to (if any).
> 246:      */
> 247:     public Element whereMember;

I don't think `whereMember` is a great name (and `where` above is not a great name either). What about naming this `targetMember` or `targetElement`?

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlAttr.java line 47:

> 45:     CLEAR,
> 46:     COLS,
> 47:     COLSPAN,

I don't think this is used anywhere.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/links/LinkFactory.java line 209:

> 207:         linkInfo.label = null;
> 208:         linkInfo.type = bound;
> 209:         ((LinkInfoImpl) linkInfo).skipPreview = false;

I guess it would be nicer to move the `skipPreview` field to `LinkInfo` to avoid that cast.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java line 1314:

> 1312:             div = HtmlTree.DIV(HtmlStyle.block, result);
> 1313:             htmltree.add(div);
> 1314:         } else {

I notice that preview code above produces the same HTML output as non-preview code below in the `else` branch. Do we really need the `preview` parameter?

-------------

PR: https://git.openjdk.java.net/jdk/pull/703

From bpb at openjdk.java.net  Wed Oct 21 16:19:20 2020
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 21 Oct 2020 16:19:20 GMT
Subject: RFR: 8238669: Long.divideUnsigned is extremely slow for certain
 values (Needs to be Intrinsic) [v3]
In-Reply-To: <h_BJ873QH_bKkb-ZDGEy-ZmarUWTrU-aTlu-2prHyzM=.79a87fd0-11f4-4295-9799-3c0044d21a3a@github.com>
References: <qTrgS9EALforkeYHdp592LnIrSJbqVAuv9Flfg3fbaU=.81db05a0-5847-4bfe-94ae-f4fcb922f4bc@github.com>
 <h_BJ873QH_bKkb-ZDGEy-ZmarUWTrU-aTlu-2prHyzM=.79a87fd0-11f4-4295-9799-3c0044d21a3a@github.com>
Message-ID: <ZkFxiZEzKLccs-utke7lz-6rRt_fbsX5286ZlXW1WC0=.8a438450-0530-4490-b4c1-64231a9232fd@github.com>

On Mon, 19 Oct 2020 14:58:22 GMT, Raffaello Giulietti <github.com+70726043+rgiulietti at openjdk.org> wrote:

>> This is a follow-up of the Mercurial-based workflow initiated on the core-lib-devs mailing list [0]. Not sure if this one is strictly necessary or if the patches sent on the list are sufficient. Anyway, I exploit this PR as a test ;-)
>> 
>> [0] https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-September/068474.html
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Modified copyright year.

Seeing no more comments in the last couple of days, I think this can be integrated.

-------------

Marked as reviewed by bpb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/31

From github.com+51754783+coreyashford at openjdk.java.net  Wed Oct 21 16:31:23 2020
From: github.com+51754783+coreyashford at openjdk.java.net (CoreyAshford)
Date: Wed, 21 Oct 2020 16:31:23 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v7]
In-Reply-To: <wK-LfPnbs0nw2SuGwGFqrbSJxZZ6Fx5JtbGsmeRJi1w=.53d44e23-e9b3-4b12-8cdd-b5efa74a5702@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <7Dgp_C-H8LsbF3tPHinVmb5bT_LoLZLYZUx9eSqigCA=.894148e4-a3f2-42c3-ab19-13e134e66853@github.com>
 <0ZTSXtU_wMV3g5TjwKPUfsRFzMDDnfmGfz6BoqlVbOM=.d51d1653-5249-4bdc-8ce4-76d54bb86c22@github.com>
 <wK-LfPnbs0nw2SuGwGFqrbSJxZZ6Fx5JtbGsmeRJi1w=.53d44e23-e9b3-4b12-8cdd-b5efa74a5702@github.com>
Message-ID: <Tu8mMwDyYP0euRIIqHWvXn1wwt5WDwBZeGvZLnsS_6I=.5021c712-b4f3-4297-a5d5-02299521806c@github.com>

On Wed, 21 Oct 2020 13:42:48 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> Buried in that GitHub test run link are the results for
> windows-x64-debug_testlogs_hs_tier1_compiler
> which includes this file (test-summary.txt):
> 
> ```
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR   
> >> jtreg:test/hotspot/jtreg:tier1_compiler             742   683    59     0 <<
> ==============================
> TEST FAILURE
> ```
> 
> I poked around, but I don't see any logs for the individual
> test failures.

In a browser at the provide test link, on the upper right in the "three-dot menu", there's an option to download the logs.  The only file containing failures is `6_Windows x64 (hstier1 compiler).txt`. There are quite a few exception backtraces in this log file, but they all look similar, saying:
TEST RESULT: Failed. Execution failed: `main' threw exception: java.lang.NullPointerException: Cannot invoke "java.lang.Throwable.getCause()" because "<local1>" is null
There's only one that's slightly different:
TEST RESULT: Failed. Execution failed: `main' threw exception: java.lang.Error: Can't get full path name for '.', got exception java.lang.NullPointerException: Cannot invoke "java.lang.Throwable.getCause()" because "<local1>" is null

-------------

PR: https://git.openjdk.java.net/jdk/pull/293

From LANCE.ANDERSEN at ORACLE.COM  Wed Oct 21 16:37:02 2020
From: LANCE.ANDERSEN at ORACLE.COM (Lance Andersen)
Date: Wed, 21 Oct 2020 12:37:02 -0400
Subject: "loc: wrong sig" in ZipFileSystem on a valid ZIP file (extra data
 field of exactly 5 bytes)
In-Reply-To: <CAM21Rt8KeWyQvjE7-5pfyXYJXO3yGgGfKpBtueOV8qgNFMa+jQ@mail.gmail.com>
References: <CAM21Rt8KeWyQvjE7-5pfyXYJXO3yGgGfKpBtueOV8qgNFMa+jQ@mail.gmail.com>
Message-ID: <17F644E3-E5E0-403E-B568-FCB89C8BD9BB@ORACLE.COM>

Hi David,

From  a quick look at ZipFileSystem this appears to be an optimization to avoid looking at the LOC extended Timestamp Extra field

If a Info-ZIP Extended Timestamp (0x5455)is found then:
  If the "zipinfo-time" entry was set  to ?false? in the Map specified when creating the Zip FileSystem,
FileSystems.newFileSystem(zipFile, Map.of("zipinfo-time", "false")
and the  data size of the CEN extended Timestamp is 5 (flag + mod time)
The modified time is used from the CEN Extended Timestamp extra field
Otherwise get the modified time, creation time, and access time from the LOC Extended Timestamp extra field.

?????
 Extended Timestamp Extra Field:
          ==============================

          The following is the layout of the extended-timestamp extra block.
          (Last Revision 19970118)

          Local-header version:

          Value         Size        Description
          -----         ----        -----------
  (time)  0x5455        Short       tag for this extra block type ("UT")
          TSize         Short       total data size for this block
          Flags         Byte        info bits
          (ModTime)     Long        time of last modification (UTC/GMT)
          (AcTime)      Long        time of last access (UTC/GMT)
          (CrTime)      Long        time of original creation (UTC/GMT)

          Central-header version:

          Value         Size        Description
          -----         ----        -----------
  (time)  0x5455        Short       tag for this extra block type ("UT")
          TSize         Short       total data size for this block
          Flags         Byte        info bits (refers to local header!)
          (ModTime)     Long        time of last modification (UTC/GMT)

          The central-header extra field contains the modification time only,
          or no timestamp at all.  TSize is used to flag its presence or
          absence.  But note:

              If "Flags" indicates that Modtime is present in the local header
              field, it MUST be present in the central header field, too!
              This correspondence is required because the modification time
              value may be used to support trans-timezone freshening and
              updating operations with zip archives.

          The time values are in standard Unix signed-long format, indicating
          the number of seconds since 1 January 1970 00:00:00.  The times
          are relative to Coordinated Universal Time (UTC), also sometimes
          referred to as Greenwich Mean Time (GMT).  To convert to local time,
          the software must know the local timezone offset from UTC/GMT.

          The lower three bits of Flags in both headers indicate which time-
          stamps are present in the LOCAL extra field:

                bit 0           if set, modification time is present
                bit 1           if set, access time is present
                bit 2           if set, creation time is present
                bits 3-7        reserved for additional timestamps; not set

          Those times that are present will appear in the order indicated, but
          any combination of times may be omitted.  (Creation time may be
          present without access time, for example.)  TSize should equal
          (1 + 4*(number of set bits in Flags)), as the block is currently
          defined.  Other timestamps may be added in the future.

--------------

It's hard to comment on why you received the error that you did but it is possible the tool that was used for writing the entry  did something unexpected.

Out of curiosity, have you tried using ZipFile/ZipEntry to access the entry?


Best,
Lance


> On Oct 21, 2020, at 4:55 AM, Dawid Weiss <dawid.weiss at gmail.com> wrote:
> 
> Hello,
> 
> We've encountered a seemingly valid ZIP file (zipinfo -v shows all its
> entries are intact) that causes a runtime exception when scanning its
> contents with ZipFileSystem. The exception indicates an invalid
> signature when parsing EXTID_EXTT. I don't quite understand this
> comment in the code:
> 
> case EXTID_EXTT:
>    // spec says the Extened timestamp in cen only has mtime
>    // need to read the loc to get the extra a/ctime, if flag
>    // "zipinfo-time" is not specified to false;
>    // there is performance cost (move up to loc and read) to
>    // access the loc table foreach entry;
>    if (zipfs.noExtt) {
>        if (sz == 5)
>            mtime = unixToJavaTime(LG(extra, pos + 1));
>         break;
>    }
> ...
> 
> but this ZIP file has the extra data block of exactly 5 bytes, as
> indicated by zipinfo:
> 
> Central directory entry #6:
> ---------------------------
> ...
>  file system or operating system of origin:      Unix
>  version of encoding software:                   3.0
>  minimum file system compatibility required:     MS-DOS, OS/2 or NT FAT
>  minimum software version required to extract:   2.0
>  compression method:                             deflated
> ...
>  extended local header:                          no
>  file last modified on (DOS date/time):          2018 Mar 1 04:56:20
>  file last modified on (UT extra field modtime): 2018 Mar 1 05:56:19 local
>  file last modified on (UT extra field modtime): 2018 Mar 1 04:56:19 UTC
> ...
>  Unix file attributes (100000 octal):            ----------
>  MS-DOS file attributes (01 hex):                read-only
> 
>  The central-directory extra field contains:
>  - A subfield with ID 0x5455 (universal time) and 5 data bytes.
>    The local extra field has UTC/GMT modification/access times.
> 
> The above conditional block checking for length == 5 would have worked
> in ZipFileSystem but it's surrounded by a condition over an
> externally-provided property - zipfs.noExtt is only set to true if:
> 
> this.noExtt = "false".equals(env.get("zipinfo-time"));
> 
> I can't share this particular ZIP file with you and I don't know how
> it was created but it seems like that "zipinfo-time" flag could be
> omitted if the length of the extra data field is exactly 5?
> 
> Dawid


Best
Lance
------------------




Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com





From github.com+70726043+rgiulietti at openjdk.java.net  Wed Oct 21 16:37:20 2020
From: github.com+70726043+rgiulietti at openjdk.java.net (Raffaello Giulietti)
Date: Wed, 21 Oct 2020 16:37:20 GMT
Subject: Integrated: 8238669: Long.divideUnsigned is extremely slow for
 certain values (Needs to be Intrinsic)
In-Reply-To: <qTrgS9EALforkeYHdp592LnIrSJbqVAuv9Flfg3fbaU=.81db05a0-5847-4bfe-94ae-f4fcb922f4bc@github.com>
References: <qTrgS9EALforkeYHdp592LnIrSJbqVAuv9Flfg3fbaU=.81db05a0-5847-4bfe-94ae-f4fcb922f4bc@github.com>
Message-ID: <ddZtwR4N95fz8XoFDNuUf1KEBW1kDSB8zc1zUaBG7bs=.adec04bd-1af3-4e44-b19c-be055568fd69@github.com>

On Sun, 6 Sep 2020 15:25:10 GMT, Raffaello Giulietti <github.com+70726043+rgiulietti at openjdk.org> wrote:

> This is a follow-up of the Mercurial-based workflow initiated on the core-lib-devs mailing list [0]. Not sure if this one is strictly necessary or if the patches sent on the list are sufficient. Anyway, I exploit this PR as a test ;-)
> 
> [0] https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-September/068474.html

This pull request has now been integrated.

Changeset: 0efdde18
Author:    Raffaello Giulietti <raffaello.giulietti at gmail.com>
Committer: Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/0efdde18
Stats:     91 lines in 2 files changed: 49 ins; 12 del; 30 mod

8238669: Long.divideUnsigned is extremely slow for certain values (Needs to be Intrinsic)

Reviewed-by: bpb

-------------

PR: https://git.openjdk.java.net/jdk/pull/31

From sgehwolf at redhat.com  Wed Oct 21 16:37:44 2020
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Wed, 21 Oct 2020 18:37:44 +0200
Subject: [11u] RFR: 8250984: Memory Docker tests fail on some Linux
 kernels w/o cgroupv1 swap limit capabilities
In-Reply-To: <a96d4ec9-c286-6078-f05f-563f92af6307@redhat.com>
References: <6ee2cb0b8081e95781d324876dc0370405cc8171.camel@redhat.com>
 <dd0fac039c329f7335271eb3ebd4b3848b459678.camel@redhat.com>
 <a96d4ec9-c286-6078-f05f-563f92af6307@redhat.com>
Message-ID: <4cf9c533637dd7c0ca30a67e2f785391371a72fe.camel@redhat.com>

On Wed, 2020-10-21 at 12:43 +0200, Aleksey Shipilev wrote:
> On 10/21/20 11:17 AM, Severin Gehwolf wrote:
> > > Bug: https://bugs.openjdk.java.net/browse/JDK-8250984
> > > webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8250984/01/webrev/
> 
> Looks fine to me.

Thanks for the review!

Cheers,
Severin


From asemenyuk at openjdk.java.net  Wed Oct 21 17:10:17 2020
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Wed, 21 Oct 2020 17:10:17 GMT
Subject: RFR: 8232024: Don't pollute log output with multiple errors of the
 same type
Message-ID: <fSuDEsw79XKdiuGVdVUS8LOVX0tPdqLAjyKstTOi1xE=.471b5e5a-98b7-4bfc-a284-5adc0dc702a3@github.com>

Don't run ldd and build list of dependency packages in case jpackage builds DEB package on non Debian Linux and RPM on Debian Linux. In this cases attempts to detect what packages provide libs will fail anyways, so don't waste time and pollute jpackage log output.

-------------

Commit messages:
 - 8232024: Don't pollute log output with multiple errors of the same type

Changes: https://git.openjdk.java.net/jdk/pull/784/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=784&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8232024
  Stats: 32 lines in 4 files changed: 17 ins; 8 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/784.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/784/head:pull/784

PR: https://git.openjdk.java.net/jdk/pull/784

From kvn at openjdk.java.net  Wed Oct 21 17:19:21 2020
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 21 Oct 2020 17:19:21 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v7]
In-Reply-To: <Tu8mMwDyYP0euRIIqHWvXn1wwt5WDwBZeGvZLnsS_6I=.5021c712-b4f3-4297-a5d5-02299521806c@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <7Dgp_C-H8LsbF3tPHinVmb5bT_LoLZLYZUx9eSqigCA=.894148e4-a3f2-42c3-ab19-13e134e66853@github.com>
 <0ZTSXtU_wMV3g5TjwKPUfsRFzMDDnfmGfz6BoqlVbOM=.d51d1653-5249-4bdc-8ce4-76d54bb86c22@github.com>
 <wK-LfPnbs0nw2SuGwGFqrbSJxZZ6Fx5JtbGsmeRJi1w=.53d44e23-e9b3-4b12-8cdd-b5efa74a5702@github.com>
 <Tu8mMwDyYP0euRIIqHWvXn1wwt5WDwBZeGvZLnsS_6I=.5021c712-b4f3-4297-a5d5-02299521806c@github.com>
Message-ID: <RfY_QPvzegQ-Z1PMlCFrGhzn7CrVM7KpADT1o721eT4=.92d8f07c-6f9c-44c7-8b14-f66fade0c689@github.com>

On Wed, 21 Oct 2020 16:28:21 GMT, CoreyAshford <github.com+51754783+CoreyAshford at openjdk.org> wrote:

>> Buried in that GitHub test run link are the results for
>> windows-x64-debug_testlogs_hs_tier1_compiler
>> which includes this file (test-summary.txt):
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR   
>>>> jtreg:test/hotspot/jtreg:tier1_compiler             742   683    59     0 <<
>> ==============================
>> TEST FAILURE
>> I poked around, but I don't see any logs for the individual
>> test failures.
>
>> Buried in that GitHub test run link are the results for
>> windows-x64-debug_testlogs_hs_tier1_compiler
>> which includes this file (test-summary.txt):
>> 
>> ```
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR   
>> >> jtreg:test/hotspot/jtreg:tier1_compiler             742   683    59     0 <<
>> ==============================
>> TEST FAILURE
>> ```
>> 
>> I poked around, but I don't see any logs for the individual
>> test failures.
> 
> In a browser at the provide test link, on the upper right in the "three-dot menu", there's an option to download the logs.  The only file containing failures is `6_Windows x64 (hstier1 compiler).txt`. There are quite a few exception backtraces in this log file, but they all look similar, saying:
> TEST RESULT: Failed. Execution failed: `main' threw exception: java.lang.NullPointerException: Cannot invoke "java.lang.Throwable.getCause()" because "<local1>" is null
> There's only one that's slightly different:
> TEST RESULT: Failed. Execution failed: `main' threw exception: java.lang.Error: Can't get full path name for '.', got exception java.lang.NullPointerException: Cannot invoke "java.lang.Throwable.getCause()" because "<local1>" is null

> I will push the code, but I haven't been successful in running the test (see [#293 (comment)](https://github.com/openjdk/jdk/pull/293#issuecomment-713223068) )

I submitted our testing and let you know results. I used your latest '06: Full' changes.
It should run CheckGraalIntrinsics.java with pushed 8254785 fix which enable it again.

-------------

PR: https://git.openjdk.java.net/jdk/pull/293

From rriggs at openjdk.java.net  Wed Oct 21 17:33:26 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 21 Oct 2020 17:33:26 GMT
Subject: RFR: 8251989: Hex formatting and parsing utility [v7]
In-Reply-To: <HSEn47GMS1K3g57mrTZeQk-WZHl3pKGHpX_OOf8VnsU=.740863c2-f9e4-43c4-b500-614aab4078b1@github.com>
References: <HSEn47GMS1K3g57mrTZeQk-WZHl3pKGHpX_OOf8VnsU=.740863c2-f9e4-43c4-b500-614aab4078b1@github.com>
Message-ID: <MSudabibbmePqmfAXqBHwN3VeHMyAUpmSetgSLDRbC0=.c5441c61-683f-41eb-82e8-369ae408207a@github.com>

> java.util.HexFormat utility:
> 
>  - Format and parse hexadecimal strings, with parameters for delimiter, prefix, suffix and upper/lowercase
>  - Static factories and builder methods to create HexFormat copies with modified parameters.
>  - Consistent naming of methods for conversion of byte arrays to formatted strings and back: formatHex and parseHex
>  - Consistent naming of methods for conversion of primitive types: toHexDigits... and fromHexDigits...
>  - Prefix and suffixes now apply to each formatted value, not the string as a whole
>  - Using java.util.Appendable as a target for buffered conversions so output to Writers and PrintStreams
>    like System.out are supported in addition to StringBuilder. (IOExceptions are converted to unchecked exceptions)
>  - Immutable and thread safe, a "value-based" class
> 
> See the [HexFormat javadoc](http://cr.openjdk.java.net/~rriggs/8251989-hex-formatter/java.base/java/util/HexFormat.html) for details.
> 
> Review comments and suggestions welcome.

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Review comment updates, in the example code, and to describe the characters used to convert to hexadecimal

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/482/files
  - new: https://git.openjdk.java.net/jdk/pull/482/files/1d2c26f2..0a47544f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=482&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=482&range=05-06

  Stats: 10 lines in 2 files changed: 0 ins; 2 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/482.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/482/head:pull/482

PR: https://git.openjdk.java.net/jdk/pull/482

From bchristi at openjdk.java.net  Wed Oct 21 17:49:20 2020
From: bchristi at openjdk.java.net (Brent Christian)
Date: Wed, 21 Oct 2020 17:49:20 GMT
Subject: RFR: 8255031 : Update java/util/prefs/AddNodeChangeListener.java
 to report more failure info
In-Reply-To: <ZRV3SOkJEwknALGlWvNjoTzp0B7njS082WWSfN0jaqw=.2be56475-f32b-45f7-b800-3681b9834776@github.com>
References: <WdQlv9nOZU91fs2chRaHhYRTVnuMwcB297XumQEUW7k=.9f8d9fe3-4418-4d8b-95db-2cc31ab34ebf@github.com>
 <ZRV3SOkJEwknALGlWvNjoTzp0B7njS082WWSfN0jaqw=.2be56475-f32b-45f7-b800-3681b9834776@github.com>
Message-ID: <-_Wz8aWunZIqNRFejfFDkUPfrNqNRq29SlfEKtqLbss=.40af4845-06cc-48a7-9468-2e8c22a0425b@github.com>

On Tue, 20 Oct 2020 23:25:31 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Hi,
>> 
>> The java/util/prefs/AddNodeChangeListener.java test fails once in a while in the automated test system.  Previous failures were traced to machine configuration errors, but that does not appear to be the case this time.
>> 
>> My efforts to reproduce this failure have been unsuccessful.  The only useful information I've gleaned so far from the test failure logs is that the overall duration for running tier1 is longer than usual when the test failure happens.
>> 
>> I would like to make the following updates to the test, in hopes of learning more if and when this test fails again:
>> 
>> * fail faster, to report if it is addNode() or removeNode() that is failing
>> * make multiple attempts to sleep+check the NodeChangeListener.  (If the test fails after a single sleep, but passes after waiting longer, maybe we just need to sleep for longer to account for the occasional slower tier1 test run).
>> * a few indentations fixes
>> 
>> Thanks,
>> -Brent
>
> test/jdk/java/util/prefs/AddNodeChangeListener.java line 65:
> 
>> 63: 
>> 64:         for (int i = 0; i < SLEEP_ITRS; i++) {
>> 65:             Thread.sleep(3000);
> 
> Would there be any value in printing the iteration number here and in the analogous location in removeNode() in case the test times out?

That's a pretty good idea.  In theory, there should be a maximum of 90s total of sleeping, and enough time for the test to complete within the default timeout of 2m.  But AFAICT in the failure case, the test takes longer to run, so maybe it could timeout in that case.  If this failure eventually shows up again, it would be best to have at least *some* new output to show for it. :)

-------------

PR: https://git.openjdk.java.net/jdk/pull/773

From bchristi at openjdk.java.net  Wed Oct 21 18:05:26 2020
From: bchristi at openjdk.java.net (Brent Christian)
Date: Wed, 21 Oct 2020 18:05:26 GMT
Subject: RFR: 8255031 : Update java/util/prefs/AddNodeChangeListener.java
 to report more failure info [v2]
In-Reply-To: <WdQlv9nOZU91fs2chRaHhYRTVnuMwcB297XumQEUW7k=.9f8d9fe3-4418-4d8b-95db-2cc31ab34ebf@github.com>
References: <WdQlv9nOZU91fs2chRaHhYRTVnuMwcB297XumQEUW7k=.9f8d9fe3-4418-4d8b-95db-2cc31ab34ebf@github.com>
Message-ID: <48y81ts6Q-HS-bJf3p_RIjj8E4evBGRKXuEVXg82avY=.e279714e-854d-451e-b7f6-d587b366ccc2@github.com>

> Hi,
> 
> The java/util/prefs/AddNodeChangeListener.java test fails once in a while in the automated test system.  Previous failures were traced to machine configuration errors, but that does not appear to be the case this time.
> 
> My efforts to reproduce this failure have been unsuccessful.  The only useful information I've gleaned so far from the test failure logs is that the overall duration for running tier1 is longer than usual when the test failure happens.
> 
> I would like to make the following updates to the test, in hopes of learning more if and when this test fails again:
> 
> * fail faster, to report if it is addNode() or removeNode() that is failing
> * make multiple attempts to sleep+check the NodeChangeListener.  (If the test fails after a single sleep, but passes after waiting longer, maybe we just need to sleep for longer to account for the occasional slower tier1 test run).
> * a few indentations fixes
> 
> Thanks,
> -Brent

Brent Christian has updated the pull request incrementally with one additional commit since the last revision:

  print counter for sleeps

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/773/files
  - new: https://git.openjdk.java.net/jdk/pull/773/files/5767bb3e..23eca90a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=773&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=773&range=00-01

  Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/773.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/773/head:pull/773

PR: https://git.openjdk.java.net/jdk/pull/773

From github.com+11685886+marcono1234 at openjdk.java.net  Wed Oct 21 18:07:18 2020
From: github.com+11685886+marcono1234 at openjdk.java.net (Marcono1234)
Date: Wed, 21 Oct 2020 18:07:18 GMT
Subject: RFR: 8251989: Hex formatting and parsing utility [v6]
In-Reply-To: <-Wba6yvKoGM96GeaL5kpA0xb7jRx4sohJ9qeeCDLVAY=.8545839a-c5d9-41e1-ae2c-2b6da1931560@github.com>
References: <HSEn47GMS1K3g57mrTZeQk-WZHl3pKGHpX_OOf8VnsU=.740863c2-f9e4-43c4-b500-614aab4078b1@github.com>
 <seKMG87WLCuFuqEZuua-7hrmYxXeSYsoFATrMAqZMs4=.b4d97cb5-d84a-427c-9994-9292fa127e35@github.com>
 <yTU1KThBgWoep1dgs5_JnxJm7Gh82hsXWDNx-vNFF04=.8877db35-776f-413f-87f5-0d5d83ee0f8b@github.com>
 <-Wba6yvKoGM96GeaL5kpA0xb7jRx4sohJ9qeeCDLVAY=.8545839a-c5d9-41e1-ae2c-2b6da1931560@github.com>
Message-ID: <EDwRIubhG0htyUqcjz2QwXmtkTTTVpbW5iyEeTDgp2M=.3cc243d2-9073-4090-887f-350290cbf5d7@github.com>

On Tue, 20 Oct 2020 14:37:01 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/HexFormat.java line 127:
>> 
>>> 125:  *
>>> 126:  * @implSpec
>>> 127:  * This class is immutable and thread-safe.
>> 
>> I'm curious why this is an implSpec, and not just a normative statement? HexFormat is a final class after all, there is just one implementation.
>
> Good point, will remove @ImplSpec.

Should this be a separate paragraph (`<p>` ) though? Currently it would be part of the paragraph about being value-based.

-------------

PR: https://git.openjdk.java.net/jdk/pull/482

From github.com+11685886+marcono1234 at openjdk.java.net  Wed Oct 21 18:07:20 2020
From: github.com+11685886+marcono1234 at openjdk.java.net (Marcono1234)
Date: Wed, 21 Oct 2020 18:07:20 GMT
Subject: RFR: 8251989: Hex formatting and parsing utility [v7]
In-Reply-To: <MSudabibbmePqmfAXqBHwN3VeHMyAUpmSetgSLDRbC0=.c5441c61-683f-41eb-82e8-369ae408207a@github.com>
References: <HSEn47GMS1K3g57mrTZeQk-WZHl3pKGHpX_OOf8VnsU=.740863c2-f9e4-43c4-b500-614aab4078b1@github.com>
 <MSudabibbmePqmfAXqBHwN3VeHMyAUpmSetgSLDRbC0=.c5441c61-683f-41eb-82e8-369ae408207a@github.com>
Message-ID: <Jr4jEVJZsxDrf0CVMUY9-IrP9W6Yl6ytzn7ORlIgWtA=.2114b24c-510b-4ffe-b4d4-d1d3355f181d@github.com>

On Wed, 21 Oct 2020 17:33:26 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> java.util.HexFormat utility:
>> 
>>  - Format and parse hexadecimal strings, with parameters for delimiter, prefix, suffix and upper/lowercase
>>  - Static factories and builder methods to create HexFormat copies with modified parameters.
>>  - Consistent naming of methods for conversion of byte arrays to formatted strings and back: formatHex and parseHex
>>  - Consistent naming of methods for conversion of primitive types: toHexDigits... and fromHexDigits...
>>  - Prefix and suffixes now apply to each formatted value, not the string as a whole
>>  - Using java.util.Appendable as a target for buffered conversions so output to Writers and PrintStreams
>>    like System.out are supported in addition to StringBuilder. (IOExceptions are converted to unchecked exceptions)
>>  - Immutable and thread safe, a "value-based" class
>> 
>> See the [HexFormat javadoc](http://cr.openjdk.java.net/~rriggs/8251989-hex-formatter/java.base/java/util/HexFormat.html) for details.
>> 
>> Review comments and suggestions welcome.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment updates, in the example code, and to describe the characters used to convert to hexadecimal

src/java.base/share/classes/java/util/HexFormat.java line 62:

> 60:  * the {@code formatHex} methods include {@link #formatHex(byte[]) formatHex(byte[])}
> 61:  * and {@link #formatHex(Appendable, byte[]) formatHex(Appendable, byte[])}.
> 62:  * The formatted output is a string or to {@link Appendable} types including

Suggestion:

 * The formatted output is a string or can be appended to {@link Appendable} types including
It looks like "can be appended" got lost.

What about using "such as" instead of "including" to make it more clear that these are only example classes?

-------------

PR: https://git.openjdk.java.net/jdk/pull/482

From dawid.weiss at gmail.com  Wed Oct 21 18:36:27 2020
From: dawid.weiss at gmail.com (Dawid Weiss)
Date: Wed, 21 Oct 2020 20:36:27 +0200
Subject: "loc: wrong sig" in ZipFileSystem on a valid ZIP file (extra data
 field of exactly 5 bytes)
In-Reply-To: <17F644E3-E5E0-403E-B568-FCB89C8BD9BB@ORACLE.COM>
References: <CAM21Rt8KeWyQvjE7-5pfyXYJXO3yGgGfKpBtueOV8qgNFMa+jQ@mail.gmail.com>
 <17F644E3-E5E0-403E-B568-FCB89C8BD9BB@ORACLE.COM>
Message-ID: <CAM21Rt-ANpHbDO-kjSHguDzSTGS-WhGwHsbxcHav1wFVvDQ2EQ@mail.gmail.com>

Hi Lance,

Yes, this is exactly the point where the problem is in JDK code. It's directly
related to the zip entry beyond max int offset. The code tries to read data
from a local zip entry header at locoff, here:

if (zipfs.readFullyAt(buf, 0, buf.length , locoff)

but the locoff is set to ~0 as per the spec for files exceeding
4 gigabytes, which says:

   4.4.16 relative offset of local header: (4 bytes)

       This is the offset from the start of the first disk on
       which this file appears, to where the local header SHOULD
       be found.  If an archive is in ZIP64 format and the value
       in this field is 0xFFFFFFFF, the size will be in the
       corresponding 8 byte zip64 extended information extra field.

A proper fix would be to read the local header from zip64 extra data
first. I don't know how this interferes with the rest of the code though -
didn't have enough time to look at it. As it stands, zip entries
beyond 4GB cause
an unchecked exception while attribute-scanning. This simple snippet
is enough to demonstrate it, given a ZIP entry beyond 4GB range:

try (FileSystem fs =
FileSystems.newFileSystem(Paths.get("zipWithEntryBeyond4Gb.zip"))) {
  for (Path root : fs.getRootDirectories()) {
    Files.walkFileTree(root, new SimpleFileVisitor<>() {
      @Override
      public FileVisitResult visitFile(Path file, BasicFileAttributes
attrs) throws IOException {
        return FileVisitResult.CONTINUE;
      }
    });
  }
}

The walkFileTree method is key here as it attempts to harvest
attributes (why we use it is another story -- this saves a lot of time
on large, network-mounted regular directories when you're collecting
file metadata).


Dawid


On Wed, Oct 21, 2020 at 6:39 PM Lance Andersen
<LANCE.ANDERSEN at oracle.com> wrote:
>
> Hi David,
>
> From  a quick look at ZipFileSystem this appears to be an optimization to avoid looking at the LOC extended Timestamp Extra field
>
> If a Info-ZIP Extended Timestamp (0x5455)is found then:
>
>   If the "zipinfo-time" entry was set  to ?false? in the Map specified when creating the Zip FileSystem,
>
> FileSystems.newFileSystem(zipFile, Map.of("zipinfo-time", "false")
>
> and the  data size of the CEN extended Timestamp is 5 (flag + mod time)
>
> The modified time is used from the CEN Extended Timestamp extra field
>
> Otherwise get the modified time, creation time, and access time from the LOC Extended Timestamp extra field.
>
>
> ?????
>
>  Extended Timestamp Extra Field:
>
>           ==============================
>
>           The following is the layout of the extended-timestamp extra block.
>           (Last Revision 19970118)
>
>           Local-header version:
>
>           Value         Size        Description
>           -----         ----        -----------
>   (time)  0x5455        Short       tag for this extra block type ("UT")
>           TSize         Short       total data size for this block
>           Flags         Byte        info bits
>           (ModTime)     Long        time of last modification (UTC/GMT)
>           (AcTime)      Long        time of last access (UTC/GMT)
>           (CrTime)      Long        time of original creation (UTC/GMT)
>
>           Central-header version:
>
>           Value         Size        Description
>           -----         ----        -----------
>   (time)  0x5455        Short       tag for this extra block type ("UT")
>           TSize         Short       total data size for this block
>           Flags         Byte        info bits (refers to local header!)
>           (ModTime)     Long        time of last modification (UTC/GMT)
>
>           The central-header extra field contains the modification time only,
>           or no timestamp at all.  TSize is used to flag its presence or
>           absence.  But note:
>
>               If "Flags" indicates that Modtime is present in the local header
>               field, it MUST be present in the central header field, too!
>               This correspondence is required because the modification time
>               value may be used to support trans-timezone freshening and
>               updating operations with zip archives.
>
>           The time values are in standard Unix signed-long format, indicating
>           the number of seconds since 1 January 1970 00:00:00.  The times
>           are relative to Coordinated Universal Time (UTC), also sometimes
>           referred to as Greenwich Mean Time (GMT).  To convert to local time,
>           the software must know the local timezone offset from UTC/GMT.
>
>           The lower three bits of Flags in both headers indicate which time-
>           stamps are present in the LOCAL extra field:
>
>                 bit 0           if set, modification time is present
>                 bit 1           if set, access time is present
>                 bit 2           if set, creation time is present
>                 bits 3-7        reserved for additional timestamps; not set
>
>           Those times that are present will appear in the order indicated, but
>           any combination of times may be omitted.  (Creation time may be
>           present without access time, for example.)  TSize should equal
>           (1 + 4*(number of set bits in Flags)), as the block is currently
>           defined.  Other timestamps may be added in the future.
>
>
> --------------
>
> It's hard to comment on why you received the error that you did but it is possible the tool that was used for writing the entry  did something unexpected.
>
> Out of curiosity, have you tried using ZipFile/ZipEntry to access the entry?
>
>
> Best,
> Lance
>
>
> On Oct 21, 2020, at 4:55 AM, Dawid Weiss <dawid.weiss at gmail.com> wrote:
>
> Hello,
>
> We've encountered a seemingly valid ZIP file (zipinfo -v shows all its
> entries are intact) that causes a runtime exception when scanning its
> contents with ZipFileSystem. The exception indicates an invalid
> signature when parsing EXTID_EXTT. I don't quite understand this
> comment in the code:
>
> case EXTID_EXTT:
>    // spec says the Extened timestamp in cen only has mtime
>    // need to read the loc to get the extra a/ctime, if flag
>    // "zipinfo-time" is not specified to false;
>    // there is performance cost (move up to loc and read) to
>    // access the loc table foreach entry;
>    if (zipfs.noExtt) {
>        if (sz == 5)
>            mtime = unixToJavaTime(LG(extra, pos + 1));
>         break;
>    }
> ...
>
> but this ZIP file has the extra data block of exactly 5 bytes, as
> indicated by zipinfo:
>
> Central directory entry #6:
> ---------------------------
> ...
>  file system or operating system of origin:      Unix
>  version of encoding software:                   3.0
>  minimum file system compatibility required:     MS-DOS, OS/2 or NT FAT
>  minimum software version required to extract:   2.0
>  compression method:                             deflated
> ...
>  extended local header:                          no
>  file last modified on (DOS date/time):          2018 Mar 1 04:56:20
>  file last modified on (UT extra field modtime): 2018 Mar 1 05:56:19 local
>  file last modified on (UT extra field modtime): 2018 Mar 1 04:56:19 UTC
> ...
>  Unix file attributes (100000 octal):            ----------
>  MS-DOS file attributes (01 hex):                read-only
>
>  The central-directory extra field contains:
>  - A subfield with ID 0x5455 (universal time) and 5 data bytes.
>    The local extra field has UTC/GMT modification/access times.
>
> The above conditional block checking for length == 5 would have worked
> in ZipFileSystem but it's surrounded by a condition over an
> externally-provided property - zipfs.noExtt is only set to true if:
>
> this.noExtt = "false".equals(env.get("zipinfo-time"));
>
> I can't share this particular ZIP file with you and I don't know how
> it was created but it seems like that "zipinfo-time" flag could be
> omitted if the length of the extra data field is exactly 5?
>
> Dawid
>
>
>
> Best
> Lance
> ------------------
>
>
>
> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering
> 1 Network Drive
> Burlington, MA 01803
> Lance.Andersen at oracle.com
>
>
>
>

From bpb at openjdk.java.net  Wed Oct 21 18:53:17 2020
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 21 Oct 2020 18:53:17 GMT
Subject: RFR: 8255031 : Update java/util/prefs/AddNodeChangeListener.java
 to report more failure info [v2]
In-Reply-To: <48y81ts6Q-HS-bJf3p_RIjj8E4evBGRKXuEVXg82avY=.e279714e-854d-451e-b7f6-d587b366ccc2@github.com>
References: <WdQlv9nOZU91fs2chRaHhYRTVnuMwcB297XumQEUW7k=.9f8d9fe3-4418-4d8b-95db-2cc31ab34ebf@github.com>
 <48y81ts6Q-HS-bJf3p_RIjj8E4evBGRKXuEVXg82avY=.e279714e-854d-451e-b7f6-d587b366ccc2@github.com>
Message-ID: <Tt98GJVTVuv1iyk1LlWhkNu6MKDje_NJlHn51MhsznU=.13a629de-af3d-448e-8361-6514e254d201@github.com>

On Wed, 21 Oct 2020 18:05:26 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Hi,
>> 
>> The java/util/prefs/AddNodeChangeListener.java test fails once in a while in the automated test system.  Previous failures were traced to machine configuration errors, but that does not appear to be the case this time.
>> 
>> My efforts to reproduce this failure have been unsuccessful.  The only useful information I've gleaned so far from the test failure logs is that the overall duration for running tier1 is longer than usual when the test failure happens.
>> 
>> I would like to make the following updates to the test, in hopes of learning more if and when this test fails again:
>> 
>> * fail faster, to report if it is addNode() or removeNode() that is failing
>> * make multiple attempts to sleep+check the NodeChangeListener.  (If the test fails after a single sleep, but passes after waiting longer, maybe we just need to sleep for longer to account for the occasional slower tier1 test run).
>> * a few indentations fixes
>> 
>> Thanks,
>> -Brent
>
> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
> 
>   print counter for sleeps

Marked as reviewed by bpb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/773

From psandoz at openjdk.java.net  Wed Oct 21 19:08:25 2020
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Wed, 21 Oct 2020 19:08:25 GMT
Subject: RFR: 8254231: Implementation of Foreign Linker API (Incubator)
 [v9]
In-Reply-To: <XvFIGunZ1EjNeZNgkF_I06FjuDxHmD8jjCJ2HkpF_xE=.15ac4c1b-063a-4181-ad6b-3fd64e95b0ed@github.com>
References: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
 <XvFIGunZ1EjNeZNgkF_I06FjuDxHmD8jjCJ2HkpF_xE=.15ac4c1b-063a-4181-ad6b-3fd64e95b0ed@github.com>
Message-ID: <KUq2-MTn5B82LZGZ0PBp4kvYEyjLyX3Rg9jtH2yKO2w=.85804c26-ea5a-4ecd-8a4f-ad475a954bd5@github.com>

On Wed, 21 Oct 2020 11:33:27 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This patch contains the changes associated with the first incubation round of the foreign linker access API incubation
>> (see JEP 389 [1]). This work is meant to sit on top of the foreign memory access support (see JEP 393 [2] and associated pull request [3]).
>> 
>> The main goal of this API is to provide a way to call native functions from Java code without the need of intermediate JNI glue code. In order to do this, native calls are modeled through the MethodHandle API. I suggest reading the writeup [4] I put together few weeks ago, which illustrates what the foreign linker support is, and how it should be used by clients.
>> 
>> Disclaimer: the pull request mechanism isn't great at managing *dependent* reviews. For this reasons, I'm attaching a webrev which contains only the differences between this PR and the memory access PR. I will be periodically uploading new webrevs, as new iterations come out, to try and make the life of reviewers as simple as possible.
>> 
>> A big thank to Jorn Vernee and Vladimir Ivanov - they are the main architects of all the hotspot changes you see here, and without their help, the foreign linker support wouldn't be what it is today. As usual, a big thank to Paul Sandoz, who provided many insights (often by trying the bits first hand).
>> 
>> Thanks
>> Maurizio
>> 
>> Webrev:
>> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/webrev
>> 
>> Javadoc:
>> 
>> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/javadoc/jdk/incubator/foreign/package-summary.html
>> 
>> Specdiff (relative to [3]):
>> 
>> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/specdiff_delta/overview-summary.html
>> 
>> CSR:
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8254232
>> 
>> 
>> 
>> ### API Changes
>> 
>> The API changes are actually rather slim:
>> 
>> * `LibraryLookup`
>>   * This class allows clients to lookup symbols in native libraries; the interface is fairly simple; you can load a library by name, or absolute path, and then lookup symbols on that library.
>> * `FunctionDescriptor`
>>   * This is an abstraction that is very similar, in spirit, to `MethodType`; it is, at its core, an aggregate of memory layouts for the function arguments/return type. A function descriptor is used to describe the signature of a native function.
>> * `CLinker`
>>   * This is the real star of the show. A `CLinker` has two main methods: `downcallHandle` and `upcallStub`; the first takes a native symbol (as obtained from `LibraryLookup`), a `MethodType` and a `FunctionDescriptor` and returns a `MethodHandle` instance which can be used to call the target native symbol. The second takes an existing method handle, and a `FunctionDescriptor` and returns a new `MemorySegment` corresponding to a code stub allocated by the VM which acts as a trampoline from native code to the user-provided method handle. This is very useful for implementing upcalls.
>>    * This class also contains the various layout constants that should be used by clients when describing native signatures (e.g. `C_LONG` and friends); these layouts contain additional ABI classfication information (in the form of layout attributes) which is used by the runtime to *infer* how Java arguments should be shuffled for the native call to take place.
>>   * Finally, this class provides some helper functions e.g. so that clients can convert Java strings into C strings and back.
>> * `NativeScope`
>>   * This is an helper class which allows clients to group together logically related allocations; that is, rather than allocating separate memory segments using separate *try-with-resource* constructs, a `NativeScope` allows clients to use a _single_ block, and allocate all the required segments there. This is not only an usability boost, but also a performance boost, since not all allocation requests will be turned into `malloc` calls.
>> * `MemorySegment`
>>   * Only one method added here - namely `handoff(NativeScope)` which allows a segment to be transferred onto an existing native scope.
>> 
>> ### Safety
>> 
>> The foreign linker API is intrinsically unsafe; many things can go wrong when requesting a native method handle. For instance, the description of the native signature might be wrong (e.g. have too many arguments) - and the runtime has, in the general case, no way to detect such mismatches. For these reasons, obtaining a `CLinker` instance is a *restricted* operation, which can be enabled by specifying the usual JDK property `-Dforeign.restricted=permit` (as it's the case for other restricted method in the foreign memory API).
>> 
>> ### Implementation changes
>> 
>> The Java changes associated with `LibraryLookup` are relative straightforward; the only interesting thing to note here is that library loading does _not_ depend on class loaders, so `LibraryLookup` is not subject to the same restrictions which apply to JNI library loading (e.g. same library cannot be loaded by different classloaders).
>> 
>> As for `NativeScope` the changes are again relatively straightforward; it is an API which sits neatly on top of the foreign meory access API, providing some kind of allocation service which shares the same underlying memory segment(s), and turns an allocation request into a segment slice, which is a much less expensive operation. `NativeScope` comes in two variants: there are native scopes for which the allocation size is known a priori, and native scopes which can grow - these two schemes are implemented by two separate subclasses of `AbstractNativeScopeImpl`.
>> 
>> Of course the bulk of the changes are to support the `CLinker` downcall/upcall routines. These changes cut pretty deep into the JVM; I'll briefly summarize the goal of some of this changes - for further details, Jorn has put together a detailed writeup which explains the rationale behind the VM support, with some references to the code [5].
>> 
>> The main idea behind foreign linker is to infer, given a Java method type (expressed as a `MethodType` instance) and the description of the signature of a native function (expressed as a `FunctionDescriptor` instance) a _recipe_ that can be used to turn a Java call into the corresponding native call targeting the requested native function.
>> 
>> This inference scheme can be defined in a pretty straightforward fashion by looking at the various ABI specifications (for instance, see [6] for the SysV ABI, which is the one used on Linux/Mac). The various `CallArranger` classes, of which we have a flavor for each supported platform, do exactly that kind of inference.
>> 
>> For the inference process to work, we need to attach extra information to memory layouts; it is no longer sufficient to know e.g. that a layout is 32/64 bits - we need to know whether it is meant to represent a floating point value, or an integral value; this knowledge is required because floating points are passed in different registers by most ABIs. For this reason, `CLinker` offers a set of pre-baked, platform-dependent layout constants which contain the required classification attributes (e.g. a `Clinker.TypeKind` enum value). The runtime extracts this attribute, and performs classification accordingly.
>> 
>> A native call is decomposed into a sequence of basic, primitive operations, called `Binding` (see the great javadoc on the `Binding.java` class for more info). There are many such bindings - for instance the `Move` binding is used to move a value into a specific machine register/stack slot. So, the main job of the various `CallingArranger` classes is to determine, given a Java `MethodType` and `FunctionDescriptor` what is the set of bindings associated with the downcall/upcall.
>> 
>> At the heart of the foreign linker support is the `ProgrammableInvoker` class. This class effectively generates a `MethodHandle` which follows the steps described by the various bindings obtained by `CallArranger`. There are actually various strategies to interpret these bindings - listed below:
>> 
>> * basic intepreted mode; in this mode, all bindings are interpreted using a stack-based machine written in Java (see `BindingInterpreter`), except for the `Move` bindings. For these bindings, the move is implemented by allocating a *buffer* (whose size is ABI specific) and by moving all the lowered values into positions within this buffer. The buffer is then passed to a piece of assembly code inside the VM which takes values from the buffer and moves them in their expected registers/stack slots (note that each position in the buffer corresponds to a different register). This is the most general invocation mode, the more "customizable" one, but also the slowest - since for every call there is some extra allocation which takes place.
>> 
>> * specialized interpreted mode; same as before, but instead of interpreting the bindings with a stack-based interpreter, we generate a method handle chain which effectively interprets all the bindings (again, except `Move` ones).
>> 
>> * intrinsified mode; this is typically used in combination with the specialized interpreted mode described above (although it can also be used with the Java-based binding interpreter). The goal here is to remove the buffer allocation and copy by introducing an additional JVM intrinsic. If a native call recipe is constant (e.g. the set of bindings is constant, which is probably the case if the native method handle is stored in a `static`, `final` field), then the VM can generate specialized assembly code which interprets the `Move` binding without the need to go for an intermediate buffer. This gives us back performances that are on par with JNI.
>> 
>> For upcalls, the support is not (yet) as advanced, and only the basic interpreted mode is available there. We plan to add support for intrinsified modes there as well, which should considerably boost perfomances (probably well beyond what JNI can offer at the moment, since the upcall support in JNI is not very well optimized).
>> 
>> Again, for more readings on the internals of the foreign linker support, please refer to [5].
>> 
>> #### Test changes
>> 
>> Many new tests have been added to validate the foreign linker support; we have high level tests (see `StdLibTest`) which aim at testing the linker from the perspective of code that clients could write. But we also have deeper combinatorial tests (see `TestUpcall` and `TestDowncall`) which are meant to stress every corner of the ABI implementation. There are also some great tests (see the `callarranger` folder) which test the various `CallArranger`s for all the possible platforms; these tests adopt more of a white-box approach - that is, instead of treating the linker machinery as a black box and verify that the support works by checking that the native call returned the results we expected, these tests aims at checking that the set of bindings generated by the call arranger is correct. This also mean that we can test the classification logic for Windows, Mac and Linux regardless of the platform we're executing on.
>> 
>> Some additional microbenchmarks have been added to compare the performances of downcall/upcall with JNI.
>> 
>> [1] - https://openjdk.java.net/jeps/389
>> [2] - https://openjdk.java.net/jeps/393
>> [3] - https://git.openjdk.java.net/jdk/pull/548
>> [4] - https://github.com/openjdk/panama-foreign/blob/foreign-jextract/doc/panama_ffi.md
>> [5] - http://cr.openjdk.java.net/~jvernee/docs/Foreign-abi%20downcall%20intrinsics%20technical%20description.html
>
> Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 27 commits:
> 
>  - Merge branch 'master' into 8254231_linker
>  - Don't use JNI when generating native wrappers
>    
>  - Merge branch 'master' into 8254231_linker
>  - Fix incorrect capitalization in one copyright header
>  - Update copyright years, and add classpath exception to files that were missing it
>  - Use separate constants for native invoker code size
>  - Re-add file erroneously deleted (detected as rename)
>  - Re-add erroneously removed files
>  - Merge branch 'master' into 8254231_linker
>    
>    - Fix tests
>  - Fix more whitespaces
>  - ... and 17 more: https://git.openjdk.java.net/jdk/compare/da97ab5c...8c7b75da

src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/AbstractNativeScope.java line 41:

> 39:     private static final int SCOPE_MASK = MemorySegment.READ | MemorySegment.WRITE; // no terminal operations allowed
> 40: 
> 41:     AbstractNativeScope(Thread ownerThread) {

Since all concrete classes pass in `Thread.currentThread()` we can make this a no-arg constructor. The concrete classes can be marked as final?

src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/AbstractNativeScope.java line 120:

> 118:                 }
> 119:             }
> 120:             throw new AssertionError("Cannot get here!");

This code is a little confusing, effectively using an exception for control flow, within a retry loop. I recommend performing an explicit bounds check to determine if a new segment of `BLOCK_SIZE` is required from which to slice into. It will also be faster than the exceptional case.

src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/CABI.java line 33:

> 31:     AArch64;
> 32: 
> 33:     public static CABI current() {

I suspect this might be called often, create a private static final constant?

src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/Binding.java line 203:

> 201:  * --------------------
> 202:  */
> 203: public abstract class Binding {

Some design considerations, to consider later maybe.

The IR representation could be simplified to use record classes (which should be exiting preview in 16), implementing a Binding interface. The interpreter   and specializer (compiler) could be separate if need be, operating on a sequence of instructions that just hold the data. Pattern matching could be used on the binding instances. It may be simpler and more efficient if the compiler generated explicit byte code rather than using MH combinators.

src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/BindingInterpreter.java line 50:

> 48:     }
> 49: 
> 50:     interface StoreFunc {

Annotate with `@FunctionalInterface`?

src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/CallingSequence.java line 51:

> 49:     }
> 50: 
> 51:     public Stream<Binding> argBindings() {

Duplicate methods `argBindings` and `argumentBindings`?

src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/CallingSequenceBuilder.java line 123:

> 121:     }
> 122: 
> 123:     private static final Set<Binding.Tag> boxTags = EnumSet.of(

s/boxTags/BOX_TAGS

-------------

PR: https://git.openjdk.java.net/jdk/pull/634

From psandoz at openjdk.java.net  Wed Oct 21 19:08:22 2020
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Wed, 21 Oct 2020 19:08:22 GMT
Subject: RFR: 8254231: Implementation of Foreign Linker API (Incubator)
 [v7]
In-Reply-To: <Rxu6c37o5dBPtGxju77Y5NfjLQNIE1yRZw-bnQz1n0k=.7c929e86-7513-49d7-90fa-1d997963050f@github.com>
References: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
 <Rxu6c37o5dBPtGxju77Y5NfjLQNIE1yRZw-bnQz1n0k=.7c929e86-7513-49d7-90fa-1d997963050f@github.com>
Message-ID: <ZGkYBBhHYxqech4xnb28ci0wZUGGlj-oiJm0hiAplUs=.ff119342-fd23-4faf-a3e1-ab31c4d067a5@github.com>

On Tue, 20 Oct 2020 17:23:26 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This patch contains the changes associated with the first incubation round of the foreign linker access API incubation
>> (see JEP 389 [1]). This work is meant to sit on top of the foreign memory access support (see JEP 393 [2] and associated pull request [3]).
>> 
>> The main goal of this API is to provide a way to call native functions from Java code without the need of intermediate JNI glue code. In order to do this, native calls are modeled through the MethodHandle API. I suggest reading the writeup [4] I put together few weeks ago, which illustrates what the foreign linker support is, and how it should be used by clients.
>> 
>> Disclaimer: the pull request mechanism isn't great at managing *dependent* reviews. For this reasons, I'm attaching a webrev which contains only the differences between this PR and the memory access PR. I will be periodically uploading new webrevs, as new iterations come out, to try and make the life of reviewers as simple as possible.
>> 
>> A big thank to Jorn Vernee and Vladimir Ivanov - they are the main architects of all the hotspot changes you see here, and without their help, the foreign linker support wouldn't be what it is today. As usual, a big thank to Paul Sandoz, who provided many insights (often by trying the bits first hand).
>> 
>> Thanks
>> Maurizio
>> 
>> Webrev:
>> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/webrev
>> 
>> Javadoc:
>> 
>> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/javadoc/jdk/incubator/foreign/package-summary.html
>> 
>> Specdiff (relative to [3]):
>> 
>> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/specdiff_delta/overview-summary.html
>> 
>> CSR:
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8254232
>> 
>> 
>> 
>> ### API Changes
>> 
>> The API changes are actually rather slim:
>> 
>> * `LibraryLookup`
>>   * This class allows clients to lookup symbols in native libraries; the interface is fairly simple; you can load a library by name, or absolute path, and then lookup symbols on that library.
>> * `FunctionDescriptor`
>>   * This is an abstraction that is very similar, in spirit, to `MethodType`; it is, at its core, an aggregate of memory layouts for the function arguments/return type. A function descriptor is used to describe the signature of a native function.
>> * `CLinker`
>>   * This is the real star of the show. A `CLinker` has two main methods: `downcallHandle` and `upcallStub`; the first takes a native symbol (as obtained from `LibraryLookup`), a `MethodType` and a `FunctionDescriptor` and returns a `MethodHandle` instance which can be used to call the target native symbol. The second takes an existing method handle, and a `FunctionDescriptor` and returns a new `MemorySegment` corresponding to a code stub allocated by the VM which acts as a trampoline from native code to the user-provided method handle. This is very useful for implementing upcalls.
>>    * This class also contains the various layout constants that should be used by clients when describing native signatures (e.g. `C_LONG` and friends); these layouts contain additional ABI classfication information (in the form of layout attributes) which is used by the runtime to *infer* how Java arguments should be shuffled for the native call to take place.
>>   * Finally, this class provides some helper functions e.g. so that clients can convert Java strings into C strings and back.
>> * `NativeScope`
>>   * This is an helper class which allows clients to group together logically related allocations; that is, rather than allocating separate memory segments using separate *try-with-resource* constructs, a `NativeScope` allows clients to use a _single_ block, and allocate all the required segments there. This is not only an usability boost, but also a performance boost, since not all allocation requests will be turned into `malloc` calls.
>> * `MemorySegment`
>>   * Only one method added here - namely `handoff(NativeScope)` which allows a segment to be transferred onto an existing native scope.
>> 
>> ### Safety
>> 
>> The foreign linker API is intrinsically unsafe; many things can go wrong when requesting a native method handle. For instance, the description of the native signature might be wrong (e.g. have too many arguments) - and the runtime has, in the general case, no way to detect such mismatches. For these reasons, obtaining a `CLinker` instance is a *restricted* operation, which can be enabled by specifying the usual JDK property `-Dforeign.restricted=permit` (as it's the case for other restricted method in the foreign memory API).
>> 
>> ### Implementation changes
>> 
>> The Java changes associated with `LibraryLookup` are relative straightforward; the only interesting thing to note here is that library loading does _not_ depend on class loaders, so `LibraryLookup` is not subject to the same restrictions which apply to JNI library loading (e.g. same library cannot be loaded by different classloaders).
>> 
>> As for `NativeScope` the changes are again relatively straightforward; it is an API which sits neatly on top of the foreign meory access API, providing some kind of allocation service which shares the same underlying memory segment(s), and turns an allocation request into a segment slice, which is a much less expensive operation. `NativeScope` comes in two variants: there are native scopes for which the allocation size is known a priori, and native scopes which can grow - these two schemes are implemented by two separate subclasses of `AbstractNativeScopeImpl`.
>> 
>> Of course the bulk of the changes are to support the `CLinker` downcall/upcall routines. These changes cut pretty deep into the JVM; I'll briefly summarize the goal of some of this changes - for further details, Jorn has put together a detailed writeup which explains the rationale behind the VM support, with some references to the code [5].
>> 
>> The main idea behind foreign linker is to infer, given a Java method type (expressed as a `MethodType` instance) and the description of the signature of a native function (expressed as a `FunctionDescriptor` instance) a _recipe_ that can be used to turn a Java call into the corresponding native call targeting the requested native function.
>> 
>> This inference scheme can be defined in a pretty straightforward fashion by looking at the various ABI specifications (for instance, see [6] for the SysV ABI, which is the one used on Linux/Mac). The various `CallArranger` classes, of which we have a flavor for each supported platform, do exactly that kind of inference.
>> 
>> For the inference process to work, we need to attach extra information to memory layouts; it is no longer sufficient to know e.g. that a layout is 32/64 bits - we need to know whether it is meant to represent a floating point value, or an integral value; this knowledge is required because floating points are passed in different registers by most ABIs. For this reason, `CLinker` offers a set of pre-baked, platform-dependent layout constants which contain the required classification attributes (e.g. a `Clinker.TypeKind` enum value). The runtime extracts this attribute, and performs classification accordingly.
>> 
>> A native call is decomposed into a sequence of basic, primitive operations, called `Binding` (see the great javadoc on the `Binding.java` class for more info). There are many such bindings - for instance the `Move` binding is used to move a value into a specific machine register/stack slot. So, the main job of the various `CallingArranger` classes is to determine, given a Java `MethodType` and `FunctionDescriptor` what is the set of bindings associated with the downcall/upcall.
>> 
>> At the heart of the foreign linker support is the `ProgrammableInvoker` class. This class effectively generates a `MethodHandle` which follows the steps described by the various bindings obtained by `CallArranger`. There are actually various strategies to interpret these bindings - listed below:
>> 
>> * basic intepreted mode; in this mode, all bindings are interpreted using a stack-based machine written in Java (see `BindingInterpreter`), except for the `Move` bindings. For these bindings, the move is implemented by allocating a *buffer* (whose size is ABI specific) and by moving all the lowered values into positions within this buffer. The buffer is then passed to a piece of assembly code inside the VM which takes values from the buffer and moves them in their expected registers/stack slots (note that each position in the buffer corresponds to a different register). This is the most general invocation mode, the more "customizable" one, but also the slowest - since for every call there is some extra allocation which takes place.
>> 
>> * specialized interpreted mode; same as before, but instead of interpreting the bindings with a stack-based interpreter, we generate a method handle chain which effectively interprets all the bindings (again, except `Move` ones).
>> 
>> * intrinsified mode; this is typically used in combination with the specialized interpreted mode described above (although it can also be used with the Java-based binding interpreter). The goal here is to remove the buffer allocation and copy by introducing an additional JVM intrinsic. If a native call recipe is constant (e.g. the set of bindings is constant, which is probably the case if the native method handle is stored in a `static`, `final` field), then the VM can generate specialized assembly code which interprets the `Move` binding without the need to go for an intermediate buffer. This gives us back performances that are on par with JNI.
>> 
>> For upcalls, the support is not (yet) as advanced, and only the basic interpreted mode is available there. We plan to add support for intrinsified modes there as well, which should considerably boost perfomances (probably well beyond what JNI can offer at the moment, since the upcall support in JNI is not very well optimized).
>> 
>> Again, for more readings on the internals of the foreign linker support, please refer to [5].
>> 
>> #### Test changes
>> 
>> Many new tests have been added to validate the foreign linker support; we have high level tests (see `StdLibTest`) which aim at testing the linker from the perspective of code that clients could write. But we also have deeper combinatorial tests (see `TestUpcall` and `TestDowncall`) which are meant to stress every corner of the ABI implementation. There are also some great tests (see the `callarranger` folder) which test the various `CallArranger`s for all the possible platforms; these tests adopt more of a white-box approach - that is, instead of treating the linker machinery as a black box and verify that the support works by checking that the native call returned the results we expected, these tests aims at checking that the set of bindings generated by the call arranger is correct. This also mean that we can test the classification logic for Windows, Mac and Linux regardless of the platform we're executing on.
>> 
>> Some additional microbenchmarks have been added to compare the performances of downcall/upcall with JNI.
>> 
>> [1] - https://openjdk.java.net/jeps/389
>> [2] - https://openjdk.java.net/jeps/393
>> [3] - https://git.openjdk.java.net/jdk/pull/548
>> [4] - https://github.com/openjdk/panama-foreign/blob/foreign-jextract/doc/panama_ffi.md
>> [5] - http://cr.openjdk.java.net/~jvernee/docs/Foreign-abi%20downcall%20intrinsics%20technical%20description.html
>
> Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits:
> 
>  - Merge branch 'master' into 8254231_linker
>  - Fix incorrect capitalization in one copyright header
>  - Update copyright years, and add classpath exception to files that were missing it
>  - Use separate constants for native invoker code size
>  - Re-add file erroneously deleted (detected as rename)
>  - Re-add erroneously removed files
>  - Merge branch 'master' into 8254231_linker
>    
>    - Fix tests
>  - Fix more whitespaces
>  - Fix whitespaces
>  - Remove rejected file
>  - ... and 15 more: https://git.openjdk.java.net/jdk/compare/cb6167b2...502bd980

Some of this is familiar to me from reviews in the `panama-foreign` repository, but less so than the memory API. I focused on the Java code, and ignored changes that are common with the memory API PR.

If it helps in can provide a PR in the `panama-foreign` repository addressing editorial comments to the linker API.

src/java.base/share/classes/java/lang/invoke/NativeMethodHandle.java line 36:

> 34: import static java.lang.invoke.MethodHandleStatics.newInternalError;
> 35: 
> 36: /** TODO */

Is the TODO to make this class public later and adjust the return type of `downcallHandle`?

src/java.base/share/classes/java/lang/invoke/NativeMethodHandle.java line 145:

> 143:      */
> 144:     private static class Lazy {
> 145:         static Class<NativeMethodHandle> THIS_CLASS = NativeMethodHandle.class;

final field? Is this field needed, as `NativeMethodHandle.class` could be used directly, or use a local variable instead in the static code block.

src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 46:

> 44: import java.util.stream.Stream;
> 45: 
> 46: import jdk.internal.loader.NativeLibrary;

Unused import?

src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java line 130:

> 128:      * @return the downcall method handle.
> 129:      * @throws IllegalArgumentException in the case of a carrier type and memory layout mismatch.
> 130:      */

Add `@see LibraryLookup#lookup`

src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java line 126:

> 124:      *
> 125:      * @param symbol   downcall symbol.
> 126:      * @param type     the method type.

s/method type/carrier type ?

src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java line 129:

> 127:      * @param function the function descriptor.
> 128:      * @return the downcall method handle.
> 129:      * @throws IllegalArgumentException in the case of a carrier type and memory layout mismatch.

carrier type and function descriptor mismatch?

src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java line 139:

> 137:      *
> 138:      * <p>The returned segment is <em>not</em> thread-confined, and it only features
> 139:      * the {@link MemorySegment#CLOSE} access mode. When the returned segment is closed,

Implying that it is shared? If so might be better to state that directly (with a link), and can be closed explicitly or left until can be collected by the GC?

src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java line 145:

> 143:      * @param function the function descriptor.
> 144:      * @return the native stub segment.
> 145:      * @throws IllegalArgumentException in the case of a carrier type and memory layout mismatch.

What's carrier type here? `target.type()`?
"IllegalArgumentException if the target's method type the function descriptor mismatch" ?

src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java line 201:

> 199:     }
> 200: 
> 201:         /**

Extra spaces

src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java line 212:

> 210:      * @param str the Java string to be converted into a C string.
> 211:      * @return a new native memory segment containing the converted C string.
> 212:      * @throws NullPointerException if either {@code str == null}.

if {@code str == null}.

src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java line 202:

> 200: 
> 201:         /**
> 202:      * Convert a Java string into a null-terminated C string, using the

Converts (and in other places and for other methods)

src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java line 314:

> 312:      * restricted methods, and use safe and supported functionalities, where possible.
> 313:      * @param addr the address at which the string is stored.
> 314:      * @param charset The {@linkplain java.nio.charset.Charset} to be used to compute the contents of the Java string.

s/linkplain/link (and in other places)

src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java line 352:

> 350:      * @param charset The {@linkplain java.nio.charset.Charset} to be used to compute the contents of the Java string.
> 351:      * @return a Java string with the contents of the null-terminated C string at given address.
> 352:      * @throws NullPointerException if {@code addr == null}

or charset == null (and in other places)

src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java line 380:

> 378: 
> 379:     /**
> 380:      * Allocate memory of given size using malloc.

What if allocation failed? `OutOfMemoryError`?

src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/FunctionDescriptor.java line 60:

> 58:     private FunctionDescriptor(MemoryLayout resLayout, Map<String, Constable> attributes, MemoryLayout... argLayouts) {
> 59:         this.resLayout = resLayout;
> 60:         this.attributes = Collections.unmodifiableMap(attributes);

Since `attributes` is never exposed directly or indirectly via a set of keys/values/entries there is no need to wrap it.

src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/FunctionDescriptor.java line 100:

> 98:     /**
> 99:      * Returns the return layout associated with this function.
> 100:      * @return the return

s/the return/the return layout (and other places)

src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/FunctionDescriptor.java line 145:

> 143:      * @throws NullPointerException if any of the new argument layouts is null.
> 144:      */
> 145:     public FunctionDescriptor appendArgumentLayouts(MemoryLayout... addedLayouts) {

Might consider using "with" as in "withAppendedArgumentLayouts", "withReturnLayout", "withVoidReturnLayout"

src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/LibraryLookup.java line 37:

> 35: 
> 36: /**
> 37:  * A native library lookup. Exposes lookup operation for searching symbols, see {@link LibraryLookup#lookup(String)}.

s/Exposes lookup/Exposes a lookup

src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/LibraryLookup.java line 91:

> 89: 
> 90:     /**
> 91:      * Lookups a symbol with given name in this library. The returned symbol maintains a strong reference to this lookup object.

s/Lookups/Looks up

src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/LibraryLookup.java line 130:

> 128: 
> 129:     /**
> 130:      * Obtain a library lookup object corresponding to a library identified by given library name.

Mention the context in which the library is found i.e. what ever the equivalent of LD_LIBRARY_PATH is in Java (the system property name escapes me at this moment).

src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/NativeScope.java line 44:

> 42:  * by off-heap memory. Native scopes can be either <em>bounded</em> or <em>unbounded</em>, depending on whether the size
> 43:  * of the native scope is known statically. If an application knows before-hand how much memory it needs to allocate,
> 44:  * then using a <em>bounded</em> native scope will typically provide better performances than independently allocating the memory

s/performances/performance

src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/NativeScope.java line 54:

> 52:  * To allow for more usability, it is possible for a native scope to reclaim ownership of an existing memory segment
> 53:  * (see {@link MemorySegment#handoff(NativeScope)}). This might be useful to allow one or more segments which were independently
> 54:  * created to share the same life-cycle as a given native scope - which in turns enables client to group all memory

s/enables client/enables a client

src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/NativeScope.java line 85:

> 83:      * @return a segment for the newly allocated memory block.
> 84:      * @throws OutOfMemoryError if there is not enough space left in this native scope, that is, if
> 85:      * {@code limit() - size() < layout.byteSize()}.

Where do the `limit` and `size` methods come from?

src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/NativeScope.java line 374:

> 372:      * }</pre>
> 373:      * @param elementLayout the array element layout.
> 374:      * @param size the array element count.

s/size/length or count?

-------------

PR: https://git.openjdk.java.net/jdk/pull/634

From kvn at openjdk.java.net  Wed Oct 21 19:24:13 2020
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 21 Oct 2020 19:24:13 GMT
Subject: RFR: 8252204: AArch64: Implement SHA3 accelerator/intrinsic [v10]
In-Reply-To: <Z8q57lCaAf6SukMKsmGpsr6TRJgGa4123VsAvrchYKA=.72dfc784-0637-4dbc-97e6-07efad147ebe@github.com>
References: <PJVtIubjiGKhCK81PIMhWuYxnR84DNieMDUGHdhHYZM=.ad903c93-c5e3-4614-9af1-d36bc33f735d@github.com>
 <kIpiKx8ovndJoa7alAki42vJ4H2lBJ4wN7MFqH5MORg=.57966a12-aa0c-40fb-815b-8bec9c7e8eda@github.com>
 <BtDcca4uUEPGQRwcPjA_ckSsCEX7u_chBB7Qe6P6Wp8=.40f38c07-d6db-41f2-bfa4-a7df321786f2@github.com>
 <Z8q57lCaAf6SukMKsmGpsr6TRJgGa4123VsAvrchYKA=.72dfc784-0637-4dbc-97e6-07efad147ebe@github.com>
Message-ID: <06kvIM_3abB-35pPdgFfbvwCND6oe9QCBqXBQ8iIrZ4=.64ae7da4-be02-46cc-afde-ffeb9ec9d703@github.com>

On Wed, 21 Oct 2020 09:19:57 GMT, Fei Yang <fyang at openjdk.org> wrote:

> > Someone in Oracle have to run tier1-tier3 testing with these changes to make sure nothing is broken. I don't want to repeat 8254790.
> 
> That's appreciated.
> On my side, I run tier1-tier3 both on aarch64 linux and x86_64 linux.
> The test result on these two platforms looks good for the latest changes.

I started testing of 09: version.

>> src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/CheckGraalIntrinsics.java line 604:
>> 
>>> 602:             add(ignore, "sun/security/provider/SHA5." + shaCompressName + "([BI)V");
>>> 603:         }
>>> 604:         add(toBeInvestigated, "sun/security/provider/SHA3." + shaCompressName + "([BI)V");
>> 
>> This should be under `if (isJDK16OrHigher())` check. Something like this:
>> https://github.com/openjdk/jdk/pull/650/files#diff-d1f378fc1b7fe041309e854d40b3a95a91e63fdecf0ecd9826b7c95eaeba314eR527
>> You can wait when Aleksey push it and update your changes
>
> OK.  Will update with the following change after Aleksey's PR is integrated:
> 
> --- a/src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/CheckGraalIntrinsics.java
> +++ b/src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/CheckGraalIntrinsics.java
> @@ -608,6 +608,10 @@ public class CheckGraalIntrinsics extends GraalTest {
>          if (!config.useSHA512Intrinsics()) {
>              add(ignore, "sun/security/provider/SHA5." + shaCompressName + "([BI)V");
>          }
> +
> +        if (isJDK16OrHigher()) {
> +            add(toBeInvestigated, "sun/security/provider/SHA3." + shaCompressName + "([BI)V");
> +        }
>      }

Yes, please, do that.

-------------

PR: https://git.openjdk.java.net/jdk/pull/207

From herrick at openjdk.java.net  Wed Oct 21 20:05:31 2020
From: herrick at openjdk.java.net (Andy Herrick)
Date: Wed, 21 Oct 2020 20:05:31 GMT
Subject: RFR: JDK-8252870: Finalize (remove "incubator" from) jpackage [v4]
In-Reply-To: <HlksY2mFyKG_kkZA6n6JHHIWBGJT3bjmoLG28c9q1EU=.2b9faa66-08b9-4694-a5db-9d9918039642@github.com>
References: <HlksY2mFyKG_kkZA6n6JHHIWBGJT3bjmoLG28c9q1EU=.2b9faa66-08b9-4694-a5db-9d9918039642@github.com>
Message-ID: <D3DS1SNKOqA6gpUZBcxI1EDDnIEaqWRfNTU6zpEI_Ko=.89e21845-916b-43bf-8d48-9112ac8c5942@github.com>

> JDK-8252870: Finalize (remove "incubator" from) jpackage

Andy Herrick has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:

 - Merge branch master into JDK-8252870
 - Merge branch 'master' into JDK-8252870
 - JDK-8252870: Finalize (remove "incubator" from) jpackage
     - reverting two auto-generated files, and changing module-info to "@since 16"
 - JDK-8252870: Finalize (remove "incubator" from) jpackage
   Merge branch 'finalize' into JDK-8252870
 - 8252869 Finalize (remove incubator from) jpackage (implementation)

-------------

Changes: https://git.openjdk.java.net/jdk/pull/633/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=633&range=03
  Stats: 1733 lines in 259 files changed: 692 ins; 701 del; 340 mod
  Patch: https://git.openjdk.java.net/jdk/pull/633.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/633/head:pull/633

PR: https://git.openjdk.java.net/jdk/pull/633

From kvn at openjdk.java.net  Wed Oct 21 20:16:16 2020
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 21 Oct 2020 20:16:16 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v7]
In-Reply-To: <7Dgp_C-H8LsbF3tPHinVmb5bT_LoLZLYZUx9eSqigCA=.894148e4-a3f2-42c3-ab19-13e134e66853@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <7Dgp_C-H8LsbF3tPHinVmb5bT_LoLZLYZUx9eSqigCA=.894148e4-a3f2-42c3-ab19-13e134e66853@github.com>
Message-ID: <9IvmeUEG1iYCXnh7wM4GcijH3T4tMI7XPrtrO1Wxm8M=.bc17c4ef-258a-4dc1-8001-a618e9596fd5@github.com>

On Wed, 21 Oct 2020 01:51:26 GMT, CoreyAshford <github.com+51754783+CoreyAshford at openjdk.org> wrote:

>> This patch set encompasses the following commits:
>> 
>> - Adds a new HotSpot intrinsic candidate to the java.lang.Base64 class - decodeBlock(), and provides a flexible API for the intrinsic.  The API is similar to the existing encodeBlock intrinsic.
>> - Adds the code in HotSpot to check and martial the new intrinsic's arguments to the arch-specific intrinsic implementation
>> - Adds a Power64LE-specific implementation of the decodeBlock intrinsic.
>> - Adds a JMH microbenchmark for both Base64 encoding and encoding.
>> - Enhances the JTReg hotspot intrinsic "TestBase64.java" regression test to more fully test both decoding and encoding.
>
> CoreyAshford has updated the pull request incrementally with one additional commit since the last revision:
> 
>   CheckGraalIntrinsics.java: fix copy/paste error

Changes requested by kvn (Reviewer).

test/hotspot/jtreg/compiler/intrinsics/base64/TestBase64.java line 29:

> 27:  * @summary tests java.util.Base64
> 28:  * @library /test/lib /
> 29:  * @build sun.hotspot.WhiteBox jdk.test.lib.Utils

Tier3 testing shows failures: java.lang.NoClassDefFoundError: jdk/test/lib/Platform
@iignatev pointed that you should not add jdk.test.lib.Utils to @build here - it will be built by jtreg in correct order.

-------------

PR: https://git.openjdk.java.net/jdk/pull/293

From psandoz at openjdk.java.net  Wed Oct 21 20:31:24 2020
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Wed, 21 Oct 2020 20:31:24 GMT
Subject: RFR: 8255022: Documentation missing for Vector API zero methods
 [v2]
In-Reply-To: <WKOOZsYoqfzmWyAfFbtHKUYgxax7JsQi3bn7IZ-R3D0=.76ad983a-e525-4f8c-a293-0ef3b4b7a987@github.com>
References: <WKOOZsYoqfzmWyAfFbtHKUYgxax7JsQi3bn7IZ-R3D0=.76ad983a-e525-4f8c-a293-0ef3b4b7a987@github.com>
Message-ID: <V2Fn1xLp1dtCIW7gQM53FDQtGmrSV0bQXYpt5WkoYdo=.f63f38d2-cdf7-4516-bc03-eab55a9859de@github.com>

> The zero methods on `IntVector` and all other specializations are missing documentation.

Paul Sandoz has updated the pull request incrementally with one additional commit since the last revision:

  Address CSR review.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/748/files
  - new: https://git.openjdk.java.net/jdk/pull/748/files/83639200..71d4e284

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=748&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=748&range=00-01

  Stats: 7 lines in 7 files changed: 0 ins; 0 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/748.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/748/head:pull/748

PR: https://git.openjdk.java.net/jdk/pull/748

From sviswanathan at openjdk.java.net  Wed Oct 21 20:33:21 2020
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Wed, 21 Oct 2020 20:33:21 GMT
Subject: RFR: 8255174: Vector API unit tests for missed public api code
 coverage
Message-ID: <plxBWyjKFaZlhHOumU8WGFasxfTyKDVHGcdi7uaw4xo=.35e1028d-b26c-47df-9a3f-e79d7a08d2fe@github.com>

Additional tests to increase Vector API public method code coverage to > 99%.

-------------

Commit messages:
 - 8255174: Vector API unit tests for missed public api code coverage

Changes: https://git.openjdk.java.net/jdk/pull/785/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=785&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8255174
  Stats: 19359 lines in 67 files changed: 19259 ins; 5 del; 95 mod
  Patch: https://git.openjdk.java.net/jdk/pull/785.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/785/head:pull/785

PR: https://git.openjdk.java.net/jdk/pull/785

From github.com+51754783+coreyashford at openjdk.java.net  Wed Oct 21 20:43:31 2020
From: github.com+51754783+coreyashford at openjdk.java.net (CoreyAshford)
Date: Wed, 21 Oct 2020 20:43:31 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v7]
In-Reply-To: <9IvmeUEG1iYCXnh7wM4GcijH3T4tMI7XPrtrO1Wxm8M=.bc17c4ef-258a-4dc1-8001-a618e9596fd5@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <7Dgp_C-H8LsbF3tPHinVmb5bT_LoLZLYZUx9eSqigCA=.894148e4-a3f2-42c3-ab19-13e134e66853@github.com>
 <9IvmeUEG1iYCXnh7wM4GcijH3T4tMI7XPrtrO1Wxm8M=.bc17c4ef-258a-4dc1-8001-a618e9596fd5@github.com>
Message-ID: <WIYa9Wl8UXjXSUNezAQjQeOVhcoZQA7zY8gDRcL90tA=.f8898c09-84e0-499d-a302-2e80e59f06a1@github.com>

On Wed, 21 Oct 2020 20:12:47 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> CoreyAshford has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   CheckGraalIntrinsics.java: fix copy/paste error
>
> test/hotspot/jtreg/compiler/intrinsics/base64/TestBase64.java line 29:
> 
>> 27:  * @summary tests java.util.Base64
>> 28:  * @library /test/lib /
>> 29:  * @build sun.hotspot.WhiteBox jdk.test.lib.Utils
> 
> Tier3 testing shows failures: java.lang.NoClassDefFoundError: jdk/test/lib/Platform
> @iignatev pointed that you should not add jdk.test.lib.Utils to @build here - it will be built by jtreg in correct order.

Done.  Thank you.

-------------

PR: https://git.openjdk.java.net/jdk/pull/293

From github.com+51754783+coreyashford at openjdk.java.net  Wed Oct 21 20:43:30 2020
From: github.com+51754783+coreyashford at openjdk.java.net (CoreyAshford)
Date: Wed, 21 Oct 2020 20:43:30 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v8]
In-Reply-To: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
Message-ID: <nU4nZ9oCthDEi7olxerj_bkmWuITInbbNzJKkb1shkY=.28b4ed81-9733-4981-b6fb-c8e4e3bd335e@github.com>

> This patch set encompasses the following commits:
> 
> - Adds a new HotSpot intrinsic candidate to the java.lang.Base64 class - decodeBlock(), and provides a flexible API for the intrinsic.  The API is similar to the existing encodeBlock intrinsic.
> - Adds the code in HotSpot to check and martial the new intrinsic's arguments to the arch-specific intrinsic implementation
> - Adds a Power64LE-specific implementation of the decodeBlock intrinsic.
> - Adds a JMH microbenchmark for both Base64 encoding and encoding.
> - Enhances the JTReg hotspot intrinsic "TestBase64.java" regression test to more fully test both decoding and encoding.

CoreyAshford has updated the pull request incrementally with one additional commit since the last revision:

  TestBase64.java: remove jdk.test.lib.Utils from @build which was causing Tier3 failures.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/293/files
  - new: https://git.openjdk.java.net/jdk/pull/293/files/f93614dc..8e15d971

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=293&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=293&range=06-07

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/293.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/293/head:pull/293

PR: https://git.openjdk.java.net/jdk/pull/293

From naoto at openjdk.java.net  Wed Oct 21 20:47:21 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 21 Oct 2020 20:47:21 GMT
Subject: RFR: 8255086: JRE country and region name may be the latest
Message-ID: <uH47zot061i3hNhl6lics05j6VFUmcpjcDFFz6PoY2U=.2e818daf-dfc7-4868-b049-31079ba56c23@github.com>

Hi,

Please review the changes to the subject issue. The fix replaces the obsolete/incorrect English language/region/script display names in the COMPAT root locale bundle. The data are derived from CLDR's English names.

-------------

Commit messages:
 - 8255086: JRE country and region name may be the latest

Changes: https://git.openjdk.java.net/jdk/pull/786/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=786&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8255086
  Stats: 234 lines in 5 files changed: 111 ins; 0 del; 123 mod
  Patch: https://git.openjdk.java.net/jdk/pull/786.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/786/head:pull/786

PR: https://git.openjdk.java.net/jdk/pull/786

From kvn at openjdk.java.net  Wed Oct 21 21:02:17 2020
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 21 Oct 2020 21:02:17 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v7]
In-Reply-To: <9IvmeUEG1iYCXnh7wM4GcijH3T4tMI7XPrtrO1Wxm8M=.bc17c4ef-258a-4dc1-8001-a618e9596fd5@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <7Dgp_C-H8LsbF3tPHinVmb5bT_LoLZLYZUx9eSqigCA=.894148e4-a3f2-42c3-ab19-13e134e66853@github.com>
 <9IvmeUEG1iYCXnh7wM4GcijH3T4tMI7XPrtrO1Wxm8M=.bc17c4ef-258a-4dc1-8001-a618e9596fd5@github.com>
Message-ID: <edmlYRa4ZyscOlZGqCNO4g5y35-9kRX5UiJLDiaQrf4=.77a4616f-035b-40c1-bc6d-86b504199079@github.com>

On Wed, 21 Oct 2020 20:12:55 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> CoreyAshford has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   CheckGraalIntrinsics.java: fix copy/paste error
>
> Changes requested by kvn (Reviewer).

Note, tier1 and tier2 passed clean. But I have to rebuild it with updated test and run tier3 again.
CheckGraalIntrinsics.java passed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/293

From darcy at openjdk.java.net  Wed Oct 21 22:33:12 2020
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 21 Oct 2020 22:33:12 GMT
Subject: RFR: 8255022: Documentation missing for Vector API zero methods
 [v2]
In-Reply-To: <V2Fn1xLp1dtCIW7gQM53FDQtGmrSV0bQXYpt5WkoYdo=.f63f38d2-cdf7-4516-bc03-eab55a9859de@github.com>
References: <WKOOZsYoqfzmWyAfFbtHKUYgxax7JsQi3bn7IZ-R3D0=.76ad983a-e525-4f8c-a293-0ef3b4b7a987@github.com>
 <V2Fn1xLp1dtCIW7gQM53FDQtGmrSV0bQXYpt5WkoYdo=.f63f38d2-cdf7-4516-bc03-eab55a9859de@github.com>
Message-ID: <uH2HuziVKnwRmZCa2VhmxE5Uu60U6Ppp7vRzhWq05MY=.829c94f0-4b2e-4a2e-8310-393240a62ae1@github.com>

On Wed, 21 Oct 2020 20:31:24 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> The zero methods on `IntVector` and all other specializations are missing documentation.
>
> Paul Sandoz has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address CSR review.

Marked as reviewed by darcy (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/748

From psandoz at openjdk.java.net  Wed Oct 21 22:33:13 2020
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Wed, 21 Oct 2020 22:33:13 GMT
Subject: Integrated: 8255022: Documentation missing for Vector API zero methods
In-Reply-To: <WKOOZsYoqfzmWyAfFbtHKUYgxax7JsQi3bn7IZ-R3D0=.76ad983a-e525-4f8c-a293-0ef3b4b7a987@github.com>
References: <WKOOZsYoqfzmWyAfFbtHKUYgxax7JsQi3bn7IZ-R3D0=.76ad983a-e525-4f8c-a293-0ef3b4b7a987@github.com>
Message-ID: <MifY7389aMDIcPjlpYrUUM7ngbxAw-BGq1LzOZn4cjE=.cfdfe3b3-2af6-4e6a-aba4-e6250fdc39c0@github.com>

On Mon, 19 Oct 2020 19:43:13 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> The zero methods on `IntVector` and all other specializations are missing documentation.

This pull request has now been integrated.

Changeset: 60d3fa2e
Author:    Paul Sandoz <psandoz at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/60d3fa2e
Stats:     42 lines in 7 files changed: 35 ins; 0 del; 7 mod

8255022: Documentation missing for Vector API zero methods

Reviewed-by: vlivanov, darcy

-------------

PR: https://git.openjdk.java.net/jdk/pull/748

From bchristi at openjdk.java.net  Wed Oct 21 23:05:11 2020
From: bchristi at openjdk.java.net (Brent Christian)
Date: Wed, 21 Oct 2020 23:05:11 GMT
Subject: RFR: 8255086: JRE country and region name may be the latest
In-Reply-To: <uH47zot061i3hNhl6lics05j6VFUmcpjcDFFz6PoY2U=.2e818daf-dfc7-4868-b049-31079ba56c23@github.com>
References: <uH47zot061i3hNhl6lics05j6VFUmcpjcDFFz6PoY2U=.2e818daf-dfc7-4868-b049-31079ba56c23@github.com>
Message-ID: <2LUYLa3MK34hhuxUJT287iBxKUQuWKw8dkKAhHbR_1k=.d933c110-ea7c-4447-beed-9013b26023f4@github.com>

On Wed, 21 Oct 2020 20:39:18 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Hi,
> 
> Please review the changes to the subject issue. The fix replaces the obsolete/incorrect English language/region/script display names in the COMPAT root locale bundle. The data are derived from CLDR's English names.

Hi, Naoto

What is the source for the updated values in LocaleNames.properties?

Also, could the bug synopsis be updated to be more descriptive?

Thanks,
-Brent

-------------

PR: https://git.openjdk.java.net/jdk/pull/786

From almatvee at openjdk.java.net  Wed Oct 21 23:18:13 2020
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Wed, 21 Oct 2020 23:18:13 GMT
Subject: RFR: 8232024: Don't pollute log output with multiple errors of
 the same type
In-Reply-To: <fSuDEsw79XKdiuGVdVUS8LOVX0tPdqLAjyKstTOi1xE=.471b5e5a-98b7-4bfc-a284-5adc0dc702a3@github.com>
References: <fSuDEsw79XKdiuGVdVUS8LOVX0tPdqLAjyKstTOi1xE=.471b5e5a-98b7-4bfc-a284-5adc0dc702a3@github.com>
Message-ID: <N6g6Vnxj1y0lN3p3kUHGIJ45EQTxRvNx8lpdTPOKkL8=.a421bede-7a67-4087-9191-5ca0eafa979e@github.com>

On Wed, 21 Oct 2020 17:03:33 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Don't run ldd and build list of dependency packages in case jpackage builds DEB package on non Debian Linux and RPM on Debian Linux. In this cases attempts to detect what packages provide libs will fail anyways, so don't waste time and pollute jpackage log output.

Marked as reviewed by almatvee (Committer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/784

From naoto at openjdk.java.net  Wed Oct 21 23:19:10 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 21 Oct 2020 23:19:10 GMT
Subject: RFR: 8255086: Update the root locale display names
In-Reply-To: <2LUYLa3MK34hhuxUJT287iBxKUQuWKw8dkKAhHbR_1k=.d933c110-ea7c-4447-beed-9013b26023f4@github.com>
References: <uH47zot061i3hNhl6lics05j6VFUmcpjcDFFz6PoY2U=.2e818daf-dfc7-4868-b049-31079ba56c23@github.com>
 <2LUYLa3MK34hhuxUJT287iBxKUQuWKw8dkKAhHbR_1k=.d933c110-ea7c-4447-beed-9013b26023f4@github.com>
Message-ID: <pdODfu52gmVdC2jXwHb86VnMcej_b-9MakJIccha34o=.ad6d2e10-8a97-4db4-af43-d51242453f44@github.com>

On Wed, 21 Oct 2020 23:01:59 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Hi,
>> 
>> Please review the changes to the subject issue. The fix replaces the obsolete/incorrect English language/region/script display names in the COMPAT root locale bundle. The data are derived from CLDR's English names.
>
> Hi, Naoto
> 
> What is the source for the updated values in LocaleNames.properties?
> 
> Also, could the bug synopsis be updated to be more descriptive?
> 
> Thanks,
> -Brent

Hi Brent,

> What is the source for the updated values in LocaleNames.properties?

The source is CLDR v37, which is currently used in the latest JDK release. They are extracted with a code snippet (https://bugs.openjdk.java.net/browse/JDK-8255086?focusedCommentId=14375906&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14375906), and non-ASCII chars are Unicode escaped.

> Also, could the bug synopsis be updated to be more descriptive?

Modified the synopsis. Hope it made sense.

Naoto

-------------

PR: https://git.openjdk.java.net/jdk/pull/786

From naoto at openjdk.java.net  Wed Oct 21 23:38:23 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 21 Oct 2020 23:38:23 GMT
Subject: RFR: 8255086: Update the root locale display names [v2]
In-Reply-To: <uH47zot061i3hNhl6lics05j6VFUmcpjcDFFz6PoY2U=.2e818daf-dfc7-4868-b049-31079ba56c23@github.com>
References: <uH47zot061i3hNhl6lics05j6VFUmcpjcDFFz6PoY2U=.2e818daf-dfc7-4868-b049-31079ba56c23@github.com>
Message-ID: <2PX_Zdi3XUq7NpyYH_jKHXGFiPotGnfVqqXQ-WymQDQ=.e91f960a-8d98-4ac7-a3d1-39e1cd1b594b@github.com>

> Hi,
> 
> Please review the changes to the subject issue. The fix replaces the obsolete/incorrect English language/region/script display names in the COMPAT root locale bundle. The data are derived from CLDR's English names.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Put a newline at the end.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/786/files
  - new: https://git.openjdk.java.net/jdk/pull/786/files/5ccc2bdb..17054a4e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=786&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=786&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/786.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/786/head:pull/786

PR: https://git.openjdk.java.net/jdk/pull/786

From fyang at openjdk.java.net  Wed Oct 21 23:42:33 2020
From: fyang at openjdk.java.net (Fei Yang)
Date: Wed, 21 Oct 2020 23:42:33 GMT
Subject: RFR: 8252204: AArch64: Implement SHA3 accelerator/intrinsic [v11]
In-Reply-To: <PJVtIubjiGKhCK81PIMhWuYxnR84DNieMDUGHdhHYZM=.ad903c93-c5e3-4614-9af1-d36bc33f735d@github.com>
References: <PJVtIubjiGKhCK81PIMhWuYxnR84DNieMDUGHdhHYZM=.ad903c93-c5e3-4614-9af1-d36bc33f735d@github.com>
Message-ID: <Nj0NeiomqIUICAlQlodWtRldTaZ5XTx-pgukmHPEOF4=.6e719a28-7d0e-4382-935d-2547308c2471@github.com>

> Contributed-by: ard.biesheuvel at linaro.org, dongbo4 at huawei.com
> 
> This added an intrinsic for SHA3 using aarch64 v8.2 SHA3 Crypto Extensions.
> Reference implementation for core SHA-3 transform using ARMv8.2 Crypto Extensions:
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm64/crypto/sha3-ce-core.S?h=v5.4.52
> 
> Trivial adaptation in SHA3. implCompress is needed for the purpose of adding the intrinsic.
> For SHA3, we need to pass one extra parameter "digestLength" to the stub for the calculation of block size.
> "digestLength" is also used in for the EOR loop before keccak to differentiate different SHA3 variants.
> 
> We added jtreg tests for SHA3 and used QEMU system emulator which supports SHA3 instructions to test the functionality.
> Patch passed jtreg tier1-3 tests with QEMU system emulator.
> Also verified with jtreg tier1-3 tests without SHA3 instructions on aarch64-linux-gnu and x86_64-linux-gnu, to make sure that there's no regression.
> 
> We used one existing JMH test for performance test: test/micro/org/openjdk/bench/java/security/MessageDigests.java
> We measured the performance benefit with an aarch64 cycle-accurate simulator.
> Patch delivers 20% - 40% performance improvement depending on specific SHA3 digest length and size of the message.
> 
> For now, this feature will not be enabled automatically for aarch64. We can auto-enable this when it is fully tested on real hardware.  But for the above testing purposes, this is auto-enabled when the corresponding hardware feature is detected.

Fei Yang has updated the pull request incrementally with one additional commit since the last revision:

  Add if (isJDK16OrHigher()) check for SHA3 in CheckGraalIntrinsics.java

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/207/files
  - new: https://git.openjdk.java.net/jdk/pull/207/files/d32c8ad7..b43f9197

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=207&range=10
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=207&range=09-10

  Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/207.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/207/head:pull/207

PR: https://git.openjdk.java.net/jdk/pull/207

From psandoz at openjdk.java.net  Wed Oct 21 23:59:10 2020
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Wed, 21 Oct 2020 23:59:10 GMT
Subject: RFR: 8255174: Vector API unit tests for missed public api code
 coverage
In-Reply-To: <plxBWyjKFaZlhHOumU8WGFasxfTyKDVHGcdi7uaw4xo=.35e1028d-b26c-47df-9a3f-e79d7a08d2fe@github.com>
References: <plxBWyjKFaZlhHOumU8WGFasxfTyKDVHGcdi7uaw4xo=.35e1028d-b26c-47df-9a3f-e79d7a08d2fe@github.com>
Message-ID: <wTt3V8tzvtUlJmWIKPcv4kRdvolTabOEek7hb2BhlgM=.f9186460-6059-4152-9d83-4f483d130730@github.com>

On Wed, 21 Oct 2020 20:17:32 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

> Additional tests to increase Vector API public method code coverage to > 99%.

I already reviewed these test updates when integrated into the `vectorIntrinsics` branch of the `panama-vector` repository.

-------------

Marked as reviewed by psandoz (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/785

From sviswanathan at openjdk.java.net  Thu Oct 22 00:15:19 2020
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Thu, 22 Oct 2020 00:15:19 GMT
Subject: Integrated: 8255174: Vector API unit tests for missed public api code
 coverage
In-Reply-To: <plxBWyjKFaZlhHOumU8WGFasxfTyKDVHGcdi7uaw4xo=.35e1028d-b26c-47df-9a3f-e79d7a08d2fe@github.com>
References: <plxBWyjKFaZlhHOumU8WGFasxfTyKDVHGcdi7uaw4xo=.35e1028d-b26c-47df-9a3f-e79d7a08d2fe@github.com>
Message-ID: <qWZkDKBaF7TKpWlF5wUhpptAZ69Sa0WSwd_3K2REzNI=.59e4e415-52b8-4d53-a9d0-305dfa31bd76@github.com>

On Wed, 21 Oct 2020 20:17:32 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

> Additional tests to increase Vector API public method code coverage to > 99%.

This pull request has now been integrated.

Changeset: 5d262290
Author:    Sandhya Viswanathan <sviswanathan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/5d262290
Stats:     19359 lines in 67 files changed: 19259 ins; 5 del; 95 mod

8255174: Vector API unit tests for missed public api code coverage

Reviewed-by: psandoz

-------------

PR: https://git.openjdk.java.net/jdk/pull/785

From mchung at openjdk.java.net  Thu Oct 22 00:28:11 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Thu, 22 Oct 2020 00:28:11 GMT
Subject: RFR: 8159746: (proxy) Support for default methods
In-Reply-To: <yzFe02HJ2qt5tT8tY9ZOofnKld93x1PM5U7AToTABJs=.439c213b-94b9-488f-bb6d-a835a86c527f@github.com>
References: <kw2VXh3vTFf1zgfd4biXA41OKffZ5oU7KT23tXAxgUA=.bcf14ffc-4dba-4c9c-8754-184172c5acbd@github.com>
 <U-6RiCpFVIrhLztPN6opiPcpFtxValDzU-K7WWFZM-4=.6bc8aaa4-636a-4664-b380-4c4af00513bd@github.com>
 <-cLIJ8pFHtnNoJMHV3aXI7XMJWp4Jrutc8Xn5PG0OK8=.d2cd87ab-3592-4524-ad85-05444c43689b@github.com>
 <r0UK2qjnmgeTNDDSWaSLPAj3QRgx_4YB82ielllO7jM=.fa615bc0-db49-4a74-b842-793f8f5209bb@github.com>
 <1T8kXDZN1bhHr4c8v4SQsImeBySCqTfX-u3_jzvyocA=.b4957400-9a33-4b6e-8475-329642a5888c@github.com>
 <XIux-dY0JXHRafHk48kVNXId9r-HSceNSytBojDxelY=.872e74cb-b064-406e-b71f-13c90ec7fbbc@github.com>
 <j4t2vT0SnwnU7lhKRlXtk967d-K6nA0EqHrqNbba7W0=.dc05dba6-bf7e-4606-8a02-9c2bad4b3b58@github.com>
 <fmVtPcBdgMuZOPm2qx3Q3znVZM7JgQPkhPAVLtwkOhE=.2d8b8447-cfae-4cb3-9a7c-6567a881231f@github.com>
 <GSeWP29fAIUFSk0CYsC557w52CuLqeUWwHNK9maltwI=.3d5f002e-6b74-4a57-a5d8-244d27da9dde@github.com>
 <GF8iEOkMUEL2dYB0HytFIc9gyeeUJ_KP0ImlqFsul2Y=.894afc05-9310-43e1-a308-8f7d71dc572b@github.com>
 <HvtDex3cmiv7XeTMITOroYfu74amSGQavQ_
 BAmVzmXw=.223be989-7c20-4ba4-ac0d-013d2b75a8cb@github.com>
 <IqRiLphFPBpGiKAnMJXqxjie9YeZ03rcE-qG1s92BLw=.d4fd5e92-5067-40df-8a0b-1dfd3d6e23af@github.com>
 <Y0hE51G3YefI6NY1O_E6VoZSKwxE78S1hv6fEatmOG8=.0a2c686c-d9ad-418c-8c1b-49addb8a54b1@github.com>
 <QrNk57L2PWQhJjzYiGTsvYyGIPAfK7bP_kANtTR-2uM=.3e5ce990-f8ea-4751-8147-27a8a9dad40d@github.com>
 <9JNNUzfV3PSvKtSg2a_zyYJmgEn3sZL9cb5sfqemk2o=.f1ef7fb7-bdd5-44ed-98c8-59213e9094f9@github.com>
 <zWGhaC8YB5I0XgffiR7o_YT5gSp9Gbj8Drtt23brl-c=.1e59f0e4-bbe3-4fb2-94dc-c55fc862f091@github.com>
 <LljojgqBhEi6tFptsbmu1jS-Xx7lYEXm9tRkkPqDGzE=.3d7d6a37-1042-4539-88d1-9f4cf5378128@github.com>
 <Gn33ydZNxqOpWUrmYiWJadMF0mukI2MR85EtgrV4D1I=.958521f2-1167-4a68-b513-e10bba37ae18@github.com>
 <NMXKaHql9XjndqPgyoN1Lasa9H8ugl8-ltD1j2XiT9Y=.3ff8871e-0f9d-40ea-8f35-e804a9afcbd5@github.com>
 <yzFe02HJ2qt5tT8tY9ZOofnKld93x1PM5U7AToTABJs=.439c213b-94b9-488f-bb6d-a835a86c527f@github.com>
Message-ID: <BoATjx7PPcLpINJVC5HM77UKMriIUqnnhcBowkJRlvM=.1221e3e1-ed27-4618-8365-dcd903d27f60@github.com>

On Tue, 20 Oct 2020 23:42:31 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Hi Mandy,
>> 
>> You're right. I haven't thought of what one can do with a Lookup for one proxy class when other proxy classes are co-located in the same module and/or package. So instead of a Lookup, we could use some other more targeted "capability". Here's alternative API no.2 that uses special SuperInvoker callback interface passed as argument to invocation handler:
>> 
>> https://github.com/mlchung/jdk/pull/4
>> 
>> Each proxy class has its own SuperInvoker instance, assigned to static final field of generated proxy class like Method objects, which is passed to invocation handler in the same way as the selected Method object. Invocation handler can use this SuperInvoker instance to invoke the super default method on the proxy. SuperInvoker can verify that the passed-in proxy is of the correct class very quickly. Also the cache of transformed method handles per Method is embedded in the SuperInvoker itself instead of using ClassValue to hold it, so overhead for super invocations is further reduced:
>> 
>> Mandy's original:
>> 
>> Benchmark             Mode  Cnt    Score    Error  Units
>> ProxyBench.implClass  avgt    5    3.709 ?  0.026  ns/op
>> ProxyBench.implProxy  avgt    5  926.215 ? 11.835  ns/op
>> 
>> 
>> Peter's performance patch:
>> 
>> Benchmark             Mode  Cnt   Score   Error  Units
>> ProxyBench.implClass  avgt    5   3.777 ? 0.005  ns/op
>> ProxyBench.implProxy  avgt    5  27.579 ? 0.250  ns/op
>> 
>> 
>> Static method moved to InvocationHandler + added access check
>> 
>> Benchmark               Mode  Cnt    Score   Error  Units
>> ProxyBench.implClass    avgt    5    3.740 ? 0.004  ns/op
>> ProxyBench.implProxy    avgt    5   34.226 ? 0.125  ns/op
>> ProxyBench.ppImplClass  avgt    5    3.780 ? 0.004  ns/op
>> ProxyBench.ppImplProxy  avgt    5  147.318 ? 1.422  ns/op
>> 
>> 
>> Alternative API #1 with access check in newProxyInstance and Lookup parameter
>> 
>> Benchmark               Mode  Cnt   Score   Error  Units
>> ProxyBench.implClass    avgt    5   3.782 ? 0.013  ns/op
>> ProxyBench.implProxy    avgt    5  32.493 ? 0.192  ns/op
>> ProxyBench.ppImplClass  avgt    5   3.749 ? 0.002  ns/op
>> ProxyBench.ppImplProxy  avgt    5  30.565 ? 0.190  ns/op
>> 
>> 
>> Alternative API #2 with SuperInvoker parameter
>> 
>> Benchmark               Mode  Cnt   Score   Error  Units
>> ProxyBench.implClass    avgt    5   3.777 ? 0.003  ns/op
>> ProxyBench.implProxy    avgt    5  20.282 ? 0.585  ns/op
>> ProxyBench.ppImplClass  avgt    5   3.752 ? 0.002  ns/op
>> ProxyBench.ppImplProxy  avgt    5  19.790 ? 0.335  ns/op
>> 
>> So what do you think about this one?
>
> Hi Peter, thanks for coming with these alternatives.   The need for new `InvocationHandler2` and `InvocationHandler2.SuperInvoker` APIs and the complexity of `plevart:proxy-default-method-alt-api2` look unpleasing in order to keep the invocation of default methods in lambdas.  I prefer the `DelegatingInvocationHandler` abstract class approach without caller-sensitive method.

Hi Peter, Alan

I have prototyped two alternatives ([mlchung:proxy-default-method-3](https://github.com/mlchung/jdk/tree/proxy-default-method-3)).
1. `DelegatingInvocationHandler` abstract class with:
protected final Object invokeDefault(Object proxy, Method method, Object... params)

2. `NewInvocationHandler` functional interface
    public Object invoke(DefaultMethodInvoker invoker, Object proxy, Method method, Object... args) throws Throwable;

    /**
     * {@inheritDoc}
     */
    public default Object invoke(Object proxy, Method method, Object[] args)
            throws Throwable
    {
         return invoke(DefaultMethodInvoker.getInvoker(proxy, this), proxy, method, args);
    }

   public final class DefaultMethodInvoker {
        public final Object invoke(Object proxy, Method method, Object... args)
                throws InvocationTargetException
   }

Similar idea as yours SuperInvoker.  But I think this is less complicated
and DefaultMethodInvoker is a final class rather than an interface.
The generated proxy class will keep invoking `InvocationHandler::invoke`
(no change in `ProxyGenerator`).  `NewInvocationHandler` allows the use of lambdas.

I like `DelegatingInvocationHandler` which is simple and clean but not
a functional interface.   `NewInvocationHandler` is a functional interface
with the need of `DefaultMethodInvoker` to bridge between an invocation
handler and an accessed check proxy object.

Thoughts?  I'm leaning toward `DelegatingInvocationHandler`.  

We need to decide on the exception if access checks fails on
`Proxy::newProxyInstance` and  `Proxy::getInvocationHandler` 
if the invocation handler needs the ability to invoke default
methods.

-------------

PR: https://git.openjdk.java.net/jdk/pull/313

From fyang at openjdk.java.net  Thu Oct 22 00:49:12 2020
From: fyang at openjdk.java.net (Fei Yang)
Date: Thu, 22 Oct 2020 00:49:12 GMT
Subject: RFR: 8252204: AArch64: Implement SHA3 accelerator/intrinsic [v10]
In-Reply-To: <06kvIM_3abB-35pPdgFfbvwCND6oe9QCBqXBQ8iIrZ4=.64ae7da4-be02-46cc-afde-ffeb9ec9d703@github.com>
References: <PJVtIubjiGKhCK81PIMhWuYxnR84DNieMDUGHdhHYZM=.ad903c93-c5e3-4614-9af1-d36bc33f735d@github.com>
 <kIpiKx8ovndJoa7alAki42vJ4H2lBJ4wN7MFqH5MORg=.57966a12-aa0c-40fb-815b-8bec9c7e8eda@github.com>
 <BtDcca4uUEPGQRwcPjA_ckSsCEX7u_chBB7Qe6P6Wp8=.40f38c07-d6db-41f2-bfa4-a7df321786f2@github.com>
 <Z8q57lCaAf6SukMKsmGpsr6TRJgGa4123VsAvrchYKA=.72dfc784-0637-4dbc-97e6-07efad147ebe@github.com>
 <06kvIM_3abB-35pPdgFfbvwCND6oe9QCBqXBQ8iIrZ4=.64ae7da4-be02-46cc-afde-ffeb9ec9d703@github.com>
Message-ID: <DvtQjTiY5jJf15l7TSgKFjQg74cSvnCdqXICYjjU_b8=.29818ac1-7849-448a-b09a-adf901be6ac5@github.com>

On Wed, 21 Oct 2020 19:20:28 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> OK.  Will update with the following change after Aleksey's PR is integrated:
>> 
>> --- a/src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/CheckGraalIntrinsics.java
>> +++ b/src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/CheckGraalIntrinsics.java
>> @@ -608,6 +608,10 @@ public class CheckGraalIntrinsics extends GraalTest {
>>          if (!config.useSHA512Intrinsics()) {
>>              add(ignore, "sun/security/provider/SHA5." + shaCompressName + "([BI)V");
>>          }
>> +
>> +        if (isJDK16OrHigher()) {
>> +            add(toBeInvestigated, "sun/security/provider/SHA3." + shaCompressName + "([BI)V");
>> +        }
>>      }
>
> Yes, please, do that.

Done.
Commit: https://github.com/openjdk/jdk/pull/207/commits/b43f91970d44e6e0c1b3b4ef452ec388ecbecb83
I think this will not conflict with Aleksey's PR as we modify in different places of CheckGraalIntrinsics.java

-------------

PR: https://git.openjdk.java.net/jdk/pull/207

From kvn at openjdk.java.net  Thu Oct 22 01:40:16 2020
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Thu, 22 Oct 2020 01:40:16 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v8]
In-Reply-To: <nU4nZ9oCthDEi7olxerj_bkmWuITInbbNzJKkb1shkY=.28b4ed81-9733-4981-b6fb-c8e4e3bd335e@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <nU4nZ9oCthDEi7olxerj_bkmWuITInbbNzJKkb1shkY=.28b4ed81-9733-4981-b6fb-c8e4e3bd335e@github.com>
Message-ID: <Gg-5_9T1MzupwVDyJK1s1yg0od6jHm_OLvKtUFjNQuU=.2179a204-620f-459e-af99-37c4f664c348@github.com>

On Wed, 21 Oct 2020 20:43:30 GMT, CoreyAshford <github.com+51754783+CoreyAshford at openjdk.org> wrote:

>> This patch set encompasses the following commits:
>> 
>> - Adds a new HotSpot intrinsic candidate to the java.lang.Base64 class - decodeBlock(), and provides a flexible API for the intrinsic.  The API is similar to the existing encodeBlock intrinsic.
>> - Adds the code in HotSpot to check and martial the new intrinsic's arguments to the arch-specific intrinsic implementation
>> - Adds a Power64LE-specific implementation of the decodeBlock intrinsic.
>> - Adds a JMH microbenchmark for both Base64 encoding and encoding.
>> - Enhances the JTReg hotspot intrinsic "TestBase64.java" regression test to more fully test both decoding and encoding.
>
> CoreyAshford has updated the pull request incrementally with one additional commit since the last revision:
> 
>   TestBase64.java: remove jdk.test.lib.Utils from @build which was causing Tier3 failures.

Tier3 testing clean with updated test.

-------------

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/293

From github.com+51754783+coreyashford at openjdk.java.net  Thu Oct 22 03:46:16 2020
From: github.com+51754783+coreyashford at openjdk.java.net (CoreyAshford)
Date: Thu, 22 Oct 2020 03:46:16 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v8]
In-Reply-To: <Gg-5_9T1MzupwVDyJK1s1yg0od6jHm_OLvKtUFjNQuU=.2179a204-620f-459e-af99-37c4f664c348@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <nU4nZ9oCthDEi7olxerj_bkmWuITInbbNzJKkb1shkY=.28b4ed81-9733-4981-b6fb-c8e4e3bd335e@github.com>
 <Gg-5_9T1MzupwVDyJK1s1yg0od6jHm_OLvKtUFjNQuU=.2179a204-620f-459e-af99-37c4f664c348@github.com>
Message-ID: <_DbhZNXM5Jq69gF-xg91xtj6ctkRAiltu0TRJK-SN98=.acafc7c4-971b-47a7-8051-9ae94071139a@github.com>

On Thu, 22 Oct 2020 01:36:59 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Tier3 testing clean with updated test.

Thank you for identifying the problem, the fix, then rebuilding and rerunning the tests!

-------------

PR: https://git.openjdk.java.net/jdk/pull/293

From kvn at openjdk.java.net  Thu Oct 22 04:02:15 2020
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Thu, 22 Oct 2020 04:02:15 GMT
Subject: RFR: 8252204: AArch64: Implement SHA3 accelerator/intrinsic [v11]
In-Reply-To: <Nj0NeiomqIUICAlQlodWtRldTaZ5XTx-pgukmHPEOF4=.6e719a28-7d0e-4382-935d-2547308c2471@github.com>
References: <PJVtIubjiGKhCK81PIMhWuYxnR84DNieMDUGHdhHYZM=.ad903c93-c5e3-4614-9af1-d36bc33f735d@github.com>
 <Nj0NeiomqIUICAlQlodWtRldTaZ5XTx-pgukmHPEOF4=.6e719a28-7d0e-4382-935d-2547308c2471@github.com>
Message-ID: <fIPQnjwS25vR5TPsG-P30IrVShbwlaSk9F8qpqghFOk=.87e80a49-fdf7-4f55-8447-dbcd62a1d828@github.com>

On Wed, 21 Oct 2020 23:42:33 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Contributed-by: ard.biesheuvel at linaro.org, dongbo4 at huawei.com
>> 
>> This added an intrinsic for SHA3 using aarch64 v8.2 SHA3 Crypto Extensions.
>> Reference implementation for core SHA-3 transform using ARMv8.2 Crypto Extensions:
>> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm64/crypto/sha3-ce-core.S?h=v5.4.52
>> 
>> Trivial adaptation in SHA3. implCompress is needed for the purpose of adding the intrinsic.
>> For SHA3, we need to pass one extra parameter "digestLength" to the stub for the calculation of block size.
>> "digestLength" is also used in for the EOR loop before keccak to differentiate different SHA3 variants.
>> 
>> We added jtreg tests for SHA3 and used QEMU system emulator which supports SHA3 instructions to test the functionality.
>> Patch passed jtreg tier1-3 tests with QEMU system emulator.
>> Also verified with jtreg tier1-3 tests without SHA3 instructions on aarch64-linux-gnu and x86_64-linux-gnu, to make sure that there's no regression.
>> 
>> We used one existing JMH test for performance test: test/micro/org/openjdk/bench/java/security/MessageDigests.java
>> We measured the performance benefit with an aarch64 cycle-accurate simulator.
>> Patch delivers 20% - 40% performance improvement depending on specific SHA3 digest length and size of the message.
>> 
>> For now, this feature will not be enabled automatically for aarch64. We can auto-enable this when it is fully tested on real hardware.  But for the above testing purposes, this is auto-enabled when the corresponding hardware feature is detected.
>
> Fei Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add if (isJDK16OrHigher()) check for SHA3 in CheckGraalIntrinsics.java

tier1,2,3 passed. I verified that new SHA3 tests were run and passed.
But because SHA3 is not enabled for now (even on aarch64), it does not test asm code.
At least testing verified that changes in shared code does not cause any issues.

-------------

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/207

From fyang at openjdk.java.net  Thu Oct 22 04:23:11 2020
From: fyang at openjdk.java.net (Fei Yang)
Date: Thu, 22 Oct 2020 04:23:11 GMT
Subject: RFR: 8252204: AArch64: Implement SHA3 accelerator/intrinsic [v11]
In-Reply-To: <fIPQnjwS25vR5TPsG-P30IrVShbwlaSk9F8qpqghFOk=.87e80a49-fdf7-4f55-8447-dbcd62a1d828@github.com>
References: <PJVtIubjiGKhCK81PIMhWuYxnR84DNieMDUGHdhHYZM=.ad903c93-c5e3-4614-9af1-d36bc33f735d@github.com>
 <Nj0NeiomqIUICAlQlodWtRldTaZ5XTx-pgukmHPEOF4=.6e719a28-7d0e-4382-935d-2547308c2471@github.com>
 <fIPQnjwS25vR5TPsG-P30IrVShbwlaSk9F8qpqghFOk=.87e80a49-fdf7-4f55-8447-dbcd62a1d828@github.com>
Message-ID: <zAVeB5gU7IpeUmcS7CTQfUgkMKblpYSCeG44emXVr9Q=.aec6cd72-e6ae-404c-9f99-e37dbfc8f1a6@github.com>

On Thu, 22 Oct 2020 03:59:45 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> tier1,2,3 passed. I verified that new SHA3 tests were run and passed.
> But because SHA3 is not enabled for now (even on aarch64), it does not test asm code.
> At least testing verified that changes in shared code does not cause any issues.

Great to hear that :-)
Thanks for the effect.
With that testing result and reviewing from three reviewers, I think it's safe to integrate.

-------------

PR: https://git.openjdk.java.net/jdk/pull/207

From fyang at openjdk.java.net  Thu Oct 22 04:44:21 2020
From: fyang at openjdk.java.net (Fei Yang)
Date: Thu, 22 Oct 2020 04:44:21 GMT
Subject: Integrated: 8252204: AArch64: Implement SHA3 accelerator/intrinsic
In-Reply-To: <PJVtIubjiGKhCK81PIMhWuYxnR84DNieMDUGHdhHYZM=.ad903c93-c5e3-4614-9af1-d36bc33f735d@github.com>
References: <PJVtIubjiGKhCK81PIMhWuYxnR84DNieMDUGHdhHYZM=.ad903c93-c5e3-4614-9af1-d36bc33f735d@github.com>
Message-ID: <GLmkvEOYPr6Twi3lsB25Lsz7AwDH52C_A_sP1O2hS7M=.5dc3e28a-d91e-47e5-a590-09d0a5701241@github.com>

On Wed, 16 Sep 2020 16:36:54 GMT, Fei Yang <fyang at openjdk.org> wrote:

> Contributed-by: ard.biesheuvel at linaro.org, dongbo4 at huawei.com
> 
> This added an intrinsic for SHA3 using aarch64 v8.2 SHA3 Crypto Extensions.
> Reference implementation for core SHA-3 transform using ARMv8.2 Crypto Extensions:
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm64/crypto/sha3-ce-core.S?h=v5.4.52
> 
> Trivial adaptation in SHA3. implCompress is needed for the purpose of adding the intrinsic.
> For SHA3, we need to pass one extra parameter "digestLength" to the stub for the calculation of block size.
> "digestLength" is also used in for the EOR loop before keccak to differentiate different SHA3 variants.
> 
> We added jtreg tests for SHA3 and used QEMU system emulator which supports SHA3 instructions to test the functionality.
> Patch passed jtreg tier1-3 tests with QEMU system emulator.
> Also verified with jtreg tier1-3 tests without SHA3 instructions on aarch64-linux-gnu and x86_64-linux-gnu, to make sure that there's no regression.
> 
> We used one existing JMH test for performance test: test/micro/org/openjdk/bench/java/security/MessageDigests.java
> We measured the performance benefit with an aarch64 cycle-accurate simulator.
> Patch delivers 20% - 40% performance improvement depending on specific SHA3 digest length and size of the message.
> 
> For now, this feature will not be enabled automatically for aarch64. We can auto-enable this when it is fully tested on real hardware.  But for the above testing purposes, this is auto-enabled when the corresponding hardware feature is detected.

This pull request has now been integrated.

Changeset: b25d8940
Author:    Fei Yang <fyang at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b25d8940
Stats:     1265 lines in 36 files changed: 1010 ins; 22 del; 233 mod

8252204: AArch64: Implement SHA3 accelerator/intrinsic

Co-authored-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
Co-authored-by: Dong Bo <dongbo4 at huawei.com>
Reviewed-by: aph, kvn

-------------

PR: https://git.openjdk.java.net/jdk/pull/207

From aph at openjdk.java.net  Thu Oct 22 09:08:31 2020
From: aph at openjdk.java.net (Andrew Haley)
Date: Thu, 22 Oct 2020 09:08:31 GMT
Subject: RFR: 8254078: DataOutputStream is very slow post-disabling of
 Biased Locking [v7]
In-Reply-To: <lLg_yNI_6LvUZTlM4PyN5ra6AaUZZeT35QzYzV_0CpI=.f2d3cb9e-be30-40dc-922c-dad5bef7feea@github.com>
References: <lLg_yNI_6LvUZTlM4PyN5ra6AaUZZeT35QzYzV_0CpI=.f2d3cb9e-be30-40dc-922c-dad5bef7feea@github.com>
Message-ID: <ooQmC1nrg_OO4nly8wSzyC_u6PgGE2BjABrF_LkuA_o=.64d25a07-1153-46fa-8ca9-5c639987d5f2@github.com>

> DataOutputStream is very slow post-disabling of Biased Locking. This
> was discovered when benchmarking a transaction library, which showed
> significant performance loss when moving to JDK 15. WIth some small
> changes to DataOutputStream we can get the performance back. There's a
> JMH benchmark at
> http://cr.openjdk.java.net/~aph/JDK-8254078/jmh-tests.tar
> 
> Some Stream classes use very fine-grained locking.
> 
> In particular, writeInt is defined like this:
> 
>         out.write((v >>> 24) & 0xFF);
>         out.write((v >>> 16) & 0xFF);
>         out.write((v >>> 8) & 0xFF);
>         out.write((v >>> 0) & 0xFF);
>         incCount(4);
> 
> Unfortunately, ByteArrayOutputStream.write(byte) is defined like this:
> 
>     public synchronized void write(int b) {
>         ensureCapacity(count + 1);
>         buf[count] = (byte) b;
>         count += 1;
>     }
> 
> so we acquire and release a lock for every byte that is output. 
> 
>  For example, writing 4kb of ints goes from 17.3 us/op to 53.9 us/op when biased locking is disabled: 
> 
> 
> +UseBiasedLocking DataOutputStreamTest.dataOutputStreamOverByteArray avgt 6 53.895 ? 5.126 us/op
> -UseBiasedLocking DataOutputStreamTest.dataOutputStreamOverByteArray avgt 6 17.291 ? 4.430 us/op
> 
> There are refactorings of DataOutputStream we can do to mitigate this.

Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:

  8254078: DataOutputStream is very slow post-disabling of Biased Locking

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/542/files
  - new: https://git.openjdk.java.net/jdk/pull/542/files/cd1d5a0a..f507a515

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=542&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=542&range=05-06

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/542.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/542/head:pull/542

PR: https://git.openjdk.java.net/jdk/pull/542

From jlahoda at openjdk.java.net  Thu Oct 22 09:10:16 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Thu, 22 Oct 2020 09:10:16 GMT
Subject: RFR: 8250625: Compiler implementation of Pattern Matching for
 instanceof (Final) [v2]
In-Reply-To: <9ylwnQ8cWjQeQ9hbRDScySUuctce51DiXlm9sDOrTEo=.fef60e85-cef5-46a6-9183-a1dadc2a1062@github.com>
References: <0uEby0-y3KVBLA1VxxdD5hCMlLhPCKB3w0mpihs9dsY=.181f22cd-7cf7-4941-b2d1-2ba4228d11d5@github.com>
 <rYOjux1Z6MNttDR7kuCqksinlB_n8gWAX_2ttvSrBRo=.68b4e032-f689-4ff1-b7a8-49937f7a85ad@github.com>
 <9ylwnQ8cWjQeQ9hbRDScySUuctce51DiXlm9sDOrTEo=.fef60e85-cef5-46a6-9183-a1dadc2a1062@github.com>
Message-ID: <WotB-XhZ7lO1iQ846k93umMVJ2UuWslF_avLPfjydZU=.54ce6664-683e-423d-a1f1-b11ab5ee4cf5@github.com>

On Wed, 21 Oct 2020 03:12:08 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 15 additional commits since the last revision:
>> 
>>  - Cleanup: using a null instead of List.of() as a parameter to JavaCompiler.getTask
>>  - Merge branch 'master' into patterns-instanceof3
>>  - Fixing more tests.
>>  - Correcting positions.
>>  - Improve the AST model.
>>  - Merge branch 'master' into patterns-instanceof3
>>  - Updating @since tags.
>>  - Merge branch 'master' into patterns-instanceof3
>>  - Cleaning up preview comments in javadoc.
>>  - Merge branch 'master' into patterns-instanceof3
>>  - ... and 5 more: https://git.openjdk.java.net/jdk/compare/efd3730b...5978bca0
>
> src/jdk.compiler/share/classes/com/sun/source/tree/PatternTree.java line 29:
> 
>> 27: 
>> 28: /**
>> 29:  * A tree node used as the base class for the different kinds of
> 
> the javadoc seems to need an update, probably:
> `A tree node used as the base class for the different kinds of pattern matching expressions`?

Patterns are not really expressions - they are a new kind of trees. Basically, before we had "statements" and "expressions" (+declarations, which are a bit special, ClassTree and VariableTree are "statements", but MethodTree, ModuleTree and PackageTree subtype Tree directly, so there is no common supertype). Now we have "patterns" in addition to that.

For example, having: `o instanceof String s`, this is an expression, but `String s` is not - it is a pattern. It cannot stand on its own as an expression, it is a special part of the expression.

-------------

PR: https://git.openjdk.java.net/jdk/pull/559

From alanb at openjdk.java.net  Thu Oct 22 09:51:13 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 22 Oct 2020 09:51:13 GMT
Subject: RFR: 8254078: DataOutputStream is very slow post-disabling of
 Biased Locking [v7]
In-Reply-To: <ooQmC1nrg_OO4nly8wSzyC_u6PgGE2BjABrF_LkuA_o=.64d25a07-1153-46fa-8ca9-5c639987d5f2@github.com>
References: <lLg_yNI_6LvUZTlM4PyN5ra6AaUZZeT35QzYzV_0CpI=.f2d3cb9e-be30-40dc-922c-dad5bef7feea@github.com>
 <ooQmC1nrg_OO4nly8wSzyC_u6PgGE2BjABrF_LkuA_o=.64d25a07-1153-46fa-8ca9-5c639987d5f2@github.com>
Message-ID: <pRIuiUtfc76AvFziPNev78B2_YZ9vchgznxKTiUnf7g=.193615cf-4b09-4a68-9e40-d0bc8f748d50@github.com>

On Thu, 22 Oct 2020 09:08:31 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> DataOutputStream is very slow post-disabling of Biased Locking. This
>> was discovered when benchmarking a transaction library, which showed
>> significant performance loss when moving to JDK 15. WIth some small
>> changes to DataOutputStream we can get the performance back. There's a
>> JMH benchmark at
>> http://cr.openjdk.java.net/~aph/JDK-8254078/jmh-tests.tar
>> 
>> Some Stream classes use very fine-grained locking.
>> 
>> In particular, writeInt is defined like this:
>> 
>>         out.write((v >>> 24) & 0xFF);
>>         out.write((v >>> 16) & 0xFF);
>>         out.write((v >>> 8) & 0xFF);
>>         out.write((v >>> 0) & 0xFF);
>>         incCount(4);
>> 
>> Unfortunately, ByteArrayOutputStream.write(byte) is defined like this:
>> 
>>     public synchronized void write(int b) {
>>         ensureCapacity(count + 1);
>>         buf[count] = (byte) b;
>>         count += 1;
>>     }
>> 
>> so we acquire and release a lock for every byte that is output. 
>> 
>>  For example, writing 4kb of ints goes from 17.3 us/op to 53.9 us/op when biased locking is disabled: 
>> 
>> 
>> +UseBiasedLocking DataOutputStreamTest.dataOutputStreamOverByteArray avgt 6 53.895 ? 5.126 us/op
>> -UseBiasedLocking DataOutputStreamTest.dataOutputStreamOverByteArray avgt 6 17.291 ? 4.430 us/op
>> 
>> There are refactorings of DataOutputStream we can do to mitigate this.
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8254078: DataOutputStream is very slow post-disabling of Biased Locking

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/542

From jlahoda at openjdk.java.net  Thu Oct 22 12:14:42 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Thu, 22 Oct 2020 12:14:42 GMT
Subject: RFR: 8250625: Compiler implementation of Pattern Matching for
 instanceof (Final) [v4]
In-Reply-To: <0uEby0-y3KVBLA1VxxdD5hCMlLhPCKB3w0mpihs9dsY=.181f22cd-7cf7-4941-b2d1-2ba4228d11d5@github.com>
References: <0uEby0-y3KVBLA1VxxdD5hCMlLhPCKB3w0mpihs9dsY=.181f22cd-7cf7-4941-b2d1-2ba4228d11d5@github.com>
Message-ID: <ImquH7O0eoATlNNlz0N0t-6KvFripYQjTaFRyX7l-z8=.8dc08d9d-2587-4f8a-98bd-724a867d2d6a@github.com>

> This is the current proposed patch for the upcoming JEP 394, for pattern matching for instanceof.
> 
> A summary of changes:
> -making the feature permanent (non-preview)
> -making the binding variables non-final (as per current specification proposal)
> -producing a compile-time error for the case where the expression's type is a subtype of the type test pattern's type (as per current specification proposal)
> -changing the AST structure so that the binding variable has a VariableTree in the AST. BindingPatternTree is preserved and encloses the VariableTree. The reason is better consistency in the API, with nodes like CatchTree, EnhancedForLoop Tree, etc.
> 
> This change will not be integrated until JEP 394 is targetted.

Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 18 additional commits since the last revision:

 - Removing the preview deprecated methods from BindingPatternTree.
 - Merge branch 'master' into patterns-instanceof3
 - Fixing review comments.
 - Cleanup: using a null instead of List.of() as a parameter to JavaCompiler.getTask
 - Merge branch 'master' into patterns-instanceof3
 - Fixing more tests.
 - Correcting positions.
 - Improve the AST model.
 - Merge branch 'master' into patterns-instanceof3
 - Updating @since tags.
 - ... and 8 more: https://git.openjdk.java.net/jdk/compare/8c106e10...77468e24

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/559/files
  - new: https://git.openjdk.java.net/jdk/pull/559/files/5699194b..77468e24

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=559&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=559&range=02-03

  Stats: 32942 lines in 393 files changed: 22168 ins; 8599 del; 2175 mod
  Patch: https://git.openjdk.java.net/jdk/pull/559.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/559/head:pull/559

PR: https://git.openjdk.java.net/jdk/pull/559

From jlahoda at openjdk.java.net  Thu Oct 22 12:14:47 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Thu, 22 Oct 2020 12:14:47 GMT
Subject: RFR: 8250625: Compiler implementation of Pattern Matching for
 instanceof (Final) [v2]
In-Reply-To: <9ylwnQ8cWjQeQ9hbRDScySUuctce51DiXlm9sDOrTEo=.fef60e85-cef5-46a6-9183-a1dadc2a1062@github.com>
References: <0uEby0-y3KVBLA1VxxdD5hCMlLhPCKB3w0mpihs9dsY=.181f22cd-7cf7-4941-b2d1-2ba4228d11d5@github.com>
 <rYOjux1Z6MNttDR7kuCqksinlB_n8gWAX_2ttvSrBRo=.68b4e032-f689-4ff1-b7a8-49937f7a85ad@github.com>
 <9ylwnQ8cWjQeQ9hbRDScySUuctce51DiXlm9sDOrTEo=.fef60e85-cef5-46a6-9183-a1dadc2a1062@github.com>
Message-ID: <sRZ1NkD0LxBP399M9xsVJLWFylqB1BmkxB5yPewPMOQ=.894ec8dc-135d-47ca-a55b-bad64d8f056b@github.com>

On Wed, 21 Oct 2020 03:13:34 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 15 additional commits since the last revision:
>> 
>>  - Cleanup: using a null instead of List.of() as a parameter to JavaCompiler.getTask
>>  - Merge branch 'master' into patterns-instanceof3
>>  - Fixing more tests.
>>  - Correcting positions.
>>  - Improve the AST model.
>>  - Merge branch 'master' into patterns-instanceof3
>>  - Updating @since tags.
>>  - Merge branch 'master' into patterns-instanceof3
>>  - Cleaning up preview comments in javadoc.
>>  - Merge branch 'master' into patterns-instanceof3
>>  - ... and 5 more: https://git.openjdk.java.net/jdk/compare/bf803de0...5978bca0
>
> Changes requested by vromero (Reviewer).

Based on an offline feedback, I've removed the old, preview, deprecated methods from BindingPatternTree.

-------------

PR: https://git.openjdk.java.net/jdk/pull/559

From sergei.tsypanov at yandex.ru  Thu Oct 22 12:45:36 2020
From: sergei.tsypanov at yandex.ru (=?utf-8?B?0KHQtdGA0LPQtdC5INCm0YvQv9Cw0L3QvtCy?=)
Date: Thu, 22 Oct 2020 14:45:36 +0200
Subject: RFR: Remove unused package-private method URL.set(String protocol,
 String host, int port, String file, String ref)
Message-ID: <543581603370534@mail.yandex.ru>

Hello,

while working with java.net.URL I've found unused package-private method URL.set(String protocol, String host, int port, String file, String ref) which can be safely removed. Testing: both tier1 and tier2 are ok.

Could someone crate an issue for tracking of this simple change?

Here's the link to PR: https://github.com/openjdk/jdk/pull/779

Regards,
Sergey Tsypanov

From mcimadamore at openjdk.java.net  Thu Oct 22 13:37:17 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 22 Oct 2020 13:37:17 GMT
Subject: RFR: 8254231: Implementation of Foreign Linker API (Incubator)
 [v7]
In-Reply-To: <ZGkYBBhHYxqech4xnb28ci0wZUGGlj-oiJm0hiAplUs=.ff119342-fd23-4faf-a3e1-ab31c4d067a5@github.com>
References: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
 <Rxu6c37o5dBPtGxju77Y5NfjLQNIE1yRZw-bnQz1n0k=.7c929e86-7513-49d7-90fa-1d997963050f@github.com>
 <ZGkYBBhHYxqech4xnb28ci0wZUGGlj-oiJm0hiAplUs=.ff119342-fd23-4faf-a3e1-ab31c4d067a5@github.com>
Message-ID: <c6SIaTGEzykNTJiywQIm0-5Hatjws_iD6fGFxylQSEQ=.b38ec923-f9c7-426e-8f97-5d7371b121ca@github.com>

On Tue, 20 Oct 2020 21:31:17 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits:
>> 
>>  - Merge branch 'master' into 8254231_linker
>>  - Fix incorrect capitalization in one copyright header
>>  - Update copyright years, and add classpath exception to files that were missing it
>>  - Use separate constants for native invoker code size
>>  - Re-add file erroneously deleted (detected as rename)
>>  - Re-add erroneously removed files
>>  - Merge branch 'master' into 8254231_linker
>>    
>>    - Fix tests
>>  - Fix more whitespaces
>>  - Fix whitespaces
>>  - Remove rejected file
>>  - ... and 15 more: https://git.openjdk.java.net/jdk/compare/cb6167b2...502bd980
>
> src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java line 126:
> 
>> 124:      *
>> 125:      * @param symbol   downcall symbol.
>> 126:      * @param type     the method type.
> 
> s/method type/carrier type ?

Not sure about this one? E.g. in my mental model, I often have seen "carrier type" associated with j.l.Class ?

> src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java line 139:
> 
>> 137:      *
>> 138:      * <p>The returned segment is <em>not</em> thread-confined, and it only features
>> 139:      * the {@link MemorySegment#CLOSE} access mode. When the returned segment is closed,
> 
> Implying that it is shared? If so might be better to state that directly (with a link), and can be closed explicitly or left until can be collected by the GC?

`The returned segment is <em>not</em> thread-confined` ? Since it features CLOSE, it can be closed explicitly - I'm not sure 100% of what additional clarification is required - but I'm happy to make this clearer (I need more info).

-------------

PR: https://git.openjdk.java.net/jdk/pull/634

From rriggs at openjdk.java.net  Thu Oct 22 13:49:14 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 22 Oct 2020 13:49:14 GMT
Subject: RFR: 8254078: DataOutputStream is very slow post-disabling of
 Biased Locking [v7]
In-Reply-To: <ooQmC1nrg_OO4nly8wSzyC_u6PgGE2BjABrF_LkuA_o=.64d25a07-1153-46fa-8ca9-5c639987d5f2@github.com>
References: <lLg_yNI_6LvUZTlM4PyN5ra6AaUZZeT35QzYzV_0CpI=.f2d3cb9e-be30-40dc-922c-dad5bef7feea@github.com>
 <ooQmC1nrg_OO4nly8wSzyC_u6PgGE2BjABrF_LkuA_o=.64d25a07-1153-46fa-8ca9-5c639987d5f2@github.com>
Message-ID: <8xp_mHc6OuhbwOUHKx86x7bxeGeQl7J992Mrprd6A28=.98410a9d-7fe5-48b3-96de-47d35d7f21f4@github.com>

On Thu, 22 Oct 2020 09:08:31 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> DataOutputStream is very slow post-disabling of Biased Locking. This
>> was discovered when benchmarking a transaction library, which showed
>> significant performance loss when moving to JDK 15. WIth some small
>> changes to DataOutputStream we can get the performance back. There's a
>> JMH benchmark at
>> http://cr.openjdk.java.net/~aph/JDK-8254078/jmh-tests.tar
>> 
>> Some Stream classes use very fine-grained locking.
>> 
>> In particular, writeInt is defined like this:
>> 
>>         out.write((v >>> 24) & 0xFF);
>>         out.write((v >>> 16) & 0xFF);
>>         out.write((v >>> 8) & 0xFF);
>>         out.write((v >>> 0) & 0xFF);
>>         incCount(4);
>> 
>> Unfortunately, ByteArrayOutputStream.write(byte) is defined like this:
>> 
>>     public synchronized void write(int b) {
>>         ensureCapacity(count + 1);
>>         buf[count] = (byte) b;
>>         count += 1;
>>     }
>> 
>> so we acquire and release a lock for every byte that is output. 
>> 
>>  For example, writing 4kb of ints goes from 17.3 us/op to 53.9 us/op when biased locking is disabled: 
>> 
>> 
>> +UseBiasedLocking DataOutputStreamTest.dataOutputStreamOverByteArray avgt 6 53.895 ? 5.126 us/op
>> -UseBiasedLocking DataOutputStreamTest.dataOutputStreamOverByteArray avgt 6 17.291 ? 4.430 us/op
>> 
>> There are refactorings of DataOutputStream we can do to mitigate this.
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8254078: DataOutputStream is very slow post-disabling of Biased Locking

Marked as reviewed by rriggs (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/542

From sgehwolf at openjdk.java.net  Thu Oct 22 14:24:23 2020
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Thu, 22 Oct 2020 14:24:23 GMT
Subject: RFR: 8254854: [cgroups v1] Metric limits not properly detected on
 some join controller combinations
Message-ID: <NpI0Y7gZOap0GTIF204zKcqpwv8G7PIarz2I8yoSX5o=.eb0dd647-192a-43dd-8e9d-c073ad098ac4@github.com>

Originally only join controllers of form `cpu,cpuacct` would have been recognized.
However, this fails if more controllers are joined at a certain path.

The proposed fix is to be sure to split join controllers on `,` and set the path
accordingly. Otherwise, the Metrics system might be initialized due to some
non-join controllers, yet the limits for join controllers wouldn't be detected. A
test for this can be added once [JDK-8254001](https://bugs.openjdk.java.net/browse/JDK-8254001) has been implemented.

Testing:

- [x] jdk/submit
- [x] container tests on Linux cgroups v1 system.

Thoughts?

-------------

Commit messages:
 - 8254854: [cgroups v1] Metric limits not properly detected on some join controller combinations

Changes: https://git.openjdk.java.net/jdk/pull/809/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=809&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8254854
  Stats: 36 lines in 1 file changed: 3 ins; 10 del; 23 mod
  Patch: https://git.openjdk.java.net/jdk/pull/809.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/809/head:pull/809

PR: https://git.openjdk.java.net/jdk/pull/809

From alanb at openjdk.java.net  Thu Oct 22 14:26:15 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 22 Oct 2020 14:26:15 GMT
Subject: RFR: 8159746: (proxy) Support for default methods
In-Reply-To: <BoATjx7PPcLpINJVC5HM77UKMriIUqnnhcBowkJRlvM=.1221e3e1-ed27-4618-8365-dcd903d27f60@github.com>
References: <kw2VXh3vTFf1zgfd4biXA41OKffZ5oU7KT23tXAxgUA=.bcf14ffc-4dba-4c9c-8754-184172c5acbd@github.com>
 <U-6RiCpFVIrhLztPN6opiPcpFtxValDzU-K7WWFZM-4=.6bc8aaa4-636a-4664-b380-4c4af00513bd@github.com>
 <-cLIJ8pFHtnNoJMHV3aXI7XMJWp4Jrutc8Xn5PG0OK8=.d2cd87ab-3592-4524-ad85-05444c43689b@github.com>
 <r0UK2qjnmgeTNDDSWaSLPAj3QRgx_4YB82ielllO7jM=.fa615bc0-db49-4a74-b842-793f8f5209bb@github.com>
 <1T8kXDZN1bhHr4c8v4SQsImeBySCqTfX-u3_jzvyocA=.b4957400-9a33-4b6e-8475-329642a5888c@github.com>
 <XIux-dY0JXHRafHk48kVNXId9r-HSceNSytBojDxelY=.872e74cb-b064-406e-b71f-13c90ec7fbbc@github.com>
 <j4t2vT0SnwnU7lhKRlXtk967d-K6nA0EqHrqNbba7W0=.dc05dba6-bf7e-4606-8a02-9c2bad4b3b58@github.com>
 <fmVtPcBdgMuZOPm2qx3Q3znVZM7JgQPkhPAVLtwkOhE=.2d8b8447-cfae-4cb3-9a7c-6567a881231f@github.com>
 <GSeWP29fAIUFSk0CYsC557w52CuLqeUWwHNK9maltwI=.3d5f002e-6b74-4a57-a5d8-244d27da9dde@github.com>
 <GF8iEOkMUEL2dYB0HytFIc9gyeeUJ_KP0ImlqFsul2Y=.894afc05-9310-43e1-a308-8f7d71dc572b@github.com>
 <HvtDex3cmiv7XeTMITOroYfu74amSGQavQ_
 BAmVzmXw=.223be989-7c20-4ba4-ac0d-013d2b75a8cb@github.com>
 <IqRiLphFPBpGiKAnMJXqxjie9YeZ03rcE-qG1s92BLw=.d4fd5e92-5067-40df-8a0b-1dfd3d6e23af@github.com>
 <Y0hE51G3YefI6NY1O_E6VoZSKwxE78S1hv6fEatmOG8=.0a2c686c-d9ad-418c-8c1b-49addb8a54b1@github.com>
 <QrNk57L2PWQhJjzYiGTsvYyGIPAfK7bP_kANtTR-2uM=.3e5ce990-f8ea-4751-8147-27a8a9dad40d@github.com>
 <9JNNUzfV3PSvKtSg2a_zyYJmgEn3sZL9cb5sfqemk2o=.f1ef7fb7-bdd5-44ed-98c8-59213e9094f9@github.com>
 <zWGhaC8YB5I0XgffiR7o_YT5gSp9Gbj8Drtt23brl-c=.1e59f0e4-bbe3-4fb2-94dc-c55fc862f091@github.com>
 <LljojgqBhEi6tFptsbmu1jS-Xx7lYEXm9tRkkPqDGzE=.3d7d6a37-1042-4539-88d1-9f4cf5378128@github.com>
 <Gn33ydZNxqOpWUrmYiWJadMF0mukI2MR85EtgrV4D1I=.958521f2-1167-4a68-b513-e10bba37ae18@github.com>
 <NMXKaHql9XjndqPgyoN1Lasa9H8ugl8-ltD1j2XiT9Y=.3ff8871e-0f9d-40ea-8f35-e804a9afcbd5@github.com>
 <yzFe02HJ2qt5tT8tY9ZOofnKld93x1PM5U7AToTABJs=.439c213b-94b9-488f-bb6d-a835a86c527f@github.com>
 <BoATjx7PPcLpINJVC5HM77UKMriIUqnnhcBowkJRlvM=.1221e3e1-ed27-4618-8365-dcd903d27f60@
 github.com>
Message-ID: <yN0JJE9mBkqz9Ijbw4FYinv08tcnxiZHAGyarXBF9CY=.50429cb9-181a-447e-90a0-e0a0a836812e@github.com>

On Thu, 22 Oct 2020 00:24:59 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Hi Peter, thanks for coming with these alternatives.   The need for new `InvocationHandler2` and `InvocationHandler2.SuperInvoker` APIs and the complexity of `plevart:proxy-default-method-alt-api2` look unpleasing in order to keep the invocation of default methods in lambdas.  I prefer the `DelegatingInvocationHandler` abstract class approach without caller-sensitive method.
>
> Hi Peter, Alan
> 
> I have prototyped two alternatives ([mlchung:proxy-default-method-3](https://github.com/mlchung/jdk/tree/proxy-default-method-3)).
> 1. `DelegatingInvocationHandler` abstract class with:
> protected final Object invokeDefault(Object proxy, Method method, Object... params)
> 
> 2. `NewInvocationHandler` functional interface
>     public Object invoke(DefaultMethodInvoker invoker, Object proxy, Method method, Object... args) throws Throwable;
> 
>     /**
>      * {@inheritDoc}
>      */
>     public default Object invoke(Object proxy, Method method, Object[] args)
>             throws Throwable
>     {
>          return invoke(DefaultMethodInvoker.getInvoker(proxy, this), proxy, method, args);
>     }
> 
>    public final class DefaultMethodInvoker {
>         public final Object invoke(Object proxy, Method method, Object... args)
>                 throws InvocationTargetException
>    }
> 
> Similar idea as yours SuperInvoker.  But I think this is less complicated
> and DefaultMethodInvoker is a final class rather than an interface.
> The generated proxy class will keep invoking `InvocationHandler::invoke`
> (no change in `ProxyGenerator`).  `NewInvocationHandler` allows the use of lambdas.
> 
> I like `DelegatingInvocationHandler` which is simple and clean but not
> a functional interface.   `NewInvocationHandler` is a functional interface
> with the need of `DefaultMethodInvoker` to bridge between an invocation
> handler and an accessed check proxy object.
> 
> Thoughts?  I'm leaning toward `DelegatingInvocationHandler`.  
> 
> We need to decide on the exception if access checks fails on
> `Proxy::newProxyInstance` and  `Proxy::getInvocationHandler` 
> if the invocation handler needs the ability to invoke default
> methods.

Thanks for the update. Lots of challenges finding the right API as there are security and usability issues, not to mention performance and making it look like the support for default methods has always been there.

I've skimmed through both prototypes in proxy-method-default-3 branch, both seem to be secure.

NewInvocationHandler/DefaultMethodInvoker feels a bit awkward. If I have it right, to use it as a lambda expression to Proxy.newProxyInterface would require casting to NewInvocationHandler. I also need to be careful when using the invoker and not call it with a non-default method.

DelegatingInvocationHandler feels more like a base implementation that I extend when I need help invoking default methods. Naming aside, it feels like it fits in better but with the downside that an instance can't be used as a functional interface. So I agree this one is a better. The users of this API will be super advanced developers and I would expect retrofitting existing code shouldn't be too hard for that are compiled to 16+.

-------------

PR: https://git.openjdk.java.net/jdk/pull/313

From sgehwolf at openjdk.java.net  Thu Oct 22 14:28:16 2020
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Thu, 22 Oct 2020 14:28:16 GMT
Subject: RFR: 8254854: [cgroups v1] Metric limits not properly detected on
 some join controller combinations
In-Reply-To: <NpI0Y7gZOap0GTIF204zKcqpwv8G7PIarz2I8yoSX5o=.eb0dd647-192a-43dd-8e9d-c073ad098ac4@github.com>
References: <NpI0Y7gZOap0GTIF204zKcqpwv8G7PIarz2I8yoSX5o=.eb0dd647-192a-43dd-8e9d-c073ad098ac4@github.com>
Message-ID: <9gK7UpXu1k9-uD4J3lm9p3sJhHfcwy51QL1bKyhHXMo=.9e1fa8ed-6ea2-4185-a4cf-78f0ab981e94@github.com>

On Thu, 22 Oct 2020 14:17:56 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Originally only join controllers of form `cpu,cpuacct` would have been recognized.
> However, this fails if more controllers are joined at a certain path.
> 
> The proposed fix is to be sure to split join controllers on `,` and set the path
> accordingly. Otherwise, the Metrics system might be initialized due to some
> non-join controllers, yet the limits for join controllers wouldn't be detected. A
> test for this can be added once [JDK-8254001](https://bugs.openjdk.java.net/browse/JDK-8254001) has been implemented.
> 
> Testing:
> 
> - [x] jdk/submit
> - [x] container tests on Linux cgroups v1 system.
> 
> Thoughts?

@bobvandette Could you please take a look? It would be much appreciated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/809

From mcimadamore at openjdk.java.net  Thu Oct 22 14:29:14 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 22 Oct 2020 14:29:14 GMT
Subject: RFR: 8254231: Implementation of Foreign Linker API (Incubator)
 [v9]
In-Reply-To: <KUq2-MTn5B82LZGZ0PBp4kvYEyjLyX3Rg9jtH2yKO2w=.85804c26-ea5a-4ecd-8a4f-ad475a954bd5@github.com>
References: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
 <XvFIGunZ1EjNeZNgkF_I06FjuDxHmD8jjCJ2HkpF_xE=.15ac4c1b-063a-4181-ad6b-3fd64e95b0ed@github.com>
 <KUq2-MTn5B82LZGZ0PBp4kvYEyjLyX3Rg9jtH2yKO2w=.85804c26-ea5a-4ecd-8a4f-ad475a954bd5@github.com>
Message-ID: <1p5weKaRsQH1q9GBnZFqKPupXb-5hYfeMm-NxaPiPUM=.db7147ad-67e0-4738-9fa7-d1afdabe3705@github.com>

On Wed, 21 Oct 2020 16:23:16 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 27 commits:
>> 
>>  - Merge branch 'master' into 8254231_linker
>>  - Don't use JNI when generating native wrappers
>>    
>>  - Merge branch 'master' into 8254231_linker
>>  - Fix incorrect capitalization in one copyright header
>>  - Update copyright years, and add classpath exception to files that were missing it
>>  - Use separate constants for native invoker code size
>>  - Re-add file erroneously deleted (detected as rename)
>>  - Re-add erroneously removed files
>>  - Merge branch 'master' into 8254231_linker
>>    
>>    - Fix tests
>>  - Fix more whitespaces
>>  - ... and 17 more: https://git.openjdk.java.net/jdk/compare/da97ab5c...8c7b75da
>
> src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/AbstractNativeScope.java line 120:
> 
>> 118:                 }
>> 119:             }
>> 120:             throw new AssertionError("Cannot get here!");
> 
> This code is a little confusing, effectively using an exception for control flow, within a retry loop. I recommend performing an explicit bounds check to determine if a new segment of `BLOCK_SIZE` is required from which to slice into. It will also be faster than the exceptional case.

I hear you - that said, note that doing the bound check is not as trivial as it seems; you have to take into account the value of `sp` and add required alignment padding, and then perform a bound check against that - all logic which would need to be duplicated across the normal and the exceptional cases. Which is why the code settled the way it is. I'll see what I can do.

-------------

PR: https://git.openjdk.java.net/jdk/pull/634

From jvernee at openjdk.java.net  Thu Oct 22 14:34:19 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Thu, 22 Oct 2020 14:34:19 GMT
Subject: RFR: 8254231: Implementation of Foreign Linker API (Incubator)
 [v7]
In-Reply-To: <ZGkYBBhHYxqech4xnb28ci0wZUGGlj-oiJm0hiAplUs=.ff119342-fd23-4faf-a3e1-ab31c4d067a5@github.com>
References: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
 <Rxu6c37o5dBPtGxju77Y5NfjLQNIE1yRZw-bnQz1n0k=.7c929e86-7513-49d7-90fa-1d997963050f@github.com>
 <ZGkYBBhHYxqech4xnb28ci0wZUGGlj-oiJm0hiAplUs=.ff119342-fd23-4faf-a3e1-ab31c4d067a5@github.com>
Message-ID: <MXCesPkhxy-D2fHC-hYBLe6DBogMjwknq7qi9FBaPsg=.dd94627f-679a-4062-b8b3-53380d36f079@github.com>

On Tue, 20 Oct 2020 21:08:26 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits:
>> 
>>  - Merge branch 'master' into 8254231_linker
>>  - Fix incorrect capitalization in one copyright header
>>  - Update copyright years, and add classpath exception to files that were missing it
>>  - Use separate constants for native invoker code size
>>  - Re-add file erroneously deleted (detected as rename)
>>  - Re-add erroneously removed files
>>  - Merge branch 'master' into 8254231_linker
>>    
>>    - Fix tests
>>  - Fix more whitespaces
>>  - Fix whitespaces
>>  - Remove rejected file
>>  - ... and 15 more: https://git.openjdk.java.net/jdk/compare/cb6167b2...502bd980
>
> src/java.base/share/classes/java/lang/invoke/NativeMethodHandle.java line 36:
> 
>> 34: import static java.lang.invoke.MethodHandleStatics.newInternalError;
>> 35: 
>> 36: /** TODO */
> 
> Is the TODO to make this class public later and adjust the return type of `downcallHandle`?

IIRC this was added to silence a javac linter warning. Something should be added here. There is/was no plan to make this class public though.

> src/java.base/share/classes/java/lang/invoke/NativeMethodHandle.java line 145:
> 
>> 143:      */
>> 144:     private static class Lazy {
>> 145:         static Class<NativeMethodHandle> THIS_CLASS = NativeMethodHandle.class;
> 
> final field? Is this field needed, as `NativeMethodHandle.class` could be used directly, or use a local variable instead in the static code block.

Yes, this was a leftover from old code. Can be a local var now, or remove altogether and replaced with `NativeMethodHandle.class`

-------------

PR: https://git.openjdk.java.net/jdk/pull/634

From jvernee at openjdk.java.net  Thu Oct 22 14:39:18 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Thu, 22 Oct 2020 14:39:18 GMT
Subject: RFR: 8254231: Implementation of Foreign Linker API (Incubator)
 [v7]
In-Reply-To: <ZGkYBBhHYxqech4xnb28ci0wZUGGlj-oiJm0hiAplUs=.ff119342-fd23-4faf-a3e1-ab31c4d067a5@github.com>
References: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
 <Rxu6c37o5dBPtGxju77Y5NfjLQNIE1yRZw-bnQz1n0k=.7c929e86-7513-49d7-90fa-1d997963050f@github.com>
 <ZGkYBBhHYxqech4xnb28ci0wZUGGlj-oiJm0hiAplUs=.ff119342-fd23-4faf-a3e1-ab31c4d067a5@github.com>
Message-ID: <tUqkSbHYQgoPJQR_4cCetLhiyd5mB2G1jmISk4-gJgE=.b3c819ad-0f61-4f8c-aaeb-2c318340f7fe@github.com>

On Tue, 20 Oct 2020 21:53:55 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits:
>> 
>>  - Merge branch 'master' into 8254231_linker
>>  - Fix incorrect capitalization in one copyright header
>>  - Update copyright years, and add classpath exception to files that were missing it
>>  - Use separate constants for native invoker code size
>>  - Re-add file erroneously deleted (detected as rename)
>>  - Re-add erroneously removed files
>>  - Merge branch 'master' into 8254231_linker
>>    
>>    - Fix tests
>>  - Fix more whitespaces
>>  - Fix whitespaces
>>  - Remove rejected file
>>  - ... and 15 more: https://git.openjdk.java.net/jdk/compare/cb6167b2...502bd980
>
> src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/FunctionDescriptor.java line 60:
> 
>> 58:     private FunctionDescriptor(MemoryLayout resLayout, Map<String, Constable> attributes, MemoryLayout... argLayouts) {
>> 59:         this.resLayout = resLayout;
>> 60:         this.attributes = Collections.unmodifiableMap(attributes);
> 
> Since `attributes` is never exposed directly or indirectly via a set of keys/values/entries there is no need to wrap it.

True. Though, it might be nice to keep like this as a bit of sanity checking. The map _should not_ be modified after construction.

-------------

PR: https://git.openjdk.java.net/jdk/pull/634

From bobv at openjdk.java.net  Thu Oct 22 14:51:12 2020
From: bobv at openjdk.java.net (Bob Vandette)
Date: Thu, 22 Oct 2020 14:51:12 GMT
Subject: RFR: 8254854: [cgroups v1] Metric limits not properly detected on
 some join controller combinations
In-Reply-To: <9gK7UpXu1k9-uD4J3lm9p3sJhHfcwy51QL1bKyhHXMo=.9e1fa8ed-6ea2-4185-a4cf-78f0ab981e94@github.com>
References: <NpI0Y7gZOap0GTIF204zKcqpwv8G7PIarz2I8yoSX5o=.eb0dd647-192a-43dd-8e9d-c073ad098ac4@github.com>
 <9gK7UpXu1k9-uD4J3lm9p3sJhHfcwy51QL1bKyhHXMo=.9e1fa8ed-6ea2-4185-a4cf-78f0ab981e94@github.com>
Message-ID: <xJMaifdM0beAA4AUuhaFKrG7jioufABfKrL1o7J_LIA=.cde22a0c-48a3-45a9-8e2b-be95ea65525d@github.com>

On Thu, 22 Oct 2020 14:25:28 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Originally only join controllers of form `cpu,cpuacct` would have been recognized.
>> However, this fails if more controllers are joined at a certain path.
>> 
>> The proposed fix is to be sure to split join controllers on `,` and set the path
>> accordingly. Otherwise, the Metrics system might be initialized due to some
>> non-join controllers, yet the limits for join controllers wouldn't be detected. A
>> test for this can be added once [JDK-8254001](https://bugs.openjdk.java.net/browse/JDK-8254001) has been implemented.
>> 
>> Testing:
>> 
>> - [x] jdk/submit
>> - [x] container tests on Linux cgroups v1 system.
>> 
>> Thoughts?
>
> @bobvandette Could you please take a look? It would be much appreciated.

How does this cgroup file get parsed properly in the hotspot side of things?  I don't see more than one controller getting registered per line???

-------------

PR: https://git.openjdk.java.net/jdk/pull/809

From github.com+12972156+pmur at openjdk.java.net  Thu Oct 22 14:59:21 2020
From: github.com+12972156+pmur at openjdk.java.net (Paul Murphy)
Date: Thu, 22 Oct 2020 14:59:21 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v8]
In-Reply-To: <nU4nZ9oCthDEi7olxerj_bkmWuITInbbNzJKkb1shkY=.28b4ed81-9733-4981-b6fb-c8e4e3bd335e@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <nU4nZ9oCthDEi7olxerj_bkmWuITInbbNzJKkb1shkY=.28b4ed81-9733-4981-b6fb-c8e4e3bd335e@github.com>
Message-ID: <r_UoYsBul9SV88OG2z5qfeCfKQFCF23_DDfdB1LKlzY=.2df9f9a4-d0b6-4ac6-b75b-1cd59022eca6@github.com>

On Wed, 21 Oct 2020 20:43:30 GMT, CoreyAshford <github.com+51754783+CoreyAshford at openjdk.org> wrote:

>> This patch set encompasses the following commits:
>> 
>> - Adds a new HotSpot intrinsic candidate to the java.lang.Base64 class - decodeBlock(), and provides a flexible API for the intrinsic.  The API is similar to the existing encodeBlock intrinsic.
>> - Adds the code in HotSpot to check and martial the new intrinsic's arguments to the arch-specific intrinsic implementation
>> - Adds a Power64LE-specific implementation of the decodeBlock intrinsic.
>> - Adds a JMH microbenchmark for both Base64 encoding and encoding.
>> - Enhances the JTReg hotspot intrinsic "TestBase64.java" regression test to more fully test both decoding and encoding.
>
> CoreyAshford has updated the pull request incrementally with one additional commit since the last revision:
> 
>   TestBase64.java: remove jdk.test.lib.Utils from @build which was causing Tier3 failures.

I took a look at the VSX algo.  I haven't looked much beyond it. I had a few questions I've inlined.  It does look like a faithful VSX implementation of the linked algo.

src/hotspot/cpu/ppc/stubGenerator_ppc.cpp line 3817:

> 3815:         __ xxperm(offsets->to_vsr(), offsetLUT, higher_nibble->to_vsr());
> 3816: 
> 3817:         // Find out which elemets are the special case character (isURL ? '/' : '-')

Trivial nit, s/elemets/elements/

src/hotspot/cpu/ppc/stubGenerator_ppc.cpp line 3820:

> 3818:         __ vcmpequb_(eq_special_case_char, input, vec_special_case_char);
> 3819:         //
> 3820:         // There's a (63/64)^16 = 77.7% chance that there are no special

I think that assumes uniformly randomized data, is that a good assumption?   Is it measurably faster to skip around the xxsel instead of doing it unconditionally?

src/hotspot/cpu/ppc/stubGenerator_ppc.cpp line 3858:

> 3856: 
> 3857:         // The Base64 characters had no errors, so add the offsets
> 3858:         __ vaddubm(input, input, offsets);

I think this looks like a correct implementation of the algo in VSX.

src/hotspot/cpu/ppc/stubGenerator_ppc.cpp line 3878:

> 3876:             // |    Element    |             |                      |                      |             |             |                      |                      |             |
> 3877:             // +===============+=============+======================+======================+=============+=============+======================+======================+=============+
> 3878:             // | after vaddubm | 00||b0:0..5 | 00||b0:6..7||b1:0..3 | 00||b1:4..7||b2:0..1 | 00||b2:2..7 | 00||b3:0..5 | 00||b3:6..7||b4:0..3 | 00||b4:4..7||b5:0..1 | 00||b5:2..7 |

An extra line here showing how the 8 6-bit values above get mapping into 6 bytes greatly help my brain out. (likewise for the <P10 case below too)

src/hotspot/cpu/ppc/stubGenerator_ppc.cpp line 3884:

> 3882:             // |   vec_0x3fs   |  00111111   |       00111111       |       00111111       |  00111111   |  00111111   |       00111111       |       00111111       |  00111111   |
> 3883:             // +---------------+-------------+----------------------+----------------------+-------------+-------------+----------------------+----------------------+-------------+
> 3884:             // | after vpextd  |   b5:0..7   |       b4:0..7        |       b3:0..7        |   b2:0..7   |   b1:0..7   |       b0:0..7        |       00000000       |  00000000   |

Are theses comments correct or am I misunderstanding this? I read the final result as something starting as `b5:2..7 || b4:4..7|| b5:0..1` from vpextd.

-------------

PR: https://git.openjdk.java.net/jdk/pull/293

From bobv at openjdk.java.net  Thu Oct 22 15:03:12 2020
From: bobv at openjdk.java.net (Bob Vandette)
Date: Thu, 22 Oct 2020 15:03:12 GMT
Subject: RFR: 8254854: [cgroups v1] Metric limits not properly detected on
 some join controller combinations
In-Reply-To: <NpI0Y7gZOap0GTIF204zKcqpwv8G7PIarz2I8yoSX5o=.eb0dd647-192a-43dd-8e9d-c073ad098ac4@github.com>
References: <NpI0Y7gZOap0GTIF204zKcqpwv8G7PIarz2I8yoSX5o=.eb0dd647-192a-43dd-8e9d-c073ad098ac4@github.com>
Message-ID: <eKasApGFhwvnZn2YiaiS4TGmbzLCE7FS_cKT0jTuKwI=.1ed1ee97-5c53-4716-a42e-5b8cf3e6c34b@github.com>

On Thu, 22 Oct 2020 14:17:56 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Originally only join controllers of form `cpu,cpuacct` would have been recognized.
> However, this fails if more controllers are joined at a certain path.
> 
> The proposed fix is to be sure to split join controllers on `,` and set the path
> accordingly. Otherwise, the Metrics system might be initialized due to some
> non-join controllers, yet the limits for join controllers wouldn't be detected. A
> test for this can be added once [JDK-8254001](https://bugs.openjdk.java.net/browse/JDK-8254001) has been implemented.
> 
> Testing:
> 
> - [x] jdk/submit
> - [x] container tests on Linux cgroups v1 system.
> 
> Thoughts?

src/java.base/linux/classes/jdk/internal/platform/cgroupv1/CgroupV1Subsystem.java line 165:

> 163: 
> 164:         if (controllerName != null && base != null) {
> 165:             for (String cName: controllerName.split(",")) {

The previous logic checked for base!=null.  Do you think this is no longer necessary?

-------------

PR: https://git.openjdk.java.net/jdk/pull/809

From sgehwolf at openjdk.java.net  Thu Oct 22 15:45:14 2020
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Thu, 22 Oct 2020 15:45:14 GMT
Subject: RFR: 8254854: [cgroups v1] Metric limits not properly detected on
 some join controller combinations
In-Reply-To: <eKasApGFhwvnZn2YiaiS4TGmbzLCE7FS_cKT0jTuKwI=.1ed1ee97-5c53-4716-a42e-5b8cf3e6c34b@github.com>
References: <NpI0Y7gZOap0GTIF204zKcqpwv8G7PIarz2I8yoSX5o=.eb0dd647-192a-43dd-8e9d-c073ad098ac4@github.com>
 <eKasApGFhwvnZn2YiaiS4TGmbzLCE7FS_cKT0jTuKwI=.1ed1ee97-5c53-4716-a42e-5b8cf3e6c34b@github.com>
Message-ID: <u5wBdH_YUiYUUQ30Sz1IhcZgWY7erjH1BD2j0KYwCZw=.0ecf7a54-a41f-41a6-a1fd-8cff5c6029cc@github.com>

On Thu, 22 Oct 2020 15:00:55 GMT, Bob Vandette <bobv at openjdk.org> wrote:

>> Originally only join controllers of form `cpu,cpuacct` would have been recognized.
>> However, this fails if more controllers are joined at a certain path.
>> 
>> The proposed fix is to be sure to split join controllers on `,` and set the path
>> accordingly. Otherwise, the Metrics system might be initialized due to some
>> non-join controllers, yet the limits for join controllers wouldn't be detected. A
>> test for this can be added once [JDK-8254001](https://bugs.openjdk.java.net/browse/JDK-8254001) has been implemented.
>> 
>> Testing:
>> 
>> - [x] jdk/submit
>> - [x] container tests on Linux cgroups v1 system.
>> 
>> Thoughts?
>
> src/java.base/linux/classes/jdk/internal/platform/cgroupv1/CgroupV1Subsystem.java line 165:
> 
>> 163: 
>> 164:         if (controllerName != null && base != null) {
>> 165:             for (String cName: controllerName.split(",")) {
> 
> The previous logic checked for base!=null.  Do you think this is no longer necessary?

Isn't this what line 164 does?

-------------

PR: https://git.openjdk.java.net/jdk/pull/809

From bobv at openjdk.java.net  Thu Oct 22 15:48:14 2020
From: bobv at openjdk.java.net (Bob Vandette)
Date: Thu, 22 Oct 2020 15:48:14 GMT
Subject: RFR: 8254854: [cgroups v1] Metric limits not properly detected on
 some join controller combinations
In-Reply-To: <NpI0Y7gZOap0GTIF204zKcqpwv8G7PIarz2I8yoSX5o=.eb0dd647-192a-43dd-8e9d-c073ad098ac4@github.com>
References: <NpI0Y7gZOap0GTIF204zKcqpwv8G7PIarz2I8yoSX5o=.eb0dd647-192a-43dd-8e9d-c073ad098ac4@github.com>
Message-ID: <KJgBz6Z4TTlIPNGEghjyIwQ9bmdAkgLkRWvjCAVt3Ho=.508b135b-49c2-4535-9c20-cd96fac1f394@github.com>

On Thu, 22 Oct 2020 14:17:56 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Originally only join controllers of form `cpu,cpuacct` would have been recognized.
> However, this fails if more controllers are joined at a certain path.
> 
> The proposed fix is to be sure to split join controllers on `,` and set the path
> accordingly. Otherwise, the Metrics system might be initialized due to some
> non-join controllers, yet the limits for join controllers wouldn't be detected. A
> test for this can be added once [JDK-8254001](https://bugs.openjdk.java.net/browse/JDK-8254001) has been implemented.
> 
> Testing:
> 
> - [x] jdk/submit
> - [x] container tests on Linux cgroups v1 system.
> 
> Thoughts?

Marked as reviewed by bobv (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/809

From bobv at openjdk.java.net  Thu Oct 22 15:48:18 2020
From: bobv at openjdk.java.net (Bob Vandette)
Date: Thu, 22 Oct 2020 15:48:18 GMT
Subject: RFR: 8254854: [cgroups v1] Metric limits not properly detected on
 some join controller combinations
In-Reply-To: <u5wBdH_YUiYUUQ30Sz1IhcZgWY7erjH1BD2j0KYwCZw=.0ecf7a54-a41f-41a6-a1fd-8cff5c6029cc@github.com>
References: <NpI0Y7gZOap0GTIF204zKcqpwv8G7PIarz2I8yoSX5o=.eb0dd647-192a-43dd-8e9d-c073ad098ac4@github.com>
 <eKasApGFhwvnZn2YiaiS4TGmbzLCE7FS_cKT0jTuKwI=.1ed1ee97-5c53-4716-a42e-5b8cf3e6c34b@github.com>
 <u5wBdH_YUiYUUQ30Sz1IhcZgWY7erjH1BD2j0KYwCZw=.0ecf7a54-a41f-41a6-a1fd-8cff5c6029cc@github.com>
Message-ID: <_NvVokiLrjdv7MUndvzthV7zDwSZ_0GlvSwr0piJwxI=.ab4db35c-ffba-4790-9c02-5ff6e19b3cf4@github.com>

On Thu, 22 Oct 2020 15:42:34 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> src/java.base/linux/classes/jdk/internal/platform/cgroupv1/CgroupV1Subsystem.java line 165:
>> 
>>> 163: 
>>> 164:         if (controllerName != null && base != null) {
>>> 165:             for (String cName: controllerName.split(",")) {
>> 
>> The previous logic checked for base!=null.  Do you think this is no longer necessary?
>
> Isn't this what line 164 does?

Sorry, I missed the fact that line 164 was being retained.  I just saw a lot of line removal.  Looks good.

-------------

PR: https://git.openjdk.java.net/jdk/pull/809

From rriggs at openjdk.java.net  Thu Oct 22 15:55:30 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 22 Oct 2020 15:55:30 GMT
Subject: RFR: 8251989: Hex formatting and parsing utility [v8]
In-Reply-To: <HSEn47GMS1K3g57mrTZeQk-WZHl3pKGHpX_OOf8VnsU=.740863c2-f9e4-43c4-b500-614aab4078b1@github.com>
References: <HSEn47GMS1K3g57mrTZeQk-WZHl3pKGHpX_OOf8VnsU=.740863c2-f9e4-43c4-b500-614aab4078b1@github.com>
Message-ID: <lX-d05Nj6nFlHSW_d-xVM0vihr1UQtxcFyCpN282hVo=.8e23858e-f014-4acb-83ed-b1310835b42a@github.com>

> java.util.HexFormat utility:
> 
>  - Format and parse hexadecimal strings, with parameters for delimiter, prefix, suffix and upper/lowercase
>  - Static factories and builder methods to create HexFormat copies with modified parameters.
>  - Consistent naming of methods for conversion of byte arrays to formatted strings and back: formatHex and parseHex
>  - Consistent naming of methods for conversion of primitive types: toHexDigits... and fromHexDigits...
>  - Prefix and suffixes now apply to each formatted value, not the string as a whole
>  - Using java.util.Appendable as a target for buffered conversions so output to Writers and PrintStreams
>    like System.out are supported in addition to StringBuilder. (IOExceptions are converted to unchecked exceptions)
>  - Immutable and thread safe, a "value-based" class
> 
> See the [HexFormat javadoc](http://cr.openjdk.java.net/~rriggs/8251989-hex-formatter/java.base/java/util/HexFormat.html) for details.
> 
> Review comments and suggestions welcome.

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Review comment updates to class javadoc

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/482/files
  - new: https://git.openjdk.java.net/jdk/pull/482/files/0a47544f..2b493d37

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=482&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=482&range=06-07

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/482.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/482/head:pull/482

PR: https://git.openjdk.java.net/jdk/pull/482

From psandoz at openjdk.java.net  Thu Oct 22 16:17:20 2020
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Thu, 22 Oct 2020 16:17:20 GMT
Subject: RFR: 8254231: Implementation of Foreign Linker API (Incubator)
 [v7]
In-Reply-To: <c6SIaTGEzykNTJiywQIm0-5Hatjws_iD6fGFxylQSEQ=.b38ec923-f9c7-426e-8f97-5d7371b121ca@github.com>
References: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
 <Rxu6c37o5dBPtGxju77Y5NfjLQNIE1yRZw-bnQz1n0k=.7c929e86-7513-49d7-90fa-1d997963050f@github.com>
 <ZGkYBBhHYxqech4xnb28ci0wZUGGlj-oiJm0hiAplUs=.ff119342-fd23-4faf-a3e1-ab31c4d067a5@github.com>
 <c6SIaTGEzykNTJiywQIm0-5Hatjws_iD6fGFxylQSEQ=.b38ec923-f9c7-426e-8f97-5d7371b121ca@github.com>
Message-ID: <itSUBCMvdQyivLbtK-HmGq7I6Bcw_s6uyeuQ4kHDprc=.4a6ff852-74b9-46c9-9ade-71f58428b131@github.com>

On Thu, 22 Oct 2020 13:30:13 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java line 126:
>> 
>>> 124:      *
>>> 125:      * @param symbol   downcall symbol.
>>> 126:      * @param type     the method type.
>> 
>> s/method type/carrier type ?
>
> Not sure about this one? E.g. in my mental model, I often have seen "carrier type" associated with j.l.Class ?

Ah, i see, i find it confusing that "carrier type" is mentioned in the `@throws`, and was assuming it was an alias for method type, did you really mean method type?

>> src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java line 139:
>> 
>>> 137:      *
>>> 138:      * <p>The returned segment is <em>not</em> thread-confined, and it only features
>>> 139:      * the {@link MemorySegment#CLOSE} access mode. When the returned segment is closed,
>> 
>> Implying that it is shared? If so might be better to state that directly (with a link), and can be closed explicitly or left until can be collected by the GC?
>
> `The returned segment is <em>not</em> thread-confined` ? Since it features CLOSE, it can be closed explicitly - I'm not sure 100% of what additional clarification is required - but I'm happy to make this clearer (I need more info).

Sometimes it's clearer to state the non-negative term i.e. _shared_ which is now something more explicit e.g.
> The returned segment is _shared_ [add link?] (not thread-confined)

That is really what i was trying to get at, rather than the CLOSE+GC aspects.

-------------

PR: https://git.openjdk.java.net/jdk/pull/634

From psandoz at openjdk.java.net  Thu Oct 22 16:17:19 2020
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Thu, 22 Oct 2020 16:17:19 GMT
Subject: RFR: 8254231: Implementation of Foreign Linker API (Incubator)
 [v7]
In-Reply-To: <MXCesPkhxy-D2fHC-hYBLe6DBogMjwknq7qi9FBaPsg=.dd94627f-679a-4062-b8b3-53380d36f079@github.com>
References: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
 <Rxu6c37o5dBPtGxju77Y5NfjLQNIE1yRZw-bnQz1n0k=.7c929e86-7513-49d7-90fa-1d997963050f@github.com>
 <ZGkYBBhHYxqech4xnb28ci0wZUGGlj-oiJm0hiAplUs=.ff119342-fd23-4faf-a3e1-ab31c4d067a5@github.com>
 <MXCesPkhxy-D2fHC-hYBLe6DBogMjwknq7qi9FBaPsg=.dd94627f-679a-4062-b8b3-53380d36f079@github.com>
Message-ID: <tQ-RwETlJ6wYNPZI_xQPCbwPtji3tLlODdrchZ8xzyg=.4e6b3428-7848-40ca-9ad5-174405bf60d0@github.com>

On Thu, 22 Oct 2020 14:31:12 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/invoke/NativeMethodHandle.java line 36:
>> 
>>> 34: import static java.lang.invoke.MethodHandleStatics.newInternalError;
>>> 35: 
>>> 36: /** TODO */
>> 
>> Is the TODO to make this class public later and adjust the return type of `downcallHandle`?
>
> IIRC this was added to silence a javac linter warning. Something should be added here. There is/was no plan to make this class public though.

It's odd the lint warning is triggering on a package private class and private methods. Separately, I recommend updating `make/CompileJavaModules.gmk` and adding `-Xdoclint:all/protected` for the module (i recently did this for the vector API see [here](https://github.com/openjdk/jdk/commit/000143504408ac7938e9f493c17c4dbb994045f9#diff-118e609b9974c0ce8af7950711461c7ab4620c9d4f4c99d231f598696f8e05d0)

-------------

PR: https://git.openjdk.java.net/jdk/pull/634

From psandoz at openjdk.java.net  Thu Oct 22 16:17:21 2020
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Thu, 22 Oct 2020 16:17:21 GMT
Subject: RFR: 8254231: Implementation of Foreign Linker API (Incubator)
 [v9]
In-Reply-To: <1p5weKaRsQH1q9GBnZFqKPupXb-5hYfeMm-NxaPiPUM=.db7147ad-67e0-4738-9fa7-d1afdabe3705@github.com>
References: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
 <XvFIGunZ1EjNeZNgkF_I06FjuDxHmD8jjCJ2HkpF_xE=.15ac4c1b-063a-4181-ad6b-3fd64e95b0ed@github.com>
 <KUq2-MTn5B82LZGZ0PBp4kvYEyjLyX3Rg9jtH2yKO2w=.85804c26-ea5a-4ecd-8a4f-ad475a954bd5@github.com>
 <1p5weKaRsQH1q9GBnZFqKPupXb-5hYfeMm-NxaPiPUM=.db7147ad-67e0-4738-9fa7-d1afdabe3705@github.com>
Message-ID: <4LF0LKSTD3ZkvV2kWKDqqeDAxh0mxMaB7eH2hakq7O4=.34d04357-f168-4ae2-b224-212122970e7d@github.com>

On Thu, 22 Oct 2020 14:26:37 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/AbstractNativeScope.java line 120:
>> 
>>> 118:                 }
>>> 119:             }
>>> 120:             throw new AssertionError("Cannot get here!");
>> 
>> This code is a little confusing, effectively using an exception for control flow, within a retry loop. I recommend performing an explicit bounds check to determine if a new segment of `BLOCK_SIZE` is required from which to slice into. It will also be faster than the exceptional case.
>
> I hear you - that said, note that doing the bound check is not as trivial as it seems; you have to take into account the value of `sp` and add required alignment padding, and then perform a bound check against that - all logic which would need to be duplicated across the normal and the exceptional cases. Which is why the code settled the way it is. I'll see what I can do.

Yeah, i would have probably done the same thing initially.

-------------

PR: https://git.openjdk.java.net/jdk/pull/634

From sgehwolf at openjdk.java.net  Thu Oct 22 16:28:13 2020
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Thu, 22 Oct 2020 16:28:13 GMT
Subject: RFR: 8254854: [cgroups v1] Metric limits not properly detected on
 some join controller combinations
In-Reply-To: <_NvVokiLrjdv7MUndvzthV7zDwSZ_0GlvSwr0piJwxI=.ab4db35c-ffba-4790-9c02-5ff6e19b3cf4@github.com>
References: <NpI0Y7gZOap0GTIF204zKcqpwv8G7PIarz2I8yoSX5o=.eb0dd647-192a-43dd-8e9d-c073ad098ac4@github.com>
 <eKasApGFhwvnZn2YiaiS4TGmbzLCE7FS_cKT0jTuKwI=.1ed1ee97-5c53-4716-a42e-5b8cf3e6c34b@github.com>
 <u5wBdH_YUiYUUQ30Sz1IhcZgWY7erjH1BD2j0KYwCZw=.0ecf7a54-a41f-41a6-a1fd-8cff5c6029cc@github.com>
 <_NvVokiLrjdv7MUndvzthV7zDwSZ_0GlvSwr0piJwxI=.ab4db35c-ffba-4790-9c02-5ff6e19b3cf4@github.com>
Message-ID: <ZW0WhEFtvFHAUdlbdAprSPD6rxxjtmui7ugEPcdvQv8=.006f783f-402f-42cb-b38e-b2507294a9a2@github.com>

On Thu, 22 Oct 2020 15:45:56 GMT, Bob Vandette <bobv at openjdk.org> wrote:

>> Isn't this what line 164 does?
>
> Sorry, I missed the fact that line 164 was being retained.  I just saw a lot of line removal.  Looks good.

No worries. Thank you for the review!

-------------

PR: https://git.openjdk.java.net/jdk/pull/809

From mcimadamore at openjdk.java.net  Thu Oct 22 16:34:28 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 22 Oct 2020 16:34:28 GMT
Subject: RFR: 8254231: Implementation of Foreign Linker API (Incubator)
 [v7]
In-Reply-To: <ZGkYBBhHYxqech4xnb28ci0wZUGGlj-oiJm0hiAplUs=.ff119342-fd23-4faf-a3e1-ab31c4d067a5@github.com>
References: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
 <Rxu6c37o5dBPtGxju77Y5NfjLQNIE1yRZw-bnQz1n0k=.7c929e86-7513-49d7-90fa-1d997963050f@github.com>
 <ZGkYBBhHYxqech4xnb28ci0wZUGGlj-oiJm0hiAplUs=.ff119342-fd23-4faf-a3e1-ab31c4d067a5@github.com>
Message-ID: <PBxmdTHRPCLwZNumUOuzWCibiO4HlOJLZuROyP_rJ6I=.255486a6-102e-494f-806c-1472f0d07258@github.com>

On Wed, 21 Oct 2020 19:05:42 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits:
>> 
>>  - Merge branch 'master' into 8254231_linker
>>  - Fix incorrect capitalization in one copyright header
>>  - Update copyright years, and add classpath exception to files that were missing it
>>  - Use separate constants for native invoker code size
>>  - Re-add file erroneously deleted (detected as rename)
>>  - Re-add erroneously removed files
>>  - Merge branch 'master' into 8254231_linker
>>    
>>    - Fix tests
>>  - Fix more whitespaces
>>  - Fix whitespaces
>>  - Remove rejected file
>>  - ... and 15 more: https://git.openjdk.java.net/jdk/compare/cb6167b2...502bd980
>
> Some of this is familiar to me from reviews in the `panama-foreign` repository, but less so than the memory API. I focused on the Java code, and ignored changes that are common with the memory API PR.
> 
> If it helps in can provide a PR in the `panama-foreign` repository addressing editorial comments to the linker API.

I've just uploaded a new iteration which addresses most of @PaulSandoz comments on the API/Java impl.

-------------

PR: https://git.openjdk.java.net/jdk/pull/634

From mcimadamore at openjdk.java.net  Thu Oct 22 16:34:27 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 22 Oct 2020 16:34:27 GMT
Subject: RFR: 8254231: Implementation of Foreign Linker API (Incubator)
 [v10]
In-Reply-To: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
References: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
Message-ID: <aFQhk8h76r3kMBk6pS3vvKso0HwpfN1shxJETFhy_Ss=.dc0ff80e-d6d8-4dd2-b959-c330ffe6a14f@github.com>

> This patch contains the changes associated with the first incubation round of the foreign linker access API incubation
> (see JEP 389 [1]). This work is meant to sit on top of the foreign memory access support (see JEP 393 [2] and associated pull request [3]).
> 
> The main goal of this API is to provide a way to call native functions from Java code without the need of intermediate JNI glue code. In order to do this, native calls are modeled through the MethodHandle API. I suggest reading the writeup [4] I put together few weeks ago, which illustrates what the foreign linker support is, and how it should be used by clients.
> 
> Disclaimer: the pull request mechanism isn't great at managing *dependent* reviews. For this reasons, I'm attaching a webrev which contains only the differences between this PR and the memory access PR. I will be periodically uploading new webrevs, as new iterations come out, to try and make the life of reviewers as simple as possible.
> 
> A big thank to Jorn Vernee and Vladimir Ivanov - they are the main architects of all the hotspot changes you see here, and without their help, the foreign linker support wouldn't be what it is today. As usual, a big thank to Paul Sandoz, who provided many insights (often by trying the bits first hand).
> 
> Thanks
> Maurizio
> 
> Webrev:
> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/webrev
> 
> Javadoc:
> 
> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/javadoc/jdk/incubator/foreign/package-summary.html
> 
> Specdiff (relative to [3]):
> 
> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/specdiff_delta/overview-summary.html
> 
> CSR:
> 
> https://bugs.openjdk.java.net/browse/JDK-8254232
> 
> 
> 
> ### API Changes
> 
> The API changes are actually rather slim:
> 
> * `LibraryLookup`
>   * This class allows clients to lookup symbols in native libraries; the interface is fairly simple; you can load a library by name, or absolute path, and then lookup symbols on that library.
> * `FunctionDescriptor`
>   * This is an abstraction that is very similar, in spirit, to `MethodType`; it is, at its core, an aggregate of memory layouts for the function arguments/return type. A function descriptor is used to describe the signature of a native function.
> * `CLinker`
>   * This is the real star of the show. A `CLinker` has two main methods: `downcallHandle` and `upcallStub`; the first takes a native symbol (as obtained from `LibraryLookup`), a `MethodType` and a `FunctionDescriptor` and returns a `MethodHandle` instance which can be used to call the target native symbol. The second takes an existing method handle, and a `FunctionDescriptor` and returns a new `MemorySegment` corresponding to a code stub allocated by the VM which acts as a trampoline from native code to the user-provided method handle. This is very useful for implementing upcalls.
>    * This class also contains the various layout constants that should be used by clients when describing native signatures (e.g. `C_LONG` and friends); these layouts contain additional ABI classfication information (in the form of layout attributes) which is used by the runtime to *infer* how Java arguments should be shuffled for the native call to take place.
>   * Finally, this class provides some helper functions e.g. so that clients can convert Java strings into C strings and back.
> * `NativeScope`
>   * This is an helper class which allows clients to group together logically related allocations; that is, rather than allocating separate memory segments using separate *try-with-resource* constructs, a `NativeScope` allows clients to use a _single_ block, and allocate all the required segments there. This is not only an usability boost, but also a performance boost, since not all allocation requests will be turned into `malloc` calls.
> * `MemorySegment`
>   * Only one method added here - namely `handoff(NativeScope)` which allows a segment to be transferred onto an existing native scope.
> 
> ### Safety
> 
> The foreign linker API is intrinsically unsafe; many things can go wrong when requesting a native method handle. For instance, the description of the native signature might be wrong (e.g. have too many arguments) - and the runtime has, in the general case, no way to detect such mismatches. For these reasons, obtaining a `CLinker` instance is a *restricted* operation, which can be enabled by specifying the usual JDK property `-Dforeign.restricted=permit` (as it's the case for other restricted method in the foreign memory API).
> 
> ### Implementation changes
> 
> The Java changes associated with `LibraryLookup` are relative straightforward; the only interesting thing to note here is that library loading does _not_ depend on class loaders, so `LibraryLookup` is not subject to the same restrictions which apply to JNI library loading (e.g. same library cannot be loaded by different classloaders).
> 
> As for `NativeScope` the changes are again relatively straightforward; it is an API which sits neatly on top of the foreign meory access API, providing some kind of allocation service which shares the same underlying memory segment(s), and turns an allocation request into a segment slice, which is a much less expensive operation. `NativeScope` comes in two variants: there are native scopes for which the allocation size is known a priori, and native scopes which can grow - these two schemes are implemented by two separate subclasses of `AbstractNativeScopeImpl`.
> 
> Of course the bulk of the changes are to support the `CLinker` downcall/upcall routines. These changes cut pretty deep into the JVM; I'll briefly summarize the goal of some of this changes - for further details, Jorn has put together a detailed writeup which explains the rationale behind the VM support, with some references to the code [5].
> 
> The main idea behind foreign linker is to infer, given a Java method type (expressed as a `MethodType` instance) and the description of the signature of a native function (expressed as a `FunctionDescriptor` instance) a _recipe_ that can be used to turn a Java call into the corresponding native call targeting the requested native function.
> 
> This inference scheme can be defined in a pretty straightforward fashion by looking at the various ABI specifications (for instance, see [6] for the SysV ABI, which is the one used on Linux/Mac). The various `CallArranger` classes, of which we have a flavor for each supported platform, do exactly that kind of inference.
> 
> For the inference process to work, we need to attach extra information to memory layouts; it is no longer sufficient to know e.g. that a layout is 32/64 bits - we need to know whether it is meant to represent a floating point value, or an integral value; this knowledge is required because floating points are passed in different registers by most ABIs. For this reason, `CLinker` offers a set of pre-baked, platform-dependent layout constants which contain the required classification attributes (e.g. a `Clinker.TypeKind` enum value). The runtime extracts this attribute, and performs classification accordingly.
> 
> A native call is decomposed into a sequence of basic, primitive operations, called `Binding` (see the great javadoc on the `Binding.java` class for more info). There are many such bindings - for instance the `Move` binding is used to move a value into a specific machine register/stack slot. So, the main job of the various `CallingArranger` classes is to determine, given a Java `MethodType` and `FunctionDescriptor` what is the set of bindings associated with the downcall/upcall.
> 
> At the heart of the foreign linker support is the `ProgrammableInvoker` class. This class effectively generates a `MethodHandle` which follows the steps described by the various bindings obtained by `CallArranger`. There are actually various strategies to interpret these bindings - listed below:
> 
> * basic intepreted mode; in this mode, all bindings are interpreted using a stack-based machine written in Java (see `BindingInterpreter`), except for the `Move` bindings. For these bindings, the move is implemented by allocating a *buffer* (whose size is ABI specific) and by moving all the lowered values into positions within this buffer. The buffer is then passed to a piece of assembly code inside the VM which takes values from the buffer and moves them in their expected registers/stack slots (note that each position in the buffer corresponds to a different register). This is the most general invocation mode, the more "customizable" one, but also the slowest - since for every call there is some extra allocation which takes place.
> 
> * specialized interpreted mode; same as before, but instead of interpreting the bindings with a stack-based interpreter, we generate a method handle chain which effectively interprets all the bindings (again, except `Move` ones).
> 
> * intrinsified mode; this is typically used in combination with the specialized interpreted mode described above (although it can also be used with the Java-based binding interpreter). The goal here is to remove the buffer allocation and copy by introducing an additional JVM intrinsic. If a native call recipe is constant (e.g. the set of bindings is constant, which is probably the case if the native method handle is stored in a `static`, `final` field), then the VM can generate specialized assembly code which interprets the `Move` binding without the need to go for an intermediate buffer. This gives us back performances that are on par with JNI.
> 
> For upcalls, the support is not (yet) as advanced, and only the basic interpreted mode is available there. We plan to add support for intrinsified modes there as well, which should considerably boost perfomances (probably well beyond what JNI can offer at the moment, since the upcall support in JNI is not very well optimized).
> 
> Again, for more readings on the internals of the foreign linker support, please refer to [5].
> 
> #### Test changes
> 
> Many new tests have been added to validate the foreign linker support; we have high level tests (see `StdLibTest`) which aim at testing the linker from the perspective of code that clients could write. But we also have deeper combinatorial tests (see `TestUpcall` and `TestDowncall`) which are meant to stress every corner of the ABI implementation. There are also some great tests (see the `callarranger` folder) which test the various `CallArranger`s for all the possible platforms; these tests adopt more of a white-box approach - that is, instead of treating the linker machinery as a black box and verify that the support works by checking that the native call returned the results we expected, these tests aims at checking that the set of bindings generated by the call arranger is correct. This also mean that we can test the classification logic for Windows, Mac and Linux regardless of the platform we're executing on.
> 
> Some additional microbenchmarks have been added to compare the performances of downcall/upcall with JNI.
> 
> [1] - https://openjdk.java.net/jeps/389
> [2] - https://openjdk.java.net/jeps/393
> [3] - https://git.openjdk.java.net/jdk/pull/548
> [4] - https://github.com/openjdk/panama-foreign/blob/foreign-jextract/doc/panama_ffi.md
> [5] - http://cr.openjdk.java.net/~jvernee/docs/Foreign-abi%20downcall%20intrinsics%20technical%20description.html

Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 39 commits:

 - Merge pull request #4 from JornVernee/Missing_ResourceMarks
   
   Add missing resource marks before parsing descriptors
 - Add missing resource marks before parsing descriptors
 - Fix CLinker javadoc
 - Simplify AbstractNativeScope::allocate
 - Fix most review comments
   Fix Graal intrinsics test failure
 - And more copyright fixes
 - Fix more copyright headers
 - Fix copyright of AbstractNativeScope
 - Fix aarch issues
 - Remove spurious include
 - ... and 29 more: https://git.openjdk.java.net/jdk/compare/cc50c8d4...21f50872

-------------

Changes: https://git.openjdk.java.net/jdk/pull/634/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=634&range=09
  Stats: 75773 lines in 270 files changed: 72888 ins; 1608 del; 1277 mod
  Patch: https://git.openjdk.java.net/jdk/pull/634.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/634/head:pull/634

PR: https://git.openjdk.java.net/jdk/pull/634

From mcimadamore at openjdk.java.net  Thu Oct 22 16:34:28 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 22 Oct 2020 16:34:28 GMT
Subject: RFR: 8254231: Implementation of Foreign Linker API (Incubator)
 [v7]
In-Reply-To: <tQ-RwETlJ6wYNPZI_xQPCbwPtji3tLlODdrchZ8xzyg=.4e6b3428-7848-40ca-9ad5-174405bf60d0@github.com>
References: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
 <Rxu6c37o5dBPtGxju77Y5NfjLQNIE1yRZw-bnQz1n0k=.7c929e86-7513-49d7-90fa-1d997963050f@github.com>
 <ZGkYBBhHYxqech4xnb28ci0wZUGGlj-oiJm0hiAplUs=.ff119342-fd23-4faf-a3e1-ab31c4d067a5@github.com>
 <MXCesPkhxy-D2fHC-hYBLe6DBogMjwknq7qi9FBaPsg=.dd94627f-679a-4062-b8b3-53380d36f079@github.com>
 <tQ-RwETlJ6wYNPZI_xQPCbwPtji3tLlODdrchZ8xzyg=.4e6b3428-7848-40ca-9ad5-174405bf60d0@github.com>
Message-ID: <903tobsjq6ao1evfv2CXzPE9jLfRWcVXrghBViPU4eo=.01d1f2d9-6c6e-456c-950b-632dd6619e1b@github.com>

On Thu, 22 Oct 2020 15:46:33 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> IIRC this was added to silence a javac linter warning. Something should be added here. There is/was no plan to make this class public though.
>
> It's odd the lint warning is triggering on a package private class and private methods. Separately, I recommend updating `make/CompileJavaModules.gmk` and adding `-Xdoclint:all/protected` for the module (i recently did this for the vector API see [here](https://github.com/openjdk/jdk/commit/000143504408ac7938e9f493c17c4dbb994045f9#diff-118e609b9974c0ce8af7950711461c7ab4620c9d4f4c99d231f598696f8e05d0)

There's no lint warning for private method, a fix is coming. As for makefile changes, I'd prefer to postpone after integration, or add them to the foreign memory access PR, since that's not specific to this PR.

-------------

PR: https://git.openjdk.java.net/jdk/pull/634

From mcimadamore at openjdk.java.net  Thu Oct 22 16:34:29 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 22 Oct 2020 16:34:29 GMT
Subject: RFR: 8254231: Implementation of Foreign Linker API (Incubator)
 [v9]
In-Reply-To: <KUq2-MTn5B82LZGZ0PBp4kvYEyjLyX3Rg9jtH2yKO2w=.85804c26-ea5a-4ecd-8a4f-ad475a954bd5@github.com>
References: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
 <XvFIGunZ1EjNeZNgkF_I06FjuDxHmD8jjCJ2HkpF_xE=.15ac4c1b-063a-4181-ad6b-3fd64e95b0ed@github.com>
 <KUq2-MTn5B82LZGZ0PBp4kvYEyjLyX3Rg9jtH2yKO2w=.85804c26-ea5a-4ecd-8a4f-ad475a954bd5@github.com>
Message-ID: <729-YxJZTBRSEYbheYgTYKRo2FpSlyaPCrCSfI0i67Y=.5445d130-fa23-46f3-b8ab-86ba8fafeaee@github.com>

On Wed, 21 Oct 2020 17:42:53 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> Some design considerations, to consider later maybe.
> 
> The IR representation could be simplified to use record classes (which should be exiting preview in 16), implementing a Binding interface. The interpreter and specializer (compiler) could be separate if need be, operating on a sequence of instructions that just hold the data. Pattern matching could be used on the binding instances. It may be simpler and more efficient if the compiler generated explicit byte code rather than using MH combinators.

Good suggestions - I think this is good to consider post-integration.

-------------

PR: https://git.openjdk.java.net/jdk/pull/634

From sgehwolf at openjdk.java.net  Thu Oct 22 16:43:20 2020
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Thu, 22 Oct 2020 16:43:20 GMT
Subject: Integrated: 8254854: [cgroups v1] Metric limits not properly detected
 on some join controller combinations
In-Reply-To: <NpI0Y7gZOap0GTIF204zKcqpwv8G7PIarz2I8yoSX5o=.eb0dd647-192a-43dd-8e9d-c073ad098ac4@github.com>
References: <NpI0Y7gZOap0GTIF204zKcqpwv8G7PIarz2I8yoSX5o=.eb0dd647-192a-43dd-8e9d-c073ad098ac4@github.com>
Message-ID: <yHfolA1VqmTxrtv-gocamKsx3sydgWxSUXOxUzsCb6I=.f7c35dcc-fa7d-4abb-8049-194bf832d87e@github.com>

On Thu, 22 Oct 2020 14:17:56 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Originally only join controllers of form `cpu,cpuacct` would have been recognized.
> However, this fails if more controllers are joined at a certain path.
> 
> The proposed fix is to be sure to split join controllers on `,` and set the path
> accordingly. Otherwise, the Metrics system might be initialized due to some
> non-join controllers, yet the limits for join controllers wouldn't be detected. A
> test for this can be added once [JDK-8254001](https://bugs.openjdk.java.net/browse/JDK-8254001) has been implemented.
> 
> Testing:
> 
> - [x] jdk/submit
> - [x] container tests on Linux cgroups v1 system.
> 
> Thoughts?

This pull request has now been integrated.

Changeset: a0b687bf
Author:    Severin Gehwolf <sgehwolf at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a0b687bf
Stats:     36 lines in 1 file changed: 3 ins; 10 del; 23 mod

8254854: [cgroups v1] Metric limits not properly detected on some join controller combinations

Reviewed-by: bobv

-------------

PR: https://git.openjdk.java.net/jdk/pull/809

From mcimadamore at openjdk.java.net  Thu Oct 22 16:57:30 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 22 Oct 2020 16:57:30 GMT
Subject: RFR: 8254231: Implementation of Foreign Linker API (Incubator)
 [v11]
In-Reply-To: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
References: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
Message-ID: <F8lFQncjOqCH0U6DjO6yuUgf1JXHc0OqPzgpUu48OcI=.24aeead3-5440-4da0-ac1a-d15ff7bc1eb1@github.com>

> This patch contains the changes associated with the first incubation round of the foreign linker access API incubation
> (see JEP 389 [1]). This work is meant to sit on top of the foreign memory access support (see JEP 393 [2] and associated pull request [3]).
> 
> The main goal of this API is to provide a way to call native functions from Java code without the need of intermediate JNI glue code. In order to do this, native calls are modeled through the MethodHandle API. I suggest reading the writeup [4] I put together few weeks ago, which illustrates what the foreign linker support is, and how it should be used by clients.
> 
> Disclaimer: the pull request mechanism isn't great at managing *dependent* reviews. For this reasons, I'm attaching a webrev which contains only the differences between this PR and the memory access PR. I will be periodically uploading new webrevs, as new iterations come out, to try and make the life of reviewers as simple as possible.
> 
> A big thank to Jorn Vernee and Vladimir Ivanov - they are the main architects of all the hotspot changes you see here, and without their help, the foreign linker support wouldn't be what it is today. As usual, a big thank to Paul Sandoz, who provided many insights (often by trying the bits first hand).
> 
> Thanks
> Maurizio
> 
> Webrev:
> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/webrev
> 
> Javadoc:
> 
> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/javadoc/jdk/incubator/foreign/package-summary.html
> 
> Specdiff (relative to [3]):
> 
> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/specdiff_delta/overview-summary.html
> 
> CSR:
> 
> https://bugs.openjdk.java.net/browse/JDK-8254232
> 
> 
> 
> ### API Changes
> 
> The API changes are actually rather slim:
> 
> * `LibraryLookup`
>   * This class allows clients to lookup symbols in native libraries; the interface is fairly simple; you can load a library by name, or absolute path, and then lookup symbols on that library.
> * `FunctionDescriptor`
>   * This is an abstraction that is very similar, in spirit, to `MethodType`; it is, at its core, an aggregate of memory layouts for the function arguments/return type. A function descriptor is used to describe the signature of a native function.
> * `CLinker`
>   * This is the real star of the show. A `CLinker` has two main methods: `downcallHandle` and `upcallStub`; the first takes a native symbol (as obtained from `LibraryLookup`), a `MethodType` and a `FunctionDescriptor` and returns a `MethodHandle` instance which can be used to call the target native symbol. The second takes an existing method handle, and a `FunctionDescriptor` and returns a new `MemorySegment` corresponding to a code stub allocated by the VM which acts as a trampoline from native code to the user-provided method handle. This is very useful for implementing upcalls.
>    * This class also contains the various layout constants that should be used by clients when describing native signatures (e.g. `C_LONG` and friends); these layouts contain additional ABI classfication information (in the form of layout attributes) which is used by the runtime to *infer* how Java arguments should be shuffled for the native call to take place.
>   * Finally, this class provides some helper functions e.g. so that clients can convert Java strings into C strings and back.
> * `NativeScope`
>   * This is an helper class which allows clients to group together logically related allocations; that is, rather than allocating separate memory segments using separate *try-with-resource* constructs, a `NativeScope` allows clients to use a _single_ block, and allocate all the required segments there. This is not only an usability boost, but also a performance boost, since not all allocation requests will be turned into `malloc` calls.
> * `MemorySegment`
>   * Only one method added here - namely `handoff(NativeScope)` which allows a segment to be transferred onto an existing native scope.
> 
> ### Safety
> 
> The foreign linker API is intrinsically unsafe; many things can go wrong when requesting a native method handle. For instance, the description of the native signature might be wrong (e.g. have too many arguments) - and the runtime has, in the general case, no way to detect such mismatches. For these reasons, obtaining a `CLinker` instance is a *restricted* operation, which can be enabled by specifying the usual JDK property `-Dforeign.restricted=permit` (as it's the case for other restricted method in the foreign memory API).
> 
> ### Implementation changes
> 
> The Java changes associated with `LibraryLookup` are relative straightforward; the only interesting thing to note here is that library loading does _not_ depend on class loaders, so `LibraryLookup` is not subject to the same restrictions which apply to JNI library loading (e.g. same library cannot be loaded by different classloaders).
> 
> As for `NativeScope` the changes are again relatively straightforward; it is an API which sits neatly on top of the foreign meory access API, providing some kind of allocation service which shares the same underlying memory segment(s), and turns an allocation request into a segment slice, which is a much less expensive operation. `NativeScope` comes in two variants: there are native scopes for which the allocation size is known a priori, and native scopes which can grow - these two schemes are implemented by two separate subclasses of `AbstractNativeScopeImpl`.
> 
> Of course the bulk of the changes are to support the `CLinker` downcall/upcall routines. These changes cut pretty deep into the JVM; I'll briefly summarize the goal of some of this changes - for further details, Jorn has put together a detailed writeup which explains the rationale behind the VM support, with some references to the code [5].
> 
> The main idea behind foreign linker is to infer, given a Java method type (expressed as a `MethodType` instance) and the description of the signature of a native function (expressed as a `FunctionDescriptor` instance) a _recipe_ that can be used to turn a Java call into the corresponding native call targeting the requested native function.
> 
> This inference scheme can be defined in a pretty straightforward fashion by looking at the various ABI specifications (for instance, see [6] for the SysV ABI, which is the one used on Linux/Mac). The various `CallArranger` classes, of which we have a flavor for each supported platform, do exactly that kind of inference.
> 
> For the inference process to work, we need to attach extra information to memory layouts; it is no longer sufficient to know e.g. that a layout is 32/64 bits - we need to know whether it is meant to represent a floating point value, or an integral value; this knowledge is required because floating points are passed in different registers by most ABIs. For this reason, `CLinker` offers a set of pre-baked, platform-dependent layout constants which contain the required classification attributes (e.g. a `Clinker.TypeKind` enum value). The runtime extracts this attribute, and performs classification accordingly.
> 
> A native call is decomposed into a sequence of basic, primitive operations, called `Binding` (see the great javadoc on the `Binding.java` class for more info). There are many such bindings - for instance the `Move` binding is used to move a value into a specific machine register/stack slot. So, the main job of the various `CallingArranger` classes is to determine, given a Java `MethodType` and `FunctionDescriptor` what is the set of bindings associated with the downcall/upcall.
> 
> At the heart of the foreign linker support is the `ProgrammableInvoker` class. This class effectively generates a `MethodHandle` which follows the steps described by the various bindings obtained by `CallArranger`. There are actually various strategies to interpret these bindings - listed below:
> 
> * basic intepreted mode; in this mode, all bindings are interpreted using a stack-based machine written in Java (see `BindingInterpreter`), except for the `Move` bindings. For these bindings, the move is implemented by allocating a *buffer* (whose size is ABI specific) and by moving all the lowered values into positions within this buffer. The buffer is then passed to a piece of assembly code inside the VM which takes values from the buffer and moves them in their expected registers/stack slots (note that each position in the buffer corresponds to a different register). This is the most general invocation mode, the more "customizable" one, but also the slowest - since for every call there is some extra allocation which takes place.
> 
> * specialized interpreted mode; same as before, but instead of interpreting the bindings with a stack-based interpreter, we generate a method handle chain which effectively interprets all the bindings (again, except `Move` ones).
> 
> * intrinsified mode; this is typically used in combination with the specialized interpreted mode described above (although it can also be used with the Java-based binding interpreter). The goal here is to remove the buffer allocation and copy by introducing an additional JVM intrinsic. If a native call recipe is constant (e.g. the set of bindings is constant, which is probably the case if the native method handle is stored in a `static`, `final` field), then the VM can generate specialized assembly code which interprets the `Move` binding without the need to go for an intermediate buffer. This gives us back performances that are on par with JNI.
> 
> For upcalls, the support is not (yet) as advanced, and only the basic interpreted mode is available there. We plan to add support for intrinsified modes there as well, which should considerably boost perfomances (probably well beyond what JNI can offer at the moment, since the upcall support in JNI is not very well optimized).
> 
> Again, for more readings on the internals of the foreign linker support, please refer to [5].
> 
> #### Test changes
> 
> Many new tests have been added to validate the foreign linker support; we have high level tests (see `StdLibTest`) which aim at testing the linker from the perspective of code that clients could write. But we also have deeper combinatorial tests (see `TestUpcall` and `TestDowncall`) which are meant to stress every corner of the ABI implementation. There are also some great tests (see the `callarranger` folder) which test the various `CallArranger`s for all the possible platforms; these tests adopt more of a white-box approach - that is, instead of treating the linker machinery as a black box and verify that the support works by checking that the native call returned the results we expected, these tests aims at checking that the set of bindings generated by the call arranger is correct. This also mean that we can test the classification logic for Windows, Mac and Linux regardless of the platform we're executing on.
> 
> Some additional microbenchmarks have been added to compare the performances of downcall/upcall with JNI.
> 
> [1] - https://openjdk.java.net/jeps/389
> [2] - https://openjdk.java.net/jeps/393
> [3] - https://git.openjdk.java.net/jdk/pull/548
> [4] - https://github.com/openjdk/panama-foreign/blob/foreign-jextract/doc/panama_ffi.md
> [5] - http://cr.openjdk.java.net/~jvernee/docs/Foreign-abi%20downcall%20intrinsics%20technical%20description.html

Maurizio Cimadamore has updated the pull request incrementally with three additional commits since the last revision:

 - Merge pull request #2 from JornVernee/No_JNI_Comments_v2
   
   Address Coleen's review comments on "Don't use JNI when generating native wrappers"
 - Merge branch '8254231_linker' into No_JNI_Comments_v2
 - Review comments:
   - Use TempNewSymbol
   - JVM_* -> JNI_*
   - rename parseXX -> parse_x_x
   - remove ref to global function using '::'
   - make 2 functions static, instead of ForeignGlobals class members

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/634/files
  - new: https://git.openjdk.java.net/jdk/pull/634/files/21f50872..0c892293

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=634&range=10
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=634&range=09-10

  Stats: 64 lines in 12 files changed: 6 ins; 20 del; 38 mod
  Patch: https://git.openjdk.java.net/jdk/pull/634.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/634/head:pull/634

PR: https://git.openjdk.java.net/jdk/pull/634

From jvernee at openjdk.java.net  Thu Oct 22 16:57:31 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Thu, 22 Oct 2020 16:57:31 GMT
Subject: RFR: 8254231: Implementation of Foreign Linker API (Incubator)
 [v7]
In-Reply-To: <PBxmdTHRPCLwZNumUOuzWCibiO4HlOJLZuROyP_rJ6I=.255486a6-102e-494f-806c-1472f0d07258@github.com>
References: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
 <Rxu6c37o5dBPtGxju77Y5NfjLQNIE1yRZw-bnQz1n0k=.7c929e86-7513-49d7-90fa-1d997963050f@github.com>
 <ZGkYBBhHYxqech4xnb28ci0wZUGGlj-oiJm0hiAplUs=.ff119342-fd23-4faf-a3e1-ab31c4d067a5@github.com>
 <PBxmdTHRPCLwZNumUOuzWCibiO4HlOJLZuROyP_rJ6I=.255486a6-102e-494f-806c-1472f0d07258@github.com>
Message-ID: <htzQBC1GnZwoO1Vh8jsP6M7PCbLIT47PFBt3ozUJkUs=.665b46cf-8b42-425c-863c-3f6861b10054@github.com>

On Thu, 22 Oct 2020 16:31:00 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Some of this is familiar to me from reviews in the `panama-foreign` repository, but less so than the memory API. I focused on the Java code, and ignored changes that are common with the memory API PR.
>> 
>> If it helps in can provide a PR in the `panama-foreign` repository addressing editorial comments to the linker API.
>
> I've just uploaded a new iteration which addresses most of @PaulSandoz comments on the API/Java impl.

The most recent changes address Coleen's review comments on: #1

The changes I've made are:
- Use TempNewSymbol when creating a symbol in field_offset & find_InstanceKlass
- change JVM_* macros -> JNI_*
- rename parseABIDescritpor & parseBufferLayout -> parse_abi_descriptor & parse_buffer_layout
- remove ref to global function using '::', by merging the 2 functions together
- make 2 functions static, instead of ForeignGlobals class members

-------------

PR: https://git.openjdk.java.net/jdk/pull/634

From mcimadamore at openjdk.java.net  Thu Oct 22 17:04:34 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 22 Oct 2020 17:04:34 GMT
Subject: RFR: 8254231: Implementation of Foreign Linker API (Incubator)
 [v12]
In-Reply-To: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
References: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
Message-ID: <2IKx6cpc-IGP3jZtr0s2I14BWM6ptyFD26szPl3b1ng=.9d956b98-dfe6-4a45-a371-bf86923214fb@github.com>

> This patch contains the changes associated with the first incubation round of the foreign linker access API incubation
> (see JEP 389 [1]). This work is meant to sit on top of the foreign memory access support (see JEP 393 [2] and associated pull request [3]).
> 
> The main goal of this API is to provide a way to call native functions from Java code without the need of intermediate JNI glue code. In order to do this, native calls are modeled through the MethodHandle API. I suggest reading the writeup [4] I put together few weeks ago, which illustrates what the foreign linker support is, and how it should be used by clients.
> 
> Disclaimer: the pull request mechanism isn't great at managing *dependent* reviews. For this reasons, I'm attaching a webrev which contains only the differences between this PR and the memory access PR. I will be periodically uploading new webrevs, as new iterations come out, to try and make the life of reviewers as simple as possible.
> 
> A big thank to Jorn Vernee and Vladimir Ivanov - they are the main architects of all the hotspot changes you see here, and without their help, the foreign linker support wouldn't be what it is today. As usual, a big thank to Paul Sandoz, who provided many insights (often by trying the bits first hand).
> 
> Thanks
> Maurizio
> 
> Webrev:
> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/webrev
> 
> Javadoc:
> 
> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/javadoc/jdk/incubator/foreign/package-summary.html
> 
> Specdiff (relative to [3]):
> 
> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/specdiff_delta/overview-summary.html
> 
> CSR:
> 
> https://bugs.openjdk.java.net/browse/JDK-8254232
> 
> 
> 
> ### API Changes
> 
> The API changes are actually rather slim:
> 
> * `LibraryLookup`
>   * This class allows clients to lookup symbols in native libraries; the interface is fairly simple; you can load a library by name, or absolute path, and then lookup symbols on that library.
> * `FunctionDescriptor`
>   * This is an abstraction that is very similar, in spirit, to `MethodType`; it is, at its core, an aggregate of memory layouts for the function arguments/return type. A function descriptor is used to describe the signature of a native function.
> * `CLinker`
>   * This is the real star of the show. A `CLinker` has two main methods: `downcallHandle` and `upcallStub`; the first takes a native symbol (as obtained from `LibraryLookup`), a `MethodType` and a `FunctionDescriptor` and returns a `MethodHandle` instance which can be used to call the target native symbol. The second takes an existing method handle, and a `FunctionDescriptor` and returns a new `MemorySegment` corresponding to a code stub allocated by the VM which acts as a trampoline from native code to the user-provided method handle. This is very useful for implementing upcalls.
>    * This class also contains the various layout constants that should be used by clients when describing native signatures (e.g. `C_LONG` and friends); these layouts contain additional ABI classfication information (in the form of layout attributes) which is used by the runtime to *infer* how Java arguments should be shuffled for the native call to take place.
>   * Finally, this class provides some helper functions e.g. so that clients can convert Java strings into C strings and back.
> * `NativeScope`
>   * This is an helper class which allows clients to group together logically related allocations; that is, rather than allocating separate memory segments using separate *try-with-resource* constructs, a `NativeScope` allows clients to use a _single_ block, and allocate all the required segments there. This is not only an usability boost, but also a performance boost, since not all allocation requests will be turned into `malloc` calls.
> * `MemorySegment`
>   * Only one method added here - namely `handoff(NativeScope)` which allows a segment to be transferred onto an existing native scope.
> 
> ### Safety
> 
> The foreign linker API is intrinsically unsafe; many things can go wrong when requesting a native method handle. For instance, the description of the native signature might be wrong (e.g. have too many arguments) - and the runtime has, in the general case, no way to detect such mismatches. For these reasons, obtaining a `CLinker` instance is a *restricted* operation, which can be enabled by specifying the usual JDK property `-Dforeign.restricted=permit` (as it's the case for other restricted method in the foreign memory API).
> 
> ### Implementation changes
> 
> The Java changes associated with `LibraryLookup` are relative straightforward; the only interesting thing to note here is that library loading does _not_ depend on class loaders, so `LibraryLookup` is not subject to the same restrictions which apply to JNI library loading (e.g. same library cannot be loaded by different classloaders).
> 
> As for `NativeScope` the changes are again relatively straightforward; it is an API which sits neatly on top of the foreign meory access API, providing some kind of allocation service which shares the same underlying memory segment(s), and turns an allocation request into a segment slice, which is a much less expensive operation. `NativeScope` comes in two variants: there are native scopes for which the allocation size is known a priori, and native scopes which can grow - these two schemes are implemented by two separate subclasses of `AbstractNativeScopeImpl`.
> 
> Of course the bulk of the changes are to support the `CLinker` downcall/upcall routines. These changes cut pretty deep into the JVM; I'll briefly summarize the goal of some of this changes - for further details, Jorn has put together a detailed writeup which explains the rationale behind the VM support, with some references to the code [5].
> 
> The main idea behind foreign linker is to infer, given a Java method type (expressed as a `MethodType` instance) and the description of the signature of a native function (expressed as a `FunctionDescriptor` instance) a _recipe_ that can be used to turn a Java call into the corresponding native call targeting the requested native function.
> 
> This inference scheme can be defined in a pretty straightforward fashion by looking at the various ABI specifications (for instance, see [6] for the SysV ABI, which is the one used on Linux/Mac). The various `CallArranger` classes, of which we have a flavor for each supported platform, do exactly that kind of inference.
> 
> For the inference process to work, we need to attach extra information to memory layouts; it is no longer sufficient to know e.g. that a layout is 32/64 bits - we need to know whether it is meant to represent a floating point value, or an integral value; this knowledge is required because floating points are passed in different registers by most ABIs. For this reason, `CLinker` offers a set of pre-baked, platform-dependent layout constants which contain the required classification attributes (e.g. a `Clinker.TypeKind` enum value). The runtime extracts this attribute, and performs classification accordingly.
> 
> A native call is decomposed into a sequence of basic, primitive operations, called `Binding` (see the great javadoc on the `Binding.java` class for more info). There are many such bindings - for instance the `Move` binding is used to move a value into a specific machine register/stack slot. So, the main job of the various `CallingArranger` classes is to determine, given a Java `MethodType` and `FunctionDescriptor` what is the set of bindings associated with the downcall/upcall.
> 
> At the heart of the foreign linker support is the `ProgrammableInvoker` class. This class effectively generates a `MethodHandle` which follows the steps described by the various bindings obtained by `CallArranger`. There are actually various strategies to interpret these bindings - listed below:
> 
> * basic intepreted mode; in this mode, all bindings are interpreted using a stack-based machine written in Java (see `BindingInterpreter`), except for the `Move` bindings. For these bindings, the move is implemented by allocating a *buffer* (whose size is ABI specific) and by moving all the lowered values into positions within this buffer. The buffer is then passed to a piece of assembly code inside the VM which takes values from the buffer and moves them in their expected registers/stack slots (note that each position in the buffer corresponds to a different register). This is the most general invocation mode, the more "customizable" one, but also the slowest - since for every call there is some extra allocation which takes place.
> 
> * specialized interpreted mode; same as before, but instead of interpreting the bindings with a stack-based interpreter, we generate a method handle chain which effectively interprets all the bindings (again, except `Move` ones).
> 
> * intrinsified mode; this is typically used in combination with the specialized interpreted mode described above (although it can also be used with the Java-based binding interpreter). The goal here is to remove the buffer allocation and copy by introducing an additional JVM intrinsic. If a native call recipe is constant (e.g. the set of bindings is constant, which is probably the case if the native method handle is stored in a `static`, `final` field), then the VM can generate specialized assembly code which interprets the `Move` binding without the need to go for an intermediate buffer. This gives us back performances that are on par with JNI.
> 
> For upcalls, the support is not (yet) as advanced, and only the basic interpreted mode is available there. We plan to add support for intrinsified modes there as well, which should considerably boost perfomances (probably well beyond what JNI can offer at the moment, since the upcall support in JNI is not very well optimized).
> 
> Again, for more readings on the internals of the foreign linker support, please refer to [5].
> 
> #### Test changes
> 
> Many new tests have been added to validate the foreign linker support; we have high level tests (see `StdLibTest`) which aim at testing the linker from the perspective of code that clients could write. But we also have deeper combinatorial tests (see `TestUpcall` and `TestDowncall`) which are meant to stress every corner of the ABI implementation. There are also some great tests (see the `callarranger` folder) which test the various `CallArranger`s for all the possible platforms; these tests adopt more of a white-box approach - that is, instead of treating the linker machinery as a black box and verify that the support works by checking that the native call returned the results we expected, these tests aims at checking that the set of bindings generated by the call arranger is correct. This also mean that we can test the classification logic for Windows, Mac and Linux regardless of the platform we're executing on.
> 
> Some additional microbenchmarks have been added to compare the performances of downcall/upcall with JNI.
> 
> [1] - https://openjdk.java.net/jeps/389
> [2] - https://openjdk.java.net/jeps/393
> [3] - https://git.openjdk.java.net/jdk/pull/548
> [4] - https://github.com/openjdk/panama-foreign/blob/foreign-jextract/doc/panama_ffi.md
> [5] - http://cr.openjdk.java.net/~jvernee/docs/Foreign-abi%20downcall%20intrinsics%20technical%20description.html

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Fix whitespaces

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/634/files
  - new: https://git.openjdk.java.net/jdk/pull/634/files/0c892293..2c2d2a70

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=634&range=11
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=634&range=10-11

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/634.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/634/head:pull/634

PR: https://git.openjdk.java.net/jdk/pull/634

From mchung at openjdk.java.net  Thu Oct 22 17:11:13 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Thu, 22 Oct 2020 17:11:13 GMT
Subject: RFR: 8159746: (proxy) Support for default methods
In-Reply-To: <yN0JJE9mBkqz9Ijbw4FYinv08tcnxiZHAGyarXBF9CY=.50429cb9-181a-447e-90a0-e0a0a836812e@github.com>
References: <kw2VXh3vTFf1zgfd4biXA41OKffZ5oU7KT23tXAxgUA=.bcf14ffc-4dba-4c9c-8754-184172c5acbd@github.com>
 <U-6RiCpFVIrhLztPN6opiPcpFtxValDzU-K7WWFZM-4=.6bc8aaa4-636a-4664-b380-4c4af00513bd@github.com>
 <-cLIJ8pFHtnNoJMHV3aXI7XMJWp4Jrutc8Xn5PG0OK8=.d2cd87ab-3592-4524-ad85-05444c43689b@github.com>
 <r0UK2qjnmgeTNDDSWaSLPAj3QRgx_4YB82ielllO7jM=.fa615bc0-db49-4a74-b842-793f8f5209bb@github.com>
 <1T8kXDZN1bhHr4c8v4SQsImeBySCqTfX-u3_jzvyocA=.b4957400-9a33-4b6e-8475-329642a5888c@github.com>
 <XIux-dY0JXHRafHk48kVNXId9r-HSceNSytBojDxelY=.872e74cb-b064-406e-b71f-13c90ec7fbbc@github.com>
 <j4t2vT0SnwnU7lhKRlXtk967d-K6nA0EqHrqNbba7W0=.dc05dba6-bf7e-4606-8a02-9c2bad4b3b58@github.com>
 <fmVtPcBdgMuZOPm2qx3Q3znVZM7JgQPkhPAVLtwkOhE=.2d8b8447-cfae-4cb3-9a7c-6567a881231f@github.com>
 <GSeWP29fAIUFSk0CYsC557w52CuLqeUWwHNK9maltwI=.3d5f002e-6b74-4a57-a5d8-244d27da9dde@github.com>
 <GF8iEOkMUEL2dYB0HytFIc9gyeeUJ_KP0ImlqFsul2Y=.894afc05-9310-43e1-a308-8f7d71dc572b@github.com>
 <HvtDex3cmiv7XeTMITOroYfu74amSGQavQ_
 BAmVzmXw=.223be989-7c20-4ba4-ac0d-013d2b75a8cb@github.com>
 <IqRiLphFPBpGiKAnMJXqxjie9YeZ03rcE-qG1s92BLw=.d4fd5e92-5067-40df-8a0b-1dfd3d6e23af@github.com>
 <Y0hE51G3YefI6NY1O_E6VoZSKwxE78S1hv6fEatmOG8=.0a2c686c-d9ad-418c-8c1b-49addb8a54b1@github.com>
 <QrNk57L2PWQhJjzYiGTsvYyGIPAfK7bP_kANtTR-2uM=.3e5ce990-f8ea-4751-8147-27a8a9dad40d@github.com>
 <9JNNUzfV3PSvKtSg2a_zyYJmgEn3sZL9cb5sfqemk2o=.f1ef7fb7-bdd5-44ed-98c8-59213e9094f9@github.com>
 <zWGhaC8YB5I0XgffiR7o_YT5gSp9Gbj8Drtt23brl-c=.1e59f0e4-bbe3-4fb2-94dc-c55fc862f091@github.com>
 <LljojgqBhEi6tFptsbmu1jS-Xx7lYEXm9tRkkPqDGzE=.3d7d6a37-1042-4539-88d1-9f4cf5378128@github.com>
 <Gn33ydZNxqOpWUrmYiWJadMF0mukI2MR85EtgrV4D1I=.958521f2-1167-4a68-b513-e10bba37ae18@github.com>
 <NMXKaHql9XjndqPgyoN1Lasa9H8ugl8-ltD1j2XiT9Y=.3ff8871e-0f9d-40ea-8f35-e804a9afcbd5@github.com>
 <yzFe02HJ2qt5tT8tY9ZOofnKld93x1PM5U7AToTABJs=.439c213b-94b9-488f-bb6d-a835a86c527f@github.com>
 <BoATjx7PPcLpINJVC5HM77UKMriIUqnnhcBowkJRlvM=.1221e3e1-ed27-4618-8365-dcd903d27f60@
 github.com>
 <yN0JJE9mBkqz9Ijbw4FYinv08tcnxiZHAGyarXBF9CY=.50429cb9-181a-447e-90a0-e0a0a836812e@github.com>
Message-ID: <CoqZRJ39DVdNI9wzS372aAG3ZIB7hrIrndaO5VrsmBA=.f78629d2-3409-44c1-9e66-7951bbd630e6@github.com>

On Thu, 22 Oct 2020 14:23:13 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> NewInvocationHandler/DefaultMethodInvoker feels a bit awkward. If I have it right, to use it as a lambda expression to Proxy.newProxyInterface would require casting to NewInvocationHandler. I also need to be careful when using the invoker and not call it with a non-default method.

Yes it requires casting to `NewInvocationHandler` or  assign the lambda in a local variable.

-------------

PR: https://git.openjdk.java.net/jdk/pull/313

From jjg at openjdk.java.net  Thu Oct 22 17:29:21 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Thu, 22 Oct 2020 17:29:21 GMT
Subject: RFR: JDK-8255262: Remove use of legacy custom @spec tag
Message-ID: <U4tky8tp6zbW2FAH956Ple4uIqsj6LYurYjOZxrO5Is=.c62b5e85-3ec2-4eea-8d8e-20d00cb32dfe@github.com>

The change is (just) to remove legacy usages of a JDK-private custom tag.

-------------

Commit messages:
 - JDK-8255262: Remove use of legacy custom @spec tag

Changes: https://git.openjdk.java.net/jdk/pull/814/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=814&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8255262
  Stats: 209 lines in 69 files changed: 0 ins; 209 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/814.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/814/head:pull/814

PR: https://git.openjdk.java.net/jdk/pull/814

From lancea at openjdk.java.net  Thu Oct 22 17:35:15 2020
From: lancea at openjdk.java.net (Lance Andersen)
Date: Thu, 22 Oct 2020 17:35:15 GMT
Subject: RFR: JDK-8255262: Remove use of legacy custom @spec tag
In-Reply-To: <U4tky8tp6zbW2FAH956Ple4uIqsj6LYurYjOZxrO5Is=.c62b5e85-3ec2-4eea-8d8e-20d00cb32dfe@github.com>
References: <U4tky8tp6zbW2FAH956Ple4uIqsj6LYurYjOZxrO5Is=.c62b5e85-3ec2-4eea-8d8e-20d00cb32dfe@github.com>
Message-ID: <YqDdpupjEAA42B4PFVQOO5Chtneb-DXRonDYRk0g1oU=.84fb141b-90cd-4c59-a0ca-e2e749898547@github.com>

On Thu, 22 Oct 2020 17:16:23 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> The change is (just) to remove legacy usages of a JDK-private custom tag.

looks fine

-------------

Marked as reviewed by lancea (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/814

From iris at openjdk.java.net  Thu Oct 22 17:46:16 2020
From: iris at openjdk.java.net (Iris Clark)
Date: Thu, 22 Oct 2020 17:46:16 GMT
Subject: RFR: JDK-8255262: Remove use of legacy custom @spec tag
In-Reply-To: <U4tky8tp6zbW2FAH956Ple4uIqsj6LYurYjOZxrO5Is=.c62b5e85-3ec2-4eea-8d8e-20d00cb32dfe@github.com>
References: <U4tky8tp6zbW2FAH956Ple4uIqsj6LYurYjOZxrO5Is=.c62b5e85-3ec2-4eea-8d8e-20d00cb32dfe@github.com>
Message-ID: <-NCS5lF0mdeaDq1CyQYTrh0gGVozPafltjNYsEpO488=.d795b2ec-acc2-4c06-8434-757b2095e386@github.com>

On Thu, 22 Oct 2020 17:16:23 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> The change is (just) to remove legacy usages of a JDK-private custom tag.

Nice clean-up.

-------------

Marked as reviewed by iris (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/814

From mr at openjdk.java.net  Thu Oct 22 17:46:15 2020
From: mr at openjdk.java.net (Mark Reinhold)
Date: Thu, 22 Oct 2020 17:46:15 GMT
Subject: RFR: JDK-8255262: Remove use of legacy custom @spec tag
In-Reply-To: <U4tky8tp6zbW2FAH956Ple4uIqsj6LYurYjOZxrO5Is=.c62b5e85-3ec2-4eea-8d8e-20d00cb32dfe@github.com>
References: <U4tky8tp6zbW2FAH956Ple4uIqsj6LYurYjOZxrO5Is=.c62b5e85-3ec2-4eea-8d8e-20d00cb32dfe@github.com>
Message-ID: <IBnKE7sN9xlVAuD9BAutsshS8xqFrfZiksTR1Vy7KYs=.c10a9cd1-b81a-491d-85ba-fa5785b224eb@github.com>

On Thu, 22 Oct 2020 17:16:23 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> The change is (just) to remove legacy usages of a JDK-private custom tag.

As the creator of these tags many moons ago, I approve this change.

-------------

Marked as reviewed by mr (Lead).

PR: https://git.openjdk.java.net/jdk/pull/814

From darcy at openjdk.java.net  Thu Oct 22 17:46:18 2020
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 22 Oct 2020 17:46:18 GMT
Subject: RFR: JDK-8255262: Remove use of legacy custom @spec tag
In-Reply-To: <U4tky8tp6zbW2FAH956Ple4uIqsj6LYurYjOZxrO5Is=.c62b5e85-3ec2-4eea-8d8e-20d00cb32dfe@github.com>
References: <U4tky8tp6zbW2FAH956Ple4uIqsj6LYurYjOZxrO5Is=.c62b5e85-3ec2-4eea-8d8e-20d00cb32dfe@github.com>
Message-ID: <5hlum1g6yK7pF3TkDMBvYSlK0Ca3bVh1VM3XJUVAvCk=.93e60ef2-400c-4775-a4c5-1f290e14ed57@github.com>

On Thu, 22 Oct 2020 17:16:23 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> The change is (just) to remove legacy usages of a JDK-private custom tag.

Marked as reviewed by darcy (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/814

From alanb at openjdk.java.net  Thu Oct 22 17:46:17 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 22 Oct 2020 17:46:17 GMT
Subject: RFR: JDK-8255262: Remove use of legacy custom @spec tag
In-Reply-To: <U4tky8tp6zbW2FAH956Ple4uIqsj6LYurYjOZxrO5Is=.c62b5e85-3ec2-4eea-8d8e-20d00cb32dfe@github.com>
References: <U4tky8tp6zbW2FAH956Ple4uIqsj6LYurYjOZxrO5Is=.c62b5e85-3ec2-4eea-8d8e-20d00cb32dfe@github.com>
Message-ID: <TOmCzg8UsQNgcxFkhfFIrZ3pPjnJQR_wRxMmuQ5z1tc=.82fb45d2-9a57-42ed-b7bc-bffc6a0ffcac@github.com>

On Thu, 22 Oct 2020 17:16:23 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> The change is (just) to remove legacy usages of a JDK-private custom tag.

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/814

From mchung at openjdk.java.net  Thu Oct 22 17:56:16 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Thu, 22 Oct 2020 17:56:16 GMT
Subject: RFR: JDK-8255262: Remove use of legacy custom @spec tag
In-Reply-To: <U4tky8tp6zbW2FAH956Ple4uIqsj6LYurYjOZxrO5Is=.c62b5e85-3ec2-4eea-8d8e-20d00cb32dfe@github.com>
References: <U4tky8tp6zbW2FAH956Ple4uIqsj6LYurYjOZxrO5Is=.c62b5e85-3ec2-4eea-8d8e-20d00cb32dfe@github.com>
Message-ID: <CfzmVDcf7nrnyFKDthPyHgl0oxzB3mhVX-O_HeNK4ak=.ad190ae9-cdad-4ecf-a831-025ca3449893@github.com>

On Thu, 22 Oct 2020 17:16:23 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> The change is (just) to remove legacy usages of a JDK-private custom tag.

Marked as reviewed by mchung (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/814

From mdoerr at openjdk.java.net  Thu Oct 22 18:13:23 2020
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Thu, 22 Oct 2020 18:13:23 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v8]
In-Reply-To: <r_UoYsBul9SV88OG2z5qfeCfKQFCF23_DDfdB1LKlzY=.2df9f9a4-d0b6-4ac6-b75b-1cd59022eca6@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <nU4nZ9oCthDEi7olxerj_bkmWuITInbbNzJKkb1shkY=.28b4ed81-9733-4981-b6fb-c8e4e3bd335e@github.com>
 <r_UoYsBul9SV88OG2z5qfeCfKQFCF23_DDfdB1LKlzY=.2df9f9a4-d0b6-4ac6-b75b-1cd59022eca6@github.com>
Message-ID: <iD4pt7fK5AExXfPuONZnrjoFTNmHO7T96s_9KCiBYTM=.64012cef-fd79-4692-a029-2b75391bd193@github.com>

On Thu, 22 Oct 2020 14:01:05 GMT, Paul Murphy <github.com+12972156+pmur at openjdk.org> wrote:

>> CoreyAshford has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   TestBase64.java: remove jdk.test.lib.Utils from @build which was causing Tier3 failures.
>
> src/hotspot/cpu/ppc/stubGenerator_ppc.cpp line 3820:
> 
>> 3818:         __ vcmpequb_(eq_special_case_char, input, vec_special_case_char);
>> 3819:         //
>> 3820:         // There's a (63/64)^16 = 77.7% chance that there are no special
> 
> I think that assumes uniformly randomized data, is that a good assumption?   Is it measurably faster to skip around the xxsel instead of doing it unconditionally?

Thanks for this question. I also stumbled over it when reviewing. I guess a branch which gets mispredicted in ~22% of the cases leads to a big performance loss. (In addition, the branch target is not aligned.)

-------------

PR: https://git.openjdk.java.net/jdk/pull/293

From jjg at openjdk.java.net  Thu Oct 22 19:49:22 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Thu, 22 Oct 2020 19:49:22 GMT
Subject: Integrated: JDK-8255262: Remove use of legacy custom @spec tag
In-Reply-To: <U4tky8tp6zbW2FAH956Ple4uIqsj6LYurYjOZxrO5Is=.c62b5e85-3ec2-4eea-8d8e-20d00cb32dfe@github.com>
References: <U4tky8tp6zbW2FAH956Ple4uIqsj6LYurYjOZxrO5Is=.c62b5e85-3ec2-4eea-8d8e-20d00cb32dfe@github.com>
Message-ID: <AF8Qx0S97zH-OBwiR9XmXmR9CBm12YhuYY2pfk2Ab7A=.76dafd63-a12a-403a-b0c4-df482c607f3b@github.com>

On Thu, 22 Oct 2020 17:16:23 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> The change is (just) to remove legacy usages of a JDK-private custom tag.

This pull request has now been integrated.

Changeset: 0aa3c925
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/0aa3c925
Stats:     209 lines in 69 files changed: 0 ins; 209 del; 0 mod

8255262: Remove use of legacy custom @spec tag

Reviewed-by: lancea, mr, iris, alanb, darcy, mchung

-------------

PR: https://git.openjdk.java.net/jdk/pull/814

From github.com+10835776+stsypanov at openjdk.java.net  Thu Oct 22 19:51:14 2020
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Thu, 22 Oct 2020 19:51:14 GMT
Subject: RFR: 8254146: Avoid unnecessary volatile write on new
 AtomicBoolean(false)
In-Reply-To: <U1IJfN94lsWZr8VITuU9ZPOJFZrj8EzC0Lo5K9R-LFQ=.9745aaa3-ff28-4563-9f47-8dbe83e2388c@github.com>
References: <AzWKluHZjvFYm2wUanwYfn91iKKMacpk_qSsje3tXWk=.ba873b46-4e12-4415-8832-fa314d6759a3@github.com>
 <RyR2m1MR6UPKbcnxdi_tHwJvQxEtMhT-o2ljRTQDcEo=.976aa7a1-6706-4502-a150-5eb25dd744d1@github.com>
 <b7teCaJhFTu-4FHTyQqDwOqy1B1blXQaoowClBcqnTU=.d75b5dd9-050b-4137-b8fd-8b8e9171a6ca@github.com>
 <xc23wavVAM3Cu4YOo122ikO4FDNUeEx0O96jUobmrYM=.455b3ead-f83b-4956-9f0a-844b3f538b57@github.com>
 <gvcLDkPPC4XuKqtAaSUiKhiRXWW0v_cQfnMsz22T3RI=.86f4cbcb-cd02-4e6a-98a9-120fa46cc497@github.com>
 <U1IJfN94lsWZr8VITuU9ZPOJFZrj8EzC0Lo5K9R-LFQ=.9745aaa3-ff28-4563-9f47-8dbe83e2388c@github.com>
Message-ID: <3-9dr0EES5o4tZRQEspq8cjpTqMCHyajxjJpcv_A9iw=.a7771b4f-60bc-48e1-9156-54d89aa7ec03@github.com>

On Thu, 15 Oct 2020 19:05:54 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> @cl4es , @dreis2211 thanks for explanation!
>
>> On 15/10/2020 11:41, Claes Redestad wrote:
>> 
>> > In the short term we could consider a point fix to replace existing
>> > use of `new AtomicInteger/-Long(0)` with `new
>> > AtomicInteger/-Long()`, but in the long term we should really try
>> > and optimize our JITs so that writing to a volatile field in
>> > constructors can be made cheaper.
>> 
>> I guess it all depends on whether there's a happens-before
>> relationship between the volatile store to Field X in a constructor
>> and any subsequent get() of Field X in another thread. Intuitively I
>> would have thought so, but I can't find any guarantee in the spec.
>> Nonetheless, I think we'd have little gain by changing this and it
>> might break (arguably incorrect) programs.
> 
> I misphrased somewhat: I think we should try and remove explicit stores of default values to volatile fields in constructors, as suggested by https://bugs.openjdk.java.net/browse/JDK-8145948 
> 
> I can't think of a way this would break any program (even arguably incorrect ones), and would net us the gains shown in comments here without any point fixes.

@cl4es could I ask one more question? Would it be helpful to create a separate PR about removal of explicit zeroing of Atomic* classes (excluding AtomicBoolean), e.g. somethin like this https://github.com/openjdk/jdk/compare/master...stsypanov:atom-simpl ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/510

From github.com+51754783+coreyashford at openjdk.java.net  Thu Oct 22 19:51:20 2020
From: github.com+51754783+coreyashford at openjdk.java.net (CoreyAshford)
Date: Thu, 22 Oct 2020 19:51:20 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v8]
In-Reply-To: <r_UoYsBul9SV88OG2z5qfeCfKQFCF23_DDfdB1LKlzY=.2df9f9a4-d0b6-4ac6-b75b-1cd59022eca6@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <nU4nZ9oCthDEi7olxerj_bkmWuITInbbNzJKkb1shkY=.28b4ed81-9733-4981-b6fb-c8e4e3bd335e@github.com>
 <r_UoYsBul9SV88OG2z5qfeCfKQFCF23_DDfdB1LKlzY=.2df9f9a4-d0b6-4ac6-b75b-1cd59022eca6@github.com>
Message-ID: <YLjp5jM3EzQen7dsHBVgnlQLQCo0jZ2DNWbKgIdxamg=.106f6cee-2945-467c-a380-388e751e9e41@github.com>

On Thu, 22 Oct 2020 14:00:49 GMT, Paul Murphy <github.com+12972156+pmur at openjdk.org> wrote:

>> CoreyAshford has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   TestBase64.java: remove jdk.test.lib.Utils from @build which was causing Tier3 failures.
>
> src/hotspot/cpu/ppc/stubGenerator_ppc.cpp line 3817:
> 
>> 3815:         __ xxperm(offsets->to_vsr(), offsetLUT, higher_nibble->to_vsr());
>> 3816: 
>> 3817:         // Find out which elemets are the special case character (isURL ? '/' : '-')
> 
> Trivial nit, s/elemets/elements/

Will fix.

-------------

PR: https://git.openjdk.java.net/jdk/pull/293

From github.com+51754783+coreyashford at openjdk.java.net  Thu Oct 22 20:43:15 2020
From: github.com+51754783+coreyashford at openjdk.java.net (CoreyAshford)
Date: Thu, 22 Oct 2020 20:43:15 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v8]
In-Reply-To: <iD4pt7fK5AExXfPuONZnrjoFTNmHO7T96s_9KCiBYTM=.64012cef-fd79-4692-a029-2b75391bd193@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <nU4nZ9oCthDEi7olxerj_bkmWuITInbbNzJKkb1shkY=.28b4ed81-9733-4981-b6fb-c8e4e3bd335e@github.com>
 <r_UoYsBul9SV88OG2z5qfeCfKQFCF23_DDfdB1LKlzY=.2df9f9a4-d0b6-4ac6-b75b-1cd59022eca6@github.com>
 <iD4pt7fK5AExXfPuONZnrjoFTNmHO7T96s_9KCiBYTM=.64012cef-fd79-4692-a029-2b75391bd193@github.com>
Message-ID: <IXZnO1Rv6RMimJLR5zL5MYSQZrBltEe_0I13tbN92XE=.24c72b06-28b8-413b-8b27-c97176125780@github.com>

On Thu, 22 Oct 2020 18:10:02 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> src/hotspot/cpu/ppc/stubGenerator_ppc.cpp line 3820:
>> 
>>> 3818:         __ vcmpequb_(eq_special_case_char, input, vec_special_case_char);
>>> 3819:         //
>>> 3820:         // There's a (63/64)^16 = 77.7% chance that there are no special
>> 
>> I think that assumes uniformly randomized data, is that a good assumption?   Is it measurably faster to skip around the xxsel instead of doing it unconditionally?
>
> Thanks for this question. I also stumbled over it when reviewing. I guess a branch which gets mispredicted in ~22% of the cases leads to a big performance loss. (In addition, the branch target is not aligned.)

Yes, it assumes uniformly random data, but also recall that the unencoded data bytes get shifted by 2, 4, 6 bits into the encoded bytes, which I'm guessing would tend to make the data somewhat more uniform, even if the source data has low entropy.

That said, I didn't actually benchmark it.  I will do that to make sure there is a gain, and if there isn't I will remove the conditional branch.

-------------

PR: https://git.openjdk.java.net/jdk/pull/293

From redestad at openjdk.java.net  Thu Oct 22 20:49:14 2020
From: redestad at openjdk.java.net (Claes Redestad)
Date: Thu, 22 Oct 2020 20:49:14 GMT
Subject: RFR: 8254146: Avoid unnecessary volatile write on new
 AtomicBoolean(false)
In-Reply-To: <3-9dr0EES5o4tZRQEspq8cjpTqMCHyajxjJpcv_A9iw=.a7771b4f-60bc-48e1-9156-54d89aa7ec03@github.com>
References: <AzWKluHZjvFYm2wUanwYfn91iKKMacpk_qSsje3tXWk=.ba873b46-4e12-4415-8832-fa314d6759a3@github.com>
 <RyR2m1MR6UPKbcnxdi_tHwJvQxEtMhT-o2ljRTQDcEo=.976aa7a1-6706-4502-a150-5eb25dd744d1@github.com>
 <b7teCaJhFTu-4FHTyQqDwOqy1B1blXQaoowClBcqnTU=.d75b5dd9-050b-4137-b8fd-8b8e9171a6ca@github.com>
 <xc23wavVAM3Cu4YOo122ikO4FDNUeEx0O96jUobmrYM=.455b3ead-f83b-4956-9f0a-844b3f538b57@github.com>
 <gvcLDkPPC4XuKqtAaSUiKhiRXWW0v_cQfnMsz22T3RI=.86f4cbcb-cd02-4e6a-98a9-120fa46cc497@github.com>
 <U1IJfN94lsWZr8VITuU9ZPOJFZrj8EzC0Lo5K9R-LFQ=.9745aaa3-ff28-4563-9f47-8dbe83e2388c@github.com>
 <3-9dr0EES5o4tZRQEspq8cjpTqMCHyajxjJpcv_A9iw=.a7771b4f-60bc-48e1-9156-54d89aa7ec03@github.com>
Message-ID: <xWU1oW73WRUXtGWg56n7to_bTI8Vdg8tGjexkBqq3Hk=.74762017-d259-44d8-8fc0-5fcfeec3c752@github.com>

On Thu, 22 Oct 2020 19:48:19 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

>>> On 15/10/2020 11:41, Claes Redestad wrote:
>>> 
>>> > In the short term we could consider a point fix to replace existing
>>> > use of `new AtomicInteger/-Long(0)` with `new
>>> > AtomicInteger/-Long()`, but in the long term we should really try
>>> > and optimize our JITs so that writing to a volatile field in
>>> > constructors can be made cheaper.
>>> 
>>> I guess it all depends on whether there's a happens-before
>>> relationship between the volatile store to Field X in a constructor
>>> and any subsequent get() of Field X in another thread. Intuitively I
>>> would have thought so, but I can't find any guarantee in the spec.
>>> Nonetheless, I think we'd have little gain by changing this and it
>>> might break (arguably incorrect) programs.
>> 
>> I misphrased somewhat: I think we should try and remove explicit stores of default values to volatile fields in constructors, as suggested by https://bugs.openjdk.java.net/browse/JDK-8145948 
>> 
>> I can't think of a way this would break any program (even arguably incorrect ones), and would net us the gains shown in comments here without any point fixes.
>
> @cl4es could I ask one more question? Would it be helpful to create a separate PR about removal of explicit zeroing of Atomic* classes (excluding AtomicBoolean), e.g. somethin like this https://github.com/openjdk/jdk/compare/master...stsypanov:atom-simpl ?

> @cl4es could I ask one more question? Would it be helpful to create a separate PR about removal of explicit zeroing of Atomic* classes (excluding AtomicBoolean), e.g. somethin like this [master...stsypanov:atom-simpl](https://github.com/openjdk/jdk/compare/master...stsypanov:atom-simpl) ?

Sure. Fixing `static final`s is unlikely to matter much, but it's a trivial change and as long as it has a performance advantage it's good to be consistent.

General advice is to limit sweeping changes to related modules, and not include code maintained in some upstream repo. What you have here looks fine.

-------------

PR: https://git.openjdk.java.net/jdk/pull/510

From github.com+10835776+stsypanov at openjdk.java.net  Thu Oct 22 20:49:14 2020
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Thu, 22 Oct 2020 20:49:14 GMT
Subject: RFR: 8254146: Avoid unnecessary volatile write on new
 AtomicBoolean(false)
In-Reply-To: <xWU1oW73WRUXtGWg56n7to_bTI8Vdg8tGjexkBqq3Hk=.74762017-d259-44d8-8fc0-5fcfeec3c752@github.com>
References: <AzWKluHZjvFYm2wUanwYfn91iKKMacpk_qSsje3tXWk=.ba873b46-4e12-4415-8832-fa314d6759a3@github.com>
 <RyR2m1MR6UPKbcnxdi_tHwJvQxEtMhT-o2ljRTQDcEo=.976aa7a1-6706-4502-a150-5eb25dd744d1@github.com>
 <b7teCaJhFTu-4FHTyQqDwOqy1B1blXQaoowClBcqnTU=.d75b5dd9-050b-4137-b8fd-8b8e9171a6ca@github.com>
 <xc23wavVAM3Cu4YOo122ikO4FDNUeEx0O96jUobmrYM=.455b3ead-f83b-4956-9f0a-844b3f538b57@github.com>
 <gvcLDkPPC4XuKqtAaSUiKhiRXWW0v_cQfnMsz22T3RI=.86f4cbcb-cd02-4e6a-98a9-120fa46cc497@github.com>
 <U1IJfN94lsWZr8VITuU9ZPOJFZrj8EzC0Lo5K9R-LFQ=.9745aaa3-ff28-4563-9f47-8dbe83e2388c@github.com>
 <3-9dr0EES5o4tZRQEspq8cjpTqMCHyajxjJpcv_A9iw=.a7771b4f-60bc-48e1-9156-54d89aa7ec03@github.com>
 <xWU1oW73WRUXtGWg56n7to_bTI8Vdg8tGjexkBqq3Hk=.74762017-d259-44d8-8fc0-5fcfeec3c752@github.com>
Message-ID: <MJdiQ25LhHbyklkNiOXyvaNFqx0I0NLuWd8Ha6PD928=.27783a41-d021-48a0-838c-00a432748e34@github.com>

On Thu, 22 Oct 2020 20:00:12 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> @cl4es could I ask one more question? Would it be helpful to create a separate PR about removal of explicit zeroing of Atomic* classes (excluding AtomicBoolean), e.g. somethin like this https://github.com/openjdk/jdk/compare/master...stsypanov:atom-simpl ?
>
>> @cl4es could I ask one more question? Would it be helpful to create a separate PR about removal of explicit zeroing of Atomic* classes (excluding AtomicBoolean), e.g. somethin like this [master...stsypanov:atom-simpl](https://github.com/openjdk/jdk/compare/master...stsypanov:atom-simpl) ?
> 
> Sure. Fixing `static final`s is unlikely to matter much, but it's a trivial change and as long as it has a performance advantage it's good to be consistent.
> 
> General advice is to limit sweeping changes to related modules, and not include code maintained in some upstream repo. What you have here looks fine.

DOne https://github.com/openjdk/jdk/pull/818

-------------

PR: https://git.openjdk.java.net/jdk/pull/510

From bpb at openjdk.java.net  Thu Oct 22 21:03:18 2020
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 22 Oct 2020 21:03:18 GMT
Subject: RFR: 8229845: Decrease memory consumption of BigInteger.toString()
Message-ID: <QcssqDSre9zJ5L6fYGesmxienoFDYDebNM2fJUMe_bw=.3236bd5c-5900-4c0b-9e00-21a7bf24b9b4@github.com>

Please review this proposed fix. The review was initially in this thread

http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-August/061914.html

under the old Hg SCM. The changes proposed here are derived from the final (.05) patch in the previous review which was posted in

http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-August/062012.html.

-------------

Commit messages:
 - 8229845: Decrease memory consumption of BigInteger.toString()

Changes: https://git.openjdk.java.net/jdk/pull/819/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=819&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8229845
  Stats: 115 lines in 2 files changed: 57 ins; 21 del; 37 mod
  Patch: https://git.openjdk.java.net/jdk/pull/819.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/819/head:pull/819

PR: https://git.openjdk.java.net/jdk/pull/819

From bchristi at openjdk.java.net  Thu Oct 22 21:44:14 2020
From: bchristi at openjdk.java.net (Brent Christian)
Date: Thu, 22 Oct 2020 21:44:14 GMT
Subject: RFR: 8255086: Update the root locale display names [v2]
In-Reply-To: <2PX_Zdi3XUq7NpyYH_jKHXGFiPotGnfVqqXQ-WymQDQ=.e91f960a-8d98-4ac7-a3d1-39e1cd1b594b@github.com>
References: <uH47zot061i3hNhl6lics05j6VFUmcpjcDFFz6PoY2U=.2e818daf-dfc7-4868-b049-31079ba56c23@github.com>
 <2PX_Zdi3XUq7NpyYH_jKHXGFiPotGnfVqqXQ-WymQDQ=.e91f960a-8d98-4ac7-a3d1-39e1cd1b594b@github.com>
Message-ID: <mLfFlo2sglfq6MEBJBNjzKTCXie5Ns2HCi9fImONW_Q=.57001415-f374-462e-a8ad-47403eb42251@github.com>

On Wed, 21 Oct 2020 23:38:23 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Hi,
>> 
>> Please review the changes to the subject issue. The fix replaces the obsolete/incorrect English language/region/script display names in the COMPAT root locale bundle. The data are derived from CLDR's English names.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Put a newline at the end.

Marked as reviewed by bchristi (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/786

From bchristi at openjdk.java.net  Thu Oct 22 21:44:14 2020
From: bchristi at openjdk.java.net (Brent Christian)
Date: Thu, 22 Oct 2020 21:44:14 GMT
Subject: RFR: 8255086: Update the root locale display names
In-Reply-To: <pdODfu52gmVdC2jXwHb86VnMcej_b-9MakJIccha34o=.ad6d2e10-8a97-4db4-af43-d51242453f44@github.com>
References: <uH47zot061i3hNhl6lics05j6VFUmcpjcDFFz6PoY2U=.2e818daf-dfc7-4868-b049-31079ba56c23@github.com>
 <2LUYLa3MK34hhuxUJT287iBxKUQuWKw8dkKAhHbR_1k=.d933c110-ea7c-4447-beed-9013b26023f4@github.com>
 <pdODfu52gmVdC2jXwHb86VnMcej_b-9MakJIccha34o=.ad6d2e10-8a97-4db4-af43-d51242453f44@github.com>
Message-ID: <XYEkQuKwc5EJAKkkW-i88LO0VEIcqxzw2-5QMqLyMG8=.067fb41c-6e5b-48b4-bf3e-f3f8ea091d77@github.com>

On Wed, 21 Oct 2020 23:16:15 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Hi, Naoto
>> 
>> What is the source for the updated values in LocaleNames.properties?
>> 
>> Also, could the bug synopsis be updated to be more descriptive?
>> 
>> Thanks,
>> -Brent
>
> Hi Brent,
> 
>> What is the source for the updated values in LocaleNames.properties?
> 
> The source is CLDR v37, which is currently used in the latest JDK release. They are extracted with a code snippet (https://bugs.openjdk.java.net/browse/JDK-8255086?focusedCommentId=14375906&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14375906), and non-ASCII chars are Unicode escaped.
> 
>> Also, could the bug synopsis be updated to be more descriptive?
> 
> Modified the synopsis. Hope it made sense.
> 
> Naoto

Looks good.

-------------

PR: https://git.openjdk.java.net/jdk/pull/786

From bchristi at openjdk.java.net  Thu Oct 22 21:54:13 2020
From: bchristi at openjdk.java.net (Brent Christian)
Date: Thu, 22 Oct 2020 21:54:13 GMT
Subject: Integrated: 8255031 : Update
 java/util/prefs/AddNodeChangeListener.java to report more failure info
In-Reply-To: <WdQlv9nOZU91fs2chRaHhYRTVnuMwcB297XumQEUW7k=.9f8d9fe3-4418-4d8b-95db-2cc31ab34ebf@github.com>
References: <WdQlv9nOZU91fs2chRaHhYRTVnuMwcB297XumQEUW7k=.9f8d9fe3-4418-4d8b-95db-2cc31ab34ebf@github.com>
Message-ID: <vRTQoLQZPQfAzfE2ki_h3Cwak-iBagzVdzTKtM_WuSs=.73116aba-9627-4a30-af0c-1d6a0e04850b@github.com>

On Tue, 20 Oct 2020 21:49:37 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> Hi,
> 
> The java/util/prefs/AddNodeChangeListener.java test fails once in a while in the automated test system.  Previous failures were traced to machine configuration errors, but that does not appear to be the case this time.
> 
> My efforts to reproduce this failure have been unsuccessful.  The only useful information I've gleaned so far from the test failure logs is that the overall duration for running tier1 is longer than usual when the test failure happens.
> 
> I would like to make the following updates to the test, in hopes of learning more if and when this test fails again:
> 
> * fail faster, to report if it is addNode() or removeNode() that is failing
> * make multiple attempts to sleep+check the NodeChangeListener.  (If the test fails after a single sleep, but passes after waiting longer, maybe we just need to sleep for longer to account for the occasional slower tier1 test run).
> * a few indentations fixes
> 
> Thanks,
> -Brent

This pull request has now been integrated.

Changeset: 8afdcaee
Author:    Brent Christian <bchristi at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/8afdcaee
Stats:     56 lines in 1 file changed: 37 ins; 3 del; 16 mod

8255031: Update java/util/prefs/AddNodeChangeListener.java to report more failure info

Reviewed-by: bpb

-------------

PR: https://git.openjdk.java.net/jdk/pull/773

From github.com+51754783+coreyashford at openjdk.java.net  Thu Oct 22 21:58:14 2020
From: github.com+51754783+coreyashford at openjdk.java.net (CoreyAshford)
Date: Thu, 22 Oct 2020 21:58:14 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v8]
In-Reply-To: <r_UoYsBul9SV88OG2z5qfeCfKQFCF23_DDfdB1LKlzY=.2df9f9a4-d0b6-4ac6-b75b-1cd59022eca6@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <nU4nZ9oCthDEi7olxerj_bkmWuITInbbNzJKkb1shkY=.28b4ed81-9733-4981-b6fb-c8e4e3bd335e@github.com>
 <r_UoYsBul9SV88OG2z5qfeCfKQFCF23_DDfdB1LKlzY=.2df9f9a4-d0b6-4ac6-b75b-1cd59022eca6@github.com>
Message-ID: <_ddbVr7GqBFrju0E3eJ1PHH306bzPxNDyMiXEceBvSE=.d7db184f-0b82-480d-bea3-85e6a342385f@github.com>

On Thu, 22 Oct 2020 14:32:40 GMT, Paul Murphy <github.com+12972156+pmur at openjdk.org> wrote:

>> CoreyAshford has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   TestBase64.java: remove jdk.test.lib.Utils from @build which was causing Tier3 failures.
>
> src/hotspot/cpu/ppc/stubGenerator_ppc.cpp line 3884:
> 
>> 3882:             // |   vec_0x3fs   |  00111111   |       00111111       |       00111111       |  00111111   |  00111111   |       00111111       |       00111111       |  00111111   |
>> 3883:             // +---------------+-------------+----------------------+----------------------+-------------+-------------+----------------------+----------------------+-------------+
>> 3884:             // | after vpextd  |   b5:0..7   |       b4:0..7        |       b3:0..7        |   b2:0..7   |   b1:0..7   |       b0:0..7        |       00000000       |  00000000   |
> 
> Are theses comments correct or am I misunderstanding this? I read the final result as something starting as `b5:2..7 || b4:4..7|| b5:0..1` from vpextd.

Because the bytes are displayed e15..e8, instead of the other way around, it's hard to follow.  As an example, consider just the last four bytes of the table, but displayed in the reverse order:

00||b0:0..5    00||b0:6..7||b1:0..3    00||b1:4..7||b2:0..1    00||b2:2..7

After vpextd with bit select pattern 00111111 for all bytes:

b0:0..5||b0:6..7    b1:0..3||1:4..7    b2:0..1||b2:2..7
=
b0:0..7    b1:0..7    b2:0..7

Should I reverse the order of this table with a comment at the top, to explain the reason for the reversal?  It seems like a good idea.

-------------

PR: https://git.openjdk.java.net/jdk/pull/293

From github.com+51754783+coreyashford at openjdk.java.net  Thu Oct 22 22:09:17 2020
From: github.com+51754783+coreyashford at openjdk.java.net (CoreyAshford)
Date: Thu, 22 Oct 2020 22:09:17 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v8]
In-Reply-To: <r_UoYsBul9SV88OG2z5qfeCfKQFCF23_DDfdB1LKlzY=.2df9f9a4-d0b6-4ac6-b75b-1cd59022eca6@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <nU4nZ9oCthDEi7olxerj_bkmWuITInbbNzJKkb1shkY=.28b4ed81-9733-4981-b6fb-c8e4e3bd335e@github.com>
 <r_UoYsBul9SV88OG2z5qfeCfKQFCF23_DDfdB1LKlzY=.2df9f9a4-d0b6-4ac6-b75b-1cd59022eca6@github.com>
Message-ID: <_JR-e3ZsRFwvZCR7ws34z5jLjp2kJQ1bu4gyl0RG1XU=.ec3040cf-8147-4dcd-b87d-4fd9be4eb59e@github.com>

On Thu, 22 Oct 2020 14:24:34 GMT, Paul Murphy <github.com+12972156+pmur at openjdk.org> wrote:

>> CoreyAshford has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   TestBase64.java: remove jdk.test.lib.Utils from @build which was causing Tier3 failures.
>
> src/hotspot/cpu/ppc/stubGenerator_ppc.cpp line 3878:
> 
>> 3876:             // |    Element    |             |                      |                      |             |             |                      |                      |             |
>> 3877:             // +===============+=============+======================+======================+=============+=============+======================+======================+=============+
>> 3878:             // | after vaddubm | 00||b0:0..5 | 00||b0:6..7||b1:0..3 | 00||b1:4..7||b2:0..1 | 00||b2:2..7 | 00||b3:0..5 | 00||b3:6..7||b4:0..3 | 00||b4:4..7||b5:0..1 | 00||b5:2..7 |
> 
> An extra line here showing how the 8 6-bit values above get mapping into 6 bytes greatly help my brain out. (likewise for the <P10 case below too)

Just to make sure I understand, you're not asking for a change here, is that right?

-------------

PR: https://git.openjdk.java.net/jdk/pull/293

From joehw at openjdk.java.net  Thu Oct 22 22:32:12 2020
From: joehw at openjdk.java.net (Joe Wang)
Date: Thu, 22 Oct 2020 22:32:12 GMT
Subject: RFR: 8255086: Update the root locale display names [v2]
In-Reply-To: <mLfFlo2sglfq6MEBJBNjzKTCXie5Ns2HCi9fImONW_Q=.57001415-f374-462e-a8ad-47403eb42251@github.com>
References: <uH47zot061i3hNhl6lics05j6VFUmcpjcDFFz6PoY2U=.2e818daf-dfc7-4868-b049-31079ba56c23@github.com>
 <2PX_Zdi3XUq7NpyYH_jKHXGFiPotGnfVqqXQ-WymQDQ=.e91f960a-8d98-4ac7-a3d1-39e1cd1b594b@github.com>
 <mLfFlo2sglfq6MEBJBNjzKTCXie5Ns2HCi9fImONW_Q=.57001415-f374-462e-a8ad-47403eb42251@github.com>
Message-ID: <Kk16tnx1exoXuQOHthE651aMPxQMFYMS_s-e0CmvqNk=.b8321322-cf82-4fbe-80df-41804f3c8045@github.com>

On Thu, 22 Oct 2020 21:40:59 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Put a newline at the end.
>
> Marked as reviewed by bchristi (Reviewer).

Hi Naoto,

Do we need a test similar to ISO3166 where display names of Locale.ROOT and Locale.US are compared? I see LocaleEnhanceTest.java has references to Locale.ROOT and a few selected names were updated. But we don't seem to have a test like ISO3166 that does a straight-forward comparison.

The code you used to generate the updated LocaleNames.properties (in the comment section), that seems to be valuable. I wonder if there's a better way to preserve it, as part of the manual tool, or maybe put it back into the repo as part of a test?

-------------

PR: https://git.openjdk.java.net/jdk/pull/786

From naoto at openjdk.java.net  Thu Oct 22 23:23:10 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 22 Oct 2020 23:23:10 GMT
Subject: RFR: 8255086: Update the root locale display names [v2]
In-Reply-To: <Kk16tnx1exoXuQOHthE651aMPxQMFYMS_s-e0CmvqNk=.b8321322-cf82-4fbe-80df-41804f3c8045@github.com>
References: <uH47zot061i3hNhl6lics05j6VFUmcpjcDFFz6PoY2U=.2e818daf-dfc7-4868-b049-31079ba56c23@github.com>
 <2PX_Zdi3XUq7NpyYH_jKHXGFiPotGnfVqqXQ-WymQDQ=.e91f960a-8d98-4ac7-a3d1-39e1cd1b594b@github.com>
 <mLfFlo2sglfq6MEBJBNjzKTCXie5Ns2HCi9fImONW_Q=.57001415-f374-462e-a8ad-47403eb42251@github.com>
 <Kk16tnx1exoXuQOHthE651aMPxQMFYMS_s-e0CmvqNk=.b8321322-cf82-4fbe-80df-41804f3c8045@github.com>
Message-ID: <N-MwU9Vl4yiDdWtCbJo0WYsO3KnO_Php9noenzfdvg0=.1b95a186-b519-4e6c-9bcf-f622720ecbdb@github.com>

On Thu, 22 Oct 2020 22:29:16 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Marked as reviewed by bchristi (Reviewer).
>
> Hi Naoto,
> 
> Do we need a test similar to ISO3166 where display names of Locale.ROOT and Locale.US are compared? I see LocaleEnhanceTest.java has references to Locale.ROOT and a few selected names were updated. But we don't seem to have a test like ISO3166 that does a straight-forward comparison.
> 
> The code you used to generate the updated LocaleNames.properties (in the comment section), that seems to be valuable. I wonder if there's a better way to preserve it, as part of the manual tool, or maybe put it back into the repo as part of a test?

Hi Joe,

> Do we need a test similar to ISO3166 where display names of Locale.ROOT and Locale.US are compared? I see LocaleEnhanceTest.java has references to Locale.ROOT and a few selected names were updated. But we don't seem to have a test like ISO3166 that does a straight-forward comparison.

test/jdk/sun/text/resources/LocaleData validates all the changes with this changeset (added lines at the end), by checking the names in the resource bundle.

> 
> The code you used to generate the updated LocaleNames.properties (in the comment section), that seems to be valuable. I wonder if there's a better way to preserve it, as part of the manual tool, or maybe put it back into the repo as part of a test?

Yeah, but I cannot think of a better location to preserve it. The reason is that it cannot be used as a test because CLDR's English names and COMPAT's root names can inherently be different. I just regard the code to be one-off to retrieve authentic English names for those language ids.

Naoto

-------------

PR: https://git.openjdk.java.net/jdk/pull/786

From joehw at openjdk.java.net  Fri Oct 23 00:24:25 2020
From: joehw at openjdk.java.net (Joe Wang)
Date: Fri, 23 Oct 2020 00:24:25 GMT
Subject: RFR: 8255086: Update the root locale display names [v2]
In-Reply-To: <N-MwU9Vl4yiDdWtCbJo0WYsO3KnO_Php9noenzfdvg0=.1b95a186-b519-4e6c-9bcf-f622720ecbdb@github.com>
References: <uH47zot061i3hNhl6lics05j6VFUmcpjcDFFz6PoY2U=.2e818daf-dfc7-4868-b049-31079ba56c23@github.com>
 <2PX_Zdi3XUq7NpyYH_jKHXGFiPotGnfVqqXQ-WymQDQ=.e91f960a-8d98-4ac7-a3d1-39e1cd1b594b@github.com>
 <mLfFlo2sglfq6MEBJBNjzKTCXie5Ns2HCi9fImONW_Q=.57001415-f374-462e-a8ad-47403eb42251@github.com>
 <Kk16tnx1exoXuQOHthE651aMPxQMFYMS_s-e0CmvqNk=.b8321322-cf82-4fbe-80df-41804f3c8045@github.com>
 <N-MwU9Vl4yiDdWtCbJo0WYsO3KnO_Php9noenzfdvg0=.1b95a186-b519-4e6c-9bcf-f622720ecbdb@github.com>
Message-ID: <DMA6WJkCjNUDypHdqN6aKOqKKuURGh704_q-ybeXlIM=.0ff76670-35a9-41a5-b23b-187411b0a548@github.com>

On Thu, 22 Oct 2020 23:20:08 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Hi Joe,
> 
> > Do we need a test similar to ISO3166 where display names of Locale.ROOT and Locale.US are compared? I see LocaleEnhanceTest.java has references to Locale.ROOT and a few selected names were updated. But we don't seem to have a test like ISO3166 that does a straight-forward comparison.
> 
> test/jdk/sun/text/resources/LocaleData validates all the changes with this changeset (added lines at the end), by checking the names in the resource bundle.

Saw the test and thought ISO3166 would be more direct. But you're right, as you said below, since it's one-off thing, can't really use a test like ISO3166 for a complete comparison.
> 
> > The code you used to generate the updated LocaleNames.properties (in the comment section), that seems to be valuable. I wonder if there's a better way to preserve it, as part of the manual tool, or maybe put it back into the repo as part of a test?
> 
> Yeah, but I cannot think of a better location to preserve it. The reason is that it cannot be used as a test because CLDR's English names and COMPAT's root names can inherently be different. I just regard the code to be one-off to retrieve authentic English names for those language ids.

I see. Thanks.

Joe

> 
> Naoto

-------------

PR: https://git.openjdk.java.net/jdk/pull/786

From joehw at openjdk.java.net  Fri Oct 23 00:24:24 2020
From: joehw at openjdk.java.net (Joe Wang)
Date: Fri, 23 Oct 2020 00:24:24 GMT
Subject: RFR: 8255086: Update the root locale display names [v2]
In-Reply-To: <2PX_Zdi3XUq7NpyYH_jKHXGFiPotGnfVqqXQ-WymQDQ=.e91f960a-8d98-4ac7-a3d1-39e1cd1b594b@github.com>
References: <uH47zot061i3hNhl6lics05j6VFUmcpjcDFFz6PoY2U=.2e818daf-dfc7-4868-b049-31079ba56c23@github.com>
 <2PX_Zdi3XUq7NpyYH_jKHXGFiPotGnfVqqXQ-WymQDQ=.e91f960a-8d98-4ac7-a3d1-39e1cd1b594b@github.com>
Message-ID: <USua9O8kb3Xy5jeMd38dzkCzVl8ddS9jCGR1xFxvuhA=.04819f82-1bb3-4c6b-9865-d5cef1ed519f@github.com>

On Wed, 21 Oct 2020 23:38:23 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Hi,
>> 
>> Please review the changes to the subject issue. The fix replaces the obsolete/incorrect English language/region/script display names in the COMPAT root locale bundle. The data are derived from CLDR's English names.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Put a newline at the end.

Marked as reviewed by joehw (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/786

From naoto at openjdk.java.net  Fri Oct 23 01:20:12 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 23 Oct 2020 01:20:12 GMT
Subject: Integrated: 8255086: Update the root locale display names
In-Reply-To: <uH47zot061i3hNhl6lics05j6VFUmcpjcDFFz6PoY2U=.2e818daf-dfc7-4868-b049-31079ba56c23@github.com>
References: <uH47zot061i3hNhl6lics05j6VFUmcpjcDFFz6PoY2U=.2e818daf-dfc7-4868-b049-31079ba56c23@github.com>
Message-ID: <5PuQOLClUtKCfPMUtsO8gJvOg7RjgSGalM9yvBFTvZM=.59b4d109-3245-43d9-8814-e8f841d49f0e@github.com>

On Wed, 21 Oct 2020 20:39:18 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Hi,
> 
> Please review the changes to the subject issue. The fix replaces the obsolete/incorrect English language/region/script display names in the COMPAT root locale bundle. The data are derived from CLDR's English names.

This pull request has now been integrated.

Changeset: ff5f2265
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ff5f2265
Stats:     234 lines in 5 files changed: 111 ins; 0 del; 123 mod

8255086: Update the root locale display names

Reviewed-by: bchristi, joehw

-------------

PR: https://git.openjdk.java.net/jdk/pull/786

From dawid.weiss at gmail.com  Fri Oct 23 07:12:34 2020
From: dawid.weiss at gmail.com (Dawid Weiss)
Date: Fri, 23 Oct 2020 09:12:34 +0200
Subject: "loc: wrong sig" in ZipFileSystem on a valid ZIP file (extra data
 field of exactly 5 bytes)
In-Reply-To: <CAM21Rt-ANpHbDO-kjSHguDzSTGS-WhGwHsbxcHav1wFVvDQ2EQ@mail.gmail.com>
References: <CAM21Rt8KeWyQvjE7-5pfyXYJXO3yGgGfKpBtueOV8qgNFMa+jQ@mail.gmail.com>
 <17F644E3-E5E0-403E-B568-FCB89C8BD9BB@ORACLE.COM>
 <CAM21Rt-ANpHbDO-kjSHguDzSTGS-WhGwHsbxcHav1wFVvDQ2EQ@mail.gmail.com>
Message-ID: <CAM21Rt_8WWsTm-DrY=stscEuiWXF1-JJkv83wZoReJB7ZD-Kjw@mail.gmail.com>

This looks like a legitimate bug to me (the zip file system implementation
is sensitive to the order of extra parameters and may throw an unexpected
error
on zip64 archives exceeding 4 gigabytes). I can't file a Jira issue - no
permissions - but I think it'd be worth adding one?

Dawid

On Wed, Oct 21, 2020 at 8:36 PM Dawid Weiss <dawid.weiss at gmail.com> wrote:

> Hi Lance,
>
> Yes, this is exactly the point where the problem is in JDK code. It's
> directly
> related to the zip entry beyond max int offset. The code tries to read data
> from a local zip entry header at locoff, here:
>
> if (zipfs.readFullyAt(buf, 0, buf.length , locoff)
>
> but the locoff is set to ~0 as per the spec for files exceeding
> 4 gigabytes, which says:
>
>    4.4.16 relative offset of local header: (4 bytes)
>
>        This is the offset from the start of the first disk on
>        which this file appears, to where the local header SHOULD
>        be found.  If an archive is in ZIP64 format and the value
>        in this field is 0xFFFFFFFF, the size will be in the
>        corresponding 8 byte zip64 extended information extra field.
>
> A proper fix would be to read the local header from zip64 extra data
> first. I don't know how this interferes with the rest of the code though -
> didn't have enough time to look at it. As it stands, zip entries
> beyond 4GB cause
> an unchecked exception while attribute-scanning. This simple snippet
> is enough to demonstrate it, given a ZIP entry beyond 4GB range:
>
> try (FileSystem fs =
> FileSystems.newFileSystem(Paths.get("zipWithEntryBeyond4Gb.zip"))) {
>   for (Path root : fs.getRootDirectories()) {
>     Files.walkFileTree(root, new SimpleFileVisitor<>() {
>       @Override
>       public FileVisitResult visitFile(Path file, BasicFileAttributes
> attrs) throws IOException {
>         return FileVisitResult.CONTINUE;
>       }
>     });
>   }
> }
>
> The walkFileTree method is key here as it attempts to harvest
> attributes (why we use it is another story -- this saves a lot of time
> on large, network-mounted regular directories when you're collecting
> file metadata).
>
>
> Dawid
>
>
> On Wed, Oct 21, 2020 at 6:39 PM Lance Andersen
> <LANCE.ANDERSEN at oracle.com> wrote:
> >
> > Hi David,
> >
> > From  a quick look at ZipFileSystem this appears to be an optimization
> to avoid looking at the LOC extended Timestamp Extra field
> >
> > If a Info-ZIP Extended Timestamp (0x5455)is found then:
> >
> >   If the "zipinfo-time" entry was set  to ?false? in the Map specified
> when creating the Zip FileSystem,
> >
> > FileSystems.newFileSystem(zipFile, Map.of("zipinfo-time", "false")
> >
> > and the  data size of the CEN extended Timestamp is 5 (flag + mod time)
> >
> > The modified time is used from the CEN Extended Timestamp extra field
> >
> > Otherwise get the modified time, creation time, and access time from the
> LOC Extended Timestamp extra field.
> >
> >
> > ?????
> >
> >  Extended Timestamp Extra Field:
> >
> >           ==============================
> >
> >           The following is the layout of the extended-timestamp extra
> block.
> >           (Last Revision 19970118)
> >
> >           Local-header version:
> >
> >           Value         Size        Description
> >           -----         ----        -----------
> >   (time)  0x5455        Short       tag for this extra block type ("UT")
> >           TSize         Short       total data size for this block
> >           Flags         Byte        info bits
> >           (ModTime)     Long        time of last modification (UTC/GMT)
> >           (AcTime)      Long        time of last access (UTC/GMT)
> >           (CrTime)      Long        time of original creation (UTC/GMT)
> >
> >           Central-header version:
> >
> >           Value         Size        Description
> >           -----         ----        -----------
> >   (time)  0x5455        Short       tag for this extra block type ("UT")
> >           TSize         Short       total data size for this block
> >           Flags         Byte        info bits (refers to local header!)
> >           (ModTime)     Long        time of last modification (UTC/GMT)
> >
> >           The central-header extra field contains the modification time
> only,
> >           or no timestamp at all.  TSize is used to flag its presence or
> >           absence.  But note:
> >
> >               If "Flags" indicates that Modtime is present in the local
> header
> >               field, it MUST be present in the central header field, too!
> >               This correspondence is required because the modification
> time
> >               value may be used to support trans-timezone freshening and
> >               updating operations with zip archives.
> >
> >           The time values are in standard Unix signed-long format,
> indicating
> >           the number of seconds since 1 January 1970 00:00:00.  The times
> >           are relative to Coordinated Universal Time (UTC), also
> sometimes
> >           referred to as Greenwich Mean Time (GMT).  To convert to local
> time,
> >           the software must know the local timezone offset from UTC/GMT.
> >
> >           The lower three bits of Flags in both headers indicate which
> time-
> >           stamps are present in the LOCAL extra field:
> >
> >                 bit 0           if set, modification time is present
> >                 bit 1           if set, access time is present
> >                 bit 2           if set, creation time is present
> >                 bits 3-7        reserved for additional timestamps; not
> set
> >
> >           Those times that are present will appear in the order
> indicated, but
> >           any combination of times may be omitted.  (Creation time may be
> >           present without access time, for example.)  TSize should equal
> >           (1 + 4*(number of set bits in Flags)), as the block is
> currently
> >           defined.  Other timestamps may be added in the future.
> >
> >
> > --------------
> >
> > It's hard to comment on why you received the error that you did but it
> is possible the tool that was used for writing the entry  did something
> unexpected.
> >
> > Out of curiosity, have you tried using ZipFile/ZipEntry to access the
> entry?
> >
> >
> > Best,
> > Lance
> >
> >
> > On Oct 21, 2020, at 4:55 AM, Dawid Weiss <dawid.weiss at gmail.com> wrote:
> >
> > Hello,
> >
> > We've encountered a seemingly valid ZIP file (zipinfo -v shows all its
> > entries are intact) that causes a runtime exception when scanning its
> > contents with ZipFileSystem. The exception indicates an invalid
> > signature when parsing EXTID_EXTT. I don't quite understand this
> > comment in the code:
> >
> > case EXTID_EXTT:
> >    // spec says the Extened timestamp in cen only has mtime
> >    // need to read the loc to get the extra a/ctime, if flag
> >    // "zipinfo-time" is not specified to false;
> >    // there is performance cost (move up to loc and read) to
> >    // access the loc table foreach entry;
> >    if (zipfs.noExtt) {
> >        if (sz == 5)
> >            mtime = unixToJavaTime(LG(extra, pos + 1));
> >         break;
> >    }
> > ...
> >
> > but this ZIP file has the extra data block of exactly 5 bytes, as
> > indicated by zipinfo:
> >
> > Central directory entry #6:
> > ---------------------------
> > ...
> >  file system or operating system of origin:      Unix
> >  version of encoding software:                   3.0
> >  minimum file system compatibility required:     MS-DOS, OS/2 or NT FAT
> >  minimum software version required to extract:   2.0
> >  compression method:                             deflated
> > ...
> >  extended local header:                          no
> >  file last modified on (DOS date/time):          2018 Mar 1 04:56:20
> >  file last modified on (UT extra field modtime): 2018 Mar 1 05:56:19
> local
> >  file last modified on (UT extra field modtime): 2018 Mar 1 04:56:19 UTC
> > ...
> >  Unix file attributes (100000 octal):            ----------
> >  MS-DOS file attributes (01 hex):                read-only
> >
> >  The central-directory extra field contains:
> >  - A subfield with ID 0x5455 (universal time) and 5 data bytes.
> >    The local extra field has UTC/GMT modification/access times.
> >
> > The above conditional block checking for length == 5 would have worked
> > in ZipFileSystem but it's surrounded by a condition over an
> > externally-provided property - zipfs.noExtt is only set to true if:
> >
> > this.noExtt = "false".equals(env.get("zipinfo-time"));
> >
> > I can't share this particular ZIP file with you and I don't know how
> > it was created but it seems like that "zipinfo-time" flag could be
> > omitted if the length of the extra data field is exactly 5?
> >
> > Dawid
> >
> >
> >
> > Best
> > Lance
> > ------------------
> >
> >
> >
> > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
> > Oracle Java Engineering
> > 1 Network Drive
> > Burlington, MA 01803
> > Lance.Andersen at oracle.com
> >
> >
> >
> >
>

From redestad at openjdk.java.net  Fri Oct 23 08:03:51 2020
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 23 Oct 2020 08:03:51 GMT
Subject: RFR: 8255299: Drop explicit zeroing at instantiation of Atomic*
 objects
In-Reply-To: <Bc1YybkJpxM06gYYRRaXsWlYOgf0iDwdw6MyPCiOUuY=.76053af0-dccd-4b14-8729-193daa70b091@github.com>
References: <Bc1YybkJpxM06gYYRRaXsWlYOgf0iDwdw6MyPCiOUuY=.76053af0-dccd-4b14-8729-193daa70b091@github.com>
Message-ID: <UFtn8VaJM1cAXrMBv_n7vga1ebhNfBjEjowMz_hEPyE=.0e65792f-4bc6-486c-94c9-dcc3d25f23c4@github.com>

On Thu, 22 Oct 2020 20:46:15 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

> As discussed in https://github.com/openjdk/jdk/pull/510 there is never a reason to explicitly instantiate any instance of `Atomic*` class with its default value, i.e. `new AtomicInteger(0)` could be replaced with `new AtomicInteger()` which is faster:
> @State(Scope.Thread)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> @BenchmarkMode(value = Mode.AverageTime)
> public class AtomicBenchmark {
>   @Benchmark
>   public Object defaultValue() {
>     return new AtomicInteger();
>   }
>   @Benchmark
>   public Object explicitValue() {
>     return new AtomicInteger(0);
>   }
> }
> THis benchmark demonstrates that `explicitValue()` is much slower:
> Benchmark                      Mode  Cnt   Score   Error  Units
> AtomicBenchmark.defaultValue   avgt   30   4.778 ? 0.403  ns/op
> AtomicBenchmark.explicitValue  avgt   30  11.846 ? 0.273  ns/op
> So meanwhile https://bugs.openjdk.java.net/browse/JDK-8145948 is still in progress we could trivially replace explicit zeroing with default constructors gaining some performance benefit with no risk.
> 
> I've tested the changes locally, both tier1 and tier 2 are ok. 
> 
> Could one create an issue for tracking this?

Filed [8255299](https://bugs.openjdk.java.net/browse/JDK-8255299) for this. Prefix the name of the PR with "8255299: " and it should pass checks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/818

From github.com+10835776+stsypanov at openjdk.java.net  Fri Oct 23 08:03:51 2020
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Fri, 23 Oct 2020 08:03:51 GMT
Subject: RFR: 8255299: Drop explicit zeroing at instantiation of Atomic*
 objects
Message-ID: <Bc1YybkJpxM06gYYRRaXsWlYOgf0iDwdw6MyPCiOUuY=.76053af0-dccd-4b14-8729-193daa70b091@github.com>

As discussed in https://github.com/openjdk/jdk/pull/510 there is never a reason to explicitly instantiate any instance of `Atomic*` class with its default value, i.e. `new AtomicInteger(0)` could be replaced with `new AtomicInteger()` which is faster:
@State(Scope.Thread)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
@BenchmarkMode(value = Mode.AverageTime)
public class AtomicBenchmark {
  @Benchmark
  public Object defaultValue() {
    return new AtomicInteger();
  }
  @Benchmark
  public Object explicitValue() {
    return new AtomicInteger(0);
  }
}
THis benchmark demonstrates that `explicitValue()` is much slower:
Benchmark                      Mode  Cnt   Score   Error  Units
AtomicBenchmark.defaultValue   avgt   30   4.778 ? 0.403  ns/op
AtomicBenchmark.explicitValue  avgt   30  11.846 ? 0.273  ns/op
So meanwhile https://bugs.openjdk.java.net/browse/JDK-8145948 is still in progress we could trivially replace explicit zeroing with default constructors gaining some performance benefit with no risk.

I've tested the changes locally, both tier1 and tier 2 are ok. 

Could one create an issue for tracking this?

-------------

Commit messages:
 - 8255299: Drop explicit zeroing at instantiation of Atomic* objects

Changes: https://git.openjdk.java.net/jdk/pull/818/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=818&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8255299
  Stats: 19 lines in 17 files changed: 0 ins; 3 del; 16 mod
  Patch: https://git.openjdk.java.net/jdk/pull/818.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/818/head:pull/818

PR: https://git.openjdk.java.net/jdk/pull/818

From redestad at openjdk.java.net  Fri Oct 23 08:08:35 2020
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 23 Oct 2020 08:08:35 GMT
Subject: RFR: 8255299: Drop explicit zeroing at instantiation of Atomic*
 objects
In-Reply-To: <Bc1YybkJpxM06gYYRRaXsWlYOgf0iDwdw6MyPCiOUuY=.76053af0-dccd-4b14-8729-193daa70b091@github.com>
References: <Bc1YybkJpxM06gYYRRaXsWlYOgf0iDwdw6MyPCiOUuY=.76053af0-dccd-4b14-8729-193daa70b091@github.com>
Message-ID: <a7akNKOUo7C8Zp2oI7gWoNrY82jsAbjvlcSSjzghGIs=.56787fcd-8758-47ca-89bd-a74ba7f1a7b6@github.com>

On Thu, 22 Oct 2020 20:46:15 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

> As discussed in https://github.com/openjdk/jdk/pull/510 there is never a reason to explicitly instantiate any instance of `Atomic*` class with its default value, i.e. `new AtomicInteger(0)` could be replaced with `new AtomicInteger()` which is faster:
> @State(Scope.Thread)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> @BenchmarkMode(value = Mode.AverageTime)
> public class AtomicBenchmark {
>   @Benchmark
>   public Object defaultValue() {
>     return new AtomicInteger();
>   }
>   @Benchmark
>   public Object explicitValue() {
>     return new AtomicInteger(0);
>   }
> }
> THis benchmark demonstrates that `explicitValue()` is much slower:
> Benchmark                      Mode  Cnt   Score   Error  Units
> AtomicBenchmark.defaultValue   avgt   30   4.778 ? 0.403  ns/op
> AtomicBenchmark.explicitValue  avgt   30  11.846 ? 0.273  ns/op
> So meanwhile https://bugs.openjdk.java.net/browse/JDK-8145948 is still in progress we could trivially replace explicit zeroing with default constructors gaining some performance benefit with no risk.
> 
> I've tested the changes locally, both tier1 and tier 2 are ok. 
> 
> Could one create an issue for tracking this?

Marked as reviewed by redestad (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/818

From serb at openjdk.java.net  Fri Oct 23 08:17:40 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 23 Oct 2020 08:17:40 GMT
Subject: RFR: 8255299: Drop explicit zeroing at instantiation of Atomic*
 objects
In-Reply-To: <Bc1YybkJpxM06gYYRRaXsWlYOgf0iDwdw6MyPCiOUuY=.76053af0-dccd-4b14-8729-193daa70b091@github.com>
References: <Bc1YybkJpxM06gYYRRaXsWlYOgf0iDwdw6MyPCiOUuY=.76053af0-dccd-4b14-8729-193daa70b091@github.com>
Message-ID: <U2xyKaDQS32Nm02PpBj391aGVSN-VZ9yACXbePoyY_Y=.765caedb-3ac3-4991-8b97-1637811edbf1@github.com>

On Thu, 22 Oct 2020 20:46:15 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

> As discussed in https://github.com/openjdk/jdk/pull/510 there is never a reason to explicitly instantiate any instance of `Atomic*` class with its default value, i.e. `new AtomicInteger(0)` could be replaced with `new AtomicInteger()` which is faster:
> @State(Scope.Thread)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> @BenchmarkMode(value = Mode.AverageTime)
> public class AtomicBenchmark {
>   @Benchmark
>   public Object defaultValue() {
>     return new AtomicInteger();
>   }
>   @Benchmark
>   public Object explicitValue() {
>     return new AtomicInteger(0);
>   }
> }
> THis benchmark demonstrates that `explicitValue()` is much slower:
> Benchmark                      Mode  Cnt   Score   Error  Units
> AtomicBenchmark.defaultValue   avgt   30   4.778 ? 0.403  ns/op
> AtomicBenchmark.explicitValue  avgt   30  11.846 ? 0.273  ns/op
> So meanwhile https://bugs.openjdk.java.net/browse/JDK-8145948 is still in progress we could trivially replace explicit zeroing with default constructors gaining some performance benefit with no risk.
> 
> I've tested the changes locally, both tier1 and tier 2 are ok. 
> 
> Could one create an issue for tracking this?

The changes in src/java.desktop looks fine.

-------------

Marked as reviewed by serb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/818

From redestad at openjdk.java.net  Fri Oct 23 08:21:35 2020
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 23 Oct 2020 08:21:35 GMT
Subject: RFR: 8229845: Decrease memory consumption of BigInteger.toString()
In-Reply-To: <QcssqDSre9zJ5L6fYGesmxienoFDYDebNM2fJUMe_bw=.3236bd5c-5900-4c0b-9e00-21a7bf24b9b4@github.com>
References: <QcssqDSre9zJ5L6fYGesmxienoFDYDebNM2fJUMe_bw=.3236bd5c-5900-4c0b-9e00-21a7bf24b9b4@github.com>
Message-ID: <qkFujixJVxpi0TiGRI-qlXz1vBvSw559crPPQdneNKI=.acc233b6-4b0f-42f5-9b54-37d5da85a7be@github.com>

On Thu, 22 Oct 2020 20:56:44 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Please review this proposed fix. The review was initially in this thread
> 
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-August/061914.html
> 
> under the old Hg SCM. The changes proposed here are derived from the final (.05) patch in the previous review which was posted in
> 
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-August/062012.html.

LGTM.

A microbenchmark or something that summarizes the improvement and can verify that we don't regress on some variant would've been nice.

-------------

Marked as reviewed by redestad (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/819

From dfuchs at openjdk.java.net  Fri Oct 23 09:14:43 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 23 Oct 2020 09:14:43 GMT
Subject: RFR: 8255299: Drop explicit zeroing at instantiation of Atomic*
 objects
In-Reply-To: <Bc1YybkJpxM06gYYRRaXsWlYOgf0iDwdw6MyPCiOUuY=.76053af0-dccd-4b14-8729-193daa70b091@github.com>
References: <Bc1YybkJpxM06gYYRRaXsWlYOgf0iDwdw6MyPCiOUuY=.76053af0-dccd-4b14-8729-193daa70b091@github.com>
Message-ID: <PG8nxD4Mf9_jJpCgRj_pRrvUuT38qRaK0CoGpcm8y4U=.9e282356-0e4b-4034-ac6b-ca5afaa69424@github.com>

On Thu, 22 Oct 2020 20:46:15 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

> As discussed in https://github.com/openjdk/jdk/pull/510 there is never a reason to explicitly instantiate any instance of `Atomic*` class with its default value, i.e. `new AtomicInteger(0)` could be replaced with `new AtomicInteger()` which is faster:
> @State(Scope.Thread)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> @BenchmarkMode(value = Mode.AverageTime)
> public class AtomicBenchmark {
>   @Benchmark
>   public Object defaultValue() {
>     return new AtomicInteger();
>   }
>   @Benchmark
>   public Object explicitValue() {
>     return new AtomicInteger(0);
>   }
> }
> THis benchmark demonstrates that `explicitValue()` is much slower:
> Benchmark                      Mode  Cnt   Score   Error  Units
> AtomicBenchmark.defaultValue   avgt   30   4.778 ? 0.403  ns/op
> AtomicBenchmark.explicitValue  avgt   30  11.846 ? 0.273  ns/op
> So meanwhile https://bugs.openjdk.java.net/browse/JDK-8145948 is still in progress we could trivially replace explicit zeroing with default constructors gaining some performance benefit with no risk.
> 
> I've tested the changes locally, both tier1 and tier 2 are ok. 
> 
> Could one create an issue for tracking this?

src/java.base/share/classes/sun/net/ResourceManager.java line 65:

> 63:         } catch (NumberFormatException e) {}
> 64:         maxSockets = defmax;
> 65:         numSockets = new AtomicInteger();

Changes in sun/net look good to me.

-------------

PR: https://git.openjdk.java.net/jdk/pull/818

From dfuchs at openjdk.java.net  Fri Oct 23 09:17:36 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 23 Oct 2020 09:17:36 GMT
Subject: RFR: 8255299: Drop explicit zeroing at instantiation of Atomic*
 objects
In-Reply-To: <U2xyKaDQS32Nm02PpBj391aGVSN-VZ9yACXbePoyY_Y=.765caedb-3ac3-4991-8b97-1637811edbf1@github.com>
References: <Bc1YybkJpxM06gYYRRaXsWlYOgf0iDwdw6MyPCiOUuY=.76053af0-dccd-4b14-8729-193daa70b091@github.com>
 <U2xyKaDQS32Nm02PpBj391aGVSN-VZ9yACXbePoyY_Y=.765caedb-3ac3-4991-8b97-1637811edbf1@github.com>
Message-ID: <JbMPcYdgEa-E-congqKtykPOp2tbK5NT5cN9NwPzdKY=.92bcae3c-6514-48cb-b102-551c7a798e6f@github.com>

On Fri, 23 Oct 2020 08:15:00 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> As discussed in https://github.com/openjdk/jdk/pull/510 there is never a reason to explicitly instantiate any instance of `Atomic*` class with its default value, i.e. `new AtomicInteger(0)` could be replaced with `new AtomicInteger()` which is faster:
>> @State(Scope.Thread)
>> @OutputTimeUnit(TimeUnit.NANOSECONDS)
>> @BenchmarkMode(value = Mode.AverageTime)
>> public class AtomicBenchmark {
>>   @Benchmark
>>   public Object defaultValue() {
>>     return new AtomicInteger();
>>   }
>>   @Benchmark
>>   public Object explicitValue() {
>>     return new AtomicInteger(0);
>>   }
>> }
>> THis benchmark demonstrates that `explicitValue()` is much slower:
>> Benchmark                      Mode  Cnt   Score   Error  Units
>> AtomicBenchmark.defaultValue   avgt   30   4.778 ? 0.403  ns/op
>> AtomicBenchmark.explicitValue  avgt   30  11.846 ? 0.273  ns/op
>> So meanwhile https://bugs.openjdk.java.net/browse/JDK-8145948 is still in progress we could trivially replace explicit zeroing with default constructors gaining some performance benefit with no risk.
>> 
>> I've tested the changes locally, both tier1 and tier 2 are ok. 
>> 
>> Could one create an issue for tracking this?
>
> The changes in src/java.desktop looks fine.

Changes to `java.logging` and `java.net.http` also look good to me.

-------------

PR: https://git.openjdk.java.net/jdk/pull/818

From dfuchs at openjdk.java.net  Fri Oct 23 09:36:42 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 23 Oct 2020 09:36:42 GMT
Subject: RFR: 8251989: Hex formatting and parsing utility [v8]
In-Reply-To: <lX-d05Nj6nFlHSW_d-xVM0vihr1UQtxcFyCpN282hVo=.8e23858e-f014-4acb-83ed-b1310835b42a@github.com>
References: <HSEn47GMS1K3g57mrTZeQk-WZHl3pKGHpX_OOf8VnsU=.740863c2-f9e4-43c4-b500-614aab4078b1@github.com>
 <lX-d05Nj6nFlHSW_d-xVM0vihr1UQtxcFyCpN282hVo=.8e23858e-f014-4acb-83ed-b1310835b42a@github.com>
Message-ID: <EvfwtUcXo4jpOHn30CokFjnNw4yTaqvSRjg_exrMcZ0=.daa01c09-87fb-43a4-9d4e-859f20a910d5@github.com>

On Thu, 22 Oct 2020 15:55:30 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> java.util.HexFormat utility:
>> 
>>  - Format and parse hexadecimal strings, with parameters for delimiter, prefix, suffix and upper/lowercase
>>  - Static factories and builder methods to create HexFormat copies with modified parameters.
>>  - Consistent naming of methods for conversion of byte arrays to formatted strings and back: formatHex and parseHex
>>  - Consistent naming of methods for conversion of primitive types: toHexDigits... and fromHexDigits...
>>  - Prefix and suffixes now apply to each formatted value, not the string as a whole
>>  - Using java.util.Appendable as a target for buffered conversions so output to Writers and PrintStreams
>>    like System.out are supported in addition to StringBuilder. (IOExceptions are converted to unchecked exceptions)
>>  - Immutable and thread safe, a "value-based" class
>> 
>> See the [HexFormat javadoc](http://cr.openjdk.java.net/~rriggs/8251989-hex-formatter/java.base/java/util/HexFormat.html) for details.
>> 
>> Review comments and suggestions welcome.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment updates to class javadoc

Marked as reviewed by dfuchs (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/482

From github.com+10835776+stsypanov at openjdk.java.net  Fri Oct 23 09:59:41 2020
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Fri, 23 Oct 2020 09:59:41 GMT
Subject: RFR: 8255299: Drop explicit zeroing at instantiation of Atomic*
 objects
In-Reply-To: <PG8nxD4Mf9_jJpCgRj_pRrvUuT38qRaK0CoGpcm8y4U=.9e282356-0e4b-4034-ac6b-ca5afaa69424@github.com>
References: <Bc1YybkJpxM06gYYRRaXsWlYOgf0iDwdw6MyPCiOUuY=.76053af0-dccd-4b14-8729-193daa70b091@github.com>
 <PG8nxD4Mf9_jJpCgRj_pRrvUuT38qRaK0CoGpcm8y4U=.9e282356-0e4b-4034-ac6b-ca5afaa69424@github.com>
Message-ID: <jxy-a6J40FvSQDynQJ6JCGy0jvQYXzpMPzE5jOsiCOM=.0b371e3c-1370-42be-9af2-29f43b73aef8@github.com>

On Fri, 23 Oct 2020 09:12:15 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> As discussed in https://github.com/openjdk/jdk/pull/510 there is never a reason to explicitly instantiate any instance of `Atomic*` class with its default value, i.e. `new AtomicInteger(0)` could be replaced with `new AtomicInteger()` which is faster:
>> @State(Scope.Thread)
>> @OutputTimeUnit(TimeUnit.NANOSECONDS)
>> @BenchmarkMode(value = Mode.AverageTime)
>> public class AtomicBenchmark {
>>   @Benchmark
>>   public Object defaultValue() {
>>     return new AtomicInteger();
>>   }
>>   @Benchmark
>>   public Object explicitValue() {
>>     return new AtomicInteger(0);
>>   }
>> }
>> THis benchmark demonstrates that `explicitValue()` is much slower:
>> Benchmark                      Mode  Cnt   Score   Error  Units
>> AtomicBenchmark.defaultValue   avgt   30   4.778 ? 0.403  ns/op
>> AtomicBenchmark.explicitValue  avgt   30  11.846 ? 0.273  ns/op
>> So meanwhile https://bugs.openjdk.java.net/browse/JDK-8145948 is still in progress we could trivially replace explicit zeroing with default constructors gaining some performance benefit with no risk.
>> 
>> I've tested the changes locally, both tier1 and tier 2 are ok. 
>> 
>> Could one create an issue for tracking this?
>
> src/java.base/share/classes/sun/net/ResourceManager.java line 65:
> 
>> 63:         } catch (NumberFormatException e) {}
>> 64:         maxSockets = defmax;
>> 65:         numSockets = new AtomicInteger();
> 
> Changes in sun/net look good to me.

@dfuch Could you then sponsor this PR?

-------------

PR: https://git.openjdk.java.net/jdk/pull/818

From kravikumar at openjdk.java.net  Fri Oct 23 10:15:38 2020
From: kravikumar at openjdk.java.net (Kiran Sidhartha Ravikumar)
Date: Fri, 23 Oct 2020 10:15:38 GMT
Subject: Integrated: 8254982: (tz) Upgrade time-zone data to tzdata2020c
In-Reply-To: <rQR51lGOpSaH5qywIqXV9ymJ36TbsUYzcurNCsvZ7OE=.21381473-7776-4ea5-8a03-734e1b3b11d9@github.com>
References: <rQR51lGOpSaH5qywIqXV9ymJ36TbsUYzcurNCsvZ7OE=.21381473-7776-4ea5-8a03-734e1b3b11d9@github.com>
Message-ID: <KjTE9nDT6TrbT3DzZQBCdkeWvgRUo4GXzztGGkGoZ_c=.65c238da-8b6f-4c65-b3a7-ab5f516fe1ba@github.com>

On Mon, 19 Oct 2020 18:44:28 GMT, Kiran Sidhartha Ravikumar <kravikumar at openjdk.org> wrote:

> Hi Guys,
> 
> Please review the integration of tzdata2020c to JDK. 
> 
> Details regarding the change can be viewed at - https://mm.icann.org/pipermail/tz-announce/2020-October/000060.html
> Bug: https://bugs.openjdk.java.net/browse/JDK-8254982
> 
> Along with it, there is a test fix for https://bugs.openjdk.java.net/browse/JDK-8254865, With tzdata2020b, the test fails for the mentioned zones expecting "PST" but JDK has Zone names for "MST" for JRE locale provider. Since the purpose of the test is to get any GMT-08:00 time zone, I have excluded those zones from the test.
> 
> Please let me know if the changes are good to push.
> 
> Thanks,
> Kiran

This pull request has now been integrated.

Changeset: 55a0cad8
Author:    Kiran Sidhartha Ravikumar <kravikumar at openjdk.org>
Committer: Sean Coffey <coffeys at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/55a0cad8
Stats:     33 lines in 4 files changed: 30 ins; 0 del; 3 mod

8254982: (tz) Upgrade time-zone data to tzdata2020c

Reviewed-by: erikj, naoto

-------------

PR: https://git.openjdk.java.net/jdk/pull/747

From plevart at openjdk.java.net  Fri Oct 23 10:35:35 2020
From: plevart at openjdk.java.net (Peter Levart)
Date: Fri, 23 Oct 2020 10:35:35 GMT
Subject: RFR: 8159746: (proxy) Support for default methods
In-Reply-To: <CoqZRJ39DVdNI9wzS372aAG3ZIB7hrIrndaO5VrsmBA=.f78629d2-3409-44c1-9e66-7951bbd630e6@github.com>
References: <kw2VXh3vTFf1zgfd4biXA41OKffZ5oU7KT23tXAxgUA=.bcf14ffc-4dba-4c9c-8754-184172c5acbd@github.com>
 <U-6RiCpFVIrhLztPN6opiPcpFtxValDzU-K7WWFZM-4=.6bc8aaa4-636a-4664-b380-4c4af00513bd@github.com>
 <-cLIJ8pFHtnNoJMHV3aXI7XMJWp4Jrutc8Xn5PG0OK8=.d2cd87ab-3592-4524-ad85-05444c43689b@github.com>
 <r0UK2qjnmgeTNDDSWaSLPAj3QRgx_4YB82ielllO7jM=.fa615bc0-db49-4a74-b842-793f8f5209bb@github.com>
 <1T8kXDZN1bhHr4c8v4SQsImeBySCqTfX-u3_jzvyocA=.b4957400-9a33-4b6e-8475-329642a5888c@github.com>
 <XIux-dY0JXHRafHk48kVNXId9r-HSceNSytBojDxelY=.872e74cb-b064-406e-b71f-13c90ec7fbbc@github.com>
 <j4t2vT0SnwnU7lhKRlXtk967d-K6nA0EqHrqNbba7W0=.dc05dba6-bf7e-4606-8a02-9c2bad4b3b58@github.com>
 <fmVtPcBdgMuZOPm2qx3Q3znVZM7JgQPkhPAVLtwkOhE=.2d8b8447-cfae-4cb3-9a7c-6567a881231f@github.com>
 <GSeWP29fAIUFSk0CYsC557w52CuLqeUWwHNK9maltwI=.3d5f002e-6b74-4a57-a5d8-244d27da9dde@github.com>
 <GF8iEOkMUEL2dYB0HytFIc9gyeeUJ_KP0ImlqFsul2Y=.894afc05-9310-43e1-a308-8f7d71dc572b@github.com>
 <HvtDex3cmiv7XeTMITOroYfu74amSGQavQ_
 BAmVzmXw=.223be989-7c20-4ba4-ac0d-013d2b75a8cb@github.com>
 <IqRiLphFPBpGiKAnMJXqxjie9YeZ03rcE-qG1s92BLw=.d4fd5e92-5067-40df-8a0b-1dfd3d6e23af@github.com>
 <Y0hE51G3YefI6NY1O_E6VoZSKwxE78S1hv6fEatmOG8=.0a2c686c-d9ad-418c-8c1b-49addb8a54b1@github.com>
 <QrNk57L2PWQhJjzYiGTsvYyGIPAfK7bP_kANtTR-2uM=.3e5ce990-f8ea-4751-8147-27a8a9dad40d@github.com>
 <9JNNUzfV3PSvKtSg2a_zyYJmgEn3sZL9cb5sfqemk2o=.f1ef7fb7-bdd5-44ed-98c8-59213e9094f9@github.com>
 <zWGhaC8YB5I0XgffiR7o_YT5gSp9Gbj8Drtt23brl-c=.1e59f0e4-bbe3-4fb2-94dc-c55fc862f091@github.com>
 <LljojgqBhEi6tFptsbmu1jS-Xx7lYEXm9tRkkPqDGzE=.3d7d6a37-1042-4539-88d1-9f4cf5378128@github.com>
 <Gn33ydZNxqOpWUrmYiWJadMF0mukI2MR85EtgrV4D1I=.958521f2-1167-4a68-b513-e10bba37ae18@github.com>
 <NMXKaHql9XjndqPgyoN1Lasa9H8ugl8-ltD1j2XiT9Y=.3ff8871e-0f9d-40ea-8f35-e804a9afcbd5@github.com>
 <yzFe02HJ2qt5tT8tY9ZOofnKld93x1PM5U7AToTABJs=.439c213b-94b9-488f-bb6d-a835a86c527f@github.com>
 <BoATjx7PPcLpINJVC5HM77UKMriIUqnnhcBowkJRlvM=.1221e3e1-ed27-4618-8365-dcd903d27f60@
 github.com>
 <yN0JJE9mBkqz9Ijbw4FYinv08tcnxiZHAGyarXBF9CY=.50429cb9-181a-447e-90a0-e0a0a836812e@github.com>
 <CoqZRJ39DVdNI9wzS372aAG3ZIB7hrIrndaO5VrsmBA=.f78629d2-3409-44c1-9e66-7951bbd630e6@github.com>
Message-ID: <W6qIb_NPGRUpQd_obRiIumwbXSTDheSdg-qnkc3cZ90=.f1f46290-3b7c-4e88-994f-5d19e0134256@github.com>

On Thu, 22 Oct 2020 17:07:55 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Thanks for the update. Lots of challenges finding the right API as there are security and usability issues, not to mention performance and making it look like the support for default methods has always been there.
>> 
>> I've skimmed through both prototypes in proxy-method-default-3 branch, both seem to be secure.
>> 
>> NewInvocationHandler/DefaultMethodInvoker feels a bit awkward. If I have it right, to use it as a lambda expression to Proxy.newProxyInterface would require casting to NewInvocationHandler. I also need to be careful when using the invoker and not call it with a non-default method.
>> 
>> DelegatingInvocationHandler feels more like a base implementation that I extend when I need help invoking default methods. Naming aside, it feels like it fits in better but with the downside that an instance can't be used as a functional interface. So I agree this one is a better. The users of this API will be super advanced developers and I would expect retrofitting existing code shouldn't be too hard for that are compiled to 16+.
>
>> NewInvocationHandler/DefaultMethodInvoker feels a bit awkward. If I have it right, to use it as a lambda expression to Proxy.newProxyInterface would require casting to NewInvocationHandler. I also need to be careful when using the invoker and not call it with a non-default method.
> 
> Yes it requires casting to `NewInvocationHandler` or  assign the lambda in a local variable.

Hi Mandy,

I think what matters here is a public surface area - what user sees. The API friendliness is the 1st aspect and very close to that is performance on the 2nd place. How complicated things are in the back is not unimportant, but very far from the leading two. I think this is how alternatives should be compared.

What I have done in my last attempt (https://github.com/mlchung/jdk/pull/4) is, admittedly, quite large from API surface. New `InvocationHandler2` interface taking additional `InvocationHandler2.SuperInvoker` callback + new overloaded static factory method `Proxy.newProxyInstance`. Additionally, internal checks needed to verify access at `newProxyInstance`-time are quite complicated since `InvocationHandler2` is a super-type of `InvocationHandler` and therefore the code has to check that the default implementation of `InvocationHandler.invoke(SuperInvoker, ...)` method is not overridden or else additional checks must be performed. This leads to complicated specification as to when access exceptions are thrown. From performance perspective, this variant showed least per-invocation overhead so far:

Benchmark               Mode  Cnt   Score   Error  Units

ProxyBench.implClass    avgt    5   3.777 ? 0.003  ns/op
ProxyBench.implProxy    avgt    5  20.282 ? 0.585  ns/op
ProxyBench.ppImplClass  avgt    5   3.752 ? 0.002  ns/op
ProxyBench.ppImplProxy  avgt    5  19.790 ? 0.335  ns/op

Your `DelegatingInvocationHandler` abstract class is nice and simple, but unfortunately not lambda-friendly. Will this hinder its use? I don't know. Alan says that this feature will mostly be for "experts", but even they like to use lambdas. The performance is quite OK as runtime per-invocation checks are not very expensive, just ~ 50% slower than my attempt above. Note that the allocation of 96 bytes per invocation is due to boxing 3 primitive argument ints into Integers which is unavoidable:

Benchmark                                                Mode  Cnt     Score      Error   Units

ProxyBench.implClass                                     avgt    5     3.765 ?    0.028   ns/op
ProxyBench.implProxy                                     avgt    5    29.812 ?    0.180   ns/op
ProxyBench.ppImplClass                                   avgt    5     3.705 ?    0.110   ns/op
ProxyBench.ppImplProxy                                   avgt    5    31.209 ?    0.900   ns/op

ProxyBench.implClass:?gc.alloc.rate.norm                 avgt    5    ? 10??               B/op
ProxyBench.implProxy:?gc.alloc.rate.norm                 avgt    5    96.004 ?    0.001    B/op
ProxyBench.ppImplClass:?gc.alloc.rate.norm               avgt    5    ? 10??               B/op
ProxyBench.ppImplProxy:?gc.alloc.rate.norm               avgt    5    96.004 ?    0.001    B/op

(NOTE: I noticed a possibility of a concurrent race condition in `Proxy.newProxyInstance` that could be used to fool the proxy interfaces access check - the array of interfaces is not defensively cloned)

Your `NewInvocationHandler` as a subinterface of `InvocationHandler` that overrides the InvocationHandler.invoke(Object proxy, ... and wires it to new abstract method taking additional DefaultMethodInvoker parameter seems similar to my last attempt, just subtype roles of old and new interfaces are reversed. This means it is easier to check whether the invocation handler has access to the super default methods or not (handler instanceof NewInvocationHandler) and adjust access checks in Proxy.newProxyInstance accordingly. But, as a consequence, the DefaultMethodInvoker instance has to be created for each invocation. You could also add an overloaded Proxy.newProxyInstance method to accept a lambda with 4 parameters (NewInvocationHandler), so this variant could be made user-friendly too, not requiring a cast. The performance is a little slower then abstract handler class. Also, the allocation of new instance of DefaultMethodInvoker per invocation seems unable to be optimized away by JIT 
 escape analysis (maybe the DefaultMethodInvoker.invoke is to big to be inlined), so we have 16 additional bytes allocated per invocation:

Benchmark                                                Mode  Cnt     Score     Error   Units

ProxyBench.implClass                                     avgt    5     3.760 ?   0.049   ns/op
ProxyBench.implProxy                                     avgt    5    34.260 ?   0.993   ns/op
ProxyBench.ppImplClass                                   avgt    5     3.745 ?   0.008   ns/op
ProxyBench.ppImplProxy                                   avgt    5    34.247 ?   0.743   ns/op

ProxyBench.implClass:?gc.alloc.rate.norm                 avgt    5    ? 10??              B/op
ProxyBench.implProxy:?gc.alloc.rate.norm                 avgt    5   112.005 ?   0.001    B/op
ProxyBench.ppImplClass:?gc.alloc.rate.norm               avgt    5    ? 10??              B/op
ProxyBench.ppImplProxy:?gc.alloc.rate.norm               avgt    5   112.005 ?   0.001    B/op


>From above 3 variants, I agree the `DelegatingInvocationHandler` abstract class seems to be most promising. But I have been thinking more about lambdas and have another idea that actually doesn't require any new types. Just an overloaded Proxy.newProxyInstance static method:

public static Object newProxyInstance(
    ClassLoader loader,
    Class<?>[] interfaces, 
    Function<? super InvocationHandler, ? extends InvocationHandler> handlerFactory
)

Here's the prototype:

https://github.com/plevart/jdk/commits/proxy-default-method-alt-api4

This is a patch against current https://github.com/openjdk/jdk, but all your latest "unrelated" changes (proxy class package/module) are included too. I can rebase this onto your https://github.com/mlchung/jdk/tree/proxy-default-method branch if required.

The performance of this one is the same as my previous alternative API 2:

Benchmark                                                Mode  Cnt     Score     Error   Units

ProxyBench.implClass                                     avgt    5     3.700 ?   0.013   ns/op
ProxyBench.implProxy                                     avgt    5    20.264 ?   0.551   ns/op
ProxyBench.ppImplClass                                   avgt    5     3.743 ?   0.028   ns/op
ProxyBench.ppImplProxy                                   avgt    5    20.274 ?   0.180   ns/op

ProxyBench.implClass:?gc.alloc.rate.norm                 avgt    5    ? 10??              B/op
ProxyBench.implProxy:?gc.alloc.rate.norm                 avgt    5    96.003 ?   0.001    B/op
ProxyBench.ppImplClass:?gc.alloc.rate.norm               avgt    5    ? 10??              B/op
ProxyBench.ppImplProxy:?gc.alloc.rate.norm               avgt    5    96.003 ?   0.001    B/op

So how does this compare to DelegatingInvocationHandler? It surely is more lambda-friendly and performance-wise it is the best we have so far. It is also not very complicated internally. The changes to ProxyGenerator are just to accomodate for new static final field holding the super-default-method InvocationHandler. Alternatively a ClassValue could be used for that without changes to ProxyGenerator albeit with somewhat bigger footprint per proxy class.

Now I would like to discuss one thing that relates to all implmenentations so far. Super default method invocation is currently modeled by the `Method.invoke` API, meaning that it throws `InvocationTargetException` wrapping the target exception thrown by the invoked method. But since this API is to be used from withing `InvocationHandler.invoke` implementations, such `InvocationTargetException` would typically need to be caught, unwrapped and its target exception re-thrown to honour the contract of the declared exceptions of the proxy method. If someone forgot to do that and leave `InvocationTargetException` to be thrown from `InvocationHandler.invoke` (and it would be very easy to forget that since that method is declared to throw `Throwable`), such `InvocationTargetException` would be wrapped again with `UndeclaredThrowableException` as per Proxy API behavior. So wouldn't it be better for the super-invoke API to throw exact exceptions that the invoked methods are throwing? No catch
 /re-throw unwrapped gymnastics would be necessary in the `InvocationHandler` implementations and forgetting to do that would not be possible. Such non-wrapping super-invoke API does not allow to distinguish between IllegalArgumentException(s) thrown by the invoked method and IllegalArgumentException(s) thrown from the API itself due to arguments incompatible with method signature though, but would one really want to distinguish them? Typically not. My alternative API 4 above uses existing `InvocationHandle.invoke` API for forwarding invocation to super default methods and this API already declares that it throws `Throwable` so it allows passing exceptions unwrapped, but current implementation still wraps exceptions thrown by the invoked method with IllegalArgumentException. If we decide that it is better to not wrap them, this can be trivially implemented.

Peter

-------------

PR: https://git.openjdk.java.net/jdk/pull/313

From ihse at openjdk.java.net  Fri Oct 23 11:04:41 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 23 Oct 2020 11:04:41 GMT
Subject: RFR: 8254231: Implementation of Foreign Linker API (Incubator)
 [v12]
In-Reply-To: <2IKx6cpc-IGP3jZtr0s2I14BWM6ptyFD26szPl3b1ng=.9d956b98-dfe6-4a45-a371-bf86923214fb@github.com>
References: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
 <2IKx6cpc-IGP3jZtr0s2I14BWM6ptyFD26szPl3b1ng=.9d956b98-dfe6-4a45-a371-bf86923214fb@github.com>
Message-ID: <x2n2-rE8gGCiMz0Yrwa6zvUWr2NCPAW-SG1f6H8qFCY=.81609fe6-75dc-4497-bfc0-2b394aed236b@github.com>

On Thu, 22 Oct 2020 17:04:34 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This patch contains the changes associated with the first incubation round of the foreign linker access API incubation
>> (see JEP 389 [1]). This work is meant to sit on top of the foreign memory access support (see JEP 393 [2] and associated pull request [3]).
>> 
>> The main goal of this API is to provide a way to call native functions from Java code without the need of intermediate JNI glue code. In order to do this, native calls are modeled through the MethodHandle API. I suggest reading the writeup [4] I put together few weeks ago, which illustrates what the foreign linker support is, and how it should be used by clients.
>> 
>> Disclaimer: the pull request mechanism isn't great at managing *dependent* reviews. For this reasons, I'm attaching a webrev which contains only the differences between this PR and the memory access PR. I will be periodically uploading new webrevs, as new iterations come out, to try and make the life of reviewers as simple as possible.
>> 
>> A big thank to Jorn Vernee and Vladimir Ivanov - they are the main architects of all the hotspot changes you see here, and without their help, the foreign linker support wouldn't be what it is today. As usual, a big thank to Paul Sandoz, who provided many insights (often by trying the bits first hand).
>> 
>> Thanks
>> Maurizio
>> 
>> Webrev:
>> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/webrev
>> 
>> Javadoc:
>> 
>> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/javadoc/jdk/incubator/foreign/package-summary.html
>> 
>> Specdiff (relative to [3]):
>> 
>> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/specdiff_delta/overview-summary.html
>> 
>> CSR:
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8254232
>> 
>> 
>> 
>> ### API Changes
>> 
>> The API changes are actually rather slim:
>> 
>> * `LibraryLookup`
>>   * This class allows clients to lookup symbols in native libraries; the interface is fairly simple; you can load a library by name, or absolute path, and then lookup symbols on that library.
>> * `FunctionDescriptor`
>>   * This is an abstraction that is very similar, in spirit, to `MethodType`; it is, at its core, an aggregate of memory layouts for the function arguments/return type. A function descriptor is used to describe the signature of a native function.
>> * `CLinker`
>>   * This is the real star of the show. A `CLinker` has two main methods: `downcallHandle` and `upcallStub`; the first takes a native symbol (as obtained from `LibraryLookup`), a `MethodType` and a `FunctionDescriptor` and returns a `MethodHandle` instance which can be used to call the target native symbol. The second takes an existing method handle, and a `FunctionDescriptor` and returns a new `MemorySegment` corresponding to a code stub allocated by the VM which acts as a trampoline from native code to the user-provided method handle. This is very useful for implementing upcalls.
>>    * This class also contains the various layout constants that should be used by clients when describing native signatures (e.g. `C_LONG` and friends); these layouts contain additional ABI classfication information (in the form of layout attributes) which is used by the runtime to *infer* how Java arguments should be shuffled for the native call to take place.
>>   * Finally, this class provides some helper functions e.g. so that clients can convert Java strings into C strings and back.
>> * `NativeScope`
>>   * This is an helper class which allows clients to group together logically related allocations; that is, rather than allocating separate memory segments using separate *try-with-resource* constructs, a `NativeScope` allows clients to use a _single_ block, and allocate all the required segments there. This is not only an usability boost, but also a performance boost, since not all allocation requests will be turned into `malloc` calls.
>> * `MemorySegment`
>>   * Only one method added here - namely `handoff(NativeScope)` which allows a segment to be transferred onto an existing native scope.
>> 
>> ### Safety
>> 
>> The foreign linker API is intrinsically unsafe; many things can go wrong when requesting a native method handle. For instance, the description of the native signature might be wrong (e.g. have too many arguments) - and the runtime has, in the general case, no way to detect such mismatches. For these reasons, obtaining a `CLinker` instance is a *restricted* operation, which can be enabled by specifying the usual JDK property `-Dforeign.restricted=permit` (as it's the case for other restricted method in the foreign memory API).
>> 
>> ### Implementation changes
>> 
>> The Java changes associated with `LibraryLookup` are relative straightforward; the only interesting thing to note here is that library loading does _not_ depend on class loaders, so `LibraryLookup` is not subject to the same restrictions which apply to JNI library loading (e.g. same library cannot be loaded by different classloaders).
>> 
>> As for `NativeScope` the changes are again relatively straightforward; it is an API which sits neatly on top of the foreign meory access API, providing some kind of allocation service which shares the same underlying memory segment(s), and turns an allocation request into a segment slice, which is a much less expensive operation. `NativeScope` comes in two variants: there are native scopes for which the allocation size is known a priori, and native scopes which can grow - these two schemes are implemented by two separate subclasses of `AbstractNativeScopeImpl`.
>> 
>> Of course the bulk of the changes are to support the `CLinker` downcall/upcall routines. These changes cut pretty deep into the JVM; I'll briefly summarize the goal of some of this changes - for further details, Jorn has put together a detailed writeup which explains the rationale behind the VM support, with some references to the code [5].
>> 
>> The main idea behind foreign linker is to infer, given a Java method type (expressed as a `MethodType` instance) and the description of the signature of a native function (expressed as a `FunctionDescriptor` instance) a _recipe_ that can be used to turn a Java call into the corresponding native call targeting the requested native function.
>> 
>> This inference scheme can be defined in a pretty straightforward fashion by looking at the various ABI specifications (for instance, see [6] for the SysV ABI, which is the one used on Linux/Mac). The various `CallArranger` classes, of which we have a flavor for each supported platform, do exactly that kind of inference.
>> 
>> For the inference process to work, we need to attach extra information to memory layouts; it is no longer sufficient to know e.g. that a layout is 32/64 bits - we need to know whether it is meant to represent a floating point value, or an integral value; this knowledge is required because floating points are passed in different registers by most ABIs. For this reason, `CLinker` offers a set of pre-baked, platform-dependent layout constants which contain the required classification attributes (e.g. a `Clinker.TypeKind` enum value). The runtime extracts this attribute, and performs classification accordingly.
>> 
>> A native call is decomposed into a sequence of basic, primitive operations, called `Binding` (see the great javadoc on the `Binding.java` class for more info). There are many such bindings - for instance the `Move` binding is used to move a value into a specific machine register/stack slot. So, the main job of the various `CallingArranger` classes is to determine, given a Java `MethodType` and `FunctionDescriptor` what is the set of bindings associated with the downcall/upcall.
>> 
>> At the heart of the foreign linker support is the `ProgrammableInvoker` class. This class effectively generates a `MethodHandle` which follows the steps described by the various bindings obtained by `CallArranger`. There are actually various strategies to interpret these bindings - listed below:
>> 
>> * basic intepreted mode; in this mode, all bindings are interpreted using a stack-based machine written in Java (see `BindingInterpreter`), except for the `Move` bindings. For these bindings, the move is implemented by allocating a *buffer* (whose size is ABI specific) and by moving all the lowered values into positions within this buffer. The buffer is then passed to a piece of assembly code inside the VM which takes values from the buffer and moves them in their expected registers/stack slots (note that each position in the buffer corresponds to a different register). This is the most general invocation mode, the more "customizable" one, but also the slowest - since for every call there is some extra allocation which takes place.
>> 
>> * specialized interpreted mode; same as before, but instead of interpreting the bindings with a stack-based interpreter, we generate a method handle chain which effectively interprets all the bindings (again, except `Move` ones).
>> 
>> * intrinsified mode; this is typically used in combination with the specialized interpreted mode described above (although it can also be used with the Java-based binding interpreter). The goal here is to remove the buffer allocation and copy by introducing an additional JVM intrinsic. If a native call recipe is constant (e.g. the set of bindings is constant, which is probably the case if the native method handle is stored in a `static`, `final` field), then the VM can generate specialized assembly code which interprets the `Move` binding without the need to go for an intermediate buffer. This gives us back performances that are on par with JNI.
>> 
>> For upcalls, the support is not (yet) as advanced, and only the basic interpreted mode is available there. We plan to add support for intrinsified modes there as well, which should considerably boost perfomances (probably well beyond what JNI can offer at the moment, since the upcall support in JNI is not very well optimized).
>> 
>> Again, for more readings on the internals of the foreign linker support, please refer to [5].
>> 
>> #### Test changes
>> 
>> Many new tests have been added to validate the foreign linker support; we have high level tests (see `StdLibTest`) which aim at testing the linker from the perspective of code that clients could write. But we also have deeper combinatorial tests (see `TestUpcall` and `TestDowncall`) which are meant to stress every corner of the ABI implementation. There are also some great tests (see the `callarranger` folder) which test the various `CallArranger`s for all the possible platforms; these tests adopt more of a white-box approach - that is, instead of treating the linker machinery as a black box and verify that the support works by checking that the native call returned the results we expected, these tests aims at checking that the set of bindings generated by the call arranger is correct. This also mean that we can test the classification logic for Windows, Mac and Linux regardless of the platform we're executing on.
>> 
>> Some additional microbenchmarks have been added to compare the performances of downcall/upcall with JNI.
>> 
>> [1] - https://openjdk.java.net/jeps/389
>> [2] - https://openjdk.java.net/jeps/393
>> [3] - https://git.openjdk.java.net/jdk/pull/548
>> [4] - https://github.com/openjdk/panama-foreign/blob/foreign-jextract/doc/panama_ffi.md
>> [5] - http://cr.openjdk.java.net/~jvernee/docs/Foreign-abi%20downcall%20intrinsics%20technical%20description.html
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix whitespaces

Changes requested by ihse (Reviewer).

make/modules/java.base/gensrc/GensrcScopedMemoryAccess.gmk line 148:

> 146: 	
> 147: $(DEST): $(BUILD_TOOLS_JDK) $(SCOPED_MEMORY_ACCESS_TEMPLATE) $(SCOPED_MEMORY_ACCESS_BIN_TEMPLATE)
> 148: 	$(MKDIR) -p $(SCOPED_MEMORY_ACCESS_GENSRC_DIR)

Please use `$(call MakeDir, $(SCOPED_MEMORY_ACCESS_GENSRC_DIR))` instead.

make/modules/java.base/gensrc/GensrcScopedMemoryAccess.gmk line 34:

> 32: SCOPED_MEMORY_ACCESS_TEMPLATE := $(SCOPED_MEMORY_ACCESS_SRC_DIR)/X-ScopedMemoryAccess.java.template
> 33: SCOPED_MEMORY_ACCESS_BIN_TEMPLATE := $(SCOPED_MEMORY_ACCESS_SRC_DIR)/X-ScopedMemoryAccess-bin.java.template
> 34: DEST := $(SCOPED_MEMORY_ACCESS_GENSRC_DIR)/ScopedMemoryAccess.java

`DEST` is a very generic and not really informative name. Maybe `SCOPED_MEMORY_ACCESS_GENSRC_DEST` to fit in with the rest of the names?

And/or, maybe, to cut down on the excessive length, shorten `SCOPED_MEMORY_ACCESS` to `SMA` in all variables.

make/modules/java.base/gensrc/GensrcScopedMemoryAccess.gmk line 26:

> 24: #
> 25: 
> 26: GENSRC_SCOPED_MEMORY_ACCESS :=

This variable does not seem to be used. A left-over from previous iterations?

Also, please cut down a bit on the consecutive empty lines.

-------------

PR: https://git.openjdk.java.net/jdk/pull/634

From ihse at openjdk.java.net  Fri Oct 23 11:08:39 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 23 Oct 2020 11:08:39 GMT
Subject: RFR: JDK-8252870: Finalize (remove "incubator" from) jpackage [v4]
In-Reply-To: <D3DS1SNKOqA6gpUZBcxI1EDDnIEaqWRfNTU6zpEI_Ko=.89e21845-916b-43bf-8d48-9112ac8c5942@github.com>
References: <HlksY2mFyKG_kkZA6n6JHHIWBGJT3bjmoLG28c9q1EU=.2b9faa66-08b9-4694-a5db-9d9918039642@github.com>
 <D3DS1SNKOqA6gpUZBcxI1EDDnIEaqWRfNTU6zpEI_Ko=.89e21845-916b-43bf-8d48-9112ac8c5942@github.com>
Message-ID: <9o_mA_y8fQ4M8ylkrTUTckyZX0NO79AZXwvz-7mdZ6Q=.53523a30-482e-433f-9211-17efb165ff72@github.com>

On Wed, 21 Oct 2020 20:05:31 GMT, Andy Herrick <herrick at openjdk.org> wrote:

>> JDK-8252870: Finalize (remove "incubator" from) jpackage
>
> Andy Herrick has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Merge branch master into JDK-8252870
>  - Merge branch 'master' into JDK-8252870
>  - JDK-8252870: Finalize (remove "incubator" from) jpackage
>      - reverting two auto-generated files, and changing module-info to "@since 16"
>  - JDK-8252870: Finalize (remove "incubator" from) jpackage
>    Merge branch 'finalize' into JDK-8252870
>  - 8252869 Finalize (remove incubator from) jpackage (implementation)

Build changes look good.

-------------

Marked as reviewed by ihse (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/633

From shade at openjdk.java.net  Fri Oct 23 12:30:44 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 23 Oct 2020 12:30:44 GMT
Subject: RFR: 8255331: Problemlist java/foreign/TestMismatch.java on 32-bit
 platforms until JDK-8254162
Message-ID: <lUlNsYKk9fdZ5mWeJunYiLK6R2zx-7QbvKB3L3H-HDo=.f3f93e84-86a8-47f3-9540-c4c367c73e1f@github.com>

I would like to have clean x86_32 test runs until JDK-8254162 arrives.

Testing:
  - [x] Affected test on Linux x86_64 (still passes)
  - [x] Affected test on Linux x86_32 (now ignored)

-------------

Commit messages:
 - 8255331: Problemlist java/foreign/TestMismatch.java on 32-bit platforms until JDK-8254162

Changes: https://git.openjdk.java.net/jdk/pull/833/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=833&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8255331
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/833.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/833/head:pull/833

PR: https://git.openjdk.java.net/jdk/pull/833

From sgehwolf at openjdk.java.net  Fri Oct 23 13:36:43 2020
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Fri, 23 Oct 2020 13:36:43 GMT
Subject: RFR: 8253939: [TESTBUG] Increase coverage of the cgroups
 detection code for Java [v2]
In-Reply-To: <4G2YAmtWb3u1gyPsKK9lK5X06dKN93_zCqJvsZmjzxE=.1e754307-4dfa-417b-98e5-3af55a441145@github.com>
References: <4G2YAmtWb3u1gyPsKK9lK5X06dKN93_zCqJvsZmjzxE=.1e754307-4dfa-417b-98e5-3af55a441145@github.com>
Message-ID: <_FwWIYpuGSriKjwb_qnhnA6ScUatrTdSy4j2s2E7ybY=.db63ce7a-65f4-41e6-a107-5419cf0faee3@github.com>

> Test only change. With [JDK-8253435](https://bugs.openjdk.java.net/browse/JDK-8253435) a test has been added on the hotspot side, but nothing for the Java Metrics code. Same for [JDK-8252359](https://bugs.openjdk.java.net/browse/JDK-8252359). This patch alleviates that. 
> 
> Thoughts?

Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:

  8253939: [TESTBUG] Increase coverage of the cgroups detection code for Java

-------------

Changes: https://git.openjdk.java.net/jdk/pull/609/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=609&range=01
  Stats: 40 lines in 1 file changed: 27 ins; 0 del; 13 mod
  Patch: https://git.openjdk.java.net/jdk/pull/609.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/609/head:pull/609

PR: https://git.openjdk.java.net/jdk/pull/609

From mcimadamore at openjdk.java.net  Fri Oct 23 14:09:39 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 23 Oct 2020 14:09:39 GMT
Subject: RFR: 8254231: Implementation of Foreign Linker API (Incubator)
 [v12]
In-Reply-To: <x2n2-rE8gGCiMz0Yrwa6zvUWr2NCPAW-SG1f6H8qFCY=.81609fe6-75dc-4497-bfc0-2b394aed236b@github.com>
References: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
 <2IKx6cpc-IGP3jZtr0s2I14BWM6ptyFD26szPl3b1ng=.9d956b98-dfe6-4a45-a371-bf86923214fb@github.com>
 <x2n2-rE8gGCiMz0Yrwa6zvUWr2NCPAW-SG1f6H8qFCY=.81609fe6-75dc-4497-bfc0-2b394aed236b@github.com>
Message-ID: <ybSizkW2Zm-dcUIZs7e2HpdZeoUeOM303b4dwV9Ij78=.bc88047f-8a05-459f-9add-b37879a8e164@github.com>

On Fri, 23 Oct 2020 11:02:11 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix whitespaces
>
> Changes requested by ihse (Reviewer).

@magicus the files you commented on are not part of this PR, but they are introduced as part of:
https://git.openjdk.java.net/jdk/pull/548
(you seemed to have approved the changes there - but it's also likely that this PR doesn't include the latest changes in that PR). Sorry for the confusion - but please do report any comment you have on the build changes on that PR!

-------------

PR: https://git.openjdk.java.net/jdk/pull/634

From shade at openjdk.java.net  Fri Oct 23 14:15:41 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 23 Oct 2020 14:15:41 GMT
Subject: RFR: 8255343: Problemlist java/util/stream/SpliteratorTest.java on
 32-bit platforms until JDK-8254162
Message-ID: <u2rAhd6_2bIHcD9WO3ga_7BngWJ8PJLhK4hqqxdWh68=.922c46fe-db5b-434b-919b-864011cd8ac5@github.com>

It currently fails on x86_32 with `java.lang.IllegalStateException: Misaligned access at address: 12`. I checked that once JDK-8254162 integrates, that issue is gone. Until then, having clean x86_32 testing is beneficial for other work.

Testing:
 - [x] Affected test on Linux x86_64 (still passes)
 - [x] Affected test on Linux x86_32 (now ignored)

-------------

Commit messages:
 - Try another bug ID: the one that is supposed to fix it
 - 8255343: Problemlist java/util/stream/SpliteratorTest.java on 32-bit platforms until JDK-8254162

Changes: https://git.openjdk.java.net/jdk/pull/836/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=836&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8255343
  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/836.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/836/head:pull/836

PR: https://git.openjdk.java.net/jdk/pull/836

From mcimadamore at openjdk.java.net  Fri Oct 23 14:28:36 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 23 Oct 2020 14:28:36 GMT
Subject: RFR: 8255343: Problemlist java/util/stream/SpliteratorTest.java
 on 32-bit platforms until JDK-8254162
In-Reply-To: <u2rAhd6_2bIHcD9WO3ga_7BngWJ8PJLhK4hqqxdWh68=.922c46fe-db5b-434b-919b-864011cd8ac5@github.com>
References: <u2rAhd6_2bIHcD9WO3ga_7BngWJ8PJLhK4hqqxdWh68=.922c46fe-db5b-434b-919b-864011cd8ac5@github.com>
Message-ID: <wwz1fWF23lbcjEtjJxy2AglhcqnJ-FmwVIoAKcCsfNg=.2132aa84-f642-4d1f-beaa-fb6fa3488c9a@github.com>

On Fri, 23 Oct 2020 12:37:10 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> It currently fails on x86_32 with `java.lang.IllegalStateException: Misaligned access at address: 12`. I checked that once JDK-8254162 integrates, that issue is gone. Until then, having clean x86_32 testing is beneficial for other work.
> 
> Testing:
>  - [x] Affected test on Linux x86_64 (still passes)
>  - [x] Affected test on Linux x86_32 (now ignored)

I'm not sure I get as to why the test fails on 32 bits - in the sense that it does not seem to rely on platform specific assumptions (at least on a quick look). On top of my head I'm not aware of what might have caused this to start working again in JDK-8254162, so maybe some more investigation is required?

At the very least we should only disable the problematic spliterator test, which is, I believe "testSegmentSpliterator" - and leave the other running, which is useful, as this is an important stress test for spliterators.

-------------

PR: https://git.openjdk.java.net/jdk/pull/836

From mcimadamore at openjdk.java.net  Fri Oct 23 14:35:38 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 23 Oct 2020 14:35:38 GMT
Subject: RFR: 8255343: Problemlist java/util/stream/SpliteratorTest.java
 on 32-bit platforms until JDK-8254162
In-Reply-To: <wwz1fWF23lbcjEtjJxy2AglhcqnJ-FmwVIoAKcCsfNg=.2132aa84-f642-4d1f-beaa-fb6fa3488c9a@github.com>
References: <u2rAhd6_2bIHcD9WO3ga_7BngWJ8PJLhK4hqqxdWh68=.922c46fe-db5b-434b-919b-864011cd8ac5@github.com>
 <wwz1fWF23lbcjEtjJxy2AglhcqnJ-FmwVIoAKcCsfNg=.2132aa84-f642-4d1f-beaa-fb6fa3488c9a@github.com>
Message-ID: <tshTJHIO0jYkngZnaffQX66TC8eo6eb5DbsjxA5wbIU=.9d1d4bb9-85f0-4ae5-9bda-b93001d14768@github.com>

On Fri, 23 Oct 2020 14:26:07 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> It currently fails on x86_32 with `java.lang.IllegalStateException: Misaligned access at address: 12`. I checked that once JDK-8254162 integrates, that issue is gone. Until then, having clean x86_32 testing is beneficial for other work.
>> 
>> Testing:
>>  - [x] Affected test on Linux x86_64 (still passes)
>>  - [x] Affected test on Linux x86_32 (now ignored)
>
> I'm not sure I get as to why the test fails on 32 bits - in the sense that it does not seem to rely on platform specific assumptions (at least on a quick look). On top of my head I'm not aware of what might have caused this to start working again in JDK-8254162, so maybe some more investigation is required?
> 
> At the very least we should only disable the problematic spliterator test, which is, I believe "testSegmentSpliterator" - and leave the other running, which is useful, as this is an important stress test for spliterators.

Ok - I understand at least why JDK-8254162 fixed it - JDK-8254162 uses a new API to access memory (MemoryAccess) which disables alignment checks, so that's why the issue doesn't happen. But that means that there could be a latent issue in the test. Looking deeper.

-------------

PR: https://git.openjdk.java.net/jdk/pull/836

From shade at openjdk.java.net  Fri Oct 23 14:48:35 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 23 Oct 2020 14:48:35 GMT
Subject: RFR: 8255343: Problemlist java/util/stream/SpliteratorTest.java
 on 32-bit platforms until JDK-8254162
In-Reply-To: <tshTJHIO0jYkngZnaffQX66TC8eo6eb5DbsjxA5wbIU=.9d1d4bb9-85f0-4ae5-9bda-b93001d14768@github.com>
References: <u2rAhd6_2bIHcD9WO3ga_7BngWJ8PJLhK4hqqxdWh68=.922c46fe-db5b-434b-919b-864011cd8ac5@github.com>
 <wwz1fWF23lbcjEtjJxy2AglhcqnJ-FmwVIoAKcCsfNg=.2132aa84-f642-4d1f-beaa-fb6fa3488c9a@github.com>
 <tshTJHIO0jYkngZnaffQX66TC8eo6eb5DbsjxA5wbIU=.9d1d4bb9-85f0-4ae5-9bda-b93001d14768@github.com>
Message-ID: <KPpgB2OekkI8sS4YKvZlv5YZ0Pg178KgdJ0icQVP0BQ=.51ab8b1c-f967-418e-ab20-1e8fc31d7bd2@github.com>

On Fri, 23 Oct 2020 14:33:11 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> I'm not sure I get as to why the test fails on 32 bits - in the sense that it does not seem to rely on platform specific assumptions (at least on a quick look). On top of my head I'm not aware of what might have caused this to start working again in JDK-8254162, so maybe some more investigation is required?
>> 
>> At the very least we should only disable the problematic spliterator test, which is, I believe "testSegmentSpliterator" - and leave the other running, which is useful, as this is an important stress test for spliterators.
>
> Ok - I understand at least why JDK-8254162 fixed it - JDK-8254162 uses a new API to access memory (MemoryAccess) which disables alignment checks, so that's why the issue doesn't happen. But that means that there could be a latent issue in the test. Looking deeper.

Thing is, I don't think there is a way to problem list the _TestNG_ testcase, is it? There is only a way to problem list the entire jtreg test or its separate `@run` with ID. Which is what the patch does. I would think that `generic-i586` only touches `x86_32`, and thus the test, while disabled there, is still operational on every other platform.

I would love if there is was pointed fix that resolves the actual issue, though.

-------------

PR: https://git.openjdk.java.net/jdk/pull/836

From mcimadamore at openjdk.java.net  Fri Oct 23 14:59:36 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 23 Oct 2020 14:59:36 GMT
Subject: RFR: 8255343: Problemlist java/util/stream/SpliteratorTest.java
 on 32-bit platforms until JDK-8254162
In-Reply-To: <KPpgB2OekkI8sS4YKvZlv5YZ0Pg178KgdJ0icQVP0BQ=.51ab8b1c-f967-418e-ab20-1e8fc31d7bd2@github.com>
References: <u2rAhd6_2bIHcD9WO3ga_7BngWJ8PJLhK4hqqxdWh68=.922c46fe-db5b-434b-919b-864011cd8ac5@github.com>
 <wwz1fWF23lbcjEtjJxy2AglhcqnJ-FmwVIoAKcCsfNg=.2132aa84-f642-4d1f-beaa-fb6fa3488c9a@github.com>
 <tshTJHIO0jYkngZnaffQX66TC8eo6eb5DbsjxA5wbIU=.9d1d4bb9-85f0-4ae5-9bda-b93001d14768@github.com>
 <KPpgB2OekkI8sS4YKvZlv5YZ0Pg178KgdJ0icQVP0BQ=.51ab8b1c-f967-418e-ab20-1e8fc31d7bd2@github.com>
Message-ID: <hoRT0y5o1qM2CVkwSs3cJk9ZOkt_WJyybytTKfAVF1M=.a5c32947-f656-430f-9087-88ae306dc8f1@github.com>

On Fri, 23 Oct 2020 14:45:22 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Ok - I understand at least why JDK-8254162 fixed it - JDK-8254162 uses a new API to access memory (MemoryAccess) which disables alignment checks, so that's why the issue doesn't happen. But that means that there could be a latent issue in the test. Looking deeper.
>
> Thing is, I don't think there is a way to problem list the _TestNG_ testcase, is it? There is only a way to problem list the entire jtreg test or its separate `@run` with ID. Which is what the patch does. I would think that `generic-i586` only touches `x86_32`, and thus the test, while disabled there, is still operational on every other platform.
> 
> I would love if there is was pointed fix that resolves the actual issue, though.

Can you see if this helps?

diff --git a/test/jdk/java/util/stream/test/org/openjdk/tests/java/util/stream/SegmentTestDataProvider.java b/test/jdk/java/util/stream/test/org/openjdk/tests/java/util/stream/SegmentTestDataProvider.java
index 2d2d33d0ab7..c5410865a2b 100644
--- a/test/jdk/java/util/stream/test/org/openjdk/tests/java/util/stream/SegmentTestDataProvider.java
+++ b/test/jdk/java/util/stream/test/org/openjdk/tests/java/util/stream/SegmentTestDataProvider.java
@@ -40,12 +40,12 @@ import org.testng.annotations.DataProvider;
 public class SegmentTestDataProvider {
 
     static VarHandle BYTE_HANDLE = MemoryLayouts.JAVA_BYTE.varHandle(byte.class);
-    static VarHandle CHAR_HANDLE = MemoryLayouts.JAVA_CHAR.varHandle(char.class);
-    static VarHandle SHORT_HANDLE = MemoryLayouts.JAVA_SHORT.varHandle(short.class);
-    static VarHandle INT_HANDLE = MemoryLayouts.JAVA_INT.varHandle(int.class);
-    static VarHandle LONG_HANDLE = MemoryLayouts.JAVA_LONG.varHandle(long.class);
-    static VarHandle FLOAT_HANDLE = MemoryLayouts.JAVA_FLOAT.varHandle(float.class);
-    static VarHandle DOUBLE_HANDLE = MemoryLayouts.JAVA_DOUBLE.varHandle(double.class);
+    static VarHandle CHAR_HANDLE = MemoryLayouts.JAVA_CHAR.withBitAlignment(8).varHandle(char.class);
+    static VarHandle SHORT_HANDLE = MemoryLayouts.JAVA_SHORT.withBitAlignment(8).varHandle(short.class);
+    static VarHandle INT_HANDLE = MemoryLayouts.JAVA_INT.withBitAlignment(8).varHandle(int.class);
+    static VarHandle LONG_HANDLE = MemoryLayouts.JAVA_LONG.withBitAlignment(8).varHandle(long.class);
+    static VarHandle FLOAT_HANDLE = MemoryLayouts.JAVA_FLOAT.withBitAlignment(8).varHandle(float.class);
+    static VarHandle DOUBLE_HANDLE = MemoryLayouts.JAVA_DOUBLE.withBitAlignment(8).varHandle(double.class);
 
     static boolean compareSegmentsByte(Collection<MemorySegment> segments1, Collection<MemorySegment> segments2, boolean isOrdered) {
:
ass);
-    static VarHandle INT_HANDLE = MemoryLayouts.JAVA_INT.varHandle(int.class);
-    static VarHandle LONG_HANDLE = MemoryLayouts.JAVA_LONG.varHandle(long.class);
-    static VarHandle FLOAT_HANDLE = MemoryLayouts.JAVA_FLOAT.varHandle(float.class);
-    static VarHandle DOUBLE_HANDLE = MemoryLayouts.JAVA_DOUBLE.varHandle(double.class);
+    static VarHandle CHAR_HANDLE = MemoryLayouts.JAVA_CHAR.withBitAlignment(8).varHandle(char.class);
+    static VarHandle SHORT_HANDLE = MemoryLayouts.JAVA_SHORT.withBitAlignment(8).varHandle(short.class);
+    static VarHandle INT_HANDLE = MemoryLayouts.JAVA_INT.withBitAlignment(8).varHandle(int.class);
+    static VarHandle LONG_HANDLE = MemoryLayouts.JAVA_LONG.withBitAlignment(8).varHandle(long.class);
+    static VarHandle FLOAT_HANDLE = MemoryLayouts.JAVA_FLOAT.withBitAlignment(8).varHandle(float.class);
+    static VarHandle DOUBLE_HANDLE = MemoryLayouts.JAVA_DOUBLE.withBitAlignment(8).varHandle(double.class);
 
     static boolean compareSegmentsByte(Collection<MemorySegment> segments1, Collection<MemorySegment> segments2, boolean isOrdered) {
         Function<MemorySegment, Byte> mapper = segment -> (byte)BYTE_HANDLE.get(segment.baseAddress());

-------------

PR: https://git.openjdk.java.net/jdk/pull/836

From shade at openjdk.java.net  Fri Oct 23 15:06:34 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 23 Oct 2020 15:06:34 GMT
Subject: RFR: 8255343: Problemlist java/util/stream/SpliteratorTest.java
 on 32-bit platforms until JDK-8254162
In-Reply-To: <hoRT0y5o1qM2CVkwSs3cJk9ZOkt_WJyybytTKfAVF1M=.a5c32947-f656-430f-9087-88ae306dc8f1@github.com>
References: <u2rAhd6_2bIHcD9WO3ga_7BngWJ8PJLhK4hqqxdWh68=.922c46fe-db5b-434b-919b-864011cd8ac5@github.com>
 <wwz1fWF23lbcjEtjJxy2AglhcqnJ-FmwVIoAKcCsfNg=.2132aa84-f642-4d1f-beaa-fb6fa3488c9a@github.com>
 <tshTJHIO0jYkngZnaffQX66TC8eo6eb5DbsjxA5wbIU=.9d1d4bb9-85f0-4ae5-9bda-b93001d14768@github.com>
 <KPpgB2OekkI8sS4YKvZlv5YZ0Pg178KgdJ0icQVP0BQ=.51ab8b1c-f967-418e-ab20-1e8fc31d7bd2@github.com>
 <hoRT0y5o1qM2CVkwSs3cJk9ZOkt_WJyybytTKfAVF1M=.a5c32947-f656-430f-9087-88ae306dc8f1@github.com>
Message-ID: <1VZgUnNPYI6hmCpL8anUKei9ZV7XJnJklpkLrch8-q0=.0a886ec1-d29d-47c7-8cd1-aa7aac31dbde@github.com>

On Fri, 23 Oct 2020 14:57:06 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Thing is, I don't think there is a way to problem list the _TestNG_ testcase, is it? There is only a way to problem list the entire jtreg test or its separate `@run` with ID. Which is what the patch does. I would think that `generic-i586` only touches `x86_32`, and thus the test, while disabled there, is still operational on every other platform.
>> 
>> I would love if there is was pointed fix that resolves the actual issue, though.
>
> Can you see if this helps?
> 
> diff --git a/test/jdk/java/util/stream/test/org/openjdk/tests/java/util/stream/SegmentTestDataProvider.java b/test/jdk/java/util/stream/test/org/openjdk/tests/java/util/stream/SegmentTestDataProvider.java
> index 2d2d33d0ab7..c5410865a2b 100644
> --- a/test/jdk/java/util/stream/test/org/openjdk/tests/java/util/stream/SegmentTestDataProvider.java
> +++ b/test/jdk/java/util/stream/test/org/openjdk/tests/java/util/stream/SegmentTestDataProvider.java
> @@ -40,12 +40,12 @@ import org.testng.annotations.DataProvider;
>  public class SegmentTestDataProvider {
>  
>      static VarHandle BYTE_HANDLE = MemoryLayouts.JAVA_BYTE.varHandle(byte.class);
> -    static VarHandle CHAR_HANDLE = MemoryLayouts.JAVA_CHAR.varHandle(char.class);
> -    static VarHandle SHORT_HANDLE = MemoryLayouts.JAVA_SHORT.varHandle(short.class);
> -    static VarHandle INT_HANDLE = MemoryLayouts.JAVA_INT.varHandle(int.class);
> -    static VarHandle LONG_HANDLE = MemoryLayouts.JAVA_LONG.varHandle(long.class);
> -    static VarHandle FLOAT_HANDLE = MemoryLayouts.JAVA_FLOAT.varHandle(float.class);
> -    static VarHandle DOUBLE_HANDLE = MemoryLayouts.JAVA_DOUBLE.varHandle(double.class);
> +    static VarHandle CHAR_HANDLE = MemoryLayouts.JAVA_CHAR.withBitAlignment(8).varHandle(char.class);
> +    static VarHandle SHORT_HANDLE = MemoryLayouts.JAVA_SHORT.withBitAlignment(8).varHandle(short.class);
> +    static VarHandle INT_HANDLE = MemoryLayouts.JAVA_INT.withBitAlignment(8).varHandle(int.class);
> +    static VarHandle LONG_HANDLE = MemoryLayouts.JAVA_LONG.withBitAlignment(8).varHandle(long.class);
> +    static VarHandle FLOAT_HANDLE = MemoryLayouts.JAVA_FLOAT.withBitAlignment(8).varHandle(float.class);
> +    static VarHandle DOUBLE_HANDLE = MemoryLayouts.JAVA_DOUBLE.withBitAlignment(8).varHandle(double.class);
>  
>      static boolean compareSegmentsByte(Collection<MemorySegment> segments1, Collection<MemorySegment> segments2, boolean isOrdered) {
> :
> ass);
> -    static VarHandle INT_HANDLE = MemoryLayouts.JAVA_INT.varHandle(int.class);
> -    static VarHandle LONG_HANDLE = MemoryLayouts.JAVA_LONG.varHandle(long.class);
> -    static VarHandle FLOAT_HANDLE = MemoryLayouts.JAVA_FLOAT.varHandle(float.class);
> -    static VarHandle DOUBLE_HANDLE = MemoryLayouts.JAVA_DOUBLE.varHandle(double.class);
> +    static VarHandle CHAR_HANDLE = MemoryLayouts.JAVA_CHAR.withBitAlignment(8).varHandle(char.class);
> +    static VarHandle SHORT_HANDLE = MemoryLayouts.JAVA_SHORT.withBitAlignment(8).varHandle(short.class);
> +    static VarHandle INT_HANDLE = MemoryLayouts.JAVA_INT.withBitAlignment(8).varHandle(int.class);
> +    static VarHandle LONG_HANDLE = MemoryLayouts.JAVA_LONG.withBitAlignment(8).varHandle(long.class);
> +    static VarHandle FLOAT_HANDLE = MemoryLayouts.JAVA_FLOAT.withBitAlignment(8).varHandle(float.class);
> +    static VarHandle DOUBLE_HANDLE = MemoryLayouts.JAVA_DOUBLE.withBitAlignment(8).varHandle(double.class);
>  
>      static boolean compareSegmentsByte(Collection<MemorySegment> segments1, Collection<MemorySegment> segments2, boolean isOrdered) {
>          Function<MemorySegment, Byte> mapper = segment -> (byte)BYTE_HANDLE.get(segment.baseAddress());

> Can you see if this helps?
>      static boolean compareSegmentsByte(Collection<MemorySegment> segments1, Collection<MemorySegment> segments2, boolean isOrdered) {
> :
> ass);

I can, but the patch is corrupted near this line. Ah, that seems to be the stray copy of the hunk above.

-------------

PR: https://git.openjdk.java.net/jdk/pull/836

From shade at openjdk.java.net  Fri Oct 23 15:06:34 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 23 Oct 2020 15:06:34 GMT
Subject: RFR: 8255343: Problemlist java/util/stream/SpliteratorTest.java
 on 32-bit platforms until JDK-8254162
In-Reply-To: <1VZgUnNPYI6hmCpL8anUKei9ZV7XJnJklpkLrch8-q0=.0a886ec1-d29d-47c7-8cd1-aa7aac31dbde@github.com>
References: <u2rAhd6_2bIHcD9WO3ga_7BngWJ8PJLhK4hqqxdWh68=.922c46fe-db5b-434b-919b-864011cd8ac5@github.com>
 <wwz1fWF23lbcjEtjJxy2AglhcqnJ-FmwVIoAKcCsfNg=.2132aa84-f642-4d1f-beaa-fb6fa3488c9a@github.com>
 <tshTJHIO0jYkngZnaffQX66TC8eo6eb5DbsjxA5wbIU=.9d1d4bb9-85f0-4ae5-9bda-b93001d14768@github.com>
 <KPpgB2OekkI8sS4YKvZlv5YZ0Pg178KgdJ0icQVP0BQ=.51ab8b1c-f967-418e-ab20-1e8fc31d7bd2@github.com>
 <hoRT0y5o1qM2CVkwSs3cJk9ZOkt_WJyybytTKfAVF1M=.a5c32947-f656-430f-9087-88ae306dc8f1@github.com>
 <1VZgUnNPYI6hmCpL8anUKei9ZV7XJnJklpkLrch8-q0=.0a886ec1-d29d-47c7-8cd1-aa7aac31dbde@github.com>
Message-ID: <8zVMhJIT55UpQ-cY2jRzM1Nf564CFWEh8u_vueUkdBE=.30ed8380-5544-4b95-864a-1b65707a8375@github.com>

On Fri, 23 Oct 2020 15:01:48 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Can you see if this helps?
>> 
>> diff --git a/test/jdk/java/util/stream/test/org/openjdk/tests/java/util/stream/SegmentTestDataProvider.java b/test/jdk/java/util/stream/test/org/openjdk/tests/java/util/stream/SegmentTestDataProvider.java
>> index 2d2d33d0ab7..c5410865a2b 100644
>> --- a/test/jdk/java/util/stream/test/org/openjdk/tests/java/util/stream/SegmentTestDataProvider.java
>> +++ b/test/jdk/java/util/stream/test/org/openjdk/tests/java/util/stream/SegmentTestDataProvider.java
>> @@ -40,12 +40,12 @@ import org.testng.annotations.DataProvider;
>>  public class SegmentTestDataProvider {
>>  
>>      static VarHandle BYTE_HANDLE = MemoryLayouts.JAVA_BYTE.varHandle(byte.class);
>> -    static VarHandle CHAR_HANDLE = MemoryLayouts.JAVA_CHAR.varHandle(char.class);
>> -    static VarHandle SHORT_HANDLE = MemoryLayouts.JAVA_SHORT.varHandle(short.class);
>> -    static VarHandle INT_HANDLE = MemoryLayouts.JAVA_INT.varHandle(int.class);
>> -    static VarHandle LONG_HANDLE = MemoryLayouts.JAVA_LONG.varHandle(long.class);
>> -    static VarHandle FLOAT_HANDLE = MemoryLayouts.JAVA_FLOAT.varHandle(float.class);
>> -    static VarHandle DOUBLE_HANDLE = MemoryLayouts.JAVA_DOUBLE.varHandle(double.class);
>> +    static VarHandle CHAR_HANDLE = MemoryLayouts.JAVA_CHAR.withBitAlignment(8).varHandle(char.class);
>> +    static VarHandle SHORT_HANDLE = MemoryLayouts.JAVA_SHORT.withBitAlignment(8).varHandle(short.class);
>> +    static VarHandle INT_HANDLE = MemoryLayouts.JAVA_INT.withBitAlignment(8).varHandle(int.class);
>> +    static VarHandle LONG_HANDLE = MemoryLayouts.JAVA_LONG.withBitAlignment(8).varHandle(long.class);
>> +    static VarHandle FLOAT_HANDLE = MemoryLayouts.JAVA_FLOAT.withBitAlignment(8).varHandle(float.class);
>> +    static VarHandle DOUBLE_HANDLE = MemoryLayouts.JAVA_DOUBLE.withBitAlignment(8).varHandle(double.class);
>>  
>>      static boolean compareSegmentsByte(Collection<MemorySegment> segments1, Collection<MemorySegment> segments2, boolean isOrdered) {
>> :
>> ass);
>> -    static VarHandle INT_HANDLE = MemoryLayouts.JAVA_INT.varHandle(int.class);
>> -    static VarHandle LONG_HANDLE = MemoryLayouts.JAVA_LONG.varHandle(long.class);
>> -    static VarHandle FLOAT_HANDLE = MemoryLayouts.JAVA_FLOAT.varHandle(float.class);
>> -    static VarHandle DOUBLE_HANDLE = MemoryLayouts.JAVA_DOUBLE.varHandle(double.class);
>> +    static VarHandle CHAR_HANDLE = MemoryLayouts.JAVA_CHAR.withBitAlignment(8).varHandle(char.class);
>> +    static VarHandle SHORT_HANDLE = MemoryLayouts.JAVA_SHORT.withBitAlignment(8).varHandle(short.class);
>> +    static VarHandle INT_HANDLE = MemoryLayouts.JAVA_INT.withBitAlignment(8).varHandle(int.class);
>> +    static VarHandle LONG_HANDLE = MemoryLayouts.JAVA_LONG.withBitAlignment(8).varHandle(long.class);
>> +    static VarHandle FLOAT_HANDLE = MemoryLayouts.JAVA_FLOAT.withBitAlignment(8).varHandle(float.class);
>> +    static VarHandle DOUBLE_HANDLE = MemoryLayouts.JAVA_DOUBLE.withBitAlignment(8).varHandle(double.class);
>>  
>>      static boolean compareSegmentsByte(Collection<MemorySegment> segments1, Collection<MemorySegment> segments2, boolean isOrdered) {
>>          Function<MemorySegment, Byte> mapper = segment -> (byte)BYTE_HANDLE.get(segment.baseAddress());
>
>> Can you see if this helps?
>>      static boolean compareSegmentsByte(Collection<MemorySegment> segments1, Collection<MemorySegment> segments2, boolean isOrdered) {
>> :
>> ass);
> 
> I can, but the patch is corrupted near this line. Ah, that seems to be the stray copy of the hunk above.

Yes, this makes the test pass:

diff --git a/test/jdk/java/util/stream/test/org/openjdk/tests/java/util/stream/SegmentTestDataProvider.java b/test/jdk/java/util/stream/test/org/openjdk/tests/java/util/stream/SegmentTestDataProvider.java
index 2d2d33d0ab7..c5410865a2b 100644
--- a/test/jdk/java/util/stream/test/org/openjdk/tests/java/util/stream/SegmentTestDataProvider.java
+++ b/test/jdk/java/util/stream/test/org/openjdk/tests/java/util/stream/SegmentTestDataProvider.java
@@ -40,12 +40,12 @@ import org.testng.annotations.DataProvider;
 public class SegmentTestDataProvider {
 
     static VarHandle BYTE_HANDLE = MemoryLayouts.JAVA_BYTE.varHandle(byte.class);
-    static VarHandle CHAR_HANDLE = MemoryLayouts.JAVA_CHAR.varHandle(char.class);
-    static VarHandle SHORT_HANDLE = MemoryLayouts.JAVA_SHORT.varHandle(short.class);
-    static VarHandle INT_HANDLE = MemoryLayouts.JAVA_INT.varHandle(int.class);
-    static VarHandle LONG_HANDLE = MemoryLayouts.JAVA_LONG.varHandle(long.class);
-    static VarHandle FLOAT_HANDLE = MemoryLayouts.JAVA_FLOAT.varHandle(float.class);
-    static VarHandle DOUBLE_HANDLE = MemoryLayouts.JAVA_DOUBLE.varHandle(double.class);
+    static VarHandle CHAR_HANDLE = MemoryLayouts.JAVA_CHAR.withBitAlignment(8).varHandle(char.class);
+    static VarHandle SHORT_HANDLE = MemoryLayouts.JAVA_SHORT.withBitAlignment(8).varHandle(short.class);
+    static VarHandle INT_HANDLE = MemoryLayouts.JAVA_INT.withBitAlignment(8).varHandle(int.class);
+    static VarHandle LONG_HANDLE = MemoryLayouts.JAVA_LONG.withBitAlignment(8).varHandle(long.class);
+    static VarHandle FLOAT_HANDLE = MemoryLayouts.JAVA_FLOAT.withBitAlignment(8).varHandle(float.class);
+    static VarHandle DOUBLE_HANDLE = MemoryLayouts.JAVA_DOUBLE.withBitAlignment(8).varHandle(double.class);
 
     static boolean compareSegmentsByte(Collection<MemorySegment> segments1, Collection<MemorySegment> segments2, boolean isOrdered) {
         Function<MemorySegment, Byte> mapper = segment -> (byte)BYTE_HANDLE.get(segment.baseAddress());

I can fix the whole thing thus, without problem listing the test then. Agree?

-------------

PR: https://git.openjdk.java.net/jdk/pull/836

From shade at openjdk.java.net  Fri Oct 23 15:31:46 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 23 Oct 2020 15:31:46 GMT
Subject: RFR: 8255343: java/util/stream/SpliteratorTest.java fails on
 32-bit platforms with "Misaligned access at address: 12" [v2]
In-Reply-To: <u2rAhd6_2bIHcD9WO3ga_7BngWJ8PJLhK4hqqxdWh68=.922c46fe-db5b-434b-919b-864011cd8ac5@github.com>
References: <u2rAhd6_2bIHcD9WO3ga_7BngWJ8PJLhK4hqqxdWh68=.922c46fe-db5b-434b-919b-864011cd8ac5@github.com>
Message-ID: <0c8AmAC1G0FCPNjwHZUDEx8gT22AoHnuqN1j2J2UUlY=.9d0ce330-ade0-4666-b987-ebe194ceba51@github.com>

> It currently fails on x86_32 with `java.lang.IllegalStateException: Misaligned access at address: 12`. I checked that once JDK-8254162 integrates, that issue is gone. Until then, having clean x86_32 testing is beneficial for other work.
> 
> Testing:
>  - [x] Affected test on Linux x86_64 (still passes)
>  - [x] Affected test on Linux x86_32 (now ignored)

Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:

  Fix it instead of problem-listing

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/836/files
  - new: https://git.openjdk.java.net/jdk/pull/836/files/e96135c6..025f9807

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=836&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=836&range=00-01

  Stats: 8 lines in 2 files changed: 0 ins; 2 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/836.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/836/head:pull/836

PR: https://git.openjdk.java.net/jdk/pull/836

From mcimadamore at openjdk.java.net  Fri Oct 23 15:31:47 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 23 Oct 2020 15:31:47 GMT
Subject: RFR: 8255343: java/util/stream/SpliteratorTest.java fails on
 32-bit platforms with "Misaligned access at address: 12"
In-Reply-To: <8zVMhJIT55UpQ-cY2jRzM1Nf564CFWEh8u_vueUkdBE=.30ed8380-5544-4b95-864a-1b65707a8375@github.com>
References: <u2rAhd6_2bIHcD9WO3ga_7BngWJ8PJLhK4hqqxdWh68=.922c46fe-db5b-434b-919b-864011cd8ac5@github.com>
 <wwz1fWF23lbcjEtjJxy2AglhcqnJ-FmwVIoAKcCsfNg=.2132aa84-f642-4d1f-beaa-fb6fa3488c9a@github.com>
 <tshTJHIO0jYkngZnaffQX66TC8eo6eb5DbsjxA5wbIU=.9d1d4bb9-85f0-4ae5-9bda-b93001d14768@github.com>
 <KPpgB2OekkI8sS4YKvZlv5YZ0Pg178KgdJ0icQVP0BQ=.51ab8b1c-f967-418e-ab20-1e8fc31d7bd2@github.com>
 <hoRT0y5o1qM2CVkwSs3cJk9ZOkt_WJyybytTKfAVF1M=.a5c32947-f656-430f-9087-88ae306dc8f1@github.com>
 <1VZgUnNPYI6hmCpL8anUKei9ZV7XJnJklpkLrch8-q0=.0a886ec1-d29d-47c7-8cd1-aa7aac31dbde@github.com>
 <8zVMhJIT55UpQ-cY2jRzM1Nf564CFWEh8u_vueUkdBE=.30ed8380-5544-4b95-864a-1b65707a8375@github.com>
Message-ID: <wmMMPCn_Qm2PcQffY3n71JfFtoqpBRlbutjhwl_x6iY=.451084d1-8f5f-4a9f-9681-8f963fdc952f@github.com>

On Fri, 23 Oct 2020 15:03:55 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I can fix the whole thing thus, without problem listing the test then. Agree?

Yes - another thing worth considering though is: if 32bit alignment is the best we can ask a 32bit VM (e.g. a 32bit VM doesn't really 64-bit align a double[] it seems, from what you are getting), then I think an even better fix would be to just make the constants JAVA_LONG and JAVA_DOUBLE aligned to 32 or 64 depending on the platform (and leave the test unchanged).

-------------

PR: https://git.openjdk.java.net/jdk/pull/836

From shade at openjdk.java.net  Fri Oct 23 15:39:35 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 23 Oct 2020 15:39:35 GMT
Subject: RFR: 8255343: java/util/stream/SpliteratorTest.java fails on
 32-bit platforms with "Misaligned access at address: 12"
In-Reply-To: <wmMMPCn_Qm2PcQffY3n71JfFtoqpBRlbutjhwl_x6iY=.451084d1-8f5f-4a9f-9681-8f963fdc952f@github.com>
References: <u2rAhd6_2bIHcD9WO3ga_7BngWJ8PJLhK4hqqxdWh68=.922c46fe-db5b-434b-919b-864011cd8ac5@github.com>
 <wwz1fWF23lbcjEtjJxy2AglhcqnJ-FmwVIoAKcCsfNg=.2132aa84-f642-4d1f-beaa-fb6fa3488c9a@github.com>
 <tshTJHIO0jYkngZnaffQX66TC8eo6eb5DbsjxA5wbIU=.9d1d4bb9-85f0-4ae5-9bda-b93001d14768@github.com>
 <KPpgB2OekkI8sS4YKvZlv5YZ0Pg178KgdJ0icQVP0BQ=.51ab8b1c-f967-418e-ab20-1e8fc31d7bd2@github.com>
 <hoRT0y5o1qM2CVkwSs3cJk9ZOkt_WJyybytTKfAVF1M=.a5c32947-f656-430f-9087-88ae306dc8f1@github.com>
 <1VZgUnNPYI6hmCpL8anUKei9ZV7XJnJklpkLrch8-q0=.0a886ec1-d29d-47c7-8cd1-aa7aac31dbde@github.com>
 <8zVMhJIT55UpQ-cY2jRzM1Nf564CFWEh8u_vueUkdBE=.30ed8380-5544-4b95-864a-1b65707a8375@github.com>
 <wmMMPCn_Qm2PcQffY3n71JfFtoqpBRlbutjhwl_x6iY=.451084d1-8f5f-4a9f-9681-8f963fdc952f@github.com>
Message-ID: <NfZxRR3UCoIaDt_ATu8EKhVcYdNjkopmER6bbOxQbN4=.49ef16d5-a4d2-48bd-9b8a-8c4b6a14dd0e@github.com>

On Fri, 23 Oct 2020 15:25:47 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Yes - another thing worth considering though is: if 32bit alignment is the best we can ask a 32bit VM (e.g. a 32bit VM doesn't really 64-bit align a double[] it seems, from what you are getting), then I think an even better fix would be to just make the constants JAVA_LONG and JAVA_DOUBLE aligned to 32 or 64 depending on the platform (and leave the test unchanged).

Please see the new revision. It passes `java/util/stream` tests on both `x86_32` and `x86_64`. 

What 32-bit VM is able to do is implementation-dependent, no? I do wonder if long[]/double[] have to be aligned by 8 anyway, since we can do a VarHandle atomic access over its elements, and it is supposed to go correctly. Let's figure that out separately? Filed [JDK-8255350](https://bugs.openjdk.java.net/browse/JDK-8255350).

-------------

PR: https://git.openjdk.java.net/jdk/pull/836

From mcimadamore at openjdk.java.net  Fri Oct 23 15:42:35 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 23 Oct 2020 15:42:35 GMT
Subject: RFR: 8255343: java/util/stream/SpliteratorTest.java fails on
 32-bit platforms with "Misaligned access at address: 12"
In-Reply-To: <NfZxRR3UCoIaDt_ATu8EKhVcYdNjkopmER6bbOxQbN4=.49ef16d5-a4d2-48bd-9b8a-8c4b6a14dd0e@github.com>
References: <u2rAhd6_2bIHcD9WO3ga_7BngWJ8PJLhK4hqqxdWh68=.922c46fe-db5b-434b-919b-864011cd8ac5@github.com>
 <wwz1fWF23lbcjEtjJxy2AglhcqnJ-FmwVIoAKcCsfNg=.2132aa84-f642-4d1f-beaa-fb6fa3488c9a@github.com>
 <tshTJHIO0jYkngZnaffQX66TC8eo6eb5DbsjxA5wbIU=.9d1d4bb9-85f0-4ae5-9bda-b93001d14768@github.com>
 <KPpgB2OekkI8sS4YKvZlv5YZ0Pg178KgdJ0icQVP0BQ=.51ab8b1c-f967-418e-ab20-1e8fc31d7bd2@github.com>
 <hoRT0y5o1qM2CVkwSs3cJk9ZOkt_WJyybytTKfAVF1M=.a5c32947-f656-430f-9087-88ae306dc8f1@github.com>
 <1VZgUnNPYI6hmCpL8anUKei9ZV7XJnJklpkLrch8-q0=.0a886ec1-d29d-47c7-8cd1-aa7aac31dbde@github.com>
 <8zVMhJIT55UpQ-cY2jRzM1Nf564CFWEh8u_vueUkdBE=.30ed8380-5544-4b95-864a-1b65707a8375@github.com>
 <wmMMPCn_Qm2PcQffY3n71JfFtoqpBRlbutjhwl_x6iY=.451084d1-8f5f-4a9f-9681-8f963fdc952f@github.com>
 <NfZxRR3UCoIaDt_ATu8EKhVcYdNjkopmER6bbOxQbN4=.49ef16d5-a4d2-48bd-9b8a-8c4b6a14dd0e@github.com>
Message-ID: <vlF2ZPQG1VfIeFZpHRi5djEUnCq0dB5keDueEMTalUs=.06b143a6-a9ad-41ea-b4c4-e4ee693ac015@github.com>

On Fri, 23 Oct 2020 15:37:03 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>>> I can fix the whole thing thus, without problem listing the test then. Agree?
>> 
>> Yes - another thing worth considering though is: if 32bit alignment is the best we can ask a 32bit VM (e.g. a 32bit VM doesn't really 64-bit align a double[] it seems, from what you are getting), then I think an even better fix would be to just make the constants JAVA_LONG and JAVA_DOUBLE aligned to 32 or 64 depending on the platform (and leave the test unchanged).
>
>> Yes - another thing worth considering though is: if 32bit alignment is the best we can ask a 32bit VM (e.g. a 32bit VM doesn't really 64-bit align a double[] it seems, from what you are getting), then I think an even better fix would be to just make the constants JAVA_LONG and JAVA_DOUBLE aligned to 32 or 64 depending on the platform (and leave the test unchanged).
> 
> Please see the new revision. It passes `java/util/stream` tests on both `x86_32` and `x86_64`. 
> 
> What 32-bit VM is able to do is implementation-dependent, no? I do wonder if long[]/double[] have to be aligned by 8 anyway, since we can do a VarHandle atomic access over its elements, and it is supposed to go correctly. Let's figure that out separately? Filed [JDK-8255350](https://bugs.openjdk.java.net/browse/JDK-8255350).

Looks good to me

-------------

PR: https://git.openjdk.java.net/jdk/pull/836

From sgehwolf at openjdk.java.net  Fri Oct 23 15:51:47 2020
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Fri, 23 Oct 2020 15:51:47 GMT
Subject: RFR: 8253939: [TESTBUG] Increase coverage of the cgroups
 detection code [v3]
In-Reply-To: <4G2YAmtWb3u1gyPsKK9lK5X06dKN93_zCqJvsZmjzxE=.1e754307-4dfa-417b-98e5-3af55a441145@github.com>
References: <4G2YAmtWb3u1gyPsKK9lK5X06dKN93_zCqJvsZmjzxE=.1e754307-4dfa-417b-98e5-3af55a441145@github.com>
Message-ID: <5Jk_4mxRk_8rIaxUY9NhUNhOmjdIuRuV-KWzeSrLkaI=.07c9a141-6335-4e52-8aff-3fcbfce02a17@github.com>

> Test only change. With [JDK-8253435](https://bugs.openjdk.java.net/browse/JDK-8253435) a test has been added on the hotspot side, but nothing for the Java Metrics code. Same for [JDK-8252359](https://bugs.openjdk.java.net/browse/JDK-8252359).
> 
> When JDK-8217766 got fixed cgroup factories with the detection logic didn't exist so were harder to test. This patch adds tests for them too.
> 
> Thoughts?

Severin Gehwolf 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:

  8253939: [TESTBUG] Increase coverage of the cgroups detection code

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/609/files
  - new: https://git.openjdk.java.net/jdk/pull/609/files/a122958f..44362211

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=609&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=609&range=01-02

  Stats: 107 lines in 2 files changed: 107 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/609.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/609/head:pull/609

PR: https://git.openjdk.java.net/jdk/pull/609

From jlahoda at openjdk.java.net  Fri Oct 23 16:17:58 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Fri, 23 Oct 2020 16:17:58 GMT
Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12
 [v3]
In-Reply-To: <RRMAPzh6xcVcxOj2S_VW_r50YvZz-3Imaj46bDi8e9U=.9347534e-d482-468a-8668-132d5516bb76@github.com>
References: <RRMAPzh6xcVcxOj2S_VW_r50YvZz-3Imaj46bDi8e9U=.9347534e-d482-468a-8668-132d5516bb76@github.com>
Message-ID: <8Mdv3fmdDrN4fvcQDIFiq72Z4cgs8Xm9cuHhPUgqj5c=.be071ea4-94b8-4841-bfa8-a432424ba2e6@github.com>

> This is an update to javac and javadoc, to introduce support for Preview APIs, and generally improve javac and javadoc behavior to more closely adhere to JEP 12.
> 
> The notable changes are:
> 
>  * adding support for Preview APIs (javac until now supported primarily only preview language features, and APIs associated with preview language features). This includes:
>      * the @PreviewFeature annotation has boolean attribute "reflective", which should be true for reflective Preview APIs, false otherwise. This replaces the existing "essentialAPI" attribute with roughly inverted meaning.
>      * the preview warnings for preview APIs are auto-suppressed as described in the JEP 12. E.g. the module that declares the preview API is free to use it without warnings
>  * improving error/warning messages. Please see [1] for a list of cases/examples.
>  * class files are only marked as preview if they are using a preview feature. [1] also shows if a class file is marked as preview or not.
>  * the PreviewFeature annotation has been moved to jdk.internal.javac package (originally was in the jdk.internal package).
>  * Preview API in JDK's javadoc no longer needs to specify @preview tag in the source files. javadoc will auto-generate a note for @PreviewFeature elements, see e.g. [2] and [3] (non-reflective and reflective API, respectively). A summary of preview elements is also provided [4]. Existing uses of @preview have been updated/removed.
>  * non-JDK javadoc is also enhanced to auto-generate preview notes for uses of Preview elements, and for declaring elements using preview language features [5].
>  
>  Please also see the CSR [6] for more information.
>  
>  [1] http://cr.openjdk.java.net/~jlahoda/8250768/JEP12-errors-warnings-v6.html
>  [2] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.base/java/lang/Record.html
>  [3] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.compiler/javax/lang/model/element/RecordComponentElement.html
>  [4] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/preview-list.html
>  [5] http://cr.openjdk.java.net/~jlahoda/8250768/test.javadoc.00/
>  [6] https://bugs.openjdk.java.net/browse/JDK-8250769

Jan Lahoda has updated the pull request incrementally with two additional commits since the last revision:

 - Using a more correct way to get URLs.
 - Reflecting review comments.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/703/files
  - new: https://git.openjdk.java.net/jdk/pull/703/files/be1d8651..caa4fd34

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=703&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=703&range=01-02

  Stats: 41 lines in 7 files changed: 5 ins; 14 del; 22 mod
  Patch: https://git.openjdk.java.net/jdk/pull/703.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/703/head:pull/703

PR: https://git.openjdk.java.net/jdk/pull/703

From jlahoda at openjdk.java.net  Fri Oct 23 16:21:53 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Fri, 23 Oct 2020 16:21:53 GMT
Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12
 [v4]
In-Reply-To: <RRMAPzh6xcVcxOj2S_VW_r50YvZz-3Imaj46bDi8e9U=.9347534e-d482-468a-8668-132d5516bb76@github.com>
References: <RRMAPzh6xcVcxOj2S_VW_r50YvZz-3Imaj46bDi8e9U=.9347534e-d482-468a-8668-132d5516bb76@github.com>
Message-ID: <DvuPT_pYUFWOCkxQnkIKxUpLqyBQYSzSDVwrqR7iz4c=.221543e2-f4ee-4e28-b7ee-80aa21a9e3a0@github.com>

> This is an update to javac and javadoc, to introduce support for Preview APIs, and generally improve javac and javadoc behavior to more closely adhere to JEP 12.
> 
> The notable changes are:
> 
>  * adding support for Preview APIs (javac until now supported primarily only preview language features, and APIs associated with preview language features). This includes:
>      * the @PreviewFeature annotation has boolean attribute "reflective", which should be true for reflective Preview APIs, false otherwise. This replaces the existing "essentialAPI" attribute with roughly inverted meaning.
>      * the preview warnings for preview APIs are auto-suppressed as described in the JEP 12. E.g. the module that declares the preview API is free to use it without warnings
>  * improving error/warning messages. Please see [1] for a list of cases/examples.
>  * class files are only marked as preview if they are using a preview feature. [1] also shows if a class file is marked as preview or not.
>  * the PreviewFeature annotation has been moved to jdk.internal.javac package (originally was in the jdk.internal package).
>  * Preview API in JDK's javadoc no longer needs to specify @preview tag in the source files. javadoc will auto-generate a note for @PreviewFeature elements, see e.g. [2] and [3] (non-reflective and reflective API, respectively). A summary of preview elements is also provided [4]. Existing uses of @preview have been updated/removed.
>  * non-JDK javadoc is also enhanced to auto-generate preview notes for uses of Preview elements, and for declaring elements using preview language features [5].
>  
>  Please also see the CSR [6] for more information.
>  
>  [1] http://cr.openjdk.java.net/~jlahoda/8250768/JEP12-errors-warnings-v6.html
>  [2] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.base/java/lang/Record.html
>  [3] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.compiler/javax/lang/model/element/RecordComponentElement.html
>  [4] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/preview-list.html
>  [5] http://cr.openjdk.java.net/~jlahoda/8250768/test.javadoc.00/
>  [6] https://bugs.openjdk.java.net/browse/JDK-8250769

Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:

  Removing unnecessary cast.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/703/files
  - new: https://git.openjdk.java.net/jdk/pull/703/files/caa4fd34..461e7d15

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=703&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=703&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/703.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/703/head:pull/703

PR: https://git.openjdk.java.net/jdk/pull/703

From github.com+11685886+marcono1234 at openjdk.java.net  Fri Oct 23 16:24:44 2020
From: github.com+11685886+marcono1234 at openjdk.java.net (Marcono1234)
Date: Fri, 23 Oct 2020 16:24:44 GMT
Subject: RFR: 8251989: Hex formatting and parsing utility [v8]
In-Reply-To: <lX-d05Nj6nFlHSW_d-xVM0vihr1UQtxcFyCpN282hVo=.8e23858e-f014-4acb-83ed-b1310835b42a@github.com>
References: <HSEn47GMS1K3g57mrTZeQk-WZHl3pKGHpX_OOf8VnsU=.740863c2-f9e4-43c4-b500-614aab4078b1@github.com>
 <lX-d05Nj6nFlHSW_d-xVM0vihr1UQtxcFyCpN282hVo=.8e23858e-f014-4acb-83ed-b1310835b42a@github.com>
Message-ID: <xyk8nbJWRVuI6CJizXM34C9vAvhwKCOStxNHu1mkhQY=.866fa22e-e973-4eab-9e8f-e2c7c20cbe97@github.com>

On Thu, 22 Oct 2020 15:55:30 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> java.util.HexFormat utility:
>> 
>>  - Format and parse hexadecimal strings, with parameters for delimiter, prefix, suffix and upper/lowercase
>>  - Static factories and builder methods to create HexFormat copies with modified parameters.
>>  - Consistent naming of methods for conversion of byte arrays to formatted strings and back: formatHex and parseHex
>>  - Consistent naming of methods for conversion of primitive types: toHexDigits... and fromHexDigits...
>>  - Prefix and suffixes now apply to each formatted value, not the string as a whole
>>  - Using java.util.Appendable as a target for buffered conversions so output to Writers and PrintStreams
>>    like System.out are supported in addition to StringBuilder. (IOExceptions are converted to unchecked exceptions)
>>  - Immutable and thread safe, a "value-based" class
>> 
>> See the [HexFormat javadoc](http://cr.openjdk.java.net/~rriggs/8251989-hex-formatter/java.base/java/util/HexFormat.html) for details.
>> 
>> Review comments and suggestions welcome.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment updates to class javadoc

Do you want to refactor some of the classes where `HexFormat` would be a well-suited replacement for the current code, and what do you think about my other previous review comments (mostly formatting related)?
The bridgekeeper bot was so kind and censored my [previous comment](https://github.com/openjdk/jdk/pull/482#issuecomment-710709003), but apparently it can't handle review comments yet ...

And no, I am not going to sign the [OpenJDK Terms of Use](https://openjdk.java.net/legal/tou/terms) for a simple pull request comment, especially when the Terms of Use document is quite long and contains the following:
> You hereby grant to Oracle and all Users a royalty-free, perpetual, irrevocable, worldwide, non-exclusive and fully sub-licensable right and license under Your intellectual property rights to reproduce, modify, adapt, publish, translate, create derivative works from, distribute, perform, display and use Your Submissions (in whole or part) and to incorporate or implement them in other works in any form, media, or technology now known or later developed. This includes, without limitation, the right to incorporate or implement the Submission into any product or service, and to display, market, sublicense and distribute the Submissions as incorporated or embedded in any product or service distributed or offered by Oracle without compensation to you.

(Might be good to rework that to actually encourage contributions. I am kind of surprised that any company is willing to contribute to the OpenJDK under these terms.)

Sorry for driving this pull request off-topic, I will stop all interaction here and will not bother you any further here if that is desired. Below is the original comment:

-----

It might also be good to clarify in the documentation that `parseHex(...)` is case insensitive. This is currently not obvious and one might expect that it respects `isUpperCase()`.

Additionally there are quite a lot places within the JDK code where this new class could be used. I have picked some where it would definitely be an improvement (but omitted test classes):
<details>
<summary>Classes</summary>
<ul>
<li><a href="https://github.com/openjdk/jdk/blob/83ea863122e1d58527c8bf3cd178acf4d0c54f30/src/java.base/share/classes/java/net/HostPortrange.java#L94"><code>java.base</code> <code>java.net.HostPortrange</code></li>
<li><a href="https://github.com/openjdk/jdk/blob/83ea863122e1d58527c8bf3cd178acf4d0c54f30/src/java.base/share/classes/jdk/internal/module/ModuleHashes.java#L215"><code>java.base</code> <code>jdk.internal.module.ModuleHashes</code></li>
<li><a href="https://github.com/openjdk/jdk/blob/83ea863122e1d58527c8bf3cd178acf4d0c54f30/src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java#L544"><code>java.base</code> <code>sun.net.www.protocol.http.DigestAuthentication</code></li>
<li><a href="https://github.com/openjdk/jdk/blob/83ea863122e1d58527c8bf3cd178acf4d0c54f30/src/java.base/share/classes/sun/security/provider/AbstractDrbg.java#L738"><code>java.base</code> <code>sun.security.provider.AbstractDrbg</code></li>
<li><a href="https://github.com/openjdk/jdk/blob/83ea863122e1d58527c8bf3cd178acf4d0c54f30/src/java.base/share/classes/sun/security/provider/certpath/ResponderId.java#L269"><code>java.base</code> <code>sun.security.provider.certpath.ResponderId</code></li>
<li><a href="https://github.com/openjdk/jdk/blob/83ea863122e1d58527c8bf3cd178acf4d0c54f30/src/java.base/share/classes/sun/security/ssl/Utilities.java#L39"><code>java.base</code> <code>sun.security.ssl.Utilities</code></li>
<li><a href="https://github.com/openjdk/jdk/blob/83ea863122e1d58527c8bf3cd178acf4d0c54f30/src/java.base/share/classes/sun/security/util/Debug.java#L323"><code>java.base</code> <code>sun.security.util.Debug</code></li>
<li><a href="https://github.com/openjdk/jdk/blob/83ea863122e1d58527c8bf3cd178acf4d0c54f30/src/java.base/share/classes/sun/security/util/HexDumpEncoder.java"><code>java.base</code> <code>sun.security.util.HexDumpEncoder</code></li>
<li><a href="https://github.com/openjdk/jdk/blob/83ea863122e1d58527c8bf3cd178acf4d0c54f30/src/java.base/share/classes/sun/security/util/ManifestEntryVerifier.java#L244"><code>java.base</code> <code>sun.security.util.ManifestEntryVerifier</code></li>
<li><a href="https://github.com/openjdk/jdk/blob/83ea863122e1d58527c8bf3cd178acf4d0c54f30/src/java.base/share/classes/sun/security/util/SignatureFileVerifier.java#L753"><code>java.base</code> <code>sun.security.util.SignatureFileVerifier</code></li>
<li><a href="https://github.com/openjdk/jdk/blob/83ea863122e1d58527c8bf3cd178acf4d0c54f30/src/java.base/share/classes/sun/security/x509/AVA.java#L742"><code>java.base</code> <code>sun.security.x509.AVA</code></li>
<li><a href="https://github.com/openjdk/jdk/blob/83ea863122e1d58527c8bf3cd178acf4d0c54f30/src/java.base/share/classes/sun/security/x509/AVA.java#L811"><code>java.base</code> <code>sun.security.x509.AVA</code></li>
<li><a href="https://github.com/openjdk/jdk/blob/83ea863122e1d58527c8bf3cd178acf4d0c54f30/src/java.base/share/classes/sun/security/x509/AVA.java#L889"><code>java.base</code> <code>sun.security.x509.AVA</code></li>
<li><a href="https://github.com/openjdk/jdk/blob/83ea863122e1d58527c8bf3cd178acf4d0c54f30/src/java.base/share/classes/sun/security/x509/AVA.java#L967"><code>java.base</code> <code>sun.security.x509.AVA</code></li>
<li><a href="https://github.com/openjdk/jdk/blob/83ea863122e1d58527c8bf3cd178acf4d0c54f30/src/java.base/share/classes/sun/security/x509/AVA.java#L1111"><code>java.base</code> <code>sun.security.x509.AVA</code></li>
<li><a href="https://github.com/openjdk/jdk/blob/83ea863122e1d58527c8bf3cd178acf4d0c54f30/src/java.base/share/classes/sun/security/x509/X509CertImpl.java#L1982"><code>java.base</code> <code>sun.security.x509.X509CertImpl</code></li>
<li><a href="https://github.com/openjdk/jdk/blob/83ea863122e1d58527c8bf3cd178acf4d0c54f30/src/java.naming/share/classes/com/sun/jndi/ldap/LdapName.java#L837"><code>java.naming</code> <code>com.sun.jndi.ldap.LdapName</code></li>
<li><a href="https://github.com/openjdk/jdk/blob/83ea863122e1d58527c8bf3cd178acf4d0c54f30/src/java.naming/share/classes/javax/naming/ldap/Rdn.java#L568"><code>java.naming</code> <code>javax.naming.ldap.Rdn</code></li>
<li><a href="https://github.com/openjdk/jdk/blob/83ea863122e1d58527c8bf3cd178acf4d0c54f30/src/java.security.jgss/share/classes/sun/security/krb5/KrbApReq.java#L314"><code>java.security.jgss</code> <code>sun.security.krb5.KrbApReq</code></li>
<li><a href="https://github.com/openjdk/jdk/blob/83ea863122e1d58527c8bf3cd178acf4d0c54f30/src/java.security.jgss/share/classes/sun/security/krb5/internal/ktab/KeyTabEntry.java#L80"><code>java.security.jgss</code> <code>sun.security.krb5.internal.ktab.KeyTabEntry</code></li>
<li><a href="https://github.com/openjdk/jdk/blob/83ea863122e1d58527c8bf3cd178acf4d0c54f30/src/java.smartcardio/share/classes/sun/security/smartcardio/PCSC.java#L174"><code>java.smartcardio</code> <code>sun.security.smartcardio.PCSC</code></li>
<li><a href="https://github.com/openjdk/jdk/blob/83ea863122e1d58527c8bf3cd178acf4d0c54f30/src/jdk.compiler/share/classes/com/sun/tools/javac/file/BaseFileManager.java#L355"><code>jdk.compiler</code> <code>com.sun.tools.javac.file.BaseFileManager</code></li>
<li><a href="https://github.com/openjdk/jdk/blob/83ea863122e1d58527c8bf3cd178acf4d0c54f30/src/jdk.compiler/share/classes/com/sun/tools/javac/main/Main.java#L490"><code>jdk.compiler</code> <code>com.sun.tools.javac.main.Main</code></li>
<li><a href="https://github.com/openjdk/jdk/blob/83ea863122e1d58527c8bf3cd178acf4d0c54f30/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Util.java#L158"><code>jdk.crypto.cryptoki</code> <code>sun.security.pkcs11.P11Util</code></li>
<li><a href="https://github.com/openjdk/jdk/blob/83ea863122e1d58527c8bf3cd178acf4d0c54f30/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/Functions.java#L168"><code>jdk.crypto.cryptoki</code> <code>sun.security.pkcs11.wrapper.Functions</code></li>
<li><a href="https://github.com/openjdk/jdk/blob/83ea863122e1d58527c8bf3cd178acf4d0c54f30/src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.java/src/org/graalvm/compiler/java/LambdaUtils.java#L129"><code>jdk.internal.vm.compiler</code> <code>org.graalvm.compiler</code></li>
<li><a href="https://github.com/openjdk/jdk/blob/83ea863122e1d58527c8bf3cd178acf4d0c54f30/src/jdk.jartool/share/classes/sun/tools/jar/Main.java#L2011"><code>jdk.jartool</code> <code>sun.tools.jar.Main</code></li>
<li><a href="https://github.com/openjdk/jdk/blob/83ea863122e1d58527c8bf3cd178acf4d0c54f30/src/jdk.jconsole/share/classes/sun/tools/jconsole/AboutDialog.java#L83"><code>jdk.jconsole</code> <code>sun.tools.jconsole.AboutDialog</code></li>
<li><a href="https://github.com/openjdk/jdk/blob/83ea863122e1d58527c8bf3cd178acf4d0c54f30/src/jdk.jconsole/share/classes/sun/tools/jconsole/ConnectDialog.java#L287"><code>jdk.jconsole</code> <code>sun.tools.jconsole.ConnectDialog</code></li>
<li><a href="https://github.com/openjdk/jdk/blob/83ea863122e1d58527c8bf3cd178acf4d0c54f30/src/jdk.jconsole/share/classes/sun/tools/jconsole/ConnectDialog.java#L595"><code>jdk.jconsole</code> <code>sun.tools.jconsole.ConnectDialog</code></li>
<li><a href="https://github.com/openjdk/jdk/blob/83ea863122e1d58527c8bf3cd178acf4d0c54f30/src/jdk.jconsole/share/classes/sun/tools/jconsole/HTMLPane.java#L61"><code>jdk.jconsole</code> <code>sun.tools.jconsole.HTMLPane</code></li>
<li><a href="https://github.com/openjdk/jdk/blob/83ea863122e1d58527c8bf3cd178acf4d0c54f30/src/jdk.jconsole/share/classes/sun/tools/jconsole/inspector/XArrayDataViewer.java#L79"><code>jdk.jconsole</code> <code>sun.tools.jconsole.inspector.XArrayDataViewer</code></li>
<li><a href="https://github.com/openjdk/jdk/blob/83ea863122e1d58527c8bf3cd178acf4d0c54f30/src/jdk.jdeps/share/classes/com/sun/tools/javap/AttributeWriter.java#L1137"><code>jdk.jdeps</code> <code>com.sun.tools.javap.AttributeWriter</code></li>
<li><a href="https://github.com/openjdk/jdk/blob/83ea863122e1d58527c8bf3cd178acf4d0c54f30/src/jdk.jdeps/share/classes/com/sun/tools/javap/ClassWriter.java#L149"><code>jdk.jdeps</code> <code>com.sun.tools.javap.ClassWriter</code></li>
<li><a href="https://github.com/openjdk/jdk/blob/83ea863122e1d58527c8bf3cd178acf4d0c54f30/src/jdk.jlink/share/classes/jdk/tools/jmod/JmodTask.java#L417"><code>jdk.jlink</code> <code>jdk.tools.jmod.JmodTask</code></li>
</ul>

-------------

PR: https://git.openjdk.java.net/jdk/pull/482

From jlahoda at openjdk.java.net  Fri Oct 23 16:26:39 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Fri, 23 Oct 2020 16:26:39 GMT
Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12
 [v2]
In-Reply-To: <xrcJMq4CEuPF6xHY7m8CTSqbl1b4mPrhhbNra76i5II=.7b266828-c487-4f6f-9d25-9753284e8932@github.com>
References: <RRMAPzh6xcVcxOj2S_VW_r50YvZz-3Imaj46bDi8e9U=.9347534e-d482-468a-8668-132d5516bb76@github.com>
 <LIb9tG4MMzEQmWmOh26MHVMLJWnyWR6NTsBIgWsi0DA=.ee56fde6-defe-4df8-88a9-81b5882f3db0@github.com>
 <xrcJMq4CEuPF6xHY7m8CTSqbl1b4mPrhhbNra76i5II=.7b266828-c487-4f6f-9d25-9753284e8932@github.com>
Message-ID: <6VRynO1yt2p2xY5qSooueo-NLlQ-hD6zWJEkfVOXq94=.b95e79ef-9345-4acf-81cb-e4accbd4ed3c@github.com>

On Wed, 21 Oct 2020 15:25:59 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 35 commits:
>> 
>>  - Merge branch 'JDK-8250768-dev' of https://github.com/lahodaj/jdk into JDK-8250768
>>  - More fixing tests.
>>  - Fixing tests.
>>  - Using unique sections for preview warning sections, as suggested.
>>  - Merge branch 'master' into JDK-8250768
>>  - Reflecting review comments.
>>  - Fixing tests.
>>  - Various cleanup.
>>  - The Preview taglet is not needed anymore.
>>  - There is not jdk.internal package anymore
>>  - ... and 25 more: https://git.openjdk.java.net/jdk/compare/98ec4a67...be1d8651
>
> The javadoc code changes look reasonable, and the preview bits in the generated documentation look good as well. 
> 
> Apart from my inline comments which all address minor issues, there are a few things I don't like around `PreviewListWriter`: its code replication with `DeprecatedListWriter, and it adds things to HtmlDocletWriter and HtmlStyle that I don't think are strictly necessary. However, I wouldn't expect you to know how we like things done in javadoc, so maybe the simplest solution would be for one of us to go over the javadoc bits, either as part of this pull request or (if you prefer to get it integrated rather sooner) as a follow-up task.

I have update the patch based on Hannes' comments. One open question is whether we should have Utils.elementFlags, or just Utils.isPreviewElement. @jonathan-gibbons, any preference? Thanks!

-------------

PR: https://git.openjdk.java.net/jdk/pull/703

From shade at openjdk.java.net  Fri Oct 23 16:36:37 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 23 Oct 2020 16:36:37 GMT
Subject: RFR: 8255343: java/util/stream/SpliteratorTest.java fails on
 32-bit platforms with "Misaligned access at address: 12"
In-Reply-To: <vlF2ZPQG1VfIeFZpHRi5djEUnCq0dB5keDueEMTalUs=.06b143a6-a9ad-41ea-b4c4-e4ee693ac015@github.com>
References: <u2rAhd6_2bIHcD9WO3ga_7BngWJ8PJLhK4hqqxdWh68=.922c46fe-db5b-434b-919b-864011cd8ac5@github.com>
 <wwz1fWF23lbcjEtjJxy2AglhcqnJ-FmwVIoAKcCsfNg=.2132aa84-f642-4d1f-beaa-fb6fa3488c9a@github.com>
 <tshTJHIO0jYkngZnaffQX66TC8eo6eb5DbsjxA5wbIU=.9d1d4bb9-85f0-4ae5-9bda-b93001d14768@github.com>
 <KPpgB2OekkI8sS4YKvZlv5YZ0Pg178KgdJ0icQVP0BQ=.51ab8b1c-f967-418e-ab20-1e8fc31d7bd2@github.com>
 <hoRT0y5o1qM2CVkwSs3cJk9ZOkt_WJyybytTKfAVF1M=.a5c32947-f656-430f-9087-88ae306dc8f1@github.com>
 <1VZgUnNPYI6hmCpL8anUKei9ZV7XJnJklpkLrch8-q0=.0a886ec1-d29d-47c7-8cd1-aa7aac31dbde@github.com>
 <8zVMhJIT55UpQ-cY2jRzM1Nf564CFWEh8u_vueUkdBE=.30ed8380-5544-4b95-864a-1b65707a8375@github.com>
 <wmMMPCn_Qm2PcQffY3n71JfFtoqpBRlbutjhwl_x6iY=.451084d1-8f5f-4a9f-9681-8f963fdc952f@github.com>
 <NfZxRR3UCoIaDt_ATu8EKhVcYdNjkopmER6bbOxQbN4=.49ef16d5-a4d2-48bd-9b8a-8c4b6a14dd0e@github.com>
 <vlF2ZPQG1VfIeFZpHRi5djEUnCq0dB5keDueEMTalUs=.06b143a6-a9ad-41ea-b4c4-e4ee693ac015@github.com>
Message-ID: <rjrl8yXZL9sCaPOJKPa5nUKd7fIGMYh1dGxcVGhTQ4E=.3e0639b9-3d95-486f-a519-40f8363e8e67@github.com>

On Fri, 23 Oct 2020 15:39:41 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>>> Yes - another thing worth considering though is: if 32bit alignment is the best we can ask a 32bit VM (e.g. a 32bit VM doesn't really 64-bit align a double[] it seems, from what you are getting), then I think an even better fix would be to just make the constants JAVA_LONG and JAVA_DOUBLE aligned to 32 or 64 depending on the platform (and leave the test unchanged).
>> 
>> Please see the new revision. It passes `java/util/stream` tests on both `x86_32` and `x86_64`. 
>> 
>> What 32-bit VM is able to do is implementation-dependent, no? I do wonder if long[]/double[] have to be aligned by 8 anyway, since we can do a VarHandle atomic access over its elements, and it is supposed to go correctly. Let's figure that out separately? Filed [JDK-8255350](https://bugs.openjdk.java.net/browse/JDK-8255350).
>
> Looks good to me

> /approve

"Files Changed" on top -> "Review Changes" -> "Approve" :)

-------------

PR: https://git.openjdk.java.net/jdk/pull/836

From rriggs at openjdk.java.net  Fri Oct 23 16:37:43 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 23 Oct 2020 16:37:43 GMT
Subject: RFR: 8251989: Hex formatting and parsing utility [v8]
In-Reply-To: <xyk8nbJWRVuI6CJizXM34C9vAvhwKCOStxNHu1mkhQY=.866fa22e-e973-4eab-9e8f-e2c7c20cbe97@github.com>
References: <HSEn47GMS1K3g57mrTZeQk-WZHl3pKGHpX_OOf8VnsU=.740863c2-f9e4-43c4-b500-614aab4078b1@github.com>
 <lX-d05Nj6nFlHSW_d-xVM0vihr1UQtxcFyCpN282hVo=.8e23858e-f014-4acb-83ed-b1310835b42a@github.com>
 <xyk8nbJWRVuI6CJizXM34C9vAvhwKCOStxNHu1mkhQY=.866fa22e-e973-4eab-9e8f-e2c7c20cbe97@github.com>
Message-ID: <k28XRI-6v9yND_qcB-kyW7uT1Tve9ok2ypzta4Ur08M=.25f3984d-f99d-40fc-b059-73876285991a@github.com>

On Fri, 23 Oct 2020 16:21:29 GMT, Marcono1234 <github.com+11685886+Marcono1234 at openjdk.org> wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comment updates to class javadoc
>
> Do you want to refactor some of the classes where `HexFormat` would be a well-suited replacement for the current code, and what do you think about my other previous review comments (mostly formatting related)?
> The bridgekeeper bot was so kind and censored my [previous comment](https://github.com/openjdk/jdk/pull/482#issuecomment-710709003), but apparently it can't handle review comments yet ...
> 
> And no, I am not going to sign the [OpenJDK Terms of Use](https://openjdk.java.net/legal/tou/terms) for a simple pull request comment, especially when the Terms of Use document is quite long and contains the following:
>> You hereby grant to Oracle and all Users a royalty-free, perpetual, irrevocable, worldwide, non-exclusive and fully sub-licensable right and license under Your intellectual property rights to reproduce, modify, adapt, publish, translate, create derivative works from, distribute, perform, display and use Your Submissions (in whole or part) and to incorporate or implement them in other works in any form, media, or technology now known or later developed. This includes, without limitation, the right to incorporate or implement the Submission into any product or service, and to display, market, sublicense and distribute the Submissions as incorporated or embedded in any product or service distributed or offered by Oracle without compensation to you.
> 
> (Might be good to rework that to actually encourage contributions. I am kind of surprised that any company is willing to contribute to the OpenJDK under these terms.)
> 
> Sorry for driving this pull request off-topic, I will stop all interaction here and will not bother you any further here if that is desired. Below is the original comment:
> 
> -----
> 
> It might also be good to clarify in the documentation that `parseHex(...)` is case insensitive. This is currently not obvious and one might expect that it respects `isUpperCase()`.
> 
> Additionally there are quite a lot places within the JDK code where this new class could be used. I have picked some where it would definitely be an improvement (but omitted test classes):
> <details>
> <summary>Classes</summary>
> <ul>
> <li><a href="https://github.com/openjdk/jdk/blob/83ea863122e1d58527c8bf3cd178acf4d0c54f30/src/java.base/share/classes/java/net/HostPortrange.java#L94"><code>java.base</code> <code>java.net.HostPortrange</code></li>
> <li><a href="https://github.com/openjdk/jdk/blob/83ea863122e1d58527c8bf3cd178acf4d0c54f30/src/java.base/share/classes/jdk/internal/module/ModuleHashes.java#L215"><code>java.base</code> <code>jdk.internal.module.ModuleHashes</code></li>
> <li><a href="https://github.com/openjdk/jdk/blob/83ea863122e1d58527c8bf3cd178acf4d0c54f30/src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java#L544"><code>java.base</code> <code>sun.net.www.protocol.http.DigestAuthentication</code></li>
> <li><a href="https://github.com/openjdk/jdk/blob/83ea863122e1d58527c8bf3cd178acf4d0c54f30/src/java.base/share/classes/sun/security/provider/AbstractDrbg.java#L738"><code>java.base</code> <code>sun.security.provider.AbstractDrbg</code></li>
> <li><a href="https://github.com/openjdk/jdk/blob/83ea863122e1d58527c8bf3cd178acf4d0c54f30/src/java.base/share/classes/sun/security/provider/certpath/ResponderId.java#L269"><code>java.base</code> <code>sun.security.provider.certpath.ResponderId</code></li>
> <li><a href="https://github.com/openjdk/jdk/blob/83ea863122e1d58527c8bf3cd178acf4d0c54f30/src/java.base/share/classes/sun/security/ssl/Utilities.java#L39"><code>java.base</code> <code>sun.security.ssl.Utilities</code></li>
> <li><a href="https://github.com/openjdk/jdk/blob/83ea863122e1d58527c8bf3cd178acf4d0c54f30/src/java.base/share/classes/sun/security/util/Debug.java#L323"><code>java.base</code> <code>sun.security.util.Debug</code></li>
> <li><a href="https://github.com/openjdk/jdk/blob/83ea863122e1d58527c8bf3cd178acf4d0c54f30/src/java.base/share/classes/sun/security/util/HexDumpEncoder.java"><code>java.base</code> <code>sun.security.util.HexDumpEncoder</code></li>
> <li><a href="https://github.com/openjdk/jdk/blob/83ea863122e1d58527c8bf3cd178acf4d0c54f30/src/java.base/share/classes/sun/security/util/ManifestEntryVerifier.java#L244"><code>java.base</code> <code>sun.security.util.ManifestEntryVerifier</code></li>
> <li><a href="https://github.com/openjdk/jdk/blob/83ea863122e1d58527c8bf3cd178acf4d0c54f30/src/java.base/share/classes/sun/security/util/SignatureFileVerifier.java#L753"><code>java.base</code> <code>sun.security.util.SignatureFileVerifier</code></li>
> <li><a href="https://github.com/openjdk/jdk/blob/83ea863122e1d58527c8bf3cd178acf4d0c54f30/src/java.base/share/classes/sun/security/x509/AVA.java#L742"><code>java.base</code> <code>sun.security.x509.AVA</code></li>
> <li><a href="https://github.com/openjdk/jdk/blob/83ea863122e1d58527c8bf3cd178acf4d0c54f30/src/java.base/share/classes/sun/security/x509/AVA.java#L811"><code>java.base</code> <code>sun.security.x509.AVA</code></li>
> <li><a href="https://github.com/openjdk/jdk/blob/83ea863122e1d58527c8bf3cd178acf4d0c54f30/src/java.base/share/classes/sun/security/x509/AVA.java#L889"><code>java.base</code> <code>sun.security.x509.AVA</code></li>
> <li><a href="https://github.com/openjdk/jdk/blob/83ea863122e1d58527c8bf3cd178acf4d0c54f30/src/java.base/share/classes/sun/security/x509/AVA.java#L967"><code>java.base</code> <code>sun.security.x509.AVA</code></li>
> <li><a href="https://github.com/openjdk/jdk/blob/83ea863122e1d58527c8bf3cd178acf4d0c54f30/src/java.base/share/classes/sun/security/x509/AVA.java#L1111"><code>java.base</code> <code>sun.security.x509.AVA</code></li>
> <li><a href="https://github.com/openjdk/jdk/blob/83ea863122e1d58527c8bf3cd178acf4d0c54f30/src/java.base/share/classes/sun/security/x509/X509CertImpl.java#L1982"><code>java.base</code> <code>sun.security.x509.X509CertImpl</code></li>
> <li><a href="https://github.com/openjdk/jdk/blob/83ea863122e1d58527c8bf3cd178acf4d0c54f30/src/java.naming/share/classes/com/sun/jndi/ldap/LdapName.java#L837"><code>java.naming</code> <code>com.sun.jndi.ldap.LdapName</code></li>
> <li><a href="https://github.com/openjdk/jdk/blob/83ea863122e1d58527c8bf3cd178acf4d0c54f30/src/java.naming/share/classes/javax/naming/ldap/Rdn.java#L568"><code>java.naming</code> <code>javax.naming.ldap.Rdn</code></li>
> <li><a href="https://github.com/openjdk/jdk/blob/83ea863122e1d58527c8bf3cd178acf4d0c54f30/src/java.security.jgss/share/classes/sun/security/krb5/KrbApReq.java#L314"><code>java.security.jgss</code> <code>sun.security.krb5.KrbApReq</code></li>
> <li><a href="https://github.com/openjdk/jdk/blob/83ea863122e1d58527c8bf3cd178acf4d0c54f30/src/java.security.jgss/share/classes/sun/security/krb5/internal/ktab/KeyTabEntry.java#L80"><code>java.security.jgss</code> <code>sun.security.krb5.internal.ktab.KeyTabEntry</code></li>
> <li><a href="https://github.com/openjdk/jdk/blob/83ea863122e1d58527c8bf3cd178acf4d0c54f30/src/java.smartcardio/share/classes/sun/security/smartcardio/PCSC.java#L174"><code>java.smartcardio</code> <code>sun.security.smartcardio.PCSC</code></li>
> <li><a href="https://github.com/openjdk/jdk/blob/83ea863122e1d58527c8bf3cd178acf4d0c54f30/src/jdk.compiler/share/classes/com/sun/tools/javac/file/BaseFileManager.java#L355"><code>jdk.compiler</code> <code>com.sun.tools.javac.file.BaseFileManager</code></li>
> <li><a href="https://github.com/openjdk/jdk/blob/83ea863122e1d58527c8bf3cd178acf4d0c54f30/src/jdk.compiler/share/classes/com/sun/tools/javac/main/Main.java#L490"><code>jdk.compiler</code> <code>com.sun.tools.javac.main.Main</code></li>
> <li><a href="https://github.com/openjdk/jdk/blob/83ea863122e1d58527c8bf3cd178acf4d0c54f30/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Util.java#L158"><code>jdk.crypto.cryptoki</code> <code>sun.security.pkcs11.P11Util</code></li>
> <li><a href="https://github.com/openjdk/jdk/blob/83ea863122e1d58527c8bf3cd178acf4d0c54f30/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/Functions.java#L168"><code>jdk.crypto.cryptoki</code> <code>sun.security.pkcs11.wrapper.Functions</code></li>
> <li><a href="https://github.com/openjdk/jdk/blob/83ea863122e1d58527c8bf3cd178acf4d0c54f30/src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.java/src/org/graalvm/compiler/java/LambdaUtils.java#L129"><code>jdk.internal.vm.compiler</code> <code>org.graalvm.compiler</code></li>
> <li><a href="https://github.com/openjdk/jdk/blob/83ea863122e1d58527c8bf3cd178acf4d0c54f30/src/jdk.jartool/share/classes/sun/tools/jar/Main.java#L2011"><code>jdk.jartool</code> <code>sun.tools.jar.Main</code></li>
> <li><a href="https://github.com/openjdk/jdk/blob/83ea863122e1d58527c8bf3cd178acf4d0c54f30/src/jdk.jconsole/share/classes/sun/tools/jconsole/AboutDialog.java#L83"><code>jdk.jconsole</code> <code>sun.tools.jconsole.AboutDialog</code></li>
> <li><a href="https://github.com/openjdk/jdk/blob/83ea863122e1d58527c8bf3cd178acf4d0c54f30/src/jdk.jconsole/share/classes/sun/tools/jconsole/ConnectDialog.java#L287"><code>jdk.jconsole</code> <code>sun.tools.jconsole.ConnectDialog</code></li>
> <li><a href="https://github.com/openjdk/jdk/blob/83ea863122e1d58527c8bf3cd178acf4d0c54f30/src/jdk.jconsole/share/classes/sun/tools/jconsole/ConnectDialog.java#L595"><code>jdk.jconsole</code> <code>sun.tools.jconsole.ConnectDialog</code></li>
> <li><a href="https://github.com/openjdk/jdk/blob/83ea863122e1d58527c8bf3cd178acf4d0c54f30/src/jdk.jconsole/share/classes/sun/tools/jconsole/HTMLPane.java#L61"><code>jdk.jconsole</code> <code>sun.tools.jconsole.HTMLPane</code></li>
> <li><a href="https://github.com/openjdk/jdk/blob/83ea863122e1d58527c8bf3cd178acf4d0c54f30/src/jdk.jconsole/share/classes/sun/tools/jconsole/inspector/XArrayDataViewer.java#L79"><code>jdk.jconsole</code> <code>sun.tools.jconsole.inspector.XArrayDataViewer</code></li>
> <li><a href="https://github.com/openjdk/jdk/blob/83ea863122e1d58527c8bf3cd178acf4d0c54f30/src/jdk.jdeps/share/classes/com/sun/tools/javap/AttributeWriter.java#L1137"><code>jdk.jdeps</code> <code>com.sun.tools.javap.AttributeWriter</code></li>
> <li><a href="https://github.com/openjdk/jdk/blob/83ea863122e1d58527c8bf3cd178acf4d0c54f30/src/jdk.jdeps/share/classes/com/sun/tools/javap/ClassWriter.java#L149"><code>jdk.jdeps</code> <code>com.sun.tools.javap.ClassWriter</code></li>
> <li><a href="https://github.com/openjdk/jdk/blob/83ea863122e1d58527c8bf3cd178acf4d0c54f30/src/jdk.jlink/share/classes/jdk/tools/jmod/JmodTask.java#L417"><code>jdk.jlink</code> <code>jdk.tools.jmod.JmodTask</code></li>
> </ul>

Hi,

The adoption of the HexFormat API by other JDK classes is a separate task.
In the security area, a pre-Git webrev included the changes, when the 
API settles
that will come back to the fore.? In many of the security tests, it may 
be better to
utilize the test library addition that can format ASN.1/DER streams to 
make the output easier to read.

The point about case insensitive parsing can be reinforced.

Regards, Roger

-------------

PR: https://git.openjdk.java.net/jdk/pull/482

From mcimadamore at openjdk.java.net  Fri Oct 23 16:42:39 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 23 Oct 2020 16:42:39 GMT
Subject: RFR: 8255343: java/util/stream/SpliteratorTest.java fails on
 32-bit platforms with "Misaligned access at address: 12" [v2]
In-Reply-To: <0c8AmAC1G0FCPNjwHZUDEx8gT22AoHnuqN1j2J2UUlY=.9d0ce330-ade0-4666-b987-ebe194ceba51@github.com>
References: <u2rAhd6_2bIHcD9WO3ga_7BngWJ8PJLhK4hqqxdWh68=.922c46fe-db5b-434b-919b-864011cd8ac5@github.com>
 <0c8AmAC1G0FCPNjwHZUDEx8gT22AoHnuqN1j2J2UUlY=.9d0ce330-ade0-4666-b987-ebe194ceba51@github.com>
Message-ID: <9-bvUyzsd3qsOSGbnBxfIwUTTcyFIdc89yVIs2WIoaw=.2e70c4d7-36b1-48b2-88e6-8dc4e235b734@github.com>

On Fri, 23 Oct 2020 15:31:46 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> It currently fails on x86_32 with `java.lang.IllegalStateException: Misaligned access at address: 12`. I checked that once JDK-8254162 integrates, that issue is gone. Until then, having clean x86_32 testing is beneficial for other work.
>> 
>> Testing:
>>  - [x] `java/util/stream` tests on Linux x86_64 (still passes)
>>  - [x] `java/util/stream` tests on Linux x86_32 (start to pass)
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix it instead of problem-listing

Looks good

-------------

Marked as reviewed by mcimadamore (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/836

From mcimadamore at openjdk.java.net  Fri Oct 23 16:42:39 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 23 Oct 2020 16:42:39 GMT
Subject: RFR: 8255343: java/util/stream/SpliteratorTest.java fails on
 32-bit platforms with "Misaligned access at address: 12" [v2]
In-Reply-To: <9-bvUyzsd3qsOSGbnBxfIwUTTcyFIdc89yVIs2WIoaw=.2e70c4d7-36b1-48b2-88e6-8dc4e235b734@github.com>
References: <u2rAhd6_2bIHcD9WO3ga_7BngWJ8PJLhK4hqqxdWh68=.922c46fe-db5b-434b-919b-864011cd8ac5@github.com>
 <0c8AmAC1G0FCPNjwHZUDEx8gT22AoHnuqN1j2J2UUlY=.9d0ce330-ade0-4666-b987-ebe194ceba51@github.com>
 <9-bvUyzsd3qsOSGbnBxfIwUTTcyFIdc89yVIs2WIoaw=.2e70c4d7-36b1-48b2-88e6-8dc4e235b734@github.com>
Message-ID: <SX6u5thdNnuGGkuRhGXJNmRgezXzaMS5fRxMJOX8P9o=.dd3d6d83-adce-4bb6-801a-360ba7637d96@github.com>

On Fri, 23 Oct 2020 16:39:57 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix it instead of problem-listing
>
> Looks good

> > /approve
> 
> "Files Changed" on top -> "Review Changes" -> "Approve" :)

I must be going mad :-)

-------------

PR: https://git.openjdk.java.net/jdk/pull/836

From herrick at openjdk.java.net  Fri Oct 23 16:46:38 2020
From: herrick at openjdk.java.net (Andy Herrick)
Date: Fri, 23 Oct 2020 16:46:38 GMT
Subject: RFR: 8232024: Don't pollute log output with multiple errors of
 the same type
In-Reply-To: <fSuDEsw79XKdiuGVdVUS8LOVX0tPdqLAjyKstTOi1xE=.471b5e5a-98b7-4bfc-a284-5adc0dc702a3@github.com>
References: <fSuDEsw79XKdiuGVdVUS8LOVX0tPdqLAjyKstTOi1xE=.471b5e5a-98b7-4bfc-a284-5adc0dc702a3@github.com>
Message-ID: <1N0YKg1Ezrm6DAthfqBZGkqb37ix-RZxeBshnuKqeNU=.f965c19e-c758-4516-8303-45e79acd1bb0@github.com>

On Wed, 21 Oct 2020 17:03:33 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Don't run ldd and build list of dependency packages in case jpackage builds DEB package on non Debian Linux and RPM on Debian Linux. In this cases attempts to detect what packages provide libs will fail anyways, so don't waste time and pollute jpackage log output.

Marked as reviewed by herrick (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/784

From jjg at openjdk.java.net  Fri Oct 23 17:05:40 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Fri, 23 Oct 2020 17:05:40 GMT
Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12
 [v2]
In-Reply-To: <xrcJMq4CEuPF6xHY7m8CTSqbl1b4mPrhhbNra76i5II=.7b266828-c487-4f6f-9d25-9753284e8932@github.com>
References: <RRMAPzh6xcVcxOj2S_VW_r50YvZz-3Imaj46bDi8e9U=.9347534e-d482-468a-8668-132d5516bb76@github.com>
 <LIb9tG4MMzEQmWmOh26MHVMLJWnyWR6NTsBIgWsi0DA=.ee56fde6-defe-4df8-88a9-81b5882f3db0@github.com>
 <xrcJMq4CEuPF6xHY7m8CTSqbl1b4mPrhhbNra76i5II=.7b266828-c487-4f6f-9d25-9753284e8932@github.com>
Message-ID: <SS1hbUR9jpY_VD7TbmC8mlECAgecfJWonA6xcGLMc_M=.8eec60af-71f1-478a-adf9-baa0a112e30f@github.com>

On Wed, 21 Oct 2020 12:43:51 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 35 commits:
>> 
>>  - Merge branch 'JDK-8250768-dev' of https://github.com/lahodaj/jdk into JDK-8250768
>>  - More fixing tests.
>>  - Fixing tests.
>>  - Using unique sections for preview warning sections, as suggested.
>>  - Merge branch 'master' into JDK-8250768
>>  - Reflecting review comments.
>>  - Fixing tests.
>>  - Various cleanup.
>>  - The Preview taglet is not needed anymore.
>>  - There is not jdk.internal package anymore
>>  - ... and 25 more: https://git.openjdk.java.net/jdk/compare/98ec4a67...be1d8651
>
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java line 3164:
> 
>> 3162:     }
>> 3163: 
>> 3164:     public Set<ElementFlag> elementFlags(Element el) {
> 
> It seems like the sole use of this method and the `ElementFlag` enum below is to determine whether a preview warning note should be generated for an element. Is there something that speaks against simplifying it to reflect that purpose, e.g. change its name to `hasPreviewNote` or `hasPreviewContent` and change the return type to `boolean`?  Of course that's unless you foresee adding more `ElementFlag` values in the future.

There's a number of predicates on an element that the doclet might be interested in that could be cached/reified as "flags". Today, we have "preview" and "deprecated" that have similar handling; there have been discussions about handling native methods in a similar fashion.

-------------

PR: https://git.openjdk.java.net/jdk/pull/703

From naoto at openjdk.java.net  Fri Oct 23 17:25:47 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 23 Oct 2020 17:25:47 GMT
Subject: RFR: 8255242: Bidi.requiresBidi has misleading exception message
Message-ID: <kWuUHntyhKCkveE28ApQtbYHnSYDHnB08E8vQ-8xmWM=.c0ff3e04-39cb-478f-88ad-27f282a43c5f@github.com>

Hi,

Please review this small exception message fix.

Naoto

-------------

Commit messages:
 - 8255242: Bidi.requiresBidi has misleading exception message

Changes: https://git.openjdk.java.net/jdk/pull/841/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=841&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8255242
  Stats: 10 lines in 2 files changed: 7 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/841.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/841/head:pull/841

PR: https://git.openjdk.java.net/jdk/pull/841

From bchristi at openjdk.java.net  Fri Oct 23 17:40:36 2020
From: bchristi at openjdk.java.net (Brent Christian)
Date: Fri, 23 Oct 2020 17:40:36 GMT
Subject: RFR: 8255242: Bidi.requiresBidi has misleading exception message
In-Reply-To: <kWuUHntyhKCkveE28ApQtbYHnSYDHnB08E8vQ-8xmWM=.c0ff3e04-39cb-478f-88ad-27f282a43c5f@github.com>
References: <kWuUHntyhKCkveE28ApQtbYHnSYDHnB08E8vQ-8xmWM=.c0ff3e04-39cb-478f-88ad-27f282a43c5f@github.com>
Message-ID: <x9l4sS2Zw8HASGrOw58fYHTCXCRz9ydTg3-IiUrGGa8=.1aca4336-6700-43c7-8f39-39002fcda112@github.com>

On Fri, 23 Oct 2020 16:48:03 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Hi,
> 
> Please review this small exception message fix.
> 
> Naoto

Looks good.

-------------

Marked as reviewed by bchristi (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/841

From jvernee at openjdk.java.net  Fri Oct 23 17:55:52 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Fri, 23 Oct 2020 17:55:52 GMT
Subject: RFR: 8254354: Add an asExact() VarHandle combinator
Message-ID: <gJ1pTeZZC7tbtwiRsrHcZ1ydfTQhr1MPndGrnGolf14=.dd935929-4f22-4e41-9e0d-99a592ac46b7@github.com>

Hi,

This patch adds an asExact() combinator to VarHandle, that will return a new VarHandle that performs exact type checks, similar to MethodHandle::invokeExact, to help developers catch inexact VarHandle usage, which can lead to performance degradation.

This is implemented using a boolean flag in VarForm. If the flag is set, the exact type of the invocation is checked against the exact type in the VarForm. If there is a mismatch, a WrongMethodTypeException is thrown.

Thanks,
Jorn

-------------

Commit messages:
 - Add an asExact() combinator to VarHandle

Changes: https://git.openjdk.java.net/jdk/pull/843/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=843&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8254354
  Stats: 1339 lines in 10 files changed: 962 ins; 64 del; 313 mod
  Patch: https://git.openjdk.java.net/jdk/pull/843.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/843/head:pull/843

PR: https://git.openjdk.java.net/jdk/pull/843

From jvernee at openjdk.java.net  Fri Oct 23 18:06:51 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Fri, 23 Oct 2020 18:06:51 GMT
Subject: RFR: 8254354: Add an asExact() VarHandle combinator [v2]
In-Reply-To: <gJ1pTeZZC7tbtwiRsrHcZ1ydfTQhr1MPndGrnGolf14=.dd935929-4f22-4e41-9e0d-99a592ac46b7@github.com>
References: <gJ1pTeZZC7tbtwiRsrHcZ1ydfTQhr1MPndGrnGolf14=.dd935929-4f22-4e41-9e0d-99a592ac46b7@github.com>
Message-ID: <Mo3T9JJzO03q-I_q8NhsGpu2TVaJg_104ESGWqLhYRg=.7d353318-6827-4708-b973-a9c30558c3ed@github.com>

> Hi,
> 
> This patch adds an asExact() combinator to VarHandle, that will return a new VarHandle that performs exact type checks, similar to MethodHandle::invokeExact, to help developers catch inexact VarHandle usage, which can lead to performance degradation.
> 
> This is implemented using a boolean flag in VarForm. If the flag is set, the exact type of the invocation is checked against the exact type in the VarForm. If there is a mismatch, a WrongMethodTypeException is thrown.
> 
> Thanks,
> Jorn

Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

  Make internalName helper method static

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/843/files
  - new: https://git.openjdk.java.net/jdk/pull/843/files/65c5d145..dc1f9ecf

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=843&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=843&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/843.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/843/head:pull/843

PR: https://git.openjdk.java.net/jdk/pull/843

From github.com+828220+forax at openjdk.java.net  Fri Oct 23 18:06:52 2020
From: github.com+828220+forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Fri, 23 Oct 2020 18:06:52 GMT
Subject: RFR: 8254354: Add an asExact() VarHandle combinator [v2]
In-Reply-To: <Mo3T9JJzO03q-I_q8NhsGpu2TVaJg_104ESGWqLhYRg=.7d353318-6827-4708-b973-a9c30558c3ed@github.com>
References: <gJ1pTeZZC7tbtwiRsrHcZ1ydfTQhr1MPndGrnGolf14=.dd935929-4f22-4e41-9e0d-99a592ac46b7@github.com>
 <Mo3T9JJzO03q-I_q8NhsGpu2TVaJg_104ESGWqLhYRg=.7d353318-6827-4708-b973-a9c30558c3ed@github.com>
Message-ID: <KxqOzrHKSVtC2juSrUcH2Z2mp6wfrEzsBYtyEp9oW5E=.5dabbb7c-85bb-4454-9db1-55001eea4462@github.com>

On Fri, 23 Oct 2020 18:04:11 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Hi,
>> 
>> This patch adds an asExact() combinator to VarHandle, that will return a new VarHandle that performs exact type checks, similar to MethodHandle::invokeExact, to help developers catch inexact VarHandle usage, which can lead to performance degradation.
>> 
>> This is implemented using a boolean flag in VarForm. If the flag is set, the exact type of the invocation is checked against the exact type in the VarForm. If there is a mismatch, a WrongMethodTypeException is thrown.
>> 
>> Thanks,
>> Jorn
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make internalName helper method static

src/java.base/share/classes/java/lang/invoke/MemoryAccessVarHandleGenerator.java line 450:

> 448:     }
> 449: 
> 450:     private String internalName(Class<?> cls) {

should be static, no ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/843

From jvernee at openjdk.java.net  Fri Oct 23 18:06:53 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Fri, 23 Oct 2020 18:06:53 GMT
Subject: RFR: 8254354: Add an asExact() VarHandle combinator [v2]
In-Reply-To: <KxqOzrHKSVtC2juSrUcH2Z2mp6wfrEzsBYtyEp9oW5E=.5dabbb7c-85bb-4454-9db1-55001eea4462@github.com>
References: <gJ1pTeZZC7tbtwiRsrHcZ1ydfTQhr1MPndGrnGolf14=.dd935929-4f22-4e41-9e0d-99a592ac46b7@github.com>
 <Mo3T9JJzO03q-I_q8NhsGpu2TVaJg_104ESGWqLhYRg=.7d353318-6827-4708-b973-a9c30558c3ed@github.com>
 <KxqOzrHKSVtC2juSrUcH2Z2mp6wfrEzsBYtyEp9oW5E=.5dabbb7c-85bb-4454-9db1-55001eea4462@github.com>
Message-ID: <6bkQ9zAqDQ6llLBFVWcQYUjOZWtWVe7hA9L3YuVr9Ko=.7c936ac5-49dc-43d8-bd64-bc9d0fc07250@github.com>

On Fri, 23 Oct 2020 18:02:11 GMT, R?mi Forax <github.com+828220+forax at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Make internalName helper method static
>
> src/java.base/share/classes/java/lang/invoke/MemoryAccessVarHandleGenerator.java line 450:
> 
>> 448:     }
>> 449: 
>> 450:     private String internalName(Class<?> cls) {
> 
> should be static, no ?

Yes, thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/843

From dfuchs at openjdk.java.net  Fri Oct 23 18:33:35 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 23 Oct 2020 18:33:35 GMT
Subject: RFR: 8255299: Drop explicit zeroing at instantiation of Atomic*
 objects
In-Reply-To: <JbMPcYdgEa-E-congqKtykPOp2tbK5NT5cN9NwPzdKY=.92bcae3c-6514-48cb-b102-551c7a798e6f@github.com>
References: <Bc1YybkJpxM06gYYRRaXsWlYOgf0iDwdw6MyPCiOUuY=.76053af0-dccd-4b14-8729-193daa70b091@github.com>
 <U2xyKaDQS32Nm02PpBj391aGVSN-VZ9yACXbePoyY_Y=.765caedb-3ac3-4991-8b97-1637811edbf1@github.com>
 <JbMPcYdgEa-E-congqKtykPOp2tbK5NT5cN9NwPzdKY=.92bcae3c-6514-48cb-b102-551c7a798e6f@github.com>
Message-ID: <N9NqqIta7gLw_c3VJ5vHhLnHsWRf3eD13DOqSmBdzbE=.62e9a338-5d19-45c2-bf2d-c0b106275340@github.com>

On Fri, 23 Oct 2020 09:14:48 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> The changes in src/java.desktop looks fine.
>
> Changes to `java.logging` and `java.net.http` also look good to me.

Hi Sergey,

I'll give it some testing and sponsor it next week unless someone else steps up.

best regards,
-- daniel

-------------

PR: https://git.openjdk.java.net/jdk/pull/818

From asemenyuk at openjdk.java.net  Fri Oct 23 18:41:36 2020
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Fri, 23 Oct 2020 18:41:36 GMT
Subject: Integrated: 8232024: Don't pollute log output with multiple errors of
 the same type
In-Reply-To: <fSuDEsw79XKdiuGVdVUS8LOVX0tPdqLAjyKstTOi1xE=.471b5e5a-98b7-4bfc-a284-5adc0dc702a3@github.com>
References: <fSuDEsw79XKdiuGVdVUS8LOVX0tPdqLAjyKstTOi1xE=.471b5e5a-98b7-4bfc-a284-5adc0dc702a3@github.com>
Message-ID: <-28A9XD_YaVmfH1tpiWx0KI8jCkqzSFgvslgpSupWZQ=.dc0d04f0-d598-40c5-b57f-c5d52c30ef98@github.com>

On Wed, 21 Oct 2020 17:03:33 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Don't run ldd and build list of dependency packages in case jpackage builds DEB package on non Debian Linux and RPM on Debian Linux. In this cases attempts to detect what packages provide libs will fail anyways, so don't waste time and pollute jpackage log output.

This pull request has now been integrated.

Changeset: cf821b0b
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/cf821b0b
Stats:     32 lines in 4 files changed: 17 ins; 8 del; 7 mod

8232024: Don't pollute log output with multiple errors of the same type

Reviewed-by: almatvee, herrick

-------------

PR: https://git.openjdk.java.net/jdk/pull/784

From jjg at openjdk.java.net  Fri Oct 23 18:46:49 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Fri, 23 Oct 2020 18:46:49 GMT
Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12
 [v4]
In-Reply-To: <DvuPT_pYUFWOCkxQnkIKxUpLqyBQYSzSDVwrqR7iz4c=.221543e2-f4ee-4e28-b7ee-80aa21a9e3a0@github.com>
References: <RRMAPzh6xcVcxOj2S_VW_r50YvZz-3Imaj46bDi8e9U=.9347534e-d482-468a-8668-132d5516bb76@github.com>
 <DvuPT_pYUFWOCkxQnkIKxUpLqyBQYSzSDVwrqR7iz4c=.221543e2-f4ee-4e28-b7ee-80aa21a9e3a0@github.com>
Message-ID: <P6CERo1De3tix7TduT-Eh184-uAfYegth-i3neTAV1Y=.46960ac4-d027-4d59-a0b6-664819d1635f@github.com>

On Fri, 23 Oct 2020 16:21:53 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is an update to javac and javadoc, to introduce support for Preview APIs, and generally improve javac and javadoc behavior to more closely adhere to JEP 12.
>> 
>> The notable changes are:
>> 
>>  * adding support for Preview APIs (javac until now supported primarily only preview language features, and APIs associated with preview language features). This includes:
>>      * the @PreviewFeature annotation has boolean attribute "reflective", which should be true for reflective Preview APIs, false otherwise. This replaces the existing "essentialAPI" attribute with roughly inverted meaning.
>>      * the preview warnings for preview APIs are auto-suppressed as described in the JEP 12. E.g. the module that declares the preview API is free to use it without warnings
>>  * improving error/warning messages. Please see [1] for a list of cases/examples.
>>  * class files are only marked as preview if they are using a preview feature. [1] also shows if a class file is marked as preview or not.
>>  * the PreviewFeature annotation has been moved to jdk.internal.javac package (originally was in the jdk.internal package).
>>  * Preview API in JDK's javadoc no longer needs to specify @preview tag in the source files. javadoc will auto-generate a note for @PreviewFeature elements, see e.g. [2] and [3] (non-reflective and reflective API, respectively). A summary of preview elements is also provided [4]. Existing uses of @preview have been updated/removed.
>>  * non-JDK javadoc is also enhanced to auto-generate preview notes for uses of Preview elements, and for declaring elements using preview language features [5].
>>  
>>  Please also see the CSR [6] for more information.
>>  
>>  [1] http://cr.openjdk.java.net/~jlahoda/8250768/JEP12-errors-warnings-v6.html
>>  [2] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.base/java/lang/Record.html
>>  [3] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.compiler/javax/lang/model/element/RecordComponentElement.html
>>  [4] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/preview-list.html
>>  [5] http://cr.openjdk.java.net/~jlahoda/8250768/test.javadoc.00/
>>  [6] https://bugs.openjdk.java.net/browse/JDK-8250769
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removing unnecessary cast.

I have primarily gone through all the javadoc changes.

There are three main areas of feedback:

1. The ElementFlag question. We have gone from one kind of element with special treatment (deprecated) to two (deprecated, preview), and there are signs of a third kind coming soon, maybe as early as next year, for work currently being discussed in the Panama project.

As the saying goes, three would be one too many.

So, I agree `ElementFlag` is underutilized today and could reasonably be removed, but it does seem worthwhile to keep, and it would even be worth increasing its usage soon, such as to combine methods and classes for deprecated elements and preview elements. 

I'm not sure I can go back into looking at files while typing this message, but if we are to keep `ElementFlag` we should at a minimum provide a better description of its purpose. For example, can/should it be used for all predicates on elements, or just the elements that get "special" handling when generating docs.

2. The use of strings containing HTML, and use of `RawHtml`, instead of working in terms of `Content` nodes such as `HtmlTree` and `StringContent`.

3. Track recent updates to the repo, regarding Conditional Pages. See how we set up conditional pages for the deprecated list, and do the same for preview items.  This is probably a must-do item, once you merge with mainline.
--

Finally, I realize this is a big chunk of work (well done!), across many areas, and that getting through a review is hard.  If it is too hard to address some of the comments here, I'm OK if you file follow-up bugs of at least the same priority and Fix Version as for the main bug here: JDK-8250768. (That applies to #1, #2 above; not #3).

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/WorkArounds.java line 526:

> 524:         return (sym.flags() & Flags.PREVIEW_REFLECTIVE) != 0;
> 525:     }
> 526: 

Generally, hacking your way into `Symbol` is undesirable (though accepted if there is no realistic alternative.)

Adding new code into the `WorkArounds` class should be seen as a means of last resort when the required information cannot be obtained from public API ... which may require updating the public API as well.  For example, should these methods be predicates on the Language Model `Elements` class?

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractExecutableMemberWriter.java line 89:

> 87:     @Override
> 88:     protected Content getDeprecatedOrPreviewLink(Element member) {
> 89:         Content deprecatedLinkContent = new ContentBuilder();

name does not match usage.  I suggest simplifying it to just "content".

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractExecutableMemberWriter.java line 88:

> 86: 
> 87:     @Override
> 88:     protected Content getDeprecatedOrPreviewLink(Element member) {

This name is a side-effect of the `ElementFlag` question.  We should either use explicit field and method names, or we should use `ElementFlag` more consistently.   This method name works OK for now, but if if ever gets to have another `orFoo` component in the name, the signature should be parameterized with something like `ElementFlag` or its equivalent.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AllClassesIndexWriter.java line 172:

> 170:             description.add(getDeprecatedPhrase(klass));
> 171:             List<? extends DocTree> tags = utils.getDeprecatedTrees(klass);
> 172:             if (!tags.isEmpty()) {

There is potential for future parameterization using `ElementFlag` or its equivalent.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AnnotationTypeRequiredMemberWriterImpl.java line 205:

> 203:     protected Content getDeprecatedOrPreviewLink(Element member) {
> 204:         String name = utils.getFullyQualifiedName(member) + "." + member.getSimpleName();
> 205:         return writer.getDocLink(LinkInfoImpl.Kind.MEMBER_DEPRECATED_PREVIEW, member, name);

I suspect the MEMBER_DEPRECATED_PREVIEW will become more general in future

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassWriterImpl.java line 210:

> 208:                 pre.add(modifiersPart);
> 209:                 pre.add(new HtmlTree(TagName.SUP).add(links.createLink(getPreviewSectionAnchor(typeElement),
> 210:                                                       contents.previewMark)));

Possible future enhancement: use a set of modifiers that need flags

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassWriterImpl.java line 281:

> 279:                     pre.add(DocletConstants.NL);
> 280:                     pre.add("permits");
> 281:                     pre.add(new HtmlTree(TagName.SUP).add(links.createLink(getPreviewSectionAnchor(typeElement),

@hns is it better to use `<sup>` or CSS?  Either way is OK in this review.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDoclet.java line 187:

> 185:             PreviewListWriter.generate(configuration);
> 186:         }
> 187: 

This may need to be updated, by comparing against similar code for DEPRECATED, and/or you need to take `HtmlDocletWriter.ConditionalPage` into account, again by comparing with latest code for deprecated items.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java line 112:

> 110: import jdk.javadoc.internal.doclets.toolkit.util.VisibleMemberTable;
> 111: import jdk.javadoc.internal.doclets.toolkit.util.Utils;
> 112: import jdk.javadoc.internal.doclets.toolkit.util.Utils.DeclarationPreviewLanguageFeatures;

Uuugh on the long class name ;-)

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java line 1039:

> 1037:         } else if (utils.isVariableElement(element) || utils.isTypeElement(element)) {
> 1038:             return getLink(new LinkInfoImpl(configuration, context, typeElement)
> 1039:                 .label(label).where(links.getName(element.getSimpleName().toString())).targetMember(element));

Note to self (@jonathan-gibbons ) links.getName should accept a `CharSequence` to avoid the need for `toString()`

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java line 2219:

> 2217:             if (previewTree != null) {
> 2218:                 div.add(HtmlTree.SPAN(HtmlStyle.previewLabel,
> 2219:                                       new RawHtml(utils.getPreviewTreeSummaryOrDetails(previewTree, true))));

There's a big cringe here that there is a method in Utils returning HTML.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java line 2281:

> 2279:                 RawHtml note2 =
> 2280:                         new RawHtml(resources.getText("doclet.PreviewTrailingNote2",
> 2281:                                     name));

This is a deviation from existing practice to allow HTML in resource files. That doesn't seem like the sort of stuff that should be localizable. In other situations, (e.g. the Help page) we put the plain-text contents in the resource file and generate the markup in the code.

Elsewhere, I said that `WorkArounds` is a means of last resort. The same is true for `RawHtml`. Use it if you must, but it's better to use other forms of `Content`, like `HtmlTree`.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java line 2322:

> 2320:                         feature.features
> 2321:                                .stream()
> 2322:                                .map(f -> "<code>" + f + "</code>")

Ugh for using string constants for HTML.  Try and use `Content` instead,

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java line 2329:

> 2327:                                           featureDisplayName,
> 2328:                                           featureCodes);
> 2329:                 result.add(new RawHtml(text));

General ugh for many of the aforementioned reasons, all related to handling HTML in strings.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java line 2351:

> 2349:                             .map(this::toLink)
> 2350:                             .map(link -> getLink(link).toString())
> 2351:                             .collect(Collectors.joining(", "))));

More of the same ... `RawHtml` and building HTML in strings

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/LinkInfoImpl.java line 64:

> 62:          * Indicate that the link appears in member documentation on the Deprecated or Preview page.
> 63:          */
> 64:         MEMBER_DEPRECATED_PREVIEW,

Will need to be generalized, eventually

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Navigation.java line 228:

> 226:                 addTreeLink(tree);
> 227:                 addDeprecatedLink(tree);
> 228:                 addPreviewLink(tree);

It's OK to put the link here, I guess, but it should also be on the INDEX page.

See also recent updates for conditional pages.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Navigation.java line 888:

> 886: 
> 887:     private void addPreviewLink(Content tree) {
> 888:         if (configuration.getIncludedModuleElements().stream().anyMatch(m -> m.getQualifiedName().contentEquals("java.base"))) {

This becomes simpler with recent support for conditional pages.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageWriterImpl.java line 39:

> 37: import com.sun.source.doctree.TextTree;
> 38: import com.sun.source.doctree.UnknownInlineTagTree;
> 39: import java.util.stream.Collectors;

why these imports?

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties line 288:

> 286: doclet.Declared_Using_Preview.SEALED_PERMITS=Sealed Classes
> 287: doclet.PreviewPlatformLeadingNote=<code>{0}</code> is a preview API of the Java platform.
> 288: doclet.ReflectivePreviewPlatformLeadingNote=<code>{0}</code> is a reflective preview API of the Java platform.

HTML in resource files is bad.  It would be marginally better to move the HTML to the value being substituted (using strings from Content nodes) and even better to use a method that substitutes Content nodes into a resource string (Not sure if that method exists, but it could/should).

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/ConstructorWriter.java line 79:

> 77:      * @param annotationDocTree content tree to which the preview information will be added
> 78:      */
> 79:     void addPreview(ExecutableElement member, Content contentTree);

Note to javadoc-team:  Consider using default methods to provide an empty implementation.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/ConstructorBuilder.java line 28:

> 26: package jdk.javadoc.internal.doclets.toolkit.builders;
> 27: 
> 28: import static java.lang.invoke.ConstantBootstraps.enumConstant;

Really? If it is required, it is in the wrong place.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/PreviewAPIListBuilder.java line 46:

> 44:  *  deletion without notice.</b>
> 45:  */
> 46: public class PreviewAPIListBuilder {

OK for now, but it might be worth eventually trying to merge this with `DeprecatedListBuilder`

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/PreviewAPIListBuilder.java line 79:

> 77:         for (PreviewElementKind kind : PreviewElementKind.values()) {
> 78:             previewMap.put(kind,
> 79:                     new TreeSet<>(utils.comparators.makeDeprecatedComparator()));

The use of `makeDeprecatedComparator` is not awful, but does smell a bit.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/PreviewAPIListBuilder.java line 86:

> 84:     /**
> 85:      * Build the sorted list of all the deprecated APIs in this run.
> 86:      * Build separate lists for deprecated modules, packages, classes, constructors,

"d-word", twice

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/PreviewAPIListBuilder.java line 89:

> 87:      * methods and fields.
> 88:      */
> 89:     private void buildDeprecatedAPIInfo() {

D-word

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/PreviewAPIListBuilder.java line 133:

> 131:                 }
> 132:             }
> 133:             composeDeprecatedList(previewMap.get(PreviewElementKind.FIELD),

I suggest you grep this file for all uses of the d-word

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/PreviewAPIListBuilder.java line 158:

> 156:      * @param members members to be added in the list.
> 157:      */
> 158:     private void composeDeprecatedList(SortedSet<Element> sset, List<? extends Element> members) {

Last time d-word comment. Consider all such uses to be flagged.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java line 2848:

> 2846:         UnknownInlineTagTree previewTag = (UnknownInlineTagTree) t;
> 2847:         List<? extends DocTree> previewContent = previewTag.getContent();
> 2848:         String previewText = ((TextTree) previewContent.get(0)).getBody();

This looks unreasonably fragile. And, I thought the tag was going away... at least according to earlier files in this review.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java line 2984:

> 2982:         SEALED(List.of("sealed")),
> 2983:         SEALED_PERMITS(List.of("sealed", "permits")),
> 2984:         RECORD(List.of("record"));

I'm guessing this is about to go away soon?

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java line 2980:

> 2978:     }
> 2979: 
> 2980:     public enum DeclarationPreviewLanguageFeatures {

General thinking aloud question ... how does all this interact with source or release options for an earlier release?

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java line 3025:

> 3023:             case MODULE, PACKAGE -> {
> 3024:             }
> 3025:             default -> throw new IllegalStateException("Unexpected: " + el.getKind());

Should be `IllegalArgumentException` not `IllegalStateException`

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java line 3145:

> 3143:      * Checks whether the given Element should be marked as a preview API.
> 3144:      *
> 3145:      * Note that is a type is marked as a preview, its members are not.

probable typo: "is" -> "if"

src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/ElementsTable.java line 1288:

> 1286:                 case FIELD: case INSTANCE_INIT: case LOCAL_VARIABLE: case PARAMETER:
> 1287:                 case RESOURCE_VARIABLE: case STATIC_INIT: case TYPE_PARAMETER:
> 1288:                 case RECORD_COMPONENT:

I'm not saying this is wrong, but I'd like to understand why it is necessary.

-------------

PR: https://git.openjdk.java.net/jdk/pull/703

From hseigel at openjdk.java.net  Fri Oct 23 18:50:44 2020
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Fri, 23 Oct 2020 18:50:44 GMT
Subject: RFR: 8238263: Create at-requires mechanism for containers
Message-ID: <FsY15A1EzVxl9sqvxg5tqW49LGcUqBRtkQ11JHggBT4=.6786bce8-36cf-4ce6-afc2-a435dddead5d@github.com>

Please review this change to add an @requires mechanism called "jdk.containerized" to help mark tests that are incompatible with containers.  Users would add "@requires jdk.containerized != true" to the incompatible tests and then use "make test ... OPTIONS=-Djdk.containerized=true" or "bash jib.sh mach5 -- remote-build-and-test ... --test-make-args JTREG=OPTIONS=-Djdk.containerized=true" to exclude those tests when testing with containers.

-------------

Commit messages:
 - 8238263: Create at-requires mechanism for containers

Changes: https://git.openjdk.java.net/jdk/pull/844/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=844&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8238263
  Stats: 4 lines in 2 files changed: 2 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/844.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/844/head:pull/844

PR: https://git.openjdk.java.net/jdk/pull/844

From bob.vandette at oracle.com  Fri Oct 23 19:12:25 2020
From: bob.vandette at oracle.com (Bob Vandette)
Date: Fri, 23 Oct 2020 15:12:25 -0400
Subject: RFR: 8238263: Create at-requires mechanism for containers
In-Reply-To: <FsY15A1EzVxl9sqvxg5tqW49LGcUqBRtkQ11JHggBT4=.6786bce8-36cf-4ce6-afc2-a435dddead5d@github.com>
References: <FsY15A1EzVxl9sqvxg5tqW49LGcUqBRtkQ11JHggBT4=.6786bce8-36cf-4ce6-afc2-a435dddead5d@github.com>
Message-ID: <9A1F573B-E6DD-4168-A89D-2425A9BDF045@oracle.com>

I wonder if it makes sense to add this option to open/test/jtreg-ext/requires/VMProps.java and have it
automatically enable this option based on an environment variable so we don?t have to remember the
cryptic command line sequence.

It?s too bad we can?t automatically detect that we are running in a container.

Bob.


> On Oct 23, 2020, at 2:50 PM, Harold Seigel <hseigel at openjdk.java.net> wrote:
> 
> Please review this change to add an @requires mechanism called "jdk.containerized" to help mark tests that are incompatible with containers.  Users would add "@requires jdk.containerized != true" to the incompatible tests and then use "make test ... OPTIONS=-Djdk.containerized=true" or "bash jib.sh mach5 -- remote-build-and-test ... --test-make-args JTREG=OPTIONS=-Djdk.containerized=true" to exclude those tests when testing with containers.
> 
> -------------
> 
> Commit messages:
> - 8238263: Create at-requires mechanism for containers
> 
> Changes: https://git.openjdk.java.net/jdk/pull/844/files
> Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=844&range=00
>  Issue: https://bugs.openjdk.java.net/browse/JDK-8238263
>  Stats: 4 lines in 2 files changed: 2 ins; 0 del; 2 mod
>  Patch: https://git.openjdk.java.net/jdk/pull/844.diff
>  Fetch: git fetch https://git.openjdk.java.net/jdk pull/844/head:pull/844
> 
> PR: https://git.openjdk.java.net/jdk/pull/844


From iignatyev at openjdk.java.net  Fri Oct 23 19:20:34 2020
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Fri, 23 Oct 2020 19:20:34 GMT
Subject: RFR: 8238263: Create at-requires mechanism for containers
In-Reply-To: <FsY15A1EzVxl9sqvxg5tqW49LGcUqBRtkQ11JHggBT4=.6786bce8-36cf-4ce6-afc2-a435dddead5d@github.com>
References: <FsY15A1EzVxl9sqvxg5tqW49LGcUqBRtkQ11JHggBT4=.6786bce8-36cf-4ce6-afc2-a435dddead5d@github.com>
Message-ID: <43YvmzXR5TzDgPqfcAJDyfpOd7f_ur6ibKfh7AGf4LU=.40b88d2c-b29b-49d4-8d7f-120b7ade6cc5@github.com>

On Fri, 23 Oct 2020 18:44:54 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

> Please review this change to add an @requires mechanism called "jdk.containerized" to help mark tests that are incompatible with containers.  Users would add "@requires jdk.containerized != true" to the incompatible tests and then use "make test ... OPTIONS=-Djdk.containerized=true" or "bash jib.sh mach5 -- remote-build-and-test ... --test-make-args JTREG=OPTIONS=-Djdk.containerized=true" to exclude those tests when testing with containers.

Hi Harold,

I actually still think that having a separate ProblemList (as we do for graal, zgc, Xcomp, aot) is a better solution. why did you choose `@requires` over it?

-- Igor

-------------

PR: https://git.openjdk.java.net/jdk/pull/844

From harold.seigel at oracle.com  Fri Oct 23 19:22:49 2020
From: harold.seigel at oracle.com (Harold Seigel)
Date: Fri, 23 Oct 2020 15:22:49 -0400
Subject: RFR: 8238263: Create at-requires mechanism for containers
In-Reply-To: <9A1F573B-E6DD-4168-A89D-2425A9BDF045@oracle.com>
References: <FsY15A1EzVxl9sqvxg5tqW49LGcUqBRtkQ11JHggBT4=.6786bce8-36cf-4ce6-afc2-a435dddead5d@github.com>
 <9A1F573B-E6DD-4168-A89D-2425A9BDF045@oracle.com>
Message-ID: <38650f41-c1e8-ffb1-711f-c870f37df6e2@oracle.com>

Hi Bob,

Thanks for looking at this.? I'll look into basing the option on an 
environment variable.

Thanks, Harold

On 10/23/2020 3:12 PM, Bob Vandette wrote:
> I wonder if it makes sense to add this option to open/test/jtreg-ext/requires/VMProps.java and have it
> automatically enable this option based on an environment variable so we don?t have to remember the
> cryptic command line sequence.
>
> It?s too bad we can?t automatically detect that we are running in a container.
>
> Bob.
>
>
>> On Oct 23, 2020, at 2:50 PM, Harold Seigel <hseigel at openjdk.java.net> wrote:
>>
>> Please review this change to add an @requires mechanism called "jdk.containerized" to help mark tests that are incompatible with containers.  Users would add "@requires jdk.containerized != true" to the incompatible tests and then use "make test ... OPTIONS=-Djdk.containerized=true" or "bash jib.sh mach5 -- remote-build-and-test ... --test-make-args JTREG=OPTIONS=-Djdk.containerized=true" to exclude those tests when testing with containers.
>>
>> -------------
>>
>> Commit messages:
>> - 8238263: Create at-requires mechanism for containers
>>
>> Changes: https://git.openjdk.java.net/jdk/pull/844/files
>> Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=844&range=00
>>   Issue: https://bugs.openjdk.java.net/browse/JDK-8238263
>>   Stats: 4 lines in 2 files changed: 2 ins; 0 del; 2 mod
>>   Patch: https://git.openjdk.java.net/jdk/pull/844.diff
>>   Fetch: git fetch https://git.openjdk.java.net/jdk pull/844/head:pull/844
>>
>> PR: https://git.openjdk.java.net/jdk/pull/844

From hseigel at openjdk.java.net  Fri Oct 23 19:28:36 2020
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Fri, 23 Oct 2020 19:28:36 GMT
Subject: RFR: 8238263: Create at-requires mechanism for containers
In-Reply-To: <43YvmzXR5TzDgPqfcAJDyfpOd7f_ur6ibKfh7AGf4LU=.40b88d2c-b29b-49d4-8d7f-120b7ade6cc5@github.com>
References: <FsY15A1EzVxl9sqvxg5tqW49LGcUqBRtkQ11JHggBT4=.6786bce8-36cf-4ce6-afc2-a435dddead5d@github.com>
 <43YvmzXR5TzDgPqfcAJDyfpOd7f_ur6ibKfh7AGf4LU=.40b88d2c-b29b-49d4-8d7f-120b7ade6cc5@github.com>
Message-ID: <rw1F2xcnmpGnCqoqUYfV2QB816kTYJFPMFK47SZ4Pus=.e2c9cb3e-9300-48a6-b96c-94d1a253211d@github.com>

On Fri, 23 Oct 2020 19:17:40 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

>> Please review this change to add an @requires mechanism called "jdk.containerized" to help mark tests that are incompatible with containers.  Users would add "@requires jdk.containerized != true" to the incompatible tests and then use "make test ... OPTIONS=-Djdk.containerized=true" or "bash jib.sh mach5 -- remote-build-and-test ... --test-make-args JTREG=OPTIONS=-Djdk.containerized=true" to exclude those tests when testing with containers.
>
> Hi Harold,
> 
> I actually still think that having a separate ProblemList (as we do for graal, zgc, Xcomp, aot) is a better solution. why did you choose `@requires` over it?
> 
> -- Igor

Hi Igor,
I think it depends on whether the tests will be permanently or temporarily excluded from running with containers.  I thought this mechanism would be to permanently exclude the tests.  That's why I used @requires.
Thanks, Harold

-------------

PR: https://git.openjdk.java.net/jdk/pull/844

From iignatyev at openjdk.java.net  Fri Oct 23 19:57:35 2020
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Fri, 23 Oct 2020 19:57:35 GMT
Subject: RFR: 8238263: Create at-requires mechanism for containers
In-Reply-To: <rw1F2xcnmpGnCqoqUYfV2QB816kTYJFPMFK47SZ4Pus=.e2c9cb3e-9300-48a6-b96c-94d1a253211d@github.com>
References: <FsY15A1EzVxl9sqvxg5tqW49LGcUqBRtkQ11JHggBT4=.6786bce8-36cf-4ce6-afc2-a435dddead5d@github.com>
 <43YvmzXR5TzDgPqfcAJDyfpOd7f_ur6ibKfh7AGf4LU=.40b88d2c-b29b-49d4-8d7f-120b7ade6cc5@github.com>
 <rw1F2xcnmpGnCqoqUYfV2QB816kTYJFPMFK47SZ4Pus=.e2c9cb3e-9300-48a6-b96c-94d1a253211d@github.com>
Message-ID: <WPMFwq6E5LzalgbbH6nRN13MMSZQjm5SDQc74XdnO64=.be4a6b0d-97ce-4652-95ca-6234d4e19bdc@github.com>

On Fri, 23 Oct 2020 19:25:27 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

> I think it depends on whether the tests will be permanently or temporarily excluded from running with containers. I thought this mechanism would be to permanently exclude the tests. That's why I used `@requires`.

I see, if this is for permanent exclusion then yes I agree that `@requires` is a better choice.

>> enable this option based on an environment variable so we don?t have to remember the
cryptic command line sequence.
> I'll look into basing the option on an environment variable.

one will still need to pass an environment variable to jtreg, and hence will need to remember some sort of "cryptic command line sequence". a solution for that might be to default `jdk.containerized` to `false` in `VMProps.java` and when only _containerized_ runs will have to set it up.


btw, I'm not sure that `jdk.containerized` is the best name for this property as _containerization_ is more of an environmental characteristic than that of jdk. how about smth like `env.containerized` or `testenv.containerized`?

-------------

PR: https://git.openjdk.java.net/jdk/pull/844

From bob.vandette at oracle.com  Fri Oct 23 20:03:11 2020
From: bob.vandette at oracle.com (Bob Vandette)
Date: Fri, 23 Oct 2020 16:03:11 -0400
Subject: RFR: 8238263: Create at-requires mechanism for containers
In-Reply-To: <WPMFwq6E5LzalgbbH6nRN13MMSZQjm5SDQc74XdnO64=.be4a6b0d-97ce-4652-95ca-6234d4e19bdc@github.com>
References: <FsY15A1EzVxl9sqvxg5tqW49LGcUqBRtkQ11JHggBT4=.6786bce8-36cf-4ce6-afc2-a435dddead5d@github.com>
 <43YvmzXR5TzDgPqfcAJDyfpOd7f_ur6ibKfh7AGf4LU=.40b88d2c-b29b-49d4-8d7f-120b7ade6cc5@github.com>
 <rw1F2xcnmpGnCqoqUYfV2QB816kTYJFPMFK47SZ4Pus=.e2c9cb3e-9300-48a6-b96c-94d1a253211d@github.com>
 <WPMFwq6E5LzalgbbH6nRN13MMSZQjm5SDQc74XdnO64=.be4a6b0d-97ce-4652-95ca-6234d4e19bdc@github.com>
Message-ID: <9DF4B853-2FFD-4E3E-AE3F-1B5B3FA6FEC6@oracle.com>



> On Oct 23, 2020, at 3:57 PM, Igor Ignatyev <iignatyev at openjdk.java.net> wrote:
> 
> On Fri, 23 Oct 2020 19:25:27 GMT, Harold Seigel <hseigel at openjdk.org> wrote:
> 
>> I think it depends on whether the tests will be permanently or temporarily excluded from running with containers. I thought this mechanism would be to permanently exclude the tests. That's why I used `@requires`.
> 
> I see, if this is for permanent exclusion then yes I agree that `@requires` is a better choice.
> 
>>> enable this option based on an environment variable so we don?t have to remember the
> cryptic command line sequence.
>> I'll look into basing the option on an environment variable.
> 
> one will still need to pass an environment variable to jtreg, and hence will need to remember some sort of "cryptic command line sequence". a solution for that might be to default `jdk.containerized` to `false` in `VMProps.java` and when only _containerized_ runs will have to set it up.

Why?  Environment variables are inherited.  For developers running jtreg, all they need to do is export the variable.

% export JAVA_CONTAINERIZED=1
% bash
% echo $JAVA_CONTAINERIZED
% 1

Bob.

> 
> 
> btw, I'm not sure that `jdk.containerized` is the best name for this property as _containerization_ is more of an environmental characteristic than that of jdk. how about smth like `env.containerized` or `testenv.containerized`?
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/844


From iignatyev at openjdk.java.net  Fri Oct 23 20:10:34 2020
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Fri, 23 Oct 2020 20:10:34 GMT
Subject: RFR: 8238263: Create at-requires mechanism for containers
In-Reply-To: <WPMFwq6E5LzalgbbH6nRN13MMSZQjm5SDQc74XdnO64=.be4a6b0d-97ce-4652-95ca-6234d4e19bdc@github.com>
References: <FsY15A1EzVxl9sqvxg5tqW49LGcUqBRtkQ11JHggBT4=.6786bce8-36cf-4ce6-afc2-a435dddead5d@github.com>
 <43YvmzXR5TzDgPqfcAJDyfpOd7f_ur6ibKfh7AGf4LU=.40b88d2c-b29b-49d4-8d7f-120b7ade6cc5@github.com>
 <rw1F2xcnmpGnCqoqUYfV2QB816kTYJFPMFK47SZ4Pus=.e2c9cb3e-9300-48a6-b96c-94d1a253211d@github.com>
 <WPMFwq6E5LzalgbbH6nRN13MMSZQjm5SDQc74XdnO64=.be4a6b0d-97ce-4652-95ca-6234d4e19bdc@github.com>
Message-ID: <TnpbwzrPiw8NroTge6re_l4b2o12UkaPwNya9QodvBI=.5ba26389-c331-456f-b27d-9124c752f85b@github.com>

On Fri, 23 Oct 2020 19:54:40 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

>> Hi Igor,
>> I think it depends on whether the tests will be permanently or temporarily excluded from running with containers.  I thought this mechanism would be to permanently exclude the tests.  That's why I used @requires.
>> Thanks, Harold
>
>> I think it depends on whether the tests will be permanently or temporarily excluded from running with containers. I thought this mechanism would be to permanently exclude the tests. That's why I used `@requires`.
> 
> I see, if this is for permanent exclusion then yes I agree that `@requires` is a better choice.
> 
>>> enable this option based on an environment variable so we don?t have to remember the
> cryptic command line sequence.
>> I'll look into basing the option on an environment variable.
> 
> one will still need to pass an environment variable to jtreg, and hence will need to remember some sort of "cryptic command line sequence". a solution for that might be to default `jdk.containerized` to `false` in `VMProps.java` and when only _containerized_ runs will have to set it up.
> 
> 
> btw, I'm not sure that `jdk.containerized` is the best name for this property as _containerization_ is more of an environmental characteristic than that of jdk. how about smth like `env.containerized` or `testenv.containerized`?

> > one will still need to pass an environment variable to jtreg, and hence will need to remember some sort of "cryptic command line sequence". a solution for that might be to default `jdk.containerized` to `false` in `VMProps.java` and when only _containerized_ runs will have to set it up.
> 
> Why? Environment variables are inherited. For developers running jtreg, all they need to do is export the variable.
> 
> % export JAVA_CONTAINERIZED=1
> % bash
> % echo $JAVA_CONTAINERIZED
> % 1

b/c jtreg strips most of the environment variables, they might still be defined in the process which runs `VMProps` though (I have never checked that)

-------------

PR: https://git.openjdk.java.net/jdk/pull/844

From psandoz at openjdk.java.net  Fri Oct 23 20:44:41 2020
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Fri, 23 Oct 2020 20:44:41 GMT
Subject: RFR: 8254354: Add an asExact() VarHandle combinator [v2]
In-Reply-To: <Mo3T9JJzO03q-I_q8NhsGpu2TVaJg_104ESGWqLhYRg=.7d353318-6827-4708-b973-a9c30558c3ed@github.com>
References: <gJ1pTeZZC7tbtwiRsrHcZ1ydfTQhr1MPndGrnGolf14=.dd935929-4f22-4e41-9e0d-99a592ac46b7@github.com>
 <Mo3T9JJzO03q-I_q8NhsGpu2TVaJg_104ESGWqLhYRg=.7d353318-6827-4708-b973-a9c30558c3ed@github.com>
Message-ID: <TXUctfc1V1T5RKCtSJAgQZe6xO4I561ez5Ol4YdzLeA=.3c0c41b5-a8b1-44b4-b107-1bd58db6e1a1@github.com>

On Fri, 23 Oct 2020 18:06:51 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Hi,
>> 
>> This patch adds an asExact() combinator to VarHandle, that will return a new VarHandle that performs exact type checks, similar to MethodHandle::invokeExact, to help developers catch inexact VarHandle usage, which can lead to performance degradation.
>> 
>> This is implemented using a boolean flag in VarForm. If the flag is set, the exact type of the invocation is checked against the exact type in the VarForm. If there is a mismatch, a WrongMethodTypeException is thrown.
>> 
>> Other than that, there is also an asGeneric() combinator added that does the inverse operation (thanks to R?mi for the suggestion). I've also added The `@Hidden` annotation to the VarHandleGuards methods, as well as a type-checking helper method called from the generic invocation lambda form, so that the stack trace we get points at the location where the VarHandle is being used.
>> 
>> Thanks,
>> Jorn
>> 
>> GH action link (at time of submission): https://github.com/JornVernee/jdk/actions/runs/324660237
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make internalName helper method static

This approach does not work for reference types, since they are erased to `Object`, and then exact checking will be performed on the erased reference types.

For example try this:

import java.lang.invoke.MethodHandles;
import java.lang.invoke.VarHandle;

public class Test {
    int x;

    public static void main(String[] args) throws Throwable {
        VarHandle x = MethodHandles.lookup().findVarHandle(Test.class, "x", int.class);
        VarHandle ex = x.asExact();
        Test t = new Test();
        ex.set(t, 1);
    }
}

Which results in:

Exception in thread "main" java.lang.invoke.WrongMethodTypeException: expected (Object,int)void but found (Test,int)void
	at Test.main(Test.java:11)

Exact type checking requires that match be performed on the VH access mode method type and the exact symbolic method type, something like:

    final static Object guard_L_L(VarHandle handle, Object arg0, VarHandle.AccessDescriptor ad) throws Throwable {
        if (handle.vform.exact && handle.accessModeType(ad.type) != ad.symbolicMethodTypeExact) {
            throw new WrongMethodTypeException("expected " + handle.vform.methodType_table_exact[ad.type] + " but found "
                    + ad.symbolicMethodTypeExact);
        }

Then it's precisely the same as `MH.invokeExact`, rather than `MH.invoke`.

A `VarForm` is a resource shared across many instances of the same _kind_ of `VarHandle`, so cannot be used for exact matching, except in specific scenarios e.g. access on a primitive array.

-------------

PR: https://git.openjdk.java.net/jdk/pull/843

From jvernee at openjdk.java.net  Fri Oct 23 21:40:34 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Fri, 23 Oct 2020 21:40:34 GMT
Subject: RFR: 8254354: Add an asExact() VarHandle combinator [v2]
In-Reply-To: <TXUctfc1V1T5RKCtSJAgQZe6xO4I561ez5Ol4YdzLeA=.3c0c41b5-a8b1-44b4-b107-1bd58db6e1a1@github.com>
References: <gJ1pTeZZC7tbtwiRsrHcZ1ydfTQhr1MPndGrnGolf14=.dd935929-4f22-4e41-9e0d-99a592ac46b7@github.com>
 <Mo3T9JJzO03q-I_q8NhsGpu2TVaJg_104ESGWqLhYRg=.7d353318-6827-4708-b973-a9c30558c3ed@github.com>
 <TXUctfc1V1T5RKCtSJAgQZe6xO4I561ez5Ol4YdzLeA=.3c0c41b5-a8b1-44b4-b107-1bd58db6e1a1@github.com>
Message-ID: <FzY88BSt7bw9P6vmQKtXtBrd8Zwd4bE0sg39ur30x_4=.8ada75c2-7f54-4058-aa7c-822d12f9cbc9@github.com>

On Fri, 23 Oct 2020 20:41:31 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Make internalName helper method static
>
> This approach does not work for reference types, since they are erased to `Object`, and then exact checking will be performed on the erased reference types.
> 
> For example try this:
> 
> import java.lang.invoke.MethodHandles;
> import java.lang.invoke.VarHandle;
> 
> public class Test {
>     int x;
> 
>     public static void main(String[] args) throws Throwable {
>         VarHandle x = MethodHandles.lookup().findVarHandle(Test.class, "x", int.class);
>         VarHandle ex = x.asExact();
>         Test t = new Test();
>         ex.set(t, 1);
>     }
> }
> 
> Which results in:
> 
> Exception in thread "main" java.lang.invoke.WrongMethodTypeException: expected (Object,int)void but found (Test,int)void
> 	at Test.main(Test.java:11)
> 
> Exact type checking requires that match be performed on the VH access mode method type and the exact symbolic method type, something like:
> 
>     final static Object guard_L_L(VarHandle handle, Object arg0, VarHandle.AccessDescriptor ad) throws Throwable {
>         if (handle.vform.exact && handle.accessModeType(ad.type) != ad.symbolicMethodTypeExact) {
>             throw new WrongMethodTypeException("expected " + handle.vform.methodType_table_exact[ad.type] + " but found "
>                     + ad.symbolicMethodTypeExact);
>         }
> 
> Then it's precisely the same as `MH.invokeExact`, rather than `MH.invoke`.
> 
> A `VarForm` is a resource shared across many instances of the same _kind_ of `VarHandle`, so cannot be used for exact matching, except in specific scenarios e.g. access on a primitive array.

@PaulSandoz Thanks. I initially tested this with memory access VarHandles, which don't erase the receiver type. e.g.

MemoryLayout layout = MemoryLayout.ofSequence(10, JAVA_INT);
VarHandle vh = layout.varHandle(int.class, MemoryLayout.PathElement.sequenceElement());
vh = vh.asExact();
try (MemorySegment segment = MemorySegment.allocateNative(layout)) {
    for (int i = 0; i <10; i++) {
        vh.set(segment.baseAddress(), i, i);
    }
}

Will result in:
Exception in thread "main" java.lang.invoke.WrongMethodTypeException: expected (MemoryAddress,long,int)void but found (MemoryAddress,int,int)void
	at java.base/java.lang.invoke.VarHandleGuards.guard_LII_V(VarHandleGuards.java:915)
	at main.Main.main(Main.java:18)

Which led me to believe the approach would work for other reference types. But, I suppose the MethodTypes fed to memaccess VarForms are non-erased as an exception rather than a rule.

I'll update the patch and sharpen the tests to check that the actual expected type is correct (per the exception message).

-------------

PR: https://git.openjdk.java.net/jdk/pull/843

From jvernee at openjdk.java.net  Fri Oct 23 23:54:51 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Fri, 23 Oct 2020 23:54:51 GMT
Subject: RFR: 8254354: Add an asExact() VarHandle combinator [v3]
In-Reply-To: <gJ1pTeZZC7tbtwiRsrHcZ1ydfTQhr1MPndGrnGolf14=.dd935929-4f22-4e41-9e0d-99a592ac46b7@github.com>
References: <gJ1pTeZZC7tbtwiRsrHcZ1ydfTQhr1MPndGrnGolf14=.dd935929-4f22-4e41-9e0d-99a592ac46b7@github.com>
Message-ID: <KLoTaBE7oFOwHLvJboIA4hUKNSvwa1257dgM1u2qLqc=.3c9d2a41-281c-489d-bab1-fd273fbefd46@github.com>

> Hi,
> 
> This patch adds an asExact() combinator to VarHandle, that will return a new VarHandle that performs exact type checks, similar to MethodHandle::invokeExact, to help developers catch inexact VarHandle usage, which can lead to performance degradation.
> 
> This is implemented using a boolean flag in VarForm. If the flag is set, the exact type of the invocation is checked against the exact type in the VarForm. If there is a mismatch, a WrongMethodTypeException is thrown.
> 
> Other than that, there is also an asGeneric() combinator added that does the inverse operation (thanks to R?mi for the suggestion). I've also added The `@Hidden` annotation to the VarHandleGuards methods, as well as a type-checking helper method called from the generic invocation lambda form, so that the stack trace we get points at the location where the VarHandle is being used.
> 
> Thanks,
> Jorn

Jorn Vernee has updated the pull request incrementally with three additional commits since the last revision:

 - Fix whitespace
 - Comment out VarHandleGuards generator code
 - Makes exactness a property of a VarHandle, not a VarForm, since the latter are shared. Use handle.accessModeType to get the exact type of the VarHandle.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/843/files
  - new: https://git.openjdk.java.net/jdk/pull/843/files/dc1f9ecf..be9e940d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=843&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=843&range=01-02

  Stats: 410 lines in 11 files changed: 90 ins; 71 del; 249 mod
  Patch: https://git.openjdk.java.net/jdk/pull/843.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/843/head:pull/843

PR: https://git.openjdk.java.net/jdk/pull/843

From jvernee at openjdk.java.net  Sat Oct 24 00:01:37 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Sat, 24 Oct 2020 00:01:37 GMT
Subject: RFR: 8254354: Add an asExact() VarHandle combinator [v2]
In-Reply-To: <FzY88BSt7bw9P6vmQKtXtBrd8Zwd4bE0sg39ur30x_4=.8ada75c2-7f54-4058-aa7c-822d12f9cbc9@github.com>
References: <gJ1pTeZZC7tbtwiRsrHcZ1ydfTQhr1MPndGrnGolf14=.dd935929-4f22-4e41-9e0d-99a592ac46b7@github.com>
 <Mo3T9JJzO03q-I_q8NhsGpu2TVaJg_104ESGWqLhYRg=.7d353318-6827-4708-b973-a9c30558c3ed@github.com>
 <TXUctfc1V1T5RKCtSJAgQZe6xO4I561ez5Ol4YdzLeA=.3c0c41b5-a8b1-44b4-b107-1bd58db6e1a1@github.com>
 <FzY88BSt7bw9P6vmQKtXtBrd8Zwd4bE0sg39ur30x_4=.8ada75c2-7f54-4058-aa7c-822d12f9cbc9@github.com>
Message-ID: <l89RFW5KvA8JvtpvCuo1q7gj2v6nRiuc_A-sN-7O0k8=.8c7153e0-d3f5-47e3-be91-a2782697ef48@github.com>

On Fri, 23 Oct 2020 21:38:16 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> This approach does not work for reference types, since they are erased to `Object`, and then exact checking will be performed on the erased reference types.
>> 
>> For example try this:
>> 
>> import java.lang.invoke.MethodHandles;
>> import java.lang.invoke.VarHandle;
>> 
>> public class Test {
>>     int x;
>> 
>>     public static void main(String[] args) throws Throwable {
>>         VarHandle x = MethodHandles.lookup().findVarHandle(Test.class, "x", int.class);
>>         VarHandle ex = x.asExact();
>>         Test t = new Test();
>>         ex.set(t, 1);
>>     }
>> }
>> 
>> Which results in:
>> 
>> Exception in thread "main" java.lang.invoke.WrongMethodTypeException: expected (Object,int)void but found (Test,int)void
>> 	at Test.main(Test.java:11)
>> 
>> Exact type checking requires that match be performed on the VH access mode method type and the exact symbolic method type, something like:
>> 
>>     final static Object guard_L_L(VarHandle handle, Object arg0, VarHandle.AccessDescriptor ad) throws Throwable {
>>         if (handle.vform.exact && handle.accessModeType(ad.type) != ad.symbolicMethodTypeExact) {
>>             throw new WrongMethodTypeException("expected " + handle.vform.methodType_table_exact[ad.type] + " but found "
>>                     + ad.symbolicMethodTypeExact);
>>         }
>> 
>> Then it's precisely the same as `MH.invokeExact`, rather than `MH.invoke`.
>> 
>> A `VarForm` is a resource shared across many instances of the same _kind_ of `VarHandle`, so cannot be used for exact matching, except in specific scenarios e.g. access on a primitive array.
>
> @PaulSandoz Thanks. I initially tested this with memory access VarHandles, which don't erase the receiver type. e.g.
> 
> MemoryLayout layout = MemoryLayout.ofSequence(10, JAVA_INT);
> VarHandle vh = layout.varHandle(int.class, MemoryLayout.PathElement.sequenceElement());
> vh = vh.asExact();
> try (MemorySegment segment = MemorySegment.allocateNative(layout)) {
>     for (int i = 0; i <10; i++) {
>         vh.set(segment.baseAddress(), i, i);
>     }
> }
> 
> Will result in:
> Exception in thread "main" java.lang.invoke.WrongMethodTypeException: expected (MemoryAddress,long,int)void but found (MemoryAddress,int,int)void
> 	at java.base/java.lang.invoke.VarHandleGuards.guard_LII_V(VarHandleGuards.java:915)
> 	at main.Main.main(Main.java:18)
> 
> Which led me to believe the approach would work for other reference types. But, I suppose the MethodTypes fed to memaccess VarForms are non-erased as an exception rather than a rule.
> 
> I'll update the patch and sharpen the tests to check that the actual expected type is correct (per the exception message).

@PaulSandoz I've implemented your suggestion. FWIW, the VH::accessModeType method took and AccessMode value as an argument, and the AccessDescriptor only stored the ordinal, so I added an `@Stable` array of values to AccessMode to map from ordinal to enum value. But, maybe it makes more sense to just store the AccessMode in the AccessDescriptor directly? (instead of the ordinal). Not sure what the original motivation was for only storing the ordinal.

I've also sharpened the tests to check the exception message. Do you think the testing is sufficient? (Note that I did not add tests to the template files since only a select set of argument type conversions causes the WMTE we're looking for. So, that's why I created a new test file).

FWIW, there seems to have been a bug in the implementation of IndirectVarHandle::accessModeTypeUncached, where it was using the VarHandle's type as the receiver argument (unlike all the other impls). I've fixed this by passing `null` instead, and also removed a workaround for this problem in VarHandles::maybeAdapt.

-------------

PR: https://git.openjdk.java.net/jdk/pull/843

From almatvee at openjdk.java.net  Sat Oct 24 00:55:44 2020
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Sat, 24 Oct 2020 00:55:44 GMT
Subject: RFR: 8255206: [macos] LicenseTest fails on macOS 11
Message-ID: <TNyJYXd93S-rihjFcaejAUAjgjH1dZDQflB9haFdjjI=.12295fd9-9c9b-45c9-a733-f8bc42ea131f@github.com>

I did not reproduce issue with license is not shown as per SQE report. It work as expected. However, jpackage fails due to unflatten/flatten being removed from hdiutil on macOS 11. I am not sure why it was needed, probably some legacy code. Without unflatten/flatten everything works as expected on macOS 11 and 10.5.7.

-------------

Commit messages:
 - 8255206: [macos] LicenseTest fails on macOS 11

Changes: https://git.openjdk.java.net/jdk/pull/847/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=847&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8255206
  Stats: 18 lines in 1 file changed: 0 ins; 18 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/847.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/847/head:pull/847

PR: https://git.openjdk.java.net/jdk/pull/847

From vromero at openjdk.java.net  Sat Oct 24 02:14:50 2020
From: vromero at openjdk.java.net (Vicente Romero)
Date: Sat, 24 Oct 2020 02:14:50 GMT
Subject: RFR: 8250625: Compiler implementation of Pattern Matching for
 instanceof (Final) [v4]
In-Reply-To: <ImquH7O0eoATlNNlz0N0t-6KvFripYQjTaFRyX7l-z8=.8dc08d9d-2587-4f8a-98bd-724a867d2d6a@github.com>
References: <0uEby0-y3KVBLA1VxxdD5hCMlLhPCKB3w0mpihs9dsY=.181f22cd-7cf7-4941-b2d1-2ba4228d11d5@github.com>
 <ImquH7O0eoATlNNlz0N0t-6KvFripYQjTaFRyX7l-z8=.8dc08d9d-2587-4f8a-98bd-724a867d2d6a@github.com>
Message-ID: <e-DgMkw1tSysnU3NptrYj_1Pwe7AXcSCZCslqrSdmHI=.3c6363f1-f508-4901-ba64-39140097f562@github.com>

On Thu, 22 Oct 2020 12:14:42 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is the current proposed patch for the upcoming JEP 394, for pattern matching for instanceof.
>> 
>> A summary of changes:
>> -making the feature permanent (non-preview)
>> -making the binding variables non-final (as per current specification proposal)
>> -producing a compile-time error for the case where the expression's type is a subtype of the type test pattern's type (as per current specification proposal)
>> -changing the AST structure so that the binding variable has a VariableTree in the AST. BindingPatternTree is preserved and encloses the VariableTree. The reason is better consistency in the API, with nodes like CatchTree, EnhancedForLoop Tree, etc.
>> 
>> This change will not be integrated until JEP 394 is targetted.
>
> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 18 additional commits since the last revision:
> 
>  - Removing the preview deprecated methods from BindingPatternTree.
>  - Merge branch 'master' into patterns-instanceof3
>  - Fixing review comments.
>  - Cleanup: using a null instead of List.of() as a parameter to JavaCompiler.getTask
>  - Merge branch 'master' into patterns-instanceof3
>  - Fixing more tests.
>  - Correcting positions.
>  - Improve the AST model.
>  - Merge branch 'master' into patterns-instanceof3
>  - Updating @since tags.
>  - ... and 8 more: https://git.openjdk.java.net/jdk/compare/68eec7af...77468e24

looks good!

-------------

Marked as reviewed by vromero (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/559

From jvernee at openjdk.java.net  Sat Oct 24 12:51:48 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Sat, 24 Oct 2020 12:51:48 GMT
Subject: RFR: 8254354: Add an asExact() VarHandle combinator [v4]
In-Reply-To: <gJ1pTeZZC7tbtwiRsrHcZ1ydfTQhr1MPndGrnGolf14=.dd935929-4f22-4e41-9e0d-99a592ac46b7@github.com>
References: <gJ1pTeZZC7tbtwiRsrHcZ1ydfTQhr1MPndGrnGolf14=.dd935929-4f22-4e41-9e0d-99a592ac46b7@github.com>
Message-ID: <KKYiDVM1vpd-4LmO4kXQ4fLRx2LQn7Rie8nG2RH46WE=.3f6a172f-04bb-4be1-8b6e-a94b0ee08cf8@github.com>

> Hi,
> 
> This patch adds an asExact() combinator to VarHandle, that will return a new VarHandle that performs exact type checks, similar to MethodHandle::invokeExact, to help developers catch inexact VarHandle usage, which can lead to performance degradation.
> 
> This is implemented using a boolean flag in VarForm. If the flag is set, the exact type of the invocation is checked against the exact type in the VarForm. If there is a mismatch, a WrongMethodTypeException is thrown.
> 
> Other than that, there is also an asGeneric() combinator added that does the inverse operation (thanks to R?mi for the suggestion). I've also added The `@Hidden` annotation to the VarHandleGuards methods, as well as a type-checking helper method called from the generic invocation lambda form, so that the stack trace we get points at the location where the VarHandle is being used.
> 
> Thanks,
> Jorn

Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

  Fixes failing tests, and enable verifier on Exact test

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/843/files
  - new: https://git.openjdk.java.net/jdk/pull/843/files/be9e940d..6d7ad477

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=843&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=843&range=02-03

  Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/843.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/843/head:pull/843

PR: https://git.openjdk.java.net/jdk/pull/843

From kbarrett at openjdk.java.net  Sat Oct 24 19:25:37 2020
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Sat, 24 Oct 2020 19:25:37 GMT
Subject: RFR: 8188055: (ref) Add Reference::refersTo predicate [v6]
In-Reply-To: <WhvzLc5GEYMSBz9jYgaRDBTbpaZGFWPHqzdfYHa-W6Q=.8efc48fe-6ae2-4608-ba4c-136df49c3707@github.com>
References: <D4HSg8FT20Eaxk5KJkkw0GgETSxRkBn1ipS3Dt0kPto=.e4bab078-2e04-4413-90cb-9bfafb2a6831@github.com>
 <Y1IHoNr8vO3OkCbEKw6ywXd4adik1yKKNIS4ABzF0d0=.d21f4183-ef4e-45ed-826d-6613215b6220@github.com>
 <9x0zaxknpYXGIvHun1CkLP0lEC8NQmPTnANxQKjhHF8=.907bdb15-2e2e-4f84-8fe4-ea4ed50534cd@github.com>
 <DR2YKv3VavKKD-cpFyf6mCSYfaKq0KAGh2XDqBStkys=.895ba671-f63a-4ba3-b042-6568d647b4ab@github.com>
 <mkn_t3hsL4mlCOfO5ahZOMbp8i_LMOHwJALA_bNjHIk=.d8031a91-ed13-4882-925f-ea8a9e634198@github.com>
 <3JzF7OkemZ-Lxc4jZgdEh3qNDzW8wF7ITeq-s7_TOlo=.11e4e40b-b775-47cf-9862-735fbc61ffd3@github.com>
 <iPK64Jh4aJtfqoPDqADOBN8BczKet53bod5y_VjZoBw=.fed662e8-2b40-478b-a9de-4906c0a897dc@github.com>
 <3kV3qhFRXBadf7Tol9n0Yomud_ndV_T_p7ShUfk4eVE=.d7151a63-0066-4020-b0ef-bae0d03dc133@github.com>
 <WhvzLc5GEYMSBz9jYgaRDBTbpaZGFWPHqzdfYHa-W6Q=.8efc48fe-6ae2-4608-ba4c-136df49c3707@github.com>
Message-ID: <gMsUQqniAKFps2oyT36xgUcCdB_mBnoIoKKQxsmmg8E=.c4811317-580c-4259-9dec-f5c6fe5d3d85@github.com>

On Fri, 16 Oct 2020 19:22:16 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> I just want to note that if you have a `Reference<SomeType> ref` at hand, you can not just do:
>> Referemce<Object> r = (Reference<Object>) ref;
>> ...since those generic types are not related. You have to do something like:
>> 
>> @SuppressWarnings({"unchecked", "rawtypes"})
>> Referemce<Object> r = (Reference) ref;
>> which is very unfortunate. Comparing this method with for example `Collection.contains(Object element)`, you can see that Collection API has made a decision to not bother with T here. That was also due to keeping old code compatible when migrating from pre-generics Java to generified Collection, but as @dfuch noted, we have a migration story here too. We will be migrating `obj == ref.get()` to `ref.refersTo(obj)` ... Mind you that this is a boolean expression fragment which might be written inline surrounded with other parts of expression. So you'll be forced to split that into assignment with @SuppressWarnings and an expression or you will have to force the whole expression or method to @SuppressWarnings. I don't know if type "safety" is forth it here.
>
> Reference instances should not be leaked and so I don't see very common that caller of `Reference::get` does not know the referent's type.   It also depends on the `refersTo` check against `null` vs an object.  Any known use case would be helpful if any (some existing code that wants to call `refersTo` to compare a `Reference` of raw type with an object of unknown type).
> 
> FWIW, when converting a few use of `Reference::get` to `refersTo` in JDK, there is only one case (`equals(Object o)` method that needs the cast.
> 
> http://cr.openjdk.java.net/~mchung/jdk15/webrevs/8188055/jdk-use-refersTo/index.html

Is there a consensus on this issue?  It's not clear whether Daniel and Peter have agreed with Mandy's responses or have just not yet responded with further discussion.

-------------

PR: https://git.openjdk.java.net/jdk/pull/498

From github.com+51754783+coreyashford at openjdk.java.net  Sat Oct 24 21:41:36 2020
From: github.com+51754783+coreyashford at openjdk.java.net (CoreyAshford)
Date: Sat, 24 Oct 2020 21:41:36 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v8]
In-Reply-To: <IXZnO1Rv6RMimJLR5zL5MYSQZrBltEe_0I13tbN92XE=.24c72b06-28b8-413b-8b27-c97176125780@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <nU4nZ9oCthDEi7olxerj_bkmWuITInbbNzJKkb1shkY=.28b4ed81-9733-4981-b6fb-c8e4e3bd335e@github.com>
 <r_UoYsBul9SV88OG2z5qfeCfKQFCF23_DDfdB1LKlzY=.2df9f9a4-d0b6-4ac6-b75b-1cd59022eca6@github.com>
 <iD4pt7fK5AExXfPuONZnrjoFTNmHO7T96s_9KCiBYTM=.64012cef-fd79-4692-a029-2b75391bd193@github.com>
 <IXZnO1Rv6RMimJLR5zL5MYSQZrBltEe_0I13tbN92XE=.24c72b06-28b8-413b-8b27-c97176125780@github.com>
Message-ID: <LBKU_Ov5ZdR3WADmgLKeXahpXnxFBxUjxQ6frLwny38=.841fba45-c53a-4225-b77f-c5d2c24d93c0@github.com>

On Thu, 22 Oct 2020 20:40:00 GMT, CoreyAshford <github.com+51754783+CoreyAshford at openjdk.org> wrote:

>> Thanks for this question. I also stumbled over it when reviewing. I guess a branch which gets mispredicted in ~22% of the cases leads to a big performance loss. (In addition, the branch target is not aligned.)
>
> Yes, it assumes uniformly random data, but also recall that the unencoded data bytes get shifted by 2, 4, 6 bits into the encoded bytes, which I'm guessing would tend to make the data somewhat more uniform, even if the source data has low entropy.
> 
> That said, I didn't actually benchmark it.  I will do that to make sure there is a gain, and if there isn't I will remove the conditional branch.

> I took a look at the VSX algo. I haven't looked much beyond it. I had a few questions I've inlined. It does look like a faithful VSX implementation of the linked algo.

I neglected to thank you for reviewing this code!  I realize there's quite a time commitment required to review this properly, and because of that I was having difficulty finding a second reviewer for the PPC64 portion.

Just to set expectations, I will be on vacation next week, so further commits won't be posted until the following week, but I will address all of your great feedback.  Thanks again!

-------------

PR: https://git.openjdk.java.net/jdk/pull/293

From winterhalter at openjdk.java.net  Sat Oct 24 21:50:48 2020
From: winterhalter at openjdk.java.net (Rafael Winterhalter)
Date: Sat, 24 Oct 2020 21:50:48 GMT
Subject: RFR: 8202471: Make type annotations on owner type parameters available
Message-ID: <WJVy8_XXMJf5UOCifoPHUc06qVaU2MKlT_oosLaiqwg=.c2b16a91-64ce-4468-991c-a51ffd6b3202@github.com>

A method's or constructor's owner type might carry annotations on its potential type parameters but is never represented as parameterized type what makes these parameters inaccessible at runtime, despite the presence of parameter type annotations.

-------------

Commit messages:
 - 8202471: A method's or constructor's owner type might carry annotations on its potential type parameters but is never represented as parameterized type what makes these parameters inaccessible at runtime, despite the presence of parameter type annotations.

Changes: https://git.openjdk.java.net/jdk/pull/851/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=851&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8202471
  Stats: 199 lines in 5 files changed: 193 ins; 1 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/851.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/851/head:pull/851

PR: https://git.openjdk.java.net/jdk/pull/851

From plevart at openjdk.java.net  Sat Oct 24 22:25:36 2020
From: plevart at openjdk.java.net (Peter Levart)
Date: Sat, 24 Oct 2020 22:25:36 GMT
Subject: RFR: 8188055: (ref) Add Reference::refersTo predicate [v6]
In-Reply-To: <WhvzLc5GEYMSBz9jYgaRDBTbpaZGFWPHqzdfYHa-W6Q=.8efc48fe-6ae2-4608-ba4c-136df49c3707@github.com>
References: <D4HSg8FT20Eaxk5KJkkw0GgETSxRkBn1ipS3Dt0kPto=.e4bab078-2e04-4413-90cb-9bfafb2a6831@github.com>
 <Y1IHoNr8vO3OkCbEKw6ywXd4adik1yKKNIS4ABzF0d0=.d21f4183-ef4e-45ed-826d-6613215b6220@github.com>
 <9x0zaxknpYXGIvHun1CkLP0lEC8NQmPTnANxQKjhHF8=.907bdb15-2e2e-4f84-8fe4-ea4ed50534cd@github.com>
 <DR2YKv3VavKKD-cpFyf6mCSYfaKq0KAGh2XDqBStkys=.895ba671-f63a-4ba3-b042-6568d647b4ab@github.com>
 <mkn_t3hsL4mlCOfO5ahZOMbp8i_LMOHwJALA_bNjHIk=.d8031a91-ed13-4882-925f-ea8a9e634198@github.com>
 <3JzF7OkemZ-Lxc4jZgdEh3qNDzW8wF7ITeq-s7_TOlo=.11e4e40b-b775-47cf-9862-735fbc61ffd3@github.com>
 <iPK64Jh4aJtfqoPDqADOBN8BczKet53bod5y_VjZoBw=.fed662e8-2b40-478b-a9de-4906c0a897dc@github.com>
 <3kV3qhFRXBadf7Tol9n0Yomud_ndV_T_p7ShUfk4eVE=.d7151a63-0066-4020-b0ef-bae0d03dc133@github.com>
 <WhvzLc5GEYMSBz9jYgaRDBTbpaZGFWPHqzdfYHa-W6Q=.8efc48fe-6ae2-4608-ba4c-136df49c3707@github.com>
Message-ID: <Rb6cPrJ-LEz3AupzI7Zp2pCC4tXfilcve_dxhRzBHps=.7dd76a96-035e-49ba-b3a3-df73f9a42e09@github.com>

On Fri, 16 Oct 2020 19:22:16 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> I just want to note that if you have a `Reference<SomeType> ref` at hand, you can not just do:
>> Referemce<Object> r = (Reference<Object>) ref;
>> ...since those generic types are not related. You have to do something like:
>> 
>> @SuppressWarnings({"unchecked", "rawtypes"})
>> Referemce<Object> r = (Reference) ref;
>> which is very unfortunate. Comparing this method with for example `Collection.contains(Object element)`, you can see that Collection API has made a decision to not bother with T here. That was also due to keeping old code compatible when migrating from pre-generics Java to generified Collection, but as @dfuch noted, we have a migration story here too. We will be migrating `obj == ref.get()` to `ref.refersTo(obj)` ... Mind you that this is a boolean expression fragment which might be written inline surrounded with other parts of expression. So you'll be forced to split that into assignment with @SuppressWarnings and an expression or you will have to force the whole expression or method to @SuppressWarnings. I don't know if type "safety" is forth it here.
>
> Reference instances should not be leaked and so I don't see very common that caller of `Reference::get` does not know the referent's type.   It also depends on the `refersTo` check against `null` vs an object.  Any known use case would be helpful if any (some existing code that wants to call `refersTo` to compare a `Reference` of raw type with an object of unknown type).
> 
> FWIW, when converting a few use of `Reference::get` to `refersTo` in JDK, there is only one case (`equals(Object o)` method that needs the cast.
> 
> http://cr.openjdk.java.net/~mchung/jdk15/webrevs/8188055/jdk-use-refersTo/index.html

@mlchung I don't have many known use cases, but how about WeakHashMap.containsKey(Object key) for example? Currently `WeakHashMap.Entry<K, V> extends  WeakReference<Object>` but it would be more type safe if it extended `WeakReference<K>`. In that case an `entry.refersTo(key)` would not work...

-------------

PR: https://git.openjdk.java.net/jdk/pull/498

From prr at openjdk.java.net  Sat Oct 24 23:14:34 2020
From: prr at openjdk.java.net (Phil Race)
Date: Sat, 24 Oct 2020 23:14:34 GMT
Subject: RFR: 8255299: Drop explicit zeroing at instantiation of Atomic*
 objects
In-Reply-To: <Bc1YybkJpxM06gYYRRaXsWlYOgf0iDwdw6MyPCiOUuY=.76053af0-dccd-4b14-8729-193daa70b091@github.com>
References: <Bc1YybkJpxM06gYYRRaXsWlYOgf0iDwdw6MyPCiOUuY=.76053af0-dccd-4b14-8729-193daa70b091@github.com>
Message-ID: <eHVhVLFsHyakMwEZ-2ich-_YunMibTtXssoIObYxSGs=.6dee1d6d-d10f-412d-adbf-be23c84142a7@github.com>

On Thu, 22 Oct 2020 20:46:15 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

> As discussed in https://github.com/openjdk/jdk/pull/510 there is never a reason to explicitly instantiate any instance of `Atomic*` class with its default value, i.e. `new AtomicInteger(0)` could be replaced with `new AtomicInteger()` which is faster:
> @State(Scope.Thread)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> @BenchmarkMode(value = Mode.AverageTime)
> public class AtomicBenchmark {
>   @Benchmark
>   public Object defaultValue() {
>     return new AtomicInteger();
>   }
>   @Benchmark
>   public Object explicitValue() {
>     return new AtomicInteger(0);
>   }
> }
> THis benchmark demonstrates that `explicitValue()` is much slower:
> Benchmark                      Mode  Cnt   Score   Error  Units
> AtomicBenchmark.defaultValue   avgt   30   4.778 ? 0.403  ns/op
> AtomicBenchmark.explicitValue  avgt   30  11.846 ? 0.273  ns/op
> So meanwhile https://bugs.openjdk.java.net/browse/JDK-8145948 is still in progress we could trivially replace explicit zeroing with default constructors gaining some performance benefit with no risk.
> 
> I've tested the changes locally, both tier1 and tier 2 are ok. 
> 
> Could one create an issue for tracking this?

client changes are fine

-------------

Marked as reviewed by prr (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/818

From github.com+11685886+marcono1234 at openjdk.java.net  Sun Oct 25 00:03:39 2020
From: github.com+11685886+marcono1234 at openjdk.java.net (Marcono1234)
Date: Sun, 25 Oct 2020 00:03:39 GMT
Subject: RFR: 8253459: Formatter treats index,
 width and precision > Integer.MAX_VALUE incorrectly [v5]
In-Reply-To: <4unPdZ6ip7WjZYg3AK-wZg6YTJBGlXN0XB2h8dlgyQc=.2e232f34-269d-4021-999d-fc43ecc3391b@github.com>
References: <3aYgWcp1IVMM0vQT5UMLSnc2JA1uK9cbtRe283RF37g=.fc2049ef-cdbe-4948-a24b-fdb88cc87a1c@github.com>
 <4unPdZ6ip7WjZYg3AK-wZg6YTJBGlXN0XB2h8dlgyQc=.2e232f34-269d-4021-999d-fc43ecc3391b@github.com>
Message-ID: <z3-ad0CCqit3JCQpg6828aIZRIgyXmxGlZhwRBMDfJw=.06f30db9-acc5-4184-bd92-db0cf46f82d8@github.com>

On Thu, 15 Oct 2020 19:20:28 GMT, Ian Graves <igraves at openjdk.org> wrote:

>> The `java.util.Formatter` format specifies support for field widths, argument indexes, or precision lengths of a field that relate to the variadic arguments supplied to the formatter. These numbers are specified by integers, sometimes negative. For argument index, it's specified in the documentation that the highest allowed argument is limited by the largest possible index of an array (ie the largest possible variadic index), but for the other two it's not defined. Moreover, what happens when a number field in a string is too large or too small to be represented by a 32-bit integer type is not defined.
>> 
>> This fix adds documentation to specify what error behavior occurs during these cases. Additionally it adds an additional exception type to throw when an invalid argument index is observed.
>> 
>> A CSR will be required for this PR.
>
> Ian Graves has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Additional specificity around width

Maybe it would be cleaner for `IllegalFormatArgumentIndexException`, `IllegalFormatWidthException` and `IllegalFormatPrecisionException` to provide no-arg constructors (which use `Integer.MIN_VALUE` as value) for the cases where the value cannot be represented.

Are you also planning to add some tests? That would probably be useful.

And would it be necessary to mention the exception for `index=0` in the release notes? I am personally a little bit afraid that there is code out there which uses it (since indices starting with 0 is not that uncommon). For example when someone used only one format specifier but wanted to be explicit, then a value of 0 would not have caused any issues for them in the past.

For what it's worth, personally I prefer having a separate exception type (`IllegalFormatArgumentIndexException`) to make it consistent with the other exceptions. The large number of exception types might not be ideal, especially since the user likely rarely needs to differentiate between them, but this pattern was chosen back then and it makes sense to stick to it now.

Might also be good to make the documentation for `getIndex()`, `getPrecision()` and `getWidth()` more consistent:
- `getIndex()`:
  - Starts with "Gets the ..."
  - "Returns ... if not ..."
- `getPrecision()`:
  - Starts with "Returns the ..."
  - "If the ... isn't ... will return"
- `getWidth()`:
  - Starts with "Returns the ..."
  - "If the ... is not ... then returns"

----

Note that I am neither an OpenJDK contributor nor have I signed the Terms of Use. Please let me know if should stop bothering you on this pull request.

src/java.base/share/classes/java/util/Formatter.java line 708:

> 706:  * <p> Values of <i>width</i> must be in the range one to
> 707:  * {@link Integer#MAX_VALUE}, inclusive, otherwise
> 708:  * {@link IllegalFormatWidthException} will be thrown

Missing period.
Suggestion:

 * {@link IllegalFormatWidthException} will be thrown.

src/java.base/share/classes/java/util/Formatter.java line 711:

> 709:  * Note that widths can appear to have a negative value, but the negative sign
> 710:  * is a <i>flag</i>. For example in the format string {@code "%-20s"} the
> 711:  * <i>width</i> is <i>20</i> and the <i>flag</i> is "-".</p>

Should the `"-"` here be formatted either as italic (to match the `<i>20</i>`; though not sure if italic is really needed there in the first place) or as code?

src/java.base/share/classes/java/util/Formatter.java line 2802:

> 2800:                     // skip the trailing '$'
> 2801:                     index = Integer.parseInt(s, start, end - 1, 10);
> 2802:                     if(index <= 0) {

Suggestion:

                    if (index <= 0) {

src/java.base/share/classes/java/util/IllegalFormatArgumentIndexException.java line 32:

> 30:  * range of supported argument index values. If an index value isn't
> 31:  * representable by an {@code int} type, then the value
> 32:  * {@code Integer.MIN_VALUE} will be used in the exception.

Maybe use a `{@link ...}` to make it easier for the reader of the documentation?

src/java.base/share/classes/java/util/IllegalFormatArgumentIndexException.java line 53:

> 51:     /**
> 52:      * Gets the value of the illegal index.
> 53:      * Returns {@code Integer.MIN_VALUE} if the illegal index is not

Maybe use a `{@link ...}` to make it easier for the reader of the documentation?

src/java.base/share/classes/java/util/IllegalFormatPrecisionException.java line 32:

> 30:  * {@code -1}, the conversion does not support a precision, or the value is
> 31:  * otherwise unsupported. If the precision is not representable by an
> 32:  * {@code int} type, then the value {@code Integer.MIN_VALUE} will be used

Maybe use a `{@link ...}` to make it easier for the reader of the documentation?

src/java.base/share/classes/java/util/IllegalFormatPrecisionException.java line 56:

> 54:     /**
> 55:      * Returns the precision. If the precision isn't representable by an
> 56:      * integer type, then will return {@code Integer.MIN_VALUE}.

Maybe use a `{@link ...}` to make it easier for the reader of the documentation?

src/java.base/share/classes/java/util/IllegalFormatPrecisionException.java line 56:

> 54:     /**
> 55:      * Returns the precision. If the precision isn't representable by an
> 56:      * integer type, then will return {@code Integer.MIN_VALUE}.

Suggestion:

     * {@code int} type, then will return {@code Integer.MIN_VALUE}.
To be consistent with other documentation and to be more explicit (`long` could also be understood as integer type).

src/java.base/share/classes/java/util/IllegalFormatWidthException.java line 54:

> 52: 
> 53:     /**
> 54:      * Returns the width. If the width is not representable by an integer type,

Suggestion:

     * Returns the width. If the width is not representable by an {@code int} type,
To be consistent with other documentation and to be more explicit (`long` could also be understood as integer type).

src/java.base/share/classes/java/util/IllegalFormatWidthException.java line 32:

> 30:  * than {@code -1} or is otherwise unsupported. If a given format width is not
> 31:  * representable by an {@code int} type, then the value
> 32:  * {@code Integer.MIN_VALUE} will be used in the exception.

Maybe use a `{@link ...}` to make it easier for the reader of the documentation?

src/java.base/share/classes/java/util/IllegalFormatWidthException.java line 55:

> 53:     /**
> 54:      * Returns the width. If the width is not representable by an integer type,
> 55:      * then returns {@code Integer.MIN_VALUE}.

Maybe use a `{@link ...}` to make it easier for the reader of the documentation?

src/java.base/share/classes/java/util/IllegalFormatPrecisionException.java line 30:

> 28: /**
> 29:  * Unchecked exception thrown when the precision is a negative value other than
> 30:  * {@code -1}, the conversion does not support a precision, or the value is

-1 being used by `java.util.Formatter.FormatSpecifier.precision(String, int, int)` as default value is in my opinion an implementation detail and should not be part of this documentation.

src/java.base/share/classes/java/util/IllegalFormatWidthException.java line 30:

> 28: /**
> 29:  * Unchecked exception thrown when the format width is a negative value other
> 30:  * than {@code -1} or is otherwise unsupported. If a given format width is not

-1 being used by `java.util.Formatter.FormatSpecifier.width(String, int, int)` as default value is in my opinion an implementation detail and should not be part of this documentation.

src/java.base/share/classes/java/util/IllegalFormatArgumentIndexException.java line 52:

> 50: 
> 51:     /**
> 52:      * Gets the value of the illegal index.

Maybe drop "illegal" here, for `@return` and for the constructor, or (preferred) add it to the existing `IllegalFormatPrecisionException` and `IllegalFormatWidthException` getter and constructor documentation for consistency.

src/java.base/share/classes/java/util/Formatter.java line 2802:

> 2800:                     // skip the trailing '$'
> 2801:                     index = Integer.parseInt(s, start, end - 1, 10);
> 2802:                     if(index <= 0) {

Note that the `java.util.Formatter.formatSpecifier` pattern does not permit a `-` in the first place, so maybe throwing an `AssertionError` would be more appropriate?

Same applies to `width` and `precision`.

src/java.base/share/classes/java/util/Formatter.java line 713:

> 711:  * <i>width</i> is <i>20</i> and the <i>flag</i> is "-".</p>
> 712:  *
> 713:  * <p> Values of <i>index</i> must be in the range one to

Suggestion:

 * <p> Values of <i>index</i> must be in the range 1 to
Maybe write a number here to make it faster to read.

-------------

PR: https://git.openjdk.java.net/jdk/pull/516

From winterhalter at openjdk.java.net  Sun Oct 25 08:33:52 2020
From: winterhalter at openjdk.java.net (Rafael Winterhalter)
Date: Sun, 25 Oct 2020 08:33:52 GMT
Subject: RFR: 8202471: Make type annotations on owner type parameters
 available [v2]
In-Reply-To: <WJVy8_XXMJf5UOCifoPHUc06qVaU2MKlT_oosLaiqwg=.c2b16a91-64ce-4468-991c-a51ffd6b3202@github.com>
References: <WJVy8_XXMJf5UOCifoPHUc06qVaU2MKlT_oosLaiqwg=.c2b16a91-64ce-4468-991c-a51ffd6b3202@github.com>
Message-ID: <KXmba4m_QdYJqAR6u8LYtskE1hxLxLNe2FA8PSqqqsA=.dfd56459-ad73-4786-80d0-861451702566@github.com>

> A method's or constructor's owner type might carry annotations on its potential type parameters but is never represented as parameterized type what makes these parameters inaccessible at runtime, despite the presence of parameter type annotations.

Rafael Winterhalter has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  8202471: A method's or constructor's owner type might carry annotations on its potential type parameters but is never represented as parameterized type what makes these parameters inaccessible at runtime, despite the presence of parameter type annotations.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/851/files
  - new: https://git.openjdk.java.net/jdk/pull/851/files/864971ea..7721c77b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=851&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=851&range=00-01

  Stats: 2 lines in 2 files changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/851.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/851/head:pull/851

PR: https://git.openjdk.java.net/jdk/pull/851

From naoto at openjdk.java.net  Sun Oct 25 18:26:38 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Sun, 25 Oct 2020 18:26:38 GMT
Subject: Integrated: 8255242: Bidi.requiresBidi has misleading exception
 message
In-Reply-To: <kWuUHntyhKCkveE28ApQtbYHnSYDHnB08E8vQ-8xmWM=.c0ff3e04-39cb-478f-88ad-27f282a43c5f@github.com>
References: <kWuUHntyhKCkveE28ApQtbYHnSYDHnB08E8vQ-8xmWM=.c0ff3e04-39cb-478f-88ad-27f282a43c5f@github.com>
Message-ID: <DoIutq83yMM1hSHY4wf9IprK-JkHdtHGNI2mhiCxpb8=.c54a7089-9b17-4b3e-a0c9-1966f538f9a8@github.com>

On Fri, 23 Oct 2020 16:48:03 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Hi,
> 
> Please review this small exception message fix.
> 
> Naoto

This pull request has now been integrated.

Changeset: 57d903bd
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/57d903bd
Stats:     10 lines in 2 files changed: 7 ins; 0 del; 3 mod

8255242: Bidi.requiresBidi has misleading exception message

Reviewed-by: bchristi

-------------

PR: https://git.openjdk.java.net/jdk/pull/841

From shade at openjdk.java.net  Mon Oct 26 07:17:37 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 26 Oct 2020 07:17:37 GMT
Subject: Integrated: 8255343: java/util/stream/SpliteratorTest.java fails on
 32-bit platforms with "Misaligned access at address: 12"
In-Reply-To: <u2rAhd6_2bIHcD9WO3ga_7BngWJ8PJLhK4hqqxdWh68=.922c46fe-db5b-434b-919b-864011cd8ac5@github.com>
References: <u2rAhd6_2bIHcD9WO3ga_7BngWJ8PJLhK4hqqxdWh68=.922c46fe-db5b-434b-919b-864011cd8ac5@github.com>
Message-ID: <HWZ14tr6Egx4O8MidnsudDXkQNXRqz3xtk4KzkYOOU8=.f258f6e6-ac1d-4a8a-9664-49ec3dcc6c80@github.com>

On Fri, 23 Oct 2020 12:37:10 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> It currently fails on x86_32 with `java.lang.IllegalStateException: Misaligned access at address: 12`. I checked that once JDK-8254162 integrates, that issue is gone. Until then, having clean x86_32 testing is beneficial for other work.
> 
> Testing:
>  - [x] `java/util/stream` tests on Linux x86_64 (still passes)
>  - [x] `java/util/stream` tests on Linux x86_32 (start to pass)

This pull request has now been integrated.

Changeset: c28b0111
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c28b0111
Stats:     6 lines in 1 file changed: 0 ins; 0 del; 6 mod

8255343: java/util/stream/SpliteratorTest.java fails on 32-bit platforms with "Misaligned access at address: 12"

Co-authored-by: Maurizio Cimadamore <mcimadamore at openjdk.org>
Reviewed-by: mcimadamore

-------------

PR: https://git.openjdk.java.net/jdk/pull/836

From shade at openjdk.java.net  Mon Oct 26 07:43:35 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 26 Oct 2020 07:43:35 GMT
Subject: RFR: 8255331: Problemlist java/foreign/TestMismatch.java on
 32-bit platforms until JDK-8254162
In-Reply-To: <lUlNsYKk9fdZ5mWeJunYiLK6R2zx-7QbvKB3L3H-HDo=.f3f93e84-86a8-47f3-9540-c4c367c73e1f@github.com>
References: <lUlNsYKk9fdZ5mWeJunYiLK6R2zx-7QbvKB3L3H-HDo=.f3f93e84-86a8-47f3-9540-c4c367c73e1f@github.com>
Message-ID: <-uYRWyx_pto4dbdQkscW7L0cypuOUzpLdsI42IT1bro=.2950671f-6cda-47dd-901e-66448976a73e@github.com>

On Fri, 23 Oct 2020 10:42:14 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I would like to have clean x86_32 test runs until JDK-8254162 arrives.
> 
> Testing:
>   - [x] Affected test on Linux x86_64 (still passes)
>   - [x] Affected test on Linux x86_32 (now ignored)

@mcimadamore, please take a look? This seems to be the only thing that keeps `x86_32` `tier1` from being clean. I think you'd need to remove this test from the problem list with/after JDK-8254162 integration.

-------------

PR: https://git.openjdk.java.net/jdk/pull/833

From ihse at openjdk.java.net  Mon Oct 26 09:14:41 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Mon, 26 Oct 2020 09:14:41 GMT
Subject: RFR: 8254162: Implementation of Foreign-Memory Access API (Third
 Incubator) [v13]
In-Reply-To: <TUZ_G4CzBA8tf0NgODaBk2p3S9Q0U_2ORYzIiqblUB8=.b7c38d3a-167f-4ad6-9816-f8e14baf4075@github.com>
References: <IngRk57F78UN3yySfo6IABbdwnMogGNdYrykh_3em-c=.b81f7478-015c-45ed-9788-58d7519a2770@github.com>
 <TUZ_G4CzBA8tf0NgODaBk2p3S9Q0U_2ORYzIiqblUB8=.b7c38d3a-167f-4ad6-9816-f8e14baf4075@github.com>
Message-ID: <rMgWA4zEJRFaXSsH30hQixWWDnum355oXbs041CvTX8=.f1ff3bec-9fd3-43db-977e-c414f4273d08@github.com>

On Mon, 19 Oct 2020 10:34:32 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This patch contains the changes associated with the third incubation round of the foreign memory access API incubation  (see JEP 393 [1]). This iteration focus on improving the usability of the API in 3 main ways:
>> 
>> * first, by providing a way to obtain truly *shared* segments, which can be accessed and closed concurrently from multiple threads
>> * second, by providing a way to register a memory segment against a `Cleaner`, so as to have some (optional) guarantee that the memory will be deallocated, eventually
>> * third, by not requiring users to dive deep into var handles when they first pick up the API; a new `MemoryAccess` class has been added, which defines several useful dereference routines; these are really just thin wrappers around memory access var handles, but they make the barrier of entry for using this API somewhat lower.
>> 
>> A big conceptual shift that comes with this API refresh is that the role of `MemorySegment` and `MemoryAddress` is not the same as it used to be; it used to be the case that a memory address could (sometimes, not always) have a back link to the memory segment which originated it; additionally, memory access var handles used `MemoryAddress` as a basic unit of dereference.
>> 
>> This has all changed as per this API refresh;  now a `MemoryAddress` is just a dumb carrier which wraps a pair of object/long addressing coordinates; `MemorySegment` has become the star of the show, as far as dereferencing memory is concerned. You cannot dereference memory if you don't have a segment. This improves usability in a number of ways - first, it is a lot easier to wrap native addresses (`long`, essentially) into a `MemoryAddress`; secondly, it is crystal clear what a client has to do in order to dereference memory: if a client has a segment, it can use that; otherwise, if the client only has an address, it will have to create a segment *unsafely* (this can be done by calling `MemoryAddress::asSegmentRestricted`).
>> 
>> A list of the API, implementation and test changes is provided below. If  you have any questions, or need more detailed explanations, I (and the  rest of the Panama team) will be happy to point at existing discussions,  and/or to provide the feedback required. 
>> 
>> A big thank to Erik Osterlund, Vladimir Ivanov and David Holmes, without whom the work on shared memory segment would not have been possible; also I'd like to thank Paul Sandoz, whose insights on API design have been very helpful in this journey.
>> 
>> Thanks 
>> Maurizio 
>> 
>> Javadoc: 
>> 
>> http://cr.openjdk.java.net/~mcimadamore/8254162_v1/javadoc/jdk/incubator/foreign/package-summary.html
>> 
>> Specdiff: 
>> 
>> http://cr.openjdk.java.net/~mcimadamore/8254162_v1/specdiff/jdk/incubator/foreign/package-summary.html
>> 
>> CSR: 
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8254163
>> 
>> 
>> 
>> ### API Changes
>> 
>> * `MemorySegment`
>>   * drop factory for restricted segment (this has been moved to `MemoryAddress`, see below)
>>   * added a no-arg factory for a native restricted segment representing entire native heap
>>   * rename `withOwnerThread` to `handoff`
>>   * add new `share` method, to create shared segments
>>   * add new `registerCleaner` method, to register a segment against a cleaner
>>   * add more helpers to create arrays from a segment e.g. `toIntArray`
>>   * add some `asSlice` overloads (to make up for the fact that now segments are more frequently used as cursors)
>>   * rename `baseAddress` to `address` (so that `MemorySegment` can implement `Addressable`)
>> * `MemoryAddress`
>>   * drop `segment` accessor
>>   * drop `rebase` method and replace it with `segmentOffset` which returns the offset (a `long`) of this address relative to a given segment
>> * `MemoryAccess`
>>   * New class supporting several static dereference helpers; the helpers are organized by carrier and access mode, where a carrier is one of the usual suspect (a Java primitive, minus `boolean`); the access mode can be simple (e.g. access base address of given segment), or indexed, in which case the accessor takes a segment and either a low-level byte offset,or a high level logical index. The classification is reflected in the naming scheme (e.g. `getByte` vs. `getByteAtOffset` vs `getByteAtIndex`).
>> * `MemoryHandles`
>>   * drop `withOffset` combinator
>>   * drop `withStride` combinator
>>   * the basic memory access handle factory now returns a var handle which takes a `MemorySegment` and a `long` - from which it is easy to derive all the other handles using plain var handle combinators.
>> * `Addressable`
>>   * This is a new interface which is attached to entities which can be projected to a `MemoryAddress`. For now, both `MemoryAddress` and `MemorySegment` implement it; we have plans, with JEP 389 [2] to add more implementations. Clients can largely ignore this interface, which comes in really handy when defining native bindings with tools like `jextract`.
>> * `MemoryLayouts`
>>   * A new layout, for machine addresses, has been added to the mix.
>> 
>> 
>> 
>> ### Implementation changes
>> 
>> There are two main things to discuss here: support for shared segments, and the general simplification of the memory access var handle support.
>> 
>> #### Shared segments
>> 
>> The support for shared segments cuts in pretty deep in the VM. Support for shared segments is notoriously hard to achieve, at least in a way that guarantees optimal access performances. This is caused by the fact that, if a segment is shared, it would be possible for a thread to close it while another is accessing it.
>> 
>> After considering several options (see [3]), we zeroed onto an approach which is inspired by an happy idea that Andrew Haley had (and that he reminded me of at this year OpenJDK committer workshop - thanks!). The idea is that if we could *freeze* the world (e.g. with a GC pause), while a segment is closed, we could then prevent segments from being accessed concurrently to a close operation. For this to work, it  is crucial that no GC safepoints can occur between a segment liveness check and the access itself (otherwise it would be possible for the accessing thread to stop just right before an unsafe call). It also relies on the fact that hotspot/C2 should not be able to propagate loads across safepoints.
>> 
>> Sadly, none of these conditions seems to be valid in the current implementation, so we needed to resort to a bit of creativity. First, we noted that, if we could mark so called *scoped* method with an annotation, it would be very simply to check as to whether a thread was in the middle of a scoped method when we stopped the world for a close operation (btw, instead of stopping the world, we do a much more efficient, thread-local polling, thanks to JEP 312 [4]).
>> 
>> The question is, then, once we detect that a thread is accessing the very segment we're about to close, what should happen? We first experimented with a solution which would install an *asynchronous* exception on the accessing thread, thus making it fail. This solution has some desirable properties, in that a `close` operation always succeeds. Unfortunately the machinery for async exceptions is a bit fragile (e.g. not all the code in hotspot checks for async exceptions); to minimize risks, we decided to revert to a simpler strategy, where `close` might fail when it finds that another thread is accessing the segment being closed.
>> 
>> As written in the javadoc, this doesn't mean that clients should just catch and try again; an exception on `close` is a bug in the user code, likely arising from lack of synchronization, and should be treated as such.
>> 
>> In terms of gritty implementation, we needed to centralize memory access routines in a single place, so that we could have a set of routines closely mimicking the primitives exposed by `Unsafe` but which, in addition, also provided a liveness check. This way we could mark all these routines with the special `@Scoped` annotation, which tells the VM that something important is going on.
>> 
>> To achieve this, we created a new (autogenerated) class, called `ScopedMemoryAccess`. This class contains all the main memory access primitives (including bulk access, like `copyMemory`, or `setMemory`), and accepts, in addition to the access coordinates, also a scope object, which is tested before access. A reachability fence is also thrown in the mix to make sure that the scope is kept alive during access (which is important when registering segments against cleaners).
>> 
>> Of course, to make memory access safe, memory access var handles, byte buffer var handles, and byte buffer API should use the new `ScopedMemoryAccess` class instead of unsafe, so that a liveness check can be triggered (in case a scope is present).
>> 
>> `ScopedMemoryAccess` has a `closeScope` method, which initiates the thread-local handshakes, and returns `true` if the handshake completed successfully.
>> 
>> The implementation of `MemoryScope` (now significantly simplified from what we had before), has two implementations, one for confined segments and one for shared segments; the main difference between the two is what happens when the scope is closed; a confined segment sets a boolean flag to false, and returns, whereas a shared segment goes into a `CLOSING` state, then starts the handshake, and then updates the state again, to either `CLOSED` or `ALIVE` depending on whether the handshake was successful or not. Note that when a shared segment is in the `CLOSING` state, `MemorySegment::isAlive` will still return `true`, while the liveness check upon memory access will fail.
>> 
>> #### Memory access var handles overhaul
>> 
>> The key realization here was that if all memory access var handles took a coordinate pair of `MemorySegment` and `long`, all other access types could be derived from this basic var handle form.
>> 
>> This allowed us to remove the on-the-fly var handle generation, and to simply derive structural access var handles (such as those obtained by calling `MemoryLayout::varHandle`) using *plain* var handle combinators, so that e.g. additional offset is injected into a base memory access var handle.
>> 
>> This also helped in simplifying the implementation by removing the special `withStride` and `withOffset` combinators, which previously needed low-level access on the innards of the memory access var handle. All that code is now gone.
>> 
>> #### Test changes
>> 
>> Not much to see here - most of the tests needed to be updated because of the API changes. Some were beefed up (like the array test, since now segments can be projected into many different kinds of arrays). A test has been added to test the `Cleaner` functionality, and another stress test has been added for shared segments (`TestHandshake`). Some of the microbenchmarks also needed some tweaks - and some of them were also updated to also test performance in the shared segment case.
>> 
>> [1] - https://openjdk.java.net/jeps/393
>> [2] - https://openjdk.java.net/jeps/389
>> [3] - https://mail.openjdk.java.net/pipermail/panama-dev/2020-May/009004.html
>> [4] - https://openjdk.java.net/jeps/312
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address CSR comments

Changes requested by ihse (Reviewer).

make/modules/java.base/gensrc/GensrcScopedMemoryAccess.gmk line 148:

> 146: 	
> 147: $(DEST): $(BUILD_TOOLS_JDK) $(SCOPED_MEMORY_ACCESS_TEMPLATE) $(SCOPED_MEMORY_ACCESS_BIN_TEMPLATE)
> 148: 	$(MKDIR) -p $(SCOPED_MEMORY_ACCESS_GENSRC_DIR)

Please use `$(call MakeDir, $(SCOPED_MEMORY_ACCESS_GENSRC_DIR))` instead.

make/modules/java.base/gensrc/GensrcScopedMemoryAccess.gmk line 34:

> 32: SCOPED_MEMORY_ACCESS_TEMPLATE := $(SCOPED_MEMORY_ACCESS_SRC_DIR)/X-ScopedMemoryAccess.java.template
> 33: SCOPED_MEMORY_ACCESS_BIN_TEMPLATE := $(SCOPED_MEMORY_ACCESS_SRC_DIR)/X-ScopedMemoryAccess-bin.java.template
> 34: DEST := $(SCOPED_MEMORY_ACCESS_GENSRC_DIR)/ScopedMemoryAccess.java

`DEST` is a very generic and not really informative name. Maybe `SCOPED_MEMORY_ACCESS_GENSRC_DEST` to fit in with the rest of the names?

And/or, maybe, to cut down on the excessive length, shorten `SCOPED_MEMORY_ACCESS` to `SMA` in all variables.

make/modules/java.base/gensrc/GensrcScopedMemoryAccess.gmk line 26:

> 24: #
> 25: 
> 26: GENSRC_SCOPED_MEMORY_ACCESS :=

This variable does not seem to be used. A left-over from previous iterations?

Also, please cut down a bit on the consecutive empty lines.

-------------

PR: https://git.openjdk.java.net/jdk/pull/548

From ihse at openjdk.java.net  Mon Oct 26 09:19:37 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Mon, 26 Oct 2020 09:19:37 GMT
Subject: RFR: 8254231: Implementation of Foreign Linker API (Incubator)
 [v12]
In-Reply-To: <2IKx6cpc-IGP3jZtr0s2I14BWM6ptyFD26szPl3b1ng=.9d956b98-dfe6-4a45-a371-bf86923214fb@github.com>
References: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
 <2IKx6cpc-IGP3jZtr0s2I14BWM6ptyFD26szPl3b1ng=.9d956b98-dfe6-4a45-a371-bf86923214fb@github.com>
Message-ID: <dubhIH90Lgeb2e_ZyjUvBeT3dk7OIn9wWIYUZ6v_wmE=.89e732bb-4d08-4f8f-8551-196867810e9d@github.com>

On Thu, 22 Oct 2020 17:04:34 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This patch contains the changes associated with the first incubation round of the foreign linker access API incubation
>> (see JEP 389 [1]). This work is meant to sit on top of the foreign memory access support (see JEP 393 [2] and associated pull request [3]).
>> 
>> The main goal of this API is to provide a way to call native functions from Java code without the need of intermediate JNI glue code. In order to do this, native calls are modeled through the MethodHandle API. I suggest reading the writeup [4] I put together few weeks ago, which illustrates what the foreign linker support is, and how it should be used by clients.
>> 
>> Disclaimer: the pull request mechanism isn't great at managing *dependent* reviews. For this reasons, I'm attaching a webrev which contains only the differences between this PR and the memory access PR. I will be periodically uploading new webrevs, as new iterations come out, to try and make the life of reviewers as simple as possible.
>> 
>> A big thank to Jorn Vernee and Vladimir Ivanov - they are the main architects of all the hotspot changes you see here, and without their help, the foreign linker support wouldn't be what it is today. As usual, a big thank to Paul Sandoz, who provided many insights (often by trying the bits first hand).
>> 
>> Thanks
>> Maurizio
>> 
>> Webrev:
>> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/webrev
>> 
>> Javadoc:
>> 
>> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/javadoc/jdk/incubator/foreign/package-summary.html
>> 
>> Specdiff (relative to [3]):
>> 
>> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/specdiff_delta/overview-summary.html
>> 
>> CSR:
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8254232
>> 
>> 
>> 
>> ### API Changes
>> 
>> The API changes are actually rather slim:
>> 
>> * `LibraryLookup`
>>   * This class allows clients to lookup symbols in native libraries; the interface is fairly simple; you can load a library by name, or absolute path, and then lookup symbols on that library.
>> * `FunctionDescriptor`
>>   * This is an abstraction that is very similar, in spirit, to `MethodType`; it is, at its core, an aggregate of memory layouts for the function arguments/return type. A function descriptor is used to describe the signature of a native function.
>> * `CLinker`
>>   * This is the real star of the show. A `CLinker` has two main methods: `downcallHandle` and `upcallStub`; the first takes a native symbol (as obtained from `LibraryLookup`), a `MethodType` and a `FunctionDescriptor` and returns a `MethodHandle` instance which can be used to call the target native symbol. The second takes an existing method handle, and a `FunctionDescriptor` and returns a new `MemorySegment` corresponding to a code stub allocated by the VM which acts as a trampoline from native code to the user-provided method handle. This is very useful for implementing upcalls.
>>    * This class also contains the various layout constants that should be used by clients when describing native signatures (e.g. `C_LONG` and friends); these layouts contain additional ABI classfication information (in the form of layout attributes) which is used by the runtime to *infer* how Java arguments should be shuffled for the native call to take place.
>>   * Finally, this class provides some helper functions e.g. so that clients can convert Java strings into C strings and back.
>> * `NativeScope`
>>   * This is an helper class which allows clients to group together logically related allocations; that is, rather than allocating separate memory segments using separate *try-with-resource* constructs, a `NativeScope` allows clients to use a _single_ block, and allocate all the required segments there. This is not only an usability boost, but also a performance boost, since not all allocation requests will be turned into `malloc` calls.
>> * `MemorySegment`
>>   * Only one method added here - namely `handoff(NativeScope)` which allows a segment to be transferred onto an existing native scope.
>> 
>> ### Safety
>> 
>> The foreign linker API is intrinsically unsafe; many things can go wrong when requesting a native method handle. For instance, the description of the native signature might be wrong (e.g. have too many arguments) - and the runtime has, in the general case, no way to detect such mismatches. For these reasons, obtaining a `CLinker` instance is a *restricted* operation, which can be enabled by specifying the usual JDK property `-Dforeign.restricted=permit` (as it's the case for other restricted method in the foreign memory API).
>> 
>> ### Implementation changes
>> 
>> The Java changes associated with `LibraryLookup` are relative straightforward; the only interesting thing to note here is that library loading does _not_ depend on class loaders, so `LibraryLookup` is not subject to the same restrictions which apply to JNI library loading (e.g. same library cannot be loaded by different classloaders).
>> 
>> As for `NativeScope` the changes are again relatively straightforward; it is an API which sits neatly on top of the foreign meory access API, providing some kind of allocation service which shares the same underlying memory segment(s), and turns an allocation request into a segment slice, which is a much less expensive operation. `NativeScope` comes in two variants: there are native scopes for which the allocation size is known a priori, and native scopes which can grow - these two schemes are implemented by two separate subclasses of `AbstractNativeScopeImpl`.
>> 
>> Of course the bulk of the changes are to support the `CLinker` downcall/upcall routines. These changes cut pretty deep into the JVM; I'll briefly summarize the goal of some of this changes - for further details, Jorn has put together a detailed writeup which explains the rationale behind the VM support, with some references to the code [5].
>> 
>> The main idea behind foreign linker is to infer, given a Java method type (expressed as a `MethodType` instance) and the description of the signature of a native function (expressed as a `FunctionDescriptor` instance) a _recipe_ that can be used to turn a Java call into the corresponding native call targeting the requested native function.
>> 
>> This inference scheme can be defined in a pretty straightforward fashion by looking at the various ABI specifications (for instance, see [6] for the SysV ABI, which is the one used on Linux/Mac). The various `CallArranger` classes, of which we have a flavor for each supported platform, do exactly that kind of inference.
>> 
>> For the inference process to work, we need to attach extra information to memory layouts; it is no longer sufficient to know e.g. that a layout is 32/64 bits - we need to know whether it is meant to represent a floating point value, or an integral value; this knowledge is required because floating points are passed in different registers by most ABIs. For this reason, `CLinker` offers a set of pre-baked, platform-dependent layout constants which contain the required classification attributes (e.g. a `Clinker.TypeKind` enum value). The runtime extracts this attribute, and performs classification accordingly.
>> 
>> A native call is decomposed into a sequence of basic, primitive operations, called `Binding` (see the great javadoc on the `Binding.java` class for more info). There are many such bindings - for instance the `Move` binding is used to move a value into a specific machine register/stack slot. So, the main job of the various `CallingArranger` classes is to determine, given a Java `MethodType` and `FunctionDescriptor` what is the set of bindings associated with the downcall/upcall.
>> 
>> At the heart of the foreign linker support is the `ProgrammableInvoker` class. This class effectively generates a `MethodHandle` which follows the steps described by the various bindings obtained by `CallArranger`. There are actually various strategies to interpret these bindings - listed below:
>> 
>> * basic intepreted mode; in this mode, all bindings are interpreted using a stack-based machine written in Java (see `BindingInterpreter`), except for the `Move` bindings. For these bindings, the move is implemented by allocating a *buffer* (whose size is ABI specific) and by moving all the lowered values into positions within this buffer. The buffer is then passed to a piece of assembly code inside the VM which takes values from the buffer and moves them in their expected registers/stack slots (note that each position in the buffer corresponds to a different register). This is the most general invocation mode, the more "customizable" one, but also the slowest - since for every call there is some extra allocation which takes place.
>> 
>> * specialized interpreted mode; same as before, but instead of interpreting the bindings with a stack-based interpreter, we generate a method handle chain which effectively interprets all the bindings (again, except `Move` ones).
>> 
>> * intrinsified mode; this is typically used in combination with the specialized interpreted mode described above (although it can also be used with the Java-based binding interpreter). The goal here is to remove the buffer allocation and copy by introducing an additional JVM intrinsic. If a native call recipe is constant (e.g. the set of bindings is constant, which is probably the case if the native method handle is stored in a `static`, `final` field), then the VM can generate specialized assembly code which interprets the `Move` binding without the need to go for an intermediate buffer. This gives us back performances that are on par with JNI.
>> 
>> For upcalls, the support is not (yet) as advanced, and only the basic interpreted mode is available there. We plan to add support for intrinsified modes there as well, which should considerably boost perfomances (probably well beyond what JNI can offer at the moment, since the upcall support in JNI is not very well optimized).
>> 
>> Again, for more readings on the internals of the foreign linker support, please refer to [5].
>> 
>> #### Test changes
>> 
>> Many new tests have been added to validate the foreign linker support; we have high level tests (see `StdLibTest`) which aim at testing the linker from the perspective of code that clients could write. But we also have deeper combinatorial tests (see `TestUpcall` and `TestDowncall`) which are meant to stress every corner of the ABI implementation. There are also some great tests (see the `callarranger` folder) which test the various `CallArranger`s for all the possible platforms; these tests adopt more of a white-box approach - that is, instead of treating the linker machinery as a black box and verify that the support works by checking that the native call returned the results we expected, these tests aims at checking that the set of bindings generated by the call arranger is correct. This also mean that we can test the classification logic for Windows, Mac and Linux regardless of the platform we're executing on.
>> 
>> Some additional microbenchmarks have been added to compare the performances of downcall/upcall with JNI.
>> 
>> [1] - https://openjdk.java.net/jeps/389
>> [2] - https://openjdk.java.net/jeps/393
>> [3] - https://git.openjdk.java.net/jdk/pull/548
>> [4] - https://github.com/openjdk/panama-foreign/blob/foreign-jextract/doc/panama_ffi.md
>> [5] - http://cr.openjdk.java.net/~jvernee/docs/Foreign-abi%20downcall%20intrinsics%20technical%20description.html
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix whitespaces

Marked as reviewed by ihse (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/634

From ihse at openjdk.java.net  Mon Oct 26 09:19:37 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Mon, 26 Oct 2020 09:19:37 GMT
Subject: RFR: 8254231: Implementation of Foreign Linker API (Incubator)
 [v12]
In-Reply-To: <ybSizkW2Zm-dcUIZs7e2HpdZeoUeOM303b4dwV9Ij78=.bc88047f-8a05-459f-9add-b37879a8e164@github.com>
References: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
 <2IKx6cpc-IGP3jZtr0s2I14BWM6ptyFD26szPl3b1ng=.9d956b98-dfe6-4a45-a371-bf86923214fb@github.com>
 <x2n2-rE8gGCiMz0Yrwa6zvUWr2NCPAW-SG1f6H8qFCY=.81609fe6-75dc-4497-bfc0-2b394aed236b@github.com>
 <ybSizkW2Zm-dcUIZs7e2HpdZeoUeOM303b4dwV9Ij78=.bc88047f-8a05-459f-9add-b37879a8e164@github.com>
Message-ID: <puU0vLzfiKHD-NL7eiYw2vVBTfxxeMlroaH2hNw8rrM=.fd992e67-3f7c-4a4e-801e-9ecddb61b5b7@github.com>

On Fri, 23 Oct 2020 14:06:22 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Changes requested by ihse (Reviewer).
>
> @magicus the files you commented on are not part of this PR, but they are introduced as part of:
> https://git.openjdk.java.net/jdk/pull/548
> (you seemed to have approved the changes there - but it's also likely that this PR doesn't include the latest changes in that PR). Sorry for the confusion - but please do report any comment you have on the build changes on that PR!

@mcimadamore I'm sorry too for the confusion. :) I must have been a bit in a bit of a hurry when approving it on the other PR. I've now moved my comments there. I don't think there's any way for me to "un-review" this change, so I'll mark it as accepted, even though I don't have anything to say about it (so that I'm not blocking a push). I'll ask the Skara guys if there's a better way to deal with this.

Also, in the future, if you are creating a PR which Skara believes has changes in the build system, but it "really" does not, please remove the `build` label, and I won't even see the PR to come bothering you again! ;-)

-------------

PR: https://git.openjdk.java.net/jdk/pull/634

From ihse at openjdk.java.net  Mon Oct 26 09:56:16 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Mon, 26 Oct 2020 09:56:16 GMT
Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12
 [v4]
In-Reply-To: <DvuPT_pYUFWOCkxQnkIKxUpLqyBQYSzSDVwrqR7iz4c=.221543e2-f4ee-4e28-b7ee-80aa21a9e3a0@github.com>
References: <RRMAPzh6xcVcxOj2S_VW_r50YvZz-3Imaj46bDi8e9U=.9347534e-d482-468a-8668-132d5516bb76@github.com>
 <DvuPT_pYUFWOCkxQnkIKxUpLqyBQYSzSDVwrqR7iz4c=.221543e2-f4ee-4e28-b7ee-80aa21a9e3a0@github.com>
Message-ID: <EWRCN2HhtI_5koSqG5ai6mcVgaArVTVFp2ngb0QvGeM=.015e96fb-2c41-4572-8ee8-a70b8393e02a@github.com>

On Fri, 23 Oct 2020 16:21:53 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is an update to javac and javadoc, to introduce support for Preview APIs, and generally improve javac and javadoc behavior to more closely adhere to JEP 12.
>> 
>> The notable changes are:
>> 
>>  * adding support for Preview APIs (javac until now supported primarily only preview language features, and APIs associated with preview language features). This includes:
>>      * the @PreviewFeature annotation has boolean attribute "reflective", which should be true for reflective Preview APIs, false otherwise. This replaces the existing "essentialAPI" attribute with roughly inverted meaning.
>>      * the preview warnings for preview APIs are auto-suppressed as described in the JEP 12. E.g. the module that declares the preview API is free to use it without warnings
>>  * improving error/warning messages. Please see [1] for a list of cases/examples.
>>  * class files are only marked as preview if they are using a preview feature. [1] also shows if a class file is marked as preview or not.
>>  * the PreviewFeature annotation has been moved to jdk.internal.javac package (originally was in the jdk.internal package).
>>  * Preview API in JDK's javadoc no longer needs to specify @preview tag in the source files. javadoc will auto-generate a note for @PreviewFeature elements, see e.g. [2] and [3] (non-reflective and reflective API, respectively). A summary of preview elements is also provided [4]. Existing uses of @preview have been updated/removed.
>>  * non-JDK javadoc is also enhanced to auto-generate preview notes for uses of Preview elements, and for declaring elements using preview language features [5].
>>  
>>  Please also see the CSR [6] for more information.
>>  
>>  [1] http://cr.openjdk.java.net/~jlahoda/8250768/JEP12-errors-warnings-v6.html
>>  [2] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.base/java/lang/Record.html
>>  [3] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.compiler/javax/lang/model/element/RecordComponentElement.html
>>  [4] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/preview-list.html
>>  [5] http://cr.openjdk.java.net/~jlahoda/8250768/test.javadoc.00/
>>  [6] https://bugs.openjdk.java.net/browse/JDK-8250769
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removing unnecessary cast.

Build changes look good.

-------------

Marked as reviewed by ihse (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/703

From jvernee at openjdk.java.net  Mon Oct 26 12:23:27 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Mon, 26 Oct 2020 12:23:27 GMT
Subject: RFR: 8254354: Add an asExact() VarHandle combinator [v5]
In-Reply-To: <gJ1pTeZZC7tbtwiRsrHcZ1ydfTQhr1MPndGrnGolf14=.dd935929-4f22-4e41-9e0d-99a592ac46b7@github.com>
References: <gJ1pTeZZC7tbtwiRsrHcZ1ydfTQhr1MPndGrnGolf14=.dd935929-4f22-4e41-9e0d-99a592ac46b7@github.com>
Message-ID: <k5qNedmn28gy_oXw8zve3zU3v4Pz8j_z0WjN3wPfbd0=.89ab8075-8567-4d5a-a7a6-16678a8796a1@github.com>

> Hi,
> 
> This patch adds an asExact() combinator to VarHandle, that will return a new VarHandle that performs exact type checks, similar to MethodHandle::invokeExact, to help developers catch inexact VarHandle usage, which can lead to performance degradation.
> 
> This is implemented using a boolean flag in VarForm. If the flag is set, the exact type of the invocation is checked against the exact type in the VarForm. If there is a mismatch, a WrongMethodTypeException is thrown.
> 
> Other than that, there is also an asGeneric() combinator added that does the inverse operation (thanks to R?mi for the suggestion). I've also added The `@Hidden` annotation to the VarHandleGuards methods, as well as a type-checking helper method called from the generic invocation lambda form, so that the stack trace we get points at the location where the VarHandle is being used.
> 
> Thanks,
> Jorn

Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

  - Update javadoc
  - Make isExact() public

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/843/files
  - new: https://git.openjdk.java.net/jdk/pull/843/files/6d7ad477..354e233b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=843&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=843&range=03-04

  Stats: 26 lines in 1 file changed: 19 ins; 0 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/843.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/843/head:pull/843

PR: https://git.openjdk.java.net/jdk/pull/843

From redestad at openjdk.java.net  Mon Oct 26 12:49:43 2020
From: redestad at openjdk.java.net (Claes Redestad)
Date: Mon, 26 Oct 2020 12:49:43 GMT
Subject: RFR: 8255231: Avoid upcalls when initializing the statSampler [v4]
In-Reply-To: <Szazq59X7qoDaQ51HtEeE4N2BarTHiiRFqbUI7DrfEk=.7199b11d-06fb-485c-b9cc-856de34714d6@github.com>
References: <Szazq59X7qoDaQ51HtEeE4N2BarTHiiRFqbUI7DrfEk=.7199b11d-06fb-485c-b9cc-856de34714d6@github.com>
Message-ID: <U1H6HTExg6qMq3JuHkZtlkFW1MpRtRz3hjcn0nZSYd0=.aca55583-d1ec-4d5a-92f9-0fef79e333bc@github.com>

> Current implementation of the statSampler does upcalls to System.getProperty to collect values for a number of properties that are all provided by the VM itself. And since the sampling starts before any user code run then no property can have changed.
> 
> I suggest refactoring the code so that no upcalls are made normally - while asserting this invariant holds using assert-only upcalls. 
> 
> This is a small startup optimization - reducing the startup sequence by approx. 300k instructions and 70k branches in my linux-x64 setup.

Claes Redestad has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 21 additional commits since the last revision:

 - Address review comments from David Holmes
 - Merge branch 'master' into com_ns
 - Refactor to remove stable_java_property_counters and clarify comments
 - Merge branch 'master' into com_ns
 - Revert unrelated changes to perfData
 - Merge branch 'master' into com_ns
 - Improve comments
 - typo
 - Missing definition
 - Extract the shorthand java.version from VersionProps and use it in StatSampler
 - ... and 11 more: https://git.openjdk.java.net/jdk/compare/56309bc2...8572159f

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/802/files
  - new: https://git.openjdk.java.net/jdk/pull/802/files/6e220227..8572159f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=802&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=802&range=02-03

  Stats: 172 lines in 14 files changed: 99 ins; 38 del; 35 mod
  Patch: https://git.openjdk.java.net/jdk/pull/802.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/802/head:pull/802

PR: https://git.openjdk.java.net/jdk/pull/802

From jvernee at openjdk.java.net  Mon Oct 26 13:41:36 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Mon, 26 Oct 2020 13:41:36 GMT
Subject: RFR: 8254354: Add an asExact() VarHandle combinator [v6]
In-Reply-To: <gJ1pTeZZC7tbtwiRsrHcZ1ydfTQhr1MPndGrnGolf14=.dd935929-4f22-4e41-9e0d-99a592ac46b7@github.com>
References: <gJ1pTeZZC7tbtwiRsrHcZ1ydfTQhr1MPndGrnGolf14=.dd935929-4f22-4e41-9e0d-99a592ac46b7@github.com>
Message-ID: <zrCtw7oF5fOZEoTV2hZ-sgEmdFFqAHP_0mMefXx5z-4=.949ff820-3ba3-4f39-8d46-c58f2f43a56d@github.com>

> Hi,
> 
> This patch adds an asExact() combinator to VarHandle, that will return a new VarHandle that performs exact type checks, similar to MethodHandle::invokeExact, to help developers catch inexact VarHandle usage, which can lead to performance degradation.
> 
> This is implemented using a boolean flag in VarForm. If the flag is set, the exact type of the invocation is checked against the exact type in the VarForm. If there is a mismatch, a WrongMethodTypeException is thrown.
> 
> Other than that, there is also an asGeneric() combinator added that does the inverse operation (thanks to R?mi for the suggestion). I've also added The `@Hidden` annotation to the VarHandleGuards methods, as well as a type-checking helper method called from the generic invocation lambda form, so that the stack trace we get points at the location where the VarHandle is being used.
> 
> Thanks,
> Jorn

Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

  Add benchmarks

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/843/files
  - new: https://git.openjdk.java.net/jdk/pull/843/files/354e233b..7b5966dd

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=843&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=843&range=04-05

  Stats: 170 lines in 2 files changed: 170 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/843.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/843/head:pull/843

PR: https://git.openjdk.java.net/jdk/pull/843

From jvernee at openjdk.java.net  Mon Oct 26 13:41:36 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Mon, 26 Oct 2020 13:41:36 GMT
Subject: RFR: 8254354: Add an asExact() VarHandle combinator [v2]
In-Reply-To: <l89RFW5KvA8JvtpvCuo1q7gj2v6nRiuc_A-sN-7O0k8=.8c7153e0-d3f5-47e3-be91-a2782697ef48@github.com>
References: <gJ1pTeZZC7tbtwiRsrHcZ1ydfTQhr1MPndGrnGolf14=.dd935929-4f22-4e41-9e0d-99a592ac46b7@github.com>
 <Mo3T9JJzO03q-I_q8NhsGpu2TVaJg_104ESGWqLhYRg=.7d353318-6827-4708-b973-a9c30558c3ed@github.com>
 <TXUctfc1V1T5RKCtSJAgQZe6xO4I561ez5Ol4YdzLeA=.3c0c41b5-a8b1-44b4-b107-1bd58db6e1a1@github.com>
 <FzY88BSt7bw9P6vmQKtXtBrd8Zwd4bE0sg39ur30x_4=.8ada75c2-7f54-4058-aa7c-822d12f9cbc9@github.com>
 <l89RFW5KvA8JvtpvCuo1q7gj2v6nRiuc_A-sN-7O0k8=.8c7153e0-d3f5-47e3-be91-a2782697ef48@github.com>
Message-ID: <ih7I5nwJ_ZtY1HovULNMqrBqmbGS2m9-IgxEl2AXnao=.72cd046b-4477-43ab-bbc9-93f448e6cd3d@github.com>

On Fri, 23 Oct 2020 23:58:29 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> @PaulSandoz Thanks. I initially tested this with memory access VarHandles, which don't erase the receiver type. e.g.
>> 
>> MemoryLayout layout = MemoryLayout.ofSequence(10, JAVA_INT);
>> VarHandle vh = layout.varHandle(int.class, MemoryLayout.PathElement.sequenceElement());
>> vh = vh.asExact();
>> try (MemorySegment segment = MemorySegment.allocateNative(layout)) {
>>     for (int i = 0; i <10; i++) {
>>         vh.set(segment.baseAddress(), i, i);
>>     }
>> }
>> 
>> Will result in:
>> Exception in thread "main" java.lang.invoke.WrongMethodTypeException: expected (MemoryAddress,long,int)void but found (MemoryAddress,int,int)void
>> 	at java.base/java.lang.invoke.VarHandleGuards.guard_LII_V(VarHandleGuards.java:915)
>> 	at main.Main.main(Main.java:18)
>> 
>> Which led me to believe the approach would work for other reference types. But, I suppose the MethodTypes fed to memaccess VarForms are non-erased as an exception rather than a rule.
>> 
>> I'll update the patch and sharpen the tests to check that the actual expected type is correct (per the exception message).
>
> @PaulSandoz I've implemented your suggestion, by moving the `exact` flag to VarHandle itself. FWIW, the VH::accessModeType method took an AccessMode value as an argument, and the AccessDescriptor only stored the ordinal, so I added an `@Stable` array of values to AccessMode to map from ordinal to enum value. But, maybe it makes more sense to just store the AccessMode in the AccessDescriptor directly? (instead of the ordinal). Not sure what the original motivation was for only storing the ordinal.
> 
> I've also sharpened the tests to check the exception message. Do you think the testing is sufficient? (Note that I did not add tests to the template files since only a select set of argument type conversions causes the WMTE we're looking for. So, that's why I created a new test file).
> 
> FWIW, there seems to have been a bug in the implementation of IndirectVarHandle::accessModeTypeUncached, where it was using the VarHandle's type as the receiver argument (unlike all the other impls). I've fixed this by passing `null` instead, and also removed a workaround for this problem in VarHandles::maybeAdapt.

I've updated the javadoc, and added two benchmarks that show the existing discrepancy between an exact and a generic use of a VarHandle, as well as showing that an exact VarHandle is as fast as a generic VarHandle for an exact invocation. (1 benchmark for normal Java field access, and 1 benchmark for the foreign memory-access API).

-------------

PR: https://git.openjdk.java.net/jdk/pull/843

From hseigel at openjdk.java.net  Mon Oct 26 13:52:10 2020
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Mon, 26 Oct 2020 13:52:10 GMT
Subject: RFR: 8238263: Create at-requires mechanism for containers
In-Reply-To: <TnpbwzrPiw8NroTge6re_l4b2o12UkaPwNya9QodvBI=.5ba26389-c331-456f-b27d-9124c752f85b@github.com>
References: <FsY15A1EzVxl9sqvxg5tqW49LGcUqBRtkQ11JHggBT4=.6786bce8-36cf-4ce6-afc2-a435dddead5d@github.com>
 <43YvmzXR5TzDgPqfcAJDyfpOd7f_ur6ibKfh7AGf4LU=.40b88d2c-b29b-49d4-8d7f-120b7ade6cc5@github.com>
 <rw1F2xcnmpGnCqoqUYfV2QB816kTYJFPMFK47SZ4Pus=.e2c9cb3e-9300-48a6-b96c-94d1a253211d@github.com>
 <WPMFwq6E5LzalgbbH6nRN13MMSZQjm5SDQc74XdnO64=.be4a6b0d-97ce-4652-95ca-6234d4e19bdc@github.com>
 <TnpbwzrPiw8NroTge6re_l4b2o12UkaPwNya9QodvBI=.5ba26389-c331-456f-b27d-9124c752f85b@github.com>
Message-ID: <LBr7Ry2ksEqumPiuBMbqPCgXyQ8zT_IBn_DCn3NtNgE=.e4cefbbc-77ad-4ac5-b293-c9a66f69ba83@github.com>

On Fri, 23 Oct 2020 20:08:01 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

>>> I think it depends on whether the tests will be permanently or temporarily excluded from running with containers. I thought this mechanism would be to permanently exclude the tests. That's why I used `@requires`.
>> 
>> I see, if this is for permanent exclusion then yes I agree that `@requires` is a better choice.
>> 
>>>> enable this option based on an environment variable so we don?t have to remember the
>> cryptic command line sequence.
>>> I'll look into basing the option on an environment variable.
>> 
>> one will still need to pass an environment variable to jtreg, and hence will need to remember some sort of "cryptic command line sequence". a solution for that might be to default `jdk.containerized` to `false` in `VMProps.java` and when only _containerized_ runs will have to set it up.
>> 
>> 
>> btw, I'm not sure that `jdk.containerized` is the best name for this property as _containerization_ is more of an environmental characteristic than that of jdk. how about smth like `env.containerized` or `testenv.containerized`?
>
>> > one will still need to pass an environment variable to jtreg, and hence will need to remember some sort of "cryptic command line sequence". a solution for that might be to default `jdk.containerized` to `false` in `VMProps.java` and when only _containerized_ runs will have to set it up.
>> 
>> Why? Environment variables are inherited. For developers running jtreg, all they need to do is export the variable.
>> 
>> % export JAVA_CONTAINERIZED=1
>> % bash
>> % echo $JAVA_CONTAINERIZED
>> % 1
> 
> b/c jtreg strips most of the environment variables, they might still be defined in the process which runs `VMProps` though (I have never checked that)

Defining an environment variable works when running JTReg from the command line.  But, mach5 does not pass environment variable settings to its JTReg test runs.  Some mach5 special command args would still be needed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/844

From iignatyev at openjdk.java.net  Mon Oct 26 14:28:11 2020
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Mon, 26 Oct 2020 14:28:11 GMT
Subject: RFR: 8238263: Create at-requires mechanism for containers
In-Reply-To: <LBr7Ry2ksEqumPiuBMbqPCgXyQ8zT_IBn_DCn3NtNgE=.e4cefbbc-77ad-4ac5-b293-c9a66f69ba83@github.com>
References: <FsY15A1EzVxl9sqvxg5tqW49LGcUqBRtkQ11JHggBT4=.6786bce8-36cf-4ce6-afc2-a435dddead5d@github.com>
 <43YvmzXR5TzDgPqfcAJDyfpOd7f_ur6ibKfh7AGf4LU=.40b88d2c-b29b-49d4-8d7f-120b7ade6cc5@github.com>
 <rw1F2xcnmpGnCqoqUYfV2QB816kTYJFPMFK47SZ4Pus=.e2c9cb3e-9300-48a6-b96c-94d1a253211d@github.com>
 <WPMFwq6E5LzalgbbH6nRN13MMSZQjm5SDQc74XdnO64=.be4a6b0d-97ce-4652-95ca-6234d4e19bdc@github.com>
 <TnpbwzrPiw8NroTge6re_l4b2o12UkaPwNya9QodvBI=.5ba26389-c331-456f-b27d-9124c752f85b@github.com>
 <LBr7Ry2ksEqumPiuBMbqPCgXyQ8zT_IBn_DCn3NtNgE=.e4cefbbc-77ad-4ac5-b293-c9a66f69ba83@github.com>
Message-ID: <FDPyGBqLAq7cbDHzhh0ZtVyupbEbK0qwJZqYqbqiJ8g=.b5833334-2a16-4f9c-a0db-0b5478741788@github.com>

On Mon, 26 Oct 2020 13:49:26 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

> Defining an environment variable works when running JTReg from the command line. But, mach5 does not pass environment variable settings to its JTReg test runs. Some mach5 special command args would still be needed.

right, yet given you also need to explicitly say mach5 that you want to run testing within docker, that's not a huge problem. this is assuming we default env. variable to `false`, `make` propagates this env. variable to `jtreg` and `jtreg` propagates it to the JVM which runs `VMProps` class.

-------------

PR: https://git.openjdk.java.net/jdk/pull/844

From jvernee at openjdk.java.net  Mon Oct 26 15:37:20 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Mon, 26 Oct 2020 15:37:20 GMT
Subject: RFR: 8255398: Add a dropReturn MethodHandle combinator
Message-ID: <zYoRWf3w-WVtBQZCV97D4sPBDGLFNQ8-JCrq4NXCQ4Q=.f5c6fb56-bc8b-44f4-987b-725dd70e6ace@github.com>

Hi,

This patch adds a `dropReturn` combinator to `MethodHandles` that can be used to create a new method handle that drops the return value, from a given method handle. Similar to the following code:

MethodHandle target = ...;
Class<?> targetReturnType = target.type().returnType();
if (targetReturnType != void.class)
    target = filterReturnValue(target, empty(methodType(void.class, targetReturnType))); 
// use target

But as a short-hand.

Thanks,
Jorn

-------------

Commit messages:
 - Add a dropReturn method handle combinator

Changes: https://git.openjdk.java.net/jdk/pull/866/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=866&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8255398
  Stats: 92 lines in 2 files changed: 92 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/866.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/866/head:pull/866

PR: https://git.openjdk.java.net/jdk/pull/866

From jvernee at openjdk.java.net  Mon Oct 26 15:45:34 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Mon, 26 Oct 2020 15:45:34 GMT
Subject: RFR: 8255398: Add a dropReturn MethodHandle combinator [v2]
In-Reply-To: <zYoRWf3w-WVtBQZCV97D4sPBDGLFNQ8-JCrq4NXCQ4Q=.f5c6fb56-bc8b-44f4-987b-725dd70e6ace@github.com>
References: <zYoRWf3w-WVtBQZCV97D4sPBDGLFNQ8-JCrq4NXCQ4Q=.f5c6fb56-bc8b-44f4-987b-725dd70e6ace@github.com>
Message-ID: <8ccDRraptUr5-NjCqXmtVas3-_geXfS8dVdwQeMBdMk=.da14d5ec-c738-43dc-9868-52169950e159@github.com>

> Hi,
> 
> This patch adds a `dropReturn` combinator to `MethodHandles` that can be used to create a new method handle that drops the return value, from a given method handle. Similar to the following code:
> 
> MethodHandle target = ...;
> Class<?> targetReturnType = target.type().returnType();
> if (targetReturnType != void.class)
>     target = filterReturnValue(target, empty(methodType(void.class, targetReturnType))); 
> // use target
> 
> But as a short-hand.
> 
> Thanks,
> Jorn

Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

  Fix bug id referenced in test

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/866/files
  - new: https://git.openjdk.java.net/jdk/pull/866/files/22ae65d0..2793ac1b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=866&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=866&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/866.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/866/head:pull/866

PR: https://git.openjdk.java.net/jdk/pull/866

From forax at univ-mlv.fr  Mon Oct 26 15:47:18 2020
From: forax at univ-mlv.fr (Remi Forax)
Date: Mon, 26 Oct 2020 16:47:18 +0100 (CET)
Subject: RFR: 8255398: Add a dropReturn MethodHandle combinator
In-Reply-To: <zYoRWf3w-WVtBQZCV97D4sPBDGLFNQ8-JCrq4NXCQ4Q=.f5c6fb56-bc8b-44f4-987b-725dd70e6ace@github.com>
References: <zYoRWf3w-WVtBQZCV97D4sPBDGLFNQ8-JCrq4NXCQ4Q=.f5c6fb56-bc8b-44f4-987b-725dd70e6ace@github.com>
Message-ID: <1827342236.459371.1603727238204.JavaMail.zimbra@u-pem.fr>

----- Mail original -----
> De: "Jorn Vernee" <jvernee at openjdk.java.net>
> ?: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Envoy?: Lundi 26 Octobre 2020 16:37:20
> Objet: RFR: 8255398: Add a dropReturn MethodHandle combinator

> Hi,
> 
> This patch adds a `dropReturn` combinator to `MethodHandles` that can be used to
> create a new method handle that drops the return value, from a given method
> handle. Similar to the following code:
> 
> MethodHandle target = ...;
> Class<?> targetReturnType = target.type().returnType();
> if (targetReturnType != void.class)
>    target = filterReturnValue(target, empty(methodType(void.class,
>    targetReturnType)));
> // use target
> 
> But as a short-hand.

As i said in the JBS issue, it's not just a short hand,
it also the semantics of the POP/POP2 bytecode, remove the return value on top of the stack.

> 
> Thanks,
> Jorn

regards,
R?mi

> 
> -------------
> 
> Commit messages:
> - Add a dropReturn method handle combinator
> 
> Changes: https://git.openjdk.java.net/jdk/pull/866/files
> Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=866&range=00
>  Issue: https://bugs.openjdk.java.net/browse/JDK-8255398
>  Stats: 92 lines in 2 files changed: 92 ins; 0 del; 0 mod
>  Patch: https://git.openjdk.java.net/jdk/pull/866.diff
>  Fetch: git fetch https://git.openjdk.java.net/jdk pull/866/head:pull/866
> 
> PR: https://git.openjdk.java.net/jdk/pull/866

From redestad at openjdk.java.net  Mon Oct 26 15:48:47 2020
From: redestad at openjdk.java.net (Claes Redestad)
Date: Mon, 26 Oct 2020 15:48:47 GMT
Subject: RFR: 8255398: Add a dropReturn MethodHandle combinator [v2]
In-Reply-To: <8ccDRraptUr5-NjCqXmtVas3-_geXfS8dVdwQeMBdMk=.da14d5ec-c738-43dc-9868-52169950e159@github.com>
References: <zYoRWf3w-WVtBQZCV97D4sPBDGLFNQ8-JCrq4NXCQ4Q=.f5c6fb56-bc8b-44f4-987b-725dd70e6ace@github.com>
 <8ccDRraptUr5-NjCqXmtVas3-_geXfS8dVdwQeMBdMk=.da14d5ec-c738-43dc-9868-52169950e159@github.com>
Message-ID: <z2Tj5arbsqySej0LLfPDCxhnndf2me4cEY26RUSOLLA=.41359c26-a489-40ca-8061-a1f670eb80b2@github.com>

On Mon, 26 Oct 2020 15:45:34 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Hi,
>> 
>> This patch adds a `dropReturn` combinator to `MethodHandles` that can be used to create a new method handle that drops the return value, from a given method handle. Similar to the following code:
>> 
>> MethodHandle target = ...;
>> Class<?> targetReturnType = target.type().returnType();
>> if (targetReturnType != void.class)
>>     target = filterReturnValue(target, empty(methodType(void.class, targetReturnType))); 
>> // use target
>> 
>> But as a short-hand.
>> 
>> Thanks,
>> Jorn
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix bug id referenced in test

LGTM, pending CSR.

A minor simplification suggested inline.

src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 5225:

> 5223:         MethodType newType = oldType.changeReturnType(void.class);
> 5224:         BoundMethodHandle result = target.rebind();
> 5225:         LambdaForm lform = result.form;

Suggestion:

        LambdaForm lform = result.editor().filterReturnForm(V_TYPE, true);

src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 5226:

> 5224:         BoundMethodHandle result = target.rebind();
> 5225:         LambdaForm lform = result.form;
> 5226:         lform = lform.editor().filterReturnForm(V_TYPE, true);

Suggestion:

-------------

Marked as reviewed by redestad (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/866

From rriggs at openjdk.java.net  Mon Oct 26 15:55:44 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Mon, 26 Oct 2020 15:55:44 GMT
Subject: RFR: 8251989: Hex formatting and parsing utility [v8]
In-Reply-To: <lv3X2v4KfUM8fxWZyX8_rwGa5wVnysBQjvqnAJaDYUU=.2b36709d-5547-411d-a609-fa465c4ce17f@github.com>
References: <HSEn47GMS1K3g57mrTZeQk-WZHl3pKGHpX_OOf8VnsU=.740863c2-f9e4-43c4-b500-614aab4078b1@github.com>
 <lv3X2v4KfUM8fxWZyX8_rwGa5wVnysBQjvqnAJaDYUU=.2b36709d-5547-411d-a609-fa465c4ce17f@github.com>
Message-ID: <GKX5fo4EdPvNJol3w9HbSlDF2hD_-leFshsXo3yNy8k=.50f85a09-51c7-4710-ba80-811b7bc75720@github.com>

On Mon, 12 Oct 2020 21:17:47 GMT, Marcono1234 <github.com+11685886+Marcono1234 at openjdk.org> wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comment updates to class javadoc
>
> src/java.base/share/classes/java/util/HexFormat.java line 148:
> 
>> 146:     private static final byte[] LOWERCASE_DIGITS = {
>> 147:             '0' , '1' , '2' , '3' , '4' , '5' , '6' , '7',
>> 148:             '8' , '9' , 'a' , 'b' , 'c' , 'd' , 'e' , 'f',
> 
> Suggestion:
> 
>             '0', '1', '2', '3', '4', '5', '6', '7',
>             '8', '9', 'a', 'b', 'c', 'd', 'e', 'f',

Will remove the extra spaces.

> src/java.base/share/classes/java/util/HexFormat.java line 182:
> 
>> 180:     /**
>> 181:      * Returns a hexadecimal formatter with no delimiter and lowercase characters.
>> 182:      * The hex characters are lowercase and the delimiter, prefix, and suffix are empty.
> 
>> The hex characters are lowercase
> 
> This is already mentioned in the sentence before.

will remove the redundancy.

> src/java.base/share/classes/java/util/HexFormat.java line 195:
> 
>> 193: 
>> 194:     /**
>> 195:      * Returns a hexadecimal formatter with a {@code delimiter} and lowercase letters.
> 
> Suggestion:
> 
>      * Returns a hexadecimal formatter with a {@code delimiter} and lowercase characters.
> To be consistent with documentation of other methods.

Will correct

-------------

PR: https://git.openjdk.java.net/jdk/pull/482

From jvernee at openjdk.java.net  Mon Oct 26 16:14:38 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Mon, 26 Oct 2020 16:14:38 GMT
Subject: RFR: 8255398: Add a dropReturn MethodHandle combinator [v3]
In-Reply-To: <zYoRWf3w-WVtBQZCV97D4sPBDGLFNQ8-JCrq4NXCQ4Q=.f5c6fb56-bc8b-44f4-987b-725dd70e6ace@github.com>
References: <zYoRWf3w-WVtBQZCV97D4sPBDGLFNQ8-JCrq4NXCQ4Q=.f5c6fb56-bc8b-44f4-987b-725dd70e6ace@github.com>
Message-ID: <TBRzOr9bG0ihK-7ugu_cLmHvE45BtMZC3MvR7ByKmDQ=.e3c82869-e06d-4894-84e2-03c94bddd9d0@github.com>

> Hi,
> 
> This patch adds a `dropReturn` combinator to `MethodHandles` that can be used to create a new method handle that drops the return value, from a given method handle. Similar to the following code:
> 
> MethodHandle target = ...;
> Class<?> targetReturnType = target.type().returnType();
> if (targetReturnType != void.class)
>     target = filterReturnValue(target, empty(methodType(void.class, targetReturnType))); 
> // use target
> 
> But as a short-hand.
> 
> Thanks,
> Jorn

Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

  Collapse lform get and update into single line
  
  Co-authored-by: Claes Redestad <claes.redestad at gmail.com>

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/866/files
  - new: https://git.openjdk.java.net/jdk/pull/866/files/2793ac1b..e392a0f8

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=866&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=866&range=01-02

  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/866.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/866/head:pull/866

PR: https://git.openjdk.java.net/jdk/pull/866

From psandoz at openjdk.java.net  Mon Oct 26 16:16:17 2020
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Mon, 26 Oct 2020 16:16:17 GMT
Subject: RFR: 8254354: Add an asExact() VarHandle combinator [v2]
In-Reply-To: <ih7I5nwJ_ZtY1HovULNMqrBqmbGS2m9-IgxEl2AXnao=.72cd046b-4477-43ab-bbc9-93f448e6cd3d@github.com>
References: <gJ1pTeZZC7tbtwiRsrHcZ1ydfTQhr1MPndGrnGolf14=.dd935929-4f22-4e41-9e0d-99a592ac46b7@github.com>
 <Mo3T9JJzO03q-I_q8NhsGpu2TVaJg_104ESGWqLhYRg=.7d353318-6827-4708-b973-a9c30558c3ed@github.com>
 <TXUctfc1V1T5RKCtSJAgQZe6xO4I561ez5Ol4YdzLeA=.3c0c41b5-a8b1-44b4-b107-1bd58db6e1a1@github.com>
 <FzY88BSt7bw9P6vmQKtXtBrd8Zwd4bE0sg39ur30x_4=.8ada75c2-7f54-4058-aa7c-822d12f9cbc9@github.com>
 <l89RFW5KvA8JvtpvCuo1q7gj2v6nRiuc_A-sN-7O0k8=.8c7153e0-d3f5-47e3-be91-a2782697ef48@github.com>
 <ih7I5nwJ_ZtY1HovULNMqrBqmbGS2m9-IgxEl2AXnao=.72cd046b-4477-43ab-bbc9-93f448e6cd3d@github.com>
Message-ID: <hsUp1zTqRf1o1KJl96lNWsGbx2_Nv_HvOFaaU2xQUdI=.05f1f992-fa75-4ccd-9f14-50b0682000b7@github.com>

On Mon, 26 Oct 2020 13:37:58 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> @PaulSandoz I've implemented your suggestion, by moving the `exact` flag to VarHandle itself. FWIW, the VH::accessModeType method took an AccessMode value as an argument, and the AccessDescriptor only stored the ordinal, so I added an `@Stable` array of values to AccessMode to map from ordinal to enum value. But, maybe it makes more sense to just store the AccessMode in the AccessDescriptor directly? (instead of the ordinal). Not sure what the original motivation was for only storing the ordinal.
>> 
>> I've also sharpened the tests to check the exception message. Do you think the testing is sufficient? (Note that I did not add tests to the template files since only a select set of argument type conversions causes the WMTE we're looking for. So, that's why I created a new test file).
>> 
>> FWIW, there seems to have been a bug in the implementation of IndirectVarHandle::accessModeTypeUncached, where it was using the VarHandle's type as the receiver argument (unlike all the other impls). I've fixed this by passing `null` instead, and also removed a workaround for this problem in VarHandles::maybeAdapt.
>
> I've updated the javadoc, and added two benchmarks that show the existing discrepancy between an exact and a generic use of a VarHandle, as well as showing that an exact VarHandle is as fast as a generic VarHandle for an exact invocation. (1 benchmark for normal Java field access, and 1 benchmark for the foreign memory-access API).
> 
> Benchmark                                                             Mode  Cnt   Score   Error  Units
> o.o.b.java.lang.invoke.VarHandleExact.exact_exactInvocation           avgt   30   0.729 ? 0.010  ns/op
> o.o.b.java.lang.invoke.VarHandleExact.generic_exactInvocation         avgt   30   0.735 ? 0.019  ns/op
> o.o.b.java.lang.invoke.VarHandleExact.generic_genericInvocation       avgt   30  14.696 ? 0.498  ns/op
> o.o.b.jdk.incubator.foreign.VarHandleExact.exact_exactInvocation      avgt   30   2.274 ? 0.012  ns/op
> o.o.b.jdk.incubator.foreign.VarHandleExact.generic_exactInvocation    avgt   30   2.278 ? 0.015  ns/op
> o.o.b.jdk.incubator.foreign.VarHandleExact.generic_genericInvocation  avgt   30  24.759 ? 0.367  ns/op

The direct use of the enum ordinal is because HotSpot accessing it from the enum value is (or was) not optimal in C2.
 
You can avoid the addition of the stable array by doing the following:

    public final MethodType accessModeType(AccessMode accessMode) {
        return accessModeType(accessMode.at.ordinal());
    }

    @ForceInline
    final MethodType accessModeType(int accessModeOrdinal) {
        TypesAndInvokers tis = getTypesAndInvokers();
        MethodType mt = tis.methodType_table[accessModeOrdinal];
        if (mt == null) {
            mt = tis.methodType_table[accessModeOrdinal] =
                    accessModeTypeUncached(accessModeOrdinal);
        }
        return mt;
    }

    final MethodType accessModeTypeUncached(int accessModeOrdinal) {
        return accessModeTypeUncached(AccessMode.values()[accessModeOrdinal]);
    }
It's a little odd going back and forth between the ordinal and the enum type, but it's all on the slow uncached path, and it avoids some duplication of code.

I'll take a closer looks at the other areas and respond in another comment.

-------------

PR: https://git.openjdk.java.net/jdk/pull/843

From psandoz at openjdk.java.net  Mon Oct 26 16:37:18 2020
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Mon, 26 Oct 2020 16:37:18 GMT
Subject: RFR: 8254354: Add an asExact() VarHandle combinator [v2]
In-Reply-To: <hsUp1zTqRf1o1KJl96lNWsGbx2_Nv_HvOFaaU2xQUdI=.05f1f992-fa75-4ccd-9f14-50b0682000b7@github.com>
References: <gJ1pTeZZC7tbtwiRsrHcZ1ydfTQhr1MPndGrnGolf14=.dd935929-4f22-4e41-9e0d-99a592ac46b7@github.com>
 <Mo3T9JJzO03q-I_q8NhsGpu2TVaJg_104ESGWqLhYRg=.7d353318-6827-4708-b973-a9c30558c3ed@github.com>
 <TXUctfc1V1T5RKCtSJAgQZe6xO4I561ez5Ol4YdzLeA=.3c0c41b5-a8b1-44b4-b107-1bd58db6e1a1@github.com>
 <FzY88BSt7bw9P6vmQKtXtBrd8Zwd4bE0sg39ur30x_4=.8ada75c2-7f54-4058-aa7c-822d12f9cbc9@github.com>
 <l89RFW5KvA8JvtpvCuo1q7gj2v6nRiuc_A-sN-7O0k8=.8c7153e0-d3f5-47e3-be91-a2782697ef48@github.com>
 <ih7I5nwJ_ZtY1HovULNMqrBqmbGS2m9-IgxEl2AXnao=.72cd046b-4477-43ab-bbc9-93f448e6cd3d@github.com>
 <hsUp1zTqRf1o1KJl96lNWsGbx2_Nv_HvOFaaU2xQUdI=.05f1f992-fa75-4ccd-9f14-50b0682000b7@github.com>
Message-ID: <zL3Ch3atQMQlQTdcwv9-cVNwSS6h1EOVlKHJBP1nK7Q=.42ed0c79-ca03-4b31-8084-1bea69d13765@github.com>

On Mon, 26 Oct 2020 16:13:59 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> I've updated the javadoc, and added two benchmarks that show the existing discrepancy between an exact and a generic use of a VarHandle, as well as showing that an exact VarHandle is as fast as a generic VarHandle for an exact invocation. (1 benchmark for normal Java field access, and 1 benchmark for the foreign memory-access API).
>> 
>> Benchmark                                                             Mode  Cnt   Score   Error  Units
>> o.o.b.java.lang.invoke.VarHandleExact.exact_exactInvocation           avgt   30   0.729 ? 0.010  ns/op
>> o.o.b.java.lang.invoke.VarHandleExact.generic_exactInvocation         avgt   30   0.735 ? 0.019  ns/op
>> o.o.b.java.lang.invoke.VarHandleExact.generic_genericInvocation       avgt   30  14.696 ? 0.498  ns/op
>> o.o.b.jdk.incubator.foreign.VarHandleExact.exact_exactInvocation      avgt   30   2.274 ? 0.012  ns/op
>> o.o.b.jdk.incubator.foreign.VarHandleExact.generic_exactInvocation    avgt   30   2.278 ? 0.015  ns/op
>> o.o.b.jdk.incubator.foreign.VarHandleExact.generic_genericInvocation  avgt   30  24.759 ? 0.367  ns/op
>
> The direct use of the enum ordinal is because HotSpot accessing it from the enum value is (or was) not optimal in C2.
>  
> You can avoid the addition of the stable array by doing the following:
> 
>     public final MethodType accessModeType(AccessMode accessMode) {
>         return accessModeType(accessMode.at.ordinal());
>     }
> 
>     @ForceInline
>     final MethodType accessModeType(int accessModeOrdinal) {
>         TypesAndInvokers tis = getTypesAndInvokers();
>         MethodType mt = tis.methodType_table[accessModeOrdinal];
>         if (mt == null) {
>             mt = tis.methodType_table[accessModeOrdinal] =
>                     accessModeTypeUncached(accessModeOrdinal);
>         }
>         return mt;
>     }
> 
>     final MethodType accessModeTypeUncached(int accessModeOrdinal) {
>         return accessModeTypeUncached(AccessMode.values()[accessModeOrdinal]);
>     }
> It's a little odd going back and forth between the ordinal and the enum value, but it's all on the slow uncached path, and it avoids some duplication of code.
> 
> I'll take a closer looks at the other areas and respond in another comment.

We can clarify the new methods and tie them closer to method handle semantics. I suggest the names `asExactInvoker` and `asInvoker`, referencing `MethodHandles.exactInvoker` and `MethodHandles.invoker` respectively. (The term "generic" is really reserved for erased method types, and otherwise used internally as the generic invoker.)

The `VarHandle` documentation already specifies that:

 * <p>
 * Invocation of an access mode method behaves as if an invocation of
 * {@link MethodHandle#invoke}, where the receiving method handle accepts the
 * VarHandle instance as the leading argument.  More specifically, the
 * following, where {@code {access-mode}} corresponds to the access mode method
 * name:
 * <pre> {@code
 * VarHandle vh = ..
 * R r = (R) vh.{access-mode}(p1, p2, ..., pN);
 * }</pre>
 * behaves as if:
 * <pre> {@code
 * VarHandle vh = ..
 * VarHandle.AccessMode am = VarHandle.AccessMode.valueFromMethodName("{access-mode}");
 * MethodHandle mh = MethodHandles.varHandleExactInvoker(
 *                       am,
 *                       vh.accessModeType(am));
 *
 * R r = (R) mh.invoke(vh, p1, p2, ..., pN)
 * }</pre>
 * (modulo access mode methods do not declare throwing of {@code Throwable}).
...

 We will need to adjust this section, i can help, but first let us reach agreement on this approach.

-------------

PR: https://git.openjdk.java.net/jdk/pull/843

From asemenyuk at openjdk.java.net  Mon Oct 26 16:51:19 2020
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Mon, 26 Oct 2020 16:51:19 GMT
Subject: RFR: 8255206: [macos] LicenseTest fails on macOS 11
In-Reply-To: <TNyJYXd93S-rihjFcaejAUAjgjH1dZDQflB9haFdjjI=.12295fd9-9c9b-45c9-a733-f8bc42ea131f@github.com>
References: <TNyJYXd93S-rihjFcaejAUAjgjH1dZDQflB9haFdjjI=.12295fd9-9c9b-45c9-a733-f8bc42ea131f@github.com>
Message-ID: <Qvm9QtiwmOPI4au6iMOADdZZQRMOuuOYIzX8JufsEpk=.bdfe3490-f879-454c-9c92-c153fe53d6b1@github.com>

On Sat, 24 Oct 2020 00:49:12 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> I did not reproduce issue with license is not shown as per SQE report. It work as expected. However, jpackage fails due to unflatten/flatten being removed from hdiutil on macOS 11. I am not sure why it was needed, probably some legacy code. Without unflatten/flatten everything works as expected on macOS 11 and 10.5.7.

Marked as reviewed by asemenyuk (Committer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/847

From jrose at openjdk.java.net  Mon Oct 26 17:19:19 2020
From: jrose at openjdk.java.net (John R Rose)
Date: Mon, 26 Oct 2020 17:19:19 GMT
Subject: RFR: 8255398: Add a dropReturn MethodHandle combinator [v3]
In-Reply-To: <z2Tj5arbsqySej0LLfPDCxhnndf2me4cEY26RUSOLLA=.41359c26-a489-40ca-8061-a1f670eb80b2@github.com>
References: <zYoRWf3w-WVtBQZCV97D4sPBDGLFNQ8-JCrq4NXCQ4Q=.f5c6fb56-bc8b-44f4-987b-725dd70e6ace@github.com>
 <8ccDRraptUr5-NjCqXmtVas3-_geXfS8dVdwQeMBdMk=.da14d5ec-c738-43dc-9868-52169950e159@github.com>
 <z2Tj5arbsqySej0LLfPDCxhnndf2me4cEY26RUSOLLA=.41359c26-a489-40ca-8061-a1f670eb80b2@github.com>
Message-ID: <yewLzMO7cUrnU2OZwHOxdhhU2RTgj2WmQHgLy4YP5DE=.a72cd93b-4803-42f7-b979-506721250d07@github.com>

On Mon, 26 Oct 2020 15:45:00 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Collapse lform get and update into single line
>>   
>>   Co-authored-by: Claes Redestad <claes.redestad at gmail.com>
>
> LGTM, pending CSR.
> 
> A minor simplification suggested inline.

I don't mind shorthands, but the existing idiom is shorter than advertised,
a one-liner assuming the MH is already bound to a var:

target = target.asType(target.type().changeReturnType(void.class));

The API has good short circuits already; no new objects are
created if the MH is already void-returning.

Perhaps this RFE could be adjusted to `MethodHandle::changeReturnType`?
Then it could be used for dropping returns *or* casting them to other types.

-------------

PR: https://git.openjdk.java.net/jdk/pull/866

From jvernee at openjdk.java.net  Mon Oct 26 17:32:20 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Mon, 26 Oct 2020 17:32:20 GMT
Subject: RFR: 8255398: Add a dropReturn MethodHandle combinator [v3]
In-Reply-To: <yewLzMO7cUrnU2OZwHOxdhhU2RTgj2WmQHgLy4YP5DE=.a72cd93b-4803-42f7-b979-506721250d07@github.com>
References: <zYoRWf3w-WVtBQZCV97D4sPBDGLFNQ8-JCrq4NXCQ4Q=.f5c6fb56-bc8b-44f4-987b-725dd70e6ace@github.com>
 <8ccDRraptUr5-NjCqXmtVas3-_geXfS8dVdwQeMBdMk=.da14d5ec-c738-43dc-9868-52169950e159@github.com>
 <z2Tj5arbsqySej0LLfPDCxhnndf2me4cEY26RUSOLLA=.41359c26-a489-40ca-8061-a1f670eb80b2@github.com>
 <yewLzMO7cUrnU2OZwHOxdhhU2RTgj2WmQHgLy4YP5DE=.a72cd93b-4803-42f7-b979-506721250d07@github.com>
Message-ID: <BBTb2SmjGX0gUXbCm3q4OOjUBx4XNDRCgRSOVTG03dE=.1fd2b43e-f67b-4102-a357-d08db58e588b@github.com>

On Mon, 26 Oct 2020 17:16:17 GMT, John R Rose <jrose at openjdk.org> wrote:

>> LGTM, pending CSR.
>> 
>> A minor simplification suggested inline.
>
> I don't mind shorthands, but the existing idiom is shorter than advertised,
> a one-liner assuming the MH is already bound to a var:
> 
> target = target.asType(target.type().changeReturnType(void.class));
> 
> The API has good short circuits already; no new objects are
> created if the MH is already void-returning.
> 
> Perhaps this RFE could be adjusted to `MethodHandle::changeReturnType`?
> Then it could be used for dropping returns *or* casting them to other types.

@rose00 My bad. You're right, I realized we could also use `asType` later on (I did call it out in the CSR), but It's still a bit more wordy than what I'm proposing.

`dropReturn` seemed like a good choice since we already have `dropArguments`. WRT changing to `MethodHandle::changeReturnType`, I think doing that also begs for adding a `MethodHandle::changeParameterType` (with a single index and varargs overload). But, in that case it seems fair to just point users at `asType` instead.

In other words; `dropReturn` seems fine to get parity with `dropArguments`, but `changeReturnType` seems a step too close to `asType` (also since it implies adding `changeParameterType` as well). So, maybe this RFE is a bust, and users should use `asType` instead? Or do you think adding both `changeReturnType` and `changeParameterType`(s) seems worth it? (I'm not so sure).

-------------

PR: https://git.openjdk.java.net/jdk/pull/866

From jrose at openjdk.java.net  Mon Oct 26 18:04:17 2020
From: jrose at openjdk.java.net (John R Rose)
Date: Mon, 26 Oct 2020 18:04:17 GMT
Subject: RFR: 8255398: Add a dropReturn MethodHandle combinator [v3]
In-Reply-To: <BBTb2SmjGX0gUXbCm3q4OOjUBx4XNDRCgRSOVTG03dE=.1fd2b43e-f67b-4102-a357-d08db58e588b@github.com>
References: <zYoRWf3w-WVtBQZCV97D4sPBDGLFNQ8-JCrq4NXCQ4Q=.f5c6fb56-bc8b-44f4-987b-725dd70e6ace@github.com>
 <8ccDRraptUr5-NjCqXmtVas3-_geXfS8dVdwQeMBdMk=.da14d5ec-c738-43dc-9868-52169950e159@github.com>
 <z2Tj5arbsqySej0LLfPDCxhnndf2me4cEY26RUSOLLA=.41359c26-a489-40ca-8061-a1f670eb80b2@github.com>
 <yewLzMO7cUrnU2OZwHOxdhhU2RTgj2WmQHgLy4YP5DE=.a72cd93b-4803-42f7-b979-506721250d07@github.com>
 <BBTb2SmjGX0gUXbCm3q4OOjUBx4XNDRCgRSOVTG03dE=.1fd2b43e-f67b-4102-a357-d08db58e588b@github.com>
Message-ID: <cWtzYwXdDEoC4v8eRBaGhY5aAI62pThg8nGQDK7d5x0=.b0e01bd2-ce7f-4054-8566-793f20dd2ca7@github.com>

On Mon, 26 Oct 2020 17:29:11 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> ?`dropReturn` seemed like a good choice since we already have `dropArguments`. WRT changing to `MethodHandle::changeReturnType`...

That's a very reasonable point.  People might look for `dropRT` after they find `dropAs`.  And `MHs` is designed as a large-ish set of utility methods.

I agree that adding `MH::changeRT` is a slippery slope; it tends to lift more of the MT API onto MH, and it starts to put new stuff into the smaller MH API; that was my bad.

But (in the spirit of brainstorming, and agreeing with your present proposal), I'll suggest a separate idea to think about.  Use a HOFP API to give easy access to the entire `MT` API all in one go, by reifying the `MH.type` property as a temporary (lambda argument):

MethodHandle mapType(MethodHandle mh, UnaryOperator<MethodType> fn) {
   return mh.asType(fn.apply(mh.type()));
}

This also suggests a possible argument transform utility, a sort of mini-version of Charlie Nutter's MH builder API:

MethodHandle mapArguments(MethodHandle mh, UnaryOperator<List<ArgumentValue<?>>> fn) {
  var args = mh.type().argumentList().stream().map(t -> makeArg(t)).asList();
  args = fn.apply(args);
  ? do stuff to re-weave mh with the resulting argument transforms ?
}
public sealed interface ArgumentValue<T> {
  Class<T> type();
  <U> ArgumentValue<U> asType(Class<U> newType);
  ? other stuff for pre-applying MHs ? 
}

-------------

PR: https://git.openjdk.java.net/jdk/pull/866

From hseigel at openjdk.java.net  Mon Oct 26 18:13:29 2020
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Mon, 26 Oct 2020 18:13:29 GMT
Subject: RFR: 8238263: Create at-requires mechanism for containers [v2]
In-Reply-To: <FsY15A1EzVxl9sqvxg5tqW49LGcUqBRtkQ11JHggBT4=.6786bce8-36cf-4ce6-afc2-a435dddead5d@github.com>
References: <FsY15A1EzVxl9sqvxg5tqW49LGcUqBRtkQ11JHggBT4=.6786bce8-36cf-4ce6-afc2-a435dddead5d@github.com>
Message-ID: <z5JkXAozR6xstlnQQW7w8x6XhkOgqt0bT3yYh3g7c5s=.c7892630-e8a0-4541-8fff-35962230d14e@github.com>

> Please review this change to add an @requires mechanism called "jdk.containerized" to help mark tests that are incompatible with containers.  Users would add "@requires jdk.containerized != true" to the incompatible tests and then use "make test ... OPTIONS=-Djdk.containerized=true" or "bash jib.sh mach5 -- remote-build-and-test ... --test-make-args JTREG=OPTIONS=-Djdk.containerized=true" to exclude those tests when testing with containers.

Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:

  8238263: Create at-requires mechanism for containers

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/844/files
  - new: https://git.openjdk.java.net/jdk/pull/844/files/9ffe9ad7..7a5ae052

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=844&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=844&range=00-01

  Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/844.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/844/head:pull/844

PR: https://git.openjdk.java.net/jdk/pull/844

From hseigel at openjdk.java.net  Mon Oct 26 18:17:16 2020
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Mon, 26 Oct 2020 18:17:16 GMT
Subject: RFR: 8238263: Create at-requires mechanism for containers
In-Reply-To: <FDPyGBqLAq7cbDHzhh0ZtVyupbEbK0qwJZqYqbqiJ8g=.b5833334-2a16-4f9c-a0db-0b5478741788@github.com>
References: <FsY15A1EzVxl9sqvxg5tqW49LGcUqBRtkQ11JHggBT4=.6786bce8-36cf-4ce6-afc2-a435dddead5d@github.com>
 <43YvmzXR5TzDgPqfcAJDyfpOd7f_ur6ibKfh7AGf4LU=.40b88d2c-b29b-49d4-8d7f-120b7ade6cc5@github.com>
 <rw1F2xcnmpGnCqoqUYfV2QB816kTYJFPMFK47SZ4Pus=.e2c9cb3e-9300-48a6-b96c-94d1a253211d@github.com>
 <WPMFwq6E5LzalgbbH6nRN13MMSZQjm5SDQc74XdnO64=.be4a6b0d-97ce-4652-95ca-6234d4e19bdc@github.com>
 <TnpbwzrPiw8NroTge6re_l4b2o12UkaPwNya9QodvBI=.5ba26389-c331-456f-b27d-9124c752f85b@github.com>
 <LBr7Ry2ksEqumPiuBMbqPCgXyQ8zT_IBn_DCn3NtNgE=.e4cefbbc-77ad-4ac5-b293-c9a66f69ba83@github.com>
 <FDPyGBqLAq7cbDHzhh0ZtVyupbEbK0qwJZqYqbqiJ8g=.b5833334-2a16-4f9c-a0db-0b5478741788@github.com>
Message-ID: <zBO1cOphbVeSaH95w1_wMfcsekO3Y1qjYZzpVDAIRp4=.f25575d3-75e9-4354-9c12-0eb1c9dea85f@github.com>

On Mon, 26 Oct 2020 14:25:14 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

>> Defining an environment variable works when running JTReg from the command line.  But, mach5 does not pass environment variable settings to its JTReg test runs.  Some mach5 special command args would still be needed.
>
>> Defining an environment variable works when running JTReg from the command line. But, mach5 does not pass environment variable settings to its JTReg test runs. Some mach5 special command args would still be needed.
> 
> right, yet given you also need to explicitly say mach5 that you want to run testing within docker, that's not a huge problem. this is assuming we default env. variable to `false`, `make` propagates this env. variable to `jtreg` and `jtreg` propagates it to the JVM which runs `VMProps` class.

Please review this updated webrev that adds environment variable TEST_JDK_CONTAINERIZED for setting @requires jdk.containerized.  When TEST_JDK_CONTAINERIZED is unset, jdk.containerized is false.

-------------

PR: https://git.openjdk.java.net/jdk/pull/844

From github.com+828220+forax at openjdk.java.net  Mon Oct 26 18:38:20 2020
From: github.com+828220+forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Mon, 26 Oct 2020 18:38:20 GMT
Subject: RFR: 8255398: Add a dropReturn MethodHandle combinator [v3]
In-Reply-To: <cWtzYwXdDEoC4v8eRBaGhY5aAI62pThg8nGQDK7d5x0=.b0e01bd2-ce7f-4054-8566-793f20dd2ca7@github.com>
References: <zYoRWf3w-WVtBQZCV97D4sPBDGLFNQ8-JCrq4NXCQ4Q=.f5c6fb56-bc8b-44f4-987b-725dd70e6ace@github.com>
 <8ccDRraptUr5-NjCqXmtVas3-_geXfS8dVdwQeMBdMk=.da14d5ec-c738-43dc-9868-52169950e159@github.com>
 <z2Tj5arbsqySej0LLfPDCxhnndf2me4cEY26RUSOLLA=.41359c26-a489-40ca-8061-a1f670eb80b2@github.com>
 <yewLzMO7cUrnU2OZwHOxdhhU2RTgj2WmQHgLy4YP5DE=.a72cd93b-4803-42f7-b979-506721250d07@github.com>
 <BBTb2SmjGX0gUXbCm3q4OOjUBx4XNDRCgRSOVTG03dE=.1fd2b43e-f67b-4102-a357-d08db58e588b@github.com>
 <cWtzYwXdDEoC4v8eRBaGhY5aAI62pThg8nGQDK7d5x0=.b0e01bd2-ce7f-4054-8566-793f20dd2ca7@github.com>
Message-ID: <N4S_va-a90fKTuRoEFZSmAZTVlscp7v72DHJqqA0C8k=.4e20fb13-ab89-4d74-8151-5eddf612ab9d@github.com>

On Mon, 26 Oct 2020 18:01:04 GMT, John R Rose <jrose at openjdk.org> wrote:

>> @rose00 My bad. You're right, I realized we could also use `asType` later on (I did call it out in the CSR), but It's still a bit more wordy than what I'm proposing.
>> 
>> `dropReturn` seemed like a good choice since we already have `dropArguments`. WRT changing to `MethodHandle::changeReturnType`, I think doing that also begs for adding a `MethodHandle::changeParameterType` (with a single index and varargs overload). But, in that case it seems fair to just point users at `asType` instead.
>> 
>> In other words; `dropReturn` seems fine to get parity with `dropArguments`, but `changeReturnType` seems a step too close to `asType` (also since it implies adding `changeParameterType` as well). So, maybe this RFE is a bust, and users should use `asType` instead? Or do you think adding both `changeReturnType` and `changeParameterType`(s) seems worth it? (I'm not so sure).
>
>> ?`dropReturn` seemed like a good choice since we already have `dropArguments`. WRT changing to `MethodHandle::changeReturnType`...
> 
> That's a very reasonable point.  People might look for `dropRT` after they find `dropAs`.  And `MHs` is designed as a large-ish set of utility methods.
> 
> I agree that adding `MH::changeRT` is a slippery slope; it tends to lift more of the MT API onto MH, and it starts to put new stuff into the smaller MH API; that was my bad.
> 
> But (in the spirit of brainstorming, and agreeing with your present proposal), I'll suggest a separate idea to think about.  Use a HOFP API to give easy access to the entire `MT` API all in one go, by reifying the `MH.type` property as a temporary (lambda argument):
> 
> MethodHandle mapType(MethodHandle mh, UnaryOperator<MethodType> fn) {
>    return mh.asType(fn.apply(mh.type()));
> }
> 
> This also suggests a possible argument transform utility, a sort of mini-version of Charlie Nutter's MH builder API:
> 
> MethodHandle mapArguments(MethodHandle mh, UnaryOperator<List<ArgumentValue<?>>> fn) {
>   var args = mh.type().argumentList().stream().map(t -> makeArg(t)).asList();
>   args = fn.apply(args);
>   ? do stuff to re-weave mh with the resulting argument transforms ?
> }
> public sealed interface ArgumentValue<T> {
>   Class<T> type();
>   <U> ArgumentValue<U> asType(Class<U> newType);
>   ? other stuff for pre-applying MHs ? 
> }

instead of mapArguments(), i believe it's better to have a method map on a MethodType that takes two mapping functions, one for the return type and one for the prameter types.

so one can write:
  MHs.mapType(mh, mt -> mt.map(Function.identity(), t-> t.isPrimitive? t: Object.class))
to not change the return type and erase the parameter type to Object if they are not primitives

With that, changing the return type to void can be done that way too
  MHs.mapType(mh, mt -> mt.map(__ -> void.class, Function.identity())

-------------

PR: https://git.openjdk.java.net/jdk/pull/866

From herrick at openjdk.java.net  Mon Oct 26 18:44:19 2020
From: herrick at openjdk.java.net (Andy Herrick)
Date: Mon, 26 Oct 2020 18:44:19 GMT
Subject: RFR: 8255206: [macos] LicenseTest fails on macOS 11
In-Reply-To: <TNyJYXd93S-rihjFcaejAUAjgjH1dZDQflB9haFdjjI=.12295fd9-9c9b-45c9-a733-f8bc42ea131f@github.com>
References: <TNyJYXd93S-rihjFcaejAUAjgjH1dZDQflB9haFdjjI=.12295fd9-9c9b-45c9-a733-f8bc42ea131f@github.com>
Message-ID: <OeZ2Y2yP_-OcjPPYLt5_-be6xvRtGV9r5X6LLONdfi8=.e54415db-0839-4a91-9dbf-8e8a50babbe6@github.com>

On Sat, 24 Oct 2020 00:49:12 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> I did not reproduce issue with license is not shown as per SQE report. It work as expected. However, jpackage fails due to unflatten/flatten being removed from hdiutil on macOS 11. I am not sure why it was needed, probably some legacy code. Without unflatten/flatten everything works as expected on macOS 11 and 10.5.7.

Marked as reviewed by herrick (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/847

From jvernee at openjdk.java.net  Mon Oct 26 18:57:43 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Mon, 26 Oct 2020 18:57:43 GMT
Subject: RFR: 8254354: Add an asExact() VarHandle combinator [v7]
In-Reply-To: <gJ1pTeZZC7tbtwiRsrHcZ1ydfTQhr1MPndGrnGolf14=.dd935929-4f22-4e41-9e0d-99a592ac46b7@github.com>
References: <gJ1pTeZZC7tbtwiRsrHcZ1ydfTQhr1MPndGrnGolf14=.dd935929-4f22-4e41-9e0d-99a592ac46b7@github.com>
Message-ID: <cZYTIoYtLfKkecaHSAZL2aaTNFhjDX2diJnXCcuGKqM=.4b24ebca-5eed-458e-bbea-d0c729646f95@github.com>

> Hi,
> 
> This patch adds an asExact() combinator to VarHandle, that will return a new VarHandle that performs exact type checks, similar to MethodHandle::invokeExact, to help developers catch inexact VarHandle usage, which can lead to performance degradation.
> 
> This is implemented using a boolean flag in VarForm. If the flag is set, the exact type of the invocation is checked against the exact type in the VarForm. If there is a mismatch, a WrongMethodTypeException is thrown.
> 
> Other than that, there is also an asGeneric() combinator added that does the inverse operation (thanks to R?mi for the suggestion). I've also added The `@Hidden` annotation to the VarHandleGuards methods, as well as a type-checking helper method called from the generic invocation lambda form, so that the stack trace we get points at the location where the VarHandle is being used.
> 
> Thanks,
> Jorn
> 
> CSR link: https://bugs.openjdk.java.net/browse/JDK-8255375

Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

  Update accessModeType to use the AccessType ordinal directly.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/843/files
  - new: https://git.openjdk.java.net/jdk/pull/843/files/7b5966dd..16d9fd0e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=843&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=843&range=05-06

  Stats: 29 lines in 5 files changed: 7 ins; 3 del; 19 mod
  Patch: https://git.openjdk.java.net/jdk/pull/843.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/843/head:pull/843

PR: https://git.openjdk.java.net/jdk/pull/843

From github.com+828220+forax at openjdk.java.net  Mon Oct 26 18:57:43 2020
From: github.com+828220+forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Mon, 26 Oct 2020 18:57:43 GMT
Subject: RFR: 8254354: Add an asExact() VarHandle combinator
In-Reply-To: <gJ1pTeZZC7tbtwiRsrHcZ1ydfTQhr1MPndGrnGolf14=.dd935929-4f22-4e41-9e0d-99a592ac46b7@github.com>
References: <gJ1pTeZZC7tbtwiRsrHcZ1ydfTQhr1MPndGrnGolf14=.dd935929-4f22-4e41-9e0d-99a592ac46b7@github.com>
Message-ID: <u5fVhdN1QmuBpAQN4ppuQCz3RnvokdKVPxTPowfQMQc=.647ea9f9-9926-4e54-80fa-e5c26d120543@github.com>

On Fri, 23 Oct 2020 17:47:36 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Hi,
> 
> This patch adds an asExact() combinator to VarHandle, that will return a new VarHandle that performs exact type checks, similar to MethodHandle::invokeExact, to help developers catch inexact VarHandle usage, which can lead to performance degradation.
> 
> This is implemented using a boolean flag in VarForm. If the flag is set, the exact type of the invocation is checked against the exact type in the VarForm. If there is a mismatch, a WrongMethodTypeException is thrown.
> 
> Other than that, there is also an asGeneric() combinator added that does the inverse operation (thanks to R?mi for the suggestion). I've also added The `@Hidden` annotation to the VarHandleGuards methods, as well as a type-checking helper method called from the generic invocation lambda form, so that the stack trace we get points at the location where the VarHandle is being used.
> 
> Thanks,
> Jorn
> 
> CSR link: https://bugs.openjdk.java.net/browse/JDK-8255375

Looks good to me.

-------------

PR: https://git.openjdk.java.net/jdk/pull/843

From github.com+828220+forax at openjdk.java.net  Mon Oct 26 18:57:43 2020
From: github.com+828220+forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Mon, 26 Oct 2020 18:57:43 GMT
Subject: RFR: 8254354: Add an asExact() VarHandle combinator [v2]
In-Reply-To: <zL3Ch3atQMQlQTdcwv9-cVNwSS6h1EOVlKHJBP1nK7Q=.42ed0c79-ca03-4b31-8084-1bea69d13765@github.com>
References: <gJ1pTeZZC7tbtwiRsrHcZ1ydfTQhr1MPndGrnGolf14=.dd935929-4f22-4e41-9e0d-99a592ac46b7@github.com>
 <Mo3T9JJzO03q-I_q8NhsGpu2TVaJg_104ESGWqLhYRg=.7d353318-6827-4708-b973-a9c30558c3ed@github.com>
 <TXUctfc1V1T5RKCtSJAgQZe6xO4I561ez5Ol4YdzLeA=.3c0c41b5-a8b1-44b4-b107-1bd58db6e1a1@github.com>
 <FzY88BSt7bw9P6vmQKtXtBrd8Zwd4bE0sg39ur30x_4=.8ada75c2-7f54-4058-aa7c-822d12f9cbc9@github.com>
 <l89RFW5KvA8JvtpvCuo1q7gj2v6nRiuc_A-sN-7O0k8=.8c7153e0-d3f5-47e3-be91-a2782697ef48@github.com>
 <ih7I5nwJ_ZtY1HovULNMqrBqmbGS2m9-IgxEl2AXnao=.72cd046b-4477-43ab-bbc9-93f448e6cd3d@github.com>
 <hsUp1zTqRf1o1KJl96lNWsGbx2_Nv_HvOFaaU2xQUdI=.05f1f992-fa75-4ccd-9f14-50b0682000b7@github.com>
 <zL3Ch3atQMQlQTdcwv9-cVNwSS6h1EOVlKHJBP1nK7Q=.42ed0c79-ca03-4b31-8084-1bea69d13765@github.com>
Message-ID: <94D2yl0BiGL56RmbE82u4mDhsvaCU79qDDpE3iu_Ce8=.71d1bb0a-3090-4937-b124-4ad9d5a3fcef@github.com>

On Mon, 26 Oct 2020 16:34:10 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> The direct use of the enum ordinal is because HotSpot accessing it from the enum value is (or was) not optimal in C2.
>>  
>> You can avoid the addition of the stable array by doing the following:
>> 
>>     public final MethodType accessModeType(AccessMode accessMode) {
>>         return accessModeType(accessMode.at.ordinal());
>>     }
>> 
>>     @ForceInline
>>     final MethodType accessModeType(int accessModeOrdinal) {
>>         TypesAndInvokers tis = getTypesAndInvokers();
>>         MethodType mt = tis.methodType_table[accessModeOrdinal];
>>         if (mt == null) {
>>             mt = tis.methodType_table[accessModeOrdinal] =
>>                     accessModeTypeUncached(accessModeOrdinal);
>>         }
>>         return mt;
>>     }
>> 
>>     final MethodType accessModeTypeUncached(int accessModeOrdinal) {
>>         return accessModeTypeUncached(AccessMode.values()[accessModeOrdinal]);
>>     }
>> It's a little odd going back and forth between the ordinal and the enum value, but it's all on the slow uncached path, and it avoids some duplication of code.
>> 
>> I'll take a closer looks at the other areas and respond in another comment.
>
> We can clarify the new methods and tie them closer to method handle semantics. I suggest the names `asExactInvoker` and `asInvoker`, referencing `MethodHandles.exactInvoker` and `MethodHandles.invoker` respectively. (The term "generic" is really reserved for erased method types, and otherwise used internally as the generic invoker.)
> 
> The `VarHandle` documentation already specifies that:
> 
>  * <p>
>  * Invocation of an access mode method behaves as if an invocation of
>  * {@link MethodHandle#invoke}, where the receiving method handle accepts the
>  * VarHandle instance as the leading argument.  More specifically, the
>  * following, where {@code {access-mode}} corresponds to the access mode method
>  * name:
>  * <pre> {@code
>  * VarHandle vh = ..
>  * R r = (R) vh.{access-mode}(p1, p2, ..., pN);
>  * }</pre>
>  * behaves as if:
>  * <pre> {@code
>  * VarHandle vh = ..
>  * VarHandle.AccessMode am = VarHandle.AccessMode.valueFromMethodName("{access-mode}");
>  * MethodHandle mh = MethodHandles.varHandleExactInvoker(
>  *                       am,
>  *                       vh.accessModeType(am));
>  *
>  * R r = (R) mh.invoke(vh, p1, p2, ..., pN)
>  * }</pre>
>  * (modulo access mode methods do not declare throwing of {@code Throwable}).
> ...
> 
>  We will need to adjust this section, i can help, but first let us reach agreement on this approach.

Paul,
an invoker has the MethodHandle (resp. VarHandle) as first argument so it's not the same semantics.

-------------

PR: https://git.openjdk.java.net/jdk/pull/843

From jvernee at openjdk.java.net  Mon Oct 26 18:57:44 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Mon, 26 Oct 2020 18:57:44 GMT
Subject: RFR: 8254354: Add an asExact() VarHandle combinator [v2]
In-Reply-To: <94D2yl0BiGL56RmbE82u4mDhsvaCU79qDDpE3iu_Ce8=.71d1bb0a-3090-4937-b124-4ad9d5a3fcef@github.com>
References: <gJ1pTeZZC7tbtwiRsrHcZ1ydfTQhr1MPndGrnGolf14=.dd935929-4f22-4e41-9e0d-99a592ac46b7@github.com>
 <Mo3T9JJzO03q-I_q8NhsGpu2TVaJg_104ESGWqLhYRg=.7d353318-6827-4708-b973-a9c30558c3ed@github.com>
 <TXUctfc1V1T5RKCtSJAgQZe6xO4I561ez5Ol4YdzLeA=.3c0c41b5-a8b1-44b4-b107-1bd58db6e1a1@github.com>
 <FzY88BSt7bw9P6vmQKtXtBrd8Zwd4bE0sg39ur30x_4=.8ada75c2-7f54-4058-aa7c-822d12f9cbc9@github.com>
 <l89RFW5KvA8JvtpvCuo1q7gj2v6nRiuc_A-sN-7O0k8=.8c7153e0-d3f5-47e3-be91-a2782697ef48@github.com>
 <ih7I5nwJ_ZtY1HovULNMqrBqmbGS2m9-IgxEl2AXnao=.72cd046b-4477-43ab-bbc9-93f448e6cd3d@github.com>
 <hsUp1zTqRf1o1KJl96lNWsGbx2_Nv_HvOFaaU2xQUdI=.05f1f992-fa75-4ccd-9f14-50b0682000b7@github.com>
 <zL3Ch3atQMQlQTdcwv9-cVNwSS6h1EOVlKHJBP1nK7Q=.42ed0c79-ca03-4b31-8084-1bea69d13765@github.com>
 <94D2yl0BiGL56RmbE82u4mDhsvaCU79qDDpE3iu_Ce8=.71d1bb0a-3090-4937-b124-4ad9d5a3fcef@github.com>
Message-ID: <0_81dNIzQI4tZmRWVVNK_CKQRUtML4397NUe1SKL3rY=.9338ffba-c8be-4e8a-9743-9838f48e95c8@github.com>

On Mon, 26 Oct 2020 17:13:05 GMT, R?mi Forax <github.com+828220+forax at openjdk.org> wrote:

>> We can clarify the new methods and tie them closer to method handle semantics. I suggest the names `asExactInvoker` and `asInvoker`, referencing `MethodHandles.exactInvoker` and `MethodHandles.invoker` respectively. (The term "generic" is really reserved for erased method types, and otherwise used internally as the generic invoker.)
>> 
>> The `VarHandle` documentation already specifies that:
>> 
>>  * <p>
>>  * Invocation of an access mode method behaves as if an invocation of
>>  * {@link MethodHandle#invoke}, where the receiving method handle accepts the
>>  * VarHandle instance as the leading argument.  More specifically, the
>>  * following, where {@code {access-mode}} corresponds to the access mode method
>>  * name:
>>  * <pre> {@code
>>  * VarHandle vh = ..
>>  * R r = (R) vh.{access-mode}(p1, p2, ..., pN);
>>  * }</pre>
>>  * behaves as if:
>>  * <pre> {@code
>>  * VarHandle vh = ..
>>  * VarHandle.AccessMode am = VarHandle.AccessMode.valueFromMethodName("{access-mode}");
>>  * MethodHandle mh = MethodHandles.varHandleExactInvoker(
>>  *                       am,
>>  *                       vh.accessModeType(am));
>>  *
>>  * R r = (R) mh.invoke(vh, p1, p2, ..., pN)
>>  * }</pre>
>>  * (modulo access mode methods do not declare throwing of {@code Throwable}).
>> ...
>> 
>>  We will need to adjust this section, i can help, but first let us reach agreement on this approach.
>
> Paul,
> an invoker has the MethodHandle (resp. VarHandle) as first argument so it's not the same semantics.

I've updated the implementation of accessModeType to work with the ordinal directly. Note that it was using the AccessType ordinal though, so I also had to change the parameter type of accessModeTypeUncached, and the respective implementations, to use AccessType directly (luckily this was possible, since the current implementations all just used the AccessType).

-------------

PR: https://git.openjdk.java.net/jdk/pull/843

From jvernee at openjdk.java.net  Mon Oct 26 19:25:43 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Mon, 26 Oct 2020 19:25:43 GMT
Subject: RFR: 8254354: Add an asExact() VarHandle combinator [v8]
In-Reply-To: <gJ1pTeZZC7tbtwiRsrHcZ1ydfTQhr1MPndGrnGolf14=.dd935929-4f22-4e41-9e0d-99a592ac46b7@github.com>
References: <gJ1pTeZZC7tbtwiRsrHcZ1ydfTQhr1MPndGrnGolf14=.dd935929-4f22-4e41-9e0d-99a592ac46b7@github.com>
Message-ID: <Otz6OIiQ61MIckBQvXDal71I59BU-b_lvx_yPOV_yUg=.6ea0a00c-5ff7-4d60-bd03-5deea1c21aa6@github.com>

> Hi,
> 
> This patch adds an asExact() combinator to VarHandle, that will return a new VarHandle that performs exact type checks, similar to MethodHandle::invokeExact, to help developers catch inexact VarHandle usage, which can lead to performance degradation.
> 
> This is implemented using a boolean flag in VarForm. If the flag is set, the exact type of the invocation is checked against the exact type in the VarForm. If there is a mismatch, a WrongMethodTypeException is thrown.
> 
> Other than that, there is also an asGeneric() combinator added that does the inverse operation (thanks to R?mi for the suggestion). I've also added The `@Hidden` annotation to the VarHandleGuards methods, as well as a type-checking helper method called from the generic invocation lambda form, so that the stack trace we get points at the location where the VarHandle is being used.
> 
> Thanks,
> Jorn
> 
> CSR link: https://bugs.openjdk.java.net/browse/JDK-8255375

Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

  Use AccessType ordinal in guard checks instead of the AccessMode ordinal

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/843/files
  - new: https://git.openjdk.java.net/jdk/pull/843/files/16d9fd0e..8e5fb451

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=843&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=843&range=06-07

  Stats: 164 lines in 3 files changed: 0 ins; 0 del; 164 mod
  Patch: https://git.openjdk.java.net/jdk/pull/843.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/843/head:pull/843

PR: https://git.openjdk.java.net/jdk/pull/843

From github.com+12972156+pmur at openjdk.java.net  Mon Oct 26 19:47:21 2020
From: github.com+12972156+pmur at openjdk.java.net (Paul Murphy)
Date: Mon, 26 Oct 2020 19:47:21 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v8]
In-Reply-To: <_JR-e3ZsRFwvZCR7ws34z5jLjp2kJQ1bu4gyl0RG1XU=.ec3040cf-8147-4dcd-b87d-4fd9be4eb59e@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <nU4nZ9oCthDEi7olxerj_bkmWuITInbbNzJKkb1shkY=.28b4ed81-9733-4981-b6fb-c8e4e3bd335e@github.com>
 <r_UoYsBul9SV88OG2z5qfeCfKQFCF23_DDfdB1LKlzY=.2df9f9a4-d0b6-4ac6-b75b-1cd59022eca6@github.com>
 <_JR-e3ZsRFwvZCR7ws34z5jLjp2kJQ1bu4gyl0RG1XU=.ec3040cf-8147-4dcd-b87d-4fd9be4eb59e@github.com>
Message-ID: <-7PHVafzbyMukuWngsX5bdLvJPubN2KzjMWM2lrQnCs=.a278b608-3e1c-4126-9791-efe18a5d8d5e@github.com>

On Thu, 22 Oct 2020 22:06:11 GMT, CoreyAshford <github.com+51754783+CoreyAshford at openjdk.org> wrote:

>> src/hotspot/cpu/ppc/stubGenerator_ppc.cpp line 3878:
>> 
>>> 3876:             // |    Element    |             |                      |                      |             |             |                      |                      |             |
>>> 3877:             // +===============+=============+======================+======================+=============+=============+======================+======================+=============+
>>> 3878:             // | after vaddubm | 00||b0:0..5 | 00||b0:6..7||b1:0..3 | 00||b1:4..7||b2:0..1 | 00||b2:2..7 | 00||b3:0..5 | 00||b3:6..7||b4:0..3 | 00||b4:4..7||b5:0..1 | 00||b5:2..7 |
>> 
>> An extra line here showing how the 8 6-bit values above get mapping into 6 bytes greatly help my brain out. (likewise for the <P10 case below too)
>
> Just to make sure I understand, you're not asking for a change here, is that right?

I think the first line should also express the initial layout of the 6 bit values similar to the linked algo.  I think changing this comment add an extra line which describes the bits as they leave `vaddubm` would be helpful to understand the demangling here. (e.g the `00aaaaaa 00bbbbbb 00ccccc 00dddddd` comments in the linked paper)

>> src/hotspot/cpu/ppc/stubGenerator_ppc.cpp line 3884:
>> 
>>> 3882:             // |   vec_0x3fs   |  00111111   |       00111111       |       00111111       |  00111111   |  00111111   |       00111111       |       00111111       |  00111111   |
>>> 3883:             // +---------------+-------------+----------------------+----------------------+-------------+-------------+----------------------+----------------------+-------------+
>>> 3884:             // | after vpextd  |   b5:0..7   |       b4:0..7        |       b3:0..7        |   b2:0..7   |   b1:0..7   |       b0:0..7        |       00000000       |  00000000   |
>> 
>> Are theses comments correct or am I misunderstanding this? I read the final result as something starting as `b5:2..7 || b4:4..7|| b5:0..1` from vpextd.
>
> Because the bytes are displayed e15..e8, instead of the other way around, it's hard to follow.  As an example, consider just the last four bytes of the table, but displayed in the reverse order:
> 
> 00||b0:0..5    00||b0:6..7||b1:0..3    00||b1:4..7||b2:0..1    00||b2:2..7
> 
> After vpextd with bit select pattern 00111111 for all bytes:
> 
> b0:0..5||b0:6..7    b1:0..3||1:4..7    b2:0..1||b2:2..7
> =
> b0:0..7    b1:0..7    b2:0..7
> 
> Should I reverse the order of this table with a comment at the top, to explain the reason for the reversal?  It seems like a good idea.

Since you are operating on doublewords here, expressing this as operations on a doubleword instead of bytes would be more intuitive here.  I think the lane mappings for little endian are what throw me off.

-------------

PR: https://git.openjdk.java.net/jdk/pull/293

From bobv at openjdk.java.net  Mon Oct 26 20:24:20 2020
From: bobv at openjdk.java.net (Bob Vandette)
Date: Mon, 26 Oct 2020 20:24:20 GMT
Subject: RFR: 8238263: Create at-requires mechanism for containers [v2]
In-Reply-To: <z5JkXAozR6xstlnQQW7w8x6XhkOgqt0bT3yYh3g7c5s=.c7892630-e8a0-4541-8fff-35962230d14e@github.com>
References: <FsY15A1EzVxl9sqvxg5tqW49LGcUqBRtkQ11JHggBT4=.6786bce8-36cf-4ce6-afc2-a435dddead5d@github.com>
 <z5JkXAozR6xstlnQQW7w8x6XhkOgqt0bT3yYh3g7c5s=.c7892630-e8a0-4541-8fff-35962230d14e@github.com>
Message-ID: <atsobocp1jlWJ3gs9rYuxUCmd0H5SeCJSXY3Sivx5Js=.36203b62-bd06-48b0-ad36-8b25fdd3240c@github.com>

On Mon, 26 Oct 2020 18:13:29 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

>> Please review this change to add an @requires mechanism called "jdk.containerized" to help mark tests that are incompatible with containers.  Users would add "@requires jdk.containerized != true" to the incompatible tests and then use "make test ... OPTIONS=-Djdk.containerized=true" or "bash jib.sh mach5 -- remote-build-and-test ... --test-make-args JTREG=OPTIONS=-Djdk.containerized=true" to exclude those tests when testing with containers.
>
> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8238263: Create at-requires mechanism for containers

Marked as reviewed by bobv (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/844

From iignatyev at openjdk.java.net  Mon Oct 26 20:27:20 2020
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Mon, 26 Oct 2020 20:27:20 GMT
Subject: RFR: 8238263: Create at-requires mechanism for containers [v2]
In-Reply-To: <z5JkXAozR6xstlnQQW7w8x6XhkOgqt0bT3yYh3g7c5s=.c7892630-e8a0-4541-8fff-35962230d14e@github.com>
References: <FsY15A1EzVxl9sqvxg5tqW49LGcUqBRtkQ11JHggBT4=.6786bce8-36cf-4ce6-afc2-a435dddead5d@github.com>
 <z5JkXAozR6xstlnQQW7w8x6XhkOgqt0bT3yYh3g7c5s=.c7892630-e8a0-4541-8fff-35962230d14e@github.com>
Message-ID: <ALh6jlIAEkZaRCn67krR-iql9iKyNXdEjl5zTZAqelY=.d457d5c3-3aad-477e-b5a8-928fe0be4aa4@github.com>

On Mon, 26 Oct 2020 18:13:29 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

>> Please review this change to add an @requires mechanism called "jdk.containerized" to help mark tests that are incompatible with containers.  Users would add "@requires jdk.containerized != true" to the incompatible tests and then use "make test ... OPTIONS=-Djdk.containerized=true" or "bash jib.sh mach5 -- remote-build-and-test ... --test-make-args JTREG=OPTIONS=-Djdk.containerized=true" to exclude those tests when testing with containers.
>
> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8238263: Create at-requires mechanism for containers

LGTM, modulo my earlier comment/doubt about the name, but I don?t think it?s important enough

-------------

Marked as reviewed by iignatyev (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/844

From hseigel at openjdk.java.net  Mon Oct 26 20:37:20 2020
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Mon, 26 Oct 2020 20:37:20 GMT
Subject: RFR: 8238263: Create at-requires mechanism for containers [v2]
In-Reply-To: <ALh6jlIAEkZaRCn67krR-iql9iKyNXdEjl5zTZAqelY=.d457d5c3-3aad-477e-b5a8-928fe0be4aa4@github.com>
References: <FsY15A1EzVxl9sqvxg5tqW49LGcUqBRtkQ11JHggBT4=.6786bce8-36cf-4ce6-afc2-a435dddead5d@github.com>
 <z5JkXAozR6xstlnQQW7w8x6XhkOgqt0bT3yYh3g7c5s=.c7892630-e8a0-4541-8fff-35962230d14e@github.com>
 <ALh6jlIAEkZaRCn67krR-iql9iKyNXdEjl5zTZAqelY=.d457d5c3-3aad-477e-b5a8-928fe0be4aa4@github.com>
Message-ID: <JF5qc57XuzsgzvcwLl4CcxtmX5Bg_gMJh4m0tFKELqQ=.aa477380-3ca4-4867-8ac3-4e60bb74603c@github.com>

On Mon, 26 Oct 2020 20:24:35 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

>> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8238263: Create at-requires mechanism for containers
>
> LGTM, modulo my earlier comment/doubt about the name, but I don?t think it?s important enough

Thanks Bob and Igor!

-------------

PR: https://git.openjdk.java.net/jdk/pull/844

From hseigel at openjdk.java.net  Mon Oct 26 20:37:21 2020
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Mon, 26 Oct 2020 20:37:21 GMT
Subject: Integrated: 8238263: Create at-requires mechanism for containers
In-Reply-To: <FsY15A1EzVxl9sqvxg5tqW49LGcUqBRtkQ11JHggBT4=.6786bce8-36cf-4ce6-afc2-a435dddead5d@github.com>
References: <FsY15A1EzVxl9sqvxg5tqW49LGcUqBRtkQ11JHggBT4=.6786bce8-36cf-4ce6-afc2-a435dddead5d@github.com>
Message-ID: <SYJ0av87MwZPaAgH0nepDS83O8d3wtyDppOv9YQHnhM=.d1990fa3-1c7b-434c-800a-9a59785c74b5@github.com>

On Fri, 23 Oct 2020 18:44:54 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

> Please review this change to add an @requires mechanism called "jdk.containerized" to help mark tests that are incompatible with containers.  Users would add "@requires jdk.containerized != true" to the incompatible tests and then use "make test ... OPTIONS=-Djdk.containerized=true" or "bash jib.sh mach5 -- remote-build-and-test ... --test-make-args JTREG=OPTIONS=-Djdk.containerized=true" to exclude those tests when testing with containers.

This pull request has now been integrated.

Changeset: ca8bba64
Author:    Harold Seigel <hseigel at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ca8bba64
Stats:     10 lines in 3 files changed: 8 ins; 0 del; 2 mod

8238263: Create at-requires mechanism for containers

Reviewed-by: bobv, iignatyev

-------------

PR: https://git.openjdk.java.net/jdk/pull/844

From almatvee at openjdk.java.net  Mon Oct 26 22:52:18 2020
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Mon, 26 Oct 2020 22:52:18 GMT
Subject: Integrated: 8255206: [macos] LicenseTest fails on macOS 11
In-Reply-To: <TNyJYXd93S-rihjFcaejAUAjgjH1dZDQflB9haFdjjI=.12295fd9-9c9b-45c9-a733-f8bc42ea131f@github.com>
References: <TNyJYXd93S-rihjFcaejAUAjgjH1dZDQflB9haFdjjI=.12295fd9-9c9b-45c9-a733-f8bc42ea131f@github.com>
Message-ID: <CjNzPwcKzrO1ZvXfjN5UW1-iPLnp9j4GUoCXkr3h4Jw=.f4774810-4337-42e6-bed4-1ea92d155213@github.com>

On Sat, 24 Oct 2020 00:49:12 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> I did not reproduce issue with license is not shown as per SQE report. It work as expected. However, jpackage fails due to unflatten/flatten being removed from hdiutil on macOS 11. I am not sure why it was needed, probably some legacy code. Without unflatten/flatten everything works as expected on macOS 11 and 10.5.7.

This pull request has now been integrated.

Changeset: 8ca59c9e
Author:    Alexander Matveev <almatvee at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/8ca59c9e
Stats:     18 lines in 1 file changed: 0 ins; 18 del; 0 mod

8255206: [macos] LicenseTest fails on macOS 11

Reviewed-by: asemenyuk, herrick

-------------

PR: https://git.openjdk.java.net/jdk/pull/847

From dholmes at openjdk.java.net  Mon Oct 26 22:55:32 2020
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 26 Oct 2020 22:55:32 GMT
Subject: RFR: 8255231: Avoid upcalls when initializing the statSampler [v4]
In-Reply-To: <U1H6HTExg6qMq3JuHkZtlkFW1MpRtRz3hjcn0nZSYd0=.aca55583-d1ec-4d5a-92f9-0fef79e333bc@github.com>
References: <Szazq59X7qoDaQ51HtEeE4N2BarTHiiRFqbUI7DrfEk=.7199b11d-06fb-485c-b9cc-856de34714d6@github.com>
 <U1H6HTExg6qMq3JuHkZtlkFW1MpRtRz3hjcn0nZSYd0=.aca55583-d1ec-4d5a-92f9-0fef79e333bc@github.com>
Message-ID: <lii6e0xHv1-8WWiYtiyoh5FgujpnVgKhBOkfcJyer94=.416f2682-ab27-469b-98a0-1182da7d9a8a@github.com>

On Mon, 26 Oct 2020 12:49:43 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Current implementation of the statSampler does upcalls to System.getProperty to collect values for a number of properties that are all provided by the VM itself. And since the sampling starts before any user code run then no property can have changed.
>> 
>> I suggest refactoring the code so that no upcalls are made normally - while asserting this invariant holds using assert-only upcalls. 
>> 
>> This is a small startup optimization - reducing the startup sequence by approx. 300k instructions and 70k branches in my linux-x64 setup.
>
> Claes Redestad has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 21 additional commits since the last revision:
> 
>  - Address review comments from David Holmes
>  - Merge branch 'master' into com_ns
>  - Refactor to remove stable_java_property_counters and clarify comments
>  - Merge branch 'master' into com_ns
>  - Revert unrelated changes to perfData
>  - Merge branch 'master' into com_ns
>  - Improve comments
>  - typo
>  - Missing definition
>  - Extract the shorthand java.version from VersionProps and use it in StatSampler
>  - ... and 11 more: https://git.openjdk.java.net/jdk/compare/145a3876...8572159f

Thanks for making the suggested changes.

I think we need a further RFE to add some error checking for the sizes of the various property strings in relation to the fixed size arrays that have been allocated to them.

Thanks,
David

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/802

From mchung at openjdk.java.net  Tue Oct 27 01:26:17 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 27 Oct 2020 01:26:17 GMT
Subject: RFR: 8159746: (proxy) Support for default methods
In-Reply-To: <W6qIb_NPGRUpQd_obRiIumwbXSTDheSdg-qnkc3cZ90=.f1f46290-3b7c-4e88-994f-5d19e0134256@github.com>
References: <kw2VXh3vTFf1zgfd4biXA41OKffZ5oU7KT23tXAxgUA=.bcf14ffc-4dba-4c9c-8754-184172c5acbd@github.com>
 <U-6RiCpFVIrhLztPN6opiPcpFtxValDzU-K7WWFZM-4=.6bc8aaa4-636a-4664-b380-4c4af00513bd@github.com>
 <-cLIJ8pFHtnNoJMHV3aXI7XMJWp4Jrutc8Xn5PG0OK8=.d2cd87ab-3592-4524-ad85-05444c43689b@github.com>
 <r0UK2qjnmgeTNDDSWaSLPAj3QRgx_4YB82ielllO7jM=.fa615bc0-db49-4a74-b842-793f8f5209bb@github.com>
 <1T8kXDZN1bhHr4c8v4SQsImeBySCqTfX-u3_jzvyocA=.b4957400-9a33-4b6e-8475-329642a5888c@github.com>
 <XIux-dY0JXHRafHk48kVNXId9r-HSceNSytBojDxelY=.872e74cb-b064-406e-b71f-13c90ec7fbbc@github.com>
 <j4t2vT0SnwnU7lhKRlXtk967d-K6nA0EqHrqNbba7W0=.dc05dba6-bf7e-4606-8a02-9c2bad4b3b58@github.com>
 <fmVtPcBdgMuZOPm2qx3Q3znVZM7JgQPkhPAVLtwkOhE=.2d8b8447-cfae-4cb3-9a7c-6567a881231f@github.com>
 <GSeWP29fAIUFSk0CYsC557w52CuLqeUWwHNK9maltwI=.3d5f002e-6b74-4a57-a5d8-244d27da9dde@github.com>
 <GF8iEOkMUEL2dYB0HytFIc9gyeeUJ_KP0ImlqFsul2Y=.894afc05-9310-43e1-a308-8f7d71dc572b@github.com>
 <HvtDex3cmiv7XeTMITOroYfu74amSGQavQ_
 BAmVzmXw=.223be989-7c20-4ba4-ac0d-013d2b75a8cb@github.com>
 <IqRiLphFPBpGiKAnMJXqxjie9YeZ03rcE-qG1s92BLw=.d4fd5e92-5067-40df-8a0b-1dfd3d6e23af@github.com>
 <Y0hE51G3YefI6NY1O_E6VoZSKwxE78S1hv6fEatmOG8=.0a2c686c-d9ad-418c-8c1b-49addb8a54b1@github.com>
 <QrNk57L2PWQhJjzYiGTsvYyGIPAfK7bP_kANtTR-2uM=.3e5ce990-f8ea-4751-8147-27a8a9dad40d@github.com>
 <9JNNUzfV3PSvKtSg2a_zyYJmgEn3sZL9cb5sfqemk2o=.f1ef7fb7-bdd5-44ed-98c8-59213e9094f9@github.com>
 <zWGhaC8YB5I0XgffiR7o_YT5gSp9Gbj8Drtt23brl-c=.1e59f0e4-bbe3-4fb2-94dc-c55fc862f091@github.com>
 <LljojgqBhEi6tFptsbmu1jS-Xx7lYEXm9tRkkPqDGzE=.3d7d6a37-1042-4539-88d1-9f4cf5378128@github.com>
 <Gn33ydZNxqOpWUrmYiWJadMF0mukI2MR85EtgrV4D1I=.958521f2-1167-4a68-b513-e10bba37ae18@github.com>
 <NMXKaHql9XjndqPgyoN1Lasa9H8ugl8-ltD1j2XiT9Y=.3ff8871e-0f9d-40ea-8f35-e804a9afcbd5@github.com>
 <yzFe02HJ2qt5tT8tY9ZOofnKld93x1PM5U7AToTABJs=.439c213b-94b9-488f-bb6d-a835a86c527f@github.com>
 <BoATjx7PPcLpINJVC5HM77UKMriIUqnnhcBowkJRlvM=.1221e3e1-ed27-4618-8365-dcd903d27f60@
 github.com>
 <yN0JJE9mBkqz9Ijbw4FYinv08tcnxiZHAGyarXBF9CY=.50429cb9-181a-447e-90a0-e0a0a836812e@github.com>
 <CoqZRJ39DVdNI9wzS372aAG3ZIB7hrIrndaO5VrsmBA=.f78629d2-3409-44c1-9e66-7951bbd630e6@github.com>
 <W6qIb_NPGRUpQd_obRiIumwbXSTDheSdg-qnkc3cZ90=.f1f46290-3b7c-4e88-994f-5d19e0134256@github.com>
Message-ID: <nALY_XHf4_MGKZHIzpIRbqLEG22ySg0NZ8mQbun7up0=.69d14612-31a4-4533-924c-01768ed50be1@github.com>

On Fri, 23 Oct 2020 10:32:27 GMT, Peter Levart <plevart at openjdk.org> wrote:

>>> NewInvocationHandler/DefaultMethodInvoker feels a bit awkward. If I have it right, to use it as a lambda expression to Proxy.newProxyInterface would require casting to NewInvocationHandler. I also need to be careful when using the invoker and not call it with a non-default method.
>> 
>> Yes it requires casting to `NewInvocationHandler` or  assign the lambda in a local variable.
>
> Hi Mandy,
> 
> I think what matters here is a public surface area - what user sees. The API friendliness is the 1st aspect and very close to that is performance on the 2nd place. How complicated things are in the back is not unimportant, but very far from the leading two. I think this is how alternatives should be compared.
> 
> What I have done in my last attempt (https://github.com/mlchung/jdk/pull/4) is, admittedly, quite large from API surface. New `InvocationHandler2` interface taking additional `InvocationHandler2.SuperInvoker` callback + new overloaded static factory method `Proxy.newProxyInstance`. Additionally, internal checks needed to verify access at `newProxyInstance`-time are quite complicated since `InvocationHandler2` is a super-type of `InvocationHandler` and therefore the code has to check that the default implementation of `InvocationHandler.invoke(SuperInvoker, ...)` method is not overridden or else additional checks must be performed. This leads to complicated specification as to when access exceptions are thrown. From performance perspective, this variant showed least per-invocation overhead so far:
> 
> Benchmark               Mode  Cnt   Score   Error  Units
> 
> ProxyBench.implClass    avgt    5   3.777 ? 0.003  ns/op
> ProxyBench.implProxy    avgt    5  20.282 ? 0.585  ns/op
> ProxyBench.ppImplClass  avgt    5   3.752 ? 0.002  ns/op
> ProxyBench.ppImplProxy  avgt    5  19.790 ? 0.335  ns/op
> 
> Your `DelegatingInvocationHandler` abstract class is nice and simple, but unfortunately not lambda-friendly. Will this hinder its use? I don't know. Alan says that this feature will mostly be for "experts", but even they like to use lambdas. The performance is quite OK as runtime per-invocation checks are not very expensive, just ~ 50% slower than my attempt above. Note that the allocation of 96 bytes per invocation is due to boxing 3 primitive argument ints into Integers which is unavoidable:
> 
> Benchmark                                                Mode  Cnt     Score      Error   Units
> 
> ProxyBench.implClass                                     avgt    5     3.765 ?    0.028   ns/op
> ProxyBench.implProxy                                     avgt    5    29.812 ?    0.180   ns/op
> ProxyBench.ppImplClass                                   avgt    5     3.705 ?    0.110   ns/op
> ProxyBench.ppImplProxy                                   avgt    5    31.209 ?    0.900   ns/op
> 
> ProxyBench.implClass:?gc.alloc.rate.norm                 avgt    5    ? 10??               B/op
> ProxyBench.implProxy:?gc.alloc.rate.norm                 avgt    5    96.004 ?    0.001    B/op
> ProxyBench.ppImplClass:?gc.alloc.rate.norm               avgt    5    ? 10??               B/op
> ProxyBench.ppImplProxy:?gc.alloc.rate.norm               avgt    5    96.004 ?    0.001    B/op
> 
> (NOTE: I noticed a possibility of a concurrent race condition in `Proxy.newProxyInstance` that could be used to fool the proxy interfaces access check - the array of interfaces is not defensively cloned)
> 
> Your `NewInvocationHandler` as a subinterface of `InvocationHandler` that overrides the InvocationHandler.invoke(Object proxy, ... and wires it to new abstract method taking additional DefaultMethodInvoker parameter seems similar to my last attempt, just subtype roles of old and new interfaces are reversed. This means it is easier to check whether the invocation handler has access to the super default methods or not (handler instanceof NewInvocationHandler) and adjust access checks in Proxy.newProxyInstance accordingly. But, as a consequence, the DefaultMethodInvoker instance has to be created for each invocation. You could also add an overloaded Proxy.newProxyInstance method to accept a lambda with 4 parameters (NewInvocationHandler), so this variant could be made user-friendly too, not requiring a cast. The performance is a little slower then abstract handler class. Also, the allocation of new instance of DefaultMethodInvoker per invocation seems unable to be optimized away by JI
 T escape analysis (maybe the DefaultMethodInvoker.invoke is to big to be inlined), so we have 16 additional bytes allocated per invocation:
> 
> Benchmark                                                Mode  Cnt     Score     Error   Units
> 
> ProxyBench.implClass                                     avgt    5     3.760 ?   0.049   ns/op
> ProxyBench.implProxy                                     avgt    5    34.260 ?   0.993   ns/op
> ProxyBench.ppImplClass                                   avgt    5     3.745 ?   0.008   ns/op
> ProxyBench.ppImplProxy                                   avgt    5    34.247 ?   0.743   ns/op
> 
> ProxyBench.implClass:?gc.alloc.rate.norm                 avgt    5    ? 10??              B/op
> ProxyBench.implProxy:?gc.alloc.rate.norm                 avgt    5   112.005 ?   0.001    B/op
> ProxyBench.ppImplClass:?gc.alloc.rate.norm               avgt    5    ? 10??              B/op
> ProxyBench.ppImplProxy:?gc.alloc.rate.norm               avgt    5   112.005 ?   0.001    B/op
> 
> 
> From above 3 variants, I agree the `DelegatingInvocationHandler` abstract class seems to be most promising. But I have been thinking more about lambdas and have another idea that actually doesn't require any new types. Just an overloaded Proxy.newProxyInstance static method:
> 
> public static Object newProxyInstance(
>     ClassLoader loader,
>     Class<?>[] interfaces, 
>     Function<? super InvocationHandler, ? extends InvocationHandler> handlerFactory
> )
> 
> Here's the prototype:
> 
> https://github.com/plevart/jdk/commits/proxy-default-method-alt-api4
> 
> This is a patch against current https://github.com/openjdk/jdk, but all your latest "unrelated" changes (proxy class package/module) are included too. I can rebase this onto your https://github.com/mlchung/jdk/tree/proxy-default-method branch if required.
> 
> The performance of this one is the same as my previous alternative API 2:
> 
> Benchmark                                                Mode  Cnt     Score     Error   Units
> 
> ProxyBench.implClass                                     avgt    5     3.700 ?   0.013   ns/op
> ProxyBench.implProxy                                     avgt    5    20.264 ?   0.551   ns/op
> ProxyBench.ppImplClass                                   avgt    5     3.743 ?   0.028   ns/op
> ProxyBench.ppImplProxy                                   avgt    5    20.274 ?   0.180   ns/op
> 
> ProxyBench.implClass:?gc.alloc.rate.norm                 avgt    5    ? 10??              B/op
> ProxyBench.implProxy:?gc.alloc.rate.norm                 avgt    5    96.003 ?   0.001    B/op
> ProxyBench.ppImplClass:?gc.alloc.rate.norm               avgt    5    ? 10??              B/op
> ProxyBench.ppImplProxy:?gc.alloc.rate.norm               avgt    5    96.003 ?   0.001    B/op
> 
> So how does this compare to DelegatingInvocationHandler? It surely is more lambda-friendly and performance-wise it is the best we have so far. It is also not very complicated internally. The changes to ProxyGenerator are just to accomodate for new static final field holding the super-default-method InvocationHandler. Alternatively a ClassValue could be used for that without changes to ProxyGenerator albeit with somewhat bigger footprint per proxy class.
> 
> Now I would like to discuss one thing that relates to all implmenentations so far. Super default method invocation is currently modeled by the `Method.invoke` API, meaning that it throws `InvocationTargetException` wrapping the target exception thrown by the invoked method. But since this API is to be used from withing `InvocationHandler.invoke` implementations, such `InvocationTargetException` would typically need to be caught, unwrapped and its target exception re-thrown to honour the contract of the declared exceptions of the proxy method. If someone forgot to do that and leave `InvocationTargetException` to be thrown from `InvocationHandler.invoke` (and it would be very easy to forget that since that method is declared to throw `Throwable`), such `InvocationTargetException` would be wrapped again with `UndeclaredThrowableException` as per Proxy API behavior. So wouldn't it be better for the super-invoke API to throw exact exceptions that the invoked methods are throwing? No cat
 ch/re-throw unwrapped gymnastics would be necessary in the `InvocationHandler` implementations and forgetting to do that would not be possible. Such non-wrapping super-invoke API does not allow to distinguish between IllegalArgumentException(s) thrown by the invoked method and IllegalArgumentException(s) thrown from the API itself due to arguments incompatible with method signature though, but would one really want to distinguish them? Typically not. My alternative API 4 above uses existing `InvocationHandle.invoke` API for forwarding invocation to super default methods and this API already declares that it throws `Throwable` so it allows passing exceptions unwrapped, but current implementation still wraps exceptions thrown by the invoked method with IllegalArgumentException. If we decide that it is better to not wrap them, this can be trivially implemented.
> 
> Peter

Hi Peter, 

Just a quick reply.  I like your idea for a `newProxyInstance` to take an invocation handler factory.   I went through the security implication and also looked into ways to avoid the need of `protected static getSuperHandler(Lookup)` method.  I haven't checked the performance and also updating the javadoc.   My prototype is in the proxy-default-method-4 branch.   I will come back to this tomorrow and respond to the other comments you had.

This approach seems promising.

-------------

PR: https://git.openjdk.java.net/jdk/pull/313

From rriggs at openjdk.java.net  Tue Oct 27 03:09:32 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 27 Oct 2020 03:09:32 GMT
Subject: RFR: 8251989: Hex formatting and parsing utility [v9]
In-Reply-To: <HSEn47GMS1K3g57mrTZeQk-WZHl3pKGHpX_OOf8VnsU=.740863c2-f9e4-43c4-b500-614aab4078b1@github.com>
References: <HSEn47GMS1K3g57mrTZeQk-WZHl3pKGHpX_OOf8VnsU=.740863c2-f9e4-43c4-b500-614aab4078b1@github.com>
Message-ID: <kq3eysudL5ES5M41vZvEHRO9BLv7uSJM1BUy4hcWFpg=.0ba9b80f-4a14-46b4-ba22-2b664efd0fdd@github.com>

> java.util.HexFormat utility:
> 
>  - Format and parse hexadecimal strings, with parameters for delimiter, prefix, suffix and upper/lowercase
>  - Static factories and builder methods to create HexFormat copies with modified parameters.
>  - Consistent naming of methods for conversion of byte arrays to formatted strings and back: formatHex and parseHex
>  - Consistent naming of methods for conversion of primitive types: toHexDigits... and fromHexDigits...
>  - Prefix and suffixes now apply to each formatted value, not the string as a whole
>  - Using java.util.Appendable as a target for buffered conversions so output to Writers and PrintStreams
>    like System.out are supported in addition to StringBuilder. (IOExceptions are converted to unchecked exceptions)
>  - Immutable and thread safe, a "value-based" class
> 
> See the [HexFormat javadoc](http://cr.openjdk.java.net/~rriggs/8251989-hex-formatter/java.base/java/util/HexFormat.html) for details.
> 
> Review comments and suggestions welcome.

Roger Riggs has updated the pull request incrementally with two additional commits since the last revision:

 - The HexFormat API indexing model for array and string ranges is changed
   to describe the range using 'fromIndex (inclusive)' and 'toIndex (exclusive)'.
   
   Initially, it was specified as 'index' and 'length'. However, both byte arrays
   and strings used in the HexFormat API typically use fromIndex and toIndex
   to describe ranges.  Using the same indexing model can prevent mistakes.
   
   The change affects the methods and corresponding tests:
   
       formatHex(byte[] bytes, int fromIndex, int toIndex)
       formatHex(A out, byte[] bytes, int fromIndex, int toIndex)
       parseHex(char[] chars, int fromIndex, int toIndex)
       parseHex(CharSequence string, int fromIndex, int toIndex)
       fromHexDigits(CharSequence string, int fromIndex, int toIndex)
       fromHexDigitsToLong(CharSequence string, int fromIndex, int toIndex)
 - - Added @see and @link references to Integer.toHexString and Long.toHexString
   - Clarified parsing is case insensistive in various parse and fromXXX methods
   - Source level cleanup based on review comments
   - Expanded some javadoc tag text to make it more descriptive
   - Consistent use of 'hexadecimal' vs 'hex'

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/482/files
  - new: https://git.openjdk.java.net/jdk/pull/482/files/2b493d37..2aeab7d7

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=482&range=08
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=482&range=07-08

  Stats: 205 lines in 4 files changed: 25 ins; 8 del; 172 mod
  Patch: https://git.openjdk.java.net/jdk/pull/482.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/482/head:pull/482

PR: https://git.openjdk.java.net/jdk/pull/482

From rriggs at openjdk.java.net  Tue Oct 27 03:09:32 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 27 Oct 2020 03:09:32 GMT
Subject: RFR: 8251989: Hex formatting and parsing utility [v8]
In-Reply-To: <k28XRI-6v9yND_qcB-kyW7uT1Tve9ok2ypzta4Ur08M=.25f3984d-f99d-40fc-b059-73876285991a@github.com>
References: <HSEn47GMS1K3g57mrTZeQk-WZHl3pKGHpX_OOf8VnsU=.740863c2-f9e4-43c4-b500-614aab4078b1@github.com>
 <lX-d05Nj6nFlHSW_d-xVM0vihr1UQtxcFyCpN282hVo=.8e23858e-f014-4acb-83ed-b1310835b42a@github.com>
 <xyk8nbJWRVuI6CJizXM34C9vAvhwKCOStxNHu1mkhQY=.866fa22e-e973-4eab-9e8f-e2c7c20cbe97@github.com>
 <k28XRI-6v9yND_qcB-kyW7uT1Tve9ok2ypzta4Ur08M=.25f3984d-f99d-40fc-b059-73876285991a@github.com>
Message-ID: <t73azKgkjsVuL-Z2qyXOL3wO6E0Ji1csO42u2rP2yeg=.d7b38133-0ecf-4d9f-a888-a13ee65f56f7@github.com>

On Fri, 23 Oct 2020 16:34:54 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Do you want to refactor some of the classes where `HexFormat` would be a well-suited replacement for the current code, and what do you think about my other previous review comments (mostly formatting related)?
>> The bridgekeeper bot was so kind and censored my [previous comment](https://github.com/openjdk/jdk/pull/482#issuecomment-710709003), but apparently it can't handle review comments yet ...
>> 
>> And no, I am not going to sign the [OpenJDK Terms of Use](https://openjdk.java.net/legal/tou/terms) for a simple pull request comment, especially when the Terms of Use document is quite long and contains the following:
>>> You hereby grant to Oracle and all Users a royalty-free, perpetual, irrevocable, worldwide, non-exclusive and fully sub-licensable right and license under Your intellectual property rights to reproduce, modify, adapt, publish, translate, create derivative works from, distribute, perform, display and use Your Submissions (in whole or part) and to incorporate or implement them in other works in any form, media, or technology now known or later developed. This includes, without limitation, the right to incorporate or implement the Submission into any product or service, and to display, market, sublicense and distribute the Submissions as incorporated or embedded in any product or service distributed or offered by Oracle without compensation to you.
>> 
>> (Might be good to rework that to actually encourage contributions. I am kind of surprised that any company is willing to contribute to the OpenJDK under these terms.)
>> 
>> Sorry for driving this pull request off-topic, I will stop all interaction here and will not bother you any further here if that is desired. Below is the original comment:
>> 
>> -----
>> 
>> It might also be good to clarify in the documentation that `parseHex(...)` is case insensitive. This is currently not obvious and one might expect that it respects `isUpperCase()`.
>> 
>> Additionally there are quite a lot places within the JDK code where this new class could be used. I have picked some where it would definitely be an improvement (but omitted test classes):
>> <details>
>> <summary>Classes</summary>
>> <ul>
>> <li><a href="https://github.com/openjdk/jdk/blob/83ea863122e1d58527c8bf3cd178acf4d0c54f30/src/java.base/share/classes/java/net/HostPortrange.java#L94"><code>java.base</code> <code>java.net.HostPortrange</code></li>
>> <li><a href="https://github.com/openjdk/jdk/blob/83ea863122e1d58527c8bf3cd178acf4d0c54f30/src/java.base/share/classes/jdk/internal/module/ModuleHashes.java#L215"><code>java.base</code> <code>jdk.internal.module.ModuleHashes</code></li>
>> <li><a href="https://github.com/openjdk/jdk/blob/83ea863122e1d58527c8bf3cd178acf4d0c54f30/src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java#L544"><code>java.base</code> <code>sun.net.www.protocol.http.DigestAuthentication</code></li>
>> <li><a href="https://github.com/openjdk/jdk/blob/83ea863122e1d58527c8bf3cd178acf4d0c54f30/src/java.base/share/classes/sun/security/provider/AbstractDrbg.java#L738"><code>java.base</code> <code>sun.security.provider.AbstractDrbg</code></li>
>> <li><a href="https://github.com/openjdk/jdk/blob/83ea863122e1d58527c8bf3cd178acf4d0c54f30/src/java.base/share/classes/sun/security/provider/certpath/ResponderId.java#L269"><code>java.base</code> <code>sun.security.provider.certpath.ResponderId</code></li>
>> <li><a href="https://github.com/openjdk/jdk/blob/83ea863122e1d58527c8bf3cd178acf4d0c54f30/src/java.base/share/classes/sun/security/ssl/Utilities.java#L39"><code>java.base</code> <code>sun.security.ssl.Utilities</code></li>
>> <li><a href="https://github.com/openjdk/jdk/blob/83ea863122e1d58527c8bf3cd178acf4d0c54f30/src/java.base/share/classes/sun/security/util/Debug.java#L323"><code>java.base</code> <code>sun.security.util.Debug</code></li>
>> <li><a href="https://github.com/openjdk/jdk/blob/83ea863122e1d58527c8bf3cd178acf4d0c54f30/src/java.base/share/classes/sun/security/util/HexDumpEncoder.java"><code>java.base</code> <code>sun.security.util.HexDumpEncoder</code></li>
>> <li><a href="https://github.com/openjdk/jdk/blob/83ea863122e1d58527c8bf3cd178acf4d0c54f30/src/java.base/share/classes/sun/security/util/ManifestEntryVerifier.java#L244"><code>java.base</code> <code>sun.security.util.ManifestEntryVerifier</code></li>
>> <li><a href="https://github.com/openjdk/jdk/blob/83ea863122e1d58527c8bf3cd178acf4d0c54f30/src/java.base/share/classes/sun/security/util/SignatureFileVerifier.java#L753"><code>java.base</code> <code>sun.security.util.SignatureFileVerifier</code></li>
>> <li><a href="https://github.com/openjdk/jdk/blob/83ea863122e1d58527c8bf3cd178acf4d0c54f30/src/java.base/share/classes/sun/security/x509/AVA.java#L742"><code>java.base</code> <code>sun.security.x509.AVA</code></li>
>> <li><a href="https://github.com/openjdk/jdk/blob/83ea863122e1d58527c8bf3cd178acf4d0c54f30/src/java.base/share/classes/sun/security/x509/AVA.java#L811"><code>java.base</code> <code>sun.security.x509.AVA</code></li>
>> <li><a href="https://github.com/openjdk/jdk/blob/83ea863122e1d58527c8bf3cd178acf4d0c54f30/src/java.base/share/classes/sun/security/x509/AVA.java#L889"><code>java.base</code> <code>sun.security.x509.AVA</code></li>
>> <li><a href="https://github.com/openjdk/jdk/blob/83ea863122e1d58527c8bf3cd178acf4d0c54f30/src/java.base/share/classes/sun/security/x509/AVA.java#L967"><code>java.base</code> <code>sun.security.x509.AVA</code></li>
>> <li><a href="https://github.com/openjdk/jdk/blob/83ea863122e1d58527c8bf3cd178acf4d0c54f30/src/java.base/share/classes/sun/security/x509/AVA.java#L1111"><code>java.base</code> <code>sun.security.x509.AVA</code></li>
>> <li><a href="https://github.com/openjdk/jdk/blob/83ea863122e1d58527c8bf3cd178acf4d0c54f30/src/java.base/share/classes/sun/security/x509/X509CertImpl.java#L1982"><code>java.base</code> <code>sun.security.x509.X509CertImpl</code></li>
>> <li><a href="https://github.com/openjdk/jdk/blob/83ea863122e1d58527c8bf3cd178acf4d0c54f30/src/java.naming/share/classes/com/sun/jndi/ldap/LdapName.java#L837"><code>java.naming</code> <code>com.sun.jndi.ldap.LdapName</code></li>
>> <li><a href="https://github.com/openjdk/jdk/blob/83ea863122e1d58527c8bf3cd178acf4d0c54f30/src/java.naming/share/classes/javax/naming/ldap/Rdn.java#L568"><code>java.naming</code> <code>javax.naming.ldap.Rdn</code></li>
>> <li><a href="https://github.com/openjdk/jdk/blob/83ea863122e1d58527c8bf3cd178acf4d0c54f30/src/java.security.jgss/share/classes/sun/security/krb5/KrbApReq.java#L314"><code>java.security.jgss</code> <code>sun.security.krb5.KrbApReq</code></li>
>> <li><a href="https://github.com/openjdk/jdk/blob/83ea863122e1d58527c8bf3cd178acf4d0c54f30/src/java.security.jgss/share/classes/sun/security/krb5/internal/ktab/KeyTabEntry.java#L80"><code>java.security.jgss</code> <code>sun.security.krb5.internal.ktab.KeyTabEntry</code></li>
>> <li><a href="https://github.com/openjdk/jdk/blob/83ea863122e1d58527c8bf3cd178acf4d0c54f30/src/java.smartcardio/share/classes/sun/security/smartcardio/PCSC.java#L174"><code>java.smartcardio</code> <code>sun.security.smartcardio.PCSC</code></li>
>> <li><a href="https://github.com/openjdk/jdk/blob/83ea863122e1d58527c8bf3cd178acf4d0c54f30/src/jdk.compiler/share/classes/com/sun/tools/javac/file/BaseFileManager.java#L355"><code>jdk.compiler</code> <code>com.sun.tools.javac.file.BaseFileManager</code></li>
>> <li><a href="https://github.com/openjdk/jdk/blob/83ea863122e1d58527c8bf3cd178acf4d0c54f30/src/jdk.compiler/share/classes/com/sun/tools/javac/main/Main.java#L490"><code>jdk.compiler</code> <code>com.sun.tools.javac.main.Main</code></li>
>> <li><a href="https://github.com/openjdk/jdk/blob/83ea863122e1d58527c8bf3cd178acf4d0c54f30/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Util.java#L158"><code>jdk.crypto.cryptoki</code> <code>sun.security.pkcs11.P11Util</code></li>
>> <li><a href="https://github.com/openjdk/jdk/blob/83ea863122e1d58527c8bf3cd178acf4d0c54f30/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/Functions.java#L168"><code>jdk.crypto.cryptoki</code> <code>sun.security.pkcs11.wrapper.Functions</code></li>
>> <li><a href="https://github.com/openjdk/jdk/blob/83ea863122e1d58527c8bf3cd178acf4d0c54f30/src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.java/src/org/graalvm/compiler/java/LambdaUtils.java#L129"><code>jdk.internal.vm.compiler</code> <code>org.graalvm.compiler</code></li>
>> <li><a href="https://github.com/openjdk/jdk/blob/83ea863122e1d58527c8bf3cd178acf4d0c54f30/src/jdk.jartool/share/classes/sun/tools/jar/Main.java#L2011"><code>jdk.jartool</code> <code>sun.tools.jar.Main</code></li>
>> <li><a href="https://github.com/openjdk/jdk/blob/83ea863122e1d58527c8bf3cd178acf4d0c54f30/src/jdk.jconsole/share/classes/sun/tools/jconsole/AboutDialog.java#L83"><code>jdk.jconsole</code> <code>sun.tools.jconsole.AboutDialog</code></li>
>> <li><a href="https://github.com/openjdk/jdk/blob/83ea863122e1d58527c8bf3cd178acf4d0c54f30/src/jdk.jconsole/share/classes/sun/tools/jconsole/ConnectDialog.java#L287"><code>jdk.jconsole</code> <code>sun.tools.jconsole.ConnectDialog</code></li>
>> <li><a href="https://github.com/openjdk/jdk/blob/83ea863122e1d58527c8bf3cd178acf4d0c54f30/src/jdk.jconsole/share/classes/sun/tools/jconsole/ConnectDialog.java#L595"><code>jdk.jconsole</code> <code>sun.tools.jconsole.ConnectDialog</code></li>
>> <li><a href="https://github.com/openjdk/jdk/blob/83ea863122e1d58527c8bf3cd178acf4d0c54f30/src/jdk.jconsole/share/classes/sun/tools/jconsole/HTMLPane.java#L61"><code>jdk.jconsole</code> <code>sun.tools.jconsole.HTMLPane</code></li>
>> <li><a href="https://github.com/openjdk/jdk/blob/83ea863122e1d58527c8bf3cd178acf4d0c54f30/src/jdk.jconsole/share/classes/sun/tools/jconsole/inspector/XArrayDataViewer.java#L79"><code>jdk.jconsole</code> <code>sun.tools.jconsole.inspector.XArrayDataViewer</code></li>
>> <li><a href="https://github.com/openjdk/jdk/blob/83ea863122e1d58527c8bf3cd178acf4d0c54f30/src/jdk.jdeps/share/classes/com/sun/tools/javap/AttributeWriter.java#L1137"><code>jdk.jdeps</code> <code>com.sun.tools.javap.AttributeWriter</code></li>
>> <li><a href="https://github.com/openjdk/jdk/blob/83ea863122e1d58527c8bf3cd178acf4d0c54f30/src/jdk.jdeps/share/classes/com/sun/tools/javap/ClassWriter.java#L149"><code>jdk.jdeps</code> <code>com.sun.tools.javap.ClassWriter</code></li>
>> <li><a href="https://github.com/openjdk/jdk/blob/83ea863122e1d58527c8bf3cd178acf4d0c54f30/src/jdk.jlink/share/classes/jdk/tools/jmod/JmodTask.java#L417"><code>jdk.jlink</code> <code>jdk.tools.jmod.JmodTask</code></li>
>> </ul>
>
> Hi,
> 
> The adoption of the HexFormat API by other JDK classes is a separate task.
> In the security area, a pre-Git webrev included the changes, when the 
> API settles
> that will come back to the fore.? In many of the security tests, it may 
> be better to
> utilize the test library addition that can format ASN.1/DER streams to 
> make the output easier to read.
> 
> The point about case insensitive parsing can be reinforced.
> 
> Regards, Roger

The HexFormat javadoc is updated to include the `fromIndex`/`toIndex' API changes.
   http://cr.openjdk.java.net/~rriggs/8251989-hex-formatter/java.base/java/util/HexFormat.html

The previous `index`/`length' indexed API is retained for comparison.
   http://cr.openjdk.java.net/~rriggs/8251989-hex-formatter-index-length/docs/api/java.base/java/util/HexFormat.html

-------------

PR: https://git.openjdk.java.net/jdk/pull/482

From dongbo at openjdk.java.net  Tue Oct 27 06:32:29 2020
From: dongbo at openjdk.java.net (Dong Bo)
Date: Tue, 27 Oct 2020 06:32:29 GMT
Subject: RFR: 8255246: AArch64: Implement BigInteger shiftRight and
 shiftLeft accelerator/intrinsic [v2]
In-Reply-To: <r6hSDpfXd-0pLBF7HqjeUtDzunl7nCUzbCQtqGP1_rw=.fe8d5cd1-2c1d-4d2d-ac6f-fc1d9ac3ebc2@github.com>
References: <r6hSDpfXd-0pLBF7HqjeUtDzunl7nCUzbCQtqGP1_rw=.fe8d5cd1-2c1d-4d2d-ac6f-fc1d9ac3ebc2@github.com>
Message-ID: <SXWanOunKxTIZhkADM5Pr6Udo6HGchzjPwfLAIWCmcs=.39401cf1-f3ec-4c91-b157-244f98a685aa@github.com>

> BigInteger.shiftRightImplWorker and BigInteger.shiftLeftImplWorker are not intrinsified on aarch64, which have been done on x86_64.
> We can implement them via USHL NEON instruction (register), which handles four integers one time at most, against just integer C2 asm-code processed.
> The usage of USHL can be found at: https://developer.arm.com/documentation/dui0801/g/A64-SIMD-Vector-Instructions/USHL--vector-?lang=en
> 
> Patch passed jtreg tier1-3 tests on our aarch64 server.
> Tests in test/jdk/java/math/BigInteger/* runned specially for the correctness of the implementation and passed.
> 
> We tested test/micro/org/openjdk/bench/java/math/BigIntegers.java for performance gain on Kunpeng916 and Kunpeng920.
> The following performance improvements were seen with this implementation:
> - Intrinsification of BigInteger.shiftLeft: 25.52% (Kunpeng916), 37.56% (Kunpeng920)
> - Intrinsification of BigInteger.shiftRight: 46.45% (Kunpeng916), 43.32% (Kunpeng920)
> 
> The BigIntegers.java JMH micro-benchmark results:
> Benchmark                      Mode  Cnt     Score    Error  Units
> 
> # Kunpeng 916, default
> BigIntegers.testAdd            avgt   25    33.554 ?  0.224  ns/op
> BigIntegers.testHugeToString   avgt   25   575.554 ? 40.656  ns/op
> BigIntegers.testLargeToString  avgt   25   190.098 ?  0.825  ns/op
> **BigIntegers.testLeftShift      avgt   25  1495.779 ? 12.365  ns/op**
> BigIntegers.testMultiply       avgt   25  7551.707 ? 39.309  ns/op
> **BigIntegers.testRightShift     avgt   25   605.302 ?  6.710  ns/op**
> BigIntegers.testSmallToString  avgt   25   179.034 ?  0.873  ns/op
> 
> # Kunpeng 916, intrinsic:
> BigIntegers.testAdd            avgt   25    33.531 ?  0.222  ns/op
> BigIntegers.testHugeToString   avgt   25   578.038 ? 40.675  ns/op
> BigIntegers.testLargeToString  avgt   25   188.566 ?  0.855  ns/op
> **BigIntegers.testLeftShift      avgt   25  1191.651 ? 20.136  ns/op**
> BigIntegers.testMultiply       avgt   25  7492.711 ?  3.702  ns/op
> **BigIntegers.testRightShift     avgt   25   326.891 ?  6.033  ns/op**
> BigIntegers.testSmallToString  avgt   25   178.267 ?  1.501  ns/op
> 
> # Kunpeng 920, default
> BigIntegers.testAdd            avgt   25    22.790 ?  0.167  ns/op
> BigIntegers.testHugeToString   avgt   25   432.428 ? 10.736  ns/op
> BigIntegers.testLargeToString  avgt   25   121.899 ?  3.356  ns/op
> **BigIntegers.testLeftShift      avgt   25   883.530 ? 53.714  ns/op**
> BigIntegers.testMultiply       avgt   25  5918.845 ? 94.937  ns/op
> **BigIntegers.testRightShift     avgt   25   329.762 ? 15.850  ns/op**
> BigIntegers.testSmallToString  avgt   25   117.460 ?  3.040  ns/op
> 
> # Kunpeng 920, intrinsic
> BigIntegers.testAdd            avgt   25    21.791 ?  0.085  ns/op
> BigIntegers.testHugeToString   avgt   25   415.209 ? 32.170  ns/op
> BigIntegers.testLargeToString  avgt   25   124.635 ?  2.157  ns/op
> **BigIntegers.testLeftShift      avgt   25   551.710 ?  7.836  ns/op**
> BigIntegers.testMultiply       avgt   25  5869.401 ? 54.803  ns/op
> **BigIntegers.testRightShift     avgt   25   186.896 ?  6.378  ns/op**
> BigIntegers.testSmallToString  avgt   25   117.543 ?  3.036  ns/op

Dong Bo has updated the pull request incrementally with one additional commit since the last revision:

  minor improvements for small BigIntegers

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/861/files
  - new: https://git.openjdk.java.net/jdk/pull/861/files/e8df2a98..7a5d76f5

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=861&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=861&range=00-01

  Stats: 85 lines in 2 files changed: 63 ins; 2 del; 20 mod
  Patch: https://git.openjdk.java.net/jdk/pull/861.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/861/head:pull/861

PR: https://git.openjdk.java.net/jdk/pull/861

From dongbo at openjdk.java.net  Tue Oct 27 06:47:17 2020
From: dongbo at openjdk.java.net (Dong Bo)
Date: Tue, 27 Oct 2020 06:47:17 GMT
Subject: RFR: 8255246: AArch64: Implement BigInteger shiftRight and
 shiftLeft accelerator/intrinsic
In-Reply-To: <r6hSDpfXd-0pLBF7HqjeUtDzunl7nCUzbCQtqGP1_rw=.fe8d5cd1-2c1d-4d2d-ac6f-fc1d9ac3ebc2@github.com>
References: <r6hSDpfXd-0pLBF7HqjeUtDzunl7nCUzbCQtqGP1_rw=.fe8d5cd1-2c1d-4d2d-ac6f-fc1d9ac3ebc2@github.com>
Message-ID: <9DFfj6e0hiQbfz9gnZp52nVHASD2iZCgudqh5AUBJgA=.51645a98-6a49-4288-8ec3-69f8f3727352@github.com>

On Mon, 26 Oct 2020 09:19:45 GMT, Dong Bo <dongbo at openjdk.org> wrote:

> BigInteger.shiftRightImplWorker and BigInteger.shiftLeftImplWorker are not intrinsified on aarch64, which have been done on x86_64.
> We can implement them via USHL NEON instruction (register), which handles four integers one time at most, against just integer C2 asm-code processed.
> The usage of USHL can be found at: https://developer.arm.com/documentation/dui0801/g/A64-SIMD-Vector-Instructions/USHL--vector-?lang=en
> 
> Patch passed jtreg tier1-3 tests on our aarch64 server.
> Tests in test/jdk/java/math/BigInteger/* runned specially for the correctness of the implementation and passed.
> 
> We tested test/micro/org/openjdk/bench/java/math/BigIntegers.java for performance gain on Kunpeng916 and Kunpeng920.
> The following performance improvements were seen with this implementation:
> - Intrinsification of BigInteger.shiftLeft: 25.52% (Kunpeng916), 37.56% (Kunpeng920)
> - Intrinsification of BigInteger.shiftRight: 46.45% (Kunpeng916), 43.32% (Kunpeng920)
> 
> The BigIntegers.java JMH micro-benchmark results:
> Benchmark                      Mode  Cnt     Score    Error  Units
> 
> # Kunpeng 916, default
> BigIntegers.testAdd            avgt   25    33.554 ?  0.224  ns/op
> BigIntegers.testHugeToString   avgt   25   575.554 ? 40.656  ns/op
> BigIntegers.testLargeToString  avgt   25   190.098 ?  0.825  ns/op
> **BigIntegers.testLeftShift      avgt   25  1495.779 ? 12.365  ns/op**
> BigIntegers.testMultiply       avgt   25  7551.707 ? 39.309  ns/op
> **BigIntegers.testRightShift     avgt   25   605.302 ?  6.710  ns/op**
> BigIntegers.testSmallToString  avgt   25   179.034 ?  0.873  ns/op
> 
> # Kunpeng 916, intrinsic:
> BigIntegers.testAdd            avgt   25    33.531 ?  0.222  ns/op
> BigIntegers.testHugeToString   avgt   25   578.038 ? 40.675  ns/op
> BigIntegers.testLargeToString  avgt   25   188.566 ?  0.855  ns/op
> **BigIntegers.testLeftShift      avgt   25  1191.651 ? 20.136  ns/op**
> BigIntegers.testMultiply       avgt   25  7492.711 ?  3.702  ns/op
> **BigIntegers.testRightShift     avgt   25   326.891 ?  6.033  ns/op**
> BigIntegers.testSmallToString  avgt   25   178.267 ?  1.501  ns/op
> 
> # Kunpeng 920, default
> BigIntegers.testAdd            avgt   25    22.790 ?  0.167  ns/op
> BigIntegers.testHugeToString   avgt   25   432.428 ? 10.736  ns/op
> BigIntegers.testLargeToString  avgt   25   121.899 ?  3.356  ns/op
> **BigIntegers.testLeftShift      avgt   25   883.530 ? 53.714  ns/op**
> BigIntegers.testMultiply       avgt   25  5918.845 ? 94.937  ns/op
> **BigIntegers.testRightShift     avgt   25   329.762 ? 15.850  ns/op**
> BigIntegers.testSmallToString  avgt   25   117.460 ?  3.040  ns/op
> 
> # Kunpeng 920, intrinsic
> BigIntegers.testAdd            avgt   25    21.791 ?  0.085  ns/op
> BigIntegers.testHugeToString   avgt   25   415.209 ? 32.170  ns/op
> BigIntegers.testLargeToString  avgt   25   124.635 ?  2.157  ns/op
> **BigIntegers.testLeftShift      avgt   25   551.710 ?  7.836  ns/op**
> BigIntegers.testMultiply       avgt   25  5869.401 ? 54.803  ns/op
> **BigIntegers.testRightShift     avgt   25   186.896 ?  6.378  ns/op**
> BigIntegers.testSmallToString  avgt   25   117.543 ?  3.036  ns/op

@theRealAph Thanks for the quick review.

Updated a version for small BigIntegers.
The less-than-four-words loop is unpacked for minor performance improvements.
Also modified code in ./test/micro/org/openjdk/bench/java/math/BigIntegers.java for small BigIntegers performance tests.
New parameter `maxNumbits` in the test indicates bits count of a BigInteger range in `[maxNumbits - 31, maxNumbits]`. 
Incremental modification: https://github.com/openjdk/jdk/pull/861/commits/7a5d76f51e693d441dee30b3d109d1b67b525378

According to the new tests, performance regress 3%~%6 only if `maxNumbits == 32`.
Seems the regression is inevitably caused by the intrinsic shared code,
performance regress even if we return immediately from the stub, like:
  /* marked as cbz_ret below */
  address generate_bigIntegerLeftShift() {
    __ align(CodeEntryAlignment);
    StubCodeMark mark(this,  "StubRoutines", "bigIntegerLeftShiftWorker");
    address start = __ pc();
    Register numIter      = c_rarg4;
    __ cbz(numIter, Exit);
    __ ret(lr);
  }
The performance of  `cbz_ret` is almost same with intrinsified 32-MaxNumbits tests.
Similar tests, returns immediately with `__ ret(0)`,  regress on a x86_64 platform too.

The BigIntegers.java JMH micro-benchmark results of small BigIntegers (~256bits):

Benchmark                        (maxNumbits)  Mode  Cnt   Score   Error  Units

# kunpeng 916, intrinsic
BigIntegers.testSmallLeftShift             32  avgt   25  51.444 ? 0.256  ns/op (cbz_ret)
BigIntegers.testSmallLeftShift             32  avgt   25  51.168 ? 0.235  ns/op
BigIntegers.testSmallLeftShift             64  avgt   25  53.566 ? 0.694  ns/op
BigIntegers.testSmallLeftShift             96  avgt   25  53.398 ? 0.651  ns/op
BigIntegers.testSmallLeftShift            128  avgt   25  55.949 ? 0.977  ns/op
BigIntegers.testSmallLeftShift            160  avgt   25  55.617 ? 0.568  ns/op
BigIntegers.testSmallLeftShift            192  avgt   25  56.285 ? 0.959  ns/op
BigIntegers.testSmallLeftShift            224  avgt   25  58.201 ? 0.965  ns/op
BigIntegers.testSmallLeftShift            256  avgt   25  58.655 ? 0.953  ns/op
BigIntegers.testSmallRightShift            32  avgt   25  56.210 ? 0.708  ns/op (cbz_ret)
BigIntegers.testSmallRightShift            32  avgt   25  56.072 ? 0.712  ns/op
BigIntegers.testSmallRightShift            64  avgt   25  56.891 ? 0.458  ns/op
BigIntegers.testSmallRightShift            96  avgt   25  56.257 ? 0.185  ns/op
BigIntegers.testSmallRightShift           128  avgt   25  56.970 ? 0.458  ns/op
BigIntegers.testSmallRightShift           160  avgt   25  58.041 ? 0.344  ns/op
BigIntegers.testSmallRightShift           192  avgt   25  58.740 ? 0.405  ns/op
BigIntegers.testSmallRightShift           224  avgt   25  60.550 ? 0.382  ns/op
BigIntegers.testSmallRightShift           256  avgt   25  65.617 ? 0.266  ns/op

# kunpeng 916, default
BigIntegers.testSmallLeftShift             32  avgt   25  49.350 ? 0.944  ns/op
BigIntegers.testSmallLeftShift             64  avgt   25  56.810 ? 0.930  ns/op
BigIntegers.testSmallLeftShift             96  avgt   25  59.472 ? 0.270  ns/op
BigIntegers.testSmallLeftShift            128  avgt   25  61.208 ? 0.252  ns/op
BigIntegers.testSmallLeftShift            160  avgt   25  63.339 ? 0.328  ns/op
BigIntegers.testSmallLeftShift            192  avgt   25  66.456 ? 0.418  ns/op
BigIntegers.testSmallLeftShift            224  avgt   25  68.437 ? 0.294  ns/op
BigIntegers.testSmallLeftShift            256  avgt   25  70.301 ? 0.306  ns/op
BigIntegers.testSmallRightShift            32  avgt   25  53.289 ? 0.272  ns/op
BigIntegers.testSmallRightShift            64  avgt   25  65.618 ? 4.097  ns/op
BigIntegers.testSmallRightShift            96  avgt   25  70.805 ? 3.695  ns/op
BigIntegers.testSmallRightShift           128  avgt   25  70.862 ? 4.205  ns/op
BigIntegers.testSmallRightShift           160  avgt   25  79.921 ? 3.272  ns/op
BigIntegers.testSmallRightShift           192  avgt   25  75.168 ? 0.224  ns/op
BigIntegers.testSmallRightShift           224  avgt   25  79.779 ? 0.609  ns/op
BigIntegers.testSmallRightShift           256  avgt   25  84.364 ? 0.540  ns/op

# kunepng 920, intrinsic
BigIntegers.testSmallLeftShift             32  avgt   25  31.404 ? 0.984  ns/op (cbz_ret)
BigIntegers.testSmallLeftShift             32  avgt   25  31.272 ? 0.558  ns/op
BigIntegers.testSmallLeftShift             64  avgt   25  33.558 ? 1.354  ns/op
BigIntegers.testSmallLeftShift             96  avgt   25  34.731 ? 1.238  ns/op
BigIntegers.testSmallLeftShift            128  avgt   25  36.082 ? 1.196  ns/op
BigIntegers.testSmallLeftShift            160  avgt   25  36.155 ? 0.932  ns/op
BigIntegers.testSmallLeftShift            192  avgt   25  38.442 ? 0.743  ns/op
BigIntegers.testSmallLeftShift            224  avgt   25  38.404 ? 1.108  ns/op
BigIntegers.testSmallLeftShift            256  avgt   25  39.381 ? 1.140  ns/op
BigIntegers.testSmallRightShift            32  avgt   25  30.821 ? 0.533  ns/op (cbz_ret)
BigIntegers.testSmallRightShift            32  avgt   25  30.662 ? 1.625  ns/op
BigIntegers.testSmallRightShift            64  avgt   25  32.686 ? 1.000  ns/op
BigIntegers.testSmallRightShift            96  avgt   25  33.922 ? 1.068  ns/op
BigIntegers.testSmallRightShift           128  avgt   25  34.997 ? 1.155  ns/op
BigIntegers.testSmallRightShift           160  avgt   25  35.763 ? 1.159  ns/op
BigIntegers.testSmallRightShift           192  avgt   25  38.180 ? 0.735  ns/op
BigIntegers.testSmallRightShift           224  avgt   25  37.985 ? 1.619  ns/op
BigIntegers.testSmallRightShift           256  avgt   25  39.957 ? 0.820  ns/op

# kunpeng 920, default
BigIntegers.testSmallLeftShift             32  avgt   25  29.524 ? 0.861  ns/op
BigIntegers.testSmallLeftShift             64  avgt   25  35.917 ? 0.467  ns/op
BigIntegers.testSmallLeftShift             96  avgt   25  36.915 ? 0.317  ns/op
BigIntegers.testSmallLeftShift            128  avgt   25  39.709 ? 0.858  ns/op
BigIntegers.testSmallLeftShift            160  avgt   25  42.796 ? 0.824  ns/op
BigIntegers.testSmallLeftShift            192  avgt   25  43.612 ? 0.319  ns/op
BigIntegers.testSmallLeftShift            224  avgt   25  45.971 ? 0.336  ns/op
BigIntegers.testSmallLeftShift            256  avgt   25  48.399 ? 0.405  ns/op
BigIntegers.testSmallRightShift            32  avgt   25  29.122 ? 0.870  ns/op
BigIntegers.testSmallRightShift            64  avgt   25  35.404 ? 1.236  ns/op
BigIntegers.testSmallRightShift            96  avgt   25  37.899 ? 1.478  ns/op
BigIntegers.testSmallRightShift           128  avgt   25  39.570 ? 0.564  ns/op
BigIntegers.testSmallRightShift           160  avgt   25  44.768 ? 1.423  ns/op
BigIntegers.testSmallRightShift           192  avgt   25  44.777 ? 1.433  ns/op
BigIntegers.testSmallRightShift           224  avgt   25  49.085 ? 0.465  ns/op
BigIntegers.testSmallRightShift           256  avgt   25  48.871 ? 1.086  ns/op

-------------

PR: https://git.openjdk.java.net/jdk/pull/861

From redestad at openjdk.java.net  Tue Oct 27 10:38:27 2020
From: redestad at openjdk.java.net (Claes Redestad)
Date: Tue, 27 Oct 2020 10:38:27 GMT
Subject: RFR: 8255231: Avoid upcalls when initializing the statSampler [v4]
In-Reply-To: <lii6e0xHv1-8WWiYtiyoh5FgujpnVgKhBOkfcJyer94=.416f2682-ab27-469b-98a0-1182da7d9a8a@github.com>
References: <Szazq59X7qoDaQ51HtEeE4N2BarTHiiRFqbUI7DrfEk=.7199b11d-06fb-485c-b9cc-856de34714d6@github.com>
 <U1H6HTExg6qMq3JuHkZtlkFW1MpRtRz3hjcn0nZSYd0=.aca55583-d1ec-4d5a-92f9-0fef79e333bc@github.com>
 <lii6e0xHv1-8WWiYtiyoh5FgujpnVgKhBOkfcJyer94=.416f2682-ab27-469b-98a0-1182da7d9a8a@github.com>
Message-ID: <AU8DH0uRz5uYeL6LIEBHzBCwUzaPziTfOQ64vXyU734=.338db2db-28ae-4315-bd64-88a1d4974269@github.com>

On Mon, 26 Oct 2020 22:52:39 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Claes Redestad has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 21 additional commits since the last revision:
>> 
>>  - Address review comments from David Holmes
>>  - Merge branch 'master' into com_ns
>>  - Refactor to remove stable_java_property_counters and clarify comments
>>  - Merge branch 'master' into com_ns
>>  - Revert unrelated changes to perfData
>>  - Merge branch 'master' into com_ns
>>  - Improve comments
>>  - typo
>>  - Missing definition
>>  - Extract the shorthand java.version from VersionProps and use it in StatSampler
>>  - ... and 11 more: https://git.openjdk.java.net/jdk/compare/94ef2dbc...8572159f
>
> Thanks for making the suggested changes.
> 
> I think we need a further RFE to add some error checking for the sizes of the various property strings in relation to the fixed size arrays that have been allocated to them.
> 
> Thanks,
> David

@dholmes @iklam: thanks for reviewing!

-------------

PR: https://git.openjdk.java.net/jdk/pull/802

From redestad at openjdk.java.net  Tue Oct 27 10:38:28 2020
From: redestad at openjdk.java.net (Claes Redestad)
Date: Tue, 27 Oct 2020 10:38:28 GMT
Subject: Integrated: 8255231: Avoid upcalls when initializing the statSampler
In-Reply-To: <Szazq59X7qoDaQ51HtEeE4N2BarTHiiRFqbUI7DrfEk=.7199b11d-06fb-485c-b9cc-856de34714d6@github.com>
References: <Szazq59X7qoDaQ51HtEeE4N2BarTHiiRFqbUI7DrfEk=.7199b11d-06fb-485c-b9cc-856de34714d6@github.com>
Message-ID: <TN5cH1y7I4qVL-POYqcThaI2PdSkBFKHVJDZD-F4XJc=.954f12fb-87fe-414d-8da6-1eac1aeca896@github.com>

On Thu, 22 Oct 2020 10:11:31 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Current implementation of the statSampler does upcalls to System.getProperty to collect values for a number of properties that are all provided by the VM itself. And since the sampling starts before any user code run then no property can have changed.
> 
> I suggest refactoring the code so that no upcalls are made normally - while asserting this invariant holds using assert-only upcalls. 
> 
> This is a small startup optimization - reducing the startup sequence by approx. 300k instructions and 70k branches in my linux-x64 setup.

This pull request has now been integrated.

Changeset: f7c59c66
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f7c59c66
Stats:     136 lines in 7 files changed: 51 ins; 41 del; 44 mod

8255231: Avoid upcalls when initializing the statSampler

Reviewed-by: iklam, dholmes

-------------

PR: https://git.openjdk.java.net/jdk/pull/802

From jvernee at openjdk.java.net  Tue Oct 27 10:43:23 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Tue, 27 Oct 2020 10:43:23 GMT
Subject: RFR: 8255398: Add a dropReturn MethodHandle combinator [v3]
In-Reply-To: <N4S_va-a90fKTuRoEFZSmAZTVlscp7v72DHJqqA0C8k=.4e20fb13-ab89-4d74-8151-5eddf612ab9d@github.com>
References: <zYoRWf3w-WVtBQZCV97D4sPBDGLFNQ8-JCrq4NXCQ4Q=.f5c6fb56-bc8b-44f4-987b-725dd70e6ace@github.com>
 <8ccDRraptUr5-NjCqXmtVas3-_geXfS8dVdwQeMBdMk=.da14d5ec-c738-43dc-9868-52169950e159@github.com>
 <z2Tj5arbsqySej0LLfPDCxhnndf2me4cEY26RUSOLLA=.41359c26-a489-40ca-8061-a1f670eb80b2@github.com>
 <yewLzMO7cUrnU2OZwHOxdhhU2RTgj2WmQHgLy4YP5DE=.a72cd93b-4803-42f7-b979-506721250d07@github.com>
 <BBTb2SmjGX0gUXbCm3q4OOjUBx4XNDRCgRSOVTG03dE=.1fd2b43e-f67b-4102-a357-d08db58e588b@github.com>
 <cWtzYwXdDEoC4v8eRBaGhY5aAI62pThg8nGQDK7d5x0=.b0e01bd2-ce7f-4054-8566-793f20dd2ca7@github.com>
 <N4S_va-a90fKTuRoEFZSmAZTVlscp7v72DHJqqA0C8k=.4e20fb13-ab89-4d74-8151-5eddf612ab9d@github.com>
Message-ID: <pTFmPu611NS1jY9NRR3P3s_fnjejISp2Ca8MCwnhpS0=.5389b31a-cb02-4601-969f-2f3a07ce0eb5@github.com>

On Mon, 26 Oct 2020 18:33:11 GMT, R?mi Forax <github.com+828220+forax at openjdk.org> wrote:

>>> ?`dropReturn` seemed like a good choice since we already have `dropArguments`. WRT changing to `MethodHandle::changeReturnType`...
>> 
>> That's a very reasonable point.  People might look for `dropRT` after they find `dropAs`.  And `MHs` is designed as a large-ish set of utility methods.
>> 
>> I agree that adding `MH::changeRT` is a slippery slope; it tends to lift more of the MT API onto MH, and it starts to put new stuff into the smaller MH API; that was my bad.
>> 
>> But (in the spirit of brainstorming, and agreeing with your present proposal), I'll suggest a separate idea to think about.  Use a HOFP API to give easy access to the entire `MT` API all in one go, by reifying the `MH.type` property as a temporary (lambda argument):
>> 
>> MethodHandle mapType(MethodHandle mh, UnaryOperator<MethodType> fn) {
>>    return mh.asType(fn.apply(mh.type()));
>> }
>> 
>> This also suggests a possible argument transform utility, a sort of mini-version of Charlie Nutter's MH builder API:
>> 
>> MethodHandle mapArguments(MethodHandle mh, UnaryOperator<List<ArgumentValue<?>>> fn) {
>>   var args = mh.type().argumentList().stream().map(t -> makeArg(t)).asList();
>>   args = fn.apply(args);
>>   ? do stuff to re-weave mh with the resulting argument transforms ?
>> }
>> public sealed interface ArgumentValue<T> {
>>   Class<T> type();
>>   <U> ArgumentValue<U> asType(Class<U> newType);
>>   ? other stuff for pre-applying MHs ? 
>> }
>
> instead of mapArguments(), i believe it's better to have a method map on a MethodType that takes two mapping functions, one for the return type and one for the prameter types.
> 
> so one can write:
>   MHs.mapType(mh, mt -> mt.map(Function.identity(), t-> t.isPrimitive? t: Object.class))
> to not change the return type and erase the parameter type to Object if they are not primitives
> 
> With that, changing the return type to void can be done that way too
>   MHs.mapType(mh, mt -> mt.map(__ -> void.class, Function.identity())

It's an interesting idea. It turns something like:

target = target.asType(target.type().changeReturnType(void.class));

Into 

target = target.asType(mt -> mt.changeReturnType(void.class));

I.e. it removes the need to reference the target handle/type twice, which prevents them from potentially going out of sync (which seems more likely when you have multiple MethodTypes and MethodHandles flying around). Also, it feels unnecessary that, I have to re-specify `target`'s type as a base, when I'm asking `target` to change it's type. This also solves that.

-------------

PR: https://git.openjdk.java.net/jdk/pull/866

From jvernee at openjdk.java.net  Tue Oct 27 12:54:27 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Tue, 27 Oct 2020 12:54:27 GMT
Subject: RFR: 8255449: Improve the exception message of
 MethodHandles::permuteArguments
Message-ID: <9ibIdtPhdYSNXJfsy6uIzu4XV46dyZBqc498HIaOII4=.08a61fba-320b-430f-a8cf-9855e4db64de@github.com>

Hi,

Currently, if MethodHandles::permuteArguments is used with a reorder array that is the wrong size, or one of the indexes in it is out of bounds of the new type, we simply get the exception message:

    bad reorder array [...]

I think we can improve the exception message by splitting these two error cases, and saying in the message exactly what went wrong.

permuteArguments is a tricky API, so improving the error message here should help to improve developer productivity.

This PR proposes splits the error message into e.g.:

    old type parameter count and reorder array length do not match: (int,int,String)int, [0, 0]

For an incorrect reorder array length, and:

    index is out of bounds for new type: 2, (int,String)int

For an out of bounds index.

Thanks,
Jorn

-------------

Commit messages:
 - Improve wording of permuteArguments exception message

Changes: https://git.openjdk.java.net/jdk/pull/878/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=878&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8255449
  Stats: 19 lines in 1 file changed: 4 ins; 3 del; 12 mod
  Patch: https://git.openjdk.java.net/jdk/pull/878.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/878/head:pull/878

PR: https://git.openjdk.java.net/jdk/pull/878

From mcimadamore at openjdk.java.net  Tue Oct 27 12:59:31 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 27 Oct 2020 12:59:31 GMT
Subject: RFR: 8254162: Implementation of Foreign-Memory Access API (Third
 Incubator) [v14]
In-Reply-To: <IngRk57F78UN3yySfo6IABbdwnMogGNdYrykh_3em-c=.b81f7478-015c-45ed-9788-58d7519a2770@github.com>
References: <IngRk57F78UN3yySfo6IABbdwnMogGNdYrykh_3em-c=.b81f7478-015c-45ed-9788-58d7519a2770@github.com>
Message-ID: <6DXvMCLE3m-Rcv_Sxl-WMZITXkY8LwzctCgf_Ke83Ls=.c8f71977-0f81-415f-b6a5-f56be3a934c1@github.com>

> This patch contains the changes associated with the third incubation round of the foreign memory access API incubation  (see JEP 393 [1]). This iteration focus on improving the usability of the API in 3 main ways:
> 
> * first, by providing a way to obtain truly *shared* segments, which can be accessed and closed concurrently from multiple threads
> * second, by providing a way to register a memory segment against a `Cleaner`, so as to have some (optional) guarantee that the memory will be deallocated, eventually
> * third, by not requiring users to dive deep into var handles when they first pick up the API; a new `MemoryAccess` class has been added, which defines several useful dereference routines; these are really just thin wrappers around memory access var handles, but they make the barrier of entry for using this API somewhat lower.
> 
> A big conceptual shift that comes with this API refresh is that the role of `MemorySegment` and `MemoryAddress` is not the same as it used to be; it used to be the case that a memory address could (sometimes, not always) have a back link to the memory segment which originated it; additionally, memory access var handles used `MemoryAddress` as a basic unit of dereference.
> 
> This has all changed as per this API refresh;  now a `MemoryAddress` is just a dumb carrier which wraps a pair of object/long addressing coordinates; `MemorySegment` has become the star of the show, as far as dereferencing memory is concerned. You cannot dereference memory if you don't have a segment. This improves usability in a number of ways - first, it is a lot easier to wrap native addresses (`long`, essentially) into a `MemoryAddress`; secondly, it is crystal clear what a client has to do in order to dereference memory: if a client has a segment, it can use that; otherwise, if the client only has an address, it will have to create a segment *unsafely* (this can be done by calling `MemoryAddress::asSegmentRestricted`).
> 
> A list of the API, implementation and test changes is provided below. If  you have any questions, or need more detailed explanations, I (and the  rest of the Panama team) will be happy to point at existing discussions,  and/or to provide the feedback required. 
> 
> A big thank to Erik Osterlund, Vladimir Ivanov and David Holmes, without whom the work on shared memory segment would not have been possible; also I'd like to thank Paul Sandoz, whose insights on API design have been very helpful in this journey.
> 
> Thanks 
> Maurizio 
> 
> Javadoc: 
> 
> http://cr.openjdk.java.net/~mcimadamore/8254162_v1/javadoc/jdk/incubator/foreign/package-summary.html
> 
> Specdiff: 
> 
> http://cr.openjdk.java.net/~mcimadamore/8254162_v1/specdiff/jdk/incubator/foreign/package-summary.html
> 
> CSR: 
> 
> https://bugs.openjdk.java.net/browse/JDK-8254163
> 
> 
> 
> ### API Changes
> 
> * `MemorySegment`
>   * drop factory for restricted segment (this has been moved to `MemoryAddress`, see below)
>   * added a no-arg factory for a native restricted segment representing entire native heap
>   * rename `withOwnerThread` to `handoff`
>   * add new `share` method, to create shared segments
>   * add new `registerCleaner` method, to register a segment against a cleaner
>   * add more helpers to create arrays from a segment e.g. `toIntArray`
>   * add some `asSlice` overloads (to make up for the fact that now segments are more frequently used as cursors)
>   * rename `baseAddress` to `address` (so that `MemorySegment` can implement `Addressable`)
> * `MemoryAddress`
>   * drop `segment` accessor
>   * drop `rebase` method and replace it with `segmentOffset` which returns the offset (a `long`) of this address relative to a given segment
> * `MemoryAccess`
>   * New class supporting several static dereference helpers; the helpers are organized by carrier and access mode, where a carrier is one of the usual suspect (a Java primitive, minus `boolean`); the access mode can be simple (e.g. access base address of given segment), or indexed, in which case the accessor takes a segment and either a low-level byte offset,or a high level logical index. The classification is reflected in the naming scheme (e.g. `getByte` vs. `getByteAtOffset` vs `getByteAtIndex`).
> * `MemoryHandles`
>   * drop `withOffset` combinator
>   * drop `withStride` combinator
>   * the basic memory access handle factory now returns a var handle which takes a `MemorySegment` and a `long` - from which it is easy to derive all the other handles using plain var handle combinators.
> * `Addressable`
>   * This is a new interface which is attached to entities which can be projected to a `MemoryAddress`. For now, both `MemoryAddress` and `MemorySegment` implement it; we have plans, with JEP 389 [2] to add more implementations. Clients can largely ignore this interface, which comes in really handy when defining native bindings with tools like `jextract`.
> * `MemoryLayouts`
>   * A new layout, for machine addresses, has been added to the mix.
> 
> 
> 
> ### Implementation changes
> 
> There are two main things to discuss here: support for shared segments, and the general simplification of the memory access var handle support.
> 
> #### Shared segments
> 
> The support for shared segments cuts in pretty deep in the VM. Support for shared segments is notoriously hard to achieve, at least in a way that guarantees optimal access performances. This is caused by the fact that, if a segment is shared, it would be possible for a thread to close it while another is accessing it.
> 
> After considering several options (see [3]), we zeroed onto an approach which is inspired by an happy idea that Andrew Haley had (and that he reminded me of at this year OpenJDK committer workshop - thanks!). The idea is that if we could *freeze* the world (e.g. with a GC pause), while a segment is closed, we could then prevent segments from being accessed concurrently to a close operation. For this to work, it  is crucial that no GC safepoints can occur between a segment liveness check and the access itself (otherwise it would be possible for the accessing thread to stop just right before an unsafe call). It also relies on the fact that hotspot/C2 should not be able to propagate loads across safepoints.
> 
> Sadly, none of these conditions seems to be valid in the current implementation, so we needed to resort to a bit of creativity. First, we noted that, if we could mark so called *scoped* method with an annotation, it would be very simply to check as to whether a thread was in the middle of a scoped method when we stopped the world for a close operation (btw, instead of stopping the world, we do a much more efficient, thread-local polling, thanks to JEP 312 [4]).
> 
> The question is, then, once we detect that a thread is accessing the very segment we're about to close, what should happen? We first experimented with a solution which would install an *asynchronous* exception on the accessing thread, thus making it fail. This solution has some desirable properties, in that a `close` operation always succeeds. Unfortunately the machinery for async exceptions is a bit fragile (e.g. not all the code in hotspot checks for async exceptions); to minimize risks, we decided to revert to a simpler strategy, where `close` might fail when it finds that another thread is accessing the segment being closed.
> 
> As written in the javadoc, this doesn't mean that clients should just catch and try again; an exception on `close` is a bug in the user code, likely arising from lack of synchronization, and should be treated as such.
> 
> In terms of gritty implementation, we needed to centralize memory access routines in a single place, so that we could have a set of routines closely mimicking the primitives exposed by `Unsafe` but which, in addition, also provided a liveness check. This way we could mark all these routines with the special `@Scoped` annotation, which tells the VM that something important is going on.
> 
> To achieve this, we created a new (autogenerated) class, called `ScopedMemoryAccess`. This class contains all the main memory access primitives (including bulk access, like `copyMemory`, or `setMemory`), and accepts, in addition to the access coordinates, also a scope object, which is tested before access. A reachability fence is also thrown in the mix to make sure that the scope is kept alive during access (which is important when registering segments against cleaners).
> 
> Of course, to make memory access safe, memory access var handles, byte buffer var handles, and byte buffer API should use the new `ScopedMemoryAccess` class instead of unsafe, so that a liveness check can be triggered (in case a scope is present).
> 
> `ScopedMemoryAccess` has a `closeScope` method, which initiates the thread-local handshakes, and returns `true` if the handshake completed successfully.
> 
> The implementation of `MemoryScope` (now significantly simplified from what we had before), has two implementations, one for confined segments and one for shared segments; the main difference between the two is what happens when the scope is closed; a confined segment sets a boolean flag to false, and returns, whereas a shared segment goes into a `CLOSING` state, then starts the handshake, and then updates the state again, to either `CLOSED` or `ALIVE` depending on whether the handshake was successful or not. Note that when a shared segment is in the `CLOSING` state, `MemorySegment::isAlive` will still return `true`, while the liveness check upon memory access will fail.
> 
> #### Memory access var handles overhaul
> 
> The key realization here was that if all memory access var handles took a coordinate pair of `MemorySegment` and `long`, all other access types could be derived from this basic var handle form.
> 
> This allowed us to remove the on-the-fly var handle generation, and to simply derive structural access var handles (such as those obtained by calling `MemoryLayout::varHandle`) using *plain* var handle combinators, so that e.g. additional offset is injected into a base memory access var handle.
> 
> This also helped in simplifying the implementation by removing the special `withStride` and `withOffset` combinators, which previously needed low-level access on the innards of the memory access var handle. All that code is now gone.
> 
> #### Test changes
> 
> Not much to see here - most of the tests needed to be updated because of the API changes. Some were beefed up (like the array test, since now segments can be projected into many different kinds of arrays). A test has been added to test the `Cleaner` functionality, and another stress test has been added for shared segments (`TestHandshake`). Some of the microbenchmarks also needed some tweaks - and some of them were also updated to also test performance in the shared segment case.
> 
> [1] - https://openjdk.java.net/jeps/393
> [2] - https://openjdk.java.net/jeps/389
> [3] - https://mail.openjdk.java.net/pipermail/panama-dev/2020-May/009004.html
> [4] - https://openjdk.java.net/jeps/312

Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:

 - Merge branch 'master' into 8254162
 - Address review comment for scoped memory access makefile
 - Address CSR comments
 - Back-port of TestByteBuffer fix
 - Merge branch 'master' into 8254162
 - Merge branch 'master' into 8254162
 - Merge branch 'master' into 8254162
 - Remove spurious check on MemoryScope::confineTo
   Added tests to make sure no spurious exception is thrown when:
   * handing off a segment from A to A
   * sharing an already shared segment
 - Merge branch 'master' into 8254162
 - Simplify example in the toplevel javadoc
 - ... and 8 more: https://git.openjdk.java.net/jdk/compare/cf56c7e0...697c7ca5

-------------

Changes: https://git.openjdk.java.net/jdk/pull/548/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=548&range=13
  Stats: 7504 lines in 79 files changed: 4797 ins; 1530 del; 1177 mod
  Patch: https://git.openjdk.java.net/jdk/pull/548.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/548/head:pull/548

PR: https://git.openjdk.java.net/jdk/pull/548

From shade at openjdk.java.net  Tue Oct 27 13:39:17 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 27 Oct 2020 13:39:17 GMT
Subject: RFR: 8255331: Problemlist java/foreign/TestMismatch.java on
 32-bit platforms until JDK-8254162
In-Reply-To: <-uYRWyx_pto4dbdQkscW7L0cypuOUzpLdsI42IT1bro=.2950671f-6cda-47dd-901e-66448976a73e@github.com>
References: <lUlNsYKk9fdZ5mWeJunYiLK6R2zx-7QbvKB3L3H-HDo=.f3f93e84-86a8-47f3-9540-c4c367c73e1f@github.com>
 <-uYRWyx_pto4dbdQkscW7L0cypuOUzpLdsI42IT1bro=.2950671f-6cda-47dd-901e-66448976a73e@github.com>
Message-ID: <A46m1R_gZBNVGm8tDXLMTBGQHhZdqoCkMBTU2xktNms=.12c28922-286e-4f87-b5a9-03b2419bba65@github.com>

On Mon, 26 Oct 2020 07:41:16 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> I would like to have clean x86_32 test runs until JDK-8254162 arrives.
>> 
>> Testing:
>>   - [x] Affected test on Linux x86_64 (still passes)
>>   - [x] Affected test on Linux x86_32 (now ignored)
>
> @mcimadamore, please take a look? This seems to be the only thing that keeps `x86_32` `tier1` from being clean. I think you'd need to remove this test from the problem list with/after JDK-8254162 integration.

Friendly reminder, please review, as it blocks #830

-------------

PR: https://git.openjdk.java.net/jdk/pull/833

From mcimadamore at openjdk.java.net  Tue Oct 27 13:51:19 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 27 Oct 2020 13:51:19 GMT
Subject: RFR: 8255331: Problemlist java/foreign/TestMismatch.java on
 32-bit platforms until JDK-8254162
In-Reply-To: <lUlNsYKk9fdZ5mWeJunYiLK6R2zx-7QbvKB3L3H-HDo=.f3f93e84-86a8-47f3-9540-c4c367c73e1f@github.com>
References: <lUlNsYKk9fdZ5mWeJunYiLK6R2zx-7QbvKB3L3H-HDo=.f3f93e84-86a8-47f3-9540-c4c367c73e1f@github.com>
Message-ID: <s47SxgYDbi1iLq6faAAft7pXtbOynk4bBxdLrrMSAtw=.d5fb4095-f95e-4492-bfbd-ebc4a2a7cce5@github.com>

On Fri, 23 Oct 2020 10:42:14 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I would like to have clean x86_32 test runs until JDK-8254162 arrives.
> 
> Testing:
>   - [x] Affected test on Linux x86_64 (still passes)
>   - [x] Affected test on Linux x86_32 (now ignored)

Marked as reviewed by mcimadamore (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/833

From shade at openjdk.java.net  Tue Oct 27 14:00:31 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 27 Oct 2020 14:00:31 GMT
Subject: RFR: 8255331: Problemlist java/foreign/TestMismatch.java on
 32-bit platforms until JDK-8254162
In-Reply-To: <s47SxgYDbi1iLq6faAAft7pXtbOynk4bBxdLrrMSAtw=.d5fb4095-f95e-4492-bfbd-ebc4a2a7cce5@github.com>
References: <lUlNsYKk9fdZ5mWeJunYiLK6R2zx-7QbvKB3L3H-HDo=.f3f93e84-86a8-47f3-9540-c4c367c73e1f@github.com>
 <s47SxgYDbi1iLq6faAAft7pXtbOynk4bBxdLrrMSAtw=.d5fb4095-f95e-4492-bfbd-ebc4a2a7cce5@github.com>
Message-ID: <-E5VT-4-fqkoZ1TBBGvZuPt2H7fZi8zp0zHtQYnGIeg=.c85fa6bd-a9bd-4a7f-b16c-bd5e498ff07e@github.com>

On Tue, 27 Oct 2020 13:48:34 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> I would like to have clean x86_32 test runs until JDK-8254162 arrives.
>> 
>> Testing:
>>   - [x] Affected test on Linux x86_64 (still passes)
>>   - [x] Affected test on Linux x86_32 (now ignored)
>
> Marked as reviewed by mcimadamore (Reviewer).

Thanks, @mcimadamore!

-------------

PR: https://git.openjdk.java.net/jdk/pull/833

From shade at openjdk.java.net  Tue Oct 27 14:00:33 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 27 Oct 2020 14:00:33 GMT
Subject: Integrated: 8255331: Problemlist java/foreign/TestMismatch.java on
 32-bit platforms until JDK-8254162
In-Reply-To: <lUlNsYKk9fdZ5mWeJunYiLK6R2zx-7QbvKB3L3H-HDo=.f3f93e84-86a8-47f3-9540-c4c367c73e1f@github.com>
References: <lUlNsYKk9fdZ5mWeJunYiLK6R2zx-7QbvKB3L3H-HDo=.f3f93e84-86a8-47f3-9540-c4c367c73e1f@github.com>
Message-ID: <3AILi-wVKjbLjyYzgUgiwm-t_r2OwKDZAGEEyXR5BQE=.755c4893-091e-4bc9-b2e3-2e4b6926456e@github.com>

On Fri, 23 Oct 2020 10:42:14 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I would like to have clean x86_32 test runs until JDK-8254162 arrives.
> 
> Testing:
>   - [x] Affected test on Linux x86_64 (still passes)
>   - [x] Affected test on Linux x86_32 (now ignored)

This pull request has now been integrated.

Changeset: 66a3917d
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/66a3917d
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8255331: Problemlist java/foreign/TestMismatch.java on 32-bit platforms until JDK-8254162

Reviewed-by: mcimadamore

-------------

PR: https://git.openjdk.java.net/jdk/pull/833

From rriggs at openjdk.java.net  Tue Oct 27 14:18:27 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 27 Oct 2020 14:18:27 GMT
Subject: RFR: 8255394: jdk/test/lib/hexdump/ASN1FormatterTest.java fails with
 ---illegal-access=deny
Message-ID: <THZVdfmbz_07FC9iy_7yUxwSd4OrSHCIQjklDXpo3P4=.740ff977-5a85-42f8-aa39-051a9e7e1742@github.com>

To access the internal security APIs to lookup known OIDs the test needs to open java.base/sun.security.util.

-------------

Commit messages:
 - 8255394: jdk/test/lib/hexdump/ASN1FormatterTest.java fails with ---illegal-access=deny

Changes: https://git.openjdk.java.net/jdk/pull/881/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=881&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8255394
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/881.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/881/head:pull/881

PR: https://git.openjdk.java.net/jdk/pull/881

From alanb at openjdk.java.net  Tue Oct 27 14:27:23 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 27 Oct 2020 14:27:23 GMT
Subject: RFR: 8255394: jdk/test/lib/hexdump/ASN1FormatterTest.java fails
 with ---illegal-access=deny
In-Reply-To: <THZVdfmbz_07FC9iy_7yUxwSd4OrSHCIQjklDXpo3P4=.740ff977-5a85-42f8-aa39-051a9e7e1742@github.com>
References: <THZVdfmbz_07FC9iy_7yUxwSd4OrSHCIQjklDXpo3P4=.740ff977-5a85-42f8-aa39-051a9e7e1742@github.com>
Message-ID: <DuOjUWmQxjtO6BJJV2ZMMsrofEJV7BImy2q8IxSrdXg=.700dc489-8963-495c-b723-2d404fb0e67f@github.com>

On Tue, 27 Oct 2020 14:11:48 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> To access the internal security APIs to lookup known OIDs the test needs to open java.base/sun.security.util.

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/881

From weijun at openjdk.java.net  Tue Oct 27 14:27:24 2020
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 27 Oct 2020 14:27:24 GMT
Subject: RFR: 8255394: jdk/test/lib/hexdump/ASN1FormatterTest.java fails
 with ---illegal-access=deny
In-Reply-To: <DuOjUWmQxjtO6BJJV2ZMMsrofEJV7BImy2q8IxSrdXg=.700dc489-8963-495c-b723-2d404fb0e67f@github.com>
References: <THZVdfmbz_07FC9iy_7yUxwSd4OrSHCIQjklDXpo3P4=.740ff977-5a85-42f8-aa39-051a9e7e1742@github.com>
 <DuOjUWmQxjtO6BJJV2ZMMsrofEJV7BImy2q8IxSrdXg=.700dc489-8963-495c-b723-2d404fb0e67f@github.com>
Message-ID: <f0EdATSULbBq5zU2QFT9WNC3ustv2pAEAIeDhCF1KC8=.490b5a95-8298-41f9-b106-2ee61de67277@github.com>

On Tue, 27 Oct 2020 14:24:26 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> To access the internal security APIs to lookup known OIDs the test needs to open java.base/sun.security.util.
>
> Marked as reviewed by alanb (Reviewer).

The `findMatch` method is public, maybe you can remove the `setAccessible` call so there is no need for `open`?

-------------

PR: https://git.openjdk.java.net/jdk/pull/881

From shade at openjdk.java.net  Tue Oct 27 14:36:25 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 27 Oct 2020 14:36:25 GMT
Subject: RFR: 8254162: Implementation of Foreign-Memory Access API (Third
 Incubator)
In-Reply-To: <IngRk57F78UN3yySfo6IABbdwnMogGNdYrykh_3em-c=.b81f7478-015c-45ed-9788-58d7519a2770@github.com>
References: <IngRk57F78UN3yySfo6IABbdwnMogGNdYrykh_3em-c=.b81f7478-015c-45ed-9788-58d7519a2770@github.com>
Message-ID: <yOegTydsRGbVYQYqpkBUVhOfnHHHh1n121gDub_vR_k=.66be37d6-16b3-4af5-bf05-0e3da021468e@github.com>

On Wed, 7 Oct 2020 17:13:22 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This patch contains the changes associated with the third incubation round of the foreign memory access API incubation  (see JEP 393 [1]). This iteration focus on improving the usability of the API in 3 main ways:
> 
> * first, by providing a way to obtain truly *shared* segments, which can be accessed and closed concurrently from multiple threads
> * second, by providing a way to register a memory segment against a `Cleaner`, so as to have some (optional) guarantee that the memory will be deallocated, eventually
> * third, by not requiring users to dive deep into var handles when they first pick up the API; a new `MemoryAccess` class has been added, which defines several useful dereference routines; these are really just thin wrappers around memory access var handles, but they make the barrier of entry for using this API somewhat lower.
> 
> A big conceptual shift that comes with this API refresh is that the role of `MemorySegment` and `MemoryAddress` is not the same as it used to be; it used to be the case that a memory address could (sometimes, not always) have a back link to the memory segment which originated it; additionally, memory access var handles used `MemoryAddress` as a basic unit of dereference.
> 
> This has all changed as per this API refresh;  now a `MemoryAddress` is just a dumb carrier which wraps a pair of object/long addressing coordinates; `MemorySegment` has become the star of the show, as far as dereferencing memory is concerned. You cannot dereference memory if you don't have a segment. This improves usability in a number of ways - first, it is a lot easier to wrap native addresses (`long`, essentially) into a `MemoryAddress`; secondly, it is crystal clear what a client has to do in order to dereference memory: if a client has a segment, it can use that; otherwise, if the client only has an address, it will have to create a segment *unsafely* (this can be done by calling `MemoryAddress::asSegmentRestricted`).
> 
> A list of the API, implementation and test changes is provided below. If  you have any questions, or need more detailed explanations, I (and the  rest of the Panama team) will be happy to point at existing discussions,  and/or to provide the feedback required. 
> 
> A big thank to Erik Osterlund, Vladimir Ivanov and David Holmes, without whom the work on shared memory segment would not have been possible; also I'd like to thank Paul Sandoz, whose insights on API design have been very helpful in this journey.
> 
> Thanks 
> Maurizio 
> 
> Javadoc: 
> 
> http://cr.openjdk.java.net/~mcimadamore/8254162_v1/javadoc/jdk/incubator/foreign/package-summary.html
> 
> Specdiff: 
> 
> http://cr.openjdk.java.net/~mcimadamore/8254162_v1/specdiff/jdk/incubator/foreign/package-summary.html
> 
> CSR: 
> 
> https://bugs.openjdk.java.net/browse/JDK-8254163
> 
> 
> 
> ### API Changes
> 
> * `MemorySegment`
>   * drop factory for restricted segment (this has been moved to `MemoryAddress`, see below)
>   * added a no-arg factory for a native restricted segment representing entire native heap
>   * rename `withOwnerThread` to `handoff`
>   * add new `share` method, to create shared segments
>   * add new `registerCleaner` method, to register a segment against a cleaner
>   * add more helpers to create arrays from a segment e.g. `toIntArray`
>   * add some `asSlice` overloads (to make up for the fact that now segments are more frequently used as cursors)
>   * rename `baseAddress` to `address` (so that `MemorySegment` can implement `Addressable`)
> * `MemoryAddress`
>   * drop `segment` accessor
>   * drop `rebase` method and replace it with `segmentOffset` which returns the offset (a `long`) of this address relative to a given segment
> * `MemoryAccess`
>   * New class supporting several static dereference helpers; the helpers are organized by carrier and access mode, where a carrier is one of the usual suspect (a Java primitive, minus `boolean`); the access mode can be simple (e.g. access base address of given segment), or indexed, in which case the accessor takes a segment and either a low-level byte offset,or a high level logical index. The classification is reflected in the naming scheme (e.g. `getByte` vs. `getByteAtOffset` vs `getByteAtIndex`).
> * `MemoryHandles`
>   * drop `withOffset` combinator
>   * drop `withStride` combinator
>   * the basic memory access handle factory now returns a var handle which takes a `MemorySegment` and a `long` - from which it is easy to derive all the other handles using plain var handle combinators.
> * `Addressable`
>   * This is a new interface which is attached to entities which can be projected to a `MemoryAddress`. For now, both `MemoryAddress` and `MemorySegment` implement it; we have plans, with JEP 389 [2] to add more implementations. Clients can largely ignore this interface, which comes in really handy when defining native bindings with tools like `jextract`.
> * `MemoryLayouts`
>   * A new layout, for machine addresses, has been added to the mix.
> 
> 
> 
> ### Implementation changes
> 
> There are two main things to discuss here: support for shared segments, and the general simplification of the memory access var handle support.
> 
> #### Shared segments
> 
> The support for shared segments cuts in pretty deep in the VM. Support for shared segments is notoriously hard to achieve, at least in a way that guarantees optimal access performances. This is caused by the fact that, if a segment is shared, it would be possible for a thread to close it while another is accessing it.
> 
> After considering several options (see [3]), we zeroed onto an approach which is inspired by an happy idea that Andrew Haley had (and that he reminded me of at this year OpenJDK committer workshop - thanks!). The idea is that if we could *freeze* the world (e.g. with a GC pause), while a segment is closed, we could then prevent segments from being accessed concurrently to a close operation. For this to work, it  is crucial that no GC safepoints can occur between a segment liveness check and the access itself (otherwise it would be possible for the accessing thread to stop just right before an unsafe call). It also relies on the fact that hotspot/C2 should not be able to propagate loads across safepoints.
> 
> Sadly, none of these conditions seems to be valid in the current implementation, so we needed to resort to a bit of creativity. First, we noted that, if we could mark so called *scoped* method with an annotation, it would be very simply to check as to whether a thread was in the middle of a scoped method when we stopped the world for a close operation (btw, instead of stopping the world, we do a much more efficient, thread-local polling, thanks to JEP 312 [4]).
> 
> The question is, then, once we detect that a thread is accessing the very segment we're about to close, what should happen? We first experimented with a solution which would install an *asynchronous* exception on the accessing thread, thus making it fail. This solution has some desirable properties, in that a `close` operation always succeeds. Unfortunately the machinery for async exceptions is a bit fragile (e.g. not all the code in hotspot checks for async exceptions); to minimize risks, we decided to revert to a simpler strategy, where `close` might fail when it finds that another thread is accessing the segment being closed.
> 
> As written in the javadoc, this doesn't mean that clients should just catch and try again; an exception on `close` is a bug in the user code, likely arising from lack of synchronization, and should be treated as such.
> 
> In terms of gritty implementation, we needed to centralize memory access routines in a single place, so that we could have a set of routines closely mimicking the primitives exposed by `Unsafe` but which, in addition, also provided a liveness check. This way we could mark all these routines with the special `@Scoped` annotation, which tells the VM that something important is going on.
> 
> To achieve this, we created a new (autogenerated) class, called `ScopedMemoryAccess`. This class contains all the main memory access primitives (including bulk access, like `copyMemory`, or `setMemory`), and accepts, in addition to the access coordinates, also a scope object, which is tested before access. A reachability fence is also thrown in the mix to make sure that the scope is kept alive during access (which is important when registering segments against cleaners).
> 
> Of course, to make memory access safe, memory access var handles, byte buffer var handles, and byte buffer API should use the new `ScopedMemoryAccess` class instead of unsafe, so that a liveness check can be triggered (in case a scope is present).
> 
> `ScopedMemoryAccess` has a `closeScope` method, which initiates the thread-local handshakes, and returns `true` if the handshake completed successfully.
> 
> The implementation of `MemoryScope` (now significantly simplified from what we had before), has two implementations, one for confined segments and one for shared segments; the main difference between the two is what happens when the scope is closed; a confined segment sets a boolean flag to false, and returns, whereas a shared segment goes into a `CLOSING` state, then starts the handshake, and then updates the state again, to either `CLOSED` or `ALIVE` depending on whether the handshake was successful or not. Note that when a shared segment is in the `CLOSING` state, `MemorySegment::isAlive` will still return `true`, while the liveness check upon memory access will fail.
> 
> #### Memory access var handles overhaul
> 
> The key realization here was that if all memory access var handles took a coordinate pair of `MemorySegment` and `long`, all other access types could be derived from this basic var handle form.
> 
> This allowed us to remove the on-the-fly var handle generation, and to simply derive structural access var handles (such as those obtained by calling `MemoryLayout::varHandle`) using *plain* var handle combinators, so that e.g. additional offset is injected into a base memory access var handle.
> 
> This also helped in simplifying the implementation by removing the special `withStride` and `withOffset` combinators, which previously needed low-level access on the innards of the memory access var handle. All that code is now gone.
> 
> #### Test changes
> 
> Not much to see here - most of the tests needed to be updated because of the API changes. Some were beefed up (like the array test, since now segments can be projected into many different kinds of arrays). A test has been added to test the `Cleaner` functionality, and another stress test has been added for shared segments (`TestHandshake`). Some of the microbenchmarks also needed some tweaks - and some of them were also updated to also test performance in the shared segment case.
> 
> [1] - https://openjdk.java.net/jeps/393
> [2] - https://openjdk.java.net/jeps/389
> [3] - https://mail.openjdk.java.net/pipermail/panama-dev/2020-May/009004.html
> [4] - https://openjdk.java.net/jeps/312

@mcimadamore, if you pull from current master, you would get the Linux x86_32 tier1 run "for free".

-------------

PR: https://git.openjdk.java.net/jdk/pull/548

From mcimadamore at openjdk.java.net  Tue Oct 27 14:43:33 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 27 Oct 2020 14:43:33 GMT
Subject: RFR: 8254162: Implementation of Foreign-Memory Access API (Third
 Incubator) [v15]
In-Reply-To: <IngRk57F78UN3yySfo6IABbdwnMogGNdYrykh_3em-c=.b81f7478-015c-45ed-9788-58d7519a2770@github.com>
References: <IngRk57F78UN3yySfo6IABbdwnMogGNdYrykh_3em-c=.b81f7478-015c-45ed-9788-58d7519a2770@github.com>
Message-ID: <O2pWkUFtoaDdP4EG2dz00sSvQCQHOQiLiiyTHXqErJo=.f1e3abee-0b3e-4455-b256-a2a0c16e6555@github.com>

> This patch contains the changes associated with the third incubation round of the foreign memory access API incubation  (see JEP 393 [1]). This iteration focus on improving the usability of the API in 3 main ways:
> 
> * first, by providing a way to obtain truly *shared* segments, which can be accessed and closed concurrently from multiple threads
> * second, by providing a way to register a memory segment against a `Cleaner`, so as to have some (optional) guarantee that the memory will be deallocated, eventually
> * third, by not requiring users to dive deep into var handles when they first pick up the API; a new `MemoryAccess` class has been added, which defines several useful dereference routines; these are really just thin wrappers around memory access var handles, but they make the barrier of entry for using this API somewhat lower.
> 
> A big conceptual shift that comes with this API refresh is that the role of `MemorySegment` and `MemoryAddress` is not the same as it used to be; it used to be the case that a memory address could (sometimes, not always) have a back link to the memory segment which originated it; additionally, memory access var handles used `MemoryAddress` as a basic unit of dereference.
> 
> This has all changed as per this API refresh;  now a `MemoryAddress` is just a dumb carrier which wraps a pair of object/long addressing coordinates; `MemorySegment` has become the star of the show, as far as dereferencing memory is concerned. You cannot dereference memory if you don't have a segment. This improves usability in a number of ways - first, it is a lot easier to wrap native addresses (`long`, essentially) into a `MemoryAddress`; secondly, it is crystal clear what a client has to do in order to dereference memory: if a client has a segment, it can use that; otherwise, if the client only has an address, it will have to create a segment *unsafely* (this can be done by calling `MemoryAddress::asSegmentRestricted`).
> 
> A list of the API, implementation and test changes is provided below. If  you have any questions, or need more detailed explanations, I (and the  rest of the Panama team) will be happy to point at existing discussions,  and/or to provide the feedback required. 
> 
> A big thank to Erik Osterlund, Vladimir Ivanov and David Holmes, without whom the work on shared memory segment would not have been possible; also I'd like to thank Paul Sandoz, whose insights on API design have been very helpful in this journey.
> 
> Thanks 
> Maurizio 
> 
> Javadoc: 
> 
> http://cr.openjdk.java.net/~mcimadamore/8254162_v1/javadoc/jdk/incubator/foreign/package-summary.html
> 
> Specdiff: 
> 
> http://cr.openjdk.java.net/~mcimadamore/8254162_v1/specdiff/jdk/incubator/foreign/package-summary.html
> 
> CSR: 
> 
> https://bugs.openjdk.java.net/browse/JDK-8254163
> 
> 
> 
> ### API Changes
> 
> * `MemorySegment`
>   * drop factory for restricted segment (this has been moved to `MemoryAddress`, see below)
>   * added a no-arg factory for a native restricted segment representing entire native heap
>   * rename `withOwnerThread` to `handoff`
>   * add new `share` method, to create shared segments
>   * add new `registerCleaner` method, to register a segment against a cleaner
>   * add more helpers to create arrays from a segment e.g. `toIntArray`
>   * add some `asSlice` overloads (to make up for the fact that now segments are more frequently used as cursors)
>   * rename `baseAddress` to `address` (so that `MemorySegment` can implement `Addressable`)
> * `MemoryAddress`
>   * drop `segment` accessor
>   * drop `rebase` method and replace it with `segmentOffset` which returns the offset (a `long`) of this address relative to a given segment
> * `MemoryAccess`
>   * New class supporting several static dereference helpers; the helpers are organized by carrier and access mode, where a carrier is one of the usual suspect (a Java primitive, minus `boolean`); the access mode can be simple (e.g. access base address of given segment), or indexed, in which case the accessor takes a segment and either a low-level byte offset,or a high level logical index. The classification is reflected in the naming scheme (e.g. `getByte` vs. `getByteAtOffset` vs `getByteAtIndex`).
> * `MemoryHandles`
>   * drop `withOffset` combinator
>   * drop `withStride` combinator
>   * the basic memory access handle factory now returns a var handle which takes a `MemorySegment` and a `long` - from which it is easy to derive all the other handles using plain var handle combinators.
> * `Addressable`
>   * This is a new interface which is attached to entities which can be projected to a `MemoryAddress`. For now, both `MemoryAddress` and `MemorySegment` implement it; we have plans, with JEP 389 [2] to add more implementations. Clients can largely ignore this interface, which comes in really handy when defining native bindings with tools like `jextract`.
> * `MemoryLayouts`
>   * A new layout, for machine addresses, has been added to the mix.
> 
> 
> 
> ### Implementation changes
> 
> There are two main things to discuss here: support for shared segments, and the general simplification of the memory access var handle support.
> 
> #### Shared segments
> 
> The support for shared segments cuts in pretty deep in the VM. Support for shared segments is notoriously hard to achieve, at least in a way that guarantees optimal access performances. This is caused by the fact that, if a segment is shared, it would be possible for a thread to close it while another is accessing it.
> 
> After considering several options (see [3]), we zeroed onto an approach which is inspired by an happy idea that Andrew Haley had (and that he reminded me of at this year OpenJDK committer workshop - thanks!). The idea is that if we could *freeze* the world (e.g. with a GC pause), while a segment is closed, we could then prevent segments from being accessed concurrently to a close operation. For this to work, it  is crucial that no GC safepoints can occur between a segment liveness check and the access itself (otherwise it would be possible for the accessing thread to stop just right before an unsafe call). It also relies on the fact that hotspot/C2 should not be able to propagate loads across safepoints.
> 
> Sadly, none of these conditions seems to be valid in the current implementation, so we needed to resort to a bit of creativity. First, we noted that, if we could mark so called *scoped* method with an annotation, it would be very simply to check as to whether a thread was in the middle of a scoped method when we stopped the world for a close operation (btw, instead of stopping the world, we do a much more efficient, thread-local polling, thanks to JEP 312 [4]).
> 
> The question is, then, once we detect that a thread is accessing the very segment we're about to close, what should happen? We first experimented with a solution which would install an *asynchronous* exception on the accessing thread, thus making it fail. This solution has some desirable properties, in that a `close` operation always succeeds. Unfortunately the machinery for async exceptions is a bit fragile (e.g. not all the code in hotspot checks for async exceptions); to minimize risks, we decided to revert to a simpler strategy, where `close` might fail when it finds that another thread is accessing the segment being closed.
> 
> As written in the javadoc, this doesn't mean that clients should just catch and try again; an exception on `close` is a bug in the user code, likely arising from lack of synchronization, and should be treated as such.
> 
> In terms of gritty implementation, we needed to centralize memory access routines in a single place, so that we could have a set of routines closely mimicking the primitives exposed by `Unsafe` but which, in addition, also provided a liveness check. This way we could mark all these routines with the special `@Scoped` annotation, which tells the VM that something important is going on.
> 
> To achieve this, we created a new (autogenerated) class, called `ScopedMemoryAccess`. This class contains all the main memory access primitives (including bulk access, like `copyMemory`, or `setMemory`), and accepts, in addition to the access coordinates, also a scope object, which is tested before access. A reachability fence is also thrown in the mix to make sure that the scope is kept alive during access (which is important when registering segments against cleaners).
> 
> Of course, to make memory access safe, memory access var handles, byte buffer var handles, and byte buffer API should use the new `ScopedMemoryAccess` class instead of unsafe, so that a liveness check can be triggered (in case a scope is present).
> 
> `ScopedMemoryAccess` has a `closeScope` method, which initiates the thread-local handshakes, and returns `true` if the handshake completed successfully.
> 
> The implementation of `MemoryScope` (now significantly simplified from what we had before), has two implementations, one for confined segments and one for shared segments; the main difference between the two is what happens when the scope is closed; a confined segment sets a boolean flag to false, and returns, whereas a shared segment goes into a `CLOSING` state, then starts the handshake, and then updates the state again, to either `CLOSED` or `ALIVE` depending on whether the handshake was successful or not. Note that when a shared segment is in the `CLOSING` state, `MemorySegment::isAlive` will still return `true`, while the liveness check upon memory access will fail.
> 
> #### Memory access var handles overhaul
> 
> The key realization here was that if all memory access var handles took a coordinate pair of `MemorySegment` and `long`, all other access types could be derived from this basic var handle form.
> 
> This allowed us to remove the on-the-fly var handle generation, and to simply derive structural access var handles (such as those obtained by calling `MemoryLayout::varHandle`) using *plain* var handle combinators, so that e.g. additional offset is injected into a base memory access var handle.
> 
> This also helped in simplifying the implementation by removing the special `withStride` and `withOffset` combinators, which previously needed low-level access on the innards of the memory access var handle. All that code is now gone.
> 
> #### Test changes
> 
> Not much to see here - most of the tests needed to be updated because of the API changes. Some were beefed up (like the array test, since now segments can be projected into many different kinds of arrays). A test has been added to test the `Cleaner` functionality, and another stress test has been added for shared segments (`TestHandshake`). Some of the microbenchmarks also needed some tweaks - and some of them were also updated to also test performance in the shared segment case.
> 
> [1] - https://openjdk.java.net/jeps/393
> [2] - https://openjdk.java.net/jeps/389
> [3] - https://mail.openjdk.java.net/pipermail/panama-dev/2020-May/009004.html
> [4] - https://openjdk.java.net/jeps/312

Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits:

 - Remove TestMismatch from 32-bit problem list
 - Merge branch 'master' into 8254162
 - Tweak javadoc for MemorySegment::mapFromPath
   Tweak alignment for long/double Java layouts on 32 bits platforms
 - Merge branch 'master' into 8254162
 - Address review comment for scoped memory access makefile
 - Address CSR comments
 - Back-port of TestByteBuffer fix
 - Merge branch 'master' into 8254162
 - Merge branch 'master' into 8254162
 - Merge branch 'master' into 8254162
 - ... and 11 more: https://git.openjdk.java.net/jdk/compare/7d41a541...f844f544

-------------

Changes: https://git.openjdk.java.net/jdk/pull/548/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=548&range=14
  Stats: 7526 lines in 80 files changed: 4814 ins; 1531 del; 1181 mod
  Patch: https://git.openjdk.java.net/jdk/pull/548.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/548/head:pull/548

PR: https://git.openjdk.java.net/jdk/pull/548

From mcimadamore at openjdk.java.net  Tue Oct 27 14:43:33 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 27 Oct 2020 14:43:33 GMT
Subject: RFR: 8254162: Implementation of Foreign-Memory Access API (Third
 Incubator)
In-Reply-To: <IngRk57F78UN3yySfo6IABbdwnMogGNdYrykh_3em-c=.b81f7478-015c-45ed-9788-58d7519a2770@github.com>
References: <IngRk57F78UN3yySfo6IABbdwnMogGNdYrykh_3em-c=.b81f7478-015c-45ed-9788-58d7519a2770@github.com>
Message-ID: <pS93Tkclki7y3uzfofkeCRZiZV8Wbb0fpPTI4aOHZXA=.b467ed27-1874-4302-833d-e022ef913dbb@github.com>

On Wed, 7 Oct 2020 17:13:22 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This patch contains the changes associated with the third incubation round of the foreign memory access API incubation  (see JEP 393 [1]). This iteration focus on improving the usability of the API in 3 main ways:
> 
> * first, by providing a way to obtain truly *shared* segments, which can be accessed and closed concurrently from multiple threads
> * second, by providing a way to register a memory segment against a `Cleaner`, so as to have some (optional) guarantee that the memory will be deallocated, eventually
> * third, by not requiring users to dive deep into var handles when they first pick up the API; a new `MemoryAccess` class has been added, which defines several useful dereference routines; these are really just thin wrappers around memory access var handles, but they make the barrier of entry for using this API somewhat lower.
> 
> A big conceptual shift that comes with this API refresh is that the role of `MemorySegment` and `MemoryAddress` is not the same as it used to be; it used to be the case that a memory address could (sometimes, not always) have a back link to the memory segment which originated it; additionally, memory access var handles used `MemoryAddress` as a basic unit of dereference.
> 
> This has all changed as per this API refresh;  now a `MemoryAddress` is just a dumb carrier which wraps a pair of object/long addressing coordinates; `MemorySegment` has become the star of the show, as far as dereferencing memory is concerned. You cannot dereference memory if you don't have a segment. This improves usability in a number of ways - first, it is a lot easier to wrap native addresses (`long`, essentially) into a `MemoryAddress`; secondly, it is crystal clear what a client has to do in order to dereference memory: if a client has a segment, it can use that; otherwise, if the client only has an address, it will have to create a segment *unsafely* (this can be done by calling `MemoryAddress::asSegmentRestricted`).
> 
> A list of the API, implementation and test changes is provided below. If  you have any questions, or need more detailed explanations, I (and the  rest of the Panama team) will be happy to point at existing discussions,  and/or to provide the feedback required. 
> 
> A big thank to Erik Osterlund, Vladimir Ivanov and David Holmes, without whom the work on shared memory segment would not have been possible; also I'd like to thank Paul Sandoz, whose insights on API design have been very helpful in this journey.
> 
> Thanks 
> Maurizio 
> 
> Javadoc: 
> 
> http://cr.openjdk.java.net/~mcimadamore/8254162_v1/javadoc/jdk/incubator/foreign/package-summary.html
> 
> Specdiff: 
> 
> http://cr.openjdk.java.net/~mcimadamore/8254162_v1/specdiff/jdk/incubator/foreign/package-summary.html
> 
> CSR: 
> 
> https://bugs.openjdk.java.net/browse/JDK-8254163
> 
> 
> 
> ### API Changes
> 
> * `MemorySegment`
>   * drop factory for restricted segment (this has been moved to `MemoryAddress`, see below)
>   * added a no-arg factory for a native restricted segment representing entire native heap
>   * rename `withOwnerThread` to `handoff`
>   * add new `share` method, to create shared segments
>   * add new `registerCleaner` method, to register a segment against a cleaner
>   * add more helpers to create arrays from a segment e.g. `toIntArray`
>   * add some `asSlice` overloads (to make up for the fact that now segments are more frequently used as cursors)
>   * rename `baseAddress` to `address` (so that `MemorySegment` can implement `Addressable`)
> * `MemoryAddress`
>   * drop `segment` accessor
>   * drop `rebase` method and replace it with `segmentOffset` which returns the offset (a `long`) of this address relative to a given segment
> * `MemoryAccess`
>   * New class supporting several static dereference helpers; the helpers are organized by carrier and access mode, where a carrier is one of the usual suspect (a Java primitive, minus `boolean`); the access mode can be simple (e.g. access base address of given segment), or indexed, in which case the accessor takes a segment and either a low-level byte offset,or a high level logical index. The classification is reflected in the naming scheme (e.g. `getByte` vs. `getByteAtOffset` vs `getByteAtIndex`).
> * `MemoryHandles`
>   * drop `withOffset` combinator
>   * drop `withStride` combinator
>   * the basic memory access handle factory now returns a var handle which takes a `MemorySegment` and a `long` - from which it is easy to derive all the other handles using plain var handle combinators.
> * `Addressable`
>   * This is a new interface which is attached to entities which can be projected to a `MemoryAddress`. For now, both `MemoryAddress` and `MemorySegment` implement it; we have plans, with JEP 389 [2] to add more implementations. Clients can largely ignore this interface, which comes in really handy when defining native bindings with tools like `jextract`.
> * `MemoryLayouts`
>   * A new layout, for machine addresses, has been added to the mix.
> 
> 
> 
> ### Implementation changes
> 
> There are two main things to discuss here: support for shared segments, and the general simplification of the memory access var handle support.
> 
> #### Shared segments
> 
> The support for shared segments cuts in pretty deep in the VM. Support for shared segments is notoriously hard to achieve, at least in a way that guarantees optimal access performances. This is caused by the fact that, if a segment is shared, it would be possible for a thread to close it while another is accessing it.
> 
> After considering several options (see [3]), we zeroed onto an approach which is inspired by an happy idea that Andrew Haley had (and that he reminded me of at this year OpenJDK committer workshop - thanks!). The idea is that if we could *freeze* the world (e.g. with a GC pause), while a segment is closed, we could then prevent segments from being accessed concurrently to a close operation. For this to work, it  is crucial that no GC safepoints can occur between a segment liveness check and the access itself (otherwise it would be possible for the accessing thread to stop just right before an unsafe call). It also relies on the fact that hotspot/C2 should not be able to propagate loads across safepoints.
> 
> Sadly, none of these conditions seems to be valid in the current implementation, so we needed to resort to a bit of creativity. First, we noted that, if we could mark so called *scoped* method with an annotation, it would be very simply to check as to whether a thread was in the middle of a scoped method when we stopped the world for a close operation (btw, instead of stopping the world, we do a much more efficient, thread-local polling, thanks to JEP 312 [4]).
> 
> The question is, then, once we detect that a thread is accessing the very segment we're about to close, what should happen? We first experimented with a solution which would install an *asynchronous* exception on the accessing thread, thus making it fail. This solution has some desirable properties, in that a `close` operation always succeeds. Unfortunately the machinery for async exceptions is a bit fragile (e.g. not all the code in hotspot checks for async exceptions); to minimize risks, we decided to revert to a simpler strategy, where `close` might fail when it finds that another thread is accessing the segment being closed.
> 
> As written in the javadoc, this doesn't mean that clients should just catch and try again; an exception on `close` is a bug in the user code, likely arising from lack of synchronization, and should be treated as such.
> 
> In terms of gritty implementation, we needed to centralize memory access routines in a single place, so that we could have a set of routines closely mimicking the primitives exposed by `Unsafe` but which, in addition, also provided a liveness check. This way we could mark all these routines with the special `@Scoped` annotation, which tells the VM that something important is going on.
> 
> To achieve this, we created a new (autogenerated) class, called `ScopedMemoryAccess`. This class contains all the main memory access primitives (including bulk access, like `copyMemory`, or `setMemory`), and accepts, in addition to the access coordinates, also a scope object, which is tested before access. A reachability fence is also thrown in the mix to make sure that the scope is kept alive during access (which is important when registering segments against cleaners).
> 
> Of course, to make memory access safe, memory access var handles, byte buffer var handles, and byte buffer API should use the new `ScopedMemoryAccess` class instead of unsafe, so that a liveness check can be triggered (in case a scope is present).
> 
> `ScopedMemoryAccess` has a `closeScope` method, which initiates the thread-local handshakes, and returns `true` if the handshake completed successfully.
> 
> The implementation of `MemoryScope` (now significantly simplified from what we had before), has two implementations, one for confined segments and one for shared segments; the main difference between the two is what happens when the scope is closed; a confined segment sets a boolean flag to false, and returns, whereas a shared segment goes into a `CLOSING` state, then starts the handshake, and then updates the state again, to either `CLOSED` or `ALIVE` depending on whether the handshake was successful or not. Note that when a shared segment is in the `CLOSING` state, `MemorySegment::isAlive` will still return `true`, while the liveness check upon memory access will fail.
> 
> #### Memory access var handles overhaul
> 
> The key realization here was that if all memory access var handles took a coordinate pair of `MemorySegment` and `long`, all other access types could be derived from this basic var handle form.
> 
> This allowed us to remove the on-the-fly var handle generation, and to simply derive structural access var handles (such as those obtained by calling `MemoryLayout::varHandle`) using *plain* var handle combinators, so that e.g. additional offset is injected into a base memory access var handle.
> 
> This also helped in simplifying the implementation by removing the special `withStride` and `withOffset` combinators, which previously needed low-level access on the innards of the memory access var handle. All that code is now gone.
> 
> #### Test changes
> 
> Not much to see here - most of the tests needed to be updated because of the API changes. Some were beefed up (like the array test, since now segments can be projected into many different kinds of arrays). A test has been added to test the `Cleaner` functionality, and another stress test has been added for shared segments (`TestHandshake`). Some of the microbenchmarks also needed some tweaks - and some of them were also updated to also test performance in the shared segment case.
> 
> [1] - https://openjdk.java.net/jeps/393
> [2] - https://openjdk.java.net/jeps/389
> [3] - https://mail.openjdk.java.net/pipermail/panama-dev/2020-May/009004.html
> [4] - https://openjdk.java.net/jeps/312

> @mcimadamore, if you pull from current master, you would get the Linux x86_32 tier1 run "for free".

Just did that - I also removed TestMismatch from the problem list in the latest iteration, and fixed the alignment for long/double layouts, after chatting with the team (https://bugs.openjdk.java.net/browse/JDK-8255350)

-------------

PR: https://git.openjdk.java.net/jdk/pull/548

From jvernee at openjdk.java.net  Tue Oct 27 15:04:20 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Tue, 27 Oct 2020 15:04:20 GMT
Subject: RFR: 8254354: Add an asExact() VarHandle combinator [v2]
In-Reply-To: <0_81dNIzQI4tZmRWVVNK_CKQRUtML4397NUe1SKL3rY=.9338ffba-c8be-4e8a-9743-9838f48e95c8@github.com>
References: <gJ1pTeZZC7tbtwiRsrHcZ1ydfTQhr1MPndGrnGolf14=.dd935929-4f22-4e41-9e0d-99a592ac46b7@github.com>
 <Mo3T9JJzO03q-I_q8NhsGpu2TVaJg_104ESGWqLhYRg=.7d353318-6827-4708-b973-a9c30558c3ed@github.com>
 <TXUctfc1V1T5RKCtSJAgQZe6xO4I561ez5Ol4YdzLeA=.3c0c41b5-a8b1-44b4-b107-1bd58db6e1a1@github.com>
 <FzY88BSt7bw9P6vmQKtXtBrd8Zwd4bE0sg39ur30x_4=.8ada75c2-7f54-4058-aa7c-822d12f9cbc9@github.com>
 <l89RFW5KvA8JvtpvCuo1q7gj2v6nRiuc_A-sN-7O0k8=.8c7153e0-d3f5-47e3-be91-a2782697ef48@github.com>
 <ih7I5nwJ_ZtY1HovULNMqrBqmbGS2m9-IgxEl2AXnao=.72cd046b-4477-43ab-bbc9-93f448e6cd3d@github.com>
 <hsUp1zTqRf1o1KJl96lNWsGbx2_Nv_HvOFaaU2xQUdI=.05f1f992-fa75-4ccd-9f14-50b0682000b7@github.com>
 <zL3Ch3atQMQlQTdcwv9-cVNwSS6h1EOVlKHJBP1nK7Q=.42ed0c79-ca03-4b31-8084-1bea69d13765@github.com>
 <94D2yl0BiGL56RmbE82u4mDhsvaCU79qDDpE3iu_Ce8=.71d1bb0a-3090-4937-b124-4ad9d5a3fcef@github.com>
 <0_81dNIzQI4tZmRWVVNK_CKQRUtML4397NUe1SKL3rY=.9338ffba-c8be-4e8a-9743-9838f48e95c8@github.com>
Message-ID: <tf6yf7PtAtS9lr0q_IPF6wwntRHpbVlYUwyGFYjhFU0=.a1c62667-82f8-4793-98e8-ae525678e85d@github.com>

On Mon, 26 Oct 2020 18:54:45 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Paul,
>> an invoker has the MethodHandle (resp. VarHandle) as first argument so it's not the same semantics.
>
> I've updated the implementation of accessModeType to work with the ordinal directly. Note that it was using the AccessType ordinal though, so I also had to change the parameter type of accessModeTypeUncached, and the respective implementations, to use AccessType directly (luckily this was possible, since the current implementations all just used the AccessType).

I think `asInvoker` and `asExactInvoker` make sense if you think of a VarHandle as an invoker of MethodHandles (though this is more of an implementation detail). But, I feel like the name `asInvoker` isn't obvious enough for what it does. i.e. it's not that obvious from the name that this removes the exactness.

If `asGeneric` is problematic, maybe just `asNonExact` works?

-------------

PR: https://git.openjdk.java.net/jdk/pull/843

From rriggs at openjdk.java.net  Tue Oct 27 15:27:39 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 27 Oct 2020 15:27:39 GMT
Subject: RFR: 8255394: jdk/test/lib/hexdump/ASN1FormatterTest.java fails
 with ---illegal-access=deny [v2]
In-Reply-To: <THZVdfmbz_07FC9iy_7yUxwSd4OrSHCIQjklDXpo3P4=.740ff977-5a85-42f8-aa39-051a9e7e1742@github.com>
References: <THZVdfmbz_07FC9iy_7yUxwSd4OrSHCIQjklDXpo3P4=.740ff977-5a85-42f8-aa39-051a9e7e1742@github.com>
Message-ID: <17YfD0Px0sJ4qRUDfhYFnghX6ftGVHwJA7pYQStS80M=.f0763fd1-e19b-40d3-9353-abaa06b40cb3@github.com>

> To access the internal security APIs to lookup known OIDs the test needs to open java.base/sun.security.util.

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  simplify: findMatch is public, so setAccessible and the module open is unnecessary

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/881/files
  - new: https://git.openjdk.java.net/jdk/pull/881/files/fb3d88a9..72037805

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=881&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=881&range=00-01

  Stats: 2 lines in 2 files changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/881.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/881/head:pull/881

PR: https://git.openjdk.java.net/jdk/pull/881

From alanb at openjdk.java.net  Tue Oct 27 15:32:20 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 27 Oct 2020 15:32:20 GMT
Subject: RFR: 8255394: jdk/test/lib/hexdump/ASN1FormatterTest.java fails
 with ---illegal-access=deny [v2]
In-Reply-To: <17YfD0Px0sJ4qRUDfhYFnghX6ftGVHwJA7pYQStS80M=.f0763fd1-e19b-40d3-9353-abaa06b40cb3@github.com>
References: <THZVdfmbz_07FC9iy_7yUxwSd4OrSHCIQjklDXpo3P4=.740ff977-5a85-42f8-aa39-051a9e7e1742@github.com>
 <17YfD0Px0sJ4qRUDfhYFnghX6ftGVHwJA7pYQStS80M=.f0763fd1-e19b-40d3-9353-abaa06b40cb3@github.com>
Message-ID: <hkffSixjEbWkGC8XMxvP4vTd5WRfpj9ibdZXEmr5l2w=.82628f0f-d7b0-4e14-ba42-95e4612192d7@github.com>

On Tue, 27 Oct 2020 15:27:39 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> To access the internal security APIs to lookup known OIDs the test needs to open java.base/sun.security.util.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   simplify: findMatch is public, so setAccessible and the module open is unnecessary

Dropping the setAccessible and change @moduels to just export sun.security.util looks fine too.

-------------

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/881

From mcimadamore at openjdk.java.net  Tue Oct 27 15:53:31 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 27 Oct 2020 15:53:31 GMT
Subject: RFR: 8254162: Implementation of Foreign-Memory Access API (Third
 Incubator) [v16]
In-Reply-To: <IngRk57F78UN3yySfo6IABbdwnMogGNdYrykh_3em-c=.b81f7478-015c-45ed-9788-58d7519a2770@github.com>
References: <IngRk57F78UN3yySfo6IABbdwnMogGNdYrykh_3em-c=.b81f7478-015c-45ed-9788-58d7519a2770@github.com>
Message-ID: <yxGqX8KkF2YWOXyHBurZtgQYiB3gOVFoTFfhCYgQxgA=.324e3414-9583-4d64-a21c-d1cb94da13f2@github.com>

> This patch contains the changes associated with the third incubation round of the foreign memory access API incubation  (see JEP 393 [1]). This iteration focus on improving the usability of the API in 3 main ways:
> 
> * first, by providing a way to obtain truly *shared* segments, which can be accessed and closed concurrently from multiple threads
> * second, by providing a way to register a memory segment against a `Cleaner`, so as to have some (optional) guarantee that the memory will be deallocated, eventually
> * third, by not requiring users to dive deep into var handles when they first pick up the API; a new `MemoryAccess` class has been added, which defines several useful dereference routines; these are really just thin wrappers around memory access var handles, but they make the barrier of entry for using this API somewhat lower.
> 
> A big conceptual shift that comes with this API refresh is that the role of `MemorySegment` and `MemoryAddress` is not the same as it used to be; it used to be the case that a memory address could (sometimes, not always) have a back link to the memory segment which originated it; additionally, memory access var handles used `MemoryAddress` as a basic unit of dereference.
> 
> This has all changed as per this API refresh;  now a `MemoryAddress` is just a dumb carrier which wraps a pair of object/long addressing coordinates; `MemorySegment` has become the star of the show, as far as dereferencing memory is concerned. You cannot dereference memory if you don't have a segment. This improves usability in a number of ways - first, it is a lot easier to wrap native addresses (`long`, essentially) into a `MemoryAddress`; secondly, it is crystal clear what a client has to do in order to dereference memory: if a client has a segment, it can use that; otherwise, if the client only has an address, it will have to create a segment *unsafely* (this can be done by calling `MemoryAddress::asSegmentRestricted`).
> 
> A list of the API, implementation and test changes is provided below. If  you have any questions, or need more detailed explanations, I (and the  rest of the Panama team) will be happy to point at existing discussions,  and/or to provide the feedback required. 
> 
> A big thank to Erik Osterlund, Vladimir Ivanov and David Holmes, without whom the work on shared memory segment would not have been possible; also I'd like to thank Paul Sandoz, whose insights on API design have been very helpful in this journey.
> 
> Thanks 
> Maurizio 
> 
> Javadoc: 
> 
> http://cr.openjdk.java.net/~mcimadamore/8254162_v1/javadoc/jdk/incubator/foreign/package-summary.html
> 
> Specdiff: 
> 
> http://cr.openjdk.java.net/~mcimadamore/8254162_v1/specdiff/jdk/incubator/foreign/package-summary.html
> 
> CSR: 
> 
> https://bugs.openjdk.java.net/browse/JDK-8254163
> 
> 
> 
> ### API Changes
> 
> * `MemorySegment`
>   * drop factory for restricted segment (this has been moved to `MemoryAddress`, see below)
>   * added a no-arg factory for a native restricted segment representing entire native heap
>   * rename `withOwnerThread` to `handoff`
>   * add new `share` method, to create shared segments
>   * add new `registerCleaner` method, to register a segment against a cleaner
>   * add more helpers to create arrays from a segment e.g. `toIntArray`
>   * add some `asSlice` overloads (to make up for the fact that now segments are more frequently used as cursors)
>   * rename `baseAddress` to `address` (so that `MemorySegment` can implement `Addressable`)
> * `MemoryAddress`
>   * drop `segment` accessor
>   * drop `rebase` method and replace it with `segmentOffset` which returns the offset (a `long`) of this address relative to a given segment
> * `MemoryAccess`
>   * New class supporting several static dereference helpers; the helpers are organized by carrier and access mode, where a carrier is one of the usual suspect (a Java primitive, minus `boolean`); the access mode can be simple (e.g. access base address of given segment), or indexed, in which case the accessor takes a segment and either a low-level byte offset,or a high level logical index. The classification is reflected in the naming scheme (e.g. `getByte` vs. `getByteAtOffset` vs `getByteAtIndex`).
> * `MemoryHandles`
>   * drop `withOffset` combinator
>   * drop `withStride` combinator
>   * the basic memory access handle factory now returns a var handle which takes a `MemorySegment` and a `long` - from which it is easy to derive all the other handles using plain var handle combinators.
> * `Addressable`
>   * This is a new interface which is attached to entities which can be projected to a `MemoryAddress`. For now, both `MemoryAddress` and `MemorySegment` implement it; we have plans, with JEP 389 [2] to add more implementations. Clients can largely ignore this interface, which comes in really handy when defining native bindings with tools like `jextract`.
> * `MemoryLayouts`
>   * A new layout, for machine addresses, has been added to the mix.
> 
> 
> 
> ### Implementation changes
> 
> There are two main things to discuss here: support for shared segments, and the general simplification of the memory access var handle support.
> 
> #### Shared segments
> 
> The support for shared segments cuts in pretty deep in the VM. Support for shared segments is notoriously hard to achieve, at least in a way that guarantees optimal access performances. This is caused by the fact that, if a segment is shared, it would be possible for a thread to close it while another is accessing it.
> 
> After considering several options (see [3]), we zeroed onto an approach which is inspired by an happy idea that Andrew Haley had (and that he reminded me of at this year OpenJDK committer workshop - thanks!). The idea is that if we could *freeze* the world (e.g. with a GC pause), while a segment is closed, we could then prevent segments from being accessed concurrently to a close operation. For this to work, it  is crucial that no GC safepoints can occur between a segment liveness check and the access itself (otherwise it would be possible for the accessing thread to stop just right before an unsafe call). It also relies on the fact that hotspot/C2 should not be able to propagate loads across safepoints.
> 
> Sadly, none of these conditions seems to be valid in the current implementation, so we needed to resort to a bit of creativity. First, we noted that, if we could mark so called *scoped* method with an annotation, it would be very simply to check as to whether a thread was in the middle of a scoped method when we stopped the world for a close operation (btw, instead of stopping the world, we do a much more efficient, thread-local polling, thanks to JEP 312 [4]).
> 
> The question is, then, once we detect that a thread is accessing the very segment we're about to close, what should happen? We first experimented with a solution which would install an *asynchronous* exception on the accessing thread, thus making it fail. This solution has some desirable properties, in that a `close` operation always succeeds. Unfortunately the machinery for async exceptions is a bit fragile (e.g. not all the code in hotspot checks for async exceptions); to minimize risks, we decided to revert to a simpler strategy, where `close` might fail when it finds that another thread is accessing the segment being closed.
> 
> As written in the javadoc, this doesn't mean that clients should just catch and try again; an exception on `close` is a bug in the user code, likely arising from lack of synchronization, and should be treated as such.
> 
> In terms of gritty implementation, we needed to centralize memory access routines in a single place, so that we could have a set of routines closely mimicking the primitives exposed by `Unsafe` but which, in addition, also provided a liveness check. This way we could mark all these routines with the special `@Scoped` annotation, which tells the VM that something important is going on.
> 
> To achieve this, we created a new (autogenerated) class, called `ScopedMemoryAccess`. This class contains all the main memory access primitives (including bulk access, like `copyMemory`, or `setMemory`), and accepts, in addition to the access coordinates, also a scope object, which is tested before access. A reachability fence is also thrown in the mix to make sure that the scope is kept alive during access (which is important when registering segments against cleaners).
> 
> Of course, to make memory access safe, memory access var handles, byte buffer var handles, and byte buffer API should use the new `ScopedMemoryAccess` class instead of unsafe, so that a liveness check can be triggered (in case a scope is present).
> 
> `ScopedMemoryAccess` has a `closeScope` method, which initiates the thread-local handshakes, and returns `true` if the handshake completed successfully.
> 
> The implementation of `MemoryScope` (now significantly simplified from what we had before), has two implementations, one for confined segments and one for shared segments; the main difference between the two is what happens when the scope is closed; a confined segment sets a boolean flag to false, and returns, whereas a shared segment goes into a `CLOSING` state, then starts the handshake, and then updates the state again, to either `CLOSED` or `ALIVE` depending on whether the handshake was successful or not. Note that when a shared segment is in the `CLOSING` state, `MemorySegment::isAlive` will still return `true`, while the liveness check upon memory access will fail.
> 
> #### Memory access var handles overhaul
> 
> The key realization here was that if all memory access var handles took a coordinate pair of `MemorySegment` and `long`, all other access types could be derived from this basic var handle form.
> 
> This allowed us to remove the on-the-fly var handle generation, and to simply derive structural access var handles (such as those obtained by calling `MemoryLayout::varHandle`) using *plain* var handle combinators, so that e.g. additional offset is injected into a base memory access var handle.
> 
> This also helped in simplifying the implementation by removing the special `withStride` and `withOffset` combinators, which previously needed low-level access on the innards of the memory access var handle. All that code is now gone.
> 
> #### Test changes
> 
> Not much to see here - most of the tests needed to be updated because of the API changes. Some were beefed up (like the array test, since now segments can be projected into many different kinds of arrays). A test has been added to test the `Cleaner` functionality, and another stress test has been added for shared segments (`TestHandshake`). Some of the microbenchmarks also needed some tweaks - and some of them were also updated to also test performance in the shared segment case.
> 
> [1] - https://openjdk.java.net/jeps/393
> [2] - https://openjdk.java.net/jeps/389
> [3] - https://mail.openjdk.java.net/pipermail/panama-dev/2020-May/009004.html
> [4] - https://openjdk.java.net/jeps/312

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  * Add final to MappedByteBuffer::SCOPED_MEMORY_ACCESS field
  * Tweak TestLayouts to make it 32-bit friendly after recent MemoryLayouts tweaks

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/548/files
  - new: https://git.openjdk.java.net/jdk/pull/548/files/f844f544..e43f5d76

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=548&range=15
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=548&range=14-15

  Stats: 8 lines in 2 files changed: 0 ins; 3 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/548.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/548/head:pull/548

PR: https://git.openjdk.java.net/jdk/pull/548

From weijun at openjdk.java.net  Tue Oct 27 15:56:19 2020
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 27 Oct 2020 15:56:19 GMT
Subject: RFR: 8255394: jdk/test/lib/hexdump/ASN1FormatterTest.java fails
 with ---illegal-access=deny [v2]
In-Reply-To: <17YfD0Px0sJ4qRUDfhYFnghX6ftGVHwJA7pYQStS80M=.f0763fd1-e19b-40d3-9353-abaa06b40cb3@github.com>
References: <THZVdfmbz_07FC9iy_7yUxwSd4OrSHCIQjklDXpo3P4=.740ff977-5a85-42f8-aa39-051a9e7e1742@github.com>
 <17YfD0Px0sJ4qRUDfhYFnghX6ftGVHwJA7pYQStS80M=.f0763fd1-e19b-40d3-9353-abaa06b40cb3@github.com>
Message-ID: <jhjG1TfdvLEoQpw2GmL-aY8bClKmKgHx8FHUxx6NNLk=.97f2b3b2-2b2b-4042-a642-420988a3f35e@github.com>

On Tue, 27 Oct 2020 15:27:39 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> To access the internal security APIs to lookup known OIDs the test needs to open java.base/sun.security.util.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   simplify: findMatch is public, so setAccessible and the module open is unnecessary

Marked as reviewed by weijun (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/881

From jlahoda at openjdk.java.net  Tue Oct 27 16:14:33 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Tue, 27 Oct 2020 16:14:33 GMT
Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12
 [v4]
In-Reply-To: <P6CERo1De3tix7TduT-Eh184-uAfYegth-i3neTAV1Y=.46960ac4-d027-4d59-a0b6-664819d1635f@github.com>
References: <RRMAPzh6xcVcxOj2S_VW_r50YvZz-3Imaj46bDi8e9U=.9347534e-d482-468a-8668-132d5516bb76@github.com>
 <DvuPT_pYUFWOCkxQnkIKxUpLqyBQYSzSDVwrqR7iz4c=.221543e2-f4ee-4e28-b7ee-80aa21a9e3a0@github.com>
 <P6CERo1De3tix7TduT-Eh184-uAfYegth-i3neTAV1Y=.46960ac4-d027-4d59-a0b6-664819d1635f@github.com>
Message-ID: <281-fNSKFfd-qngLAcLkMFdmKe-XHD-0qKCEh4OGvog=.82b534a0-e57a-41bf-ba94-e487601b2773@github.com>

On Fri, 23 Oct 2020 17:22:33 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removing unnecessary cast.
>
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractExecutableMemberWriter.java line 88:
> 
>> 86: 
>> 87:     @Override
>> 88:     protected Content getDeprecatedOrPreviewLink(Element member) {
> 
> This name is a side-effect of the `ElementFlag` question.  We should either use explicit field and method names, or we should use `ElementFlag` more consistently.   This method name works OK for now, but if if ever gets to have another `orFoo` component in the name, the signature should be parameterized with something like `ElementFlag` or its equivalent.

Note this method returns the same link for deprecate or preview - it just was named "getDeprecatedLink", and when using it work preview, I renamed it "getDeprecatedOrPreviewLink". We may need to think of a better name.

> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java line 2980:
> 
>> 2978:     }
>> 2979: 
>> 2980:     public enum DeclarationPreviewLanguageFeatures {
> 
> General thinking aloud question ... how does all this interact with source or release options for an earlier release?

I don't think there should be much interaction with -source <older-version>. We don't support preview features from previous version or preview class files from previous versions, so I think it should be enough to handle the currently present preview features.

> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java line 2984:
> 
>> 2982:         SEALED(List.of("sealed")),
>> 2983:         SEALED_PERMITS(List.of("sealed", "permits")),
>> 2984:         RECORD(List.of("record"));
> 
> I'm guessing this is about to go away soon?

Right, this is likely to go away soon.

-------------

PR: https://git.openjdk.java.net/jdk/pull/703

From aph at openjdk.java.net  Tue Oct 27 16:48:23 2020
From: aph at openjdk.java.net (Andrew Haley)
Date: Tue, 27 Oct 2020 16:48:23 GMT
Subject: RFR: 8255246: AArch64: Implement BigInteger shiftRight and
 shiftLeft accelerator/intrinsic [v2]
In-Reply-To: <SXWanOunKxTIZhkADM5Pr6Udo6HGchzjPwfLAIWCmcs=.39401cf1-f3ec-4c91-b157-244f98a685aa@github.com>
References: <r6hSDpfXd-0pLBF7HqjeUtDzunl7nCUzbCQtqGP1_rw=.fe8d5cd1-2c1d-4d2d-ac6f-fc1d9ac3ebc2@github.com>
 <SXWanOunKxTIZhkADM5Pr6Udo6HGchzjPwfLAIWCmcs=.39401cf1-f3ec-4c91-b157-244f98a685aa@github.com>
Message-ID: <Dr2DlSJvZ8l4hPJR3iYcPm2Q2Xpxfax-WkoKDV_L6Mg=.82e5d20a-6178-42dc-b545-33e3266c3055@github.com>

On Tue, 27 Oct 2020 06:32:29 GMT, Dong Bo <dongbo at openjdk.org> wrote:

>> BigInteger.shiftRightImplWorker and BigInteger.shiftLeftImplWorker are not intrinsified on aarch64, which have been done on x86_64.
>> We can implement them via USHL NEON instruction (register), which handles four integers one time at most, against just integer C2 asm-code processed.
>> The usage of USHL can be found at: https://developer.arm.com/documentation/dui0801/g/A64-SIMD-Vector-Instructions/USHL--vector-?lang=en
>> 
>> Patch passed jtreg tier1-3 tests on our aarch64 server.
>> Tests in test/jdk/java/math/BigInteger/* runned specially for the correctness of the implementation and passed.
>> 
>> We tested test/micro/org/openjdk/bench/java/math/BigIntegers.java for performance gain on Kunpeng916 and Kunpeng920.
>> The following performance improvements were seen with this implementation:
>> - Intrinsification of BigInteger.shiftLeft: 25.52% (Kunpeng916), 37.56% (Kunpeng920)
>> - Intrinsification of BigInteger.shiftRight: 46.45% (Kunpeng916), 43.32% (Kunpeng920)
>> 
>> The BigIntegers.java JMH micro-benchmark results:
>> Benchmark                      Mode  Cnt     Score    Error  Units
>> 
>> # Kunpeng 916, default
>> BigIntegers.testAdd            avgt   25    33.554 ?  0.224  ns/op
>> BigIntegers.testHugeToString   avgt   25   575.554 ? 40.656  ns/op
>> BigIntegers.testLargeToString  avgt   25   190.098 ?  0.825  ns/op
>> **BigIntegers.testLeftShift      avgt   25  1495.779 ? 12.365  ns/op**
>> BigIntegers.testMultiply       avgt   25  7551.707 ? 39.309  ns/op
>> **BigIntegers.testRightShift     avgt   25   605.302 ?  6.710  ns/op**
>> BigIntegers.testSmallToString  avgt   25   179.034 ?  0.873  ns/op
>> 
>> # Kunpeng 916, intrinsic:
>> BigIntegers.testAdd            avgt   25    33.531 ?  0.222  ns/op
>> BigIntegers.testHugeToString   avgt   25   578.038 ? 40.675  ns/op
>> BigIntegers.testLargeToString  avgt   25   188.566 ?  0.855  ns/op
>> **BigIntegers.testLeftShift      avgt   25  1191.651 ? 20.136  ns/op**
>> BigIntegers.testMultiply       avgt   25  7492.711 ?  3.702  ns/op
>> **BigIntegers.testRightShift     avgt   25   326.891 ?  6.033  ns/op**
>> BigIntegers.testSmallToString  avgt   25   178.267 ?  1.501  ns/op
>> 
>> # Kunpeng 920, default
>> BigIntegers.testAdd            avgt   25    22.790 ?  0.167  ns/op
>> BigIntegers.testHugeToString   avgt   25   432.428 ? 10.736  ns/op
>> BigIntegers.testLargeToString  avgt   25   121.899 ?  3.356  ns/op
>> **BigIntegers.testLeftShift      avgt   25   883.530 ? 53.714  ns/op**
>> BigIntegers.testMultiply       avgt   25  5918.845 ? 94.937  ns/op
>> **BigIntegers.testRightShift     avgt   25   329.762 ? 15.850  ns/op**
>> BigIntegers.testSmallToString  avgt   25   117.460 ?  3.040  ns/op
>> 
>> # Kunpeng 920, intrinsic
>> BigIntegers.testAdd            avgt   25    21.791 ?  0.085  ns/op
>> BigIntegers.testHugeToString   avgt   25   415.209 ? 32.170  ns/op
>> BigIntegers.testLargeToString  avgt   25   124.635 ?  2.157  ns/op
>> **BigIntegers.testLeftShift      avgt   25   551.710 ?  7.836  ns/op**
>> BigIntegers.testMultiply       avgt   25  5869.401 ? 54.803  ns/op
>> **BigIntegers.testRightShift     avgt   25   186.896 ?  6.378  ns/op**
>> BigIntegers.testSmallToString  avgt   25   117.543 ?  3.036  ns/op
>
> Dong Bo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor improvements for small BigIntegers

Marked as reviewed by aph (Reviewer).

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 4167:

> 4165:     __ strw(r12,  __ post(newArr, 4));
> 4166:     __ sub(numIter, numIter, 1);
> 4167:     __ cbz(numIter, Exit);

This is odd code. Why not `cbnz(numIter, ShiftOneLoop)` ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/861

From rriggs at openjdk.java.net  Tue Oct 27 18:25:22 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 27 Oct 2020 18:25:22 GMT
Subject: Integrated: 8255394: jdk/test/lib/hexdump/ASN1FormatterTest.java
 fails with ---illegal-access=deny
In-Reply-To: <THZVdfmbz_07FC9iy_7yUxwSd4OrSHCIQjklDXpo3P4=.740ff977-5a85-42f8-aa39-051a9e7e1742@github.com>
References: <THZVdfmbz_07FC9iy_7yUxwSd4OrSHCIQjklDXpo3P4=.740ff977-5a85-42f8-aa39-051a9e7e1742@github.com>
Message-ID: <a2T2izkBQYvnwDWcN8Kx9QzULb06FIGPBoBSU8kJZr4=.85759b00-4249-4575-9983-458a1bf8e6fc@github.com>

On Tue, 27 Oct 2020 14:11:48 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> To access the internal security APIs to lookup known OIDs the test needs to open java.base/sun.security.util.

This pull request has now been integrated.

Changeset: a023b937
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a023b937
Stats:     2 lines in 2 files changed: 1 ins; 1 del; 0 mod

8255394: jdk/test/lib/hexdump/ASN1FormatterTest.java fails with ---illegal-access=deny

Reviewed-by: alanb, weijun

-------------

PR: https://git.openjdk.java.net/jdk/pull/881

From sgehwolf at openjdk.java.net  Tue Oct 27 19:06:19 2020
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Tue, 27 Oct 2020 19:06:19 GMT
Subject: RFR: 8253939: [TESTBUG] Increase coverage of the cgroups
 detection code
In-Reply-To: <4G2YAmtWb3u1gyPsKK9lK5X06dKN93_zCqJvsZmjzxE=.1e754307-4dfa-417b-98e5-3af55a441145@github.com>
References: <4G2YAmtWb3u1gyPsKK9lK5X06dKN93_zCqJvsZmjzxE=.1e754307-4dfa-417b-98e5-3af55a441145@github.com>
Message-ID: <h6q0dRCnRVZWwxwO99p_nnnpeMs9jQz-0-AV-7hvD1w=.2abf3007-a3fb-4adf-ab4e-2ee2f81189d7@github.com>

On Mon, 12 Oct 2020 13:24:16 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Test only change. With [JDK-8253435](https://bugs.openjdk.java.net/browse/JDK-8253435) a test has been added on the hotspot side, but nothing for the Java Metrics code. Same for [JDK-8252359](https://bugs.openjdk.java.net/browse/JDK-8252359).
> 
> When JDK-8217766 got fixed cgroup factories with the detection logic didn't exist so were harder to test. This patch adds tests for them too.
> 
> Thoughts?

@bobvandette Could you please take a look at this when you get a chance?

I'd like to get this in before I propose [JDK-8254001](https://bugs.openjdk.java.net/browse/JDK-8254001) which would enable us to have better tests for all sorts of corner cases irrespective of the system it runs on.

-------------

PR: https://git.openjdk.java.net/jdk/pull/609

From mchung at openjdk.java.net  Tue Oct 27 19:11:24 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 27 Oct 2020 19:11:24 GMT
Subject: RFR: 8159746: (proxy) Support for default methods
In-Reply-To: <nALY_XHf4_MGKZHIzpIRbqLEG22ySg0NZ8mQbun7up0=.69d14612-31a4-4533-924c-01768ed50be1@github.com>
References: <kw2VXh3vTFf1zgfd4biXA41OKffZ5oU7KT23tXAxgUA=.bcf14ffc-4dba-4c9c-8754-184172c5acbd@github.com>
 <U-6RiCpFVIrhLztPN6opiPcpFtxValDzU-K7WWFZM-4=.6bc8aaa4-636a-4664-b380-4c4af00513bd@github.com>
 <-cLIJ8pFHtnNoJMHV3aXI7XMJWp4Jrutc8Xn5PG0OK8=.d2cd87ab-3592-4524-ad85-05444c43689b@github.com>
 <r0UK2qjnmgeTNDDSWaSLPAj3QRgx_4YB82ielllO7jM=.fa615bc0-db49-4a74-b842-793f8f5209bb@github.com>
 <1T8kXDZN1bhHr4c8v4SQsImeBySCqTfX-u3_jzvyocA=.b4957400-9a33-4b6e-8475-329642a5888c@github.com>
 <XIux-dY0JXHRafHk48kVNXId9r-HSceNSytBojDxelY=.872e74cb-b064-406e-b71f-13c90ec7fbbc@github.com>
 <j4t2vT0SnwnU7lhKRlXtk967d-K6nA0EqHrqNbba7W0=.dc05dba6-bf7e-4606-8a02-9c2bad4b3b58@github.com>
 <fmVtPcBdgMuZOPm2qx3Q3znVZM7JgQPkhPAVLtwkOhE=.2d8b8447-cfae-4cb3-9a7c-6567a881231f@github.com>
 <GSeWP29fAIUFSk0CYsC557w52CuLqeUWwHNK9maltwI=.3d5f002e-6b74-4a57-a5d8-244d27da9dde@github.com>
 <GF8iEOkMUEL2dYB0HytFIc9gyeeUJ_KP0ImlqFsul2Y=.894afc05-9310-43e1-a308-8f7d71dc572b@github.com>
 <HvtDex3cmiv7XeTMITOroYfu74amSGQavQ_
 BAmVzmXw=.223be989-7c20-4ba4-ac0d-013d2b75a8cb@github.com>
 <IqRiLphFPBpGiKAnMJXqxjie9YeZ03rcE-qG1s92BLw=.d4fd5e92-5067-40df-8a0b-1dfd3d6e23af@github.com>
 <Y0hE51G3YefI6NY1O_E6VoZSKwxE78S1hv6fEatmOG8=.0a2c686c-d9ad-418c-8c1b-49addb8a54b1@github.com>
 <QrNk57L2PWQhJjzYiGTsvYyGIPAfK7bP_kANtTR-2uM=.3e5ce990-f8ea-4751-8147-27a8a9dad40d@github.com>
 <9JNNUzfV3PSvKtSg2a_zyYJmgEn3sZL9cb5sfqemk2o=.f1ef7fb7-bdd5-44ed-98c8-59213e9094f9@github.com>
 <zWGhaC8YB5I0XgffiR7o_YT5gSp9Gbj8Drtt23brl-c=.1e59f0e4-bbe3-4fb2-94dc-c55fc862f091@github.com>
 <LljojgqBhEi6tFptsbmu1jS-Xx7lYEXm9tRkkPqDGzE=.3d7d6a37-1042-4539-88d1-9f4cf5378128@github.com>
 <Gn33ydZNxqOpWUrmYiWJadMF0mukI2MR85EtgrV4D1I=.958521f2-1167-4a68-b513-e10bba37ae18@github.com>
 <NMXKaHql9XjndqPgyoN1Lasa9H8ugl8-ltD1j2XiT9Y=.3ff8871e-0f9d-40ea-8f35-e804a9afcbd5@github.com>
 <yzFe02HJ2qt5tT8tY9ZOofnKld93x1PM5U7AToTABJs=.439c213b-94b9-488f-bb6d-a835a86c527f@github.com>
 <BoATjx7PPcLpINJVC5HM77UKMriIUqnnhcBowkJRlvM=.1221e3e1-ed27-4618-8365-dcd903d27f60@
 github.com>
 <yN0JJE9mBkqz9Ijbw4FYinv08tcnxiZHAGyarXBF9CY=.50429cb9-181a-447e-90a0-e0a0a836812e@github.com>
 <CoqZRJ39DVdNI9wzS372aAG3ZIB7hrIrndaO5VrsmBA=.f78629d2-3409-44c1-9e66-7951bbd630e6@github.com>
 <W6qIb_NPGRUpQd_obRiIumwbXSTDheSdg-qnkc3cZ90=.f1f46290-3b7c-4e88-994f-5d19e0134256@github.com>
 <nALY_XHf4_MGKZHIzpIRbqLEG22ySg0NZ8mQbun7up0=.69d14612-31a4-4533-924c-01768ed50be1@github.com>
Message-ID: <dWu0mcInZ8duRgGoQRfdgKXASYodtIhqgoejf-weUek=.eec68bf3-1a34-4f4b-82ca-6be48caeff1c@github.com>

On Tue, 27 Oct 2020 01:23:07 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Hi Mandy,
>> 
>> I think what matters here is a public surface area - what user sees. The API friendliness is the 1st aspect and very close to that is performance on the 2nd place. How complicated things are in the back is not unimportant, but very far from the leading two. I think this is how alternatives should be compared.
>> 
>> What I have done in my last attempt (https://github.com/mlchung/jdk/pull/4) is, admittedly, quite large from API surface. New `InvocationHandler2` interface taking additional `InvocationHandler2.SuperInvoker` callback + new overloaded static factory method `Proxy.newProxyInstance`. Additionally, internal checks needed to verify access at `newProxyInstance`-time are quite complicated since `InvocationHandler2` is a super-type of `InvocationHandler` and therefore the code has to check that the default implementation of `InvocationHandler.invoke(SuperInvoker, ...)` method is not overridden or else additional checks must be performed. This leads to complicated specification as to when access exceptions are thrown. From performance perspective, this variant showed least per-invocation overhead so far:
>> 
>> Benchmark               Mode  Cnt   Score   Error  Units
>> 
>> ProxyBench.implClass    avgt    5   3.777 ? 0.003  ns/op
>> ProxyBench.implProxy    avgt    5  20.282 ? 0.585  ns/op
>> ProxyBench.ppImplClass  avgt    5   3.752 ? 0.002  ns/op
>> ProxyBench.ppImplProxy  avgt    5  19.790 ? 0.335  ns/op
>> 
>> Your `DelegatingInvocationHandler` abstract class is nice and simple, but unfortunately not lambda-friendly. Will this hinder its use? I don't know. Alan says that this feature will mostly be for "experts", but even they like to use lambdas. The performance is quite OK as runtime per-invocation checks are not very expensive, just ~ 50% slower than my attempt above. Note that the allocation of 96 bytes per invocation is due to boxing 3 primitive argument ints into Integers which is unavoidable:
>> 
>> Benchmark                                                Mode  Cnt     Score      Error   Units
>> 
>> ProxyBench.implClass                                     avgt    5     3.765 ?    0.028   ns/op
>> ProxyBench.implProxy                                     avgt    5    29.812 ?    0.180   ns/op
>> ProxyBench.ppImplClass                                   avgt    5     3.705 ?    0.110   ns/op
>> ProxyBench.ppImplProxy                                   avgt    5    31.209 ?    0.900   ns/op
>> 
>> ProxyBench.implClass:?gc.alloc.rate.norm                 avgt    5    ? 10??               B/op
>> ProxyBench.implProxy:?gc.alloc.rate.norm                 avgt    5    96.004 ?    0.001    B/op
>> ProxyBench.ppImplClass:?gc.alloc.rate.norm               avgt    5    ? 10??               B/op
>> ProxyBench.ppImplProxy:?gc.alloc.rate.norm               avgt    5    96.004 ?    0.001    B/op
>> 
>> (NOTE: I noticed a possibility of a concurrent race condition in `Proxy.newProxyInstance` that could be used to fool the proxy interfaces access check - the array of interfaces is not defensively cloned)
>> 
>> Your `NewInvocationHandler` as a subinterface of `InvocationHandler` that overrides the InvocationHandler.invoke(Object proxy, ... and wires it to new abstract method taking additional DefaultMethodInvoker parameter seems similar to my last attempt, just subtype roles of old and new interfaces are reversed. This means it is easier to check whether the invocation handler has access to the super default methods or not (handler instanceof NewInvocationHandler) and adjust access checks in Proxy.newProxyInstance accordingly. But, as a consequence, the DefaultMethodInvoker instance has to be created for each invocation. You could also add an overloaded Proxy.newProxyInstance method to accept a lambda with 4 parameters (NewInvocationHandler), so this variant could be made user-friendly too, not requiring a cast. The performance is a little slower then abstract handler class. Also, the allocation of new instance of DefaultMethodInvoker per invocation seems unable to be optimized away by J
 IT escape analysis (maybe the DefaultMethodInvoker.invoke is to big to be inlined), so we have 16 additional bytes allocated per invocation:
>> 
>> Benchmark                                                Mode  Cnt     Score     Error   Units
>> 
>> ProxyBench.implClass                                     avgt    5     3.760 ?   0.049   ns/op
>> ProxyBench.implProxy                                     avgt    5    34.260 ?   0.993   ns/op
>> ProxyBench.ppImplClass                                   avgt    5     3.745 ?   0.008   ns/op
>> ProxyBench.ppImplProxy                                   avgt    5    34.247 ?   0.743   ns/op
>> 
>> ProxyBench.implClass:?gc.alloc.rate.norm                 avgt    5    ? 10??              B/op
>> ProxyBench.implProxy:?gc.alloc.rate.norm                 avgt    5   112.005 ?   0.001    B/op
>> ProxyBench.ppImplClass:?gc.alloc.rate.norm               avgt    5    ? 10??              B/op
>> ProxyBench.ppImplProxy:?gc.alloc.rate.norm               avgt    5   112.005 ?   0.001    B/op
>> 
>> 
>> From above 3 variants, I agree the `DelegatingInvocationHandler` abstract class seems to be most promising. But I have been thinking more about lambdas and have another idea that actually doesn't require any new types. Just an overloaded Proxy.newProxyInstance static method:
>> 
>> public static Object newProxyInstance(
>>     ClassLoader loader,
>>     Class<?>[] interfaces, 
>>     Function<? super InvocationHandler, ? extends InvocationHandler> handlerFactory
>> )
>> 
>> Here's the prototype:
>> 
>> https://github.com/plevart/jdk/commits/proxy-default-method-alt-api4
>> 
>> This is a patch against current https://github.com/openjdk/jdk, but all your latest "unrelated" changes (proxy class package/module) are included too. I can rebase this onto your https://github.com/mlchung/jdk/tree/proxy-default-method branch if required.
>> 
>> The performance of this one is the same as my previous alternative API 2:
>> 
>> Benchmark                                                Mode  Cnt     Score     Error   Units
>> 
>> ProxyBench.implClass                                     avgt    5     3.700 ?   0.013   ns/op
>> ProxyBench.implProxy                                     avgt    5    20.264 ?   0.551   ns/op
>> ProxyBench.ppImplClass                                   avgt    5     3.743 ?   0.028   ns/op
>> ProxyBench.ppImplProxy                                   avgt    5    20.274 ?   0.180   ns/op
>> 
>> ProxyBench.implClass:?gc.alloc.rate.norm                 avgt    5    ? 10??              B/op
>> ProxyBench.implProxy:?gc.alloc.rate.norm                 avgt    5    96.003 ?   0.001    B/op
>> ProxyBench.ppImplClass:?gc.alloc.rate.norm               avgt    5    ? 10??              B/op
>> ProxyBench.ppImplProxy:?gc.alloc.rate.norm               avgt    5    96.003 ?   0.001    B/op
>> 
>> So how does this compare to DelegatingInvocationHandler? It surely is more lambda-friendly and performance-wise it is the best we have so far. It is also not very complicated internally. The changes to ProxyGenerator are just to accomodate for new static final field holding the super-default-method InvocationHandler. Alternatively a ClassValue could be used for that without changes to ProxyGenerator albeit with somewhat bigger footprint per proxy class.
>> 
>> Now I would like to discuss one thing that relates to all implmenentations so far. Super default method invocation is currently modeled by the `Method.invoke` API, meaning that it throws `InvocationTargetException` wrapping the target exception thrown by the invoked method. But since this API is to be used from withing `InvocationHandler.invoke` implementations, such `InvocationTargetException` would typically need to be caught, unwrapped and its target exception re-thrown to honour the contract of the declared exceptions of the proxy method. If someone forgot to do that and leave `InvocationTargetException` to be thrown from `InvocationHandler.invoke` (and it would be very easy to forget that since that method is declared to throw `Throwable`), such `InvocationTargetException` would be wrapped again with `UndeclaredThrowableException` as per Proxy API behavior. So wouldn't it be better for the super-invoke API to throw exact exceptions that the invoked methods are throwing? No ca
 tch/re-throw unwrapped gymnastics would be necessary in the `InvocationHandler` implementations and forgetting to do that would not be possible. Such non-wrapping super-invoke API does not allow to distinguish between IllegalArgumentException(s) thrown by the invoked method and IllegalArgumentException(s) thrown from the API itself due to arguments incompatible with method signature though, but would one really want to distinguish them? Typically not. My alternative API 4 above uses existing `InvocationHandle.invoke` API for forwarding invocation to super default methods and this API already declares that it throws `Throwable` so it allows passing exceptions unwrapped, but current implementation still wraps exceptions thrown by the invoked method with IllegalArgumentException. If we decide that it is better to not wrap them, this can be trivially implemented.
>> 
>> Peter
>
> Hi Peter, 
> 
> Just a quick reply.  I like your idea for a `newProxyInstance` to take an invocation handler factory.   I went through the security implication and also looked into ways to avoid the need of `protected static getSuperHandler(Lookup)` method.  I haven't checked the performance and also updating the javadoc.   My prototype is in the proxy-default-method-4 branch.   I will come back to this tomorrow and respond to the other comments you had.
> 
> This approach seems promising.

Hi Peter,

To capture what I considered for security: we need to ensure that the one who can invoke the default methods of the proxy interfaces of a proxy via the super-default-method invocation handler should have access.  So
- `newProxyInstance` will do access check to ensure that the caller class has access to all proxy interfaces at proxy creation time
- `getInvocationHandler` will do access check to ensure that the caller class has access to all proxy interfaces at proxy creation time.
- the owner of the proxy instance and invocation handler should protect the super-default-method handler passed to the invocation handler factory and make sure it's not leaked to malicious code.

Since this is a new factory method, I'm thinking to move the interfaces argument to the last so that it can be a vararg, like this:

public static Object newProxyInstance(
     Function<? super InvocationHandler, ? extends InvocationHandler> handlerFactory,
     ClassLoader loader,
     Class<?>... interfaces) throws IllegalAccessException

Since the current `getInvocationHandler` API does not throw `IllegalAccessException`, we have two options
a) have `getInvocationHandler` to throw an unchecked exception  wrapping `IAE` such as `IllegalCallerException` or `IllegalArgumentException`.  Or a new `UncheckedIllegalAccessException`.
b) add a new method `Proxy.invocationHandler(Object proxy) throws IllegalAccessException`.   `getInvocationHandler` will still need to throw an unchecked exception if the given proxy supports invocation of default methods.

Responding to Peter's comments:
> The changes to ProxyGenerator are just to accomodate for new static final field holding the super-default-method InvocationHandler. Alternatively a ClassValue could be used for that without changes to ProxyGenerator albeit with somewhat bigger footprint per proxy class.

The static `newSuperHandler` method is just a bridge for the proxy class to create its super-default-method handler.  It's not really needed to expose as a public API.   Instead I pass the super-default-method to the private Proxy constructor and store it in a private final field.  Yes, a small footprint increase.  It's a tradeoff.

> So wouldn't it be better for the super-invoke API to throw exact exceptions that the invoked methods are throwing? 

With this new API, `SuperInvocationHandler` should follow the spec of `InvocationHandler::invoke`:
Throwable - the exception to throw from the method invocation on the proxy instance. The exception's type must be assignable either to any of the exception types declared in the throws clause of the interface method or to the unchecked exception types java.lang.RuntimeException or java.lang.Error. If a checked exception is thrown by this method that is not assignable to any of the exception types declared in the throws clause of the interface method, then an UndeclaredThrowableException containing the exception that was thrown by this method will be thrown by the method invocation on the proxy instance.

In other words, I agree it does not need to wrap it with `InvocationTargetException`.  And `IllegalArgumentException` may be thrown by the invoked method and also thrown due to arguments mismatched with method signature.

-------------

PR: https://git.openjdk.java.net/jdk/pull/313

From shade at openjdk.java.net  Tue Oct 27 19:12:20 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 27 Oct 2020 19:12:20 GMT
Subject: RFR: 8202471: Make type annotations on owner type parameters
 available
In-Reply-To: <WJVy8_XXMJf5UOCifoPHUc06qVaU2MKlT_oosLaiqwg=.c2b16a91-64ce-4468-991c-a51ffd6b3202@github.com>
References: <WJVy8_XXMJf5UOCifoPHUc06qVaU2MKlT_oosLaiqwg=.c2b16a91-64ce-4468-991c-a51ffd6b3202@github.com>
Message-ID: <nruqzzWvKlH2vzXaYez9l7ol30GFHrP3cU4JbwLHwO8=.8af75fe4-2cca-473d-a7aa-772da4791b0c@github.com>

On Sat, 24 Oct 2020 21:44:22 GMT, Rafael Winterhalter <winterhalter at openjdk.org> wrote:

> A method's or constructor's owner type might carry annotations on its potential type parameters but is never represented as parameterized type what makes these parameters inaccessible at runtime, despite the presence of parameter type annotations.

Hint: if you merge from master, you would get the updated test workflows, which would include the artifact with *.jtr (jtreg output) files in "testsupport". You can then use them to diagnose the testing failures you are getting.

-------------

PR: https://git.openjdk.java.net/jdk/pull/851

From mcimadamore at openjdk.java.net  Tue Oct 27 19:13:36 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 27 Oct 2020 19:13:36 GMT
Subject: RFR: 8254162: Implementation of Foreign-Memory Access API (Third
 Incubator) [v17]
In-Reply-To: <IngRk57F78UN3yySfo6IABbdwnMogGNdYrykh_3em-c=.b81f7478-015c-45ed-9788-58d7519a2770@github.com>
References: <IngRk57F78UN3yySfo6IABbdwnMogGNdYrykh_3em-c=.b81f7478-015c-45ed-9788-58d7519a2770@github.com>
Message-ID: <ZtSwsjV214aIFXeNde_xiZRxMwWuBwVPxH8cNiMYTyY=.022c3bb5-b95f-4966-b6dd-77bfe746b74d@github.com>

> This patch contains the changes associated with the third incubation round of the foreign memory access API incubation  (see JEP 393 [1]). This iteration focus on improving the usability of the API in 3 main ways:
> 
> * first, by providing a way to obtain truly *shared* segments, which can be accessed and closed concurrently from multiple threads
> * second, by providing a way to register a memory segment against a `Cleaner`, so as to have some (optional) guarantee that the memory will be deallocated, eventually
> * third, by not requiring users to dive deep into var handles when they first pick up the API; a new `MemoryAccess` class has been added, which defines several useful dereference routines; these are really just thin wrappers around memory access var handles, but they make the barrier of entry for using this API somewhat lower.
> 
> A big conceptual shift that comes with this API refresh is that the role of `MemorySegment` and `MemoryAddress` is not the same as it used to be; it used to be the case that a memory address could (sometimes, not always) have a back link to the memory segment which originated it; additionally, memory access var handles used `MemoryAddress` as a basic unit of dereference.
> 
> This has all changed as per this API refresh;  now a `MemoryAddress` is just a dumb carrier which wraps a pair of object/long addressing coordinates; `MemorySegment` has become the star of the show, as far as dereferencing memory is concerned. You cannot dereference memory if you don't have a segment. This improves usability in a number of ways - first, it is a lot easier to wrap native addresses (`long`, essentially) into a `MemoryAddress`; secondly, it is crystal clear what a client has to do in order to dereference memory: if a client has a segment, it can use that; otherwise, if the client only has an address, it will have to create a segment *unsafely* (this can be done by calling `MemoryAddress::asSegmentRestricted`).
> 
> A list of the API, implementation and test changes is provided below. If  you have any questions, or need more detailed explanations, I (and the  rest of the Panama team) will be happy to point at existing discussions,  and/or to provide the feedback required. 
> 
> A big thank to Erik Osterlund, Vladimir Ivanov and David Holmes, without whom the work on shared memory segment would not have been possible; also I'd like to thank Paul Sandoz, whose insights on API design have been very helpful in this journey.
> 
> Thanks 
> Maurizio 
> 
> Javadoc: 
> 
> http://cr.openjdk.java.net/~mcimadamore/8254162_v1/javadoc/jdk/incubator/foreign/package-summary.html
> 
> Specdiff: 
> 
> http://cr.openjdk.java.net/~mcimadamore/8254162_v1/specdiff/jdk/incubator/foreign/package-summary.html
> 
> CSR: 
> 
> https://bugs.openjdk.java.net/browse/JDK-8254163
> 
> 
> 
> ### API Changes
> 
> * `MemorySegment`
>   * drop factory for restricted segment (this has been moved to `MemoryAddress`, see below)
>   * added a no-arg factory for a native restricted segment representing entire native heap
>   * rename `withOwnerThread` to `handoff`
>   * add new `share` method, to create shared segments
>   * add new `registerCleaner` method, to register a segment against a cleaner
>   * add more helpers to create arrays from a segment e.g. `toIntArray`
>   * add some `asSlice` overloads (to make up for the fact that now segments are more frequently used as cursors)
>   * rename `baseAddress` to `address` (so that `MemorySegment` can implement `Addressable`)
> * `MemoryAddress`
>   * drop `segment` accessor
>   * drop `rebase` method and replace it with `segmentOffset` which returns the offset (a `long`) of this address relative to a given segment
> * `MemoryAccess`
>   * New class supporting several static dereference helpers; the helpers are organized by carrier and access mode, where a carrier is one of the usual suspect (a Java primitive, minus `boolean`); the access mode can be simple (e.g. access base address of given segment), or indexed, in which case the accessor takes a segment and either a low-level byte offset,or a high level logical index. The classification is reflected in the naming scheme (e.g. `getByte` vs. `getByteAtOffset` vs `getByteAtIndex`).
> * `MemoryHandles`
>   * drop `withOffset` combinator
>   * drop `withStride` combinator
>   * the basic memory access handle factory now returns a var handle which takes a `MemorySegment` and a `long` - from which it is easy to derive all the other handles using plain var handle combinators.
> * `Addressable`
>   * This is a new interface which is attached to entities which can be projected to a `MemoryAddress`. For now, both `MemoryAddress` and `MemorySegment` implement it; we have plans, with JEP 389 [2] to add more implementations. Clients can largely ignore this interface, which comes in really handy when defining native bindings with tools like `jextract`.
> * `MemoryLayouts`
>   * A new layout, for machine addresses, has been added to the mix.
> 
> 
> 
> ### Implementation changes
> 
> There are two main things to discuss here: support for shared segments, and the general simplification of the memory access var handle support.
> 
> #### Shared segments
> 
> The support for shared segments cuts in pretty deep in the VM. Support for shared segments is notoriously hard to achieve, at least in a way that guarantees optimal access performances. This is caused by the fact that, if a segment is shared, it would be possible for a thread to close it while another is accessing it.
> 
> After considering several options (see [3]), we zeroed onto an approach which is inspired by an happy idea that Andrew Haley had (and that he reminded me of at this year OpenJDK committer workshop - thanks!). The idea is that if we could *freeze* the world (e.g. with a GC pause), while a segment is closed, we could then prevent segments from being accessed concurrently to a close operation. For this to work, it  is crucial that no GC safepoints can occur between a segment liveness check and the access itself (otherwise it would be possible for the accessing thread to stop just right before an unsafe call). It also relies on the fact that hotspot/C2 should not be able to propagate loads across safepoints.
> 
> Sadly, none of these conditions seems to be valid in the current implementation, so we needed to resort to a bit of creativity. First, we noted that, if we could mark so called *scoped* method with an annotation, it would be very simply to check as to whether a thread was in the middle of a scoped method when we stopped the world for a close operation (btw, instead of stopping the world, we do a much more efficient, thread-local polling, thanks to JEP 312 [4]).
> 
> The question is, then, once we detect that a thread is accessing the very segment we're about to close, what should happen? We first experimented with a solution which would install an *asynchronous* exception on the accessing thread, thus making it fail. This solution has some desirable properties, in that a `close` operation always succeeds. Unfortunately the machinery for async exceptions is a bit fragile (e.g. not all the code in hotspot checks for async exceptions); to minimize risks, we decided to revert to a simpler strategy, where `close` might fail when it finds that another thread is accessing the segment being closed.
> 
> As written in the javadoc, this doesn't mean that clients should just catch and try again; an exception on `close` is a bug in the user code, likely arising from lack of synchronization, and should be treated as such.
> 
> In terms of gritty implementation, we needed to centralize memory access routines in a single place, so that we could have a set of routines closely mimicking the primitives exposed by `Unsafe` but which, in addition, also provided a liveness check. This way we could mark all these routines with the special `@Scoped` annotation, which tells the VM that something important is going on.
> 
> To achieve this, we created a new (autogenerated) class, called `ScopedMemoryAccess`. This class contains all the main memory access primitives (including bulk access, like `copyMemory`, or `setMemory`), and accepts, in addition to the access coordinates, also a scope object, which is tested before access. A reachability fence is also thrown in the mix to make sure that the scope is kept alive during access (which is important when registering segments against cleaners).
> 
> Of course, to make memory access safe, memory access var handles, byte buffer var handles, and byte buffer API should use the new `ScopedMemoryAccess` class instead of unsafe, so that a liveness check can be triggered (in case a scope is present).
> 
> `ScopedMemoryAccess` has a `closeScope` method, which initiates the thread-local handshakes, and returns `true` if the handshake completed successfully.
> 
> The implementation of `MemoryScope` (now significantly simplified from what we had before), has two implementations, one for confined segments and one for shared segments; the main difference between the two is what happens when the scope is closed; a confined segment sets a boolean flag to false, and returns, whereas a shared segment goes into a `CLOSING` state, then starts the handshake, and then updates the state again, to either `CLOSED` or `ALIVE` depending on whether the handshake was successful or not. Note that when a shared segment is in the `CLOSING` state, `MemorySegment::isAlive` will still return `true`, while the liveness check upon memory access will fail.
> 
> #### Memory access var handles overhaul
> 
> The key realization here was that if all memory access var handles took a coordinate pair of `MemorySegment` and `long`, all other access types could be derived from this basic var handle form.
> 
> This allowed us to remove the on-the-fly var handle generation, and to simply derive structural access var handles (such as those obtained by calling `MemoryLayout::varHandle`) using *plain* var handle combinators, so that e.g. additional offset is injected into a base memory access var handle.
> 
> This also helped in simplifying the implementation by removing the special `withStride` and `withOffset` combinators, which previously needed low-level access on the innards of the memory access var handle. All that code is now gone.
> 
> #### Test changes
> 
> Not much to see here - most of the tests needed to be updated because of the API changes. Some were beefed up (like the array test, since now segments can be projected into many different kinds of arrays). A test has been added to test the `Cleaner` functionality, and another stress test has been added for shared segments (`TestHandshake`). Some of the microbenchmarks also needed some tweaks - and some of them were also updated to also test performance in the shared segment case.
> 
> [1] - https://openjdk.java.net/jeps/393
> [2] - https://openjdk.java.net/jeps/389
> [3] - https://mail.openjdk.java.net/pipermail/panama-dev/2020-May/009004.html
> [4] - https://openjdk.java.net/jeps/312

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  More 32-bit fixes for TestLayouts

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/548/files
  - new: https://git.openjdk.java.net/jdk/pull/548/files/e43f5d76..b01af093

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=548&range=16
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=548&range=15-16

  Stats: 10 lines in 1 file changed: 2 ins; 4 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/548.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/548/head:pull/548

PR: https://git.openjdk.java.net/jdk/pull/548

From plevart at openjdk.java.net  Tue Oct 27 21:48:19 2020
From: plevart at openjdk.java.net (Peter Levart)
Date: Tue, 27 Oct 2020 21:48:19 GMT
Subject: RFR: 8159746: (proxy) Support for default methods
In-Reply-To: <dWu0mcInZ8duRgGoQRfdgKXASYodtIhqgoejf-weUek=.eec68bf3-1a34-4f4b-82ca-6be48caeff1c@github.com>
References: <kw2VXh3vTFf1zgfd4biXA41OKffZ5oU7KT23tXAxgUA=.bcf14ffc-4dba-4c9c-8754-184172c5acbd@github.com>
 <U-6RiCpFVIrhLztPN6opiPcpFtxValDzU-K7WWFZM-4=.6bc8aaa4-636a-4664-b380-4c4af00513bd@github.com>
 <-cLIJ8pFHtnNoJMHV3aXI7XMJWp4Jrutc8Xn5PG0OK8=.d2cd87ab-3592-4524-ad85-05444c43689b@github.com>
 <r0UK2qjnmgeTNDDSWaSLPAj3QRgx_4YB82ielllO7jM=.fa615bc0-db49-4a74-b842-793f8f5209bb@github.com>
 <1T8kXDZN1bhHr4c8v4SQsImeBySCqTfX-u3_jzvyocA=.b4957400-9a33-4b6e-8475-329642a5888c@github.com>
 <XIux-dY0JXHRafHk48kVNXId9r-HSceNSytBojDxelY=.872e74cb-b064-406e-b71f-13c90ec7fbbc@github.com>
 <j4t2vT0SnwnU7lhKRlXtk967d-K6nA0EqHrqNbba7W0=.dc05dba6-bf7e-4606-8a02-9c2bad4b3b58@github.com>
 <fmVtPcBdgMuZOPm2qx3Q3znVZM7JgQPkhPAVLtwkOhE=.2d8b8447-cfae-4cb3-9a7c-6567a881231f@github.com>
 <GSeWP29fAIUFSk0CYsC557w52CuLqeUWwHNK9maltwI=.3d5f002e-6b74-4a57-a5d8-244d27da9dde@github.com>
 <GF8iEOkMUEL2dYB0HytFIc9gyeeUJ_KP0ImlqFsul2Y=.894afc05-9310-43e1-a308-8f7d71dc572b@github.com>
 <HvtDex3cmiv7XeTMITOroYfu74amSGQavQ_
 BAmVzmXw=.223be989-7c20-4ba4-ac0d-013d2b75a8cb@github.com>
 <IqRiLphFPBpGiKAnMJXqxjie9YeZ03rcE-qG1s92BLw=.d4fd5e92-5067-40df-8a0b-1dfd3d6e23af@github.com>
 <Y0hE51G3YefI6NY1O_E6VoZSKwxE78S1hv6fEatmOG8=.0a2c686c-d9ad-418c-8c1b-49addb8a54b1@github.com>
 <QrNk57L2PWQhJjzYiGTsvYyGIPAfK7bP_kANtTR-2uM=.3e5ce990-f8ea-4751-8147-27a8a9dad40d@github.com>
 <9JNNUzfV3PSvKtSg2a_zyYJmgEn3sZL9cb5sfqemk2o=.f1ef7fb7-bdd5-44ed-98c8-59213e9094f9@github.com>
 <zWGhaC8YB5I0XgffiR7o_YT5gSp9Gbj8Drtt23brl-c=.1e59f0e4-bbe3-4fb2-94dc-c55fc862f091@github.com>
 <LljojgqBhEi6tFptsbmu1jS-Xx7lYEXm9tRkkPqDGzE=.3d7d6a37-1042-4539-88d1-9f4cf5378128@github.com>
 <Gn33ydZNxqOpWUrmYiWJadMF0mukI2MR85EtgrV4D1I=.958521f2-1167-4a68-b513-e10bba37ae18@github.com>
 <NMXKaHql9XjndqPgyoN1Lasa9H8ugl8-ltD1j2XiT9Y=.3ff8871e-0f9d-40ea-8f35-e804a9afcbd5@github.com>
 <yzFe02HJ2qt5tT8tY9ZOofnKld93x1PM5U7AToTABJs=.439c213b-94b9-488f-bb6d-a835a86c527f@github.com>
 <BoATjx7PPcLpINJVC5HM77UKMriIUqnnhcBowkJRlvM=.1221e3e1-ed27-4618-8365-dcd903d27f60@
 github.com>
 <yN0JJE9mBkqz9Ijbw4FYinv08tcnxiZHAGyarXBF9CY=.50429cb9-181a-447e-90a0-e0a0a836812e@github.com>
 <CoqZRJ39DVdNI9wzS372aAG3ZIB7hrIrndaO5VrsmBA=.f78629d2-3409-44c1-9e66-7951bbd630e6@github.com>
 <W6qIb_NPGRUpQd_obRiIumwbXSTDheSdg-qnkc3cZ90=.f1f46290-3b7c-4e88-994f-5d19e0134256@github.com>
 <nALY_XHf4_MGKZHIzpIRbqLEG22ySg0NZ8mQbun7up0=.69d14612-31a4-4533-924c-01768ed50be1@github.com>
 <dWu0mcInZ8duRgGoQRfdgKXASYodtIhqgoejf-weUek=.eec68bf3-1a34-4f4b-82ca-6be48caeff1c@github.com>
Message-ID: <S-gpV6ntV3fkkjzvU8PYpAWAJVWpvdykReMXyRVwd9U=.0893dd0d-55d0-49c1-9bb9-883005fed496@github.com>

On Tue, 27 Oct 2020 19:08:10 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Hi Peter, 
>> 
>> Just a quick reply.  I like your idea for a `newProxyInstance` to take an invocation handler factory.   I went through the security implication and also looked into ways to avoid the need of `protected static getSuperHandler(Lookup)` method.  I haven't checked the performance and also updating the javadoc.   My prototype is in the proxy-default-method-4 branch.   I will come back to this tomorrow and respond to the other comments you had.
>> 
>> This approach seems promising.
>
> Hi Peter,
> 
> To capture what I considered for security: we need to ensure that the one who can invoke the default methods of the proxy interfaces of a proxy via the super-default-method invocation handler should have access.  So
> - `newProxyInstance` will do access check to ensure that the caller class has access to all proxy interfaces at proxy creation time
> - `getInvocationHandler` will do access check to ensure that the caller class has access to all proxy interfaces at proxy creation time.
> - the owner of the proxy instance and invocation handler should protect the super-default-method handler passed to the invocation handler factory and make sure it's not leaked to malicious code.
> 
> Since this is a new factory method, I'm thinking to move the interfaces argument to the last so that it can be a vararg, like this:
> 
> public static Object newProxyInstance(
>      Function<? super InvocationHandler, ? extends InvocationHandler> handlerFactory,
>      ClassLoader loader,
>      Class<?>... interfaces) throws IllegalAccessException
> 
> But the usage may be a bit strange.
> Proxy.newProxyInstance(superHandler -> (p, m, a) -> superHandler.invoke(p, m, a),
>              loader, I.class, J.class);
> 
> Since the current `getInvocationHandler` API does not throw `IllegalAccessException`, we have two options
> a) have `getInvocationHandler` to throw an unchecked exception  wrapping `IAE` such as `IllegalCallerException` or `IllegalArgumentException`.  Or a new `UncheckedIllegalAccessException`.
> b) add a new method `Proxy.invocationHandler(Object proxy) throws IllegalAccessException`.   `getInvocationHandler` will still need to throw an unchecked exception if the given proxy supports invocation of default methods.
> 
> Responding to Peter's comments:
>> The changes to ProxyGenerator are just to accomodate for new static final field holding the super-default-method InvocationHandler. Alternatively a ClassValue could be used for that without changes to ProxyGenerator albeit with somewhat bigger footprint per proxy class.
> 
> The static `newSuperHandler` method is just a bridge for the proxy class to create its super-default-method handler.  It's not really needed to expose as a public API.   Instead I pass the super-default-method to the private Proxy constructor and store it in a private final field.  Yes, a small footprint increase.  It's a tradeoff.
> 
>> So wouldn't it be better for the super-invoke API to throw exact exceptions that the invoked methods are throwing? 
> 
> With this new API, `SuperInvocationHandler` should follow the spec of `InvocationHandler::invoke`:
> Throwable - the exception to throw from the method invocation on the proxy instance. The exception's type must be assignable either to any of the exception types declared in the throws clause of the interface method or to the unchecked exception types java.lang.RuntimeException or java.lang.Error. If a checked exception is thrown by this method that is not assignable to any of the exception types declared in the throws clause of the interface method, then an UndeclaredThrowableException containing the exception that was thrown by this method will be thrown by the method invocation on the proxy instance.
> 
> In other words, I agree it does not need to wrap it with `InvocationTargetException`.  And `IllegalArgumentException` may be thrown by the invoked method and also thrown due to arguments mismatched with method signature.

Hi Mandy,

Comments inline...

> Hi Peter,
> 
> To capture what I considered for security: we need to ensure that the one who can invoke the default methods of the proxy interfaces of a proxy via the super-default-method invocation handler should have access. So
> 
>     * `newProxyInstance` will do access check to ensure that the caller class has access to all proxy interfaces at proxy creation time
> 
>     * `getInvocationHandler` will do access check to ensure that the caller class has access to all proxy interfaces at proxy creation time.
> 
>     * the owner of the proxy instance and invocation handler should protect the super-default-method handler passed to the invocation handler factory and make sure it's not leaked to malicious code.

I agree (see about exceptions below).

> 
> 
> Since this is a new factory method, I'm thinking to move the interfaces argument to the last so that it can be a vararg, like this:
> 
> ```
> public static Object newProxyInstance(
>      Function<? super InvocationHandler, ? extends InvocationHandler> handlerFactory,
>      ClassLoader loader,
>      Class<?>... interfaces) throws IllegalAccessException
> ```
> 
> But the usage may be a bit strange.
> 
> ```
> Proxy.newProxyInstance(superHandler -> (p, m, a) -> superHandler.invoke(p, m, a),
>              loader, I.class, J.class);
> ```

Well, yes. Vararg parameter can only be the last parameter, but lambda parameter looks best as the last parameter too. In particular if it is a statement lambda (with curly braces in lambda body and long body). So I'm divided on that part. What about a List<Class<?>> insteadn of Class<?>[] ? Hm...

Proxy.newProxyInstance(loader, of(I.class, J.class), superHandler -> (p, m, a) -> {
    ...
});

Vs.

Proxy.newProxyInstance(loader, new Class<?>[] {I.class, J.class}, superHandler -> (p, m, a) -> {
    ...
});

Not too bad. Shortening `List.of(I.class, J.class)` to `of(I.class, J.class)` with static import we get almost the same character count without reordering lambda parameter...


> 
> Since the current `getInvocationHandler` API does not throw `IllegalAccessException`, we have two options
> a) have `getInvocationHandler` to throw an unchecked exception wrapping `IAE` such as `IllegalCallerException` or `IllegalArgumentException`. Or a new `UncheckedIllegalAccessException`.
> b) add a new method `Proxy.invocationHandler(Object proxy) throws IllegalAccessException`. `getInvocationHandler` will still need to throw an unchecked exception if the given proxy supports invocation of default methods.
> 

I'm divided on this one too. But, if we must create new exception type, then instead of `UncheckedIllegalAccessException`, we could create a type that covers all `ReflectiveOperationException`(s) like `UncheckedIOException` covers all `IOException`(s). We could create an `UncheckedReflectiveOperationException` which would be universally useful for wrapping reflective exceptions in lambdas etc.

Question remains how do we distinguish proxies with old-fassioned InvocationHandlers from proxies with InvocationHandlers having access to super-default-handler. Both kinds of handlers look the same from Proxy's perspective... Perhaps we need a boolean flag in Proxy instance for that, coupled with an overloaded constructor that takes it...

> Responding to Peter's comments:
> 
> > The changes to ProxyGenerator are just to accomodate for new static final field holding the super-default-method InvocationHandler. Alternatively a ClassValue could be used for that without changes to ProxyGenerator albeit with somewhat bigger footprint per proxy class.
> 
> The static `newSuperHandler` method is just a bridge for the proxy class to create its super-default-method handler. It's not really needed to expose as a public API. Instead I pass the super-default-method to the private Proxy constructor and store it in a private final field. Yes, a small footprint increase. It's a tradeoff.
> 

Problem with this approach is that it is not really useful in the proxy instance. We don't need it in the proxy instance. We need it before we call the invocation handler factory function with it and that is before we create the proxy instance with the resulting invocation handler. We need to cache it at the proxy class level. No problem, we can use ClassValue for that. What I achieved with protected static Proxy.newSuperHandler method was an easy way to pass the Lookup object created in the static initializer of the proxy class down to the constructor of the SuperHandler.  But if we have an internal way of constructing a full-privileged Lookup object with proxy class as lookup class, then we don't need to construct it in the proxy class static initializer... One way to do that was your implementation of a generated static method in the proxy class that verifies the caller by checking the passed in Lookup object is full-privileged Lookup with Proxy.class as lookup class and then cons
 tructs and returns its own Lookup instance (LIEP - Lookup Instance Exchange Protocol).

> > So wouldn't it be better for the super-invoke API to throw exact exceptions that the invoked methods are throwing?
> 
> With this new API, `SuperInvocationHandler` should follow the spec of `InvocationHandler::invoke`:
> 
> ```
> Throwable - the exception to throw from the method invocation on the proxy instance. The exception's type must be assignable either to any of the exception types declared in the throws clause of the interface method or to the unchecked exception types java.lang.RuntimeException or java.lang.Error. If a checked exception is thrown by this method that is not assignable to any of the exception types declared in the throws clause of the interface method, then an UndeclaredThrowableException containing the exception that was thrown by this method will be thrown by the method invocation on the proxy instance.
> ```
> 
> In other words, I agree it does not need to wrap it with `InvocationTargetException`. And `IllegalArgumentException` may be thrown by the invoked method and also thrown due to arguments mismatched with method signature.

Right. It feels better that way. I can take some time tomorrow or in then next days to prepare a variant with these changes if we reach an agreement on the exceptions thrown from getInvocationHandler(proxy) method...

-------------

PR: https://git.openjdk.java.net/jdk/pull/313

From github.com+11685886+marcono1234 at openjdk.java.net  Tue Oct 27 23:04:23 2020
From: github.com+11685886+marcono1234 at openjdk.java.net (Marcono1234)
Date: Tue, 27 Oct 2020 23:04:23 GMT
Subject: RFR: 8251989: Hex formatting and parsing utility [v9]
In-Reply-To: <kq3eysudL5ES5M41vZvEHRO9BLv7uSJM1BUy4hcWFpg=.0ba9b80f-4a14-46b4-ba22-2b664efd0fdd@github.com>
References: <HSEn47GMS1K3g57mrTZeQk-WZHl3pKGHpX_OOf8VnsU=.740863c2-f9e4-43c4-b500-614aab4078b1@github.com>
 <kq3eysudL5ES5M41vZvEHRO9BLv7uSJM1BUy4hcWFpg=.0ba9b80f-4a14-46b4-ba22-2b664efd0fdd@github.com>
Message-ID: <24K9pRWZszSVT9sxe05nKv2QJUiMHQ8k8Dn-30cc0m4=.ce3767a3-8820-403e-af24-ab671b9309ee@github.com>

On Tue, 27 Oct 2020 03:09:32 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> java.util.HexFormat utility:
>> 
>>  - Format and parse hexadecimal strings, with parameters for delimiter, prefix, suffix and upper/lowercase
>>  - Static factories and builder methods to create HexFormat copies with modified parameters.
>>  - Consistent naming of methods for conversion of byte arrays to formatted strings and back: formatHex and parseHex
>>  - Consistent naming of methods for conversion of primitive types: toHexDigits... and fromHexDigits...
>>  - Prefix and suffixes now apply to each formatted value, not the string as a whole
>>  - Using java.util.Appendable as a target for buffered conversions so output to Writers and PrintStreams
>>    like System.out are supported in addition to StringBuilder. (IOExceptions are converted to unchecked exceptions)
>>  - Immutable and thread safe, a "value-based" class
>> 
>> See the [HexFormat javadoc](http://cr.openjdk.java.net/~rriggs/8251989-hex-formatter/java.base/java/util/HexFormat.html) for details.
>> 
>> Review comments and suggestions welcome.
>
> Roger Riggs has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - The HexFormat API indexing model for array and string ranges is changed
>    to describe the range using 'fromIndex (inclusive)' and 'toIndex (exclusive)'.
>    
>    Initially, it was specified as 'index' and 'length'. However, both byte arrays
>    and strings used in the HexFormat API typically use fromIndex and toIndex
>    to describe ranges.  Using the same indexing model can prevent mistakes.
>    
>    The change affects the methods and corresponding tests:
>    
>        formatHex(byte[] bytes, int fromIndex, int toIndex)
>        formatHex(A out, byte[] bytes, int fromIndex, int toIndex)
>        parseHex(char[] chars, int fromIndex, int toIndex)
>        parseHex(CharSequence string, int fromIndex, int toIndex)
>        fromHexDigits(CharSequence string, int fromIndex, int toIndex)
>        fromHexDigitsToLong(CharSequence string, int fromIndex, int toIndex)
>  - - Added @see and @link references to Integer.toHexString and Long.toHexString
>    - Clarified parsing is case insensistive in various parse and fromXXX methods
>    - Source level cleanup based on review comments
>    - Expanded some javadoc tag text to make it more descriptive
>    - Consistent use of 'hexadecimal' vs 'hex'

The changes look good, especially that `Integer.toHexString` and `Long.toHexString` now link to this new class!

src/java.base/share/classes/java/lang/Integer.java line 260:

> 258:      *  {@code Integer.toHexString(n).toUpperCase()}
> 259:      * </blockquote>
> 260:      * <p>

Is this needed? `@apiNote` is a block tag so should create a paragraph on its own.

src/java.base/share/classes/java/lang/Long.java line 295:

> 293:      *  {@code Long.toHexString(n).toUpperCase()}
> 294:      * </blockquote>
> 295:      * <p>

Is this needed? `@apiNote` is a block tag so should create a paragraph on its own.

src/java.base/share/classes/java/util/HexFormat.java line 316:

> 314:      * @param bytes a non-null array of bytes
> 315:      * @param fromIndex the initial index of the range, inclusive
> 316:      * @param toIndex the final index of the range, exclusive.

Suggestion:

     * @param toIndex the final index of the range, exclusive

The period at the end is inconsistent.
Applies to the other `@param toIndex` as well.

-------------

PR: https://git.openjdk.java.net/jdk/pull/482

From mchung at openjdk.java.net  Wed Oct 28 03:09:24 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 28 Oct 2020 03:09:24 GMT
Subject: RFR: 8159746: (proxy) Support for default methods
In-Reply-To: <S-gpV6ntV3fkkjzvU8PYpAWAJVWpvdykReMXyRVwd9U=.0893dd0d-55d0-49c1-9bb9-883005fed496@github.com>
References: <kw2VXh3vTFf1zgfd4biXA41OKffZ5oU7KT23tXAxgUA=.bcf14ffc-4dba-4c9c-8754-184172c5acbd@github.com>
 <U-6RiCpFVIrhLztPN6opiPcpFtxValDzU-K7WWFZM-4=.6bc8aaa4-636a-4664-b380-4c4af00513bd@github.com>
 <-cLIJ8pFHtnNoJMHV3aXI7XMJWp4Jrutc8Xn5PG0OK8=.d2cd87ab-3592-4524-ad85-05444c43689b@github.com>
 <r0UK2qjnmgeTNDDSWaSLPAj3QRgx_4YB82ielllO7jM=.fa615bc0-db49-4a74-b842-793f8f5209bb@github.com>
 <1T8kXDZN1bhHr4c8v4SQsImeBySCqTfX-u3_jzvyocA=.b4957400-9a33-4b6e-8475-329642a5888c@github.com>
 <XIux-dY0JXHRafHk48kVNXId9r-HSceNSytBojDxelY=.872e74cb-b064-406e-b71f-13c90ec7fbbc@github.com>
 <j4t2vT0SnwnU7lhKRlXtk967d-K6nA0EqHrqNbba7W0=.dc05dba6-bf7e-4606-8a02-9c2bad4b3b58@github.com>
 <fmVtPcBdgMuZOPm2qx3Q3znVZM7JgQPkhPAVLtwkOhE=.2d8b8447-cfae-4cb3-9a7c-6567a881231f@github.com>
 <GSeWP29fAIUFSk0CYsC557w52CuLqeUWwHNK9maltwI=.3d5f002e-6b74-4a57-a5d8-244d27da9dde@github.com>
 <GF8iEOkMUEL2dYB0HytFIc9gyeeUJ_KP0ImlqFsul2Y=.894afc05-9310-43e1-a308-8f7d71dc572b@github.com>
 <HvtDex3cmiv7XeTMITOroYfu74amSGQavQ_
 BAmVzmXw=.223be989-7c20-4ba4-ac0d-013d2b75a8cb@github.com>
 <IqRiLphFPBpGiKAnMJXqxjie9YeZ03rcE-qG1s92BLw=.d4fd5e92-5067-40df-8a0b-1dfd3d6e23af@github.com>
 <Y0hE51G3YefI6NY1O_E6VoZSKwxE78S1hv6fEatmOG8=.0a2c686c-d9ad-418c-8c1b-49addb8a54b1@github.com>
 <QrNk57L2PWQhJjzYiGTsvYyGIPAfK7bP_kANtTR-2uM=.3e5ce990-f8ea-4751-8147-27a8a9dad40d@github.com>
 <9JNNUzfV3PSvKtSg2a_zyYJmgEn3sZL9cb5sfqemk2o=.f1ef7fb7-bdd5-44ed-98c8-59213e9094f9@github.com>
 <zWGhaC8YB5I0XgffiR7o_YT5gSp9Gbj8Drtt23brl-c=.1e59f0e4-bbe3-4fb2-94dc-c55fc862f091@github.com>
 <LljojgqBhEi6tFptsbmu1jS-Xx7lYEXm9tRkkPqDGzE=.3d7d6a37-1042-4539-88d1-9f4cf5378128@github.com>
 <Gn33ydZNxqOpWUrmYiWJadMF0mukI2MR85EtgrV4D1I=.958521f2-1167-4a68-b513-e10bba37ae18@github.com>
 <NMXKaHql9XjndqPgyoN1Lasa9H8ugl8-ltD1j2XiT9Y=.3ff8871e-0f9d-40ea-8f35-e804a9afcbd5@github.com>
 <yzFe02HJ2qt5tT8tY9ZOofnKld93x1PM5U7AToTABJs=.439c213b-94b9-488f-bb6d-a835a86c527f@github.com>
 <BoATjx7PPcLpINJVC5HM77UKMriIUqnnhcBowkJRlvM=.1221e3e1-ed27-4618-8365-dcd903d27f60@
 github.com>
 <yN0JJE9mBkqz9Ijbw4FYinv08tcnxiZHAGyarXBF9CY=.50429cb9-181a-447e-90a0-e0a0a836812e@github.com>
 <CoqZRJ39DVdNI9wzS372aAG3ZIB7hrIrndaO5VrsmBA=.f78629d2-3409-44c1-9e66-7951bbd630e6@github.com>
 <W6qIb_NPGRUpQd_obRiIumwbXSTDheSdg-qnkc3cZ90=.f1f46290-3b7c-4e88-994f-5d19e0134256@github.com>
 <nALY_XHf4_MGKZHIzpIRbqLEG22ySg0NZ8mQbun7up0=.69d14612-31a4-4533-924c-01768ed50be1@github.com>
 <dWu0mcInZ8duRgGoQRfdgKXASYodtIhqgoejf-weUek=.eec68bf3-1a34-4f4b-82ca-6be48caeff1c@github.com>
 <S-gpV6ntV3fkkjzvU8PYpAWAJVWpvdykReMXyRVwd9U=.0893dd0d-55d0-49c1-9bb9-883005fed496@github.com>
Message-ID: <VE9aWCMrcLW5QIl0wRpGppb0gObfI0cfbg0DnuKRfSs=.e398df44-4b64-465a-9697-8b4d2ed1652d@github.com>

On Tue, 27 Oct 2020 21:45:53 GMT, Peter Levart <plevart at openjdk.org> wrote:

>> Hi Peter,
>> 
>> To capture what I considered for security: we need to ensure that the one who can invoke the default methods of the proxy interfaces of a proxy via the super-default-method invocation handler should have access.  So
>> - `newProxyInstance` will do access check to ensure that the caller class has access to all proxy interfaces at proxy creation time
>> - `getInvocationHandler` will do access check to ensure that the caller class has access to all proxy interfaces at proxy creation time.
>> - the owner of the proxy instance and invocation handler should protect the super-default-method handler passed to the invocation handler factory and make sure it's not leaked to malicious code.
>> 
>> Since this is a new factory method, I'm thinking to move the interfaces argument to the last so that it can be a vararg, like this:
>> 
>> public static Object newProxyInstance(
>>      Function<? super InvocationHandler, ? extends InvocationHandler> handlerFactory,
>>      ClassLoader loader,
>>      Class<?>... interfaces) throws IllegalAccessException
>> 
>> But the usage may be a bit strange.
>> Proxy.newProxyInstance(superHandler -> (p, m, a) -> superHandler.invoke(p, m, a),
>>              loader, I.class, J.class);
>> 
>> Since the current `getInvocationHandler` API does not throw `IllegalAccessException`, we have two options
>> a) have `getInvocationHandler` to throw an unchecked exception  wrapping `IAE` such as `IllegalCallerException` or `IllegalArgumentException`.  Or a new `UncheckedIllegalAccessException`.
>> b) add a new method `Proxy.invocationHandler(Object proxy) throws IllegalAccessException`.   `getInvocationHandler` will still need to throw an unchecked exception if the given proxy supports invocation of default methods.
>> 
>> Responding to Peter's comments:
>>> The changes to ProxyGenerator are just to accomodate for new static final field holding the super-default-method InvocationHandler. Alternatively a ClassValue could be used for that without changes to ProxyGenerator albeit with somewhat bigger footprint per proxy class.
>> 
>> The static `newSuperHandler` method is just a bridge for the proxy class to create its super-default-method handler.  It's not really needed to expose as a public API.   Instead I pass the super-default-method to the private Proxy constructor and store it in a private final field.  Yes, a small footprint increase.  It's a tradeoff.
>> 
>>> So wouldn't it be better for the super-invoke API to throw exact exceptions that the invoked methods are throwing? 
>> 
>> With this new API, `SuperInvocationHandler` should follow the spec of `InvocationHandler::invoke`:
>> Throwable - the exception to throw from the method invocation on the proxy instance. The exception's type must be assignable either to any of the exception types declared in the throws clause of the interface method or to the unchecked exception types java.lang.RuntimeException or java.lang.Error. If a checked exception is thrown by this method that is not assignable to any of the exception types declared in the throws clause of the interface method, then an UndeclaredThrowableException containing the exception that was thrown by this method will be thrown by the method invocation on the proxy instance.
>> 
>> In other words, I agree it does not need to wrap it with `InvocationTargetException`.  And `IllegalArgumentException` may be thrown by the invoked method and also thrown due to arguments mismatched with method signature.
>
> Hi Mandy,
> 
> Comments inline...
> 
>> Hi Peter,
>> 
>> To capture what I considered for security: we need to ensure that the one who can invoke the default methods of the proxy interfaces of a proxy via the super-default-method invocation handler should have access. So
>> 
>>     * `newProxyInstance` will do access check to ensure that the caller class has access to all proxy interfaces at proxy creation time
>> 
>>     * `getInvocationHandler` will do access check to ensure that the caller class has access to all proxy interfaces at proxy creation time.
>> 
>>     * the owner of the proxy instance and invocation handler should protect the super-default-method handler passed to the invocation handler factory and make sure it's not leaked to malicious code.
> 
> I agree (see about exceptions below).
> 
>> 
>> 
>> Since this is a new factory method, I'm thinking to move the interfaces argument to the last so that it can be a vararg, like this:
>> 
>> ```
>> public static Object newProxyInstance(
>>      Function<? super InvocationHandler, ? extends InvocationHandler> handlerFactory,
>>      ClassLoader loader,
>>      Class<?>... interfaces) throws IllegalAccessException
>> ```
>> 
>> But the usage may be a bit strange.
>> 
>> ```
>> Proxy.newProxyInstance(superHandler -> (p, m, a) -> superHandler.invoke(p, m, a),
>>              loader, I.class, J.class);
>> ```
> 
> Well, yes. Vararg parameter can only be the last parameter, but lambda parameter looks best as the last parameter too. In particular if it is a statement lambda (with curly braces in lambda body and long body). So I'm divided on that part. What about a List<Class<?>> insteadn of Class<?>[] ? Hm...
> 
> Proxy.newProxyInstance(loader, of(I.class, J.class), superHandler -> (p, m, a) -> {
>     ...
> });
> 
> Vs.
> 
> Proxy.newProxyInstance(loader, new Class<?>[] {I.class, J.class}, superHandler -> (p, m, a) -> {
>     ...
> });
> 
> Not too bad. Shortening `List.of(I.class, J.class)` to `of(I.class, J.class)` with static import we get almost the same character count without reordering lambda parameter...
> 
> 
>> 
>> Since the current `getInvocationHandler` API does not throw `IllegalAccessException`, we have two options
>> a) have `getInvocationHandler` to throw an unchecked exception wrapping `IAE` such as `IllegalCallerException` or `IllegalArgumentException`. Or a new `UncheckedIllegalAccessException`.
>> b) add a new method `Proxy.invocationHandler(Object proxy) throws IllegalAccessException`. `getInvocationHandler` will still need to throw an unchecked exception if the given proxy supports invocation of default methods.
>> 
> 
> I'm divided on this one too. But, if we must create new exception type, then instead of `UncheckedIllegalAccessException`, we could create a type that covers all `ReflectiveOperationException`(s) like `UncheckedIOException` covers all `IOException`(s). We could create an `UncheckedReflectiveOperationException` which would be universally useful for wrapping reflective exceptions in lambdas etc.
> 
> Question remains how do we distinguish proxies with old-fassioned InvocationHandlers from proxies with InvocationHandlers having access to super-default-handler. Both kinds of handlers look the same from Proxy's perspective... Perhaps we need a boolean flag in Proxy instance for that, coupled with an overloaded constructor that takes it...
> 
>> Responding to Peter's comments:
>> 
>> > The changes to ProxyGenerator are just to accomodate for new static final field holding the super-default-method InvocationHandler. Alternatively a ClassValue could be used for that without changes to ProxyGenerator albeit with somewhat bigger footprint per proxy class.
>> 
>> The static `newSuperHandler` method is just a bridge for the proxy class to create its super-default-method handler. It's not really needed to expose as a public API. Instead I pass the super-default-method to the private Proxy constructor and store it in a private final field. Yes, a small footprint increase. It's a tradeoff.
>> 
> 
> Problem with this approach is that it is not really useful in the proxy instance. We don't need it in the proxy instance. We need it before we call the invocation handler factory function with it and that is before we create the proxy instance with the resulting invocation handler. We need to cache it at the proxy class level. No problem, we can use ClassValue for that. What I achieved with protected static Proxy.newSuperHandler method was an easy way to pass the Lookup object created in the static initializer of the proxy class down to the constructor of the SuperHandler.  But if we have an internal way of constructing a full-privileged Lookup object with proxy class as lookup class, then we don't need to construct it in the proxy class static initializer... One way to do that was your implementation of a generated static method in the proxy class that verifies the caller by checking the passed in Lookup object is full-privileged Lookup with Proxy.class as lookup class and then co
 nstructs and returns its own Lookup instance (LIEP - Lookup Instance Exchange Protocol).
> 
>> > So wouldn't it be better for the super-invoke API to throw exact exceptions that the invoked methods are throwing?
>> 
>> With this new API, `SuperInvocationHandler` should follow the spec of `InvocationHandler::invoke`:
>> 
>> ```
>> Throwable - the exception to throw from the method invocation on the proxy instance. The exception's type must be assignable either to any of the exception types declared in the throws clause of the interface method or to the unchecked exception types java.lang.RuntimeException or java.lang.Error. If a checked exception is thrown by this method that is not assignable to any of the exception types declared in the throws clause of the interface method, then an UndeclaredThrowableException containing the exception that was thrown by this method will be thrown by the method invocation on the proxy instance.
>> ```
>> 
>> In other words, I agree it does not need to wrap it with `InvocationTargetException`. And `IllegalArgumentException` may be thrown by the invoked method and also thrown due to arguments mismatched with method signature.
> 
> Right. It feels better that way. I can take some time tomorrow or in then next days to prepare a variant with these changes if we reach an agreement on the exceptions thrown from getInvocationHandler(proxy) method...

Hi Peter,

> Question remains how do we distinguish proxies with old-fassioned InvocationHandlers from proxies with InvocationHandlers having access to super-default-handler. Both kinds of handlers look the same from Proxy's perspective... Perhaps we need a boolean flag in Proxy instance for that, coupled with an overloaded constructor that takes it...

I have the Proxy constructor taking both the invocation handler and `superHandler` in my [mlchung:proxy-default-method-4](https://github.com/mlchung/jdk/tree/proxy-default-method-4) branch.

> Problem with this approach is that it is not really useful in the proxy instance. We don't need it in the proxy instance. 

See above.

About the exception thrown: we need to distinguish CCE and NPE thrown by the default method vs thrown by arguments incompatible with the method signature.  In my proxy-default-method-4 branch, I define an internal exception type for that.  There is an overhead doing the wrapping but it's an exception case which performance should not be critical.

-------------

PR: https://git.openjdk.java.net/jdk/pull/313

From dongbo at openjdk.java.net  Wed Oct 28 03:30:18 2020
From: dongbo at openjdk.java.net (Dong Bo)
Date: Wed, 28 Oct 2020 03:30:18 GMT
Subject: RFR: 8255246: AArch64: Implement BigInteger shiftRight and
 shiftLeft accelerator/intrinsic [v2]
In-Reply-To: <Dr2DlSJvZ8l4hPJR3iYcPm2Q2Xpxfax-WkoKDV_L6Mg=.82e5d20a-6178-42dc-b545-33e3266c3055@github.com>
References: <r6hSDpfXd-0pLBF7HqjeUtDzunl7nCUzbCQtqGP1_rw=.fe8d5cd1-2c1d-4d2d-ac6f-fc1d9ac3ebc2@github.com>
 <SXWanOunKxTIZhkADM5Pr6Udo6HGchzjPwfLAIWCmcs=.39401cf1-f3ec-4c91-b157-244f98a685aa@github.com>
 <Dr2DlSJvZ8l4hPJR3iYcPm2Q2Xpxfax-WkoKDV_L6Mg=.82e5d20a-6178-42dc-b545-33e3266c3055@github.com>
Message-ID: <JXvYCi7sShkgAfYuF0bqHjdytdL1ijeKXKpFK1x7NGs=.ac8ceca3-265f-4deb-9fbd-7b621fbd8c78@github.com>

On Mon, 26 Oct 2020 10:40:27 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Dong Bo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   minor improvements for small BigIntegers
>
> src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 4167:
> 
>> 4165:     __ strw(r12,  __ post(newArr, 4));
>> 4166:     __ sub(numIter, numIter, 1);
>> 4167:     __ cbz(numIter, Exit);
> 
> This is odd code. Why not `cbnz(numIter, ShiftOneLoop)` ?

My bad, it should be cbnz(numIter, ShiftOneLoop).
But it's gone now, the ShiftOneLoop is unrolled in the newest version.
Do you think we need further modifications?

-------------

PR: https://git.openjdk.java.net/jdk/pull/861

From smarks at openjdk.java.net  Wed Oct 28 03:49:19 2020
From: smarks at openjdk.java.net (Stuart Marks)
Date: Wed, 28 Oct 2020 03:49:19 GMT
Subject: RFR: 8188055: (ref) Add Reference::refersTo predicate [v6]
In-Reply-To: <Rb6cPrJ-LEz3AupzI7Zp2pCC4tXfilcve_dxhRzBHps=.7dd76a96-035e-49ba-b3a3-df73f9a42e09@github.com>
References: <D4HSg8FT20Eaxk5KJkkw0GgETSxRkBn1ipS3Dt0kPto=.e4bab078-2e04-4413-90cb-9bfafb2a6831@github.com>
 <Y1IHoNr8vO3OkCbEKw6ywXd4adik1yKKNIS4ABzF0d0=.d21f4183-ef4e-45ed-826d-6613215b6220@github.com>
 <9x0zaxknpYXGIvHun1CkLP0lEC8NQmPTnANxQKjhHF8=.907bdb15-2e2e-4f84-8fe4-ea4ed50534cd@github.com>
 <DR2YKv3VavKKD-cpFyf6mCSYfaKq0KAGh2XDqBStkys=.895ba671-f63a-4ba3-b042-6568d647b4ab@github.com>
 <mkn_t3hsL4mlCOfO5ahZOMbp8i_LMOHwJALA_bNjHIk=.d8031a91-ed13-4882-925f-ea8a9e634198@github.com>
 <3JzF7OkemZ-Lxc4jZgdEh3qNDzW8wF7ITeq-s7_TOlo=.11e4e40b-b775-47cf-9862-735fbc61ffd3@github.com>
 <iPK64Jh4aJtfqoPDqADOBN8BczKet53bod5y_VjZoBw=.fed662e8-2b40-478b-a9de-4906c0a897dc@github.com>
 <3kV3qhFRXBadf7Tol9n0Yomud_ndV_T_p7ShUfk4eVE=.d7151a63-0066-4020-b0ef-bae0d03dc133@github.com>
 <WhvzLc5GEYMSBz9jYgaRDBTbpaZGFWPHqzdfYHa-W6Q=.8efc48fe-6ae2-4608-ba4c-136df49c3707@github.com>
 <Rb6cPrJ-LEz3AupzI7Zp2pCC4tXfilcve_dxhRzBHps=.7dd76a96-035e-49ba-b3a3-df73f9a42e09@github.com>
Message-ID: <a3JuXf0MtVHpL7iS2Af5dmzj9aPY6yGENU59L025sVY=.03691a63-b4bf-494f-9b0e-408459f844c3@github.com>

On Sat, 24 Oct 2020 22:22:56 GMT, Peter Levart <plevart at openjdk.org> wrote:

>> Reference instances should not be leaked and so I don't see very common that caller of `Reference::get` does not know the referent's type.   It also depends on the `refersTo` check against `null` vs an object.  Any known use case would be helpful if any (some existing code that wants to call `refersTo` to compare a `Reference` of raw type with an object of unknown type).
>> 
>> FWIW, when converting a few use of `Reference::get` to `refersTo` in JDK, there is only one case (`equals(Object o)` method that needs the cast.
>> 
>> http://cr.openjdk.java.net/~mchung/jdk15/webrevs/8188055/jdk-use-refersTo/index.html
>
> @mlchung I don't have many known use cases, but how about WeakHashMap.containsKey(Object key) for example? Currently `WeakHashMap.Entry<K, V> extends  WeakReference<Object>` but it would be more type safe if it extended `WeakReference<K>`. In that case an `entry.refersTo(key)` would not compile...
> What I'm trying to say is that even if `Reference` instances are not "leaked", you can get an untyped object reference from outside and you may want to identity-compare it with the Reference's referent.

Some thoughts regarding the parameter type of refersTo. Summary: I think `refersTo(T)` is fine and that we don't want to change it to `refersTo(Object)`.

I don't think we have a migration issue similar to generifying collections, where there was a possibility of changing `contains(Object)` to `contains(E)`. If that had been done, it would have been a source compatibility issue, because changing the signature of the method potentially affects existing code that calls the method. That doesn't apply here because we're adding a new method.

The question now falls to whether it's preferable to have more convenience with `refersTo(Object)` or more type-safety with `refersTo(T)`. With the generic collections issue, the migration issue probably drove the decision to keep `contains(Object)`, but this has resulted in a continual set of complaints about the lack of an error when code passes an instance of the "wrong" type. I think that kind of error is likely to occur with `refersTo`. Since we don't have a source compatibility issue here, we can choose the safer API and avoid this kind of problem entirely.

The safer API does raise the possibility of having to add inconvenient unchecked casts and local variables in certain places, but I think Mandy's comment about the code already having a reference of the "right" type is correct. Her prototype webrev linked above shows that having to add unchecked casts is fairly infrequent.

-------------

PR: https://git.openjdk.java.net/jdk/pull/498

From smarks at openjdk.java.net  Wed Oct 28 03:52:24 2020
From: smarks at openjdk.java.net (Stuart Marks)
Date: Wed, 28 Oct 2020 03:52:24 GMT
Subject: RFR: 8188055: (ref) Add Reference::refersTo predicate [v6]
In-Reply-To: <0dhF_xxcp1VoUowwdZenB2qWa9ILcZjTMe3lsaRrg7k=.3c633db8-f745-4353-ad34-a64fbc96d4e0@github.com>
References: <D4HSg8FT20Eaxk5KJkkw0GgETSxRkBn1ipS3Dt0kPto=.e4bab078-2e04-4413-90cb-9bfafb2a6831@github.com>
 <0dhF_xxcp1VoUowwdZenB2qWa9ILcZjTMe3lsaRrg7k=.3c633db8-f745-4353-ad34-a64fbc96d4e0@github.com>
Message-ID: <gg5pNOeZrTRXHisqBBsBrFTfwemvTf6WgEySMRjW7ik=.0ba485e8-c77a-47c2-9210-abaf6fc6a28d@github.com>

On Wed, 21 Oct 2020 02:28:30 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Finally returning to this review that was started in April 2020.  I've
>> recast it as a github PR.  I think the security concern raised by Gil
>> has been adequately answered.
>> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-April/029203.html
>> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-July/030401.html
>> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-August/030677.html
>> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-September/030793.html
>> 
>> Please review a new function: java.lang.ref.Reference.refersTo.
>> 
>> This function is needed to test the referent of a Reference object without
>> artificially extending the lifetime of the referent object, as may happen
>> when calling Reference.get.  Some garbage collectors require extending the
>> lifetime of a weak referent when accessed, in order to maintain collector
>> invariants.  Lifetime extension may occur with any collector when the
>> Reference is a SoftReference, as calling get indicates recent access.  This
>> new function also allows testing the referent of a PhantomReference, which
>> can't be accessed by calling get.
>> 
>> The new function uses native methods whose implementations are in the VM so
>> they can use the Access API.  It is the intent that these methods will be
>> intrinsified by optimizing compilers like C2 or graal, but that hasn't been
>> implemented yet.  Bear that in mind before rushing off to change existing
>> uses of Reference.get.
>> 
>> There are two native methods involved, one in Reference and an override in
>> PhantomReference, both package private in java.lang.ref. The reason for this
>> split is to simplify the intrinsification. This is a change from the version
>> from April 2020; that version had a single native method in Reference,
>> implemented using the ON_UNKNOWN_OOP_REF Access reference strength category.
>> However, adding support for that category in the compilers adds significant
>> implementation effort and complexity. Splitting avoids that complexity.
>> 
>> Testing:
>> mach5 tier1
>> Locally (linux-x64) verified the new test passes with various garbage collectors.
>
> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
> 
>   improve wording in refersTo javadoc

Marked as reviewed by smarks (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/498

From plevart at openjdk.java.net  Wed Oct 28 08:38:22 2020
From: plevart at openjdk.java.net (Peter Levart)
Date: Wed, 28 Oct 2020 08:38:22 GMT
Subject: RFR: 8159746: (proxy) Support for default methods
In-Reply-To: <VE9aWCMrcLW5QIl0wRpGppb0gObfI0cfbg0DnuKRfSs=.e398df44-4b64-465a-9697-8b4d2ed1652d@github.com>
References: <kw2VXh3vTFf1zgfd4biXA41OKffZ5oU7KT23tXAxgUA=.bcf14ffc-4dba-4c9c-8754-184172c5acbd@github.com>
 <U-6RiCpFVIrhLztPN6opiPcpFtxValDzU-K7WWFZM-4=.6bc8aaa4-636a-4664-b380-4c4af00513bd@github.com>
 <-cLIJ8pFHtnNoJMHV3aXI7XMJWp4Jrutc8Xn5PG0OK8=.d2cd87ab-3592-4524-ad85-05444c43689b@github.com>
 <r0UK2qjnmgeTNDDSWaSLPAj3QRgx_4YB82ielllO7jM=.fa615bc0-db49-4a74-b842-793f8f5209bb@github.com>
 <1T8kXDZN1bhHr4c8v4SQsImeBySCqTfX-u3_jzvyocA=.b4957400-9a33-4b6e-8475-329642a5888c@github.com>
 <XIux-dY0JXHRafHk48kVNXId9r-HSceNSytBojDxelY=.872e74cb-b064-406e-b71f-13c90ec7fbbc@github.com>
 <j4t2vT0SnwnU7lhKRlXtk967d-K6nA0EqHrqNbba7W0=.dc05dba6-bf7e-4606-8a02-9c2bad4b3b58@github.com>
 <fmVtPcBdgMuZOPm2qx3Q3znVZM7JgQPkhPAVLtwkOhE=.2d8b8447-cfae-4cb3-9a7c-6567a881231f@github.com>
 <GSeWP29fAIUFSk0CYsC557w52CuLqeUWwHNK9maltwI=.3d5f002e-6b74-4a57-a5d8-244d27da9dde@github.com>
 <GF8iEOkMUEL2dYB0HytFIc9gyeeUJ_KP0ImlqFsul2Y=.894afc05-9310-43e1-a308-8f7d71dc572b@github.com>
 <HvtDex3cmiv7XeTMITOroYfu74amSGQavQ_
 BAmVzmXw=.223be989-7c20-4ba4-ac0d-013d2b75a8cb@github.com>
 <IqRiLphFPBpGiKAnMJXqxjie9YeZ03rcE-qG1s92BLw=.d4fd5e92-5067-40df-8a0b-1dfd3d6e23af@github.com>
 <Y0hE51G3YefI6NY1O_E6VoZSKwxE78S1hv6fEatmOG8=.0a2c686c-d9ad-418c-8c1b-49addb8a54b1@github.com>
 <QrNk57L2PWQhJjzYiGTsvYyGIPAfK7bP_kANtTR-2uM=.3e5ce990-f8ea-4751-8147-27a8a9dad40d@github.com>
 <9JNNUzfV3PSvKtSg2a_zyYJmgEn3sZL9cb5sfqemk2o=.f1ef7fb7-bdd5-44ed-98c8-59213e9094f9@github.com>
 <zWGhaC8YB5I0XgffiR7o_YT5gSp9Gbj8Drtt23brl-c=.1e59f0e4-bbe3-4fb2-94dc-c55fc862f091@github.com>
 <LljojgqBhEi6tFptsbmu1jS-Xx7lYEXm9tRkkPqDGzE=.3d7d6a37-1042-4539-88d1-9f4cf5378128@github.com>
 <Gn33ydZNxqOpWUrmYiWJadMF0mukI2MR85EtgrV4D1I=.958521f2-1167-4a68-b513-e10bba37ae18@github.com>
 <NMXKaHql9XjndqPgyoN1Lasa9H8ugl8-ltD1j2XiT9Y=.3ff8871e-0f9d-40ea-8f35-e804a9afcbd5@github.com>
 <yzFe02HJ2qt5tT8tY9ZOofnKld93x1PM5U7AToTABJs=.439c213b-94b9-488f-bb6d-a835a86c527f@github.com>
 <BoATjx7PPcLpINJVC5HM77UKMriIUqnnhcBowkJRlvM=.1221e3e1-ed27-4618-8365-dcd903d27f60@
 github.com>
 <yN0JJE9mBkqz9Ijbw4FYinv08tcnxiZHAGyarXBF9CY=.50429cb9-181a-447e-90a0-e0a0a836812e@github.com>
 <CoqZRJ39DVdNI9wzS372aAG3ZIB7hrIrndaO5VrsmBA=.f78629d2-3409-44c1-9e66-7951bbd630e6@github.com>
 <W6qIb_NPGRUpQd_obRiIumwbXSTDheSdg-qnkc3cZ90=.f1f46290-3b7c-4e88-994f-5d19e0134256@github.com>
 <nALY_XHf4_MGKZHIzpIRbqLEG22ySg0NZ8mQbun7up0=.69d14612-31a4-4533-924c-01768ed50be1@github.com>
 <dWu0mcInZ8duRgGoQRfdgKXASYodtIhqgoejf-weUek=.eec68bf3-1a34-4f4b-82ca-6be48caeff1c@github.com>
 <S-gpV6ntV3fkkjzvU8PYpAWAJVWpvdykReMXyRVwd9U=.0893dd0d-55d0-49c1-9bb9-883005fed496@github.com>
 <VE9aWCMrcLW5QIl0wRpGppb0gObfI0cfbg0DnuKRfSs=.e398df44-4b64-465a-9697-8b4d2ed1652d@github.com>
Message-ID: <50_1vC3yErplQgnnTNJHpF-d0ibuMKtRa9kg3jGKymc=.978abc22-8b04-49ed-b950-7bafe2b1931a@github.com>

On Wed, 28 Oct 2020 03:06:04 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> Hi Peter,
> 
> > Question remains how do we distinguish proxies with old-fassioned InvocationHandlers from proxies with InvocationHandlers having access to super-default-handler. Both kinds of handlers look the same from Proxy's perspective... Perhaps we need a boolean flag in Proxy instance for that, coupled with an overloaded constructor that takes it...
> 
> I have the Proxy constructor taking both the invocation handler and `superHandler` in my [mlchung:proxy-default-method-4](https://github.com/mlchung/jdk/tree/proxy-default-method-4) branch.
> 

Yes, but it is not really useful there. The super handler is captured by the user invocation handler created in the invocation handler factory function and it is only used by the user invocation handler. All we need in the proxy instance is a boolean flag indicating the way the invocation handler was created (which one of the two overloaded newProxyInstance methods was called).

> > Problem with this approach is that it is not really useful in the proxy instance. We don't need it in the proxy instance.
> 
> See above.
> 
> About the exception thrown: we need to distinguish CCE and NPE thrown by the default method vs thrown by arguments incompatible with the method signature. In my proxy-default-method-4 branch, I define an internal exception type for that. There is an overhead doing the wrapping but it's an exception case which performance should not be critical.

To be precise, we need to pass CCE and NPE thrown by the default method unchanged, but we need to wrap CCE and NPE thrown by the method handle transformation chain with IllegalArgumentException. Is that what you are referring to? In that case we need an internal exception type, not exposed to public API, used just to "tunnel" the exception from the default method unchanged. That's just implementation detail.

But we have to ask ourselves a question: "Do we want to wrap CCE and NPE thrown by the method handle transformation chain with IllegalArgumentException?". We did that in previous variants to mimic the Method.invoke specification. But now we already departed from that specification by not wrapping exceptions thrown by the default method with InvocationTargetException. So we are not obligated to follow the rest of the Method.invoke specification either. All exception types thrown by method handle transformation chain (CCE, NPE, IAE) are unchecked exceptions and as such are not eligible to wrapping with UndeclaredThrowableException by the Proxy API. So it's just a matter of deciding what is more suitable: to have more specific exception types (CCE, NPE, IAE) for describing transformation exceptions or to reduce them to one common type (IAE). In either case those exception types can also be thrown by the default method and we can't or even want to distinguish their source. Let's be hones
 t, all of CCE, NPE, IAE are usually describing the subtle variants of the same thing: that the parameters are wrong. Whether this happens in the logic of invocation handler, method handle transformation chain or the default method, we want those exceptions to propagate out of the invoked proxy method unchanged.

So WDYT?

-------------

PR: https://git.openjdk.java.net/jdk/pull/313

From plevart at openjdk.java.net  Wed Oct 28 08:44:25 2020
From: plevart at openjdk.java.net (Peter Levart)
Date: Wed, 28 Oct 2020 08:44:25 GMT
Subject: RFR: 8159746: (proxy) Support for default methods
In-Reply-To: <50_1vC3yErplQgnnTNJHpF-d0ibuMKtRa9kg3jGKymc=.978abc22-8b04-49ed-b950-7bafe2b1931a@github.com>
References: <kw2VXh3vTFf1zgfd4biXA41OKffZ5oU7KT23tXAxgUA=.bcf14ffc-4dba-4c9c-8754-184172c5acbd@github.com>
 <U-6RiCpFVIrhLztPN6opiPcpFtxValDzU-K7WWFZM-4=.6bc8aaa4-636a-4664-b380-4c4af00513bd@github.com>
 <-cLIJ8pFHtnNoJMHV3aXI7XMJWp4Jrutc8Xn5PG0OK8=.d2cd87ab-3592-4524-ad85-05444c43689b@github.com>
 <r0UK2qjnmgeTNDDSWaSLPAj3QRgx_4YB82ielllO7jM=.fa615bc0-db49-4a74-b842-793f8f5209bb@github.com>
 <1T8kXDZN1bhHr4c8v4SQsImeBySCqTfX-u3_jzvyocA=.b4957400-9a33-4b6e-8475-329642a5888c@github.com>
 <XIux-dY0JXHRafHk48kVNXId9r-HSceNSytBojDxelY=.872e74cb-b064-406e-b71f-13c90ec7fbbc@github.com>
 <j4t2vT0SnwnU7lhKRlXtk967d-K6nA0EqHrqNbba7W0=.dc05dba6-bf7e-4606-8a02-9c2bad4b3b58@github.com>
 <fmVtPcBdgMuZOPm2qx3Q3znVZM7JgQPkhPAVLtwkOhE=.2d8b8447-cfae-4cb3-9a7c-6567a881231f@github.com>
 <GSeWP29fAIUFSk0CYsC557w52CuLqeUWwHNK9maltwI=.3d5f002e-6b74-4a57-a5d8-244d27da9dde@github.com>
 <GF8iEOkMUEL2dYB0HytFIc9gyeeUJ_KP0ImlqFsul2Y=.894afc05-9310-43e1-a308-8f7d71dc572b@github.com>
 <HvtDex3cmiv7XeTMITOroYfu74amSGQavQ_
 BAmVzmXw=.223be989-7c20-4ba4-ac0d-013d2b75a8cb@github.com>
 <IqRiLphFPBpGiKAnMJXqxjie9YeZ03rcE-qG1s92BLw=.d4fd5e92-5067-40df-8a0b-1dfd3d6e23af@github.com>
 <Y0hE51G3YefI6NY1O_E6VoZSKwxE78S1hv6fEatmOG8=.0a2c686c-d9ad-418c-8c1b-49addb8a54b1@github.com>
 <QrNk57L2PWQhJjzYiGTsvYyGIPAfK7bP_kANtTR-2uM=.3e5ce990-f8ea-4751-8147-27a8a9dad40d@github.com>
 <9JNNUzfV3PSvKtSg2a_zyYJmgEn3sZL9cb5sfqemk2o=.f1ef7fb7-bdd5-44ed-98c8-59213e9094f9@github.com>
 <zWGhaC8YB5I0XgffiR7o_YT5gSp9Gbj8Drtt23brl-c=.1e59f0e4-bbe3-4fb2-94dc-c55fc862f091@github.com>
 <LljojgqBhEi6tFptsbmu1jS-Xx7lYEXm9tRkkPqDGzE=.3d7d6a37-1042-4539-88d1-9f4cf5378128@github.com>
 <Gn33ydZNxqOpWUrmYiWJadMF0mukI2MR85EtgrV4D1I=.958521f2-1167-4a68-b513-e10bba37ae18@github.com>
 <NMXKaHql9XjndqPgyoN1Lasa9H8ugl8-ltD1j2XiT9Y=.3ff8871e-0f9d-40ea-8f35-e804a9afcbd5@github.com>
 <yzFe02HJ2qt5tT8tY9ZOofnKld93x1PM5U7AToTABJs=.439c213b-94b9-488f-bb6d-a835a86c527f@github.com>
 <BoATjx7PPcLpINJVC5HM77UKMriIUqnnhcBowkJRlvM=.1221e3e1-ed27-4618-8365-dcd903d27f60@
 github.com>
 <yN0JJE9mBkqz9Ijbw4FYinv08tcnxiZHAGyarXBF9CY=.50429cb9-181a-447e-90a0-e0a0a836812e@github.com>
 <CoqZRJ39DVdNI9wzS372aAG3ZIB7hrIrndaO5VrsmBA=.f78629d2-3409-44c1-9e66-7951bbd630e6@github.com>
 <W6qIb_NPGRUpQd_obRiIumwbXSTDheSdg-qnkc3cZ90=.f1f46290-3b7c-4e88-994f-5d19e0134256@github.com>
 <nALY_XHf4_MGKZHIzpIRbqLEG22ySg0NZ8mQbun7up0=.69d14612-31a4-4533-924c-01768ed50be1@github.com>
 <dWu0mcInZ8duRgGoQRfdgKXASYodtIhqgoejf-weUek=.eec68bf3-1a34-4f4b-82ca-6be48caeff1c@github.com>
 <S-gpV6ntV3fkkjzvU8PYpAWAJVWpvdykReMXyRVwd9U=.0893dd0d-55d0-49c1-9bb9-883005fed496@github.com>
 <VE9aWCMrcLW5QIl0wRpGppb0gObfI0cfbg0DnuKRfSs=.e398df44-4b64-465a-9697-8b4d2ed1652d@github.com>
 <50_1vC3yErplQgnnTNJHpF-d0ibuMKtRa9kg3jGKymc=.978abc22-8b04-49ed-b950-7bafe2b1931a@github.com>
Message-ID: <j2DFcOmsi0rUUIeWa6AIownoOKsIyflX1Y-ciwjIStU=.5bd6c122-1d18-437a-bfcb-b2381cdf426f@github.com>

On Wed, 28 Oct 2020 08:35:47 GMT, Peter Levart <plevart at openjdk.org> wrote:

>> Hi Peter,
>> 
>>> Question remains how do we distinguish proxies with old-fassioned InvocationHandlers from proxies with InvocationHandlers having access to super-default-handler. Both kinds of handlers look the same from Proxy's perspective... Perhaps we need a boolean flag in Proxy instance for that, coupled with an overloaded constructor that takes it...
>> 
>> I have the Proxy constructor taking both the invocation handler and `superHandler` in my [mlchung:proxy-default-method-4](https://github.com/mlchung/jdk/tree/proxy-default-method-4) branch.
>> 
>>> Problem with this approach is that it is not really useful in the proxy instance. We don't need it in the proxy instance. 
>> 
>> See above.
>> 
>> About the exception thrown: we need to distinguish CCE and NPE thrown by the default method vs thrown by arguments incompatible with the method signature.  In my proxy-default-method-4 branch, I define an internal exception type for that.  There is an overhead doing the wrapping but it's an exception case which performance should not be critical.
>
>> Hi Peter,
>> 
>> > Question remains how do we distinguish proxies with old-fassioned InvocationHandlers from proxies with InvocationHandlers having access to super-default-handler. Both kinds of handlers look the same from Proxy's perspective... Perhaps we need a boolean flag in Proxy instance for that, coupled with an overloaded constructor that takes it...
>> 
>> I have the Proxy constructor taking both the invocation handler and `superHandler` in my [mlchung:proxy-default-method-4](https://github.com/mlchung/jdk/tree/proxy-default-method-4) branch.
>> 
> 
> Yes, but it is not really useful there. The super handler is captured by the user invocation handler created in the invocation handler factory function and it is only used by the user invocation handler. All we need in the proxy instance is a boolean flag indicating the way the invocation handler was created (which one of the two overloaded newProxyInstance methods was called).
> 
>> > Problem with this approach is that it is not really useful in the proxy instance. We don't need it in the proxy instance.
>> 
>> See above.
>> 
>> About the exception thrown: we need to distinguish CCE and NPE thrown by the default method vs thrown by arguments incompatible with the method signature. In my proxy-default-method-4 branch, I define an internal exception type for that. There is an overhead doing the wrapping but it's an exception case which performance should not be critical.
> 
> To be precise, we need to pass CCE and NPE thrown by the default method unchanged, but we need to wrap CCE and NPE thrown by the method handle transformation chain with IllegalArgumentException. Is that what you are referring to? In that case we need an internal exception type, not exposed to public API, used just to "tunnel" the exception from the default method unchanged. That's just implementation detail.
> 
> But we have to ask ourselves a question: "Do we want to wrap CCE and NPE thrown by the method handle transformation chain with IllegalArgumentException?". We did that in previous variants to mimic the Method.invoke specification. But now we already departed from that specification by not wrapping exceptions thrown by the default method with InvocationTargetException. So we are not obligated to follow the rest of the Method.invoke specification either. All exception types thrown by method handle transformation chain (CCE, NPE, IAE) are unchecked exceptions and as such are not eligible to wrapping with UndeclaredThrowableException by the Proxy API. So it's just a matter of deciding what is more suitable: to have more specific exception types (CCE, NPE, IAE) for describing transformation exceptions or to reduce them to one common type (IAE). In either case those exception types can also be thrown by the default method and we can't or even want to distinguish their source. Let's be hon
 est, all of CCE, NPE, IAE are usually describing the subtle variants of the same thing: that the parameters are wrong. Whether this happens in the logic of invocation handler, method handle transformation chain or the default method, we want those exceptions to propagate out of the invoked proxy method unchanged.
> 
> So WDYT?

> Hi Peter,
> 
> About the exception thrown: ...

What I was referring to in my message before the last was about reflective access exeption thrown by Proxy.getInvocationHandler() when the handler has access to super invocation handler and the caller does not have access to proxy interfaces. What to do about that. Is UncheckedReflectiveOperationException a suitable solution? I'm not particularly fond of creating another Proxy.invocationHandler method, because it does not solve the problem of the old method that may also be called.

-------------

PR: https://git.openjdk.java.net/jdk/pull/313

From github.com+10835776+stsypanov at openjdk.java.net  Wed Oct 28 08:44:40 2020
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Wed, 28 Oct 2020 08:44:40 GMT
Subject: RFR: 8255299: Drop explicit zeroing at instantiation of Atomic*
 objects [v2]
In-Reply-To: <Bc1YybkJpxM06gYYRRaXsWlYOgf0iDwdw6MyPCiOUuY=.76053af0-dccd-4b14-8729-193daa70b091@github.com>
References: <Bc1YybkJpxM06gYYRRaXsWlYOgf0iDwdw6MyPCiOUuY=.76053af0-dccd-4b14-8729-193daa70b091@github.com>
Message-ID: <MTBEbVthFiMpd_eUkOsvckmhTQHZRu1DoYzEGXSnFuw=.ddea4ca1-57bd-4aab-8eb7-338c4057ec23@github.com>

> As discussed in https://github.com/openjdk/jdk/pull/510 there is never a reason to explicitly instantiate any instance of `Atomic*` class with its default value, i.e. `new AtomicInteger(0)` could be replaced with `new AtomicInteger()` which is faster:
> @State(Scope.Thread)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> @BenchmarkMode(value = Mode.AverageTime)
> public class AtomicBenchmark {
>   @Benchmark
>   public Object defaultValue() {
>     return new AtomicInteger();
>   }
>   @Benchmark
>   public Object explicitValue() {
>     return new AtomicInteger(0);
>   }
> }
> THis benchmark demonstrates that `explicitValue()` is much slower:
> Benchmark                      Mode  Cnt   Score   Error  Units
> AtomicBenchmark.defaultValue   avgt   30   4.778 ? 0.403  ns/op
> AtomicBenchmark.explicitValue  avgt   30  11.846 ? 0.273  ns/op
> So meanwhile https://bugs.openjdk.java.net/browse/JDK-8145948 is still in progress we could trivially replace explicit zeroing with default constructors gaining some performance benefit with no risk.
> 
> I've tested the changes locally, both tier1 and tier 2 are ok. 
> 
> Could one create an issue for tracking this?

?????? ??????? has updated the pull request with a new target base 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:

  8255299: Drop explicit zeroing at instantiation of Atomic* objects

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/818/files
  - new: https://git.openjdk.java.net/jdk/pull/818/files/c1fb362f..7dc646d0

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=818&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=818&range=00-01

  Stats: 4576 lines in 201 files changed: 2659 ins; 1135 del; 782 mod
  Patch: https://git.openjdk.java.net/jdk/pull/818.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/818/head:pull/818

PR: https://git.openjdk.java.net/jdk/pull/818

From github.com+10835776+stsypanov at openjdk.java.net  Wed Oct 28 08:44:41 2020
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Wed, 28 Oct 2020 08:44:41 GMT
Subject: RFR: 8255299: Drop explicit zeroing at instantiation of Atomic*
 objects [v2]
In-Reply-To: <eHVhVLFsHyakMwEZ-2ich-_YunMibTtXssoIObYxSGs=.6dee1d6d-d10f-412d-adbf-be23c84142a7@github.com>
References: <Bc1YybkJpxM06gYYRRaXsWlYOgf0iDwdw6MyPCiOUuY=.76053af0-dccd-4b14-8729-193daa70b091@github.com>
 <eHVhVLFsHyakMwEZ-2ich-_YunMibTtXssoIObYxSGs=.6dee1d6d-d10f-412d-adbf-be23c84142a7@github.com>
Message-ID: <kA7i2ZqE5aTruyHG4a-Wws0mSsiDFh9AvoqajJOfaXk=.9beead6e-8b73-458f-855c-3c9be39b68d2@github.com>

On Sat, 24 Oct 2020 23:12:09 GMT, Phil Race <prr 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 one additional commit since the last revision:
>> 
>>   8255299: Drop explicit zeroing at instantiation of Atomic* objects
>
> client changes are fine

Rebased onto master to have the fix introduced in https://github.com/openjdk/jdk/pull/778

-------------

PR: https://git.openjdk.java.net/jdk/pull/818

From serb at openjdk.java.net  Wed Oct 28 08:52:19 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 28 Oct 2020 08:52:19 GMT
Subject: RFR: 8255299: Drop explicit zeroing at instantiation of Atomic*
 objects [v2]
In-Reply-To: <kA7i2ZqE5aTruyHG4a-Wws0mSsiDFh9AvoqajJOfaXk=.9beead6e-8b73-458f-855c-3c9be39b68d2@github.com>
References: <Bc1YybkJpxM06gYYRRaXsWlYOgf0iDwdw6MyPCiOUuY=.76053af0-dccd-4b14-8729-193daa70b091@github.com>
 <eHVhVLFsHyakMwEZ-2ich-_YunMibTtXssoIObYxSGs=.6dee1d6d-d10f-412d-adbf-be23c84142a7@github.com>
 <kA7i2ZqE5aTruyHG4a-Wws0mSsiDFh9AvoqajJOfaXk=.9beead6e-8b73-458f-855c-3c9be39b68d2@github.com>
Message-ID: <Ybj5jF1E4frLMetmULomtH4i0opbzg-OX3m7eeShnfc=.c541d5a2-93ab-49b5-be84-fdcc73bcfe78@github.com>

On Wed, 28 Oct 2020 08:40:02 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

>> client changes are fine
>
> Rebased onto master to have the fix introduced in https://github.com/openjdk/jdk/pull/778

FYI it is better to use merge, instead of rebase+force push. Rebase breaks history and all existed code comments.

-------------

PR: https://git.openjdk.java.net/jdk/pull/818

From plevart at openjdk.java.net  Wed Oct 28 08:57:25 2020
From: plevart at openjdk.java.net (Peter Levart)
Date: Wed, 28 Oct 2020 08:57:25 GMT
Subject: RFR: 8188055: (ref) Add Reference::refersTo predicate [v6]
In-Reply-To: <a3JuXf0MtVHpL7iS2Af5dmzj9aPY6yGENU59L025sVY=.03691a63-b4bf-494f-9b0e-408459f844c3@github.com>
References: <D4HSg8FT20Eaxk5KJkkw0GgETSxRkBn1ipS3Dt0kPto=.e4bab078-2e04-4413-90cb-9bfafb2a6831@github.com>
 <Y1IHoNr8vO3OkCbEKw6ywXd4adik1yKKNIS4ABzF0d0=.d21f4183-ef4e-45ed-826d-6613215b6220@github.com>
 <9x0zaxknpYXGIvHun1CkLP0lEC8NQmPTnANxQKjhHF8=.907bdb15-2e2e-4f84-8fe4-ea4ed50534cd@github.com>
 <DR2YKv3VavKKD-cpFyf6mCSYfaKq0KAGh2XDqBStkys=.895ba671-f63a-4ba3-b042-6568d647b4ab@github.com>
 <mkn_t3hsL4mlCOfO5ahZOMbp8i_LMOHwJALA_bNjHIk=.d8031a91-ed13-4882-925f-ea8a9e634198@github.com>
 <3JzF7OkemZ-Lxc4jZgdEh3qNDzW8wF7ITeq-s7_TOlo=.11e4e40b-b775-47cf-9862-735fbc61ffd3@github.com>
 <iPK64Jh4aJtfqoPDqADOBN8BczKet53bod5y_VjZoBw=.fed662e8-2b40-478b-a9de-4906c0a897dc@github.com>
 <3kV3qhFRXBadf7Tol9n0Yomud_ndV_T_p7ShUfk4eVE=.d7151a63-0066-4020-b0ef-bae0d03dc133@github.com>
 <WhvzLc5GEYMSBz9jYgaRDBTbpaZGFWPHqzdfYHa-W6Q=.8efc48fe-6ae2-4608-ba4c-136df49c3707@github.com>
 <Rb6cPrJ-LEz3AupzI7Zp2pCC4tXfilcve_dxhRzBHps=.7dd76a96-035e-49ba-b3a3-df73f9a42e09@github.com>
 <a3JuXf0MtVHpL7iS2Af5dmzj9aPY6yGENU5
 9L025sVY=.03691a63-b4bf-494f-9b0e-408459f844c3@github.com>
Message-ID: <ADfAMn6ivK0gU0iOwNPv1qVAhxtd5SSwAFVA6s2D4Tw=.e8239549-74a9-4cf7-acf4-d7e5113b9fbe@github.com>

On Wed, 28 Oct 2020 03:46:55 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> Some thoughts regarding the parameter type of refersTo. Summary: I think `refersTo(T)` is fine and that we don't want to change it to `refersTo(Object)`.
> 
I agree that we don't have a migration problem here that collections had. So let it be `refersTo(T)` then.

-------------

PR: https://git.openjdk.java.net/jdk/pull/498

From github.com+10835776+stsypanov at openjdk.java.net  Wed Oct 28 08:59:23 2020
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Wed, 28 Oct 2020 08:59:23 GMT
Subject: RFR: 8255299: Drop explicit zeroing at instantiation of Atomic*
 objects [v2]
In-Reply-To: <Ybj5jF1E4frLMetmULomtH4i0opbzg-OX3m7eeShnfc=.c541d5a2-93ab-49b5-be84-fdcc73bcfe78@github.com>
References: <Bc1YybkJpxM06gYYRRaXsWlYOgf0iDwdw6MyPCiOUuY=.76053af0-dccd-4b14-8729-193daa70b091@github.com>
 <eHVhVLFsHyakMwEZ-2ich-_YunMibTtXssoIObYxSGs=.6dee1d6d-d10f-412d-adbf-be23c84142a7@github.com>
 <kA7i2ZqE5aTruyHG4a-Wws0mSsiDFh9AvoqajJOfaXk=.9beead6e-8b73-458f-855c-3c9be39b68d2@github.com>
 <Ybj5jF1E4frLMetmULomtH4i0opbzg-OX3m7eeShnfc=.c541d5a2-93ab-49b5-be84-fdcc73bcfe78@github.com>
Message-ID: <GPDSIE9rozDaZbs_94T4zgWxvK1adDtkHjlcP_m6_w4=.33980242-74dd-4993-98e1-c7bdd932d8be@github.com>

On Wed, 28 Oct 2020 08:49:38 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Rebased onto master to have the fix introduced in https://github.com/openjdk/jdk/pull/778
>
> FYI it is better to use merge, instead of rebase+force push. Rebase breaks history and all existed code comments.

@mrserb thanks for pointing this out!

-------------

PR: https://git.openjdk.java.net/jdk/pull/818

From shade at openjdk.java.net  Wed Oct 28 09:23:17 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 28 Oct 2020 09:23:17 GMT
Subject: RFR: 8255449: Improve the exception message of
 MethodHandles::permuteArguments
In-Reply-To: <9ibIdtPhdYSNXJfsy6uIzu4XV46dyZBqc498HIaOII4=.08a61fba-320b-430f-a8cf-9855e4db64de@github.com>
References: <9ibIdtPhdYSNXJfsy6uIzu4XV46dyZBqc498HIaOII4=.08a61fba-320b-430f-a8cf-9855e4db64de@github.com>
Message-ID: <QcsuHGnj-WUqAa6q8I1rPZ84JLUvyAbrTa2DayD9iZU=.883d98a0-a6cc-40ee-9468-c1226496ffae@github.com>

On Tue, 27 Oct 2020 12:43:47 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Hi,
> 
> Currently, if MethodHandles::permuteArguments is used with a reorder array that is the wrong size, or one of the indexes in it is out of bounds of the new type, we simply get the exception message:
> 
>     bad reorder array [...]
> 
> I think we can improve the exception message by splitting these two error cases, and saying in the message exactly what went wrong.
> 
> permuteArguments is a tricky API, so improving the error message here should help to improve developer productivity.
> 
> This PR proposes splits the error message into e.g.:
> 
>     old type parameter count and reorder array length do not match: (int,int,String)int, [0, 0]
> 
> For an incorrect reorder array length, and:
> 
>     index is out of bounds for new type: 2, (int,String)int
> 
> For an out of bounds index.
> 
> Thanks,
> Jorn

This looks okay to me. Someone from core-libs should take a look as well.

As the follow-up, maybe reconcile that method returns normally only with `true`, and throws exceptions otherwise. There are some uses like `assert(permuteArgumentChecks(...))` that apparently depend on this, how necessary are those?

-------------

PR: https://git.openjdk.java.net/jdk/pull/878

From aph at redhat.com  Wed Oct 28 09:41:45 2020
From: aph at redhat.com (Andrew Haley)
Date: Wed, 28 Oct 2020 09:41:45 +0000
Subject: RFR: 8255246: AArch64: Implement BigInteger shiftRight and
 shiftLeft accelerator/intrinsic [v2]
In-Reply-To: <JXvYCi7sShkgAfYuF0bqHjdytdL1ijeKXKpFK1x7NGs=.ac8ceca3-265f-4deb-9fbd-7b621fbd8c78@github.com>
References: <r6hSDpfXd-0pLBF7HqjeUtDzunl7nCUzbCQtqGP1_rw=.fe8d5cd1-2c1d-4d2d-ac6f-fc1d9ac3ebc2@github.com>
 <SXWanOunKxTIZhkADM5Pr6Udo6HGchzjPwfLAIWCmcs=.39401cf1-f3ec-4c91-b157-244f98a685aa@github.com>
 <Dr2DlSJvZ8l4hPJR3iYcPm2Q2Xpxfax-WkoKDV_L6Mg=.82e5d20a-6178-42dc-b545-33e3266c3055@github.com>
 <JXvYCi7sShkgAfYuF0bqHjdytdL1ijeKXKpFK1x7NGs=.ac8ceca3-265f-4deb-9fbd-7b621fbd8c78@github.com>
Message-ID: <31f48709-553d-32f8-6b7f-a834f347e801@redhat.com>

On 28/10/2020 03:30, Dong Bo wrote:
> My bad, it should be cbnz(numIter, ShiftOneLoop).
> But it's gone now, the ShiftOneLoop is unrolled in the newest version.
> Do you think we need further modifications?

No. As I said in my previous reply, the cost of actually shifting
is now only 5% of a benchmark. It doesn't matter.

-- 
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 shade at openjdk.java.net  Wed Oct 28 09:54:20 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 28 Oct 2020 09:54:20 GMT
Subject: RFR: 8253939: [TESTBUG] Increase coverage of the cgroups
 detection code [v3]
In-Reply-To: <5Jk_4mxRk_8rIaxUY9NhUNhOmjdIuRuV-KWzeSrLkaI=.07c9a141-6335-4e52-8aff-3fcbfce02a17@github.com>
References: <4G2YAmtWb3u1gyPsKK9lK5X06dKN93_zCqJvsZmjzxE=.1e754307-4dfa-417b-98e5-3af55a441145@github.com>
 <5Jk_4mxRk_8rIaxUY9NhUNhOmjdIuRuV-KWzeSrLkaI=.07c9a141-6335-4e52-8aff-3fcbfce02a17@github.com>
Message-ID: <QU1_IJDYcA8RGXcrzpVYBEwStwAe0l6OqE6AGFY2CJg=.d42e1ab4-6bb7-4641-8c21-daa251791b8b@github.com>

On Fri, 23 Oct 2020 15:51:47 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Test only change. With [JDK-8253435](https://bugs.openjdk.java.net/browse/JDK-8253435) a test has been added on the hotspot side, but nothing for the Java Metrics code. Same for [JDK-8252359](https://bugs.openjdk.java.net/browse/JDK-8252359).
>> 
>> When JDK-8217766 got fixed cgroup factories with the detection logic didn't exist so were harder to test. This patch adds tests for them too.
>> 
>> Thoughts?
>
> Severin Gehwolf 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.

This looks okay to me.

-------------

Marked as reviewed by shade (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/609

From dfuchs at openjdk.java.net  Wed Oct 28 09:55:19 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 28 Oct 2020 09:55:19 GMT
Subject: RFR: 8188055: (ref) Add Reference::refersTo predicate [v6]
In-Reply-To: <ADfAMn6ivK0gU0iOwNPv1qVAhxtd5SSwAFVA6s2D4Tw=.e8239549-74a9-4cf7-acf4-d7e5113b9fbe@github.com>
References: <D4HSg8FT20Eaxk5KJkkw0GgETSxRkBn1ipS3Dt0kPto=.e4bab078-2e04-4413-90cb-9bfafb2a6831@github.com>
 <Y1IHoNr8vO3OkCbEKw6ywXd4adik1yKKNIS4ABzF0d0=.d21f4183-ef4e-45ed-826d-6613215b6220@github.com>
 <9x0zaxknpYXGIvHun1CkLP0lEC8NQmPTnANxQKjhHF8=.907bdb15-2e2e-4f84-8fe4-ea4ed50534cd@github.com>
 <DR2YKv3VavKKD-cpFyf6mCSYfaKq0KAGh2XDqBStkys=.895ba671-f63a-4ba3-b042-6568d647b4ab@github.com>
 <mkn_t3hsL4mlCOfO5ahZOMbp8i_LMOHwJALA_bNjHIk=.d8031a91-ed13-4882-925f-ea8a9e634198@github.com>
 <3JzF7OkemZ-Lxc4jZgdEh3qNDzW8wF7ITeq-s7_TOlo=.11e4e40b-b775-47cf-9862-735fbc61ffd3@github.com>
 <iPK64Jh4aJtfqoPDqADOBN8BczKet53bod5y_VjZoBw=.fed662e8-2b40-478b-a9de-4906c0a897dc@github.com>
 <3kV3qhFRXBadf7Tol9n0Yomud_ndV_T_p7ShUfk4eVE=.d7151a63-0066-4020-b0ef-bae0d03dc133@github.com>
 <WhvzLc5GEYMSBz9jYgaRDBTbpaZGFWPHqzdfYHa-W6Q=.8efc48fe-6ae2-4608-ba4c-136df49c3707@github.com>
 <Rb6cPrJ-LEz3AupzI7Zp2pCC4tXfilcve_dxhRzBHps=.7dd76a96-035e-49ba-b3a3-df73f9a42e09@github.com>
 <a3JuXf0MtVHpL7iS2Af5dmzj9aPY6yGENU5
 9L025sVY=.03691a63-b4bf-494f-9b0e-408459f844c3@github.com>
 <ADfAMn6ivK0gU0iOwNPv1qVAhxtd5SSwAFVA6s2D4Tw=.e8239549-74a9-4cf7-acf4-d7e5113b9fbe@github.com>
Message-ID: <FDjnWXGfO7g3E8b-_f-UkeNBfm-zo9ZiW17PGtE4pqw=.335bc892-a322-407d-bfb4-940fcb5e54cf@github.com>

On Wed, 28 Oct 2020 08:54:31 GMT, Peter Levart <plevart at openjdk.org> wrote:

>> Some thoughts regarding the parameter type of refersTo. Summary: I think `refersTo(T)` is fine and that we don't want to change it to `refersTo(Object)`.
>> 
>> I don't think we have a migration issue similar to generifying collections, where there was a possibility of changing `contains(Object)` to `contains(E)`. If that had been done, it would have been a source compatibility issue, because changing the signature of the method potentially affects existing code that calls the method. That doesn't apply here because we're adding a new method.
>> 
>> The question now falls to whether it's preferable to have more convenience with `refersTo(Object)` or more type-safety with `refersTo(T)`. With the generic collections issue, the migration issue probably drove the decision to keep `contains(Object)`, but this has resulted in a continual set of complaints about the lack of an error when code passes an instance of the "wrong" type. I think that kind of error is likely to occur with `refersTo`. Since we don't have a source compatibility issue here, we can choose the safer API and avoid this kind of problem entirely.
>> 
>> The safer API does raise the possibility of having to add inconvenient unchecked casts and local variables in certain places, but I think Mandy's comment about the code already having a reference of the "right" type is correct. Her prototype webrev linked above shows that having to add unchecked casts is fairly infrequent.
>
>> Some thoughts regarding the parameter type of refersTo. Summary: I think `refersTo(T)` is fine and that we don't want to change it to `refersTo(Object)`.
>> 
> I agree that we don't have a migration problem here that collections had. So let it be `refersTo(T)` then.

I agree as well.

-------------

PR: https://git.openjdk.java.net/jdk/pull/498

From chegar at openjdk.java.net  Wed Oct 28 10:22:23 2020
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Wed, 28 Oct 2020 10:22:23 GMT
Subject: RFR: 8255449: Improve the exception message of
 MethodHandles::permuteArguments
In-Reply-To: <QcsuHGnj-WUqAa6q8I1rPZ84JLUvyAbrTa2DayD9iZU=.883d98a0-a6cc-40ee-9468-c1226496ffae@github.com>
References: <9ibIdtPhdYSNXJfsy6uIzu4XV46dyZBqc498HIaOII4=.08a61fba-320b-430f-a8cf-9855e4db64de@github.com>
 <QcsuHGnj-WUqAa6q8I1rPZ84JLUvyAbrTa2DayD9iZU=.883d98a0-a6cc-40ee-9468-c1226496ffae@github.com>
Message-ID: <2Tiy6BY0WPACz7O3kr7gA85b1OM6RD2yoMFs2ADne7g=.53daf7de-c7f1-473d-b921-e5e7b48bb989@github.com>

On Wed, 28 Oct 2020 09:20:54 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Hi,
>> 
>> Currently, if MethodHandles::permuteArguments is used with a reorder array that is the wrong size, or one of the indexes in it is out of bounds of the new type, we simply get the exception message:
>> 
>>     bad reorder array [...]
>> 
>> I think we can improve the exception message by splitting these two error cases, and saying in the message exactly what went wrong.
>> 
>> permuteArguments is a tricky API, so improving the error message here should help to improve developer productivity.
>> 
>> This PR proposes splits the error message into e.g.:
>> 
>>     old type parameter count and reorder array length do not match: (int,int,String)int, [0, 0]
>> 
>> For an incorrect reorder array length, and:
>> 
>>     index is out of bounds for new type: 2, (int,String)int
>> 
>> For an out of bounds index.
>> 
>> Thanks,
>> Jorn
>
> This looks okay to me. Someone from core-libs should take a look as well.
> 
> As the follow-up, maybe reconcile that method returns normally only with `true`, and throws exceptions otherwise. There are some uses like `assert(permuteArgumentChecks(...))` that apparently depend on this, how necessary are those?

Seems like a reasonable change. Is there an already existing test for "bad" permute args that could be expanded to discern the new exception message?

-------------

PR: https://git.openjdk.java.net/jdk/pull/878

From jvernee at openjdk.java.net  Wed Oct 28 11:54:45 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Wed, 28 Oct 2020 11:54:45 GMT
Subject: RFR: 8255449: Improve the exception message of
 MethodHandles::permuteArguments
In-Reply-To: <QcsuHGnj-WUqAa6q8I1rPZ84JLUvyAbrTa2DayD9iZU=.883d98a0-a6cc-40ee-9468-c1226496ffae@github.com>
References: <9ibIdtPhdYSNXJfsy6uIzu4XV46dyZBqc498HIaOII4=.08a61fba-320b-430f-a8cf-9855e4db64de@github.com>
 <QcsuHGnj-WUqAa6q8I1rPZ84JLUvyAbrTa2DayD9iZU=.883d98a0-a6cc-40ee-9468-c1226496ffae@github.com>
Message-ID: <9U65YSig1gq1hVDBsN57ks4lZh1J5LgW2CJpvdEBYwI=.22e29b40-849e-4bc4-b899-23827735d7c0@github.com>

On Wed, 28 Oct 2020 09:20:54 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> 
> 
> This looks okay to me. Someone from core-libs should take a look as well.
> 
> As the follow-up, maybe reconcile that method returns normally only with `true`, and throws exceptions otherwise. There are some uses like `assert(permuteArgumentChecks(...))` that apparently depend on this, how necessary are those?

It checks that the normalized reorder array is correct as well.

I'm a little reluctant to remove it right now though, since I just discovered a bug in that area: https://bugs.openjdk.java.net/browse/JDK-8255531 and it would be nice to have some extra safety nets when fixing that I think.

I agree it looks a little ugly, but let's leave it for now.

-------------

PR: https://git.openjdk.java.net/jdk/pull/878

From jvernee at openjdk.java.net  Wed Oct 28 11:54:46 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Wed, 28 Oct 2020 11:54:46 GMT
Subject: RFR: 8255449: Improve the exception message of
 MethodHandles::permuteArguments
In-Reply-To: <2Tiy6BY0WPACz7O3kr7gA85b1OM6RD2yoMFs2ADne7g=.53daf7de-c7f1-473d-b921-e5e7b48bb989@github.com>
References: <9ibIdtPhdYSNXJfsy6uIzu4XV46dyZBqc498HIaOII4=.08a61fba-320b-430f-a8cf-9855e4db64de@github.com>
 <QcsuHGnj-WUqAa6q8I1rPZ84JLUvyAbrTa2DayD9iZU=.883d98a0-a6cc-40ee-9468-c1226496ffae@github.com>
 <2Tiy6BY0WPACz7O3kr7gA85b1OM6RD2yoMFs2ADne7g=.53daf7de-c7f1-473d-b921-e5e7b48bb989@github.com>
Message-ID: <5TzkjFPwno1TTe98r2t6sObPt9LkuoH2HJpUQZCn_mY=.53040332-01a8-4e0d-b622-13c2b5a31228@github.com>

On Wed, 28 Oct 2020 10:19:58 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

> 
> 
> Seems like a reasonable change. Is there an already existing test for "bad" permute args that could be expanded to discern the new exception message?

There are several tests for permuteArguments, but none that explicitly test this failure. I'll add some (good idea).

-------------

PR: https://git.openjdk.java.net/jdk/pull/878

From dongbo at openjdk.java.net  Wed Oct 28 11:54:46 2020
From: dongbo at openjdk.java.net (Dong Bo)
Date: Wed, 28 Oct 2020 11:54:46 GMT
Subject: RFR: 8255246: AArch64: Implement BigInteger shiftRight and
 shiftLeft accelerator/intrinsic [v2]
In-Reply-To: <Dr2DlSJvZ8l4hPJR3iYcPm2Q2Xpxfax-WkoKDV_L6Mg=.82e5d20a-6178-42dc-b545-33e3266c3055@github.com>
References: <r6hSDpfXd-0pLBF7HqjeUtDzunl7nCUzbCQtqGP1_rw=.fe8d5cd1-2c1d-4d2d-ac6f-fc1d9ac3ebc2@github.com>
 <SXWanOunKxTIZhkADM5Pr6Udo6HGchzjPwfLAIWCmcs=.39401cf1-f3ec-4c91-b157-244f98a685aa@github.com>
 <Dr2DlSJvZ8l4hPJR3iYcPm2Q2Xpxfax-WkoKDV_L6Mg=.82e5d20a-6178-42dc-b545-33e3266c3055@github.com>
Message-ID: <q4UtgnbyvOWFKC62NtHrTsXA1q35CLwJHwn0gdypXLg=.1fa29a17-7110-411d-9fa8-c7ba2d8bffee@github.com>

On Tue, 27 Oct 2020 16:45:42 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Dong Bo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   minor improvements for small BigIntegers
>
> Marked as reviewed by aph (Reviewer).

@theRealAph Thanks for the review.

@RealFYang Could you please sponsor this? Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/861

From dongbo at openjdk.java.net  Wed Oct 28 11:54:47 2020
From: dongbo at openjdk.java.net (Dong Bo)
Date: Wed, 28 Oct 2020 11:54:47 GMT
Subject: Integrated: 8255246: AArch64: Implement BigInteger shiftRight and
 shiftLeft accelerator/intrinsic
In-Reply-To: <r6hSDpfXd-0pLBF7HqjeUtDzunl7nCUzbCQtqGP1_rw=.fe8d5cd1-2c1d-4d2d-ac6f-fc1d9ac3ebc2@github.com>
References: <r6hSDpfXd-0pLBF7HqjeUtDzunl7nCUzbCQtqGP1_rw=.fe8d5cd1-2c1d-4d2d-ac6f-fc1d9ac3ebc2@github.com>
Message-ID: <vjGGvU1YVYkVjBzBK5-HSQDLX6KxDPqH0SrPTAjh6DQ=.e550e00c-3642-4dd6-aa58-4822ff933ff5@github.com>

On Mon, 26 Oct 2020 09:19:45 GMT, Dong Bo <dongbo at openjdk.org> wrote:

> BigInteger.shiftRightImplWorker and BigInteger.shiftLeftImplWorker are not intrinsified on aarch64, which have been done on x86_64.
> We can implement them via USHL NEON instruction (register), which handles four integers one time at most, against just integer C2 asm-code processed.
> The usage of USHL can be found at: https://developer.arm.com/documentation/dui0801/g/A64-SIMD-Vector-Instructions/USHL--vector-?lang=en
> 
> Patch passed jtreg tier1-3 tests on our aarch64 server.
> Tests in test/jdk/java/math/BigInteger/* runned specially for the correctness of the implementation and passed.
> 
> We tested test/micro/org/openjdk/bench/java/math/BigIntegers.java for performance gain on Kunpeng916 and Kunpeng920.
> The following performance improvements were seen with this implementation:
> - Intrinsification of BigInteger.shiftLeft: 25.52% (Kunpeng916), 37.56% (Kunpeng920)
> - Intrinsification of BigInteger.shiftRight: 46.45% (Kunpeng916), 43.32% (Kunpeng920)
> 
> The BigIntegers.java JMH micro-benchmark results:
> Benchmark                      Mode  Cnt     Score    Error  Units
> 
> # Kunpeng 916, default
> BigIntegers.testAdd            avgt   25    33.554 ?  0.224  ns/op
> BigIntegers.testHugeToString   avgt   25   575.554 ? 40.656  ns/op
> BigIntegers.testLargeToString  avgt   25   190.098 ?  0.825  ns/op
> **BigIntegers.testLeftShift      avgt   25  1495.779 ? 12.365  ns/op**
> BigIntegers.testMultiply       avgt   25  7551.707 ? 39.309  ns/op
> **BigIntegers.testRightShift     avgt   25   605.302 ?  6.710  ns/op**
> BigIntegers.testSmallToString  avgt   25   179.034 ?  0.873  ns/op
> 
> # Kunpeng 916, intrinsic:
> BigIntegers.testAdd            avgt   25    33.531 ?  0.222  ns/op
> BigIntegers.testHugeToString   avgt   25   578.038 ? 40.675  ns/op
> BigIntegers.testLargeToString  avgt   25   188.566 ?  0.855  ns/op
> **BigIntegers.testLeftShift      avgt   25  1191.651 ? 20.136  ns/op**
> BigIntegers.testMultiply       avgt   25  7492.711 ?  3.702  ns/op
> **BigIntegers.testRightShift     avgt   25   326.891 ?  6.033  ns/op**
> BigIntegers.testSmallToString  avgt   25   178.267 ?  1.501  ns/op
> 
> # Kunpeng 920, default
> BigIntegers.testAdd            avgt   25    22.790 ?  0.167  ns/op
> BigIntegers.testHugeToString   avgt   25   432.428 ? 10.736  ns/op
> BigIntegers.testLargeToString  avgt   25   121.899 ?  3.356  ns/op
> **BigIntegers.testLeftShift      avgt   25   883.530 ? 53.714  ns/op**
> BigIntegers.testMultiply       avgt   25  5918.845 ? 94.937  ns/op
> **BigIntegers.testRightShift     avgt   25   329.762 ? 15.850  ns/op**
> BigIntegers.testSmallToString  avgt   25   117.460 ?  3.040  ns/op
> 
> # Kunpeng 920, intrinsic
> BigIntegers.testAdd            avgt   25    21.791 ?  0.085  ns/op
> BigIntegers.testHugeToString   avgt   25   415.209 ? 32.170  ns/op
> BigIntegers.testLargeToString  avgt   25   124.635 ?  2.157  ns/op
> **BigIntegers.testLeftShift      avgt   25   551.710 ?  7.836  ns/op**
> BigIntegers.testMultiply       avgt   25  5869.401 ? 54.803  ns/op
> **BigIntegers.testRightShift     avgt   25   186.896 ?  6.378  ns/op**
> BigIntegers.testSmallToString  avgt   25   117.543 ?  3.036  ns/op

This pull request has now been integrated.

Changeset: 6b2d11ba
Author:    Dong Bo <dongbo at openjdk.org>
Committer: Fei Yang <fyang at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/6b2d11ba
Stats:     275 lines in 3 files changed: 273 ins; 0 del; 2 mod

8255246: AArch64: Implement BigInteger shiftRight and shiftLeft accelerator/intrinsic

Reviewed-by: aph

-------------

PR: https://git.openjdk.java.net/jdk/pull/861

From michael.edgar at gmail.com  Wed Oct 28 12:14:50 2020
From: michael.edgar at gmail.com (Michael Edgar)
Date: Wed, 28 Oct 2020 08:14:50 -0400
Subject: Filtered XMLStreamReader Exceptions (java.xml)
Message-ID: <CAJ9fJk4dF8H1M23xv6L2cacB8epxg1WOsPsX7sRZ=MrAS23aXw@mail.gmail.com>

Hi everyone,
I'm working on a project that makes use of the StAX API and an issue I have
encountered is that when wrapping an `XMLStreamReader` with a
`StreamFilter`, errors encountered in the setup are not thrown to the
caller. The source of the error could be any stream error that is triggered
as the `XMLStreamFilterImpl` advances to the next acceptable event.
Ultimately, when attempting to utilize the filtered reader, some secondary
exception will occur, but the original `Exception` is lost.

I have not seen any other issues related specifically to this problem, so I
would like to propose removal of the try/catch in the constructor of
`com.sun.org.apache.xerces.internal.impl.XMLStreamFilterImpl` and the
method signature changed to declare that `XMLStreamException` is thrown.
The constructor is used by
`com.sun.xml.internal.stream.XMLInputFactoryImpl.createFilteredReader(XMLStreamReader,
StreamFilter)` which itself already declares the same exception and is an
implementation of the public `XMLInputFactory` interface.

Further, the `nextTag` method of the same class has a bug where it checks
for `START_ELEMENT` events twice.

I have an OCA in place and I am happy to submit a PR, but I believe that a
bug record needs to be opened in order to proceed.

Thank you,
Mike

From github.com+10835776+stsypanov at openjdk.java.net  Wed Oct 28 12:14:48 2020
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Wed, 28 Oct 2020 12:14:48 GMT
Subject: Integrated: 8255299: Drop explicit zeroing at instantiation of
 Atomic* objects
In-Reply-To: <Bc1YybkJpxM06gYYRRaXsWlYOgf0iDwdw6MyPCiOUuY=.76053af0-dccd-4b14-8729-193daa70b091@github.com>
References: <Bc1YybkJpxM06gYYRRaXsWlYOgf0iDwdw6MyPCiOUuY=.76053af0-dccd-4b14-8729-193daa70b091@github.com>
Message-ID: <s9QN2M6WRG0kn77XHHkuyPHKav_igWzLtf7eJFU6GLQ=.5e596801-b62d-4e14-b969-e82096e9ab18@github.com>

On Thu, 22 Oct 2020 20:46:15 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

> As discussed in https://github.com/openjdk/jdk/pull/510 there is never a reason to explicitly instantiate any instance of `Atomic*` class with its default value, i.e. `new AtomicInteger(0)` could be replaced with `new AtomicInteger()` which is faster:
> @State(Scope.Thread)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> @BenchmarkMode(value = Mode.AverageTime)
> public class AtomicBenchmark {
>   @Benchmark
>   public Object defaultValue() {
>     return new AtomicInteger();
>   }
>   @Benchmark
>   public Object explicitValue() {
>     return new AtomicInteger(0);
>   }
> }
> THis benchmark demonstrates that `explicitValue()` is much slower:
> Benchmark                      Mode  Cnt   Score   Error  Units
> AtomicBenchmark.defaultValue   avgt   30   4.778 ? 0.403  ns/op
> AtomicBenchmark.explicitValue  avgt   30  11.846 ? 0.273  ns/op
> So meanwhile https://bugs.openjdk.java.net/browse/JDK-8145948 is still in progress we could trivially replace explicit zeroing with default constructors gaining some performance benefit with no risk.
> 
> I've tested the changes locally, both tier1 and tier 2 are ok. 
> 
> Could one create an issue for tracking this?

This pull request has now been integrated.

Changeset: 3c4fc793
Author:    Sergey Tsypanov <sergei.tsypanov at yandex.ru>
Committer: Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/3c4fc793
Stats:     19 lines in 17 files changed: 0 ins; 3 del; 16 mod

8255299: Drop explicit zeroing at instantiation of Atomic* objects

Reviewed-by: redestad, serb, prr

-------------

PR: https://git.openjdk.java.net/jdk/pull/818

From dfuchs at openjdk.java.net  Wed Oct 28 12:14:47 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 28 Oct 2020 12:14:47 GMT
Subject: RFR: 8255299: Drop explicit zeroing at instantiation of Atomic*
 objects [v2]
In-Reply-To: <GPDSIE9rozDaZbs_94T4zgWxvK1adDtkHjlcP_m6_w4=.33980242-74dd-4993-98e1-c7bdd932d8be@github.com>
References: <Bc1YybkJpxM06gYYRRaXsWlYOgf0iDwdw6MyPCiOUuY=.76053af0-dccd-4b14-8729-193daa70b091@github.com>
 <eHVhVLFsHyakMwEZ-2ich-_YunMibTtXssoIObYxSGs=.6dee1d6d-d10f-412d-adbf-be23c84142a7@github.com>
 <kA7i2ZqE5aTruyHG4a-Wws0mSsiDFh9AvoqajJOfaXk=.9beead6e-8b73-458f-855c-3c9be39b68d2@github.com>
 <Ybj5jF1E4frLMetmULomtH4i0opbzg-OX3m7eeShnfc=.c541d5a2-93ab-49b5-be84-fdcc73bcfe78@github.com>
 <GPDSIE9rozDaZbs_94T4zgWxvK1adDtkHjlcP_m6_w4=.33980242-74dd-4993-98e1-c7bdd932d8be@github.com>
Message-ID: <T0ZlHNLTHD35aWgX_xJfvtvz0V7wJ4uaP6WZXdccnmw=.4bb65e37-dd73-44f7-81bb-49d51dc9e14c@github.com>

On Wed, 28 Oct 2020 08:56:05 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

>> FYI it is better to use merge, instead of rebase+force push. Rebase breaks history and all existed code comments.
>
> @mrserb thanks for pointing this out!

Thanks for updating with latest master changes Sergey! My tests were all green.

-------------

PR: https://git.openjdk.java.net/jdk/pull/818

From jvernee at openjdk.java.net  Wed Oct 28 13:36:57 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Wed, 28 Oct 2020 13:36:57 GMT
Subject: RFR: 8255449: Improve the exception message of
 MethodHandles::permuteArguments [v2]
In-Reply-To: <9ibIdtPhdYSNXJfsy6uIzu4XV46dyZBqc498HIaOII4=.08a61fba-320b-430f-a8cf-9855e4db64de@github.com>
References: <9ibIdtPhdYSNXJfsy6uIzu4XV46dyZBqc498HIaOII4=.08a61fba-320b-430f-a8cf-9855e4db64de@github.com>
Message-ID: <X-1hHSz2a0Xi-BIAdtc2queGStNNr6nspOW67gOPQ2w=.352f992e-7b65-40bc-acf3-aa53a88de2df@github.com>

> Hi,
> 
> Currently, if MethodHandles::permuteArguments is used with a reorder array that is the wrong size, or one of the indexes in it is out of bounds of the new type, we simply get the exception message:
> 
>     bad reorder array [...]
> 
> I think we can improve the exception message by splitting these two error cases, and saying in the message exactly what went wrong.
> 
> permuteArguments is a tricky API, so improving the error message here should help to improve developer productivity.
> 
> This PR proposes splits the error message into e.g.:
> 
>     old type parameter count and reorder array length do not match: (int,int,String)int, [0, 0]
> 
> For an incorrect reorder array length, and:
> 
>     index is out of bounds for new type: 2, (int,String)int
> 
> For an out of bounds index.
> 
> Thanks,
> Jorn

Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

  Add some negative permuteArguments tests

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/878/files
  - new: https://git.openjdk.java.net/jdk/pull/878/files/42cf6b6c..2dbb4e57

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=878&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=878&range=00-01

  Stats: 58 lines in 1 file changed: 57 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/878.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/878/head:pull/878

PR: https://git.openjdk.java.net/jdk/pull/878

From jvernee at openjdk.java.net  Wed Oct 28 13:36:57 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Wed, 28 Oct 2020 13:36:57 GMT
Subject: RFR: 8255449: Improve the exception message of
 MethodHandles::permuteArguments [v2]
In-Reply-To: <5TzkjFPwno1TTe98r2t6sObPt9LkuoH2HJpUQZCn_mY=.53040332-01a8-4e0d-b622-13c2b5a31228@github.com>
References: <9ibIdtPhdYSNXJfsy6uIzu4XV46dyZBqc498HIaOII4=.08a61fba-320b-430f-a8cf-9855e4db64de@github.com>
 <QcsuHGnj-WUqAa6q8I1rPZ84JLUvyAbrTa2DayD9iZU=.883d98a0-a6cc-40ee-9468-c1226496ffae@github.com>
 <2Tiy6BY0WPACz7O3kr7gA85b1OM6RD2yoMFs2ADne7g=.53daf7de-c7f1-473d-b921-e5e7b48bb989@github.com>
 <5TzkjFPwno1TTe98r2t6sObPt9LkuoH2HJpUQZCn_mY=.53040332-01a8-4e0d-b622-13c2b5a31228@github.com>
Message-ID: <33oe19yjMeVfJwBTPBk01tm_FYWByQUGMNsv0y_0B5I=.d4689b06-b9b0-47db-bd42-9b57301daa43@github.com>

On Wed, 28 Oct 2020 11:52:17 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Seems like a reasonable change. Is there an already existing test for "bad" permute args that could be expanded to discern the new exception message?
>
>> 
>> 
>> Seems like a reasonable change. Is there an already existing test for "bad" permute args that could be expanded to discern the new exception message?
> 
> There are several tests for permuteArguments, but none that explicitly test this failure. I'll add some (good idea).

I've added some negative tests that test for the different failure conditions.

-------------

PR: https://git.openjdk.java.net/jdk/pull/878

From sgehwolf at openjdk.java.net  Wed Oct 28 13:49:53 2020
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Wed, 28 Oct 2020 13:49:53 GMT
Subject: RFR: 8253939: [TESTBUG] Increase coverage of the cgroups
 detection code [v4]
In-Reply-To: <4G2YAmtWb3u1gyPsKK9lK5X06dKN93_zCqJvsZmjzxE=.1e754307-4dfa-417b-98e5-3af55a441145@github.com>
References: <4G2YAmtWb3u1gyPsKK9lK5X06dKN93_zCqJvsZmjzxE=.1e754307-4dfa-417b-98e5-3af55a441145@github.com>
Message-ID: <xsQuHOCEl_38GAItRQYfzCUvXSDtLUgJOmwnSWrchxw=.ea3efa65-a968-4a03-a237-03779cbac4d2@github.com>

> Test only change. With [JDK-8253435](https://bugs.openjdk.java.net/browse/JDK-8253435) a test has been added on the hotspot side, but nothing for the Java Metrics code. Same for [JDK-8252359](https://bugs.openjdk.java.net/browse/JDK-8252359).
> 
> When JDK-8217766 got fixed cgroup factories with the detection logic didn't exist so were harder to test. This patch adds tests for them too.
> 
> Thoughts?

Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:

  8253939: [TESTBUG] Increase coverage of the cgroups detection code

-------------

Changes: https://git.openjdk.java.net/jdk/pull/609/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=609&range=03
  Stats: 147 lines in 2 files changed: 134 ins; 0 del; 13 mod
  Patch: https://git.openjdk.java.net/jdk/pull/609.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/609/head:pull/609

PR: https://git.openjdk.java.net/jdk/pull/609

From chegar at openjdk.java.net  Wed Oct 28 14:32:47 2020
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Wed, 28 Oct 2020 14:32:47 GMT
Subject: RFR: 8255449: Improve the exception message of
 MethodHandles::permuteArguments [v2]
In-Reply-To: <33oe19yjMeVfJwBTPBk01tm_FYWByQUGMNsv0y_0B5I=.d4689b06-b9b0-47db-bd42-9b57301daa43@github.com>
References: <9ibIdtPhdYSNXJfsy6uIzu4XV46dyZBqc498HIaOII4=.08a61fba-320b-430f-a8cf-9855e4db64de@github.com>
 <QcsuHGnj-WUqAa6q8I1rPZ84JLUvyAbrTa2DayD9iZU=.883d98a0-a6cc-40ee-9468-c1226496ffae@github.com>
 <2Tiy6BY0WPACz7O3kr7gA85b1OM6RD2yoMFs2ADne7g=.53daf7de-c7f1-473d-b921-e5e7b48bb989@github.com>
 <5TzkjFPwno1TTe98r2t6sObPt9LkuoH2HJpUQZCn_mY=.53040332-01a8-4e0d-b622-13c2b5a31228@github.com>
 <33oe19yjMeVfJwBTPBk01tm_FYWByQUGMNsv0y_0B5I=.d4689b06-b9b0-47db-bd42-9b57301daa43@github.com>
Message-ID: <mUuJxCRYwUrl7VlriEFvspyzn4QifJi30uzUfs32txo=.ec883692-3f91-404e-9203-a5ac7e3cffd6@github.com>

On Wed, 28 Oct 2020 13:32:19 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>>> 
>>> 
>>> Seems like a reasonable change. Is there an already existing test for "bad" permute args that could be expanded to discern the new exception message?
>> 
>> There are several tests for permuteArguments, but none that explicitly test this failure. I'll add some (good idea).
>
> I've added some negative tests that test for the different failure conditions.

Thanks for adding additional test coverage @JornVernee.

Writing a tight implementation of assertThrows is non-trivial - I'm not sure that the version you have will fail if the exception is not thrown?  Either way maybe we can reuse some of the junit machinery for this purpose, e.g.:

static final Class<IllegalArgumentException> IAE = IllegalArgumentException.class;

public void testReorderTypeMismatch() throws Throwable {
    MethodHandle mh = MethodHandles.empty(MethodType.methodType(void.class, int.class, int.class, String.class));
    MethodType newType = MethodType.methodType(void.class, double.class, String.class);
    var exception = expectThrows(IAE, () -> MethodHandles.permuteArguments(mh, newType, 0, 0, 1));
    assertMatches(exception.getMessage(), ".*parameter types do not match after reorder.*");
}

private static void assertMatches(String str, String pattern) {
    if (!str.matches(pattern)) {
        throw new AssertionError("'" + str + "' did not match the pattern '" + pattern + "'.");
    }
}

-------------

PR: https://git.openjdk.java.net/jdk/pull/878

From jvernee at openjdk.java.net  Wed Oct 28 15:00:59 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Wed, 28 Oct 2020 15:00:59 GMT
Subject: RFR: 8255449: Improve the exception message of
 MethodHandles::permuteArguments [v3]
In-Reply-To: <9ibIdtPhdYSNXJfsy6uIzu4XV46dyZBqc498HIaOII4=.08a61fba-320b-430f-a8cf-9855e4db64de@github.com>
References: <9ibIdtPhdYSNXJfsy6uIzu4XV46dyZBqc498HIaOII4=.08a61fba-320b-430f-a8cf-9855e4db64de@github.com>
Message-ID: <EpOOHLlIEc-mWtIYy22QjUrG61do-jyJ2bzhQyj7g5s=.6ff3c7ea-12bb-4fff-8685-326e0e59bd00@github.com>

> Hi,
> 
> Currently, if MethodHandles::permuteArguments is used with a reorder array that is the wrong size, or one of the indexes in it is out of bounds of the new type, we simply get the exception message:
> 
>     bad reorder array [...]
> 
> I think we can improve the exception message by splitting these two error cases, and saying in the message exactly what went wrong.
> 
> permuteArguments is a tricky API, so improving the error message here should help to improve developer productivity.
> 
> This PR proposes splits the error message into e.g.:
> 
>     old type parameter count and reorder array length do not match: (int,int,String)int, [0, 0]
> 
> For an incorrect reorder array length, and:
> 
>     index is out of bounds for new type: 2, (int,String)int
> 
> For an out of bounds index.
> 
> Thanks,
> Jorn

Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

  Fail when exception is not thrown in assertThrows

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/878/files
  - new: https://git.openjdk.java.net/jdk/pull/878/files/2dbb4e57..34050c3e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=878&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=878&range=01-02

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/878.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/878/head:pull/878

PR: https://git.openjdk.java.net/jdk/pull/878

From chegar at openjdk.java.net  Wed Oct 28 15:01:00 2020
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Wed, 28 Oct 2020 15:01:00 GMT
Subject: RFR: 8255449: Improve the exception message of
 MethodHandles::permuteArguments [v3]
In-Reply-To: <EpOOHLlIEc-mWtIYy22QjUrG61do-jyJ2bzhQyj7g5s=.6ff3c7ea-12bb-4fff-8685-326e0e59bd00@github.com>
References: <9ibIdtPhdYSNXJfsy6uIzu4XV46dyZBqc498HIaOII4=.08a61fba-320b-430f-a8cf-9855e4db64de@github.com>
 <EpOOHLlIEc-mWtIYy22QjUrG61do-jyJ2bzhQyj7g5s=.6ff3c7ea-12bb-4fff-8685-326e0e59bd00@github.com>
Message-ID: <4Zv8s_yJVm2ySbnXi1jyE1kPHNCU3xFeuhrP8bORIcc=.fbf6893c-58b2-4bf3-ae44-816be93b594b@github.com>

On Wed, 28 Oct 2020 14:57:44 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Hi,
>> 
>> Currently, if MethodHandles::permuteArguments is used with a reorder array that is the wrong size, or one of the indexes in it is out of bounds of the new type, we simply get the exception message:
>> 
>>     bad reorder array [...]
>> 
>> I think we can improve the exception message by splitting these two error cases, and saying in the message exactly what went wrong.
>> 
>> permuteArguments is a tricky API, so improving the error message here should help to improve developer productivity.
>> 
>> This PR proposes splits the error message into e.g.:
>> 
>>     old type parameter count and reorder array length do not match: (int,int,String)int, [0, 0]
>> 
>> For an incorrect reorder array length, and:
>> 
>>     index is out of bounds for new type: 2, (int,String)int
>> 
>> For an out of bounds index.
>> 
>> Thanks,
>> Jorn
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fail when exception is not thrown in assertThrows

Marked as reviewed by chegar (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/878

From chegar at openjdk.java.net  Wed Oct 28 15:01:00 2020
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Wed, 28 Oct 2020 15:01:00 GMT
Subject: RFR: 8255449: Improve the exception message of
 MethodHandles::permuteArguments [v3]
In-Reply-To: <mUuJxCRYwUrl7VlriEFvspyzn4QifJi30uzUfs32txo=.ec883692-3f91-404e-9203-a5ac7e3cffd6@github.com>
References: <9ibIdtPhdYSNXJfsy6uIzu4XV46dyZBqc498HIaOII4=.08a61fba-320b-430f-a8cf-9855e4db64de@github.com>
 <QcsuHGnj-WUqAa6q8I1rPZ84JLUvyAbrTa2DayD9iZU=.883d98a0-a6cc-40ee-9468-c1226496ffae@github.com>
 <2Tiy6BY0WPACz7O3kr7gA85b1OM6RD2yoMFs2ADne7g=.53daf7de-c7f1-473d-b921-e5e7b48bb989@github.com>
 <5TzkjFPwno1TTe98r2t6sObPt9LkuoH2HJpUQZCn_mY=.53040332-01a8-4e0d-b622-13c2b5a31228@github.com>
 <33oe19yjMeVfJwBTPBk01tm_FYWByQUGMNsv0y_0B5I=.d4689b06-b9b0-47db-bd42-9b57301daa43@github.com>
 <mUuJxCRYwUrl7VlriEFvspyzn4QifJi30uzUfs32txo=.ec883692-3f91-404e-9203-a5ac7e3cffd6@github.com>
Message-ID: <Z1sRcgx13RfOXeoh8cZkGlN9KPNDB0V-MGzhayabl0E=.3242d53b-c662-485b-ae53-a11cdaafe100@github.com>

On Wed, 28 Oct 2020 14:30:30 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

>> I've added some negative tests that test for the different failure conditions.
>
> Thanks for adding additional test coverage @JornVernee.
> 
> Writing a tight implementation of assertThrows is non-trivial - I'm not sure that the version you have will fail if the exception is not thrown?  Either way maybe we can reuse some of the junit machinery for this purpose, e.g.:
> 
> static final Class<IllegalArgumentException> IAE = IllegalArgumentException.class;
> 
> public void testReorderTypeMismatch() throws Throwable {
>     MethodHandle mh = MethodHandles.empty(MethodType.methodType(void.class, int.class, int.class, String.class));
>     MethodType newType = MethodType.methodType(void.class, double.class, String.class);
>     var exception = expectThrows(IAE, () -> MethodHandles.permuteArguments(mh, newType, 0, 0, 1));
>     assertMatches(exception.getMessage(), ".*parameter types do not match after reorder.*");
> }
> 
> private static void assertMatches(String str, String pattern) {
>     if (!str.matches(pattern)) {
>         throw new AssertionError("'" + str + "' did not match the pattern '" + pattern + "'.");
>     }
> }

My last comment, that suggested to use expectThrows was not appropriate for this junit test ( I mistakenly assumed that that functional was available, but it is not ) - withdrawn.

Thanks for adding the extra check in assertThrows. LGTM.

-------------

PR: https://git.openjdk.java.net/jdk/pull/878

From bobv at openjdk.java.net  Wed Oct 28 15:45:52 2020
From: bobv at openjdk.java.net (Bob Vandette)
Date: Wed, 28 Oct 2020 15:45:52 GMT
Subject: RFR: 8253939: [TESTBUG] Increase coverage of the cgroups
 detection code [v4]
In-Reply-To: <xsQuHOCEl_38GAItRQYfzCUvXSDtLUgJOmwnSWrchxw=.ea3efa65-a968-4a03-a237-03779cbac4d2@github.com>
References: <4G2YAmtWb3u1gyPsKK9lK5X06dKN93_zCqJvsZmjzxE=.1e754307-4dfa-417b-98e5-3af55a441145@github.com>
 <xsQuHOCEl_38GAItRQYfzCUvXSDtLUgJOmwnSWrchxw=.ea3efa65-a968-4a03-a237-03779cbac4d2@github.com>
Message-ID: <euybZbkMvw89SZ3uPCXjdedj6wKoZ5ezav-6tDFIzUo=.ad92fba3-4ae9-4bfa-8cd1-8d19c85e3a56@github.com>

On Wed, 28 Oct 2020 13:49:53 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Test only change. With [JDK-8253435](https://bugs.openjdk.java.net/browse/JDK-8253435) a test has been added on the hotspot side, but nothing for the Java Metrics code. Same for [JDK-8252359](https://bugs.openjdk.java.net/browse/JDK-8252359).
>> 
>> When JDK-8217766 got fixed cgroup factories with the detection logic didn't exist so were harder to test. This patch adds tests for them too.
>> 
>> Thoughts?
>
> Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains one additional commit since the last revision:
> 
>   8253939: [TESTBUG] Increase coverage of the cgroups detection code

Looks good.

-------------

Marked as reviewed by bobv (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/609

From alanb at openjdk.java.net  Wed Oct 28 15:59:54 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 28 Oct 2020 15:59:54 GMT
Subject: RFR: 8188055: (ref) Add Reference::refersTo predicate [v6]
In-Reply-To: <0dhF_xxcp1VoUowwdZenB2qWa9ILcZjTMe3lsaRrg7k=.3c633db8-f745-4353-ad34-a64fbc96d4e0@github.com>
References: <D4HSg8FT20Eaxk5KJkkw0GgETSxRkBn1ipS3Dt0kPto=.e4bab078-2e04-4413-90cb-9bfafb2a6831@github.com>
 <0dhF_xxcp1VoUowwdZenB2qWa9ILcZjTMe3lsaRrg7k=.3c633db8-f745-4353-ad34-a64fbc96d4e0@github.com>
Message-ID: <JQqMtimYvcfwvNPp7O6OP6F7Jib8794qnGbWpfps4Qo=.d9694144-b5c2-467a-8afd-e31a65aec7a0@github.com>

On Wed, 21 Oct 2020 02:28:30 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Finally returning to this review that was started in April 2020.  I've
>> recast it as a github PR.  I think the security concern raised by Gil
>> has been adequately answered.
>> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-April/029203.html
>> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-July/030401.html
>> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-August/030677.html
>> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-September/030793.html
>> 
>> Please review a new function: java.lang.ref.Reference.refersTo.
>> 
>> This function is needed to test the referent of a Reference object without
>> artificially extending the lifetime of the referent object, as may happen
>> when calling Reference.get.  Some garbage collectors require extending the
>> lifetime of a weak referent when accessed, in order to maintain collector
>> invariants.  Lifetime extension may occur with any collector when the
>> Reference is a SoftReference, as calling get indicates recent access.  This
>> new function also allows testing the referent of a PhantomReference, which
>> can't be accessed by calling get.
>> 
>> The new function uses native methods whose implementations are in the VM so
>> they can use the Access API.  It is the intent that these methods will be
>> intrinsified by optimizing compilers like C2 or graal, but that hasn't been
>> implemented yet.  Bear that in mind before rushing off to change existing
>> uses of Reference.get.
>> 
>> There are two native methods involved, one in Reference and an override in
>> PhantomReference, both package private in java.lang.ref. The reason for this
>> split is to simplify the intrinsification. This is a change from the version
>> from April 2020; that version had a single native method in Reference,
>> implemented using the ON_UNKNOWN_OOP_REF Access reference strength category.
>> However, adding support for that category in the compilers adds significant
>> implementation effort and complexity. Splitting avoids that complexity.
>> 
>> Testing:
>> mach5 tier1
>> Locally (linux-x64) verified the new test passes with various garbage collectors.
>
> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
> 
>   improve wording in refersTo javadoc

The API looks good, thanks for getting this in.

-------------

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/498

From mchung at openjdk.java.net  Wed Oct 28 16:12:44 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 28 Oct 2020 16:12:44 GMT
Subject: RFR: 8255449: Improve the exception message of
 MethodHandles::permuteArguments [v3]
In-Reply-To: <EpOOHLlIEc-mWtIYy22QjUrG61do-jyJ2bzhQyj7g5s=.6ff3c7ea-12bb-4fff-8685-326e0e59bd00@github.com>
References: <9ibIdtPhdYSNXJfsy6uIzu4XV46dyZBqc498HIaOII4=.08a61fba-320b-430f-a8cf-9855e4db64de@github.com>
 <EpOOHLlIEc-mWtIYy22QjUrG61do-jyJ2bzhQyj7g5s=.6ff3c7ea-12bb-4fff-8685-326e0e59bd00@github.com>
Message-ID: <tvIREUbLx1ZXDlJ0pYy1yuKpaHa9A4jccuoVZZYBbGU=.b7843090-3b41-4123-a71b-ea12e303b795@github.com>

On Wed, 28 Oct 2020 15:00:59 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Hi,
>> 
>> Currently, if MethodHandles::permuteArguments is used with a reorder array that is the wrong size, or one of the indexes in it is out of bounds of the new type, we simply get the exception message:
>> 
>>     bad reorder array [...]
>> 
>> I think we can improve the exception message by splitting these two error cases, and saying in the message exactly what went wrong.
>> 
>> permuteArguments is a tricky API, so improving the error message here should help to improve developer productivity.
>> 
>> This PR proposes splits the error message into e.g.:
>> 
>>     old type parameter count and reorder array length do not match: (int,int,String)int, [0, 0]
>> 
>> For an incorrect reorder array length, and:
>> 
>>     index is out of bounds for new type: 2, (int,String)int
>> 
>> For an out of bounds index.
>> 
>> Thanks,
>> Jorn
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fail when exception is not thrown in assertThrows

This looks okay to me.

-------------

Marked as reviewed by mchung (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/878

From huizhe.wang at oracle.com  Wed Oct 28 16:52:48 2020
From: huizhe.wang at oracle.com (Joe Wang)
Date: Wed, 28 Oct 2020 09:52:48 -0700
Subject: Filtered XMLStreamReader Exceptions (java.xml)
In-Reply-To: <CAJ9fJk4dF8H1M23xv6L2cacB8epxg1WOsPsX7sRZ=MrAS23aXw@mail.gmail.com>
References: <CAJ9fJk4dF8H1M23xv6L2cacB8epxg1WOsPsX7sRZ=MrAS23aXw@mail.gmail.com>
Message-ID: <1bef2d11-0e3f-944a-4fd7-7b1a8524f9a1@oracle.com>

Hi Mike,

As you said, creating a bug report would be a good start. If it involves 
a signature change, it'd need to go through a proper review (CSR) process.

When you are ready to submit a bug report, please make sure to add a 
test case to illustrate the use case scenario.

Thanks,
Joe

On 10/28/20 5:14 AM, Michael Edgar wrote:
> Hi everyone,
> I'm working on a project that makes use of the StAX API and an issue I have
> encountered is that when wrapping an `XMLStreamReader` with a
> `StreamFilter`, errors encountered in the setup are not thrown to the
> caller. The source of the error could be any stream error that is triggered
> as the `XMLStreamFilterImpl` advances to the next acceptable event.
> Ultimately, when attempting to utilize the filtered reader, some secondary
> exception will occur, but the original `Exception` is lost.
>
> I have not seen any other issues related specifically to this problem, so I
> would like to propose removal of the try/catch in the constructor of
> `com.sun.org.apache.xerces.internal.impl.XMLStreamFilterImpl` and the
> method signature changed to declare that `XMLStreamException` is thrown.
> The constructor is used by
> `com.sun.xml.internal.stream.XMLInputFactoryImpl.createFilteredReader(XMLStreamReader,
> StreamFilter)` which itself already declares the same exception and is an
> implementation of the public `XMLInputFactory` interface.
>
> Further, the `nextTag` method of the same class has a bug where it checks
> for `START_ELEMENT` events twice.
>
> I have an OCA in place and I am happy to submit a PR, but I believe that a
> bug record needs to be opened in order to proceed.
>
> Thank you,
> Mike


From sgehwolf at openjdk.java.net  Wed Oct 28 17:19:52 2020
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Wed, 28 Oct 2020 17:19:52 GMT
Subject: RFR: 8253939: [TESTBUG] Increase coverage of the cgroups
 detection code [v4]
In-Reply-To: <euybZbkMvw89SZ3uPCXjdedj6wKoZ5ezav-6tDFIzUo=.ad92fba3-4ae9-4bfa-8cd1-8d19c85e3a56@github.com>
References: <4G2YAmtWb3u1gyPsKK9lK5X06dKN93_zCqJvsZmjzxE=.1e754307-4dfa-417b-98e5-3af55a441145@github.com>
 <xsQuHOCEl_38GAItRQYfzCUvXSDtLUgJOmwnSWrchxw=.ea3efa65-a968-4a03-a237-03779cbac4d2@github.com>
 <euybZbkMvw89SZ3uPCXjdedj6wKoZ5ezav-6tDFIzUo=.ad92fba3-4ae9-4bfa-8cd1-8d19c85e3a56@github.com>
Message-ID: <J55z2rFPc1ER36aB5hJEf0SMyurojBvTs9knaQwDdjg=.a9b7361f-915d-4c94-82ff-ac871ae4b5ff@github.com>

On Wed, 28 Oct 2020 15:42:37 GMT, Bob Vandette <bobv at openjdk.org> wrote:

>> Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains one additional commit since the last revision:
>> 
>>   8253939: [TESTBUG] Increase coverage of the cgroups detection code
>
> Looks good.

Thanks for the review!

-------------

PR: https://git.openjdk.java.net/jdk/pull/609

From mchung at openjdk.java.net  Wed Oct 28 17:41:48 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 28 Oct 2020 17:41:48 GMT
Subject: RFR: 8159746: (proxy) Support for default methods
In-Reply-To: <50_1vC3yErplQgnnTNJHpF-d0ibuMKtRa9kg3jGKymc=.978abc22-8b04-49ed-b950-7bafe2b1931a@github.com>
References: <kw2VXh3vTFf1zgfd4biXA41OKffZ5oU7KT23tXAxgUA=.bcf14ffc-4dba-4c9c-8754-184172c5acbd@github.com>
 <U-6RiCpFVIrhLztPN6opiPcpFtxValDzU-K7WWFZM-4=.6bc8aaa4-636a-4664-b380-4c4af00513bd@github.com>
 <-cLIJ8pFHtnNoJMHV3aXI7XMJWp4Jrutc8Xn5PG0OK8=.d2cd87ab-3592-4524-ad85-05444c43689b@github.com>
 <r0UK2qjnmgeTNDDSWaSLPAj3QRgx_4YB82ielllO7jM=.fa615bc0-db49-4a74-b842-793f8f5209bb@github.com>
 <1T8kXDZN1bhHr4c8v4SQsImeBySCqTfX-u3_jzvyocA=.b4957400-9a33-4b6e-8475-329642a5888c@github.com>
 <XIux-dY0JXHRafHk48kVNXId9r-HSceNSytBojDxelY=.872e74cb-b064-406e-b71f-13c90ec7fbbc@github.com>
 <j4t2vT0SnwnU7lhKRlXtk967d-K6nA0EqHrqNbba7W0=.dc05dba6-bf7e-4606-8a02-9c2bad4b3b58@github.com>
 <fmVtPcBdgMuZOPm2qx3Q3znVZM7JgQPkhPAVLtwkOhE=.2d8b8447-cfae-4cb3-9a7c-6567a881231f@github.com>
 <GSeWP29fAIUFSk0CYsC557w52CuLqeUWwHNK9maltwI=.3d5f002e-6b74-4a57-a5d8-244d27da9dde@github.com>
 <GF8iEOkMUEL2dYB0HytFIc9gyeeUJ_KP0ImlqFsul2Y=.894afc05-9310-43e1-a308-8f7d71dc572b@github.com>
 <HvtDex3cmiv7XeTMITOroYfu74amSGQavQ_
 BAmVzmXw=.223be989-7c20-4ba4-ac0d-013d2b75a8cb@github.com>
 <IqRiLphFPBpGiKAnMJXqxjie9YeZ03rcE-qG1s92BLw=.d4fd5e92-5067-40df-8a0b-1dfd3d6e23af@github.com>
 <Y0hE51G3YefI6NY1O_E6VoZSKwxE78S1hv6fEatmOG8=.0a2c686c-d9ad-418c-8c1b-49addb8a54b1@github.com>
 <QrNk57L2PWQhJjzYiGTsvYyGIPAfK7bP_kANtTR-2uM=.3e5ce990-f8ea-4751-8147-27a8a9dad40d@github.com>
 <9JNNUzfV3PSvKtSg2a_zyYJmgEn3sZL9cb5sfqemk2o=.f1ef7fb7-bdd5-44ed-98c8-59213e9094f9@github.com>
 <zWGhaC8YB5I0XgffiR7o_YT5gSp9Gbj8Drtt23brl-c=.1e59f0e4-bbe3-4fb2-94dc-c55fc862f091@github.com>
 <LljojgqBhEi6tFptsbmu1jS-Xx7lYEXm9tRkkPqDGzE=.3d7d6a37-1042-4539-88d1-9f4cf5378128@github.com>
 <Gn33ydZNxqOpWUrmYiWJadMF0mukI2MR85EtgrV4D1I=.958521f2-1167-4a68-b513-e10bba37ae18@github.com>
 <NMXKaHql9XjndqPgyoN1Lasa9H8ugl8-ltD1j2XiT9Y=.3ff8871e-0f9d-40ea-8f35-e804a9afcbd5@github.com>
 <yzFe02HJ2qt5tT8tY9ZOofnKld93x1PM5U7AToTABJs=.439c213b-94b9-488f-bb6d-a835a86c527f@github.com>
 <BoATjx7PPcLpINJVC5HM77UKMriIUqnnhcBowkJRlvM=.1221e3e1-ed27-4618-8365-dcd903d27f60@
 github.com>
 <yN0JJE9mBkqz9Ijbw4FYinv08tcnxiZHAGyarXBF9CY=.50429cb9-181a-447e-90a0-e0a0a836812e@github.com>
 <CoqZRJ39DVdNI9wzS372aAG3ZIB7hrIrndaO5VrsmBA=.f78629d2-3409-44c1-9e66-7951bbd630e6@github.com>
 <W6qIb_NPGRUpQd_obRiIumwbXSTDheSdg-qnkc3cZ90=.f1f46290-3b7c-4e88-994f-5d19e0134256@github.com>
 <nALY_XHf4_MGKZHIzpIRbqLEG22ySg0NZ8mQbun7up0=.69d14612-31a4-4533-924c-01768ed50be1@github.com>
 <dWu0mcInZ8duRgGoQRfdgKXASYodtIhqgoejf-weUek=.eec68bf3-1a34-4f4b-82ca-6be48caeff1c@github.com>
 <S-gpV6ntV3fkkjzvU8PYpAWAJVWpvdykReMXyRVwd9U=.0893dd0d-55d0-49c1-9bb9-883005fed496@github.com>
 <VE9aWCMrcLW5QIl0wRpGppb0gObfI0cfbg0DnuKRfSs=.e398df44-4b64-465a-9697-8b4d2ed1652d@github.com>
 <50_1vC3yErplQgnnTNJHpF-d0ibuMKtRa9kg3jGKymc=.978abc22-8b04-49ed-b950-7bafe2b1931a@github.com>
Message-ID: <3_3xp4MbiLH-_9zyTkLVKZKP3ds0AftAVtbWo8tYeFs=.483fa478-0e33-495d-a545-b2339ecee592@github.com>

On Wed, 28 Oct 2020 08:35:47 GMT, Peter Levart <plevart at openjdk.org> wrote:

> Yes, but it is not really useful there. The super handler is captured by the user invocation handler created in the invocation handler factory function and it is only used by the user invocation handler. All we need in the proxy instance is a boolean flag indicating the way the invocation handler was created (which one of the two overloaded newProxyInstance methods was called).

Either way provides the distinction if this proxy class supports default method invocation.   I chose to store the superHandler rather than a boolean that may allow us to do white-box testing (an alternative to the trick in getting the superHandler in spinning another proxy instance).   It's a trivial change  if we prefer to store a boolean field but keep the constructor to take `superHandler` parameter.  I'm fine with it.

> To be precise, we need to pass CCE and NPE thrown by the default method unchanged, but we need to wrap CCE and NPE thrown by the method handle transformation chain with IllegalArgumentException. Is that what you are referring to? 

Yes and it's implementation details.  For the specification side, I agree that `InvocationHandler::invoke` throws the exception by the method and no need to wrap it with `InvocationTargetException` .

> "Do we want to wrap CCE and NPE thrown by the method handle transformation chain with IllegalArgumentException?".

I did consider that and propose to go with IAE for simplicity and consistency with the core reflection (`Method::invoke`, `Field::set` etc) when there is an illegal argument.   Is it worth specifying `CCE` and  `NPE` explicitly when an argument fails the conversion?   Maybe but average users of `java.lang.reflect` may not use `java.lang.invoke` and `IAE` is thrown for illegal argument to the method invocation.   When invoking a default method, `Method` object representing a default method is passed to `superHandler` and it's intuitive to consider the behavior as if `Method::invoke` is called (note that the specification does not mandate/expect to use `Lookup::findSpecial` and `MethodHandle::invoke*`).   While CCE and NPE provide slightly clearer reason of the illegal argument, as you said, they are subtle variants of the same thing indicating the parameters are wrong.  This only impacts the performance of the exception cases which should not be a big concern.    This explains why I a
 m in favor to throw IAE for illegal arguments which is the expected behavior for average core reflection users.  

> What to do about that. Is UncheckedReflectiveOperationException a suitable solution? 

I do see your point of proposing `UncheckedReflectiveOperationException` which I thought about too and was tempted.  I'm uncertain yet if we want a  unchecked  exception type for any reflective operation exceptions.     Should future new `java.lang.reflect` and `java.lang.invoke` APIs use the unchecked exception?  This is a broader question to answer than one specific exception type `java.lang.reflect.InaccessibleInvocationHandlerException`??

> I'm not particularly fond of creating another Proxy.invocationHandler method, because it does not solve the problem of the old method that may also be called.

Me neither.

-------------

PR: https://git.openjdk.java.net/jdk/pull/313

From naoto at openjdk.java.net  Wed Oct 28 17:41:52 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 28 Oct 2020 17:41:52 GMT
Subject: RFR: 8255533: Incorrect javadoc in
 DateTimeFormatterBuilder.appendPattern() for 'uu'/'yy'
Message-ID: <k7ADQrfpo4r_1r8-r5GPNIu0maVDzqen-8naxdUjjeg=.122298df-6124-446d-9253-1056a5fd0352@github.com>

Hi,

Please review this simple doc fix in DateTimeFormatterBuilder.appendPattern(). It is missing the value for `maxWidth` argument.

Naoto

-------------

Commit messages:
 - 8255533: Incorrect javadoc in DateTimeFormatterBuilder.appendPattern() for 'uu'/'yy'

Changes: https://git.openjdk.java.net/jdk/pull/908/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=908&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8255533
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/908.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/908/head:pull/908

PR: https://git.openjdk.java.net/jdk/pull/908

From lancea at openjdk.java.net  Wed Oct 28 17:49:46 2020
From: lancea at openjdk.java.net (Lance Andersen)
Date: Wed, 28 Oct 2020 17:49:46 GMT
Subject: RFR: 8255533: Incorrect javadoc in
 DateTimeFormatterBuilder.appendPattern() for 'uu'/'yy'
In-Reply-To: <k7ADQrfpo4r_1r8-r5GPNIu0maVDzqen-8naxdUjjeg=.122298df-6124-446d-9253-1056a5fd0352@github.com>
References: <k7ADQrfpo4r_1r8-r5GPNIu0maVDzqen-8naxdUjjeg=.122298df-6124-446d-9253-1056a5fd0352@github.com>
Message-ID: <bdzBwMqb-yw2cjeHyaJbnSDEfQBWk122hrWiRjszCd8=.dcb0596e-de11-4fb0-9bd9-8c521ec4c58c@github.com>

On Wed, 28 Oct 2020 17:35:16 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Hi,
> 
> Please review this simple doc fix in DateTimeFormatterBuilder.appendPattern(). It is missing the value for `maxWidth` argument.
> 
> Naoto

Looks good

-------------

Marked as reviewed by lancea (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/908

From github.com+828220+forax at openjdk.java.net  Wed Oct 28 18:05:51 2020
From: github.com+828220+forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Wed, 28 Oct 2020 18:05:51 GMT
Subject: RFR: 8159746: (proxy) Support for default methods
In-Reply-To: <3_3xp4MbiLH-_9zyTkLVKZKP3ds0AftAVtbWo8tYeFs=.483fa478-0e33-495d-a545-b2339ecee592@github.com>
References: <kw2VXh3vTFf1zgfd4biXA41OKffZ5oU7KT23tXAxgUA=.bcf14ffc-4dba-4c9c-8754-184172c5acbd@github.com>
 <U-6RiCpFVIrhLztPN6opiPcpFtxValDzU-K7WWFZM-4=.6bc8aaa4-636a-4664-b380-4c4af00513bd@github.com>
 <-cLIJ8pFHtnNoJMHV3aXI7XMJWp4Jrutc8Xn5PG0OK8=.d2cd87ab-3592-4524-ad85-05444c43689b@github.com>
 <r0UK2qjnmgeTNDDSWaSLPAj3QRgx_4YB82ielllO7jM=.fa615bc0-db49-4a74-b842-793f8f5209bb@github.com>
 <1T8kXDZN1bhHr4c8v4SQsImeBySCqTfX-u3_jzvyocA=.b4957400-9a33-4b6e-8475-329642a5888c@github.com>
 <XIux-dY0JXHRafHk48kVNXId9r-HSceNSytBojDxelY=.872e74cb-b064-406e-b71f-13c90ec7fbbc@github.com>
 <j4t2vT0SnwnU7lhKRlXtk967d-K6nA0EqHrqNbba7W0=.dc05dba6-bf7e-4606-8a02-9c2bad4b3b58@github.com>
 <fmVtPcBdgMuZOPm2qx3Q3znVZM7JgQPkhPAVLtwkOhE=.2d8b8447-cfae-4cb3-9a7c-6567a881231f@github.com>
 <GSeWP29fAIUFSk0CYsC557w52CuLqeUWwHNK9maltwI=.3d5f002e-6b74-4a57-a5d8-244d27da9dde@github.com>
 <GF8iEOkMUEL2dYB0HytFIc9gyeeUJ_KP0ImlqFsul2Y=.894afc05-9310-43e1-a308-8f7d71dc572b@github.com>
 <HvtDex3cmiv7XeTMITOroYfu74amSGQavQ_
 BAmVzmXw=.223be989-7c20-4ba4-ac0d-013d2b75a8cb@github.com>
 <IqRiLphFPBpGiKAnMJXqxjie9YeZ03rcE-qG1s92BLw=.d4fd5e92-5067-40df-8a0b-1dfd3d6e23af@github.com>
 <Y0hE51G3YefI6NY1O_E6VoZSKwxE78S1hv6fEatmOG8=.0a2c686c-d9ad-418c-8c1b-49addb8a54b1@github.com>
 <QrNk57L2PWQhJjzYiGTsvYyGIPAfK7bP_kANtTR-2uM=.3e5ce990-f8ea-4751-8147-27a8a9dad40d@github.com>
 <9JNNUzfV3PSvKtSg2a_zyYJmgEn3sZL9cb5sfqemk2o=.f1ef7fb7-bdd5-44ed-98c8-59213e9094f9@github.com>
 <zWGhaC8YB5I0XgffiR7o_YT5gSp9Gbj8Drtt23brl-c=.1e59f0e4-bbe3-4fb2-94dc-c55fc862f091@github.com>
 <LljojgqBhEi6tFptsbmu1jS-Xx7lYEXm9tRkkPqDGzE=.3d7d6a37-1042-4539-88d1-9f4cf5378128@github.com>
 <Gn33ydZNxqOpWUrmYiWJadMF0mukI2MR85EtgrV4D1I=.958521f2-1167-4a68-b513-e10bba37ae18@github.com>
 <NMXKaHql9XjndqPgyoN1Lasa9H8ugl8-ltD1j2XiT9Y=.3ff8871e-0f9d-40ea-8f35-e804a9afcbd5@github.com>
 <yzFe02HJ2qt5tT8tY9ZOofnKld93x1PM5U7AToTABJs=.439c213b-94b9-488f-bb6d-a835a86c527f@github.com>
 <BoATjx7PPcLpINJVC5HM77UKMriIUqnnhcBowkJRlvM=.1221e3e1-ed27-4618-8365-dcd903d27f60@
 github.com>
 <yN0JJE9mBkqz9Ijbw4FYinv08tcnxiZHAGyarXBF9CY=.50429cb9-181a-447e-90a0-e0a0a836812e@github.com>
 <CoqZRJ39DVdNI9wzS372aAG3ZIB7hrIrndaO5VrsmBA=.f78629d2-3409-44c1-9e66-7951bbd630e6@github.com>
 <W6qIb_NPGRUpQd_obRiIumwbXSTDheSdg-qnkc3cZ90=.f1f46290-3b7c-4e88-994f-5d19e0134256@github.com>
 <nALY_XHf4_MGKZHIzpIRbqLEG22ySg0NZ8mQbun7up0=.69d14612-31a4-4533-924c-01768ed50be1@github.com>
 <dWu0mcInZ8duRgGoQRfdgKXASYodtIhqgoejf-weUek=.eec68bf3-1a34-4f4b-82ca-6be48caeff1c@github.com>
 <S-gpV6ntV3fkkjzvU8PYpAWAJVWpvdykReMXyRVwd9U=.0893dd0d-55d0-49c1-9bb9-883005fed496@github.com>
 <VE9aWCMrcLW5QIl0wRpGppb0gObfI0cfbg0DnuKRfSs=.e398df44-4b64-465a-9697-8b4d2ed1652d@github.com>
 <50_1vC3yErplQgnnTNJHpF-d0ibuMKtRa9kg3jGKymc=.978abc22-8b04-49ed-b950-7bafe2b1931a@github.com>
 <3_3xp4MbiLH-_9zyTkLVKZKP3ds0AftAVtbWo8tYeFs=.483fa478-0e33-495d-a545-b2339ecee592@github.com>
Message-ID: <X93bQ76ydubQKGZAlD4ub43vTBHXjwnXQx--UN5xgus=.5e2ddf9d-86a5-4c34-b53a-65daff1d43df@github.com>

On Wed, 28 Oct 2020 17:36:40 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>>> Hi Peter,
>>> 
>>> > Question remains how do we distinguish proxies with old-fassioned InvocationHandlers from proxies with InvocationHandlers having access to super-default-handler. Both kinds of handlers look the same from Proxy's perspective... Perhaps we need a boolean flag in Proxy instance for that, coupled with an overloaded constructor that takes it...
>>> 
>>> I have the Proxy constructor taking both the invocation handler and `superHandler` in my [mlchung:proxy-default-method-4](https://github.com/mlchung/jdk/tree/proxy-default-method-4) branch.
>>> 
>> 
>> Yes, but it is not really useful there. The super handler is captured by the user invocation handler created in the invocation handler factory function and it is only used by the user invocation handler. All we need in the proxy instance is a boolean flag indicating the way the invocation handler was created (which one of the two overloaded newProxyInstance methods was called).
>> 
>>> > Problem with this approach is that it is not really useful in the proxy instance. We don't need it in the proxy instance.
>>> 
>>> See above.
>>> 
>>> About the exception thrown: we need to distinguish CCE and NPE thrown by the default method vs thrown by arguments incompatible with the method signature. In my proxy-default-method-4 branch, I define an internal exception type for that. There is an overhead doing the wrapping but it's an exception case which performance should not be critical.
>> 
>> To be precise, we need to pass CCE and NPE thrown by the default method unchanged, but we need to wrap CCE and NPE thrown by the method handle transformation chain with IllegalArgumentException. Is that what you are referring to? In that case we need an internal exception type, not exposed to public API, used just to "tunnel" the exception from the default method unchanged. That's just implementation detail.
>> 
>> But we have to ask ourselves a question: "Do we want to wrap CCE and NPE thrown by the method handle transformation chain with IllegalArgumentException?". We did that in previous variants to mimic the Method.invoke specification. But now we already departed from that specification by not wrapping exceptions thrown by the default method with InvocationTargetException. So we are not obligated to follow the rest of the Method.invoke specification either. All exception types thrown by method handle transformation chain (CCE, NPE, IAE) are unchecked exceptions and as such are not eligible to wrapping with UndeclaredThrowableException by the Proxy API. So it's just a matter of deciding what is more suitable: to have more specific exception types (CCE, NPE, IAE) for describing transformation exceptions or to reduce them to one common type (IAE). In either case those exception types can also be thrown by the default method and we can't or even want to distinguish their source. Let's be ho
 nest, all of CCE, NPE, IAE are usually describing the subtle variants of the same thing: that the parameters are wrong. Whether this happens in the logic of invocation handler, method handle transformation chain or the default method, we want those exceptions to propagate out of the invoked proxy method unchanged.
>> 
>> So WDYT?
>
>> Yes, but it is not really useful there. The super handler is captured by the user invocation handler created in the invocation handler factory function and it is only used by the user invocation handler. All we need in the proxy instance is a boolean flag indicating the way the invocation handler was created (which one of the two overloaded newProxyInstance methods was called).
> 
> Either way provides the distinction if this proxy class supports default method invocation.   I chose to store the superHandler rather than a boolean that may allow us to do white-box testing (an alternative to the trick in getting the superHandler in spinning another proxy instance).   It's a trivial change  if we prefer to store a boolean field but keep the constructor to take `superHandler` parameter.  I'm fine with it.
> 
>> To be precise, we need to pass CCE and NPE thrown by the default method unchanged, but we need to wrap CCE and NPE thrown by the method handle transformation chain with IllegalArgumentException. Is that what you are referring to? 
> 
> Yes and it's implementation details.  For the specification side, I agree that `InvocationHandler::invoke` throws the exception by the method and no need to wrap it with `InvocationTargetException` .
> 
>> "Do we want to wrap CCE and NPE thrown by the method handle transformation chain with IllegalArgumentException?".
> 
> I did consider that and propose to go with IAE for simplicity and consistency with the core reflection (`Method::invoke`, `Field::set` etc) when there is an illegal argument.   Is it worth specifying `CCE` and  `NPE` explicitly when an argument fails the conversion?   Maybe but average users of `java.lang.reflect` may not use `java.lang.invoke` and `IAE` is thrown for illegal argument to the method invocation.   When invoking a default method, `Method` object representing a default method is passed to `superHandler` and it's intuitive to consider the behavior as if `Method::invoke` is called (note that the specification does not mandate/expect to use `Lookup::findSpecial` and `MethodHandle::invoke*`).   While CCE and NPE provide slightly clearer reason of the illegal argument, as you said, they are subtle variants of the same thing indicating the parameters are wrong.  This only impacts the performance of the exception cases which should not be a big concern.    This explains why I
  am in favor to throw IAE for illegal arguments which is the expected behavior for average core reflection users.  
> 
>> What to do about that. Is UncheckedReflectiveOperationException a suitable solution? 
> 
> I do see your point of proposing `UncheckedReflectiveOperationException` which I thought about too and was tempted.  I'm uncertain yet if we want a  unchecked  exception type for any reflective operation exceptions.     Should future new `java.lang.reflect` and `java.lang.invoke` APIs use the unchecked exception?  This is a broader question to answer than one specific exception type `java.lang.reflect.InaccessibleInvocationHandlerException`??
> 
>> I'm not particularly fond of creating another Proxy.invocationHandler method, because it does not solve the problem of the old method that may also be called.
> 
> Me neither.

Hi Mandy and Peter,
reading your exchanges, i wonder if it's not better to stop trying to add more and more features to the already clunky java.lang.reflect.Proxy but instead to move to provide the same set of feature but using an implementation based on java.lang.invoke.Lookup/MethodHandle.

I propose to introduce a java.lang.invoke.Proxy has a replacement of java.lang.reflect.Proxy using j.l.i.MethodHandle instead of j.l.r.Method, the equivalent of the InvocationHandler acting as a linker called once per the first time a method of the Proxy is called instead of being called each time a method is called.

Such proxy
- has it's security model based on Lookup to define the class,
  so no supplementary restrictions on package/module of the interface implemented
- avoid to mix java.lang.reflect API and java.invoke API
- is transparent in term of exceptions (ther are propagated without any wrapping/unwrapping)
- can support default methods natively
- doesn't requires any caching (the user will be responsible to do the caching)
- is more efficient, actually as efficient as the equivalent written code or a little more (thanks to @ForceInline)

-------------

PR: https://git.openjdk.java.net/jdk/pull/313

From rriggs at openjdk.java.net  Wed Oct 28 18:29:51 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 28 Oct 2020 18:29:51 GMT
Subject: RFR: 8255533: Incorrect javadoc in
 DateTimeFormatterBuilder.appendPattern() for 'uu'/'yy'
In-Reply-To: <k7ADQrfpo4r_1r8-r5GPNIu0maVDzqen-8naxdUjjeg=.122298df-6124-446d-9253-1056a5fd0352@github.com>
References: <k7ADQrfpo4r_1r8-r5GPNIu0maVDzqen-8naxdUjjeg=.122298df-6124-446d-9253-1056a5fd0352@github.com>
Message-ID: <vLDJvRsPx5C3koPI-l2PIYHz9iUPcWT6_X3r4PKEIcc=.d40bb753-2203-4f8f-8a09-c12d11ea4a29@github.com>

On Wed, 28 Oct 2020 17:35:16 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Hi,
> 
> Please review this simple doc fix in DateTimeFormatterBuilder.appendPattern(). It is missing the value for `maxWidth` argument.
> 
> Naoto

Marked as reviewed by rriggs (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/908

From sgehwolf at openjdk.java.net  Wed Oct 28 18:57:46 2020
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Wed, 28 Oct 2020 18:57:46 GMT
Subject: Integrated: 8253939: [TESTBUG] Increase coverage of the cgroups
 detection code
In-Reply-To: <4G2YAmtWb3u1gyPsKK9lK5X06dKN93_zCqJvsZmjzxE=.1e754307-4dfa-417b-98e5-3af55a441145@github.com>
References: <4G2YAmtWb3u1gyPsKK9lK5X06dKN93_zCqJvsZmjzxE=.1e754307-4dfa-417b-98e5-3af55a441145@github.com>
Message-ID: <MNUr4jCm24M3VOM7BEYrJCgeMFFH4AMMhKBH6hQeRJI=.2a7ebb78-5c4f-4dcb-9668-62be3307be9d@github.com>

On Mon, 12 Oct 2020 13:24:16 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Test only change. With [JDK-8253435](https://bugs.openjdk.java.net/browse/JDK-8253435) a test has been added on the hotspot side, but nothing for the Java Metrics code. Same for [JDK-8252359](https://bugs.openjdk.java.net/browse/JDK-8252359).
> 
> When JDK-8217766 got fixed cgroup factories with the detection logic didn't exist so were harder to test. This patch adds tests for them too.
> 
> Thoughts?

This pull request has now been integrated.

Changeset: 42fc1589
Author:    Severin Gehwolf <sgehwolf at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/42fc1589
Stats:     147 lines in 2 files changed: 134 ins; 0 del; 13 mod

8253939: [TESTBUG] Increase coverage of the cgroups detection code

Reviewed-by: shade, bobv

-------------

PR: https://git.openjdk.java.net/jdk/pull/609

From mchung at openjdk.java.net  Wed Oct 28 19:31:45 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 28 Oct 2020 19:31:45 GMT
Subject: RFR: 8159746: (proxy) Support for default methods
In-Reply-To: <X93bQ76ydubQKGZAlD4ub43vTBHXjwnXQx--UN5xgus=.5e2ddf9d-86a5-4c34-b53a-65daff1d43df@github.com>
References: <kw2VXh3vTFf1zgfd4biXA41OKffZ5oU7KT23tXAxgUA=.bcf14ffc-4dba-4c9c-8754-184172c5acbd@github.com>
 <U-6RiCpFVIrhLztPN6opiPcpFtxValDzU-K7WWFZM-4=.6bc8aaa4-636a-4664-b380-4c4af00513bd@github.com>
 <-cLIJ8pFHtnNoJMHV3aXI7XMJWp4Jrutc8Xn5PG0OK8=.d2cd87ab-3592-4524-ad85-05444c43689b@github.com>
 <r0UK2qjnmgeTNDDSWaSLPAj3QRgx_4YB82ielllO7jM=.fa615bc0-db49-4a74-b842-793f8f5209bb@github.com>
 <1T8kXDZN1bhHr4c8v4SQsImeBySCqTfX-u3_jzvyocA=.b4957400-9a33-4b6e-8475-329642a5888c@github.com>
 <XIux-dY0JXHRafHk48kVNXId9r-HSceNSytBojDxelY=.872e74cb-b064-406e-b71f-13c90ec7fbbc@github.com>
 <j4t2vT0SnwnU7lhKRlXtk967d-K6nA0EqHrqNbba7W0=.dc05dba6-bf7e-4606-8a02-9c2bad4b3b58@github.com>
 <fmVtPcBdgMuZOPm2qx3Q3znVZM7JgQPkhPAVLtwkOhE=.2d8b8447-cfae-4cb3-9a7c-6567a881231f@github.com>
 <GSeWP29fAIUFSk0CYsC557w52CuLqeUWwHNK9maltwI=.3d5f002e-6b74-4a57-a5d8-244d27da9dde@github.com>
 <GF8iEOkMUEL2dYB0HytFIc9gyeeUJ_KP0ImlqFsul2Y=.894afc05-9310-43e1-a308-8f7d71dc572b@github.com>
 <HvtDex3cmiv7XeTMITOroYfu74amSGQavQ_
 BAmVzmXw=.223be989-7c20-4ba4-ac0d-013d2b75a8cb@github.com>
 <IqRiLphFPBpGiKAnMJXqxjie9YeZ03rcE-qG1s92BLw=.d4fd5e92-5067-40df-8a0b-1dfd3d6e23af@github.com>
 <Y0hE51G3YefI6NY1O_E6VoZSKwxE78S1hv6fEatmOG8=.0a2c686c-d9ad-418c-8c1b-49addb8a54b1@github.com>
 <QrNk57L2PWQhJjzYiGTsvYyGIPAfK7bP_kANtTR-2uM=.3e5ce990-f8ea-4751-8147-27a8a9dad40d@github.com>
 <9JNNUzfV3PSvKtSg2a_zyYJmgEn3sZL9cb5sfqemk2o=.f1ef7fb7-bdd5-44ed-98c8-59213e9094f9@github.com>
 <zWGhaC8YB5I0XgffiR7o_YT5gSp9Gbj8Drtt23brl-c=.1e59f0e4-bbe3-4fb2-94dc-c55fc862f091@github.com>
 <LljojgqBhEi6tFptsbmu1jS-Xx7lYEXm9tRkkPqDGzE=.3d7d6a37-1042-4539-88d1-9f4cf5378128@github.com>
 <Gn33ydZNxqOpWUrmYiWJadMF0mukI2MR85EtgrV4D1I=.958521f2-1167-4a68-b513-e10bba37ae18@github.com>
 <NMXKaHql9XjndqPgyoN1Lasa9H8ugl8-ltD1j2XiT9Y=.3ff8871e-0f9d-40ea-8f35-e804a9afcbd5@github.com>
 <yzFe02HJ2qt5tT8tY9ZOofnKld93x1PM5U7AToTABJs=.439c213b-94b9-488f-bb6d-a835a86c527f@github.com>
 <BoATjx7PPcLpINJVC5HM77UKMriIUqnnhcBowkJRlvM=.1221e3e1-ed27-4618-8365-dcd903d27f60@
 github.com>
 <yN0JJE9mBkqz9Ijbw4FYinv08tcnxiZHAGyarXBF9CY=.50429cb9-181a-447e-90a0-e0a0a836812e@github.com>
 <CoqZRJ39DVdNI9wzS372aAG3ZIB7hrIrndaO5VrsmBA=.f78629d2-3409-44c1-9e66-7951bbd630e6@github.com>
 <W6qIb_NPGRUpQd_obRiIumwbXSTDheSdg-qnkc3cZ90=.f1f46290-3b7c-4e88-994f-5d19e0134256@github.com>
 <nALY_XHf4_MGKZHIzpIRbqLEG22ySg0NZ8mQbun7up0=.69d14612-31a4-4533-924c-01768ed50be1@github.com>
 <dWu0mcInZ8duRgGoQRfdgKXASYodtIhqgoejf-weUek=.eec68bf3-1a34-4f4b-82ca-6be48caeff1c@github.com>
 <S-gpV6ntV3fkkjzvU8PYpAWAJVWpvdykReMXyRVwd9U=.0893dd0d-55d0-49c1-9bb9-883005fed496@github.com>
 <VE9aWCMrcLW5QIl0wRpGppb0gObfI0cfbg0DnuKRfSs=.e398df44-4b64-465a-9697-8b4d2ed1652d@github.com>
 <50_1vC3yErplQgnnTNJHpF-d0ibuMKtRa9kg3jGKymc=.978abc22-8b04-49ed-b950-7bafe2b1931a@github.com>
 <3_3xp4MbiLH-_9zyTkLVKZKP3ds0AftAVtbWo8tYeFs=.483fa478-0e33-495d-a545-b2339ecee592@github.com>
 <X93bQ76ydubQKGZAlD4ub43vTBHXjwnXQx--UN5xgus=.5e2ddf9d-86a5-4c34-b53a-65daff1d43df@github.com>
Message-ID: <mthe4gxs2yOuXitvRF4Cwzbk4LLamGCDlxTaQJdRo_g=.edaa421c-e144-4466-a07f-251da9357364@github.com>

On Wed, 28 Oct 2020 18:01:44 GMT, R?mi Forax <github.com+828220+forax at openjdk.org> wrote:

>>> Yes, but it is not really useful there. The super handler is captured by the user invocation handler created in the invocation handler factory function and it is only used by the user invocation handler. All we need in the proxy instance is a boolean flag indicating the way the invocation handler was created (which one of the two overloaded newProxyInstance methods was called).
>> 
>> Either way provides the distinction if this proxy class supports default method invocation.   I chose to store the superHandler rather than a boolean that may allow us to do white-box testing (an alternative to the trick in getting the superHandler in spinning another proxy instance).   It's a trivial change  if we prefer to store a boolean field but keep the constructor to take `superHandler` parameter.  I'm fine with it.
>> 
>>> To be precise, we need to pass CCE and NPE thrown by the default method unchanged, but we need to wrap CCE and NPE thrown by the method handle transformation chain with IllegalArgumentException. Is that what you are referring to? 
>> 
>> Yes and it's implementation details.  For the specification side, I agree that `InvocationHandler::invoke` throws the exception by the method and no need to wrap it with `InvocationTargetException` .
>> 
>>> "Do we want to wrap CCE and NPE thrown by the method handle transformation chain with IllegalArgumentException?".
>> 
>> I did consider that and propose to go with IAE for simplicity and consistency with the core reflection (`Method::invoke`, `Field::set` etc) when there is an illegal argument.   Is it worth specifying `CCE` and  `NPE` explicitly when an argument fails the conversion?   Maybe but average users of `java.lang.reflect` may not use `java.lang.invoke` and `IAE` is thrown for illegal argument to the method invocation.   When invoking a default method, `Method` object representing a default method is passed to `superHandler` and it's intuitive to consider the behavior as if `Method::invoke` is called (note that the specification does not mandate/expect to use `Lookup::findSpecial` and `MethodHandle::invoke*`).   While CCE and NPE provide slightly clearer reason of the illegal argument, as you said, they are subtle variants of the same thing indicating the parameters are wrong.  This only impacts the performance of the exception cases which should not be a big concern.    This explains why 
 I am in favor to throw IAE for illegal arguments which is the expected behavior for average core reflection users.  
>> 
>>> What to do about that. Is UncheckedReflectiveOperationException a suitable solution? 
>> 
>> I do see your point of proposing `UncheckedReflectiveOperationException` which I thought about too and was tempted.  I'm uncertain yet if we want a  unchecked  exception type for any reflective operation exceptions.     Should future new `java.lang.reflect` and `java.lang.invoke` APIs use the unchecked exception?  This is a broader question to answer than one specific exception type `java.lang.reflect.InaccessibleInvocationHandlerException`??
>> 
>>> I'm not particularly fond of creating another Proxy.invocationHandler method, because it does not solve the problem of the old method that may also be called.
>> 
>> Me neither.
>
> Hi Mandy and Peter,
> reading your exchanges, i wonder if it's not better to stop trying to add more and more features to the already clunky java.lang.reflect.Proxy but instead to move to provide the same set of feature but using an implementation based on java.lang.invoke.Lookup/MethodHandle.
> 
> I propose to introduce a java.lang.invoke.Proxy has a replacement of java.lang.reflect.Proxy using j.l.i.MethodHandle instead of j.l.r.Method, the equivalent of the InvocationHandler acting as a linker called once per the first time a method of the Proxy is called instead of being called each time a method is called.
> 
> Such proxy
> - has it's security model based on Lookup to define the class,
>   so no supplementary restrictions on package/module of the interface implemented
> - avoid to mix java.lang.reflect API and java.invoke API
> - is transparent in term of exceptions (ther are propagated without any wrapping/unwrapping)
> - can support default methods natively
> - doesn't requires any caching (the user will be responsible to do the caching)
> - is more efficient, actually as efficient as the equivalent written code or a little more (thanks to @ForceInline)

Hi Remi,

I appreciate your proposal to modernize Proxy API.   There are several requests for this enhancement to support default methods in Proxy.   Defining a new `java.lang.invoke.Proxy` is a much bigger project that I can't tell when the existing users of `java.lang.reflect.Proxy` will be able to get this default method invocation support.  

I do agree that this API design has many challenges caused by what you listed above.   Well, I believe we are very close to have a consensus:
1. New `newProxyInstance` factory method takes a handler factory doing the access check
2. Update `getInvocationHandler` to throw `InaccessibleInvocationHandlerException` if access denied to get an invocation handler associated with the proxy instance

If this needs more time, I think we can consider to shelf this RFE and come back to it later (and consider your proposal as well).

-------------

PR: https://git.openjdk.java.net/jdk/pull/313

From alexey.semenyuk at oracle.com  Wed Oct 28 19:59:21 2020
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Wed, 28 Oct 2020 15:59:21 -0400
Subject: [jpackage] Issue with upgrading from javapackager to jpackage on
 Windows
In-Reply-To: <CAAoP7T4UBLatfAneSv-VN06cG6w4SVeS+FfEqJBP8sSmqdaxQw@mail.gmail.com>
References: <mailman.5881.1581956828.14600.core-libs-dev@openjdk.java.net>
 <02102893-DD43-4626-9F39-DBBD1A71975C@deepsymmetry.org>
 <CAAoP7T7VT1ewQiNsb6SG00jrwRX1yX93v7moBEVwMUHoU4HmTA@mail.gmail.com>
 <CAAoP7T7YCvc2bnOUqLNnw22FJXV26BNGW+ceA3ptNjg_rFDXtg@mail.gmail.com>
 <d25818fa-d4af-5906-df7e-a6c4ff0e8b8b@oracle.com>
 <CAAoP7T4UBLatfAneSv-VN06cG6w4SVeS+FfEqJBP8sSmqdaxQw@mail.gmail.com>
Message-ID: <a83c8ff4-a791-6e63-0616-8d057426f02b@oracle.com>

Daniel,

https://bugs.openjdk.java.net/browse/JDK-8240111 has been updated with 
the evaluation of your request. Please take a look.

- Alexey

On 2/27/2020 2:00 AM, Daniel Peintner wrote:
> Alexey, all,
>
> In my case the update, as described, seems to work just fine. However 
> once I try to actually start the application nothing happens. It 
> silently fails.
>
> Could this be a reason why you don't encounter any issue? Just an idea 
> though...
>
> -- Daniel
>
>
> Alexey Semenyuk <alexey.semenyuk at oracle.com 
> <mailto:alexey.semenyuk at oracle.com>> schrieb am Mi., 26. Feb. 2020, 22:56:
>
>     Daniel,
>
>     Interesting. We have jtreg tests for testing upgrade scenarios on
>     Windows and they work without Upgrade element in WiX template.
>
>     - Alexey
>
>     On 2/26/2020 11:10 AM, Daniel Peintner wrote:
>     > All,
>     >
>     > after some private discussions with James and @Kevinnns I
>     believe the
>     > necessary change to let upgrades succeed is rather minimal.
>     >
>     > The WIX template jpackage uses
>     >
>     > <Product Id="*" Name="$(var.AppName)" Language="1033"
>     > Version="$(var.AppVersion)" Manufacturer="$(var.AppVendor)"
>     > UpgradeCode="$(var.AppUpgradeCode)">
>     >
>     > needs to have
>     >
>     > <Upgrade Id="$(var.AppUpgradeCode)" />
>     >
>     > as well within the product element.
>     >
>     > I wonder whether anyone in the jpackage team is willing to work
>     or look
>     > into this proposed change. Or does this cause any other issue I
>     am not
>     > aware of?
>     >
>     > As said, I think this would be a big help for anyone coming from
>     the *old*
>     > javapackager tool.
>     >
>     > Thanks,
>     >
>     > -- Daniel
>     >
>     >
>     >
>     >
>     >
>     >
>     > On Tue, Feb 25, 2020 at 4:30 PM Daniel Peintner
>     <daniel.peintner at gmail.com <mailto:daniel.peintner at gmail.com>>
>     > wrote:
>     >
>     >> Hi James, all,
>     >>
>     >> Thank you for your feedback.
>     >>
>     >> I did try around and I think there is a jpackage upgrade ID
>     option now.
>     >>
>     >> --win-upgrade-uuid <string> ? UUID associated with upgrades for
>     this
>     >> package
>     >>
>     >> In my case though, I think I run into some other issues. The
>     InnoSetup
>     >> installer seems not to provide any UUID.
>     >>
>     >> I believe I also found a related issue [1] that mentions UUID and
>     >> InnoSetup but unfortunately that didn't help me either.
>     >>
>     >> Thanks again for any help,
>     >>
>     >> -- Daniel
>     >>
>     >> [1] https://bugs.openjdk.java.net/browse/JDK-8214564
>     >>
>     >>
>     >>
>     >> On Mon, Feb 17, 2020 at 5:38 PM James Elliott
>     <james at deepsymmetry.org <mailto:james at deepsymmetry.org>>
>     >> wrote:
>     >>
>     >>> Sorry, tried sending this with the incorrect email personality
>     first.
>     >>>
>     >>> On Mon, 17 Feb 2020 15:32:14 +0100 Daniel Peintner <
>     >>> daniel.peintner at gmail.com <mailto:daniel.peintner at gmail.com>
>     <mailto:daniel.peintner at gmail.com
>     <mailto:daniel.peintner at gmail.com>>> wrote:
>     >>>> The only *working* solution we found was to *manually*
>     uninstall the old
>     >>>> application before starting msi installer.
>     >>>> Any future update with msi installers work fine. But the
>     first update
>     >>> fails!
>     >>>
>     >>> I had been previously manually creating WiX installers (with
>     the help of
>     >>> a script built by one of my Windows-based users), and he
>     discovered the
>     >>> same problem when I migrated to jpackage. It turns out that the
>     >>> jpackage-built WiX installers are missing an upgrade ID. I
>     mentioned that
>     >>> on this list a few weeks ago, but there was not any interest in
>     >>> investigating the issue.
>     >>>
>     >>> So now I use jpackage to just create the application image,
>     and then
>     >>> separately use WiX directly to create an installer that can
>     properly
>     >>> upgrade older installations. You can find the GitHub Actions
>     workflow that
>     >>> drives the process here:
>     >>>
>     >>>
>     https://github.com/Deep-Symmetry/beat-link-trigger/blob/master/.github/workflows/uberjar.yml#L84-L144
>     <https://urldefense.com/v3/__https://github.com/Deep-Symmetry/beat-link-trigger/blob/master/.github/workflows/uberjar.yml*L84-L144__;Iw!!GqivPVa7Brio!LYzdLFh5v8DMnAKHvh4rZHAApveVQIcLFDgeEisOIhEJ4otLO9CwsNXryAngS7-AM7YV$>
>     >>> <
>     >>>
>     https://github.com/Deep-Symmetry/beat-link-trigger/blob/master/.github/workflows/uberjar.yml#L84-L144
>     <https://urldefense.com/v3/__https://github.com/Deep-Symmetry/beat-link-trigger/blob/master/.github/workflows/uberjar.yml*L84-L144__;Iw!!GqivPVa7Brio!LYzdLFh5v8DMnAKHvh4rZHAApveVQIcLFDgeEisOIhEJ4otLO9CwsNXryAngS7-AM7YV$>
>     >>> The PowerShell script that runs jpackage and WiX is here:
>     >>>
>     >>>
>     https://github.com/Deep-Symmetry/beat-link-trigger/blob/master/.github/scripts/build_msi.ps1
>     <https://urldefense.com/v3/__https://github.com/Deep-Symmetry/beat-link-trigger/blob/master/.github/scripts/build_msi.ps1__;!!GqivPVa7Brio!LYzdLFh5v8DMnAKHvh4rZHAApveVQIcLFDgeEisOIhEJ4otLO9CwsNXryAngS2PBkRF4$>
>     >>> <
>     >>>
>     https://github.com/Deep-Symmetry/beat-link-trigger/blob/master/.github/scripts/build_msi.ps1
>     <https://urldefense.com/v3/__https://github.com/Deep-Symmetry/beat-link-trigger/blob/master/.github/scripts/build_msi.ps1__;!!GqivPVa7Brio!LYzdLFh5v8DMnAKHvh4rZHAApveVQIcLFDgeEisOIhEJ4otLO9CwsNXryAngS2PBkRF4$>
>     >>> And the WIX template it uses is here:
>     >>>
>     >>>
>     https://github.com/Deep-Symmetry/beat-link-trigger/blob/master/.github/resources/MSI%20Template.wxs
>     <https://urldefense.com/v3/__https://github.com/Deep-Symmetry/beat-link-trigger/blob/master/.github/resources/MSI*20Template.wxs__;JQ!!GqivPVa7Brio!LYzdLFh5v8DMnAKHvh4rZHAApveVQIcLFDgeEisOIhEJ4otLO9CwsNXryAngS2imkvmE$>
>     >>> <
>     >>>
>     https://github.com/Deep-Symmetry/beat-link-trigger/blob/master/.github/resources/MSI%20Template.wxs
>     <https://urldefense.com/v3/__https://github.com/Deep-Symmetry/beat-link-trigger/blob/master/.github/resources/MSI*20Template.wxs__;JQ!!GqivPVa7Brio!LYzdLFh5v8DMnAKHvh4rZHAApveVQIcLFDgeEisOIhEJ4otLO9CwsNXryAngS2imkvmE$>
>     >>> Hopefully this can help you, and perhaps jpackage can be
>     updated to do
>     >>> this on its own as well.
>     >>>
>     >>> Cheers,
>     >>>
>     >>>? ? ? ? ? -James
>     >>>
>


From naoto at openjdk.java.net  Wed Oct 28 20:05:46 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 28 Oct 2020 20:05:46 GMT
Subject: Integrated: 8255533: Incorrect javadoc in
 DateTimeFormatterBuilder.appendPattern() for 'uu'/'yy'
In-Reply-To: <k7ADQrfpo4r_1r8-r5GPNIu0maVDzqen-8naxdUjjeg=.122298df-6124-446d-9253-1056a5fd0352@github.com>
References: <k7ADQrfpo4r_1r8-r5GPNIu0maVDzqen-8naxdUjjeg=.122298df-6124-446d-9253-1056a5fd0352@github.com>
Message-ID: <XR91mbPRaa-8Xn58SRjgwi5Mi3aFOVyZQZ_4QyT-HqE=.db0a0d2a-2f35-4864-aa11-dce1269e2677@github.com>

On Wed, 28 Oct 2020 17:35:16 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Hi,
> 
> Please review this simple doc fix in DateTimeFormatterBuilder.appendPattern(). It is missing the value for `maxWidth` argument.
> 
> Naoto

This pull request has now been integrated.

Changeset: 790d6e2d
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/790d6e2d
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8255533: Incorrect javadoc in DateTimeFormatterBuilder.appendPattern() for 'uu'/'yy'

Reviewed-by: lancea, rriggs

-------------

PR: https://git.openjdk.java.net/jdk/pull/908

From github.com+828220+forax at openjdk.java.net  Wed Oct 28 20:15:44 2020
From: github.com+828220+forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Wed, 28 Oct 2020 20:15:44 GMT
Subject: RFR: 8159746: (proxy) Support for default methods
In-Reply-To: <mthe4gxs2yOuXitvRF4Cwzbk4LLamGCDlxTaQJdRo_g=.edaa421c-e144-4466-a07f-251da9357364@github.com>
References: <kw2VXh3vTFf1zgfd4biXA41OKffZ5oU7KT23tXAxgUA=.bcf14ffc-4dba-4c9c-8754-184172c5acbd@github.com>
 <U-6RiCpFVIrhLztPN6opiPcpFtxValDzU-K7WWFZM-4=.6bc8aaa4-636a-4664-b380-4c4af00513bd@github.com>
 <-cLIJ8pFHtnNoJMHV3aXI7XMJWp4Jrutc8Xn5PG0OK8=.d2cd87ab-3592-4524-ad85-05444c43689b@github.com>
 <r0UK2qjnmgeTNDDSWaSLPAj3QRgx_4YB82ielllO7jM=.fa615bc0-db49-4a74-b842-793f8f5209bb@github.com>
 <1T8kXDZN1bhHr4c8v4SQsImeBySCqTfX-u3_jzvyocA=.b4957400-9a33-4b6e-8475-329642a5888c@github.com>
 <XIux-dY0JXHRafHk48kVNXId9r-HSceNSytBojDxelY=.872e74cb-b064-406e-b71f-13c90ec7fbbc@github.com>
 <j4t2vT0SnwnU7lhKRlXtk967d-K6nA0EqHrqNbba7W0=.dc05dba6-bf7e-4606-8a02-9c2bad4b3b58@github.com>
 <fmVtPcBdgMuZOPm2qx3Q3znVZM7JgQPkhPAVLtwkOhE=.2d8b8447-cfae-4cb3-9a7c-6567a881231f@github.com>
 <GSeWP29fAIUFSk0CYsC557w52CuLqeUWwHNK9maltwI=.3d5f002e-6b74-4a57-a5d8-244d27da9dde@github.com>
 <GF8iEOkMUEL2dYB0HytFIc9gyeeUJ_KP0ImlqFsul2Y=.894afc05-9310-43e1-a308-8f7d71dc572b@github.com>
 <HvtDex3cmiv7XeTMITOroYfu74amSGQavQ_
 BAmVzmXw=.223be989-7c20-4ba4-ac0d-013d2b75a8cb@github.com>
 <IqRiLphFPBpGiKAnMJXqxjie9YeZ03rcE-qG1s92BLw=.d4fd5e92-5067-40df-8a0b-1dfd3d6e23af@github.com>
 <Y0hE51G3YefI6NY1O_E6VoZSKwxE78S1hv6fEatmOG8=.0a2c686c-d9ad-418c-8c1b-49addb8a54b1@github.com>
 <QrNk57L2PWQhJjzYiGTsvYyGIPAfK7bP_kANtTR-2uM=.3e5ce990-f8ea-4751-8147-27a8a9dad40d@github.com>
 <9JNNUzfV3PSvKtSg2a_zyYJmgEn3sZL9cb5sfqemk2o=.f1ef7fb7-bdd5-44ed-98c8-59213e9094f9@github.com>
 <zWGhaC8YB5I0XgffiR7o_YT5gSp9Gbj8Drtt23brl-c=.1e59f0e4-bbe3-4fb2-94dc-c55fc862f091@github.com>
 <LljojgqBhEi6tFptsbmu1jS-Xx7lYEXm9tRkkPqDGzE=.3d7d6a37-1042-4539-88d1-9f4cf5378128@github.com>
 <Gn33ydZNxqOpWUrmYiWJadMF0mukI2MR85EtgrV4D1I=.958521f2-1167-4a68-b513-e10bba37ae18@github.com>
 <NMXKaHql9XjndqPgyoN1Lasa9H8ugl8-ltD1j2XiT9Y=.3ff8871e-0f9d-40ea-8f35-e804a9afcbd5@github.com>
 <yzFe02HJ2qt5tT8tY9ZOofnKld93x1PM5U7AToTABJs=.439c213b-94b9-488f-bb6d-a835a86c527f@github.com>
 <BoATjx7PPcLpINJVC5HM77UKMriIUqnnhcBowkJRlvM=.1221e3e1-ed27-4618-8365-dcd903d27f60@
 github.com>
 <yN0JJE9mBkqz9Ijbw4FYinv08tcnxiZHAGyarXBF9CY=.50429cb9-181a-447e-90a0-e0a0a836812e@github.com>
 <CoqZRJ39DVdNI9wzS372aAG3ZIB7hrIrndaO5VrsmBA=.f78629d2-3409-44c1-9e66-7951bbd630e6@github.com>
 <W6qIb_NPGRUpQd_obRiIumwbXSTDheSdg-qnkc3cZ90=.f1f46290-3b7c-4e88-994f-5d19e0134256@github.com>
 <nALY_XHf4_MGKZHIzpIRbqLEG22ySg0NZ8mQbun7up0=.69d14612-31a4-4533-924c-01768ed50be1@github.com>
 <dWu0mcInZ8duRgGoQRfdgKXASYodtIhqgoejf-weUek=.eec68bf3-1a34-4f4b-82ca-6be48caeff1c@github.com>
 <S-gpV6ntV3fkkjzvU8PYpAWAJVWpvdykReMXyRVwd9U=.0893dd0d-55d0-49c1-9bb9-883005fed496@github.com>
 <VE9aWCMrcLW5QIl0wRpGppb0gObfI0cfbg0DnuKRfSs=.e398df44-4b64-465a-9697-8b4d2ed1652d@github.com>
 <50_1vC3yErplQgnnTNJHpF-d0ibuMKtRa9kg3jGKymc=.978abc22-8b04-49ed-b950-7bafe2b1931a@github.com>
 <3_3xp4MbiLH-_9zyTkLVKZKP3ds0AftAVtbWo8tYeFs=.483fa478-0e33-495d-a545-b2339ecee592@github.com>
 <X93bQ76ydubQKGZAlD4ub43vTBHXjwnXQx--UN5xgus=.5e2ddf9d-86a5-4c34-b53a-65daff1d43df@github.com>
 <mthe4gxs2yOuXitvRF4Cwzbk4LLamGCDlx
 TaQJdRo_g=.edaa421c-e144-4466-a07f-251da9357364@github.com>
Message-ID: <LrmZFLofpx4ewPC-GKlK9Z3xjIi4PrFLpOUL8qz6SJg=.ce86cf0c-c579-4d26-b68f-29b656ab78d3@github.com>

On Wed, 28 Oct 2020 19:28:36 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Hi Mandy and Peter,
>> reading your exchanges, i wonder if it's not better to stop trying to add more and more features to the already clunky java.lang.reflect.Proxy but instead to move to provide the same set of feature but using an implementation based on java.lang.invoke.Lookup/MethodHandle.
>> 
>> I propose to introduce a java.lang.invoke.Proxy has a replacement of java.lang.reflect.Proxy using j.l.i.MethodHandle instead of j.l.r.Method, the equivalent of the InvocationHandler acting as a linker called once per the first time a method of the Proxy is called instead of being called each time a method is called.
>> 
>> Such proxy
>> - has it's security model based on Lookup to define the class,
>>   so no supplementary restrictions on package/module of the interface implemented
>> - avoid to mix java.lang.reflect API and java.invoke API
>> - is transparent in term of exceptions (ther are propagated without any wrapping/unwrapping)
>> - can support default methods natively
>> - doesn't requires any caching (the user will be responsible to do the caching)
>> - is more efficient, actually as efficient as the equivalent written code or a little more (thanks to @ForceInline)
>
> Hi Remi,
> 
> I appreciate your proposal to modernize Proxy API.   There are several requests for this enhancement to support default methods in Proxy.   Defining a new `java.lang.invoke.Proxy` is a much bigger project that I can't tell when the existing users of `java.lang.reflect.Proxy` will be able to get this default method invocation support.  
> 
> I do agree that this API design has many challenges caused by what you listed above.   Well, I believe we are very close to have a consensus:
> 1. New `newProxyInstance` factory method takes a handler factory doing the access check
> 2. Update `getInvocationHandler` to throw `InaccessibleInvocationHandlerException` if access denied to get an invocation handler associated with the proxy instance
> 
> If this needs more time, I think I will consider to shelf this RFE and come back to it later (and consider your proposal as well).

The trick is that if we know that a class like java.lang.invoke.Proxy may exist,
it means that instead of distorting the j.l.r.Proxy API to increase of few percents the performance when calling a default method, you can come with a simpler design in term of API that just add an API point to call a default method.

Better performance becoming on the the goals of java.lang.invoke.Proxy.

-------------

PR: https://git.openjdk.java.net/jdk/pull/313

From ecaspole at openjdk.java.net  Wed Oct 28 21:00:52 2020
From: ecaspole at openjdk.java.net (Eric Caspole)
Date: Wed, 28 Oct 2020 21:00:52 GMT
Subject: RFR: 8250669: Running JMH micros is broken after JDK-8248135
In-Reply-To: <wTNixdnJIFZBmigjAKeA1ut2uQKmSII-1ZU2Kx5hFLg=.ee2ab15a-15ef-4f39-862c-7e138c7506a5@github.com>
References: <wTNixdnJIFZBmigjAKeA1ut2uQKmSII-1ZU2Kx5hFLg=.ee2ab15a-15ef-4f39-862c-7e138c7506a5@github.com>
Message-ID: <7ujMMngqgUMpCP-QHWyGs2HsfOoTQQ1L5F8CbWNMPZM=.c71f32dc-7c4d-4864-b6f2-461c93d34132@github.com>

On Wed, 28 Oct 2020 20:50:49 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> A microbenchmark with --enable-preview was added in JDK-8248135. This had the unintended side effect that we now had to always run with --enable-preview. 
> 
> With records out of preview, I think the best course of action now is to not build the micros with preview enabled, and leave it for a future RFE to figure out how to add proper support for preview features.

Looks good and thanks for doing this as soon as practical.
Eric

-------------

Marked as reviewed by ecaspole (Committer).

PR: https://git.openjdk.java.net/jdk/pull/914

From redestad at openjdk.java.net  Wed Oct 28 21:00:51 2020
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 28 Oct 2020 21:00:51 GMT
Subject: RFR: 8250669: Running JMH micros is broken after JDK-8248135
Message-ID: <wTNixdnJIFZBmigjAKeA1ut2uQKmSII-1ZU2Kx5hFLg=.ee2ab15a-15ef-4f39-862c-7e138c7506a5@github.com>

A microbenchmark with --enable-preview was added in JDK-8248135. This had the unintended side effect that we now had to always run with --enable-preview. 

With records out of preview, I think the best course of action now is to not build the micros with preview enabled, and leave it for a future RFE to figure out how to add proper support for preview features.

-------------

Commit messages:
 - Drop --enable-preview from microbenchmarks

Changes: https://git.openjdk.java.net/jdk/pull/914/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=914&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8250669
  Stats: 3 lines in 2 files changed: 0 ins; 1 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/914.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/914/head:pull/914

PR: https://git.openjdk.java.net/jdk/pull/914

From weijun at openjdk.java.net  Wed Oct 28 21:01:52 2020
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 28 Oct 2020 21:01:52 GMT
Subject: RFR: 8255536: Remove the directsign property and option
Message-ID: <J0ZmAMQoBwstdg8kJHeEA8vlZW-31Juznbu50JJJDug=.b3f521db-d61b-444a-8343-03f89a581655@github.com>

I regret adding the `directsign` property/option to JarSigner/jarsigner. See the bug for details.

-------------

Commit messages:
 - 8255536: Remove the directsign property and option

Changes: https://git.openjdk.java.net/jdk/pull/915/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=915&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8255536
  Stats: 184 lines in 7 files changed: 14 ins; 162 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/915.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/915/head:pull/915

PR: https://git.openjdk.java.net/jdk/pull/915

From github.com+70893615+jasontatton-aws at openjdk.java.net  Wed Oct 28 22:06:50 2020
From: github.com+70893615+jasontatton-aws at openjdk.java.net (Jason Tatton)
Date: Wed, 28 Oct 2020 22:06:50 GMT
Subject: RFR: 8254782: Fix benchmark issues in
 java/lang/StringIndexOfChar.java benchmark
Message-ID: <mZTWui0sO-rBz965bS_AHmIVGrV93nn5EBSGnKwihp0=.733a58ac-e3b8-4945-be1a-493377de5207@github.com>

Please review the improvements which I have made to the java/lang/StringIndexOfChar.java jmh benchmark. Please let me know if any further improvements are required.

Thanks,
Jason

-------------

Commit messages:
 - 8254782

Changes: https://git.openjdk.java.net/jdk/pull/918/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=918&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8254782
  Stats: 48 lines in 1 file changed: 28 ins; 0 del; 20 mod
  Patch: https://git.openjdk.java.net/jdk/pull/918.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/918/head:pull/918

PR: https://git.openjdk.java.net/jdk/pull/918

From redestad at openjdk.java.net  Wed Oct 28 22:40:47 2020
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 28 Oct 2020 22:40:47 GMT
Subject: RFR: 8250669: Running JMH micros is broken after JDK-8248135
In-Reply-To: <7ujMMngqgUMpCP-QHWyGs2HsfOoTQQ1L5F8CbWNMPZM=.c71f32dc-7c4d-4864-b6f2-461c93d34132@github.com>
References: <wTNixdnJIFZBmigjAKeA1ut2uQKmSII-1ZU2Kx5hFLg=.ee2ab15a-15ef-4f39-862c-7e138c7506a5@github.com>
 <7ujMMngqgUMpCP-QHWyGs2HsfOoTQQ1L5F8CbWNMPZM=.c71f32dc-7c4d-4864-b6f2-461c93d34132@github.com>
Message-ID: <_swsE_nCN4lIy8F4qlLRTPKerAC6cXvdhdN7lSP0e9k=.028dfd89-7fbd-41b8-96df-6d930b958c6f@github.com>

On Wed, 28 Oct 2020 20:56:55 GMT, Eric Caspole <ecaspole at openjdk.org> wrote:

>> A microbenchmark with --enable-preview was added in JDK-8248135. This had the unintended side effect that we now had to always run with --enable-preview. 
>> 
>> With records out of preview, I think the best course of action now is to not build the micros with preview enabled, and leave it for a future RFE to figure out how to add proper support for preview features.
>
> Looks good and thanks for doing this as soon as practical.
> Eric

@ericcaspole, @erikj79, thanks for reviewing!

-------------

PR: https://git.openjdk.java.net/jdk/pull/914

From erikj at openjdk.java.net  Wed Oct 28 22:40:47 2020
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Wed, 28 Oct 2020 22:40:47 GMT
Subject: RFR: 8250669: Running JMH micros is broken after JDK-8248135
In-Reply-To: <wTNixdnJIFZBmigjAKeA1ut2uQKmSII-1ZU2Kx5hFLg=.ee2ab15a-15ef-4f39-862c-7e138c7506a5@github.com>
References: <wTNixdnJIFZBmigjAKeA1ut2uQKmSII-1ZU2Kx5hFLg=.ee2ab15a-15ef-4f39-862c-7e138c7506a5@github.com>
Message-ID: <Bl9FhPYNW31PkI8q2ADd8VMKNoKHTSarXHArWv9TXPw=.70baa896-a8c7-4e5a-85ae-3ecb593835a9@github.com>

On Wed, 28 Oct 2020 20:50:49 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> A microbenchmark with --enable-preview was added in JDK-8248135. This had the unintended side effect that we now had to always run with --enable-preview. 
> 
> With records out of preview, I think the best course of action now is to not build the micros with preview enabled, and leave it for a future RFE to figure out how to add proper support for preview features.

Marked as reviewed by erikj (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/914

From redestad at openjdk.java.net  Wed Oct 28 22:40:48 2020
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 28 Oct 2020 22:40:48 GMT
Subject: Integrated: 8250669: Running JMH micros is broken after JDK-8248135
In-Reply-To: <wTNixdnJIFZBmigjAKeA1ut2uQKmSII-1ZU2Kx5hFLg=.ee2ab15a-15ef-4f39-862c-7e138c7506a5@github.com>
References: <wTNixdnJIFZBmigjAKeA1ut2uQKmSII-1ZU2Kx5hFLg=.ee2ab15a-15ef-4f39-862c-7e138c7506a5@github.com>
Message-ID: <iYFa0BJQJyeLExzAWJ1Q6XWRHm_OBcKy76R0D00TI5I=.f903abff-1699-444d-a103-ac0f7234d187@github.com>

On Wed, 28 Oct 2020 20:50:49 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> A microbenchmark with --enable-preview was added in JDK-8248135. This had the unintended side effect that we now had to always run with --enable-preview. 
> 
> With records out of preview, I think the best course of action now is to not build the micros with preview enabled, and leave it for a future RFE to figure out how to add proper support for preview features.

This pull request has now been integrated.

Changeset: a7595b2a
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a7595b2a
Stats:     3 lines in 2 files changed: 0 ins; 1 del; 2 mod

8250669: Running JMH micros is broken after JDK-8248135

Reviewed-by: ecaspole, erikj

-------------

PR: https://git.openjdk.java.net/jdk/pull/914

From redestad at openjdk.java.net  Wed Oct 28 22:52:49 2020
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 28 Oct 2020 22:52:49 GMT
Subject: RFR: 8254782: Fix benchmark issues in
 java/lang/StringIndexOfChar.java benchmark
In-Reply-To: <mZTWui0sO-rBz965bS_AHmIVGrV93nn5EBSGnKwihp0=.733a58ac-e3b8-4945-be1a-493377de5207@github.com>
References: <mZTWui0sO-rBz965bS_AHmIVGrV93nn5EBSGnKwihp0=.733a58ac-e3b8-4945-be1a-493377de5207@github.com>
Message-ID: <HUgxI3o3Ocd-rlos6KJF8SwF3WPv5feN0bgVhTO5t-E=.5eecb41c-cfce-46dd-94cf-6f0bcc8356d1@github.com>

On Wed, 28 Oct 2020 21:59:53 GMT, Jason Tatton <github.com+70893615+jasontatton-aws at openjdk.org> wrote:

> Please review the improvements which I have made to the java/lang/StringIndexOfChar.java jmh benchmark. Please let me know if any further improvements are required.
> 
> Thanks,
> Jason

Looks OK.

FWIW the current looping scheme look like what the [SafeLooping.measureWrong_2](https://github.com/openjdk/jmh/blob/620036ec27db3503fa2dee476036b3219c9a38bc/jmh-samples/src/main/java/org/openjdk/jmh/samples/JMHSample_34_SafeLooping.java#L115) warns us about, and could possibly be improved by taking cues from [SafeLooping.measureRight_1](https://github.com/openjdk/jmh/blob/620036ec27db3503fa2dee476036b3219c9a38bc/jmh-samples/src/main/java/org/openjdk/jmh/samples/JMHSample_34_SafeLooping.java#L136) and sink each `what.indexOf(..)` into a `BlackHole`. This might matter here since each unit of work is quite small. 

I'll approve the patch as-is, but please consider making those changes.

test/micro/org/openjdk/bench/java/lang/StringIndexOfChar.java line 63:

> 61:     private String [] utf16_sse4;
> 62:     private String [] utf16_avx2;
> 63:     private String [] utf16_mixedLength;

I'd be a little bit happier with `String[]` rather than `String []`

-------------

Marked as reviewed by redestad (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/918

From github.com+70893615+jasontatton-aws at openjdk.java.net  Thu Oct 29 00:59:56 2020
From: github.com+70893615+jasontatton-aws at openjdk.java.net (Jason Tatton)
Date: Thu, 29 Oct 2020 00:59:56 GMT
Subject: RFR: 8254782: Fix benchmark issues in
 java/lang/StringIndexOfChar.java benchmark [v2]
In-Reply-To: <mZTWui0sO-rBz965bS_AHmIVGrV93nn5EBSGnKwihp0=.733a58ac-e3b8-4945-be1a-493377de5207@github.com>
References: <mZTWui0sO-rBz965bS_AHmIVGrV93nn5EBSGnKwihp0=.733a58ac-e3b8-4945-be1a-493377de5207@github.com>
Message-ID: <MKCLK58eW3gw06S_NwxEUs3PdCem7-AKFvte-b9F6ks=.24d526d2-9d8f-4d77-a948-4e740b90750f@github.com>

> Please review the improvements which I have made to the java/lang/StringIndexOfChar.java jmh benchmark. Please let me know if any further improvements are required.
> 
> Thanks,
> Jason

Jason Tatton has updated the pull request incrementally with one additional commit since the last revision:

  Adjusted benchmark to use BlackHole and improved String array syntax as advised

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/918/files
  - new: https://git.openjdk.java.net/jdk/pull/918/files/5f3a1ce7..07485356

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=918&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=918&range=00-01

  Stats: 73 lines in 1 file changed: 1 ins; 32 del; 40 mod
  Patch: https://git.openjdk.java.net/jdk/pull/918.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/918/head:pull/918

PR: https://git.openjdk.java.net/jdk/pull/918

From github.com+70893615+jasontatton-aws at openjdk.java.net  Thu Oct 29 00:59:57 2020
From: github.com+70893615+jasontatton-aws at openjdk.java.net (Jason Tatton)
Date: Thu, 29 Oct 2020 00:59:57 GMT
Subject: RFR: 8254782: Fix benchmark issues in
 java/lang/StringIndexOfChar.java benchmark [v2]
In-Reply-To: <HUgxI3o3Ocd-rlos6KJF8SwF3WPv5feN0bgVhTO5t-E=.5eecb41c-cfce-46dd-94cf-6f0bcc8356d1@github.com>
References: <mZTWui0sO-rBz965bS_AHmIVGrV93nn5EBSGnKwihp0=.733a58ac-e3b8-4945-be1a-493377de5207@github.com>
 <HUgxI3o3Ocd-rlos6KJF8SwF3WPv5feN0bgVhTO5t-E=.5eecb41c-cfce-46dd-94cf-6f0bcc8356d1@github.com>
Message-ID: <CT8Yv3B9d4-cWjVKcakgQaaGTFe-lWT91cy__tGehUo=.95ba0efa-f6e9-420b-a75e-eeb375d92e3f@github.com>

On Wed, 28 Oct 2020 22:44:37 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Jason Tatton has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adjusted benchmark to use BlackHole and improved String array syntax as advised
>
> test/micro/org/openjdk/bench/java/lang/StringIndexOfChar.java line 63:
> 
>> 61:     private String [] utf16_sse4;
>> 62:     private String [] utf16_avx2;
>> 63:     private String [] utf16_mixedLength;
> 
> I'd be a little bit happier with `String[]` rather than `String []`

Thanks Claes, I have made the modifications as advised

-------------

PR: https://git.openjdk.java.net/jdk/pull/918

From shade at openjdk.java.net  Thu Oct 29 06:32:49 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 29 Oct 2020 06:32:49 GMT
Subject: RFR: 8254782: Fix benchmark issues in
 java/lang/StringIndexOfChar.java benchmark [v2]
In-Reply-To: <MKCLK58eW3gw06S_NwxEUs3PdCem7-AKFvte-b9F6ks=.24d526d2-9d8f-4d77-a948-4e740b90750f@github.com>
References: <mZTWui0sO-rBz965bS_AHmIVGrV93nn5EBSGnKwihp0=.733a58ac-e3b8-4945-be1a-493377de5207@github.com>
 <MKCLK58eW3gw06S_NwxEUs3PdCem7-AKFvte-b9F6ks=.24d526d2-9d8f-4d77-a948-4e740b90750f@github.com>
Message-ID: <8UjjJVmwPJoglyx9EGcF6WMKy1Ddjyol4HLyr90U94c=.e7ed5142-e53a-403d-ad70-d1f5e35453d5@github.com>

On Thu, 29 Oct 2020 00:59:56 GMT, Jason Tatton <github.com+70893615+jasontatton-aws at openjdk.org> wrote:

>> Please review the improvements which I have made to the java/lang/StringIndexOfChar.java jmh benchmark. Please let me know if any further improvements are required.
>> 
>> Thanks,
>> Jason
>
> Jason Tatton has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjusted benchmark to use BlackHole and improved String array syntax as advised

Looks fine to me, thanks.

-------------

Marked as reviewed by shade (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/918

From redestad at openjdk.java.net  Thu Oct 29 07:08:43 2020
From: redestad at openjdk.java.net (Claes Redestad)
Date: Thu, 29 Oct 2020 07:08:43 GMT
Subject: RFR: 8254782: Fix benchmark issues in
 java/lang/StringIndexOfChar.java benchmark [v2]
In-Reply-To: <MKCLK58eW3gw06S_NwxEUs3PdCem7-AKFvte-b9F6ks=.24d526d2-9d8f-4d77-a948-4e740b90750f@github.com>
References: <mZTWui0sO-rBz965bS_AHmIVGrV93nn5EBSGnKwihp0=.733a58ac-e3b8-4945-be1a-493377de5207@github.com>
 <MKCLK58eW3gw06S_NwxEUs3PdCem7-AKFvte-b9F6ks=.24d526d2-9d8f-4d77-a948-4e740b90750f@github.com>
Message-ID: <VJqhUdTzcCGd012j1ddsUp6k-le8o1cMOfqICVzep1s=.597b8ee2-b3f7-4307-8601-147401ac6842@github.com>

On Thu, 29 Oct 2020 00:59:56 GMT, Jason Tatton <github.com+70893615+jasontatton-aws at openjdk.org> wrote:

>> Please review the improvements which I have made to the java/lang/StringIndexOfChar.java jmh benchmark. Please let me know if any further improvements are required.
>> 
>> Thanks,
>> Jason
>
> Jason Tatton has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjusted benchmark to use BlackHole and improved String array syntax as advised

Marked as reviewed by redestad (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/918

From daniel.peintner at gmail.com  Thu Oct 29 09:21:55 2020
From: daniel.peintner at gmail.com (Daniel Peintner)
Date: Thu, 29 Oct 2020 10:21:55 +0100
Subject: [jpackage] Issue with upgrading from javapackager to jpackage on
 Windows
In-Reply-To: <a83c8ff4-a791-6e63-0616-8d057426f02b@oracle.com>
References: <mailman.5881.1581956828.14600.core-libs-dev@openjdk.java.net>
 <02102893-DD43-4626-9F39-DBBD1A71975C@deepsymmetry.org>
 <CAAoP7T7VT1ewQiNsb6SG00jrwRX1yX93v7moBEVwMUHoU4HmTA@mail.gmail.com>
 <CAAoP7T7YCvc2bnOUqLNnw22FJXV26BNGW+ceA3ptNjg_rFDXtg@mail.gmail.com>
 <d25818fa-d4af-5906-df7e-a6c4ff0e8b8b@oracle.com>
 <CAAoP7T4UBLatfAneSv-VN06cG6w4SVeS+FfEqJBP8sSmqdaxQw@mail.gmail.com>
 <a83c8ff4-a791-6e63-0616-8d057426f02b@oracle.com>
Message-ID: <CAAoP7T5WZz9QX1NWf+69XGENsEkU2MAY637Mn15omxwBemae-A@mail.gmail.com>

Alexey, all,

Thanks for keeping me updated.
I agree with the statement that a full fledged procedure for updates is out
of scope for jpackage.

Note:  It is mentioned that <Upgrade Id="$(var.AppUpgradeCode)" /> has been
added also in the meantime.
I did try it out with JDK-16-ea+21 and my application but the issue still
persists (but different: user gets error dialog mentioning jre cannot be
found).
Hence a user needs to manually uninstall the "old" application before being
able to run the new installer.

Thanks a lot anyway,

-- Daniel


On Wed, Oct 28, 2020 at 8:59 PM Alexey Semenyuk <alexey.semenyuk at oracle.com>
wrote:

> Daniel,
>
> https://bugs.openjdk.java.net/browse/JDK-8240111 has been updated with
> the evaluation of your request. Please take a look.
>
> - Alexey
>
> On 2/27/2020 2:00 AM, Daniel Peintner wrote:
>
> Alexey, all,
>
> In my case the update, as described, seems to work just fine. However once
> I try to actually start the application nothing happens. It silently fails.
>
> Could this be a reason why you don't encounter any issue? Just an idea
> though...
>
> -- Daniel
>
>
> Alexey Semenyuk <alexey.semenyuk at oracle.com> schrieb am Mi., 26. Feb.
> 2020, 22:56:
>
>> Daniel,
>>
>> Interesting. We have jtreg tests for testing upgrade scenarios on
>> Windows and they work without Upgrade element in WiX template.
>>
>> - Alexey
>>
>> On 2/26/2020 11:10 AM, Daniel Peintner wrote:
>> > All,
>> >
>> > after some private discussions with James and @Kevinnns I believe the
>> > necessary change to let upgrades succeed is rather minimal.
>> >
>> > The WIX template jpackage uses
>> >
>> > <Product Id="*" Name="$(var.AppName)" Language="1033"
>> > Version="$(var.AppVersion)" Manufacturer="$(var.AppVendor)"
>> > UpgradeCode="$(var.AppUpgradeCode)">
>> >
>> > needs to have
>> >
>> > <Upgrade Id="$(var.AppUpgradeCode)" />
>> >
>> > as well within the product element.
>> >
>> > I wonder whether anyone in the jpackage team is willing to work or look
>> > into this proposed change. Or does this cause any other issue I am not
>> > aware of?
>> >
>> > As said, I think this would be a big help for anyone coming from the
>> *old*
>> > javapackager tool.
>> >
>> > Thanks,
>> >
>> > -- Daniel
>> >
>> >
>> >
>> >
>> >
>> >
>> > On Tue, Feb 25, 2020 at 4:30 PM Daniel Peintner <
>> daniel.peintner at gmail.com>
>> > wrote:
>> >
>> >> Hi James, all,
>> >>
>> >> Thank you for your feedback.
>> >>
>> >> I did try around and I think there is a jpackage upgrade ID option now.
>> >>
>> >> --win-upgrade-uuid <string> ? UUID associated with upgrades for this
>> >> package
>> >>
>> >> In my case though, I think I run into some other issues. The InnoSetup
>> >> installer seems not to provide any UUID.
>> >>
>> >> I believe I also found a related issue [1] that mentions UUID and
>> >> InnoSetup but unfortunately that didn't help me either.
>> >>
>> >> Thanks again for any help,
>> >>
>> >> -- Daniel
>> >>
>> >> [1] https://bugs.openjdk.java.net/browse/JDK-8214564
>> >>
>> >>
>> >>
>> >> On Mon, Feb 17, 2020 at 5:38 PM James Elliott <james at deepsymmetry.org>
>> >> wrote:
>> >>
>> >>> Sorry, tried sending this with the incorrect email personality first.
>> >>>
>> >>> On Mon, 17 Feb 2020 15:32:14 +0100 Daniel Peintner <
>> >>> daniel.peintner at gmail.com <mailto:daniel.peintner at gmail.com>> wrote:
>> >>>> The only *working* solution we found was to *manually* uninstall the
>> old
>> >>>> application before starting msi installer.
>> >>>> Any future update with msi installers work fine. But the first update
>> >>> fails!
>> >>>
>> >>> I had been previously manually creating WiX installers (with the help
>> of
>> >>> a script built by one of my Windows-based users), and he discovered
>> the
>> >>> same problem when I migrated to jpackage. It turns out that the
>> >>> jpackage-built WiX installers are missing an upgrade ID. I mentioned
>> that
>> >>> on this list a few weeks ago, but there was not any interest in
>> >>> investigating the issue.
>> >>>
>> >>> So now I use jpackage to just create the application image, and then
>> >>> separately use WiX directly to create an installer that can properly
>> >>> upgrade older installations. You can find the GitHub Actions workflow
>> that
>> >>> drives the process here:
>> >>>
>> >>>
>> https://github.com/Deep-Symmetry/beat-link-trigger/blob/master/.github/workflows/uberjar.yml#L84-L144
>> <https://urldefense.com/v3/__https://github.com/Deep-Symmetry/beat-link-trigger/blob/master/.github/workflows/uberjar.yml*L84-L144__;Iw!!GqivPVa7Brio!LYzdLFh5v8DMnAKHvh4rZHAApveVQIcLFDgeEisOIhEJ4otLO9CwsNXryAngS7-AM7YV$>
>> >>> <
>> >>>
>> https://github.com/Deep-Symmetry/beat-link-trigger/blob/master/.github/workflows/uberjar.yml#L84-L144
>> <https://urldefense.com/v3/__https://github.com/Deep-Symmetry/beat-link-trigger/blob/master/.github/workflows/uberjar.yml*L84-L144__;Iw!!GqivPVa7Brio!LYzdLFh5v8DMnAKHvh4rZHAApveVQIcLFDgeEisOIhEJ4otLO9CwsNXryAngS7-AM7YV$>
>> >>> The PowerShell script that runs jpackage and WiX is here:
>> >>>
>> >>>
>> https://github.com/Deep-Symmetry/beat-link-trigger/blob/master/.github/scripts/build_msi.ps1
>> <https://urldefense.com/v3/__https://github.com/Deep-Symmetry/beat-link-trigger/blob/master/.github/scripts/build_msi.ps1__;!!GqivPVa7Brio!LYzdLFh5v8DMnAKHvh4rZHAApveVQIcLFDgeEisOIhEJ4otLO9CwsNXryAngS2PBkRF4$>
>> >>> <
>> >>>
>> https://github.com/Deep-Symmetry/beat-link-trigger/blob/master/.github/scripts/build_msi.ps1
>> <https://urldefense.com/v3/__https://github.com/Deep-Symmetry/beat-link-trigger/blob/master/.github/scripts/build_msi.ps1__;!!GqivPVa7Brio!LYzdLFh5v8DMnAKHvh4rZHAApveVQIcLFDgeEisOIhEJ4otLO9CwsNXryAngS2PBkRF4$>
>> >>> And the WIX template it uses is here:
>> >>>
>> >>>
>> https://github.com/Deep-Symmetry/beat-link-trigger/blob/master/.github/resources/MSI%20Template.wxs
>> <https://urldefense.com/v3/__https://github.com/Deep-Symmetry/beat-link-trigger/blob/master/.github/resources/MSI*20Template.wxs__;JQ!!GqivPVa7Brio!LYzdLFh5v8DMnAKHvh4rZHAApveVQIcLFDgeEisOIhEJ4otLO9CwsNXryAngS2imkvmE$>
>> >>> <
>> >>>
>> https://github.com/Deep-Symmetry/beat-link-trigger/blob/master/.github/resources/MSI%20Template.wxs
>> <https://urldefense.com/v3/__https://github.com/Deep-Symmetry/beat-link-trigger/blob/master/.github/resources/MSI*20Template.wxs__;JQ!!GqivPVa7Brio!LYzdLFh5v8DMnAKHvh4rZHAApveVQIcLFDgeEisOIhEJ4otLO9CwsNXryAngS2imkvmE$>
>> >>> Hopefully this can help you, and perhaps jpackage can be updated to do
>> >>> this on its own as well.
>> >>>
>> >>> Cheers,
>> >>>
>> >>>          -James
>> >>>
>>
>>
>

From jlahoda at openjdk.java.net  Thu Oct 29 09:28:51 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Thu, 29 Oct 2020 09:28:51 GMT
Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12
 [v4]
In-Reply-To: <P6CERo1De3tix7TduT-Eh184-uAfYegth-i3neTAV1Y=.46960ac4-d027-4d59-a0b6-664819d1635f@github.com>
References: <RRMAPzh6xcVcxOj2S_VW_r50YvZz-3Imaj46bDi8e9U=.9347534e-d482-468a-8668-132d5516bb76@github.com>
 <DvuPT_pYUFWOCkxQnkIKxUpLqyBQYSzSDVwrqR7iz4c=.221543e2-f4ee-4e28-b7ee-80aa21a9e3a0@github.com>
 <P6CERo1De3tix7TduT-Eh184-uAfYegth-i3neTAV1Y=.46960ac4-d027-4d59-a0b6-664819d1635f@github.com>
Message-ID: <R2KYb4nzD1FZrz1hP4dXxn6a16GAAHCjlglZ6V6U45I=.b421488e-2f19-4511-8a71-c52f18dfe740@github.com>

On Fri, 23 Oct 2020 18:28:12 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removing unnecessary cast.
>
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/ElementsTable.java line 1288:
> 
>> 1286:                 case FIELD: case INSTANCE_INIT: case LOCAL_VARIABLE: case PARAMETER:
>> 1287:                 case RESOURCE_VARIABLE: case STATIC_INIT: case TYPE_PARAMETER:
>> 1288:                 case RECORD_COMPONENT:
> 
> I'm not saying this is wrong, but I'd like to understand why it is necessary.

HtmlDocletWriter.getPreviewNotes analyzes classes and their members, to see if some are using aspects that are under preview. When looking at the members, it uses utils.isIncluded on the member, and that eventually gets here. And if the member is a RECORD_COMPONENT, it would fail here. But we can avoid asking for RECORD_COMPONENTS, if needed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/703

From jlahoda at openjdk.java.net  Thu Oct 29 09:41:50 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Thu, 29 Oct 2020 09:41:50 GMT
Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12
 [v4]
In-Reply-To: <P6CERo1De3tix7TduT-Eh184-uAfYegth-i3neTAV1Y=.46960ac4-d027-4d59-a0b6-664819d1635f@github.com>
References: <RRMAPzh6xcVcxOj2S_VW_r50YvZz-3Imaj46bDi8e9U=.9347534e-d482-468a-8668-132d5516bb76@github.com>
 <DvuPT_pYUFWOCkxQnkIKxUpLqyBQYSzSDVwrqR7iz4c=.221543e2-f4ee-4e28-b7ee-80aa21a9e3a0@github.com>
 <P6CERo1De3tix7TduT-Eh184-uAfYegth-i3neTAV1Y=.46960ac4-d027-4d59-a0b6-664819d1635f@github.com>
Message-ID: <cqoCAEv9muR8KSaic8tUoemaqJqVfy0NOlrX4dQFq7M=.11746d6f-3667-4e24-9037-3d30601dd262@github.com>

On Fri, 23 Oct 2020 17:58:42 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removing unnecessary cast.
>
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Navigation.java line 228:
> 
>> 226:                 addTreeLink(tree);
>> 227:                 addDeprecatedLink(tree);
>> 228:                 addPreviewLink(tree);
> 
> It's OK to put the link here, I guess, but it should also be on the INDEX page.
> 
> See also recent updates for conditional pages.

I believe the link is in the navigation bar on all pages (as DEPRECATED is).

-------------

PR: https://git.openjdk.java.net/jdk/pull/703

From jlahoda at openjdk.java.net  Thu Oct 29 09:46:46 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Thu, 29 Oct 2020 09:46:46 GMT
Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12
 [v4]
In-Reply-To: <P6CERo1De3tix7TduT-Eh184-uAfYegth-i3neTAV1Y=.46960ac4-d027-4d59-a0b6-664819d1635f@github.com>
References: <RRMAPzh6xcVcxOj2S_VW_r50YvZz-3Imaj46bDi8e9U=.9347534e-d482-468a-8668-132d5516bb76@github.com>
 <DvuPT_pYUFWOCkxQnkIKxUpLqyBQYSzSDVwrqR7iz4c=.221543e2-f4ee-4e28-b7ee-80aa21a9e3a0@github.com>
 <P6CERo1De3tix7TduT-Eh184-uAfYegth-i3neTAV1Y=.46960ac4-d027-4d59-a0b6-664819d1635f@github.com>
Message-ID: <3izxrckqtdi9Hg7tV7-EUeIV0M7oqmMl3j802UTtFuM=.014127ae-6ca1-4309-91b7-a622e5fe89c4@github.com>

On Fri, 23 Oct 2020 18:19:13 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removing unnecessary cast.
>
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java line 2848:
> 
>> 2846:         UnknownInlineTagTree previewTag = (UnknownInlineTagTree) t;
>> 2847:         List<? extends DocTree> previewContent = previewTag.getContent();
>> 2848:         String previewText = ((TextTree) previewContent.get(0)).getBody();
> 
> This looks unreasonably fragile. And, I thought the tag was going away... at least according to earlier files in this review.

This was intended to allow Preview APIs to provide their own text instead of the generic one. But, looking again at JEP 12, this shouldn't be supported, so removing.

-------------

PR: https://git.openjdk.java.net/jdk/pull/703

From jlahoda at openjdk.java.net  Thu Oct 29 09:46:47 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Thu, 29 Oct 2020 09:46:47 GMT
Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12
 [v4]
In-Reply-To: <281-fNSKFfd-qngLAcLkMFdmKe-XHD-0qKCEh4OGvog=.82b534a0-e57a-41bf-ba94-e487601b2773@github.com>
References: <RRMAPzh6xcVcxOj2S_VW_r50YvZz-3Imaj46bDi8e9U=.9347534e-d482-468a-8668-132d5516bb76@github.com>
 <DvuPT_pYUFWOCkxQnkIKxUpLqyBQYSzSDVwrqR7iz4c=.221543e2-f4ee-4e28-b7ee-80aa21a9e3a0@github.com>
 <P6CERo1De3tix7TduT-Eh184-uAfYegth-i3neTAV1Y=.46960ac4-d027-4d59-a0b6-664819d1635f@github.com>
 <281-fNSKFfd-qngLAcLkMFdmKe-XHD-0qKCEh4OGvog=.82b534a0-e57a-41bf-ba94-e487601b2773@github.com>
Message-ID: <DrJrH40To0Fq7TDeDV6ni9sik4WVsH-5pk6zcBUkR3A=.4f2bdac5-7269-40d5-9ad2-e997e281f21a@github.com>

On Tue, 27 Oct 2020 16:11:18 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java line 2980:
>> 
>>> 2978:     }
>>> 2979: 
>>> 2980:     public enum DeclarationPreviewLanguageFeatures {
>> 
>> General thinking aloud question ... how does all this interact with source or release options for an earlier release?
>
> I don't think there should be much interaction with -source <older-version>. We don't support preview features from previous version or preview class files from previous versions, so I think it should be enough to handle the currently present preview features.

We don't support preview features from previous releases, AFAIK. So javadoc for JDK 16 should not accept e.g. record class when running with  -source 15.

-------------

PR: https://git.openjdk.java.net/jdk/pull/703

From github.com+70893615+jasontatton-aws at openjdk.java.net  Thu Oct 29 12:10:45 2020
From: github.com+70893615+jasontatton-aws at openjdk.java.net (Jason Tatton)
Date: Thu, 29 Oct 2020 12:10:45 GMT
Subject: Integrated: 8254782: Fix benchmark issues in
 java/lang/StringIndexOfChar.java benchmark
In-Reply-To: <mZTWui0sO-rBz965bS_AHmIVGrV93nn5EBSGnKwihp0=.733a58ac-e3b8-4945-be1a-493377de5207@github.com>
References: <mZTWui0sO-rBz965bS_AHmIVGrV93nn5EBSGnKwihp0=.733a58ac-e3b8-4945-be1a-493377de5207@github.com>
Message-ID: <0xjdJ-HKIe_JyKVS7Cn6mLLnxibc0CvTnm3YiPKGDiU=.79ef9d75-1467-4607-adb5-2f97c876eefa@github.com>

On Wed, 28 Oct 2020 21:59:53 GMT, Jason Tatton <github.com+70893615+jasontatton-aws at openjdk.org> wrote:

> Please review the improvements which I have made to the java/lang/StringIndexOfChar.java jmh benchmark. Please let me know if any further improvements are required.
> 
> Thanks,
> Jason

This pull request has now been integrated.

Changeset: 72ff8e21
Author:    jasontatton-aws <jptatton at amazon.com>
Committer: Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/72ff8e21
Stats:     92 lines in 1 file changed: 22 ins; 25 del; 45 mod

8254782: Fix benchmark issues in java/lang/StringIndexOfChar.java benchmark

Reviewed-by: redestad, shade

-------------

PR: https://git.openjdk.java.net/jdk/pull/918

From jlahoda at openjdk.java.net  Thu Oct 29 13:37:55 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Thu, 29 Oct 2020 13:37:55 GMT
Subject: RFR: 8250625: Compiler implementation of Pattern Matching for
 instanceof (Final) [v5]
In-Reply-To: <0uEby0-y3KVBLA1VxxdD5hCMlLhPCKB3w0mpihs9dsY=.181f22cd-7cf7-4941-b2d1-2ba4228d11d5@github.com>
References: <0uEby0-y3KVBLA1VxxdD5hCMlLhPCKB3w0mpihs9dsY=.181f22cd-7cf7-4941-b2d1-2ba4228d11d5@github.com>
Message-ID: <fORy9sxJ3pGeZ3pTdO1IL20-zyvS3c8ExTmRawoqMjs=.4808a5ec-37a5-4609-9139-62164234171c@github.com>

> This is the current proposed patch for the upcoming JEP 394, for pattern matching for instanceof.
> 
> A summary of changes:
> -making the feature permanent (non-preview)
> -making the binding variables non-final (as per current specification proposal)
> -producing a compile-time error for the case where the expression's type is a subtype of the type test pattern's type (as per current specification proposal)
> -changing the AST structure so that the binding variable has a VariableTree in the AST. BindingPatternTree is preserved and encloses the VariableTree. The reason is better consistency in the API, with nodes like CatchTree, EnhancedForLoop Tree, etc.
> 
> This change will not be integrated until JEP 394 is targetted.

Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits:

 - Merging master into patterns-instanceof3
 - Removing the preview deprecated methods from BindingPatternTree.
 - Merge branch 'master' into patterns-instanceof3
 - Fixing review comments.
 - Cleanup: using a null instead of List.of() as a parameter to JavaCompiler.getTask
 - Merge branch 'master' into patterns-instanceof3
 - Fixing more tests.
 - Correcting positions.
 - Improve the AST model.
 - Merge branch 'master' into patterns-instanceof3
 - ... and 9 more: https://git.openjdk.java.net/jdk/compare/ea26ff11...8fbed8c9

-------------

Changes: https://git.openjdk.java.net/jdk/pull/559/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=559&range=04
  Stats: 651 lines in 90 files changed: 228 ins; 310 del; 113 mod
  Patch: https://git.openjdk.java.net/jdk/pull/559.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/559/head:pull/559

PR: https://git.openjdk.java.net/jdk/pull/559

From mcimadamore at openjdk.java.net  Thu Oct 29 14:13:03 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 29 Oct 2020 14:13:03 GMT
Subject: RFR: 8254162: Implementation of Foreign-Memory Access API (Third
 Incubator) [v18]
In-Reply-To: <IngRk57F78UN3yySfo6IABbdwnMogGNdYrykh_3em-c=.b81f7478-015c-45ed-9788-58d7519a2770@github.com>
References: <IngRk57F78UN3yySfo6IABbdwnMogGNdYrykh_3em-c=.b81f7478-015c-45ed-9788-58d7519a2770@github.com>
Message-ID: <Z0IIcGqmDSjn02W5zbgZpx7HUloH0ccJMR5Yu-4ZSp0=.63c53826-2f1c-49d5-b1f0-879746142d48@github.com>

> This patch contains the changes associated with the third incubation round of the foreign memory access API incubation  (see JEP 393 [1]). This iteration focus on improving the usability of the API in 3 main ways:
> 
> * first, by providing a way to obtain truly *shared* segments, which can be accessed and closed concurrently from multiple threads
> * second, by providing a way to register a memory segment against a `Cleaner`, so as to have some (optional) guarantee that the memory will be deallocated, eventually
> * third, by not requiring users to dive deep into var handles when they first pick up the API; a new `MemoryAccess` class has been added, which defines several useful dereference routines; these are really just thin wrappers around memory access var handles, but they make the barrier of entry for using this API somewhat lower.
> 
> A big conceptual shift that comes with this API refresh is that the role of `MemorySegment` and `MemoryAddress` is not the same as it used to be; it used to be the case that a memory address could (sometimes, not always) have a back link to the memory segment which originated it; additionally, memory access var handles used `MemoryAddress` as a basic unit of dereference.
> 
> This has all changed as per this API refresh;  now a `MemoryAddress` is just a dumb carrier which wraps a pair of object/long addressing coordinates; `MemorySegment` has become the star of the show, as far as dereferencing memory is concerned. You cannot dereference memory if you don't have a segment. This improves usability in a number of ways - first, it is a lot easier to wrap native addresses (`long`, essentially) into a `MemoryAddress`; secondly, it is crystal clear what a client has to do in order to dereference memory: if a client has a segment, it can use that; otherwise, if the client only has an address, it will have to create a segment *unsafely* (this can be done by calling `MemoryAddress::asSegmentRestricted`).
> 
> A list of the API, implementation and test changes is provided below. If  you have any questions, or need more detailed explanations, I (and the  rest of the Panama team) will be happy to point at existing discussions,  and/or to provide the feedback required. 
> 
> A big thank to Erik Osterlund, Vladimir Ivanov and David Holmes, without whom the work on shared memory segment would not have been possible; also I'd like to thank Paul Sandoz, whose insights on API design have been very helpful in this journey.
> 
> Thanks 
> Maurizio 
> 
> Javadoc: 
> 
> http://cr.openjdk.java.net/~mcimadamore/8254162_v1/javadoc/jdk/incubator/foreign/package-summary.html
> 
> Specdiff: 
> 
> http://cr.openjdk.java.net/~mcimadamore/8254162_v1/specdiff/jdk/incubator/foreign/package-summary.html
> 
> CSR: 
> 
> https://bugs.openjdk.java.net/browse/JDK-8254163
> 
> 
> 
> ### API Changes
> 
> * `MemorySegment`
>   * drop factory for restricted segment (this has been moved to `MemoryAddress`, see below)
>   * added a no-arg factory for a native restricted segment representing entire native heap
>   * rename `withOwnerThread` to `handoff`
>   * add new `share` method, to create shared segments
>   * add new `registerCleaner` method, to register a segment against a cleaner
>   * add more helpers to create arrays from a segment e.g. `toIntArray`
>   * add some `asSlice` overloads (to make up for the fact that now segments are more frequently used as cursors)
>   * rename `baseAddress` to `address` (so that `MemorySegment` can implement `Addressable`)
> * `MemoryAddress`
>   * drop `segment` accessor
>   * drop `rebase` method and replace it with `segmentOffset` which returns the offset (a `long`) of this address relative to a given segment
> * `MemoryAccess`
>   * New class supporting several static dereference helpers; the helpers are organized by carrier and access mode, where a carrier is one of the usual suspect (a Java primitive, minus `boolean`); the access mode can be simple (e.g. access base address of given segment), or indexed, in which case the accessor takes a segment and either a low-level byte offset,or a high level logical index. The classification is reflected in the naming scheme (e.g. `getByte` vs. `getByteAtOffset` vs `getByteAtIndex`).
> * `MemoryHandles`
>   * drop `withOffset` combinator
>   * drop `withStride` combinator
>   * the basic memory access handle factory now returns a var handle which takes a `MemorySegment` and a `long` - from which it is easy to derive all the other handles using plain var handle combinators.
> * `Addressable`
>   * This is a new interface which is attached to entities which can be projected to a `MemoryAddress`. For now, both `MemoryAddress` and `MemorySegment` implement it; we have plans, with JEP 389 [2] to add more implementations. Clients can largely ignore this interface, which comes in really handy when defining native bindings with tools like `jextract`.
> * `MemoryLayouts`
>   * A new layout, for machine addresses, has been added to the mix.
> 
> 
> 
> ### Implementation changes
> 
> There are two main things to discuss here: support for shared segments, and the general simplification of the memory access var handle support.
> 
> #### Shared segments
> 
> The support for shared segments cuts in pretty deep in the VM. Support for shared segments is notoriously hard to achieve, at least in a way that guarantees optimal access performances. This is caused by the fact that, if a segment is shared, it would be possible for a thread to close it while another is accessing it.
> 
> After considering several options (see [3]), we zeroed onto an approach which is inspired by an happy idea that Andrew Haley had (and that he reminded me of at this year OpenJDK committer workshop - thanks!). The idea is that if we could *freeze* the world (e.g. with a GC pause), while a segment is closed, we could then prevent segments from being accessed concurrently to a close operation. For this to work, it  is crucial that no GC safepoints can occur between a segment liveness check and the access itself (otherwise it would be possible for the accessing thread to stop just right before an unsafe call). It also relies on the fact that hotspot/C2 should not be able to propagate loads across safepoints.
> 
> Sadly, none of these conditions seems to be valid in the current implementation, so we needed to resort to a bit of creativity. First, we noted that, if we could mark so called *scoped* method with an annotation, it would be very simply to check as to whether a thread was in the middle of a scoped method when we stopped the world for a close operation (btw, instead of stopping the world, we do a much more efficient, thread-local polling, thanks to JEP 312 [4]).
> 
> The question is, then, once we detect that a thread is accessing the very segment we're about to close, what should happen? We first experimented with a solution which would install an *asynchronous* exception on the accessing thread, thus making it fail. This solution has some desirable properties, in that a `close` operation always succeeds. Unfortunately the machinery for async exceptions is a bit fragile (e.g. not all the code in hotspot checks for async exceptions); to minimize risks, we decided to revert to a simpler strategy, where `close` might fail when it finds that another thread is accessing the segment being closed.
> 
> As written in the javadoc, this doesn't mean that clients should just catch and try again; an exception on `close` is a bug in the user code, likely arising from lack of synchronization, and should be treated as such.
> 
> In terms of gritty implementation, we needed to centralize memory access routines in a single place, so that we could have a set of routines closely mimicking the primitives exposed by `Unsafe` but which, in addition, also provided a liveness check. This way we could mark all these routines with the special `@Scoped` annotation, which tells the VM that something important is going on.
> 
> To achieve this, we created a new (autogenerated) class, called `ScopedMemoryAccess`. This class contains all the main memory access primitives (including bulk access, like `copyMemory`, or `setMemory`), and accepts, in addition to the access coordinates, also a scope object, which is tested before access. A reachability fence is also thrown in the mix to make sure that the scope is kept alive during access (which is important when registering segments against cleaners).
> 
> Of course, to make memory access safe, memory access var handles, byte buffer var handles, and byte buffer API should use the new `ScopedMemoryAccess` class instead of unsafe, so that a liveness check can be triggered (in case a scope is present).
> 
> `ScopedMemoryAccess` has a `closeScope` method, which initiates the thread-local handshakes, and returns `true` if the handshake completed successfully.
> 
> The implementation of `MemoryScope` (now significantly simplified from what we had before), has two implementations, one for confined segments and one for shared segments; the main difference between the two is what happens when the scope is closed; a confined segment sets a boolean flag to false, and returns, whereas a shared segment goes into a `CLOSING` state, then starts the handshake, and then updates the state again, to either `CLOSED` or `ALIVE` depending on whether the handshake was successful or not. Note that when a shared segment is in the `CLOSING` state, `MemorySegment::isAlive` will still return `true`, while the liveness check upon memory access will fail.
> 
> #### Memory access var handles overhaul
> 
> The key realization here was that if all memory access var handles took a coordinate pair of `MemorySegment` and `long`, all other access types could be derived from this basic var handle form.
> 
> This allowed us to remove the on-the-fly var handle generation, and to simply derive structural access var handles (such as those obtained by calling `MemoryLayout::varHandle`) using *plain* var handle combinators, so that e.g. additional offset is injected into a base memory access var handle.
> 
> This also helped in simplifying the implementation by removing the special `withStride` and `withOffset` combinators, which previously needed low-level access on the innards of the memory access var handle. All that code is now gone.
> 
> #### Test changes
> 
> Not much to see here - most of the tests needed to be updated because of the API changes. Some were beefed up (like the array test, since now segments can be projected into many different kinds of arrays). A test has been added to test the `Cleaner` functionality, and another stress test has been added for shared segments (`TestHandshake`). Some of the microbenchmarks also needed some tweaks - and some of them were also updated to also test performance in the shared segment case.
> 
> [1] - https://openjdk.java.net/jeps/393
> [2] - https://openjdk.java.net/jeps/389
> [3] - https://mail.openjdk.java.net/pipermail/panama-dev/2020-May/009004.html
> [4] - https://openjdk.java.net/jeps/312

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Fix issues with derived buffers and IO operations

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/548/files
  - new: https://git.openjdk.java.net/jdk/pull/548/files/b01af093..e3ec6b4c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=548&range=17
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=548&range=16-17

  Stats: 81 lines in 5 files changed: 77 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/548.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/548/head:pull/548

PR: https://git.openjdk.java.net/jdk/pull/548

From mcimadamore at openjdk.java.net  Thu Oct 29 14:16:49 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 29 Oct 2020 14:16:49 GMT
Subject: RFR: 8254162: Implementation of Foreign-Memory Access API (Third
 Incubator)
In-Reply-To: <pS93Tkclki7y3uzfofkeCRZiZV8Wbb0fpPTI4aOHZXA=.b467ed27-1874-4302-833d-e022ef913dbb@github.com>
References: <IngRk57F78UN3yySfo6IABbdwnMogGNdYrykh_3em-c=.b81f7478-015c-45ed-9788-58d7519a2770@github.com>
 <pS93Tkclki7y3uzfofkeCRZiZV8Wbb0fpPTI4aOHZXA=.b467ed27-1874-4302-833d-e022ef913dbb@github.com>
Message-ID: <gKyi3UsqpyQ6bWnRX3JIEsc5-4SEMZmHLFdz0gRgRoY=.2b655f9f-551c-4454-9f21-1c9dbf2dcc24@github.com>

On Tue, 27 Oct 2020 14:40:29 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This patch contains the changes associated with the third incubation round of the foreign memory access API incubation  (see JEP 393 [1]). This iteration focus on improving the usability of the API in 3 main ways:
>> 
>> * first, by providing a way to obtain truly *shared* segments, which can be accessed and closed concurrently from multiple threads
>> * second, by providing a way to register a memory segment against a `Cleaner`, so as to have some (optional) guarantee that the memory will be deallocated, eventually
>> * third, by not requiring users to dive deep into var handles when they first pick up the API; a new `MemoryAccess` class has been added, which defines several useful dereference routines; these are really just thin wrappers around memory access var handles, but they make the barrier of entry for using this API somewhat lower.
>> 
>> A big conceptual shift that comes with this API refresh is that the role of `MemorySegment` and `MemoryAddress` is not the same as it used to be; it used to be the case that a memory address could (sometimes, not always) have a back link to the memory segment which originated it; additionally, memory access var handles used `MemoryAddress` as a basic unit of dereference.
>> 
>> This has all changed as per this API refresh;  now a `MemoryAddress` is just a dumb carrier which wraps a pair of object/long addressing coordinates; `MemorySegment` has become the star of the show, as far as dereferencing memory is concerned. You cannot dereference memory if you don't have a segment. This improves usability in a number of ways - first, it is a lot easier to wrap native addresses (`long`, essentially) into a `MemoryAddress`; secondly, it is crystal clear what a client has to do in order to dereference memory: if a client has a segment, it can use that; otherwise, if the client only has an address, it will have to create a segment *unsafely* (this can be done by calling `MemoryAddress::asSegmentRestricted`).
>> 
>> A list of the API, implementation and test changes is provided below. If  you have any questions, or need more detailed explanations, I (and the  rest of the Panama team) will be happy to point at existing discussions,  and/or to provide the feedback required. 
>> 
>> A big thank to Erik Osterlund, Vladimir Ivanov and David Holmes, without whom the work on shared memory segment would not have been possible; also I'd like to thank Paul Sandoz, whose insights on API design have been very helpful in this journey.
>> 
>> Thanks 
>> Maurizio 
>> 
>> Javadoc: 
>> 
>> http://cr.openjdk.java.net/~mcimadamore/8254162_v1/javadoc/jdk/incubator/foreign/package-summary.html
>> 
>> Specdiff: 
>> 
>> http://cr.openjdk.java.net/~mcimadamore/8254162_v1/specdiff/jdk/incubator/foreign/package-summary.html
>> 
>> CSR: 
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8254163
>> 
>> 
>> 
>> ### API Changes
>> 
>> * `MemorySegment`
>>   * drop factory for restricted segment (this has been moved to `MemoryAddress`, see below)
>>   * added a no-arg factory for a native restricted segment representing entire native heap
>>   * rename `withOwnerThread` to `handoff`
>>   * add new `share` method, to create shared segments
>>   * add new `registerCleaner` method, to register a segment against a cleaner
>>   * add more helpers to create arrays from a segment e.g. `toIntArray`
>>   * add some `asSlice` overloads (to make up for the fact that now segments are more frequently used as cursors)
>>   * rename `baseAddress` to `address` (so that `MemorySegment` can implement `Addressable`)
>> * `MemoryAddress`
>>   * drop `segment` accessor
>>   * drop `rebase` method and replace it with `segmentOffset` which returns the offset (a `long`) of this address relative to a given segment
>> * `MemoryAccess`
>>   * New class supporting several static dereference helpers; the helpers are organized by carrier and access mode, where a carrier is one of the usual suspect (a Java primitive, minus `boolean`); the access mode can be simple (e.g. access base address of given segment), or indexed, in which case the accessor takes a segment and either a low-level byte offset,or a high level logical index. The classification is reflected in the naming scheme (e.g. `getByte` vs. `getByteAtOffset` vs `getByteAtIndex`).
>> * `MemoryHandles`
>>   * drop `withOffset` combinator
>>   * drop `withStride` combinator
>>   * the basic memory access handle factory now returns a var handle which takes a `MemorySegment` and a `long` - from which it is easy to derive all the other handles using plain var handle combinators.
>> * `Addressable`
>>   * This is a new interface which is attached to entities which can be projected to a `MemoryAddress`. For now, both `MemoryAddress` and `MemorySegment` implement it; we have plans, with JEP 389 [2] to add more implementations. Clients can largely ignore this interface, which comes in really handy when defining native bindings with tools like `jextract`.
>> * `MemoryLayouts`
>>   * A new layout, for machine addresses, has been added to the mix.
>> 
>> 
>> 
>> ### Implementation changes
>> 
>> There are two main things to discuss here: support for shared segments, and the general simplification of the memory access var handle support.
>> 
>> #### Shared segments
>> 
>> The support for shared segments cuts in pretty deep in the VM. Support for shared segments is notoriously hard to achieve, at least in a way that guarantees optimal access performances. This is caused by the fact that, if a segment is shared, it would be possible for a thread to close it while another is accessing it.
>> 
>> After considering several options (see [3]), we zeroed onto an approach which is inspired by an happy idea that Andrew Haley had (and that he reminded me of at this year OpenJDK committer workshop - thanks!). The idea is that if we could *freeze* the world (e.g. with a GC pause), while a segment is closed, we could then prevent segments from being accessed concurrently to a close operation. For this to work, it  is crucial that no GC safepoints can occur between a segment liveness check and the access itself (otherwise it would be possible for the accessing thread to stop just right before an unsafe call). It also relies on the fact that hotspot/C2 should not be able to propagate loads across safepoints.
>> 
>> Sadly, none of these conditions seems to be valid in the current implementation, so we needed to resort to a bit of creativity. First, we noted that, if we could mark so called *scoped* method with an annotation, it would be very simply to check as to whether a thread was in the middle of a scoped method when we stopped the world for a close operation (btw, instead of stopping the world, we do a much more efficient, thread-local polling, thanks to JEP 312 [4]).
>> 
>> The question is, then, once we detect that a thread is accessing the very segment we're about to close, what should happen? We first experimented with a solution which would install an *asynchronous* exception on the accessing thread, thus making it fail. This solution has some desirable properties, in that a `close` operation always succeeds. Unfortunately the machinery for async exceptions is a bit fragile (e.g. not all the code in hotspot checks for async exceptions); to minimize risks, we decided to revert to a simpler strategy, where `close` might fail when it finds that another thread is accessing the segment being closed.
>> 
>> As written in the javadoc, this doesn't mean that clients should just catch and try again; an exception on `close` is a bug in the user code, likely arising from lack of synchronization, and should be treated as such.
>> 
>> In terms of gritty implementation, we needed to centralize memory access routines in a single place, so that we could have a set of routines closely mimicking the primitives exposed by `Unsafe` but which, in addition, also provided a liveness check. This way we could mark all these routines with the special `@Scoped` annotation, which tells the VM that something important is going on.
>> 
>> To achieve this, we created a new (autogenerated) class, called `ScopedMemoryAccess`. This class contains all the main memory access primitives (including bulk access, like `copyMemory`, or `setMemory`), and accepts, in addition to the access coordinates, also a scope object, which is tested before access. A reachability fence is also thrown in the mix to make sure that the scope is kept alive during access (which is important when registering segments against cleaners).
>> 
>> Of course, to make memory access safe, memory access var handles, byte buffer var handles, and byte buffer API should use the new `ScopedMemoryAccess` class instead of unsafe, so that a liveness check can be triggered (in case a scope is present).
>> 
>> `ScopedMemoryAccess` has a `closeScope` method, which initiates the thread-local handshakes, and returns `true` if the handshake completed successfully.
>> 
>> The implementation of `MemoryScope` (now significantly simplified from what we had before), has two implementations, one for confined segments and one for shared segments; the main difference between the two is what happens when the scope is closed; a confined segment sets a boolean flag to false, and returns, whereas a shared segment goes into a `CLOSING` state, then starts the handshake, and then updates the state again, to either `CLOSED` or `ALIVE` depending on whether the handshake was successful or not. Note that when a shared segment is in the `CLOSING` state, `MemorySegment::isAlive` will still return `true`, while the liveness check upon memory access will fail.
>> 
>> #### Memory access var handles overhaul
>> 
>> The key realization here was that if all memory access var handles took a coordinate pair of `MemorySegment` and `long`, all other access types could be derived from this basic var handle form.
>> 
>> This allowed us to remove the on-the-fly var handle generation, and to simply derive structural access var handles (such as those obtained by calling `MemoryLayout::varHandle`) using *plain* var handle combinators, so that e.g. additional offset is injected into a base memory access var handle.
>> 
>> This also helped in simplifying the implementation by removing the special `withStride` and `withOffset` combinators, which previously needed low-level access on the innards of the memory access var handle. All that code is now gone.
>> 
>> #### Test changes
>> 
>> Not much to see here - most of the tests needed to be updated because of the API changes. Some were beefed up (like the array test, since now segments can be projected into many different kinds of arrays). A test has been added to test the `Cleaner` functionality, and another stress test has been added for shared segments (`TestHandshake`). Some of the microbenchmarks also needed some tweaks - and some of them were also updated to also test performance in the shared segment case.
>> 
>> [1] - https://openjdk.java.net/jeps/393
>> [2] - https://openjdk.java.net/jeps/389
>> [3] - https://mail.openjdk.java.net/pipermail/panama-dev/2020-May/009004.html
>> [4] - https://openjdk.java.net/jeps/312
>
>> @mcimadamore, if you pull from current master, you would get the Linux x86_32 tier1 run "for free".
> 
> Just did that - I also removed TestMismatch from the problem list in the latest iteration, and fixed the alignment for long/double layouts, after chatting with the team (https://bugs.openjdk.java.net/browse/JDK-8255350)

I've just uploaded another iteration which addresses some comments from @AlanBateman. Basically, there are some operations on Channel and Socket which take ByteBuffer as arguments, and then, if such buffers are *direct*, they get the address and pass it down to some native function. This idiom is problematic because there's no way to guarantee that the buffer won't be closed (if obtained from a memory segment) after the address has been obtained. As a stop gap solution, I've introduced checks in `DirectBuffer::address` method, which is used in around 30 places in the JDK. This method will now throw if (a) the buffer has a shared scope, or (b) if the scope is confined, but already closed. With this extra check, I believe there's no way to misuse the buffer obtained from a segment. We have discussed plans to remove this limitations (which we think will be possible) - but for the time being, it's better to play the conservative card.

-------------

PR: https://git.openjdk.java.net/jdk/pull/548

From naoto at openjdk.java.net  Thu Oct 29 16:15:52 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 29 Oct 2020 16:15:52 GMT
Subject: RFR: 8247781: Day periods support
Message-ID: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>

Hi,

Please review the changes for the subject issue. This is to enhance the java.time package to support day periods, such as "in the morning", defined in CLDR. It will add a new pattern character 'B' and its supporting builder method. The motivation and its spec are in this CSR:

https://bugs.openjdk.java.net/browse/JDK-8254629

Naoto

-------------

Commit messages:
 - 8247781: Day periods support

Changes: https://git.openjdk.java.net/jdk/pull/938/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=938&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8247781
  Stats: 1022 lines in 17 files changed: 838 ins; 87 del; 97 mod
  Patch: https://git.openjdk.java.net/jdk/pull/938.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/938/head:pull/938

PR: https://git.openjdk.java.net/jdk/pull/938

From serban.iordache at gmail.com  Thu Oct 29 17:03:15 2020
From: serban.iordache at gmail.com (Serban Iordache)
Date: Thu, 29 Oct 2020 18:03:15 +0100
Subject: Incorrect value of resource.wxl-file-name in
 WinResources_ja.properties and WinResources_zh_CN.properties
Message-ID: <CA+QZ5tS5iWhuzCg=QDHj+WBLYsrUbLmt8efaggTDveRNc=HSyg@mail.gmail.com>

A China-based user of my Gradle plugin for creating installable packages
reported getting the following light.exe error:
LGHT0311 : A string was provided with characters that are not available in
the specified database code page '1252'.

I cannot reproduce the error because I don't have a machine running a
Chinese Windows 10, but I think that it's caused by the
resource.wxl-file-name property having the value MsiInstallerStrings_en.wxl
in all localization files. More specifically, I think that:

- in
https://github.com/openjdk/jdk/blob/ee2e61d7e0da8780f9893fbba8ca4cb44b520da1/src/jdk.incubator.jpackage/windows/classes/jdk/incubator/jpackage/internal/resources/WinResources_ja.properties#L37
resource.wxl-file-name=MsiInstallerStrings_en.wxl
  should be replaced with
resource.wxl-file-name=MsiInstallerStrings_ja.wxl

- in
https://github.com/openjdk/jdk/blob/ee2e61d7e0da8780f9893fbba8ca4cb44b520da1/src/jdk.incubator.jpackage/windows/classes/jdk/incubator/jpackage/internal/resources/WinResources_zh_CN.properties#L37
resource.wxl-file-name=MsiInstallerStrings_en.wxl
  should be replaced with
resource.wxl-file-name=MsiInstallerStrings_zh_CN.wxl

Thanks,

Serban

From herrick at openjdk.java.net  Thu Oct 29 17:47:54 2020
From: herrick at openjdk.java.net (Andy Herrick)
Date: Thu, 29 Oct 2020 17:47:54 GMT
Subject: RFR: JDK-8254920: Application launched with jpackage produced .exe
 crashes JVM
Message-ID: <Tcn6BwsjMBJ4KTFov7i4VN7kVJasVeTEXGyguR4RVUw=.1f8c589f-0ade-447b-be0d-b5178e15752b@github.com>

JVM

-------------

Commit messages:
 - JDK-8254920: Application launched with jpackage produced .exe crashes

Changes: https://git.openjdk.java.net/jdk/pull/940/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=940&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8254920
  Stats: 109 lines in 4 files changed: 107 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/940.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/940/head:pull/940

PR: https://git.openjdk.java.net/jdk/pull/940

From jvernee at openjdk.java.net  Thu Oct 29 18:14:06 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Thu, 29 Oct 2020 18:14:06 GMT
Subject: RFR: 8254354: Add an asExact() VarHandle combinator [v2]
In-Reply-To: <tf6yf7PtAtS9lr0q_IPF6wwntRHpbVlYUwyGFYjhFU0=.a1c62667-82f8-4793-98e8-ae525678e85d@github.com>
References: <gJ1pTeZZC7tbtwiRsrHcZ1ydfTQhr1MPndGrnGolf14=.dd935929-4f22-4e41-9e0d-99a592ac46b7@github.com>
 <Mo3T9JJzO03q-I_q8NhsGpu2TVaJg_104ESGWqLhYRg=.7d353318-6827-4708-b973-a9c30558c3ed@github.com>
 <TXUctfc1V1T5RKCtSJAgQZe6xO4I561ez5Ol4YdzLeA=.3c0c41b5-a8b1-44b4-b107-1bd58db6e1a1@github.com>
 <FzY88BSt7bw9P6vmQKtXtBrd8Zwd4bE0sg39ur30x_4=.8ada75c2-7f54-4058-aa7c-822d12f9cbc9@github.com>
 <l89RFW5KvA8JvtpvCuo1q7gj2v6nRiuc_A-sN-7O0k8=.8c7153e0-d3f5-47e3-be91-a2782697ef48@github.com>
 <ih7I5nwJ_ZtY1HovULNMqrBqmbGS2m9-IgxEl2AXnao=.72cd046b-4477-43ab-bbc9-93f448e6cd3d@github.com>
 <hsUp1zTqRf1o1KJl96lNWsGbx2_Nv_HvOFaaU2xQUdI=.05f1f992-fa75-4ccd-9f14-50b0682000b7@github.com>
 <zL3Ch3atQMQlQTdcwv9-cVNwSS6h1EOVlKHJBP1nK7Q=.42ed0c79-ca03-4b31-8084-1bea69d13765@github.com>
 <94D2yl0BiGL56RmbE82u4mDhsvaCU79qDDpE3iu_Ce8=.71d1bb0a-3090-4937-b124-4ad9d5a3fcef@github.com>
 <0_81dNIzQI4tZmRWVVNK_CKQRUtML4397NUe1SKL3rY=.9338ffba-c8be-4e8a-9743-9838f48e95c8@github.com>
 <tf6yf7PtAtS9lr0q_IPF6wwntRHpbVlYUwy
 GFYjhFU0=.a1c62667-82f8-4793-98e8-ae525678e85d@github.com>
Message-ID: <8mZ49gYHzX7l5aEdCaB4eDUYAVzjbvcam2gyslKdAeA=.b47d5b60-1869-462e-a745-aea7e2c9c3cd@github.com>

On Tue, 27 Oct 2020 15:01:31 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> I've updated the implementation of accessModeType to work with the ordinal directly. Note that it was using the AccessType ordinal though, so I also had to change the parameter type of accessModeTypeUncached, and the respective implementations, to use AccessType directly (luckily this was possible, since the current implementations all just used the AccessType).
>
> I think `asInvoker` and `asExactInvoker` make sense if you think of a VarHandle as an invoker of MethodHandles (though this is more of an implementation detail). But, I feel like the name `asInvoker` isn't obvious enough for what it does. i.e. it's not that obvious from the name that this removes the exactness.
> 
> If `asGeneric` is problematic, maybe just `asNonExact` works?

I've uploaded another revision that has the suggested javadoc changes, courtesy of Paul. We also decided to rename asExact() and asGeneric() to withInvokeExactBehaviour() and withInvokeBehaviour() (with links to the relevant javadoc sections).

-------------

PR: https://git.openjdk.java.net/jdk/pull/843

From jvernee at openjdk.java.net  Thu Oct 29 18:14:05 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Thu, 29 Oct 2020 18:14:05 GMT
Subject: RFR: 8254354: Add an asExact() VarHandle combinator [v9]
In-Reply-To: <gJ1pTeZZC7tbtwiRsrHcZ1ydfTQhr1MPndGrnGolf14=.dd935929-4f22-4e41-9e0d-99a592ac46b7@github.com>
References: <gJ1pTeZZC7tbtwiRsrHcZ1ydfTQhr1MPndGrnGolf14=.dd935929-4f22-4e41-9e0d-99a592ac46b7@github.com>
Message-ID: <uTje1Aig7YoVD5weI_IyD0yZdCFlNsIiSJjyzUQIXHM=.fcd5a9fa-e186-4776-a968-b07f4552b4e9@github.com>

> Hi,
> 
> This patch adds an asExact() combinator to VarHandle, that will return a new VarHandle that performs exact type checks, similar to MethodHandle::invokeExact, to help developers catch inexact VarHandle usage, which can lead to performance degradation.
> 
> This is implemented using a boolean flag in VarForm. If the flag is set, the exact type of the invocation is checked against the exact type in the VarForm. If there is a mismatch, a WrongMethodTypeException is thrown.
> 
> Other than that, there is also an asGeneric() combinator added that does the inverse operation (thanks to R?mi for the suggestion). I've also added The `@Hidden` annotation to the VarHandleGuards methods, as well as a type-checking helper method called from the generic invocation lambda form, so that the stack trace we get points at the location where the VarHandle is being used.
> 
> Thanks,
> Jorn
> 
> CSR link: https://bugs.openjdk.java.net/browse/JDK-8255375

Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision:

 - Update Javadoc, and rename asExact and asGeneric to withInvokeExactBehaviour and withInvokeBehaviour
 - Merge branch 'master' into Exact_VarHandle
 - Use AccessType ordinal in guard checks instead of the AccessMode ordinal
 - Update accessModeType to use the AccessType ordinal directly.
 - Add benchmarks
 - - Update javadoc
   - Make isExact() public
 - Fixes failing tests, and enable verifier on Exact test
 - Fix whitespace
 - Comment out VarHandleGuards generator code
 - Makes exactness a property of a VarHandle, not a VarForm, since the latter are shared. Use handle.accessModeType to get the exact type of the VarHandle.
 - ... and 2 more: https://git.openjdk.java.net/jdk/compare/f9c76729...3c707bc7

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/843/files
  - new: https://git.openjdk.java.net/jdk/pull/843/files/8e5fb451..3c707bc7

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=843&range=08
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=843&range=07-08

  Stats: 14492 lines in 455 files changed: 8478 ins; 4347 del; 1667 mod
  Patch: https://git.openjdk.java.net/jdk/pull/843.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/843/head:pull/843

PR: https://git.openjdk.java.net/jdk/pull/843

From github.com+27751938+amcap1712 at openjdk.java.net  Thu Oct 29 18:31:52 2020
From: github.com+27751938+amcap1712 at openjdk.java.net (Kartik Ohri)
Date: Thu, 29 Oct 2020 18:31:52 GMT
Subject: RFR: 8186085: (opt) add filter(), flatMap(),
 and map() methods to OptionalDouble/Int/Long
Message-ID: <b7KzeBxklrPQqohcMHsNfDtIKbYaZ_9qa5td3dV_Oe4=.542e7568-bf8b-47b9-979a-6864fcf7eece@github.com>

Hi all,
This PR intends to add filter, map and flatMap methods to the Optional classes for primitives. The rationale is consistency with the Optional class for objects and user convenience.
Thanks.
Regards,
Kartik

-------------

Commit messages:
 - 8186085: (opt) add filter(), flatMap(), and map() methods to OptionalDouble/Int/Long

Changes: https://git.openjdk.java.net/jdk/pull/857/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=857&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8186085
  Stats: 336 lines in 6 files changed: 336 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/857.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/857/head:pull/857

PR: https://git.openjdk.java.net/jdk/pull/857

From rriggs at openjdk.java.net  Thu Oct 29 18:36:52 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 29 Oct 2020 18:36:52 GMT
Subject: RFR: 8254975: lambda proxy fails to access a protected member
 inherited from a split package
In-Reply-To: <8QLuT7jhXUHtB8Ce1Eb15D4LuEZkAEGWPr4k7LetMcI=.bbda143d-7c36-4da9-8e04-f359b19a7aed@github.com>
References: <8QLuT7jhXUHtB8Ce1Eb15D4LuEZkAEGWPr4k7LetMcI=.bbda143d-7c36-4da9-8e04-f359b19a7aed@github.com>
Message-ID: <uwCaZ_ACFh5OGkF0m5B_l8WUdQFUaVnqn5HSXVZtyHY=.8341bb44-8abc-4fea-9f61-e414612e5922@github.com>

On Tue, 20 Oct 2020 18:13:39 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> It's a bug in determining if a protected member inherited from a superclass is in
> a split package as its host class that it only checks on the package name.  
> 
> The fix is simple and compare the runtime package of the lambda class (which
> is in the same runtime package as the host class) with that of the declaring class
> of the protected member being accessed.

Marked as reviewed by rriggs (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/767

From jvernee at openjdk.java.net  Thu Oct 29 18:37:49 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Thu, 29 Oct 2020 18:37:49 GMT
Subject: Integrated: 8255449: Improve the exception message of
 MethodHandles::permuteArguments
In-Reply-To: <9ibIdtPhdYSNXJfsy6uIzu4XV46dyZBqc498HIaOII4=.08a61fba-320b-430f-a8cf-9855e4db64de@github.com>
References: <9ibIdtPhdYSNXJfsy6uIzu4XV46dyZBqc498HIaOII4=.08a61fba-320b-430f-a8cf-9855e4db64de@github.com>
Message-ID: <cdq7BekjZJE7_OP_FQhzhE3F97boR9a-d0uvpFLdUyk=.7c0d3788-86f8-40fa-bff9-17f21185011b@github.com>

On Tue, 27 Oct 2020 12:43:47 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Hi,
> 
> Currently, if MethodHandles::permuteArguments is used with a reorder array that is the wrong size, or one of the indexes in it is out of bounds of the new type, we simply get the exception message:
> 
>     bad reorder array [...]
> 
> I think we can improve the exception message by splitting these two error cases, and saying in the message exactly what went wrong.
> 
> permuteArguments is a tricky API, so improving the error message here should help to improve developer productivity.
> 
> This PR proposes splits the error message into e.g.:
> 
>     old type parameter count and reorder array length do not match: (int,int,String)int, [0, 0]
> 
> For an incorrect reorder array length, and:
> 
>     index is out of bounds for new type: 2, (int,String)int
> 
> For an out of bounds index.
> 
> Thanks,
> Jorn

This pull request has now been integrated.

Changeset: 2a2fa134
Author:    Jorn Vernee <jvernee at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/2a2fa134
Stats:     78 lines in 2 files changed: 62 ins; 3 del; 13 mod

8255449: Improve the exception message of MethodHandles::permuteArguments

Reviewed-by: chegar, mchung

-------------

PR: https://git.openjdk.java.net/jdk/pull/878

From asemenyuk at openjdk.java.net  Thu Oct 29 21:07:45 2020
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Thu, 29 Oct 2020 21:07:45 GMT
Subject: RFR: JDK-8254920: Application launched with jpackage produced
 .exe crashes JVM
In-Reply-To: <Tcn6BwsjMBJ4KTFov7i4VN7kVJasVeTEXGyguR4RVUw=.1f8c589f-0ade-447b-be0d-b5178e15752b@github.com>
References: <Tcn6BwsjMBJ4KTFov7i4VN7kVJasVeTEXGyguR4RVUw=.1f8c589f-0ade-447b-be0d-b5178e15752b@github.com>
Message-ID: <qywQ056M5fNrrUyBdoZ_6-UkQdHme13uKbkWqOkNE1c=.acee482c-7db3-4221-a4a6-4058309abae1@github.com>

On Thu, 29 Oct 2020 17:32:24 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> JVM

test/jdk/tools/jpackage/helpers/jdk/jpackage/test/HelloApp.java line 276:

> 274:         AppOutputVerifier av = getVerifier(cmd, args);
> 275:         if (av != null) {
> 276:             // when running app launchers, clear users environment

How about executeLauncher() method? It will not clear the environment.

-------------

PR: https://git.openjdk.java.net/jdk/pull/940

From mchung at openjdk.java.net  Thu Oct 29 21:15:48 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Thu, 29 Oct 2020 21:15:48 GMT
Subject: Integrated: 8254975: lambda proxy fails to access a protected member
 inherited from a split package
In-Reply-To: <8QLuT7jhXUHtB8Ce1Eb15D4LuEZkAEGWPr4k7LetMcI=.bbda143d-7c36-4da9-8e04-f359b19a7aed@github.com>
References: <8QLuT7jhXUHtB8Ce1Eb15D4LuEZkAEGWPr4k7LetMcI=.bbda143d-7c36-4da9-8e04-f359b19a7aed@github.com>
Message-ID: <mYB5q_EOmRDHhCRyPpuhPcawmZAJl_pY2l-HM9mqGIE=.fd1cab80-8add-475b-bf1d-b23cb77042b0@github.com>

On Tue, 20 Oct 2020 18:13:39 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> It's a bug in determining if a protected member inherited from a superclass is in
> a split package as its host class that it only checks on the package name.  
> 
> The fix is simple and compare the runtime package of the lambda class (which
> is in the same runtime package as the host class) with that of the declaring class
> of the protected member being accessed.

This pull request has now been integrated.

Changeset: 5782a2a3
Author:    Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/5782a2a3
Stats:     86 lines in 2 files changed: 77 ins; 1 del; 8 mod

8254975: lambda proxy fails to access a protected member inherited from a split package

Reviewed-by: rriggs

-------------

PR: https://git.openjdk.java.net/jdk/pull/767

From andy.herrick at oracle.com  Thu Oct 29 21:26:18 2020
From: andy.herrick at oracle.com (Andy Herrick)
Date: Thu, 29 Oct 2020 17:26:18 -0400
Subject: Incorrect value of resource.wxl-file-name in
 WinResources_ja.properties and WinResources_zh_CN.properties
In-Reply-To: <CA+QZ5tS5iWhuzCg=QDHj+WBLYsrUbLmt8efaggTDveRNc=HSyg@mail.gmail.com>
References: <CA+QZ5tS5iWhuzCg=QDHj+WBLYsrUbLmt8efaggTDveRNc=HSyg@mail.gmail.com>
Message-ID: <b8677f50-3f63-2b52-9af9-237b65f212db@oracle.com>

your right - I filed JDK-8255619 to fix this in JDK-16

/Andy

On 10/29/2020 1:03 PM, Serban Iordache wrote:
> A China-based user of my Gradle plugin for creating installable packages
> reported getting the following light.exe error:
> LGHT0311 : A string was provided with characters that are not available in
> the specified database code page '1252'.
>
> I cannot reproduce the error because I don't have a machine running a
> Chinese Windows 10, but I think that it's caused by the
> resource.wxl-file-name property having the value MsiInstallerStrings_en.wxl
> in all localization files. More specifically, I think that:
>
> - in
> https://github.com/openjdk/jdk/blob/ee2e61d7e0da8780f9893fbba8ca4cb44b520da1/src/jdk.incubator.jpackage/windows/classes/jdk/incubator/jpackage/internal/resources/WinResources_ja.properties#L37
> resource.wxl-file-name=MsiInstallerStrings_en.wxl
>    should be replaced with
> resource.wxl-file-name=MsiInstallerStrings_ja.wxl
>
> - in
> https://github.com/openjdk/jdk/blob/ee2e61d7e0da8780f9893fbba8ca4cb44b520da1/src/jdk.incubator.jpackage/windows/classes/jdk/incubator/jpackage/internal/resources/WinResources_zh_CN.properties#L37
> resource.wxl-file-name=MsiInstallerStrings_en.wxl
>    should be replaced with
> resource.wxl-file-name=MsiInstallerStrings_zh_CN.wxl
>
> Thanks,
>
> Serban

From alexey.semenyuk at oracle.com  Thu Oct 29 21:45:00 2020
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Thu, 29 Oct 2020 17:45:00 -0400
Subject: [jpackage] Issue with upgrading from javapackager to jpackage on
 Windows
In-Reply-To: <CAAoP7T5WZz9QX1NWf+69XGENsEkU2MAY637Mn15omxwBemae-A@mail.gmail.com>
References: <mailman.5881.1581956828.14600.core-libs-dev@openjdk.java.net>
 <02102893-DD43-4626-9F39-DBBD1A71975C@deepsymmetry.org>
 <CAAoP7T7VT1ewQiNsb6SG00jrwRX1yX93v7moBEVwMUHoU4HmTA@mail.gmail.com>
 <CAAoP7T7YCvc2bnOUqLNnw22FJXV26BNGW+ceA3ptNjg_rFDXtg@mail.gmail.com>
 <d25818fa-d4af-5906-df7e-a6c4ff0e8b8b@oracle.com>
 <CAAoP7T4UBLatfAneSv-VN06cG6w4SVeS+FfEqJBP8sSmqdaxQw@mail.gmail.com>
 <a83c8ff4-a791-6e63-0616-8d057426f02b@oracle.com>
 <CAAoP7T5WZz9QX1NWf+69XGENsEkU2MAY637Mn15omxwBemae-A@mail.gmail.com>
Message-ID: <ba682a80-4448-2535-361a-c5c63b5a197c@oracle.com>

Hi Daniel,

The original issue described in the CR is expected to persist with 
<Upgrade Id="$(var.AppUpgradeCode)" /> element in WiX source of? msi 
installers produced by jpackage. For the reasons described in the 
comment to the CR.
Unfortunately there is no simple fix for the problem. Fortunately there 
is simple workaround for it :)

- Alexey

On 10/29/2020 5:21 AM, Daniel Peintner wrote:
> Alexey, all,
>
> Thanks for keeping me updated.
> I agree with the statement that a full fledged procedure for updates 
> is out of scope for jpackage.
>
> Note:? It is mentioned that <Upgrade Id="$(var.AppUpgradeCode)" /> has 
> been added also in the meantime.
> I did try it out with JDK-16-ea+21 and my application but the issue 
> still persists (but different: user gets error dialog mentioning jre 
> cannot be found).
> Hence a user needs to manually uninstall the "old" application before 
> being able to run the new installer.
>
> Thanks a lot anyway,
>
> -- Daniel
>
>
> On Wed, Oct 28, 2020 at 8:59 PM Alexey Semenyuk 
> <alexey.semenyuk at oracle.com <mailto:alexey.semenyuk at oracle.com>> wrote:
>
>     Daniel,
>
>     https://bugs.openjdk.java.net/browse/JDK-8240111 has been updated
>     with the evaluation of your request. Please take a look.
>
>     - Alexey
>
>     On 2/27/2020 2:00 AM, Daniel Peintner wrote:
>>     Alexey, all,
>>
>>     In my case the update, as described, seems to work just fine.
>>     However once I try to actually start the application nothing
>>     happens. It silently fails.
>>
>>     Could this be a reason why you don't encounter any issue? Just an
>>     idea though...
>>
>>     -- Daniel
>>
>>
>>     Alexey Semenyuk <alexey.semenyuk at oracle.com
>>     <mailto:alexey.semenyuk at oracle.com>> schrieb am Mi., 26. Feb.
>>     2020, 22:56:
>>
>>         Daniel,
>>
>>         Interesting. We have jtreg tests for testing upgrade
>>         scenarios on
>>         Windows and they work without Upgrade element in WiX template.
>>
>>         - Alexey
>>
>>         On 2/26/2020 11:10 AM, Daniel Peintner wrote:
>>         > All,
>>         >
>>         > after some private discussions with James and @Kevinnns I
>>         believe the
>>         > necessary change to let upgrades succeed is rather minimal.
>>         >
>>         > The WIX template jpackage uses
>>         >
>>         > <Product Id="*" Name="$(var.AppName)" Language="1033"
>>         > Version="$(var.AppVersion)" Manufacturer="$(var.AppVendor)"
>>         > UpgradeCode="$(var.AppUpgradeCode)">
>>         >
>>         > needs to have
>>         >
>>         > <Upgrade Id="$(var.AppUpgradeCode)" />
>>         >
>>         > as well within the product element.
>>         >
>>         > I wonder whether anyone in the jpackage team is willing to
>>         work or look
>>         > into this proposed change. Or does this cause any other
>>         issue I am not
>>         > aware of?
>>         >
>>         > As said, I think this would be a big help for anyone coming
>>         from the *old*
>>         > javapackager tool.
>>         >
>>         > Thanks,
>>         >
>>         > -- Daniel
>>         >
>>         >
>>         >
>>         >
>>         >
>>         >
>>         > On Tue, Feb 25, 2020 at 4:30 PM Daniel Peintner
>>         <daniel.peintner at gmail.com <mailto:daniel.peintner at gmail.com>>
>>         > wrote:
>>         >
>>         >> Hi James, all,
>>         >>
>>         >> Thank you for your feedback.
>>         >>
>>         >> I did try around and I think there is a jpackage upgrade
>>         ID option now.
>>         >>
>>         >> --win-upgrade-uuid <string> ? UUID associated with
>>         upgrades for this
>>         >> package
>>         >>
>>         >> In my case though, I think I run into some other issues.
>>         The InnoSetup
>>         >> installer seems not to provide any UUID.
>>         >>
>>         >> I believe I also found a related issue [1] that mentions
>>         UUID and
>>         >> InnoSetup but unfortunately that didn't help me either.
>>         >>
>>         >> Thanks again for any help,
>>         >>
>>         >> -- Daniel
>>         >>
>>         >> [1] https://bugs.openjdk.java.net/browse/JDK-8214564
>>         >>
>>         >>
>>         >>
>>         >> On Mon, Feb 17, 2020 at 5:38 PM James Elliott
>>         <james at deepsymmetry.org <mailto:james at deepsymmetry.org>>
>>         >> wrote:
>>         >>
>>         >>> Sorry, tried sending this with the incorrect email
>>         personality first.
>>         >>>
>>         >>> On Mon, 17 Feb 2020 15:32:14 +0100 Daniel Peintner <
>>         >>> daniel.peintner at gmail.com
>>         <mailto:daniel.peintner at gmail.com>
>>         <mailto:daniel.peintner at gmail.com
>>         <mailto:daniel.peintner at gmail.com>>> wrote:
>>         >>>> The only *working* solution we found was to *manually*
>>         uninstall the old
>>         >>>> application before starting msi installer.
>>         >>>> Any future update with msi installers work fine. But the
>>         first update
>>         >>> fails!
>>         >>>
>>         >>> I had been previously manually creating WiX installers
>>         (with the help of
>>         >>> a script built by one of my Windows-based users), and he
>>         discovered the
>>         >>> same problem when I migrated to jpackage. It turns out
>>         that the
>>         >>> jpackage-built WiX installers are missing an upgrade ID.
>>         I mentioned that
>>         >>> on this list a few weeks ago, but there was not any
>>         interest in
>>         >>> investigating the issue.
>>         >>>
>>         >>> So now I use jpackage to just create the application
>>         image, and then
>>         >>> separately use WiX directly to create an installer that
>>         can properly
>>         >>> upgrade older installations. You can find the GitHub
>>         Actions workflow that
>>         >>> drives the process here:
>>         >>>
>>         >>>
>>         https://github.com/Deep-Symmetry/beat-link-trigger/blob/master/.github/workflows/uberjar.yml#L84-L144
>>         <https://urldefense.com/v3/__https://github.com/Deep-Symmetry/beat-link-trigger/blob/master/.github/workflows/uberjar.yml*L84-L144__;Iw!!GqivPVa7Brio!LYzdLFh5v8DMnAKHvh4rZHAApveVQIcLFDgeEisOIhEJ4otLO9CwsNXryAngS7-AM7YV$>
>>         >>> <
>>         >>>
>>         https://github.com/Deep-Symmetry/beat-link-trigger/blob/master/.github/workflows/uberjar.yml#L84-L144
>>         <https://urldefense.com/v3/__https://github.com/Deep-Symmetry/beat-link-trigger/blob/master/.github/workflows/uberjar.yml*L84-L144__;Iw!!GqivPVa7Brio!LYzdLFh5v8DMnAKHvh4rZHAApveVQIcLFDgeEisOIhEJ4otLO9CwsNXryAngS7-AM7YV$>
>>         >>> The PowerShell script that runs jpackage and WiX is here:
>>         >>>
>>         >>>
>>         https://github.com/Deep-Symmetry/beat-link-trigger/blob/master/.github/scripts/build_msi.ps1
>>         <https://urldefense.com/v3/__https://github.com/Deep-Symmetry/beat-link-trigger/blob/master/.github/scripts/build_msi.ps1__;!!GqivPVa7Brio!LYzdLFh5v8DMnAKHvh4rZHAApveVQIcLFDgeEisOIhEJ4otLO9CwsNXryAngS2PBkRF4$>
>>         >>> <
>>         >>>
>>         https://github.com/Deep-Symmetry/beat-link-trigger/blob/master/.github/scripts/build_msi.ps1
>>         <https://urldefense.com/v3/__https://github.com/Deep-Symmetry/beat-link-trigger/blob/master/.github/scripts/build_msi.ps1__;!!GqivPVa7Brio!LYzdLFh5v8DMnAKHvh4rZHAApveVQIcLFDgeEisOIhEJ4otLO9CwsNXryAngS2PBkRF4$>
>>         >>> And the WIX template it uses is here:
>>         >>>
>>         >>>
>>         https://github.com/Deep-Symmetry/beat-link-trigger/blob/master/.github/resources/MSI%20Template.wxs
>>         <https://urldefense.com/v3/__https://github.com/Deep-Symmetry/beat-link-trigger/blob/master/.github/resources/MSI*20Template.wxs__;JQ!!GqivPVa7Brio!LYzdLFh5v8DMnAKHvh4rZHAApveVQIcLFDgeEisOIhEJ4otLO9CwsNXryAngS2imkvmE$>
>>         >>> <
>>         >>>
>>         https://github.com/Deep-Symmetry/beat-link-trigger/blob/master/.github/resources/MSI%20Template.wxs
>>         <https://urldefense.com/v3/__https://github.com/Deep-Symmetry/beat-link-trigger/blob/master/.github/resources/MSI*20Template.wxs__;JQ!!GqivPVa7Brio!LYzdLFh5v8DMnAKHvh4rZHAApveVQIcLFDgeEisOIhEJ4otLO9CwsNXryAngS2imkvmE$>
>>         >>> Hopefully this can help you, and perhaps jpackage can be
>>         updated to do
>>         >>> this on its own as well.
>>         >>>
>>         >>> Cheers,
>>         >>>
>>         >>>? ? ? ? ? -James
>>         >>>
>>
>


From jlahoda at openjdk.java.net  Fri Oct 30 08:30:58 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Fri, 30 Oct 2020 08:30:58 GMT
Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12
 [v5]
In-Reply-To: <RRMAPzh6xcVcxOj2S_VW_r50YvZz-3Imaj46bDi8e9U=.9347534e-d482-468a-8668-132d5516bb76@github.com>
References: <RRMAPzh6xcVcxOj2S_VW_r50YvZz-3Imaj46bDi8e9U=.9347534e-d482-468a-8668-132d5516bb76@github.com>
Message-ID: <OHQ8_LEssKt6sJ6hBaU5FgPwRv8w-e4WilONiCIGKp8=.fc91ab3e-1bc9-431a-904b-7fde02ee758d@github.com>

> This is an update to javac and javadoc, to introduce support for Preview APIs, and generally improve javac and javadoc behavior to more closely adhere to JEP 12.
> 
> The notable changes are:
> 
>  * adding support for Preview APIs (javac until now supported primarily only preview language features, and APIs associated with preview language features). This includes:
>      * the @PreviewFeature annotation has boolean attribute "reflective", which should be true for reflective Preview APIs, false otherwise. This replaces the existing "essentialAPI" attribute with roughly inverted meaning.
>      * the preview warnings for preview APIs are auto-suppressed as described in the JEP 12. E.g. the module that declares the preview API is free to use it without warnings
>  * improving error/warning messages. Please see [1] for a list of cases/examples.
>  * class files are only marked as preview if they are using a preview feature. [1] also shows if a class file is marked as preview or not.
>  * the PreviewFeature annotation has been moved to jdk.internal.javac package (originally was in the jdk.internal package).
>  * Preview API in JDK's javadoc no longer needs to specify @preview tag in the source files. javadoc will auto-generate a note for @PreviewFeature elements, see e.g. [2] and [3] (non-reflective and reflective API, respectively). A summary of preview elements is also provided [4]. Existing uses of @preview have been updated/removed.
>  * non-JDK javadoc is also enhanced to auto-generate preview notes for uses of Preview elements, and for declaring elements using preview language features [5].
>  
>  Please also see the CSR [6] for more information.
>  
>  [1] http://cr.openjdk.java.net/~jlahoda/8250768/JEP12-errors-warnings-v6.html
>  [2] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.base/java/lang/Record.html
>  [3] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.compiler/javax/lang/model/element/RecordComponentElement.html
>  [4] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/preview-list.html
>  [5] http://cr.openjdk.java.net/~jlahoda/8250768/test.javadoc.00/
>  [6] https://bugs.openjdk.java.net/browse/JDK-8250769

Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 44 commits:

 - Updating tests after records are a final feature.
 - Fixing tests.
 - Finalizing removal of record preview hooks.
 - Merging master into JDK-8250768
 - Reflecting review comments.
 - Merge branch 'master' into JDK-8250768
 - Removing unnecessary cast.
 - Using a more correct way to get URLs.
 - Reflecting review comments.
 - Merge branch 'JDK-8250768-dev' of https://github.com/lahodaj/jdk into JDK-8250768
 - ... and 34 more: https://git.openjdk.java.net/jdk/compare/ea26ff11...d76eb293

-------------

Changes: https://git.openjdk.java.net/jdk/pull/703/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=703&range=04
  Stats: 3012 lines in 142 files changed: 2521 ins; 260 del; 231 mod
  Patch: https://git.openjdk.java.net/jdk/pull/703.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/703/head:pull/703

PR: https://git.openjdk.java.net/jdk/pull/703

From mcimadamore at openjdk.java.net  Fri Oct 30 11:40:58 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 30 Oct 2020 11:40:58 GMT
Subject: RFR: 8254162: Implementation of Foreign-Memory Access API (Third
 Incubator) [v19]
In-Reply-To: <IngRk57F78UN3yySfo6IABbdwnMogGNdYrykh_3em-c=.b81f7478-015c-45ed-9788-58d7519a2770@github.com>
References: <IngRk57F78UN3yySfo6IABbdwnMogGNdYrykh_3em-c=.b81f7478-015c-45ed-9788-58d7519a2770@github.com>
Message-ID: <pHzgnh6T5mdzbu6WgI41ueFSFKbt4t6YEDW3_TEei9U=.848cd139-b31b-402c-8a8a-bf3113e0168f@github.com>

> This patch contains the changes associated with the third incubation round of the foreign memory access API incubation  (see JEP 393 [1]). This iteration focus on improving the usability of the API in 3 main ways:
> 
> * first, by providing a way to obtain truly *shared* segments, which can be accessed and closed concurrently from multiple threads
> * second, by providing a way to register a memory segment against a `Cleaner`, so as to have some (optional) guarantee that the memory will be deallocated, eventually
> * third, by not requiring users to dive deep into var handles when they first pick up the API; a new `MemoryAccess` class has been added, which defines several useful dereference routines; these are really just thin wrappers around memory access var handles, but they make the barrier of entry for using this API somewhat lower.
> 
> A big conceptual shift that comes with this API refresh is that the role of `MemorySegment` and `MemoryAddress` is not the same as it used to be; it used to be the case that a memory address could (sometimes, not always) have a back link to the memory segment which originated it; additionally, memory access var handles used `MemoryAddress` as a basic unit of dereference.
> 
> This has all changed as per this API refresh;  now a `MemoryAddress` is just a dumb carrier which wraps a pair of object/long addressing coordinates; `MemorySegment` has become the star of the show, as far as dereferencing memory is concerned. You cannot dereference memory if you don't have a segment. This improves usability in a number of ways - first, it is a lot easier to wrap native addresses (`long`, essentially) into a `MemoryAddress`; secondly, it is crystal clear what a client has to do in order to dereference memory: if a client has a segment, it can use that; otherwise, if the client only has an address, it will have to create a segment *unsafely* (this can be done by calling `MemoryAddress::asSegmentRestricted`).
> 
> A list of the API, implementation and test changes is provided below. If  you have any questions, or need more detailed explanations, I (and the  rest of the Panama team) will be happy to point at existing discussions,  and/or to provide the feedback required. 
> 
> A big thank to Erik Osterlund, Vladimir Ivanov and David Holmes, without whom the work on shared memory segment would not have been possible; also I'd like to thank Paul Sandoz, whose insights on API design have been very helpful in this journey.
> 
> Thanks 
> Maurizio 
> 
> Javadoc: 
> 
> http://cr.openjdk.java.net/~mcimadamore/8254162_v1/javadoc/jdk/incubator/foreign/package-summary.html
> 
> Specdiff: 
> 
> http://cr.openjdk.java.net/~mcimadamore/8254162_v1/specdiff/jdk/incubator/foreign/package-summary.html
> 
> CSR: 
> 
> https://bugs.openjdk.java.net/browse/JDK-8254163
> 
> 
> 
> ### API Changes
> 
> * `MemorySegment`
>   * drop factory for restricted segment (this has been moved to `MemoryAddress`, see below)
>   * added a no-arg factory for a native restricted segment representing entire native heap
>   * rename `withOwnerThread` to `handoff`
>   * add new `share` method, to create shared segments
>   * add new `registerCleaner` method, to register a segment against a cleaner
>   * add more helpers to create arrays from a segment e.g. `toIntArray`
>   * add some `asSlice` overloads (to make up for the fact that now segments are more frequently used as cursors)
>   * rename `baseAddress` to `address` (so that `MemorySegment` can implement `Addressable`)
> * `MemoryAddress`
>   * drop `segment` accessor
>   * drop `rebase` method and replace it with `segmentOffset` which returns the offset (a `long`) of this address relative to a given segment
> * `MemoryAccess`
>   * New class supporting several static dereference helpers; the helpers are organized by carrier and access mode, where a carrier is one of the usual suspect (a Java primitive, minus `boolean`); the access mode can be simple (e.g. access base address of given segment), or indexed, in which case the accessor takes a segment and either a low-level byte offset,or a high level logical index. The classification is reflected in the naming scheme (e.g. `getByte` vs. `getByteAtOffset` vs `getByteAtIndex`).
> * `MemoryHandles`
>   * drop `withOffset` combinator
>   * drop `withStride` combinator
>   * the basic memory access handle factory now returns a var handle which takes a `MemorySegment` and a `long` - from which it is easy to derive all the other handles using plain var handle combinators.
> * `Addressable`
>   * This is a new interface which is attached to entities which can be projected to a `MemoryAddress`. For now, both `MemoryAddress` and `MemorySegment` implement it; we have plans, with JEP 389 [2] to add more implementations. Clients can largely ignore this interface, which comes in really handy when defining native bindings with tools like `jextract`.
> * `MemoryLayouts`
>   * A new layout, for machine addresses, has been added to the mix.
> 
> 
> 
> ### Implementation changes
> 
> There are two main things to discuss here: support for shared segments, and the general simplification of the memory access var handle support.
> 
> #### Shared segments
> 
> The support for shared segments cuts in pretty deep in the VM. Support for shared segments is notoriously hard to achieve, at least in a way that guarantees optimal access performances. This is caused by the fact that, if a segment is shared, it would be possible for a thread to close it while another is accessing it.
> 
> After considering several options (see [3]), we zeroed onto an approach which is inspired by an happy idea that Andrew Haley had (and that he reminded me of at this year OpenJDK committer workshop - thanks!). The idea is that if we could *freeze* the world (e.g. with a GC pause), while a segment is closed, we could then prevent segments from being accessed concurrently to a close operation. For this to work, it  is crucial that no GC safepoints can occur between a segment liveness check and the access itself (otherwise it would be possible for the accessing thread to stop just right before an unsafe call). It also relies on the fact that hotspot/C2 should not be able to propagate loads across safepoints.
> 
> Sadly, none of these conditions seems to be valid in the current implementation, so we needed to resort to a bit of creativity. First, we noted that, if we could mark so called *scoped* method with an annotation, it would be very simply to check as to whether a thread was in the middle of a scoped method when we stopped the world for a close operation (btw, instead of stopping the world, we do a much more efficient, thread-local polling, thanks to JEP 312 [4]).
> 
> The question is, then, once we detect that a thread is accessing the very segment we're about to close, what should happen? We first experimented with a solution which would install an *asynchronous* exception on the accessing thread, thus making it fail. This solution has some desirable properties, in that a `close` operation always succeeds. Unfortunately the machinery for async exceptions is a bit fragile (e.g. not all the code in hotspot checks for async exceptions); to minimize risks, we decided to revert to a simpler strategy, where `close` might fail when it finds that another thread is accessing the segment being closed.
> 
> As written in the javadoc, this doesn't mean that clients should just catch and try again; an exception on `close` is a bug in the user code, likely arising from lack of synchronization, and should be treated as such.
> 
> In terms of gritty implementation, we needed to centralize memory access routines in a single place, so that we could have a set of routines closely mimicking the primitives exposed by `Unsafe` but which, in addition, also provided a liveness check. This way we could mark all these routines with the special `@Scoped` annotation, which tells the VM that something important is going on.
> 
> To achieve this, we created a new (autogenerated) class, called `ScopedMemoryAccess`. This class contains all the main memory access primitives (including bulk access, like `copyMemory`, or `setMemory`), and accepts, in addition to the access coordinates, also a scope object, which is tested before access. A reachability fence is also thrown in the mix to make sure that the scope is kept alive during access (which is important when registering segments against cleaners).
> 
> Of course, to make memory access safe, memory access var handles, byte buffer var handles, and byte buffer API should use the new `ScopedMemoryAccess` class instead of unsafe, so that a liveness check can be triggered (in case a scope is present).
> 
> `ScopedMemoryAccess` has a `closeScope` method, which initiates the thread-local handshakes, and returns `true` if the handshake completed successfully.
> 
> The implementation of `MemoryScope` (now significantly simplified from what we had before), has two implementations, one for confined segments and one for shared segments; the main difference between the two is what happens when the scope is closed; a confined segment sets a boolean flag to false, and returns, whereas a shared segment goes into a `CLOSING` state, then starts the handshake, and then updates the state again, to either `CLOSED` or `ALIVE` depending on whether the handshake was successful or not. Note that when a shared segment is in the `CLOSING` state, `MemorySegment::isAlive` will still return `true`, while the liveness check upon memory access will fail.
> 
> #### Memory access var handles overhaul
> 
> The key realization here was that if all memory access var handles took a coordinate pair of `MemorySegment` and `long`, all other access types could be derived from this basic var handle form.
> 
> This allowed us to remove the on-the-fly var handle generation, and to simply derive structural access var handles (such as those obtained by calling `MemoryLayout::varHandle`) using *plain* var handle combinators, so that e.g. additional offset is injected into a base memory access var handle.
> 
> This also helped in simplifying the implementation by removing the special `withStride` and `withOffset` combinators, which previously needed low-level access on the innards of the memory access var handle. All that code is now gone.
> 
> #### Test changes
> 
> Not much to see here - most of the tests needed to be updated because of the API changes. Some were beefed up (like the array test, since now segments can be projected into many different kinds of arrays). A test has been added to test the `Cleaner` functionality, and another stress test has been added for shared segments (`TestHandshake`). Some of the microbenchmarks also needed some tweaks - and some of them were also updated to also test performance in the shared segment case.
> 
> [1] - https://openjdk.java.net/jeps/393
> [2] - https://openjdk.java.net/jeps/389
> [3] - https://mail.openjdk.java.net/pipermail/panama-dev/2020-May/009004.html
> [4] - https://openjdk.java.net/jeps/312

Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits:

 - Merge branch 'master' into 8254162
 - Fix issues with derived buffers and IO operations
 - More 32-bit fixes for TestLayouts
 - * Add final to MappedByteBuffer::SCOPED_MEMORY_ACCESS field
   * Tweak TestLayouts to make it 32-bit friendly after recent MemoryLayouts tweaks
 - Remove TestMismatch from 32-bit problem list
 - Merge branch 'master' into 8254162
 - Tweak javadoc for MemorySegment::mapFromPath
   Tweak alignment for long/double Java layouts on 32 bits platforms
 - Merge branch 'master' into 8254162
 - Address review comment for scoped memory access makefile
 - Address CSR comments
 - ... and 15 more: https://git.openjdk.java.net/jdk/compare/e48016b1...bd400615

-------------

Changes: https://git.openjdk.java.net/jdk/pull/548/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=548&range=18
  Stats: 7618 lines in 80 files changed: 4892 ins; 1537 del; 1189 mod
  Patch: https://git.openjdk.java.net/jdk/pull/548.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/548/head:pull/548

PR: https://git.openjdk.java.net/jdk/pull/548

From scolebourne at openjdk.java.net  Fri Oct 30 11:45:54 2020
From: scolebourne at openjdk.java.net (Stephen Colebourne)
Date: Fri, 30 Oct 2020 11:45:54 GMT
Subject: RFR: 8247781: Day periods support
In-Reply-To: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
References: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
Message-ID: <LzBaAtUIc3RzanmZDGnDcbgwEAc1j194SuSGamn_--o=.0a3c2199-ee99-4e4d-95c6-e9295b84ba2a@github.com>

On Thu, 29 Oct 2020 15:59:51 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Hi,
> 
> Please review the changes for the subject issue. This is to enhance the java.time package to support day periods, such as "in the morning", defined in CLDR. It will add a new pattern character 'B' and its supporting builder method. The motivation and its spec are in this CSR:
> 
> https://bugs.openjdk.java.net/browse/JDK-8254629
> 
> Naoto

Changes requested by scolebourne (Author).

test/jdk/java/time/test/java/time/format/TestDateTimeFormatterBuilder.java line 981:

> 979: 
> 980:             {"B", "Text(DayPeriod,SHORT)"},
> 981:             {"BB", "Text(DayPeriod,SHORT)"},

"BB" and "BBB" are not defined to do anything in the CSR. Java should match CLDR/LDML rules here.

test/jdk/java/time/test/java/time/format/TestDateTimeFormatterBuilder.java line 540:

> 538:         builder.appendDayPeriodText(TextStyle.FULL);
> 539:         DateTimeFormatter f = builder.toFormatter();
> 540:         assertEquals(f.toString(), "Text(DayPeriod,FULL)");

This should be "DayPeriod(FULL)", because an end user might create a `TemporalField` with the name "DayPeriod" and the toString should be unique.

src/java.base/share/classes/java/time/format/Parsed.java line 352:

> 350:                     (fieldValues.containsKey(MINUTE_OF_HOUR) ? fieldValues.get(MINUTE_OF_HOUR) : 0);
> 351:             if (!dayPeriod.includes(mod)) {
> 352:                 throw new DateTimeException("Conflict found: " + changeField + " conflict with day period");

"conflict with day period" -> "conflicts with day period"

Should also include `changeValue` and ideally the valid range

src/java.base/share/classes/java/time/format/Parsed.java line 472:

> 470:         }
> 471:         if (dayPeriod != null) {
> 472:             if (fieldValues.containsKey(HOUR_OF_DAY)) {

Are we certain that the CLDR data does not contain day periods based on minutes as well as hours? This logic does not check against MINUTE_OF_HOUR for example. The logic also conflicts with the spec Javadoc that says MINUTE_OF_HOUR is validated.

src/java.base/share/classes/java/time/format/Parsed.java line 497:

> 495:                         AMPM_OF_DAY.checkValidValue(ap);
> 496:                     }
> 497:                     updateCheckDayPeriodConflict(AMPM_OF_DAY, midpoint / 720);

No need to put `AMPM_OF_DAY` back in here because you've already resolved it to `HOUR_OF_DAY` and `MINUTE_OF_HOUR`. There probably does need to be validation to check that the day period agrees with the AM/PM value.

src/java.base/share/classes/java/time/format/Parsed.java line 500:

> 498:                 }
> 499:             }
> 500:         }

Looking at the existing logic, the `AMPM_OF_DAY` field is completely ignored if there is no `HOUR_OF_AMPM` field. Thus, there is no validation to check `AMPM_OF_DAY` against `HOUR_OF_DAY`. This seems odd. (AMPM_OF_DAY = 0 and HOUR_OF_DAY=18 does not look like it throws an exception, when it probably should).

On solution would be for `AMPM_OF_DAY` to be resolved to a day period at line 427, checking for conflicts with any parsed day period. (a small bug fix behavioural change)

src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 1489:

> 1487:         Objects.requireNonNull(style, "style");
> 1488:         if (style != TextStyle.FULL && style != TextStyle.SHORT && style != TextStyle.NARROW) {
> 1489:             throw new IllegalArgumentException("Style must be either full, short, or narrow");

Nothing in the Javadoc describes this behaviour. It would make more sense to map FULL_STANDALONE to FULL and so on and not throw an exception.

src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 1869:

> 1867:                 } else if (cur == 'B') {
> 1868:                     switch (count) {
> 1869:                         case 1, 2, 3 -> appendDayPeriodText(TextStyle.SHORT);

I think this should be `case 1`. The 2 and 3 are not in the Javadoc, and I don't think they are in LDML. I note that patterns G and E do this though, so there is precedent.

src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 5094:

> 5092:         @Override
> 5093:         public String toString() {
> 5094:             return "Text(DayPeriod," + textStyle + ")";

Should be "DayPeriod(FULL)" to avoid possible `toString` clashes with the text printer/parser

src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 5153:

> 5151:          * minute-of-day of "at" or "from" attribute
> 5152:          */
> 5153:         private final long from;

Could these three instance variables be `int` ?

src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 5252:

> 5250:                         .getLocaleResources(CalendarDataUtility.findRegionOverride(l));
> 5251:                 String dayPeriodRules = lr.getRules()[1];
> 5252:                 final Map<DayPeriod, Long> pm = new ConcurrentHashMap<>();

`pm` is a confusing variable name given this method deals with AM/PM concept.

src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 5289:

> 5287:                 .filter(dp -> dp.getIndex() == index)
> 5288:                 .findAny()
> 5289:                 .orElseThrow();

Isn't is likely that the user could pass in an unexpected `Locale`? If so, then this needs an exception message.

src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 5137:

> 5135:      * <a href="https://www.unicode.org/reports/tr35/tr35-dates.html#dayPeriods">DayPeriod</a> defined in CLDR.
> 5136:      */
> 5137:     static final class DayPeriod {

Looks like this class could be `ValueBased` as per other PRs

test/jdk/java/time/test/java/time/format/TestDateTimeFormatterBuilder.java line 712:

> 710:         }
> 711:     }
> 712: 

There don't seem to be any tests of the resolver logic in `Parsed`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/938

From mcimadamore at openjdk.java.net  Fri Oct 30 11:55:05 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 30 Oct 2020 11:55:05 GMT
Subject: RFR: 8254231: Implementation of Foreign Linker API (Incubator)
 [v13]
In-Reply-To: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
References: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
Message-ID: <fgCT42R3bNCE2WD6zEyKjcU3_NaomVb0JbIT1cDlSew=.8296020c-1ede-497e-b29b-737161d79ebc@github.com>

> This patch contains the changes associated with the first incubation round of the foreign linker access API incubation
> (see JEP 389 [1]). This work is meant to sit on top of the foreign memory access support (see JEP 393 [2] and associated pull request [3]).
> 
> The main goal of this API is to provide a way to call native functions from Java code without the need of intermediate JNI glue code. In order to do this, native calls are modeled through the MethodHandle API. I suggest reading the writeup [4] I put together few weeks ago, which illustrates what the foreign linker support is, and how it should be used by clients.
> 
> Disclaimer: the pull request mechanism isn't great at managing *dependent* reviews. For this reasons, I'm attaching a webrev which contains only the differences between this PR and the memory access PR. I will be periodically uploading new webrevs, as new iterations come out, to try and make the life of reviewers as simple as possible.
> 
> A big thank to Jorn Vernee and Vladimir Ivanov - they are the main architects of all the hotspot changes you see here, and without their help, the foreign linker support wouldn't be what it is today. As usual, a big thank to Paul Sandoz, who provided many insights (often by trying the bits first hand).
> 
> Thanks
> Maurizio
> 
> Webrev:
> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/webrev
> 
> Javadoc:
> 
> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/javadoc/jdk/incubator/foreign/package-summary.html
> 
> Specdiff (relative to [3]):
> 
> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/specdiff_delta/overview-summary.html
> 
> CSR:
> 
> https://bugs.openjdk.java.net/browse/JDK-8254232
> 
> 
> 
> ### API Changes
> 
> The API changes are actually rather slim:
> 
> * `LibraryLookup`
>   * This class allows clients to lookup symbols in native libraries; the interface is fairly simple; you can load a library by name, or absolute path, and then lookup symbols on that library.
> * `FunctionDescriptor`
>   * This is an abstraction that is very similar, in spirit, to `MethodType`; it is, at its core, an aggregate of memory layouts for the function arguments/return type. A function descriptor is used to describe the signature of a native function.
> * `CLinker`
>   * This is the real star of the show. A `CLinker` has two main methods: `downcallHandle` and `upcallStub`; the first takes a native symbol (as obtained from `LibraryLookup`), a `MethodType` and a `FunctionDescriptor` and returns a `MethodHandle` instance which can be used to call the target native symbol. The second takes an existing method handle, and a `FunctionDescriptor` and returns a new `MemorySegment` corresponding to a code stub allocated by the VM which acts as a trampoline from native code to the user-provided method handle. This is very useful for implementing upcalls.
>    * This class also contains the various layout constants that should be used by clients when describing native signatures (e.g. `C_LONG` and friends); these layouts contain additional ABI classfication information (in the form of layout attributes) which is used by the runtime to *infer* how Java arguments should be shuffled for the native call to take place.
>   * Finally, this class provides some helper functions e.g. so that clients can convert Java strings into C strings and back.
> * `NativeScope`
>   * This is an helper class which allows clients to group together logically related allocations; that is, rather than allocating separate memory segments using separate *try-with-resource* constructs, a `NativeScope` allows clients to use a _single_ block, and allocate all the required segments there. This is not only an usability boost, but also a performance boost, since not all allocation requests will be turned into `malloc` calls.
> * `MemorySegment`
>   * Only one method added here - namely `handoff(NativeScope)` which allows a segment to be transferred onto an existing native scope.
> 
> ### Safety
> 
> The foreign linker API is intrinsically unsafe; many things can go wrong when requesting a native method handle. For instance, the description of the native signature might be wrong (e.g. have too many arguments) - and the runtime has, in the general case, no way to detect such mismatches. For these reasons, obtaining a `CLinker` instance is a *restricted* operation, which can be enabled by specifying the usual JDK property `-Dforeign.restricted=permit` (as it's the case for other restricted method in the foreign memory API).
> 
> ### Implementation changes
> 
> The Java changes associated with `LibraryLookup` are relative straightforward; the only interesting thing to note here is that library loading does _not_ depend on class loaders, so `LibraryLookup` is not subject to the same restrictions which apply to JNI library loading (e.g. same library cannot be loaded by different classloaders).
> 
> As for `NativeScope` the changes are again relatively straightforward; it is an API which sits neatly on top of the foreign meory access API, providing some kind of allocation service which shares the same underlying memory segment(s), and turns an allocation request into a segment slice, which is a much less expensive operation. `NativeScope` comes in two variants: there are native scopes for which the allocation size is known a priori, and native scopes which can grow - these two schemes are implemented by two separate subclasses of `AbstractNativeScopeImpl`.
> 
> Of course the bulk of the changes are to support the `CLinker` downcall/upcall routines. These changes cut pretty deep into the JVM; I'll briefly summarize the goal of some of this changes - for further details, Jorn has put together a detailed writeup which explains the rationale behind the VM support, with some references to the code [5].
> 
> The main idea behind foreign linker is to infer, given a Java method type (expressed as a `MethodType` instance) and the description of the signature of a native function (expressed as a `FunctionDescriptor` instance) a _recipe_ that can be used to turn a Java call into the corresponding native call targeting the requested native function.
> 
> This inference scheme can be defined in a pretty straightforward fashion by looking at the various ABI specifications (for instance, see [6] for the SysV ABI, which is the one used on Linux/Mac). The various `CallArranger` classes, of which we have a flavor for each supported platform, do exactly that kind of inference.
> 
> For the inference process to work, we need to attach extra information to memory layouts; it is no longer sufficient to know e.g. that a layout is 32/64 bits - we need to know whether it is meant to represent a floating point value, or an integral value; this knowledge is required because floating points are passed in different registers by most ABIs. For this reason, `CLinker` offers a set of pre-baked, platform-dependent layout constants which contain the required classification attributes (e.g. a `Clinker.TypeKind` enum value). The runtime extracts this attribute, and performs classification accordingly.
> 
> A native call is decomposed into a sequence of basic, primitive operations, called `Binding` (see the great javadoc on the `Binding.java` class for more info). There are many such bindings - for instance the `Move` binding is used to move a value into a specific machine register/stack slot. So, the main job of the various `CallingArranger` classes is to determine, given a Java `MethodType` and `FunctionDescriptor` what is the set of bindings associated with the downcall/upcall.
> 
> At the heart of the foreign linker support is the `ProgrammableInvoker` class. This class effectively generates a `MethodHandle` which follows the steps described by the various bindings obtained by `CallArranger`. There are actually various strategies to interpret these bindings - listed below:
> 
> * basic intepreted mode; in this mode, all bindings are interpreted using a stack-based machine written in Java (see `BindingInterpreter`), except for the `Move` bindings. For these bindings, the move is implemented by allocating a *buffer* (whose size is ABI specific) and by moving all the lowered values into positions within this buffer. The buffer is then passed to a piece of assembly code inside the VM which takes values from the buffer and moves them in their expected registers/stack slots (note that each position in the buffer corresponds to a different register). This is the most general invocation mode, the more "customizable" one, but also the slowest - since for every call there is some extra allocation which takes place.
> 
> * specialized interpreted mode; same as before, but instead of interpreting the bindings with a stack-based interpreter, we generate a method handle chain which effectively interprets all the bindings (again, except `Move` ones).
> 
> * intrinsified mode; this is typically used in combination with the specialized interpreted mode described above (although it can also be used with the Java-based binding interpreter). The goal here is to remove the buffer allocation and copy by introducing an additional JVM intrinsic. If a native call recipe is constant (e.g. the set of bindings is constant, which is probably the case if the native method handle is stored in a `static`, `final` field), then the VM can generate specialized assembly code which interprets the `Move` binding without the need to go for an intermediate buffer. This gives us back performances that are on par with JNI.
> 
> For upcalls, the support is not (yet) as advanced, and only the basic interpreted mode is available there. We plan to add support for intrinsified modes there as well, which should considerably boost perfomances (probably well beyond what JNI can offer at the moment, since the upcall support in JNI is not very well optimized).
> 
> Again, for more readings on the internals of the foreign linker support, please refer to [5].
> 
> #### Test changes
> 
> Many new tests have been added to validate the foreign linker support; we have high level tests (see `StdLibTest`) which aim at testing the linker from the perspective of code that clients could write. But we also have deeper combinatorial tests (see `TestUpcall` and `TestDowncall`) which are meant to stress every corner of the ABI implementation. There are also some great tests (see the `callarranger` folder) which test the various `CallArranger`s for all the possible platforms; these tests adopt more of a white-box approach - that is, instead of treating the linker machinery as a black box and verify that the support works by checking that the native call returned the results we expected, these tests aims at checking that the set of bindings generated by the call arranger is correct. This also mean that we can test the classification logic for Windows, Mac and Linux regardless of the platform we're executing on.
> 
> Some additional microbenchmarks have been added to compare the performances of downcall/upcall with JNI.
> 
> [1] - https://openjdk.java.net/jeps/389
> [2] - https://openjdk.java.net/jeps/393
> [3] - https://git.openjdk.java.net/jdk/pull/548
> [4] - https://github.com/openjdk/panama-foreign/blob/foreign-jextract/doc/panama_ffi.md
> [5] - http://cr.openjdk.java.net/~jvernee/docs/Foreign-abi%20downcall%20intrinsics%20technical%20description.html

Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 58 commits:

 - Merge branch '8254162' into 8254231_linker
 - Merge branch 'master' into 8254162
 - Fix issues with derived buffers and IO operations
 - More 32-bit fixes for TestLayouts
 - * Add final to MappedByteBuffer::SCOPED_MEMORY_ACCESS field
   * Tweak TestLayouts to make it 32-bit friendly after recent MemoryLayouts tweaks
 - Remove TestMismatch from 32-bit problem list
 - Merge branch 'master' into 8254162
 - Tweak javadoc for MemorySegment::mapFromPath
   Tweak alignment for long/double Java layouts on 32 bits platforms
 - Merge branch 'master' into 8254162
 - Address review comment for scoped memory access makefile
 - ... and 48 more: https://git.openjdk.java.net/jdk/compare/e48016b1...4a2c2240

-------------

Changes: https://git.openjdk.java.net/jdk/pull/634/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=634&range=12
  Stats: 75299 lines in 271 files changed: 72395 ins; 1615 del; 1289 mod
  Patch: https://git.openjdk.java.net/jdk/pull/634.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/634/head:pull/634

PR: https://git.openjdk.java.net/jdk/pull/634

From mcimadamore at openjdk.java.net  Fri Oct 30 12:16:02 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 30 Oct 2020 12:16:02 GMT
Subject: RFR: 8254231: Implementation of Foreign Linker API (Incubator)
 [v14]
In-Reply-To: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
References: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
Message-ID: <P8t0K2fKjwwudHg7xDwbiyVM8plG0ADy34fzxBgROps=.b07a6d4a-660f-4642-9f6c-67027d21f348@github.com>

> This patch contains the changes associated with the first incubation round of the foreign linker access API incubation
> (see JEP 389 [1]). This work is meant to sit on top of the foreign memory access support (see JEP 393 [2] and associated pull request [3]).
> 
> The main goal of this API is to provide a way to call native functions from Java code without the need of intermediate JNI glue code. In order to do this, native calls are modeled through the MethodHandle API. I suggest reading the writeup [4] I put together few weeks ago, which illustrates what the foreign linker support is, and how it should be used by clients.
> 
> Disclaimer: the pull request mechanism isn't great at managing *dependent* reviews. For this reasons, I'm attaching a webrev which contains only the differences between this PR and the memory access PR. I will be periodically uploading new webrevs, as new iterations come out, to try and make the life of reviewers as simple as possible.
> 
> A big thank to Jorn Vernee and Vladimir Ivanov - they are the main architects of all the hotspot changes you see here, and without their help, the foreign linker support wouldn't be what it is today. As usual, a big thank to Paul Sandoz, who provided many insights (often by trying the bits first hand).
> 
> Thanks
> Maurizio
> 
> Webrev:
> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/webrev
> 
> Javadoc:
> 
> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/javadoc/jdk/incubator/foreign/package-summary.html
> 
> Specdiff (relative to [3]):
> 
> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/specdiff_delta/overview-summary.html
> 
> CSR:
> 
> https://bugs.openjdk.java.net/browse/JDK-8254232
> 
> 
> 
> ### API Changes
> 
> The API changes are actually rather slim:
> 
> * `LibraryLookup`
>   * This class allows clients to lookup symbols in native libraries; the interface is fairly simple; you can load a library by name, or absolute path, and then lookup symbols on that library.
> * `FunctionDescriptor`
>   * This is an abstraction that is very similar, in spirit, to `MethodType`; it is, at its core, an aggregate of memory layouts for the function arguments/return type. A function descriptor is used to describe the signature of a native function.
> * `CLinker`
>   * This is the real star of the show. A `CLinker` has two main methods: `downcallHandle` and `upcallStub`; the first takes a native symbol (as obtained from `LibraryLookup`), a `MethodType` and a `FunctionDescriptor` and returns a `MethodHandle` instance which can be used to call the target native symbol. The second takes an existing method handle, and a `FunctionDescriptor` and returns a new `MemorySegment` corresponding to a code stub allocated by the VM which acts as a trampoline from native code to the user-provided method handle. This is very useful for implementing upcalls.
>    * This class also contains the various layout constants that should be used by clients when describing native signatures (e.g. `C_LONG` and friends); these layouts contain additional ABI classfication information (in the form of layout attributes) which is used by the runtime to *infer* how Java arguments should be shuffled for the native call to take place.
>   * Finally, this class provides some helper functions e.g. so that clients can convert Java strings into C strings and back.
> * `NativeScope`
>   * This is an helper class which allows clients to group together logically related allocations; that is, rather than allocating separate memory segments using separate *try-with-resource* constructs, a `NativeScope` allows clients to use a _single_ block, and allocate all the required segments there. This is not only an usability boost, but also a performance boost, since not all allocation requests will be turned into `malloc` calls.
> * `MemorySegment`
>   * Only one method added here - namely `handoff(NativeScope)` which allows a segment to be transferred onto an existing native scope.
> 
> ### Safety
> 
> The foreign linker API is intrinsically unsafe; many things can go wrong when requesting a native method handle. For instance, the description of the native signature might be wrong (e.g. have too many arguments) - and the runtime has, in the general case, no way to detect such mismatches. For these reasons, obtaining a `CLinker` instance is a *restricted* operation, which can be enabled by specifying the usual JDK property `-Dforeign.restricted=permit` (as it's the case for other restricted method in the foreign memory API).
> 
> ### Implementation changes
> 
> The Java changes associated with `LibraryLookup` are relative straightforward; the only interesting thing to note here is that library loading does _not_ depend on class loaders, so `LibraryLookup` is not subject to the same restrictions which apply to JNI library loading (e.g. same library cannot be loaded by different classloaders).
> 
> As for `NativeScope` the changes are again relatively straightforward; it is an API which sits neatly on top of the foreign meory access API, providing some kind of allocation service which shares the same underlying memory segment(s), and turns an allocation request into a segment slice, which is a much less expensive operation. `NativeScope` comes in two variants: there are native scopes for which the allocation size is known a priori, and native scopes which can grow - these two schemes are implemented by two separate subclasses of `AbstractNativeScopeImpl`.
> 
> Of course the bulk of the changes are to support the `CLinker` downcall/upcall routines. These changes cut pretty deep into the JVM; I'll briefly summarize the goal of some of this changes - for further details, Jorn has put together a detailed writeup which explains the rationale behind the VM support, with some references to the code [5].
> 
> The main idea behind foreign linker is to infer, given a Java method type (expressed as a `MethodType` instance) and the description of the signature of a native function (expressed as a `FunctionDescriptor` instance) a _recipe_ that can be used to turn a Java call into the corresponding native call targeting the requested native function.
> 
> This inference scheme can be defined in a pretty straightforward fashion by looking at the various ABI specifications (for instance, see [6] for the SysV ABI, which is the one used on Linux/Mac). The various `CallArranger` classes, of which we have a flavor for each supported platform, do exactly that kind of inference.
> 
> For the inference process to work, we need to attach extra information to memory layouts; it is no longer sufficient to know e.g. that a layout is 32/64 bits - we need to know whether it is meant to represent a floating point value, or an integral value; this knowledge is required because floating points are passed in different registers by most ABIs. For this reason, `CLinker` offers a set of pre-baked, platform-dependent layout constants which contain the required classification attributes (e.g. a `Clinker.TypeKind` enum value). The runtime extracts this attribute, and performs classification accordingly.
> 
> A native call is decomposed into a sequence of basic, primitive operations, called `Binding` (see the great javadoc on the `Binding.java` class for more info). There are many such bindings - for instance the `Move` binding is used to move a value into a specific machine register/stack slot. So, the main job of the various `CallingArranger` classes is to determine, given a Java `MethodType` and `FunctionDescriptor` what is the set of bindings associated with the downcall/upcall.
> 
> At the heart of the foreign linker support is the `ProgrammableInvoker` class. This class effectively generates a `MethodHandle` which follows the steps described by the various bindings obtained by `CallArranger`. There are actually various strategies to interpret these bindings - listed below:
> 
> * basic intepreted mode; in this mode, all bindings are interpreted using a stack-based machine written in Java (see `BindingInterpreter`), except for the `Move` bindings. For these bindings, the move is implemented by allocating a *buffer* (whose size is ABI specific) and by moving all the lowered values into positions within this buffer. The buffer is then passed to a piece of assembly code inside the VM which takes values from the buffer and moves them in their expected registers/stack slots (note that each position in the buffer corresponds to a different register). This is the most general invocation mode, the more "customizable" one, but also the slowest - since for every call there is some extra allocation which takes place.
> 
> * specialized interpreted mode; same as before, but instead of interpreting the bindings with a stack-based interpreter, we generate a method handle chain which effectively interprets all the bindings (again, except `Move` ones).
> 
> * intrinsified mode; this is typically used in combination with the specialized interpreted mode described above (although it can also be used with the Java-based binding interpreter). The goal here is to remove the buffer allocation and copy by introducing an additional JVM intrinsic. If a native call recipe is constant (e.g. the set of bindings is constant, which is probably the case if the native method handle is stored in a `static`, `final` field), then the VM can generate specialized assembly code which interprets the `Move` binding without the need to go for an intermediate buffer. This gives us back performances that are on par with JNI.
> 
> For upcalls, the support is not (yet) as advanced, and only the basic interpreted mode is available there. We plan to add support for intrinsified modes there as well, which should considerably boost perfomances (probably well beyond what JNI can offer at the moment, since the upcall support in JNI is not very well optimized).
> 
> Again, for more readings on the internals of the foreign linker support, please refer to [5].
> 
> #### Test changes
> 
> Many new tests have been added to validate the foreign linker support; we have high level tests (see `StdLibTest`) which aim at testing the linker from the perspective of code that clients could write. But we also have deeper combinatorial tests (see `TestUpcall` and `TestDowncall`) which are meant to stress every corner of the ABI implementation. There are also some great tests (see the `callarranger` folder) which test the various `CallArranger`s for all the possible platforms; these tests adopt more of a white-box approach - that is, instead of treating the linker machinery as a black box and verify that the support works by checking that the native call returned the results we expected, these tests aims at checking that the set of bindings generated by the call arranger is correct. This also mean that we can test the classification logic for Windows, Mac and Linux regardless of the platform we're executing on.
> 
> Some additional microbenchmarks have been added to compare the performances of downcall/upcall with JNI.
> 
> [1] - https://openjdk.java.net/jeps/389
> [2] - https://openjdk.java.net/jeps/393
> [3] - https://git.openjdk.java.net/jdk/pull/548
> [4] - https://github.com/openjdk/panama-foreign/blob/foreign-jextract/doc/panama_ffi.md
> [5] - http://cr.openjdk.java.net/~jvernee/docs/Foreign-abi%20downcall%20intrinsics%20technical%20description.html

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Fix typo in upcall helper for aarch64

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/634/files
  - new: https://git.openjdk.java.net/jdk/pull/634/files/4a2c2240..98718866

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=634&range=13
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=634&range=12-13

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/634.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/634/head:pull/634

PR: https://git.openjdk.java.net/jdk/pull/634

From herrick at openjdk.java.net  Fri Oct 30 12:47:08 2020
From: herrick at openjdk.java.net (Andy Herrick)
Date: Fri, 30 Oct 2020 12:47:08 GMT
Subject: RFR: JDK-8254920: Application launched with jpackage produced
 .exe crashes JVM [v2]
In-Reply-To: <Tcn6BwsjMBJ4KTFov7i4VN7kVJasVeTEXGyguR4RVUw=.1f8c589f-0ade-447b-be0d-b5178e15752b@github.com>
References: <Tcn6BwsjMBJ4KTFov7i4VN7kVJasVeTEXGyguR4RVUw=.1f8c589f-0ade-447b-be0d-b5178e15752b@github.com>
Message-ID: <Onmh1iYhLXHbF-wCy79dgWr6fsNMDSoIBsXDlTJIG0c=.0190573e-d1ed-4afe-8d90-9a0518e095fa@github.com>

> JVM

Andy Herrick has updated the pull request incrementally with one additional commit since the last revision:

  JDK-8254920: Application launched with jpackage produced .exe crashes JVM

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/940/files
  - new: https://git.openjdk.java.net/jdk/pull/940/files/196a9def..3d83b99b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=940&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=940&range=00-01

  Stats: 16 lines in 2 files changed: 3 ins; 0 del; 13 mod
  Patch: https://git.openjdk.java.net/jdk/pull/940.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/940/head:pull/940

PR: https://git.openjdk.java.net/jdk/pull/940

From jvernee at openjdk.java.net  Fri Oct 30 12:54:02 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Fri, 30 Oct 2020 12:54:02 GMT
Subject: RFR: 8255128: linux x86 build failure with libJNIPoint.c
Message-ID: <MImCUxGlxSb-NpBy2yuetfm2dqujCVEFNl4JNytZ_zk=.228962eb-1e0d-49d6-b30c-289500d55454@github.com>

Guard libJNIPoint.c impl in `#ifdef _LP64` block

This fixes a 32-bit build error

-------------

Commit messages:
 - Guard libJNIPoint.c impl in #ifdef _LP64 block

Changes: https://git.openjdk.java.net/jdk/pull/956/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=956&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8255128
  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/956.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/956/head:pull/956

PR: https://git.openjdk.java.net/jdk/pull/956

From jvernee at openjdk.java.net  Fri Oct 30 14:32:01 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Fri, 30 Oct 2020 14:32:01 GMT
Subject: RFR: 8255398: Add a dropReturn MethodHandle combinator [v3]
In-Reply-To: <pTFmPu611NS1jY9NRR3P3s_fnjejISp2Ca8MCwnhpS0=.5389b31a-cb02-4601-969f-2f3a07ce0eb5@github.com>
References: <zYoRWf3w-WVtBQZCV97D4sPBDGLFNQ8-JCrq4NXCQ4Q=.f5c6fb56-bc8b-44f4-987b-725dd70e6ace@github.com>
 <8ccDRraptUr5-NjCqXmtVas3-_geXfS8dVdwQeMBdMk=.da14d5ec-c738-43dc-9868-52169950e159@github.com>
 <z2Tj5arbsqySej0LLfPDCxhnndf2me4cEY26RUSOLLA=.41359c26-a489-40ca-8061-a1f670eb80b2@github.com>
 <yewLzMO7cUrnU2OZwHOxdhhU2RTgj2WmQHgLy4YP5DE=.a72cd93b-4803-42f7-b979-506721250d07@github.com>
 <BBTb2SmjGX0gUXbCm3q4OOjUBx4XNDRCgRSOVTG03dE=.1fd2b43e-f67b-4102-a357-d08db58e588b@github.com>
 <cWtzYwXdDEoC4v8eRBaGhY5aAI62pThg8nGQDK7d5x0=.b0e01bd2-ce7f-4054-8566-793f20dd2ca7@github.com>
 <N4S_va-a90fKTuRoEFZSmAZTVlscp7v72DHJqqA0C8k=.4e20fb13-ab89-4d74-8151-5eddf612ab9d@github.com>
 <pTFmPu611NS1jY9NRR3P3s_fnjejISp2Ca8MCwnhpS0=.5389b31a-cb02-4601-969f-2f3a07ce0eb5@github.com>
Message-ID: <7cRCKgHsz9eulPRrx4YaxROgH0Dctw-fy5UckOQCYow=.e45f4177-30a6-4877-a89e-48c487be8825@github.com>

On Tue, 27 Oct 2020 10:40:40 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>>> ?`dropReturn` seemed like a good choice since we already have `dropArguments`. WRT changing to `MethodHandle::changeReturnType`...
>> 
>> That's a very reasonable point.  People might look for `dropRT` after they find `dropAs`.  And `MHs` is designed as a large-ish set of utility methods.
>> 
>> I agree that adding `MH::changeRT` is a slippery slope; it tends to lift more of the MT API onto MH, and it starts to put new stuff into the smaller MH API; that was my bad.
>> 
>> But (in the spirit of brainstorming, and agreeing with your present proposal), I'll suggest a separate idea to think about.  Use a HOFP API to give easy access to the entire `MT` API all in one go, by reifying the `MH.type` property as a temporary (lambda argument):
>> 
>> MethodHandle mapType(MethodHandle mh, UnaryOperator<MethodType> fn) {
>>    return mh.asType(fn.apply(mh.type()));
>> }
>> 
>> This also suggests a possible argument transform utility, a sort of mini-version of Charlie Nutter's MH builder API:
>> 
>> MethodHandle mapArguments(MethodHandle mh, UnaryOperator<List<ArgumentValue<?>>> fn) {
>>   var args = mh.type().argumentList().stream().map(t -> makeArg(t)).asList();
>>   args = fn.apply(args);
>>   ? do stuff to re-weave mh with the resulting argument transforms ?
>> }
>> public sealed interface ArgumentValue<T> {
>>   Class<T> type();
>>   <U> ArgumentValue<U> asType(Class<U> newType);
>>   ? other stuff for pre-applying MHs ? 
>> }
>
> It's an interesting idea. It turns something like:
> 
> target = target.asType(target.type().changeReturnType(void.class));
> 
> Into 
> 
> target = target.asType(mt -> mt.changeReturnType(void.class));
> 
> I.e. it removes the need to reference the target handle/type twice, which prevents them from potentially going out of sync (which seems more likely when you have multiple MethodTypes and MethodHandles flying around). Also, it feels unnecessary that, I have to re-specify `target`'s type as a base, when I'm asking `target` to change it's type. This also solves that.

CSR is now provisional. Please review: https://bugs.openjdk.java.net/browse/JDK-8255398

Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/866

From psandoz at openjdk.java.net  Fri Oct 30 15:26:03 2020
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Fri, 30 Oct 2020 15:26:03 GMT
Subject: RFR: 8254354: Add an asExact() VarHandle combinator [v9]
In-Reply-To: <uTje1Aig7YoVD5weI_IyD0yZdCFlNsIiSJjyzUQIXHM=.fcd5a9fa-e186-4776-a968-b07f4552b4e9@github.com>
References: <gJ1pTeZZC7tbtwiRsrHcZ1ydfTQhr1MPndGrnGolf14=.dd935929-4f22-4e41-9e0d-99a592ac46b7@github.com>
 <uTje1Aig7YoVD5weI_IyD0yZdCFlNsIiSJjyzUQIXHM=.fcd5a9fa-e186-4776-a968-b07f4552b4e9@github.com>
Message-ID: <lgz1VUKPSgaoURH9_ducL4gAAP498ncimLq4NCMfhAo=.2fa5aebf-ff0f-47df-af05-5e19f54b504e@github.com>

On Thu, 29 Oct 2020 18:14:05 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Hi,
>> 
>> This patch adds an asExact() combinator to VarHandle, that will return a new VarHandle that performs exact type checks, similar to MethodHandle::invokeExact, to help developers catch inexact VarHandle usage, which can lead to performance degradation.
>> 
>> This is implemented using a boolean flag in VarForm. If the flag is set, the exact type of the invocation is checked against the exact type in the VarForm. If there is a mismatch, a WrongMethodTypeException is thrown.
>> 
>> Other than that, there is also an asGeneric() combinator added that does the inverse operation (thanks to R?mi for the suggestion). I've also added The `@Hidden` annotation to the VarHandleGuards methods, as well as a type-checking helper method called from the generic invocation lambda form, so that the stack trace we get points at the location where the VarHandle is being used.
>> 
>> Thanks,
>> Jorn
>> 
>> CSR link: https://bugs.openjdk.java.net/browse/JDK-8255375
>
> Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision:
> 
>  - Update Javadoc, and rename asExact and asGeneric to withInvokeExactBehaviour and withInvokeBehaviour
>  - Merge branch 'master' into Exact_VarHandle
>  - Use AccessType ordinal in guard checks instead of the AccessMode ordinal
>  - Update accessModeType to use the AccessType ordinal directly.
>  - Add benchmarks
>  - - Update javadoc
>    - Make isExact() public
>  - Fixes failing tests, and enable verifier on Exact test
>  - Fix whitespace
>  - Comment out VarHandleGuards generator code
>  - Makes exactness a property of a VarHandle, not a VarForm, since the latter are shared. Use handle.accessModeType to get the exact type of the VarHandle.
>  - ... and 2 more: https://git.openjdk.java.net/jdk/compare/08226775...3c707bc7

Looks good. There is just one difference between the spec and implementation. The spec states: 
> If this VarHandle already has invoke{-exact} behaviour this VarHandle is returned.

I prefer this behaviour, but feel free to update the spec if you like e.g. If ... already has XXX then a new VH with exactly the same behaviour as this VH is returned.

I just realized i used "behaviour", the english spelling. We should use the US spelling, "behavior", which is more commonly used throughout the JDK documentation.

-------------

Marked as reviewed by psandoz (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/843

From jvernee at openjdk.java.net  Fri Oct 30 16:13:06 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Fri, 30 Oct 2020 16:13:06 GMT
Subject: RFR: 8254354: Add an asExact() VarHandle combinator [v10]
In-Reply-To: <gJ1pTeZZC7tbtwiRsrHcZ1ydfTQhr1MPndGrnGolf14=.dd935929-4f22-4e41-9e0d-99a592ac46b7@github.com>
References: <gJ1pTeZZC7tbtwiRsrHcZ1ydfTQhr1MPndGrnGolf14=.dd935929-4f22-4e41-9e0d-99a592ac46b7@github.com>
Message-ID: <tXHj1JySTy9DlgKjFjopTmTfx0aZmBP2DqiphVZRG0o=.23ebacd7-d8f8-4f74-b448-9a793437ef92@github.com>

> Hi,
> 
> This patch adds an asExact() combinator to VarHandle, that will return a new VarHandle that performs exact type checks, similar to MethodHandle::invokeExact, to help developers catch inexact VarHandle usage, which can lead to performance degradation.
> 
> This is implemented using a boolean flag in VarForm. If the flag is set, the exact type of the invocation is checked against the exact type in the VarForm. If there is a mismatch, a WrongMethodTypeException is thrown.
> 
> Other than that, there is also an asGeneric() combinator added that does the inverse operation (thanks to R?mi for the suggestion). I've also added The `@Hidden` annotation to the VarHandleGuards methods, as well as a type-checking helper method called from the generic invocation lambda form, so that the stack trace we get points at the location where the VarHandle is being used.
> 
> Thanks,
> Jorn
> 
> CSR link: https://bugs.openjdk.java.net/browse/JDK-8255375

Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

  - behaviour -> behaviour
  - Return same VarHandle instance when instance is already exact/non-exact

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/843/files
  - new: https://git.openjdk.java.net/jdk/pull/843/files/3c707bc7..ff4c08d2

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=843&range=09
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=843&range=08-09

  Stats: 172 lines in 10 files changed: 32 ins; 0 del; 140 mod
  Patch: https://git.openjdk.java.net/jdk/pull/843.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/843/head:pull/843

PR: https://git.openjdk.java.net/jdk/pull/843

From jvernee at openjdk.java.net  Fri Oct 30 16:17:06 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Fri, 30 Oct 2020 16:17:06 GMT
Subject: RFR: 8254354: Add an asExact() VarHandle combinator [v11]
In-Reply-To: <gJ1pTeZZC7tbtwiRsrHcZ1ydfTQhr1MPndGrnGolf14=.dd935929-4f22-4e41-9e0d-99a592ac46b7@github.com>
References: <gJ1pTeZZC7tbtwiRsrHcZ1ydfTQhr1MPndGrnGolf14=.dd935929-4f22-4e41-9e0d-99a592ac46b7@github.com>
Message-ID: <NR1F0WMnkPod8dLn2mb-Xw_VkcY4pJUQltrfz9GQqNU=.30ab1722-a9c6-48e3-ab09-d9908aa2ed2e@github.com>

> Hi,
> 
> This patch adds an asExact() combinator to VarHandle, that will return a new VarHandle that performs exact type checks, similar to MethodHandle::invokeExact, to help developers catch inexact VarHandle usage, which can lead to performance degradation.
> 
> This is implemented using a boolean flag in VarForm. If the flag is set, the exact type of the invocation is checked against the exact type in the VarForm. If there is a mismatch, a WrongMethodTypeException is thrown.
> 
> Other than that, there is also an asGeneric() combinator added that does the inverse operation (thanks to R?mi for the suggestion). I've also added The `@Hidden` annotation to the VarHandleGuards methods, as well as a type-checking helper method called from the generic invocation lambda form, so that the stack trace we get points at the location where the VarHandle is being used.
> 
> Thanks,
> Jorn
> 
> CSR link: https://bugs.openjdk.java.net/browse/JDK-8255375

Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

  behaviour -> behavior in javadoc as well

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/843/files
  - new: https://git.openjdk.java.net/jdk/pull/843/files/ff4c08d2..d49e3f30

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=843&range=10
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=843&range=09-10

  Stats: 17 lines in 1 file changed: 0 ins; 0 del; 17 mod
  Patch: https://git.openjdk.java.net/jdk/pull/843.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/843/head:pull/843

PR: https://git.openjdk.java.net/jdk/pull/843

From jvernee at openjdk.java.net  Fri Oct 30 17:58:54 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Fri, 30 Oct 2020 17:58:54 GMT
Subject: Withdrawn: 8255128: linux x86 build failure with libJNIPoint.c
In-Reply-To: <MImCUxGlxSb-NpBy2yuetfm2dqujCVEFNl4JNytZ_zk=.228962eb-1e0d-49d6-b30c-289500d55454@github.com>
References: <MImCUxGlxSb-NpBy2yuetfm2dqujCVEFNl4JNytZ_zk=.228962eb-1e0d-49d6-b30c-289500d55454@github.com>
Message-ID: <fJBFetdJwWGgjhRTowUL9LmNa4-6_8cB-0X8gR3br7o=.04e47313-6b80-4fee-b6e1-4ad8169242bc@github.com>

On Fri, 30 Oct 2020 12:47:59 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Guard libJNIPoint.c impl in `#ifdef _LP64` block
> 
> This fixes a 32-bit build error

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/956

From bchristi at openjdk.java.net  Fri Oct 30 19:37:05 2020
From: bchristi at openjdk.java.net (Brent Christian)
Date: Fri, 30 Oct 2020 19:37:05 GMT
Subject: RFR: 8255690:  &nbsp in StringBuilder.subSequence
Message-ID: <0kTP-h7Kt8I3sfBnT8_zQOITECOyuvNDeh_brOF_Bgw=.61217b67-fc0c-4798-a738-48c241d20af2@github.com>

There are a couple of stray "&nbsp"'s in the StringBuilder.subSequence() documentation, which should be removed.  The updated doc build looks good.

-------------

Commit messages:
 - remove nbsp from AbstractStringBuilder.subSequence()

Changes: https://git.openjdk.java.net/jdk/pull/963/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=963&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8255690
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/963.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/963/head:pull/963

PR: https://git.openjdk.java.net/jdk/pull/963

From lancea at openjdk.java.net  Fri Oct 30 19:40:59 2020
From: lancea at openjdk.java.net (Lance Andersen)
Date: Fri, 30 Oct 2020 19:40:59 GMT
Subject: RFR: 8255690:  &nbsp in StringBuilder.subSequence
In-Reply-To: <0kTP-h7Kt8I3sfBnT8_zQOITECOyuvNDeh_brOF_Bgw=.61217b67-fc0c-4798-a738-48c241d20af2@github.com>
References: <0kTP-h7Kt8I3sfBnT8_zQOITECOyuvNDeh_brOF_Bgw=.61217b67-fc0c-4798-a738-48c241d20af2@github.com>
Message-ID: <L__Bmh0mJCrt-pTEoPYULut-zn9xPfxcrazhg1Hb7X8=.92860e86-b213-4dfb-8f6a-930d6de6405d@github.com>

On Fri, 30 Oct 2020 19:30:14 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> There are a couple of stray "&nbsp"'s in the StringBuilder.subSequence() documentation, which should be removed.  The updated doc build looks good.

Looks fine Brent

-------------

Marked as reviewed by lancea (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/963

From bchristi at openjdk.java.net  Fri Oct 30 19:55:04 2020
From: bchristi at openjdk.java.net (Brent Christian)
Date: Fri, 30 Oct 2020 19:55:04 GMT
Subject: RFR: 8214561: Use {@systemProperty} for definition of
 "java.util.prefs.PreferencesFactory" system property
Message-ID: <Lb2mhIgm6eTOFGp1yaE5opxe2HD_BS9CEb2QNooSb2M=.87a4b349-cd65-4972-8c55-8cc8da2ce92b@github.com>

Using the {@systemProperty} tag for the "java.util.prefs.PreferencesFactory" system property will allow it to be found in the main javadoc search index.

The updated doc build looks good.

-------------

Commit messages:
 - 8214561: Use {@systemProperty} for definition of java.util.prefs.PreferencesFactory system property

Changes: https://git.openjdk.java.net/jdk/pull/965/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=965&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8214561
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/965.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/965/head:pull/965

PR: https://git.openjdk.java.net/jdk/pull/965

From lancea at openjdk.java.net  Fri Oct 30 20:07:54 2020
From: lancea at openjdk.java.net (Lance Andersen)
Date: Fri, 30 Oct 2020 20:07:54 GMT
Subject: RFR: 8214561: Use {@systemProperty} for definition of
 "java.util.prefs.PreferencesFactory" system property
In-Reply-To: <Lb2mhIgm6eTOFGp1yaE5opxe2HD_BS9CEb2QNooSb2M=.87a4b349-cd65-4972-8c55-8cc8da2ce92b@github.com>
References: <Lb2mhIgm6eTOFGp1yaE5opxe2HD_BS9CEb2QNooSb2M=.87a4b349-cd65-4972-8c55-8cc8da2ce92b@github.com>
Message-ID: <_hZ_ew58TZP3I_zBS3ahvOpiDE00Ov5bb2ThUtliOuE=.465c7015-bbdc-4b31-9b0b-0298e0d40aab@github.com>

On Fri, 30 Oct 2020 19:47:14 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> Using the {@systemProperty} tag for the "java.util.prefs.PreferencesFactory" system property will allow it to be found in the main javadoc search index.
> 
> The updated doc build looks good.

Marked as reviewed by lancea (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/965

From bchristi at openjdk.java.net  Fri Oct 30 20:39:57 2020
From: bchristi at openjdk.java.net (Brent Christian)
Date: Fri, 30 Oct 2020 20:39:57 GMT
Subject: Integrated: 8255690:  &nbsp in StringBuilder.subSequence
In-Reply-To: <0kTP-h7Kt8I3sfBnT8_zQOITECOyuvNDeh_brOF_Bgw=.61217b67-fc0c-4798-a738-48c241d20af2@github.com>
References: <0kTP-h7Kt8I3sfBnT8_zQOITECOyuvNDeh_brOF_Bgw=.61217b67-fc0c-4798-a738-48c241d20af2@github.com>
Message-ID: <gt7xFuuTSD8dXThmb_Jipbro53UpYaraQpWUr5f_1M8=.79b762c7-4c6b-4fee-a7b4-5361e336f9a7@github.com>

On Fri, 30 Oct 2020 19:30:14 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> There are a couple of stray "&nbsp"'s in the StringBuilder.subSequence() documentation, which should be removed.  The updated doc build looks good.

This pull request has now been integrated.

Changeset: 98a69ede
Author:    Brent Christian <bchristi at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/98a69ede
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8255690: &nbsp in StringBuilder.subSequence

Reviewed-by: lancea

-------------

PR: https://git.openjdk.java.net/jdk/pull/963

From bchristi at openjdk.java.net  Fri Oct 30 20:39:56 2020
From: bchristi at openjdk.java.net (Brent Christian)
Date: Fri, 30 Oct 2020 20:39:56 GMT
Subject: RFR: 8255690:  &nbsp in StringBuilder.subSequence
In-Reply-To: <L__Bmh0mJCrt-pTEoPYULut-zn9xPfxcrazhg1Hb7X8=.92860e86-b213-4dfb-8f6a-930d6de6405d@github.com>
References: <0kTP-h7Kt8I3sfBnT8_zQOITECOyuvNDeh_brOF_Bgw=.61217b67-fc0c-4798-a738-48c241d20af2@github.com>
 <L__Bmh0mJCrt-pTEoPYULut-zn9xPfxcrazhg1Hb7X8=.92860e86-b213-4dfb-8f6a-930d6de6405d@github.com>
Message-ID: <1mf6pchXCp2KtAW6nUT3gVgYY6JfRMFaHdxZXFg9vOs=.7a58453f-0511-49ea-a03c-83f6a9606170@github.com>

On Fri, 30 Oct 2020 19:38:45 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> There are a couple of stray "&nbsp"'s in the StringBuilder.subSequence() documentation, which should be removed.  The updated doc build looks good.
>
> Looks fine Brent

Thanks, Lance

-------------

PR: https://git.openjdk.java.net/jdk/pull/963

From bchristi at openjdk.java.net  Fri Oct 30 20:40:55 2020
From: bchristi at openjdk.java.net (Brent Christian)
Date: Fri, 30 Oct 2020 20:40:55 GMT
Subject: Integrated: 8214561: Use {@systemProperty} for definition of
 "java.util.prefs.PreferencesFactory" system property
In-Reply-To: <Lb2mhIgm6eTOFGp1yaE5opxe2HD_BS9CEb2QNooSb2M=.87a4b349-cd65-4972-8c55-8cc8da2ce92b@github.com>
References: <Lb2mhIgm6eTOFGp1yaE5opxe2HD_BS9CEb2QNooSb2M=.87a4b349-cd65-4972-8c55-8cc8da2ce92b@github.com>
Message-ID: <JmCDn_-77W4tHr8RTAY_vDrQwRkpn6W3boYkq4V6RAo=.cb622e6b-e8f6-421c-a05e-39130d21d429@github.com>

On Fri, 30 Oct 2020 19:47:14 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> Using the {@systemProperty} tag for the "java.util.prefs.PreferencesFactory" system property will allow it to be found in the main javadoc search index.
> 
> The updated doc build looks good.

This pull request has now been integrated.

Changeset: 0f486033
Author:    Brent Christian <bchristi at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/0f486033
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8214561: Use {@systemProperty} for definition of "java.util.prefs.PreferencesFactory" system property

Reviewed-by: lancea

-------------

PR: https://git.openjdk.java.net/jdk/pull/965

From asemenyuk at openjdk.java.net  Fri Oct 30 21:07:59 2020
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Fri, 30 Oct 2020 21:07:59 GMT
Subject: RFR: JDK-8254920: Application launched with jpackage produced
 .exe crashes JVM [v2]
In-Reply-To: <Onmh1iYhLXHbF-wCy79dgWr6fsNMDSoIBsXDlTJIG0c=.0190573e-d1ed-4afe-8d90-9a0518e095fa@github.com>
References: <Tcn6BwsjMBJ4KTFov7i4VN7kVJasVeTEXGyguR4RVUw=.1f8c589f-0ade-447b-be0d-b5178e15752b@github.com>
 <Onmh1iYhLXHbF-wCy79dgWr6fsNMDSoIBsXDlTJIG0c=.0190573e-d1ed-4afe-8d90-9a0518e095fa@github.com>
Message-ID: <KW6FZgJYnHYsdicMHeVPm_XSpfbYuZRpC3qsavowQz0=.f4198eaa-3105-4e84-8965-c01fb33c8d40@github.com>

On Fri, 30 Oct 2020 12:47:08 GMT, Andy Herrick <herrick at openjdk.org> wrote:

>> JVM
>
> Andy Herrick has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8254920: Application launched with jpackage produced .exe crashes JVM

Marked as reviewed by asemenyuk (Committer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/940

From naoto at openjdk.java.net  Fri Oct 30 21:43:14 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 30 Oct 2020 21:43:14 GMT
Subject: RFR: 8247781: Day periods support [v2]
In-Reply-To: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
References: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
Message-ID: <o3tZADaROPx5aE1AUUdqMy2mFKYSn4y--SXAYSf7JCY=.d67a2be3-86c5-48b8-8134-b52fb2189456@github.com>

> Hi,
> 
> Please review the changes for the subject issue. This is to enhance the java.time package to support day periods, such as "in the morning", defined in CLDR. It will add a new pattern character 'B' and its supporting builder method. The motivation and its spec are in this CSR:
> 
> https://bugs.openjdk.java.net/browse/JDK-8254629
> 
> Naoto

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Addressed the following comments:
  - https://github.com/openjdk/jdk/pull/938#discussion_r515003422
  - https://github.com/openjdk/jdk/pull/938#discussion_r515005296
  - https://github.com/openjdk/jdk/pull/938#discussion_r515008862
  - https://github.com/openjdk/jdk/pull/938#discussion_r515030268
  - https://github.com/openjdk/jdk/pull/938#discussion_r515030880
  - https://github.com/openjdk/jdk/pull/938#discussion_r515032002
  - https://github.com/openjdk/jdk/pull/938#discussion_r515036803
  - https://github.com/openjdk/jdk/pull/938#discussion_r515037626
  - https://github.com/openjdk/jdk/pull/938#discussion_r515038069
  - https://github.com/openjdk/jdk/pull/938#discussion_r515039056

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/938/files
  - new: https://git.openjdk.java.net/jdk/pull/938/files/7ac5fa03..6e1eade7

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=938&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=938&range=00-01

  Stats: 99 lines in 3 files changed: 48 ins; 2 del; 49 mod
  Patch: https://git.openjdk.java.net/jdk/pull/938.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/938/head:pull/938

PR: https://git.openjdk.java.net/jdk/pull/938

From naoto at openjdk.java.net  Fri Oct 30 21:43:21 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 30 Oct 2020 21:43:21 GMT
Subject: RFR: 8247781: Day periods support [v2]
In-Reply-To: <LzBaAtUIc3RzanmZDGnDcbgwEAc1j194SuSGamn_--o=.0a3c2199-ee99-4e4d-95c6-e9295b84ba2a@github.com>
References: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
 <LzBaAtUIc3RzanmZDGnDcbgwEAc1j194SuSGamn_--o=.0a3c2199-ee99-4e4d-95c6-e9295b84ba2a@github.com>
Message-ID: <DnMwydDzsyXWpVxNeFK2hfasKlwH8-JWH2S5INzdBBY=.4bc6f1f9-eff0-4aa5-bc39-ac6652686544@github.com>

On Fri, 30 Oct 2020 10:33:28 GMT, Stephen Colebourne <scolebourne at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Addressed the following comments:
>>   - https://github.com/openjdk/jdk/pull/938#discussion_r515003422
>>   - https://github.com/openjdk/jdk/pull/938#discussion_r515005296
>>   - https://github.com/openjdk/jdk/pull/938#discussion_r515008862
>>   - https://github.com/openjdk/jdk/pull/938#discussion_r515030268
>>   - https://github.com/openjdk/jdk/pull/938#discussion_r515030880
>>   - https://github.com/openjdk/jdk/pull/938#discussion_r515032002
>>   - https://github.com/openjdk/jdk/pull/938#discussion_r515036803
>>   - https://github.com/openjdk/jdk/pull/938#discussion_r515037626
>>   - https://github.com/openjdk/jdk/pull/938#discussion_r515038069
>>   - https://github.com/openjdk/jdk/pull/938#discussion_r515039056
>
> test/jdk/java/time/test/java/time/format/TestDateTimeFormatterBuilder.java line 981:
> 
>> 979: 
>> 980:             {"B", "Text(DayPeriod,SHORT)"},
>> 981:             {"BB", "Text(DayPeriod,SHORT)"},
> 
> "BB" and "BBB" are not defined to do anything in the CSR. Java should match CLDR/LDML rules here.

Fixed.

> test/jdk/java/time/test/java/time/format/TestDateTimeFormatterBuilder.java line 540:
> 
>> 538:         builder.appendDayPeriodText(TextStyle.FULL);
>> 539:         DateTimeFormatter f = builder.toFormatter();
>> 540:         assertEquals(f.toString(), "Text(DayPeriod,FULL)");
> 
> This should be "DayPeriod(FULL)", because an end user might create a `TemporalField` with the name "DayPeriod" and the toString should be unique.

Fixed.

> src/java.base/share/classes/java/time/format/Parsed.java line 352:
> 
>> 350:                     (fieldValues.containsKey(MINUTE_OF_HOUR) ? fieldValues.get(MINUTE_OF_HOUR) : 0);
>> 351:             if (!dayPeriod.includes(mod)) {
>> 352:                 throw new DateTimeException("Conflict found: " + changeField + " conflict with day period");
> 
> "conflict with day period" -> "conflicts with day period"
> 
> Should also include `changeValue` and ideally the valid range

Fixed.

> src/java.base/share/classes/java/time/format/Parsed.java line 472:
> 
>> 470:         }
>> 471:         if (dayPeriod != null) {
>> 472:             if (fieldValues.containsKey(HOUR_OF_DAY)) {
> 
> Are we certain that the CLDR data does not contain day periods based on minutes as well as hours? This logic does not check against MINUTE_OF_HOUR for example. The logic also conflicts with the spec Javadoc that says MINUTE_OF_HOUR is validated.

MINUTE_OF_HOUR without HOUR_OF_DAY/HOUR_OF_AMPM may not make any sense, so it is only validated in updateCheckDayPeriodConflict.

> src/java.base/share/classes/java/time/format/Parsed.java line 500:
> 
>> 498:                 }
>> 499:             }
>> 500:         }
> 
> Looking at the existing logic, the `AMPM_OF_DAY` field is completely ignored if there is no `HOUR_OF_AMPM` field. Thus, there is no validation to check `AMPM_OF_DAY` against `HOUR_OF_DAY`. This seems odd. (AMPM_OF_DAY = 0 and HOUR_OF_DAY=18 does not look like it throws an exception, when it probably should).
> 
> On solution would be for `AMPM_OF_DAY` to be resolved to a day period at line 427, checking for conflicts with any parsed day period. (a small bug fix behavioural change)

There are cases where a period crosses midnight, e.g., 23:00-04:00 so it cannot validate am/pm, so I decided to just override ampm with dayperiod without validating.

> src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 1489:
> 
>> 1487:         Objects.requireNonNull(style, "style");
>> 1488:         if (style != TextStyle.FULL && style != TextStyle.SHORT && style != TextStyle.NARROW) {
>> 1489:             throw new IllegalArgumentException("Style must be either full, short, or narrow");
> 
> Nothing in the Javadoc describes this behaviour. It would make more sense to map FULL_STANDALONE to FULL and so on and not throw an exception.

Fixed.

> src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 1869:
> 
>> 1867:                 } else if (cur == 'B') {
>> 1868:                     switch (count) {
>> 1869:                         case 1, 2, 3 -> appendDayPeriodText(TextStyle.SHORT);
> 
> I think this should be `case 1`. The 2 and 3 are not in the Javadoc, and I don't think they are in LDML. I note that patterns G and E do this though, so there is precedent.

Fixed.

> src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 5094:
> 
>> 5092:         @Override
>> 5093:         public String toString() {
>> 5094:             return "Text(DayPeriod," + textStyle + ")";
> 
> Should be "DayPeriod(FULL)" to avoid possible `toString` clashes with the text printer/parser

Fixed.

> src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 5153:
> 
>> 5151:          * minute-of-day of "at" or "from" attribute
>> 5152:          */
>> 5153:         private final long from;
> 
> Could these three instance variables be `int` ?

It shares the code with other TempralFields which is Long, so it is more fit to take long imo.

> src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 5252:
> 
>> 5250:                         .getLocaleResources(CalendarDataUtility.findRegionOverride(l));
>> 5251:                 String dayPeriodRules = lr.getRules()[1];
>> 5252:                 final Map<DayPeriod, Long> pm = new ConcurrentHashMap<>();
> 
> `pm` is a confusing variable name given this method deals with AM/PM concept.

Fixed.

> src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 5289:
> 
>> 5287:                 .filter(dp -> dp.getIndex() == index)
>> 5288:                 .findAny()
>> 5289:                 .orElseThrow();
> 
> Isn't is likely that the user could pass in an unexpected `Locale`? If so, then this needs an exception message.

Although it will never throw an exception due to unknown locale (am/pm is always available), I added a DateTimeException w/ message supplier to orElseThrow().

> src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 5137:
> 
>> 5135:      * <a href="https://www.unicode.org/reports/tr35/tr35-dates.html#dayPeriods">DayPeriod</a> defined in CLDR.
>> 5136:      */
>> 5137:     static final class DayPeriod {
> 
> Looks like this class could be `ValueBased` as per other PRs

Fixed.

> test/jdk/java/time/test/java/time/format/TestDateTimeFormatterBuilder.java line 712:
> 
>> 710:         }
>> 711:     }
>> 712: 
> 
> There don't seem to be any tests of the resolver logic in `Parsed`.

Test case added.

-------------

PR: https://git.openjdk.java.net/jdk/pull/938

From naoto at openjdk.java.net  Fri Oct 30 22:03:08 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 30 Oct 2020 22:03:08 GMT
Subject: RFR: 8247781: Day periods support [v3]
In-Reply-To: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
References: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
Message-ID: <GLJiZaszK-Ut5Ylcw7XH5fZlSdthxIsntMr6HenWf6c=.d16b1861-d000-4338-adef-80d5cd82b29f@github.com>

> Hi,
> 
> Please review the changes for the subject issue. This is to enhance the java.time package to support day periods, such as "in the morning", defined in CLDR. It will add a new pattern character 'B' and its supporting builder method. The motivation and its spec are in this CSR:
> 
> https://bugs.openjdk.java.net/browse/JDK-8254629
> 
> Naoto

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Fixed exception messages.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/938/files
  - new: https://git.openjdk.java.net/jdk/pull/938/files/6e1eade7..29c47afc

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=938&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=938&range=01-02

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/938.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/938/head:pull/938

PR: https://git.openjdk.java.net/jdk/pull/938

From almatvee at openjdk.java.net  Fri Oct 30 22:18:57 2020
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Fri, 30 Oct 2020 22:18:57 GMT
Subject: RFR: JDK-8254920: Application launched with jpackage produced
 .exe crashes JVM [v2]
In-Reply-To: <Onmh1iYhLXHbF-wCy79dgWr6fsNMDSoIBsXDlTJIG0c=.0190573e-d1ed-4afe-8d90-9a0518e095fa@github.com>
References: <Tcn6BwsjMBJ4KTFov7i4VN7kVJasVeTEXGyguR4RVUw=.1f8c589f-0ade-447b-be0d-b5178e15752b@github.com>
 <Onmh1iYhLXHbF-wCy79dgWr6fsNMDSoIBsXDlTJIG0c=.0190573e-d1ed-4afe-8d90-9a0518e095fa@github.com>
Message-ID: <s9aF6ot-bFs60vUhwvA8OgcDgvOSqr5Nq1-bjyx6zzk=.ff4da716-b2b3-40b2-8ad0-0e804d17044d@github.com>

On Fri, 30 Oct 2020 12:47:08 GMT, Andy Herrick <herrick at openjdk.org> wrote:

>> JVM
>
> Andy Herrick has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8254920: Application launched with jpackage produced .exe crashes JVM

Marked as reviewed by almatvee (Committer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/940

From naoto at openjdk.java.net  Fri Oct 30 22:31:00 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 30 Oct 2020 22:31:00 GMT
Subject: RFR: 8255671: Bidi.reorderVisually has misleading exception messages
Message-ID: <irFBtIXgezDQi9atpQK8wSsmX2xHxLmzCh9oRK4E7KM=.e12f1d21-76cf-402f-a2e7-fbc59853acf5@github.com>

Hi,

Please review this simple message fix that follows JDK-8255242.

Naoto

-------------

Commit messages:
 - 8255671: Bidi.reorderVisually has misleading exception messages

Changes: https://git.openjdk.java.net/jdk/pull/973/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=973&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8255671
  Stats: 35 lines in 2 files changed: 32 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/973.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/973/head:pull/973

PR: https://git.openjdk.java.net/jdk/pull/973

From psandoz at openjdk.java.net  Fri Oct 30 23:09:56 2020
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Fri, 30 Oct 2020 23:09:56 GMT
Subject: RFR: 8254354: Add a withInvokeExactBehavior() VarHandle
 combinator [v11]
In-Reply-To: <NR1F0WMnkPod8dLn2mb-Xw_VkcY4pJUQltrfz9GQqNU=.30ab1722-a9c6-48e3-ab09-d9908aa2ed2e@github.com>
References: <gJ1pTeZZC7tbtwiRsrHcZ1ydfTQhr1MPndGrnGolf14=.dd935929-4f22-4e41-9e0d-99a592ac46b7@github.com>
 <NR1F0WMnkPod8dLn2mb-Xw_VkcY4pJUQltrfz9GQqNU=.30ab1722-a9c6-48e3-ab09-d9908aa2ed2e@github.com>
Message-ID: <_JKuq3pd8kOtysfeizyCJCDjusYDiBQQMPL2ecMtfTc=.09f389a3-625f-4c52-8b5e-063a7f09511d@github.com>

On Fri, 30 Oct 2020 16:17:06 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Hi,
>> 
>> This patch adds an asExact() combinator to VarHandle, that will return a new VarHandle that performs exact type checks, similar to MethodHandle::invokeExact, to help developers catch inexact VarHandle usage, which can lead to performance degradation.
>> 
>> This is implemented using a boolean flag in VarForm. If the flag is set, the exact type of the invocation is checked against the exact type in the VarForm. If there is a mismatch, a WrongMethodTypeException is thrown.
>> 
>> Other than that, there is also an asGeneric() combinator added that does the inverse operation (thanks to R?mi for the suggestion). I've also added The `@Hidden` annotation to the VarHandleGuards methods, as well as a type-checking helper method called from the generic invocation lambda form, so that the stack trace we get points at the location where the VarHandle is being used.
>> 
>> Thanks,
>> Jorn
>> 
>> CSR link: https://bugs.openjdk.java.net/browse/JDK-8255375
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   behaviour -> behavior in javadoc as well

src/java.base/share/classes/java/lang/invoke/VarHandle.java line 1601:

> 1599:      * @apiNote
> 1600:      * Invoke-exact behavior guarantees that that upon invocation of an access mode method
> 1601:      * the types an arity of the arguments must match the {@link #accessModeType(AccessMode) access mode type},

s/an arity/and arity/

-------------

PR: https://git.openjdk.java.net/jdk/pull/843

From joehw at openjdk.java.net  Fri Oct 30 23:27:58 2020
From: joehw at openjdk.java.net (Joe Wang)
Date: Fri, 30 Oct 2020 23:27:58 GMT
Subject: RFR: 8255671: Bidi.reorderVisually has misleading exception
 messages
In-Reply-To: <irFBtIXgezDQi9atpQK8wSsmX2xHxLmzCh9oRK4E7KM=.e12f1d21-76cf-402f-a2e7-fbc59853acf5@github.com>
References: <irFBtIXgezDQi9atpQK8wSsmX2xHxLmzCh9oRK4E7KM=.e12f1d21-76cf-402f-a2e7-fbc59853acf5@github.com>
Message-ID: <sobH8ulbPEZIoTwNOGCgBvIMY7pK0dOL98GZuYermH0=.8e4f9c9f-a931-4845-a819-8b11e007f3d5@github.com>

On Fri, 30 Oct 2020 22:23:30 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Hi,
> 
> Please review this simple message fix that follows JDK-8255242.
> 
> Naoto

Marked as reviewed by joehw (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/973

From github.com+27751938+amcap1712 at openjdk.java.net  Sat Oct 31 15:37:01 2020
From: github.com+27751938+amcap1712 at openjdk.java.net (Kartik Ohri)
Date: Sat, 31 Oct 2020 15:37:01 GMT
Subject: RFR: 8248122: java.base should not handle JavaFX application in a
 specific way
Message-ID: <TjUfO--mHAmH_-39IOJk3J5Bp9BxTbAqMC4lglo9Mko=.87ae64a6-8f15-4726-af0d-3358c4bef38b@github.com>

JavaFX is no longer a part of OpenJDK. It makes sense to not treat it specially in the JDK. Hence, refactoring the Launcher class to remove JavaFX specific code.

Further investigation reveals that some JavaFX specific code is also present in the `javadoc` tool. For instance,
https://github.com/openjdk/jdk/blob/master/src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/BaseOptions.java#L90-L96
https://github.com/openjdk/jdk/blob/master/src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/BaseOptions.java#L347-L353
I think we should remove this code as well and the related tests for it.

-------------

Commit messages:
 - Refactor LauncherHelper to remove JavaFX specific handling

Changes: https://git.openjdk.java.net/jdk/pull/978/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=978&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8248122
  Stats: 156 lines in 1 file changed: 0 ins; 154 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/978.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/978/head:pull/978

PR: https://git.openjdk.java.net/jdk/pull/978

From alanb at openjdk.java.net  Sat Oct 31 15:58:54 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sat, 31 Oct 2020 15:58:54 GMT
Subject: RFR: 8248122: java.base should not handle JavaFX application in a
 specific way
In-Reply-To: <TjUfO--mHAmH_-39IOJk3J5Bp9BxTbAqMC4lglo9Mko=.87ae64a6-8f15-4726-af0d-3358c4bef38b@github.com>
References: <TjUfO--mHAmH_-39IOJk3J5Bp9BxTbAqMC4lglo9Mko=.87ae64a6-8f15-4726-af0d-3358c4bef38b@github.com>
Message-ID: <IszYOjN7ScHGcDzfZGTxpDByoVKqCTXkce5cCZw0TFA=.23a94c40-59c7-4247-b015-09ac3279de9a@github.com>

On Sat, 31 Oct 2020 15:25:13 GMT, Kartik Ohri <github.com+27751938+amCap1712 at openjdk.org> wrote:

> JavaFX is no longer a part of OpenJDK. It makes sense to not treat it specially in the JDK. Hence, refactoring the Launcher class to remove JavaFX specific code.
> 
> Further investigation reveals that some JavaFX specific code is also present in the `javadoc` tool. For instance,
> https://github.com/openjdk/jdk/blob/master/src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/BaseOptions.java#L90-L96
> https://github.com/openjdk/jdk/blob/master/src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/BaseOptions.java#L347-L353
> I think we should remove this code as well and the related tests for it.

Please start a discussion on core-libs-dev before proposing this patch.

-------------

PR: https://git.openjdk.java.net/jdk/pull/978

From kartikohri13 at gmail.com  Sat Oct 31 16:05:06 2020
From: kartikohri13 at gmail.com (Kartik Ohri)
Date: Sat, 31 Oct 2020 21:35:06 +0530
Subject: 8248122: java.base should not handle JavaFX application in a specific
 way
Message-ID: <CAASLQ4MS+P2H-vdmkSfaG_OpSAjaZ1BgAD5eRS9jXVsKNt6Qzw@mail.gmail.com>

Hi!
JavaFX is no longer a part of OpenJDK. It does not make sense to treat it
specially in the JDK. Hence, as suggested in JDK-
<https://bugs.openjdk.java.net/browse/JDK-8248122>8248122
<https://bugs.openjdk.java.net/browse/JDK-8248122>, the Launcher class
should be refactored to remove the JavaFX specific handling code.
Accordingly, I have proposed a patch here
<https://github.com/openjdk/jdk/pull/978>.

All suggestions are welcome. Thank you.
Regards,
Kartik

From kcr at openjdk.java.net  Sat Oct 31 16:12:53 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Sat, 31 Oct 2020 16:12:53 GMT
Subject: RFR: 8248122: java.base should not handle JavaFX application in a
 specific way
In-Reply-To: <JOnqQYk6XV0JS_BsWe5Q0l15qz3Qu1nJ5BUjYLjtZTU=.b153ead3-170c-4bb2-9fd4-7dd4f713b77b@github.com>
References: <TjUfO--mHAmH_-39IOJk3J5Bp9BxTbAqMC4lglo9Mko=.87ae64a6-8f15-4726-af0d-3358c4bef38b@github.com>
 <JOnqQYk6XV0JS_BsWe5Q0l15qz3Qu1nJ5BUjYLjtZTU=.b153ead3-170c-4bb2-9fd4-7dd4f713b77b@github.com>
Message-ID: <v8Porjpc9cWId3vbEY1VF-FeSvtXhfiW-cADU7cN2xY=.68e93fd6-05d8-4bd8-a4c1-2373b1f20122@github.com>

On Sat, 31 Oct 2020 16:09:18 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> JavaFX is no longer a part of OpenJDK. It makes sense to not treat it specially in the JDK. Hence, refactoring the Launcher class to remove JavaFX specific code.
>> 
>> Further investigation reveals that some JavaFX specific code is also present in the `javadoc` tool. For instance,
>> https://github.com/openjdk/jdk/blob/master/src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/BaseOptions.java#L90-L96
>> https://github.com/openjdk/jdk/blob/master/src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/BaseOptions.java#L347-L353
>> I think we should remove this code as well and the related tests for it.
>
> This will cause a regression in behavior. It will break existing JavaFX applications that do not have a main program. It could also break applications that create or use certain JavaFX objects in the class initializer of their JavaFX application.
> 
> There was [some initial discussion](https://bugs.openjdk.java.net/browse/JDK-8202553?focusedCommentId=14176584&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14176584) around doing this as a follow-on to the removal of JavaFX from JDK 11, but if it is to be done, it needs to be discussed first. It would need to be done using a process similar to deprecation-for-removal. We would need to make changes in the JDK and/or JavaFX to warn about this in one release, and then remove it in the following. A CSR would be needed for both steps.
> 
> I note that while I disagree with the rationale described in [JDK-8248122](https://bugs.openjdk.java.net/browse/JDK-8248122) for making this change, I am not necessarily opposed to the change itself.

This also needs to be discussed on the openjfx-dev mailing list, since it will have behavioral compatibility implications for JavaFX.

-------------

PR: https://git.openjdk.java.net/jdk/pull/978

From kcr at openjdk.java.net  Sat Oct 31 16:12:53 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Sat, 31 Oct 2020 16:12:53 GMT
Subject: RFR: 8248122: java.base should not handle JavaFX application in a
 specific way
In-Reply-To: <TjUfO--mHAmH_-39IOJk3J5Bp9BxTbAqMC4lglo9Mko=.87ae64a6-8f15-4726-af0d-3358c4bef38b@github.com>
References: <TjUfO--mHAmH_-39IOJk3J5Bp9BxTbAqMC4lglo9Mko=.87ae64a6-8f15-4726-af0d-3358c4bef38b@github.com>
Message-ID: <JOnqQYk6XV0JS_BsWe5Q0l15qz3Qu1nJ5BUjYLjtZTU=.b153ead3-170c-4bb2-9fd4-7dd4f713b77b@github.com>

On Sat, 31 Oct 2020 15:25:13 GMT, Kartik Ohri <github.com+27751938+amCap1712 at openjdk.org> wrote:

> JavaFX is no longer a part of OpenJDK. It makes sense to not treat it specially in the JDK. Hence, refactoring the Launcher class to remove JavaFX specific code.
> 
> Further investigation reveals that some JavaFX specific code is also present in the `javadoc` tool. For instance,
> https://github.com/openjdk/jdk/blob/master/src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/BaseOptions.java#L90-L96
> https://github.com/openjdk/jdk/blob/master/src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/BaseOptions.java#L347-L353
> I think we should remove this code as well and the related tests for it.

This will cause a regression in behavior. It will break existing JavaFX applications that do not have a main program. It could also break applications that create or use certain JavaFX objects in the class initializer of their JavaFX application.

There was [some initial discussion](https://bugs.openjdk.java.net/browse/JDK-8202553?focusedCommentId=14176584&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14176584) around doing this as a follow-on to the removal of JavaFX from JDK 11, but if it is to be done, it needs to be discussed first. It would need to be done using a process similar to deprecation-for-removal. We would need to make changes in the JDK and/or JavaFX to warn about this in one release, and then remove it in the following. A CSR would be needed for both steps.

I note that while I disagree with the rationale described in [JDK-8248122](https://bugs.openjdk.java.net/browse/JDK-8248122) for making this change, I am not necessarily opposed to the change itself.

-------------

Changes requested by kcr (Author).

PR: https://git.openjdk.java.net/jdk/pull/978

From kevin.rushforth at oracle.com  Sat Oct 31 16:22:50 2020
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Sat, 31 Oct 2020 09:22:50 -0700
Subject: 8248122: java.base should not handle JavaFX application in a
 specific way
In-Reply-To: <CAASLQ4MS+P2H-vdmkSfaG_OpSAjaZ1BgAD5eRS9jXVsKNt6Qzw@mail.gmail.com>
References: <CAASLQ4MS+P2H-vdmkSfaG_OpSAjaZ1BgAD5eRS9jXVsKNt6Qzw@mail.gmail.com>
Message-ID: <4d685d22-b4c2-b02f-fa97-661104a72440@oracle.com>

As mentioned in the pull request, this cannot be done as proposed 
without causing a behavioral regression and breaking JavaFX 
applications. If done, it should be done carefully using a similar 
process to the deprecate-for-removal in one release (to give 
applications time to react and adapt) and then remove in a future release.

Before getting into a discussion of how to do it, though, can you say 
more about the reasons you want to do it?

-- Kevin


On 10/31/2020 9:05 AM, Kartik Ohri wrote:
> Hi!
> JavaFX is no longer a part of OpenJDK. It does not make sense to treat it
> specially in the JDK. Hence, as suggested in JDK-
> <https://bugs.openjdk.java.net/browse/JDK-8248122>8248122
> <https://bugs.openjdk.java.net/browse/JDK-8248122>, the Launcher class
> should be refactored to remove the JavaFX specific handling code.
> Accordingly, I have proposed a patch here
> <https://github.com/openjdk/jdk/pull/978>.
>
> All suggestions are welcome. Thank you.
> Regards,
> Kartik


From winterhalter at openjdk.java.net  Sat Oct 31 16:43:21 2020
From: winterhalter at openjdk.java.net (Rafael Winterhalter)
Date: Sat, 31 Oct 2020 16:43:21 GMT
Subject: RFR: 8202471: Make type annotations on owner type parameters
 available [v3]
In-Reply-To: <WJVy8_XXMJf5UOCifoPHUc06qVaU2MKlT_oosLaiqwg=.c2b16a91-64ce-4468-991c-a51ffd6b3202@github.com>
References: <WJVy8_XXMJf5UOCifoPHUc06qVaU2MKlT_oosLaiqwg=.c2b16a91-64ce-4468-991c-a51ffd6b3202@github.com>
Message-ID: <YZW0qbqzb0bbpaH80TwM_oQnj3UMb2U9SiAjLx95CEw=.3524c72c-079a-49ac-9e89-7ff901e87640@github.com>

> A method's or constructor's owner type might carry annotations on its potential type parameters but is never represented as parameterized type what makes these parameters inaccessible at runtime, despite the presence of parameter type annotations.

Rafael Winterhalter has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains one additional commit since the last revision:

  8202471: A method's or constructor's owner type might carry annotations on its potential type parameters but is never represented as parameterized type what makes these parameters inaccessible at runtime, despite the presence of parameter type annotations.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/851/files
  - new: https://git.openjdk.java.net/jdk/pull/851/files/7721c77b..fa2bca37

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=851&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=851&range=01-02

  Stats: 15937 lines in 529 files changed: 9219 ins; 4581 del; 2137 mod
  Patch: https://git.openjdk.java.net/jdk/pull/851.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/851/head:pull/851

PR: https://git.openjdk.java.net/jdk/pull/851

From github.com+27751938+amcap1712 at openjdk.java.net  Sat Oct 31 16:47:54 2020
From: github.com+27751938+amcap1712 at openjdk.java.net (Kartik Ohri)
Date: Sat, 31 Oct 2020 16:47:54 GMT
Subject: RFR: 8186085: (opt) add filter(), flatMap(),
 and map() methods to OptionalDouble/Int/Long
In-Reply-To: <b7KzeBxklrPQqohcMHsNfDtIKbYaZ_9qa5td3dV_Oe4=.542e7568-bf8b-47b9-979a-6864fcf7eece@github.com>
References: <b7KzeBxklrPQqohcMHsNfDtIKbYaZ_9qa5td3dV_Oe4=.542e7568-bf8b-47b9-979a-6864fcf7eece@github.com>
Message-ID: <-3VzAZKRIBxGn1ompqha9OBTeYP9mGBK8yzq3bZP4to=.ee9dfff4-b66f-42c3-b69d-ce60b52732bc@github.com>

On Sun, 25 Oct 2020 10:49:01 GMT, Kartik Ohri <github.com+27751938+amCap1712 at openjdk.org> wrote:

> Hi all,
> This PR intends to add filter, map and flatMap methods to the Optional classes for primitives. The rationale is consistency with the Optional class for objects and user convenience.
> Thanks.
> Regards,
> Kartik

Kindly review the patch. Thanks in advance!

-------------

PR: https://git.openjdk.java.net/jdk/pull/857

From herrick at openjdk.java.net  Sat Oct 31 18:34:08 2020
From: herrick at openjdk.java.net (Andy Herrick)
Date: Sat, 31 Oct 2020 18:34:08 GMT
Subject: RFR: JDK-8252870: Finalize (remove "incubator" from) jpackage [v5]
In-Reply-To: <HlksY2mFyKG_kkZA6n6JHHIWBGJT3bjmoLG28c9q1EU=.2b9faa66-08b9-4694-a5db-9d9918039642@github.com>
References: <HlksY2mFyKG_kkZA6n6JHHIWBGJT3bjmoLG28c9q1EU=.2b9faa66-08b9-4694-a5db-9d9918039642@github.com>
Message-ID: <d2iWaRCvAogWMryVGinnsvBP6PrgjkpkJrMqk9PUiAI=.b9bc239d-6b82-414d-bf03-5173ff3bae68@github.com>

> JDK-8252870: Finalize (remove "incubator" from) jpackage

Andy Herrick has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:

 - Merge branch 'master' into JDK-8252870
 - Merge branch master into JDK-8252870
 - Merge branch 'master' into JDK-8252870
 - JDK-8252870: Finalize (remove "incubator" from) jpackage
     - reverting two auto-generated files, and changing module-info to "@since 16"
 - JDK-8252870: Finalize (remove "incubator" from) jpackage
   Merge branch 'finalize' into JDK-8252870
 - 8252869 Finalize (remove incubator from) jpackage (implementation)

-------------

Changes: https://git.openjdk.java.net/jdk/pull/633/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=633&range=04
  Stats: 1733 lines in 259 files changed: 692 ins; 701 del; 340 mod
  Patch: https://git.openjdk.java.net/jdk/pull/633.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/633/head:pull/633

PR: https://git.openjdk.java.net/jdk/pull/633

From prr at openjdk.java.net  Sat Oct 31 20:46:55 2020
From: prr at openjdk.java.net (Phil Race)
Date: Sat, 31 Oct 2020 20:46:55 GMT
Subject: RFR: 8248122: java.base should not handle JavaFX application in a
 specific way
In-Reply-To: <v8Porjpc9cWId3vbEY1VF-FeSvtXhfiW-cADU7cN2xY=.68e93fd6-05d8-4bd8-a4c1-2373b1f20122@github.com>
References: <TjUfO--mHAmH_-39IOJk3J5Bp9BxTbAqMC4lglo9Mko=.87ae64a6-8f15-4726-af0d-3358c4bef38b@github.com>
 <JOnqQYk6XV0JS_BsWe5Q0l15qz3Qu1nJ5BUjYLjtZTU=.b153ead3-170c-4bb2-9fd4-7dd4f713b77b@github.com>
 <v8Porjpc9cWId3vbEY1VF-FeSvtXhfiW-cADU7cN2xY=.68e93fd6-05d8-4bd8-a4c1-2373b1f20122@github.com>
Message-ID: <k4aYsZ_h6lzHhtGZDDcytO9zT0VOk-wkM6GUmPvzmfg=.e3e28d98-b75a-4a18-8060-84a41d4ba712@github.com>

On Sat, 31 Oct 2020 16:10:23 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> This will cause a regression in behavior. It will break existing JavaFX applications that do not have a main program. It could also break applications that create or use certain JavaFX objects in the class initializer of their JavaFX application.
>> 
>> There was [some initial discussion](https://bugs.openjdk.java.net/browse/JDK-8202553?focusedCommentId=14176584&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14176584) around doing this as a follow-on to the removal of JavaFX from JDK 11, but if it is to be done, it needs to be discussed first. It would need to be done using a process similar to deprecation-for-removal. We would need to make changes in the JDK and/or JavaFX to warn about this in one release, and then remove it in the following. A CSR would be needed for both steps.
>> 
>> I note that while I disagree with the rationale described in [JDK-8248122](https://bugs.openjdk.java.net/browse/JDK-8248122) for making this change, I am not necessarily opposed to the change itself.
>
> This also needs to be discussed on the openjfx-dev mailing list, since it will have behavioral compatibility implications for JavaFX.

Indeed this is very much of out the blue and the pre-existence of a bug report discussing this does not mean it
has been accepted to be done .. 

And launcher changes need to be done carefully. I would expect them to come from someone who has a long history of contributions in this area and has had extensive discussions with stakeholders before moving on to code ..

-------------

PR: https://git.openjdk.java.net/jdk/pull/978

From winterhalter at openjdk.java.net  Sat Oct 31 21:11:15 2020
From: winterhalter at openjdk.java.net (Rafael Winterhalter)
Date: Sat, 31 Oct 2020 21:11:15 GMT
Subject: RFR: 8202471: Make type annotations on owner type parameters
 available [v4]
In-Reply-To: <WJVy8_XXMJf5UOCifoPHUc06qVaU2MKlT_oosLaiqwg=.c2b16a91-64ce-4468-991c-a51ffd6b3202@github.com>
References: <WJVy8_XXMJf5UOCifoPHUc06qVaU2MKlT_oosLaiqwg=.c2b16a91-64ce-4468-991c-a51ffd6b3202@github.com>
Message-ID: <kQyOv9xmyNPvRKuHMG9b6ev3HV7pt_GGAZe_ki12vgM=.8afc6c47-a01c-432e-9739-9c69bc121932@github.com>

> A method's or constructor's owner type might carry annotations on its potential type parameters but is never represented as parameterized type what makes these parameters inaccessible at runtime, despite the presence of parameter type annotations.

Rafael Winterhalter has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  8202471: A method's or constructor's owner type might carry annotations on its potential type parameters but is never represented as parameterized type what makes these parameters inaccessible at runtime, despite the presence of parameter type annotations.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/851/files
  - new: https://git.openjdk.java.net/jdk/pull/851/files/fa2bca37..ac306162

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=851&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=851&range=02-03

  Stats: 21 lines in 3 files changed: 15 ins; 0 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/851.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/851/head:pull/851

PR: https://git.openjdk.java.net/jdk/pull/851